编程领域不仅仅关乎代码。许多企业一开始都认为开发人员只需要学习编程语言就可以了。但是，要想让开发人员效率更高，企业还必须了解代码的细微差别及其与编码内容的关系。
代码不仅仅是代码，它还编纂了规则，集成了人们对编程内容的理解与解读。如果开发人员无法理解编程的内容，就无法高效地工作。
这也是为什么开发人员不仅仅是程序猿——他们的工作不仅限于根据给定的、相对模糊的营销需求来敲键盘。虽然这种情况很常见，但事实上，开发人员绝不应止步于此——尤其是想成为一名敏捷的开发人员。
对于敏捷的误解
敏捷是一个有趣的词。很多人都似乎“了解”它。企业更是深信不疑地认为自己在践行这一点。但很多人都理解错了。大部分情况下，敏捷变成了奇怪的瀑布式开发。一个项目被划分为几个阶段，最后一次性交付给客户，这种情况很常见。
在瀑布式开发，或者说伪敏捷开发中，开发人员都无法参与到中间流程中，只负责最后的流程。但开发人员不是泥瓦匠，也不应该被那样对待。
当马丁·福勒 、罗伯特·马丁和其他15位软件开发领军者在《敏捷软件开发宣言》上署名时，他们的侧重点是革新软件的开发方式，赋予开发人员在工作中更多的有效性与自主权。
这在一定程度上是因为他们认识到开发人员不是一味执行他人计划的机器人。他们还是建筑师、工程师和建设者，通常被包装成一个独特的角色。他们是你的全栈工程师、软件开发人员、IT运维技术人员和混合开发人员，有着交叉领域的知识和技术。他们是专业技术人才，也是通才。
企业如何改变这一现状
如果开发人员觉得自己只是个程序猿，那么解决这一问题就是一个机构层面的过程和结构问题。如果你是小型初创企业的一员，处理这一问题可能要比思维模式根深蒂固、工作关系稳固的大企业容易一些。
敏捷开发的目的是通过循环交付为企业创造速度和流动性。与主流观点相反，软件从来都不是一个完整的产品。人们总是要对软件做一些修改——无论是基于市场需求，还是由于不可预见的情况引起了错误，亦或是这一修改对公司发展至关重要。软件开发中唯一的永恒的就是改变本身，这是无法避免的。
为了应对这些变化，开发团队必须要小——那种人数在一位数或两位数出头、两张披萨就可以管饱的小团队。杰夫·贝佐斯称之为“双披萨原则”。一个大项目拥有多个团队无可厚非，但关键是要把人数维持在最低标准，这样才能实现成员间的有效沟通。
每个团队可以在一个团队主管或负责人的带领下负责一个功能，但团队主管或负责人必须有效地将战略性开发计划传达给每一个成员。这点至关重要，因为它能让开发人员提前构思代码和结构，想出有效的自动化流程方法，使其输出结果与企业需求保持一致。
自主、负责地创建代码
代码或许是开发人员创建的最终输出，但它也受市场营销、管理、商业团队和任何关系到最终输出的人的影响。当出现问题时，不能只责怪代码。
最高效的开发人员也会参与到沟通、用户故事创建、最终决策制定和交付功能排序等其他过程中。这种参与非常重要，因为它可以让开发人员了解他们编码的领域。如果开发人员不了解这一领域的知识和实践，或者在这方面没有牢固的基础，那么他们必不能将企业的规则和要求有效地转化为‘计算机语言’。
编程不仅仅是编程语言，还是对规则和期望的集成，同时也要让电脑以人类能明白的方式去理解和重现这些规则与期望。如果代码因开发人员对源代码的误解而出错，假设他们的能力没有问题，那么就是没能准确理解企业对数字材料格式的需求。
对于别人的代码又能做些什么呢?
有时，开发团队可能继承前一支团队的代码。这些代码可能很好。但通常情况下，由于遗留方法、过时的格式和当时流行但现在低效的工程模式，这些代码现在可能不适用了。
这种情况时常发生，尤其是对于那些在软件开发行业干了很多年的人。虽然这些代码是过时的产品，但企业及其团队依然要对其负责。每个软件、硬件和基础架构都有保质期，超过了5年就要接受检测，使其适应新的时代。还能用并不代表还能保持高效——这也可能成为团队敏捷开发能力的主要瓶颈。
这一点开发人员最清楚，当参与更高层次的沟通和决策时，他们可以充分规划更新并创建应急计划，以降低遗留系统带来的风险。直接在遗留系统中添加新功能无异于在检查旧房子结构完整性之前拆除房梁。如果真的这样做了，你永远也不知道这个房子什么时候或是否会坍塌。
结语
代码如同数字房地产，企业需要接受的事实是，开发人员不仅仅是程序猿。只有当开发人员被视为一个具有凝聚力、跨功能团队的一员时，他们的编码能力才会有效提高。
把开发人员都放到项目的末尾就如同凭借一些草图和一块平顶木板盖房子。开发人员的职责是选择、构建、美化及其中间的所有流程，最终将企业的理想转化为现实。这就是为什么在项目开发周期中，尽早让开发人员参与其中至关重要。
