编程的领域不只是代码。许多企业开始时认为开发人员只需要学习一种编程语言。但为了提高开发人员的工作效率，企业还必须了解代码的细微差别以及代码与编码内容的关系。代码不仅仅是代码，它还编纂了规则，整合了人们对编程内容的理解和解释。如果开发人员无法理解要编程的内容，他们就无法提高工作效率。这也是开发人员不仅仅是编码员的原因——他们的工作不限于为给定的、相对模糊的营销需求敲键盘。虽然这种情况很常见，但现实是开发人员永远不应该就此止步——尤其是如果有人想成为一名敏捷开发人员。关于敏捷的误解敏捷是一个有趣的词。很多人似乎“明白”了它。企业更加坚信自己正在践行这一点。但是很多人都弄错了。在大多数情况下，敏捷变成了怪异的瀑布式开发。一个项目被分成几个阶段并最终一次性交付给客户的情况并不少见。在瀑布式开发，或者伪敏捷开发中，开发人员不能参与中间过程，只负责最后的过程。但开发人员不是泥瓦匠，也不应该被这样对待。当MartinFowler、RobertMartin和其他15位软件开发领导者在《敏捷软件开发宣言》上签名时，他们的重点是彻底改变软件的开发方式，让开发人员在工作中更有效率和自主权。这部分是因为他们认识到开发人员不是执行他人计划的机器人。他们也是建筑师、工程师和建筑商，通常被包装成一个独特的角色。他们是你的全栈工程师、软件开发人员、IT运维技术人员和混合开发人员，拥有跨领域的知识和技术。他们是技术专家和通才。企业如何改变这一点如果开发人员觉得他们只是程序员，那么解决这个问题就是组织层面的流程和结构问题。如果你是一家小型初创公司的一员，处理这个问题可能比在具有根深蒂固的心态和稳固的工作关系的大公司更容易。敏捷开发的目的是通过循环交付为企业创造速度和流动性。与流行的看法相反，软件从来都不是一个完整的产品。人们总是不得不对软件进行一些更改——无论是基于市场需求、不可预见的情况导致的错误，还是对公司成长至关重要的更改。软件开发中唯一不变的就是变化本身，这是不可避免的。为了应对这些变化，开发团队必须很小——可以用两个比萨饼喂饱的那种，个位数或早期两位数。JeffBezos称之为“双披萨原则”。一个大项目有多个团队没有错，但关键是要将人数控制在最低限度，这样才能实现成员之间的有效沟通。每个团队可以在团队领导或领导的领导下负责一个特性，但团队领导或领导必须有效地将战略发展计划传达给每个成员。这一点很关键，因为它允许开发人员提前构思代码和结构，并想出有效的方法来自动化流程，使其输出符合业务需求。自主且负责任地创建代码代码可能是开发人员创建的最终输出，但它也会受到营销、管理、商业团队以及与最终输出有利益关系的任何其他人的影响。当出现问题时，您不能只责怪代码。最有效的开发人员还参与其他流程，例如沟通、用户故事创建、最终决策制定和交付功能的排序。这种参与很重要，因为它可以让开发人员了解他们正在编码的领域。如果开发人员不了解该领域的知识和实践，或者在该领域没有扎实的基础，那么他们一定无法有效地翻译将企业的规则和要求转化为“计算机语言”。编程不仅仅是一种编程语言，更是规则和期望的融合，也需要计算机以人类能够理解的方式理解和再现这些规则和期望。如果由于开发者对源代码的误解导致代码错误，假设他们的能力没有问题，那么就没有准确理解企业对数字资料格式的需求。用别人的代码能做什么？有时，开发团队可能会从以前的团队继承代码。这些代码可能没问题。但通常情况下，由于遗留方法、过时的格式以及当时流行但现在效率低下的工程模式，这些代码现在可能不适用。这种情况经常发生，尤其是对于那些在软件开发行业工作多年的人来说。虽然这些代码是过时的产品，但企业和他们的团队仍然要对它们负责。每一个软件、硬件和基础设施都有超过5年的保质期，并经过测试以适应新时代。可用并不意味着它仍然高效——它也可能成为团队敏捷开发能力的主要瓶颈。开发人员最了解这一点，当参与更高级别的沟通和决策制定时，他们可以充分规划更新并制定应急计划以减轻遗留系统带来的风险。将新功能直接添加到遗留系统中类似于在检查其结构完整性之前从旧房子中拆除横梁。如果确实如此，您永远不知道房屋何时或是否会倒塌。EpilogueCode就像数字房地产，企业需要接受开发人员不仅仅是程序员。只有当开发人员被视为一个有凝聚力的跨职能团队的一部分时，他们的编码能力才能有效提高。将开发人员全部放在项目的最后，就像用几张草图和平屋顶盖房子一样。开发者的角色是选择、构建、美化以及这之间的所有过程，最终将企业的理想化为现实。这就是让开发人员尽早参与项目开发周期至关重要的原因。
