这是纪律工程系列的第一部分。 它是为那些想为他们的组织建立一种卓越工程文化的团队准备的。对于已经有既定流程的团队，我们推荐阅读第二部分：创建代码信心。如果你想进一步改善你的流程，请查看第三部分：完善你的工程流程。
建立一个工程流程
对于任何一个健康的工程组织来说，一个明确的将一个功能从开始到生产的过程是至关重要的。拥有明确流程的团队能够以更快的速度写出质量更好的代码，并且更加灵活和独立。
许多组织的第一步是了解你目前的结构并记录你的流程的基本要素。这些流程应该由你的团队中所有在项目中发挥积极作用的工程和业务成员来确定和同意。一旦知道了这些流程，它们必须被记录下来，并在团队中的每个人之间分享。这为你的团队建立和完善你的工程流程打下了基础，并对每个人如何为发布一个功能做出贡献有了共同的理解。
一旦你了解了你目前的流程，你和你的团队就可以对它进行迭代，以进行改进和解决关切。创造这种积极的反馈循环是许多工程流程的基础，从敏捷到测试驱动开发和许多其他的流程。反馈环路涉及到完成一定数量的工作，然后评估这些工作，以便做出积极的改变。这些定期的评估和细微的修正使你的项目在长期的质量和可持续性方面有显著的改善。
我们已经帮助许多团队改善了他们的流程，使他们的组织发挥出最好的作用。在你的组织内建立一个工程流程将使你的团队能够更好地对变化做出反应，如加入一个团队成员或将你的组织转变为在家工作，因为每个人都会有众所周知的、记录在案的方法来产生工作。以下是我们发现的有助于提高应用质量和工程组织的可持续性的基本做法。
定义 "完成"（Done
一个团队在建立他们的流程时，首先要做的是确定一个功能从开始到生产所经历的步骤。用敏捷的说法，这通常是就 "完成 "的定义达成一致。
例如，一个团队可能将 "完成 "定义为一个故事已经经历了所有这些阶段。
- 故事已被添加到冲刺中
- 代码已经完成
- 单元和功能测试已经写好并通过
- 代码被审查和合并
- 业务部门已经审查了该功能并签字确认
- 功能已被确定为发布到生产中
这并不是一套开发特性的全面说明。相反，它提供了一个基本框架，允许团队建立角色和责任。现在，团队可以将人员和角色分配到流程的每个步骤。它还会围绕你的流程强调一些问题，比如，"代码审查是什么样子的？"和 "故事什么时候可以加入到冲刺中？"回答这些问题将为你的流程的其余部分提供信息。
冲刺计划
冲刺计划是任何工程过程中的第一步。它是整个团队聚集在一起，与工程和业务部门讨论一组计划中的功能的第一个机会。在规划结束时，团队中的每个人都应该对冲刺期间要进行的工作有一个很好的理解。
为了确保每个人都能正确执行计划中的冲刺，需要采取一些步骤。首先，为冲刺计划的功能应该介绍给团队的其他成员。实施者（工程师、设计师、QA等）然后提出问题，确定工作的范围，然后再给功能分配一个点值。在确定故事的大小时，重要的是要考虑到可能是工作的一部分的任何风险或不确定性。例如，与需要新的或很少使用的方法的功能相比，增加一个遵循你的组织所记录的知名模式的功能，其本身的风险较小（因此应该分配较少的点数）。 一旦确定了工作的规模，项目经理就可以与产品所有者和工程师合作，将工作分配到冲刺阶段。加到冲刺中的工作量应该大致等于以前冲刺中完成的点数（即你的平均速度），并得到整个团队的同意。
一组功能被分配后，应该由工程师和其他负责完成工作的人将其分解成更小的步骤。每个步骤都应该包括一个范围有限的工作，以便在合理的时间内完成。如何做到这一点，以及每一步有多小，应该由团队决定。在分解任务的时候，工程师应该依靠团队的文件模式和先前的工作来确定那些将遵循已知路径完成的任务。任何不遵循已知模式的工作都应该包括一个设计阶段，实施者可以和另一个团队成员一起审核一个方法。这一步对于尽快确定最佳方法至关重要。跳过这一步的团队往往最终会在代码审查中重新设计解决方案，这对质量、士气和速度都有严重影响。
建立共享的知识
在项目的整个过程中，团队不断地做出决定。对于工程师来说，这些决定往往是关于如何解决一个特定的问题。例如，一个常见的决策点往往是："我的团队如何在前端、后端以及两者之间表示一个日期？"最理想的情况是，这些重要的决定是在规划期间确定的，其中有记录的决定可以作为设计的一部分来参考--没有记录的决定是已知的风险，必须解决并记录。
围绕着可重用模式或基础流程的重要决定应该被存储在一个突出的、一致的位置，作为单一的真理来源。许多没有写下他们的通用模式的团队过于依赖机构知识，这些知识使人们的理解只停留在少数关键贡献者身上（关于这一点，请参阅TalkScript 53: Single Point of Failure）。这迫使工程师在参加每一次会议之间做出选择，这样他们就可以不断地了解未记录的信息，或者冒着被抛在后面的风险，产生缓慢、次优的工作。不记录共享知识也会对许多其他做法产生负面影响，从建立一个一致的速度到有效地接纳一个新的团队成员。 这就是为什么团队应该优先创建和维护一个组织良好、精简的中央知识库，以便工程师能够有效地找到和分享共同的模式和架构决策。
在冲刺的过程中，工程师应该记录他们在开发过程中提出的问题和假设。出现的新模式和解决方案应该作为一个小型的设计阶段，尽早与另一个工程师进行审核。然后，两位工程师应该负责分享商定的设计，并在团队的中央知识库中记录出现的任何模式。这将确保知识在团队中的共享，反过来，质量和一致性也将得到保持。将知识共享作为优先事项的团队通常会看到所有贡献者的速度都有明显的提高。
回顾性研究
回顾是一个迭代和完善工程流程的机会。团队中的每个人都应该回答两个问题：哪些工作做得好，哪些需要改进。回顾性检查的目的是识别过程中的缺陷，并作出改变以保证应用的质量。因此，进行无责审查是很重要的。应该把失败看成是整个团队的责任，以完善他们的流程，防止它再次发生。
这也是一个收集并与团队其他成员分享指标的好时机。衡量标准应该反映你的工程过程的质量和可持续性。例如，在回顾会议开始时，花时间回顾一下与平均速度相比完成了多少点，可以为其余的讨论定下基调。工程部也应该收集和分享能够加强他们努力的指标。例如，如果增加单元测试是团队的一项举措，那么分享分支覆盖率是强调工程部重要投资的一个很好的方法。分享反映应用程序质量的指标是很重要的。没有这些信息，团队往往没有信息来识别风险，直到事情开始失败。
总结
创建一个关心软件质量的良好文化，是任何组织的一个令人钦佩的目标。质量可以通过渐进的、精心设计的流程来实现，并得到组织各方的支持。我们已经触及了建立以迭代和自我评价为中心的工程文化的基本要素。任何组织只要从这里开始，就可以建立一个成功而有效的工程文化。
你可以在第二部分 "完善你的工程流程"或第三部分 "在你的工程项目中创建代码信心"中阅读更多关于这个主题的内容。很多时候，组织根本没有时间来解决工程改进问题。如果你需要帮助，请联系我们以了解更多。我们已经帮助许多组织完善了他们的流程!
