软件开发总结-开发模式选择

 

改善协作

想象一个软件开发组织，它和市场紧密连接，可以随时交付完成的工作或调整方向，对市场做出准确的反应，这样的组织必然会在市场竞争中占据优势。响应能力是所有软件开发组织所期望具备的，但真正能做到的却很少。究竟是什么影响了组织的响应能力。从内部看，主要是堆积的“在制品”，和技术及学习“债务”。从外部看主要是和市场的连接程度，也即研发团队和业务人员、用户的协作。以下将分别分析这三个方面对组织响应能力的影响。

“在制品”是响应外部变化的负担

所谓“在制品”（Work In Progress，WIP），是指已经开始但未完成（可以向最终用户交付）的工作。主要包括：未实施的决策、未实现的设计、未集成的编码和未验证的系统。

图1是一个典型的瀑布开发模型，需求阶段产出系统的全部需求规格说明；分析设计阶段产出整个系统的架构和详细设计；测试验证前完成所有的代码。这些都属于不可交付的“在制品”，在整个开发过程中，都无法交付软件以响应客户的需求。另外，在项目开发过程中，任何需求的变更，都意味着对“在制品”的返工，例如在编码结束时需求发生了变化，意味着前期的需求分析、架构和详细设计，以及编码都要进行返工，这引入了需求变更的额外成本。因为这些原因，团队无法在较低额外开销的情况下，随时向客户交付产品或改变方向，其响应能力必然是受限的。

图1 瀑布模型下的在制品及其影响

如图2所示，理想的迭代模式下，“在制品”仅仅存在于迭代之内。团队在迭代开始时，计划一部分需求，迭代结束时产生可交付的软件，清空所有的“在制品”。这样的模式为提升组织的响应能力提供了可能，1）迭代结束时软件是可交付的，可以通过交付它们来响应市场的需要。2）每个迭代开始前，都可以对产品的功能需求和规划做出调整，响应市场、用户及相关各方的反馈。而且因为迭代结束时“在制品”的数量为零，不存在对“在制品”的返工成本。

图2 理想的迭代开发模型

即使是迭代开发，大部分团队并不能做到迭代产出物的直接可交付。如图3所示，在一个典型的迭代开发中，每个迭代产生可运行的软件。但可运行不等于可交付，由于技术手段等的限制，迭代结束时会有遗留未完成工作。随着迭代的进展，未完成工作不断累积，形成迭代开发模式下的“在制品”，它们损害了组织响应能力。首先，可运行的软件加上未完成的工作，才构成可交付的软件。也就是交付软件前必须完成这些工作，组织无法随时交付以响应客户的需求。其次，这些“在制品”也意味着风险，未完成工作的不确定性，使得交付更加不可控，损害响应能力。

图3 现实迭代模型的WIP

技术和学习“债务”（debts）加大响应的难度

“债务”是指将来某个时刻要偿还的负担。如图4所示，如果没有适当技术实践的支持，随着迭代的进行，既有代码的单元测试工作增加；功能回归测试工作量变大；代码质量因频繁变更而变差；系统越来越复杂，团队成员却缺乏对系统的理解。这些构成了软件开发中的“债务”，它们加大了将来系统修改、测试的难度，因而降低了系统的响应能力。

图4 技术债务和学习债务的积累

“债务”又可以分为技术“债务”（tech. Debts）和学习“债务”（learning Debts）。技术“债务”是指因系统的不良设计、实现和测试，导致系统在需要变更时，难以被理解，难以改变；改变后，难以验证代码的正确性；难以对既有功能进行回归测试。学习“债务”是指，在开发过程中，团队成员未能及时分享和掌握业务及实现相关的知识，加大系统变难度，而且更容易引入质量问题，甚至新的技术“债务”。“债务”对系统的影响，并不会立刻显现。但长期来看，它会使系统响应变化时，耗费时间更长，成本更高，引入质量问题的可能性更大，严重损害组织的响应能力。

有效的协作决定响应及时性和准确

“在制品”数量、“债务”水平决定了软件开发组织的内部响应性，与之同样重要的是响应的准确性。它取决于组织与外部的连接程度，也就是团队与用户及业务人员有效协作，以及团队内部有效协作，即时获取、整合市场信息，并准确传递至开发团队，有效地落实到开发活动当中。

综上所述，只有降低“在制品”，维持低“负债”，并合理协作，才能保证准确、即时地响应，达成目标。敏捷开发的实践正是在构建这样一个系统。

实施敏捷

从一定程度上说，敏捷软件开发就是通过系统的实践，减少“在制品”数量，降低“债务”水平和改善协作来提高组织的响应能力。表1列举常见的敏捷实践，并分析了它们对于以上三个方面的贡献。我们将这些实践分成了三类—管理实践、团队技术实践和个人技术实践，下面将分别对这些实践加以总结。

表1 敏捷实践分

管理实践

• 用户故事：用户故事是端到端的，足够小需求单元。用户故事应该是具备用户价值和可交付的。它作为敏捷开发中计划的单位，为减少“在制品”提供了可能。同时，它是从用户的角度出发，以用户的语言描述需求，是用户、业务人员和开发团队沟通的起点和工具，改善了他们之间的协作。

