软件开发模式

改善协作 想象一个软件开发组织，它和市场紧密连接，可以随时交付完成的工作或调整方向，对市场做出准确的反应，这样的组织必然会在市场竞争中占据优势。响应能力是所有软件开发组织所期望具备的，但真正能做到的却很少。究竟是什么影响了组织的响应能力。从内部看，主要是堆积的“在制品”，和技术及学习“债务”。从外部看主要是和市场的连接程度，也即研发团队和业务人员、用户的协作。以下将分别分析这三个方面对组织响应能力的影响。 “在制品”是响应外部变化的负担 所谓“在制品”（Work In Progress，WIP），是指已经开始但未完成（可以向最终用户交付）的工作。主要包括：未实施的决策、未实现的设计、未集成的编码和未验证的系统。 图1是一个典型的瀑布开发模型，需求阶段产出系统的全部需求规格说明；分析设计阶段产出整个系统的架构和详细设计；测试验证前完成所有的代码。这些都属于不可交付的“在制品”，在整个开发过程中，都无法交付软件以响应客户的需求。另外，在项目开发过程中，任何需求的变更，都意味着对“在制品”的返工，例如在编码结束时需求发生了变化，意味着前期的需求分析、架构和详细设计，以及编码都要进行返工，这引入了需求变更的额外成本。因为这些原因，团队无法在较低额外开销的情况下，随时向客户交付产品或改变方向，其响应能力必然是受限的。 图1 瀑布模型下的在制品及其影响 如图2所示，理想的迭代模式下，“在制品”仅仅存在于迭代之内。团队在迭代开始时，计划一部分需求，迭代结束时产生可交付的软件，清空所有的“在制品”。这样的模式为提升组织的响应能力提供了可能，1）迭代结束时软件是可交付的，可以通过交付它们来响应市场的需要。2）每个迭代开始前，都可以对产品的功能需求和规划做出调整，响应市场、用户及相关各方的反馈。而且因为迭代结束时“在制品”的数量为零，不存在对“在制品”的返工成本。 图2 理想的迭代开发模型 即使是迭代开发，大部分团队并不能做到迭代产出物的直接可交付。如图3所示，在一个典型的迭代开发中，每个迭代产生可运行的软件。但可运行不等于可交付，由于技术手段等的限制，迭代结束时会有遗留未完成工作。随着迭代的进展，未完成工作不断累积，形成迭代开发模式下的“在制品”，它们损害了组织响应能力。首先，可运行的软件加上未完成的工作，才构成可交付的软件。也就是交付软件前必须完成这些工作，组织无法随时交付以响应客户的需求。其次，这些“在制品”也意味着风险，未完成工作的不确定性，使得交付更加不可控，损害响应能力。 图3 现实迭代模型的WIP 技术和学习“债务”（debts）加大响应的难度 “债务”是指将来某个时刻要偿还的负担。如图4所示，如果没有适当技术实践的支持，随着迭代的进行，既有代码的 单元测试 部编版二年级下册第二单元测试题部编版二年级下册第二单元测试卷部编版二年级下册第二单元测试部编版二年级下册语文第二单元测试卷人教版七年级下册英语单元测试卷 工作增加；功能回归测试工作量变大；代码质量因频繁变更而变差；系统越来越复杂，团队成员却缺乏对系统的理解。这些构成了软件开发中的“债务”，它们加大了将来系统修改、测试的难度，因而降低了系统的响应能力。 图4 技术债务和学习债务的积累 “债务”又可以分为技术“债务”（tech. Debts）和学习“债务”（learning Debts）。技术“债务”是指因系统的不良设计、实现和测试，导致系统在需要变更时，难以被理解，难以改变；改变后，难以验证代码的正确性；难以对既有功能进行回归测试。学习“债务”是指，在开发过程中，团队成员未能及时分享和掌握业务及实现相关的知识，加大系统变难度，而且更容易引入质量问题，甚至新的技术“债务”。“债务”对系统的影响，并不会立刻显现。但长期来看，它会使系统响应变化时，耗费时间更长，成本更高，引入质量问题的可能性更大，严重损害组织的响应能力。 有效的协作决定响应及时性和准确 “在制品”数量、“债务”水平决定了软件开发组织的内部响应性，与之同样重要的是响应的准确性。它取决于组织与外部的连接程度，也就是团队与用户及业务人员有效协作，以及团队内部有效协作，即时获取、整合市场信息，并准确传递至开发团队，有效地落实到开发活动当中。 综上所述，只有降低“在制品”，维持低“负债”，并合理协作，才能保证准确、即时地响应，达成目标。敏捷开发的实践正是在构建这样一个系统。 实施敏捷 从一定程度上说，敏捷软件开发就是通过系统的实践，减少“在制品”数量，降低“债务”水平和改善协作来提高组织的响应能力。表1列举常见的敏捷实践，并分析了它们对于以上三个方面的贡献。我们将这些实践分成了三类—管理实践、团队技术实践和个人技术实践，下面将分别对这些实践加以 总结 初级经济法重点总结下载党员个人总结TXt高中句型全总结.doc高中句型全总结.doc理论力学知识点总结pdf 。 表1 敏捷实践分 管理实践 · 用户故事：用户故事是端到端的，足够小需求单元。用户故事应该是具备用户价值和可交付的。它作为敏捷开发中计划的单位，为减少“在制品”提供了可能。同时，它是从用户的角度出发，以用户的语言描述需求，是用户、业务人员和开发团队沟通的起点和工具，改善了他们之间的协作。 · 短迭代开发，小版本发布：短迭代开发模式下，每个迭代产生可交付的软件，“在制品”始终控制在迭代内，处于较低的水平。小版本发布，即时获取用户的反馈，为调整产品的方向提供了最可靠的输入，使开发团队与用户的协作变得具体和有效。 · 自组织的多功能团队：多功能的团队，避免了工作在各个功能团队间的传递和等待，极大降低了“在制品”产生的可能，和维持的时间。同时，多功能团队成员间的知识共享和学习也降低了学习的“债务”。团队的自组织，使决策可以在团队层面迅速做出，减少了等待和批准的时间，避免 “在制品”的累积。 团队技术实践 · 持续集成：持续集成作为一个开发实践，强调小步地增加功能，并随时集成、验证，始终维持可运行的软件系统，使“在制品”数量控制在一个低水平。同时，持续集成作为一个团队纪律，保证被集成的代码能达到定义的质量标准，如通过代码规则检查，自动测试等，屏蔽特定类型的技术“债务”。 · 统一语言：使用领域专家的语汇（领域语言）作为开发团队、业务人员以及用户之间的沟通语言，减少沟通中产生误解的可能，提高沟通效率。代码中出现的概念也应该与领域语言保持一致，这进一步确保了实现和领域之间的一致，既改善了合作，也降低了因系统理解难度而带来的技术“债务”。 接收测试驱动开发：在开发活动前，由业务、开发人员和测试人员共同参与，用实例对需求进行细化和澄清，确保大家的一致理解。这首先是一个良好的沟通工具，使三方的合作变得有序和有效。另一方面这些实例将成为功能测试自动化的起点，降低了测试相关的技术“债务”；这些实例同时还会成为理解系统的依据，降低了学习“债务”。 个人技术实践 · 整洁代码：代码仅实现功能是不够的，整洁的代码清晰的表达意图，易于理解和改变。整洁的代码降低了技术“债务”。 · 设计原则和实践：不管是Robert.C.Martin的S.O.L.I.D.原则，还是其它一些耳熟能详的设计原则，如消除重复、分离关注点和向稳定依赖等，其目的都是要产生一个高内聚、低耦合的系统，使系统易于变更和维护，减少技术“债务”。 · 持续重构：随着变更的引入，即使是好代码也有变坏的倾向，产生技术“债务”。持续重构正是要消除这些技术“债务”，维持代码的整洁，并使之符合基本的设计原则。持续重构应该是团队和个人的工程习惯，而非一次性的行为。 · 简单设计：过度设计带来的复杂性，本身就会成为未来变更的负担（债务）。另一方面，超越当下功能要求的设计无法得到充分的功能验证，会成为“在制品”。简单设计在实现功能、消除重复，以及清晰表达的前提下，力求用最少的元素实现系统。 · 自动单元测试， 测试驱动开发：单元测试是系统健壮性的基石，设计良好的自动化单元测试是系统最有效的防护网，它确保代码发生变更时，原有意图不被破坏。也只有有了单元测试的保护，重构才可能持续安全地进行。测试驱动开发则是产生良好设计的手段，同时它往往能生成最优和最及时的单元测试用例。 · 结对编程：结对编程有机综合了两个程序员的思维能力，更容易产生设计和实现良好的代码。同时，通过持续的代码检查，减少错误引入，并在开发人员之间有效传递了知识，降低了技术和学习“债务”。 以上，我们从响应能力出发，梳理了敏捷软件开发中的主要实践，这些实践并非为敏捷软件开发所专享。其实施，也非一蹴而就，需要以团队整体技术和管理水平的提高作为支撑。否则反而可能会带来新的“在制品”和“债务”，特别是“债务”。比如，引入单元测试自动化是为了减少技术“债务”，但如果单元测试自动化本身设计不良，测试用例过分依赖于实现细节。这样，对实现细节的改变，会影响到测试用例的正确运行，反而使单元测试成为负担，提高变更的成本，降低响应能力。 敏捷的实践之间是相互关联的，成为一个有机系统，才能发挥效益。管理实践之间是相互支持的。例如，离开多功能的团队，开发任务就必须在多个功能团队之间传递，无法做到短迭代开发。 技术实践之间是相互支持的。例如，没有单元测试自动化的保障，持续重构的风险将激增，在操作上变得不现实；有了持续重构保障，维持一个最简单的系统设计，需要时再通过重构，使设计适应新的变化要求，简单设计才更可能得以实施。技术实践和管理实践也是相互支持的。例如，短迭代开发中没有技术实践支持，就会不断积累技术“债务”，产品质量和开发效率不断下降；而，短迭代内全生命周期的反馈，也为各类技术实践的部署提供了便利。 综上，敏捷实践的应用和团队技术水平的提高，相辅相成，在应用中不断总结提高，构建和完善实践体系，加强客户、业务人员和团队的合作，以及团队内部的合作，持续、有效地减少“在制品”，以及技术和学习“债务”，提升组织的整体技术和管理水平，只有这样才能构建可持续的响应能力。