• 短迭代开发，小版本发布：短迭代开发模式下，每个迭代产生可交付的软件，“在制品”始终控制在迭代内，处于较低的水平。小版本发布，即时获取用户的反馈，为调整产品的方向提供了最可靠的输入，使开发团队与用户的协作变得具体和有效。

• 自组织的多功能团队：多功能的团队，避免了工作在各个功能团队间的传递和等待，极大降低了“在制品”产生的可能，和维持的时间。同时，多功能团队成员间的知识共享和学习也降低了学习的“债务”。团队的自组织，使决策可以在团队层面迅速做出，减少了等待和批准的时间，避免 “在制品”的累积。

团队技术实践

• 持续集成：持续集成作为一个开发实践，强调小步地增加功能，并随时集成、验证，始终维持可运行的软件系统，使“在制品”数量控制在一个低水平。同时，持续集成作为一个团队纪律，保证被集成的代码能达到定义的质量标准，如通过代码规则检查，自动测试等，屏蔽特定类型的技术“债务”。

• 统一语言：使用领域专家的语汇（领域语言）作为开发团队、业务人员以及用户之间的沟通语言，减少沟通中产生误解的可能，提高沟通效率。代码中出现的概念也应该与领域语言保持一致，这进一步确保了实现和领域之间的一致，既改善了合作，也降低了因系统理解难度而带来的技术“债务”。

接收测试驱动开发：在开发活动前，由业务、开发人员和测试人员共同参与，用实例对需求进行细化和澄清，确保大家的一致理解。这首先是一个良好的沟通工具，使三方的合作变得有序和有效。另一方面这些实例将成为功能测试自动化的起点，降低了测试相关的技术“债务”；这些实例同时还会成为理解系统的依据，降低了学习“债务”。

个人技术实践

• 整洁代码：代码仅实现功能是不够的，整洁的代码清晰的表达意图，易于理解和改变。整洁的代码降低了技术“债务”。

• 设计原则和实践：不管是Robert.C.Martin的S.O.L.I.D.原则，还是其它一些耳熟能详的设计原则，如消除重复、分离关注点和向稳定依赖等，其目的都是要产生一个高内聚、低耦合的系统，使系统易于变更和维护，减少技术“债务”。

• 持续重构：随着变更的引入，即使是好代码也有变坏的倾向，产生技术“债务”。持续重构正是要消除这些技术“债务”，维持代码的整洁，并使之符合基本的设计原则。持续重构应该是团队和个人的工程习惯，而非一次性的行为。

• 简单设计：过度设计带来的复杂性，本身就会成为未来变更的负担（债务）。另一方面，超越当下功能要求的设计无法得到充分的功能验证，会成为“在制品”。简单设计在实现功能、消除重复，以及清晰表达的前提下，力求用最少的元素实现系统。

• 自动单元测试， 测试驱动开发：单元测试是系统健壮性的基石，设计良好的自动化单元测试是系统最有效的防护网，它确保代码发生变更时，原有意图不被破坏。也只有有了单元测试的保护，重构才可能持续安全地进行。测试驱动开发则是产生良好设计的手段，同时它往往能生成最优和最及时的单元测试用例。

• 结对编程：结对编程有机综合了两个程序员的思维能力，更容易产生设计和实现良好的代码。同时，通过持续的代码检查，减少错误引入，并在开发人员之间有效传递了知识，降低了技术和学习“债务”。

以上，我们从响应能力出发，梳理了敏捷软件开发中的主要实践，这些实践并非为敏捷软件开发所专享。其实施，也非一蹴而就，需要以团队整体技术和管理水平的提高作为支撑。否则反而可能会带来新的“在制品”和“债务”，特别是“债务”。比如，引入单元测试自动化是为了减少技术“债务”，但如果单元测试自动化本身设计不良，测试用例过分依赖于实现细节。这样，对实现细节的改变，会影响到测试用例的正确运行，反而使单元测试成为负担，提高变更的成本，降低响应能力。

敏捷的实践之间是相互关联的，成为一个有机系统，才能发挥效益。管理实践之间是相互支持的。例如，离开多功能的团队，开发任务就必须在多个功能团队之间传递，无法做到短迭代开发。 技术实践之间是相互支持的。例如，没有单元测试自动化的保障，持续重构的风险将激增，在操作上变得不现实；有了持续重构保障，维持一个最简单的系统设计，需要时再通过重构，使设计适应新的变化要求，简单设计才更可能得以实施。技术实践和管理实践也是相互支持的。例如，短迭代开发中没有技术实践支持，就会不断积累技术“债务”，产品质量和开发效率不断下降；而，短迭代内全生命周期的反馈，也为各类技术实践的部署提供了便利。

综上，敏捷实践的应用和团队技术水平的提高，相辅相成，在应用中不断总结提高，构建和完善实践体系，加强客户、业务人员和团队的合作，以及团队内部的合作，持续、有效地减少“在制品”，以及技术和学习“债务”，提升组织的整体技术和管理水平，只有这样才能构建可持续的响应能力。