【BOOK：敏捷开发修炼之道】ch4 交付用户想要的软件

 

让用户做决定

用户参与开发

开发者要做出判断：哪些是自己决定不了的，应该让企业主做决定。不需要自己给业务上的关键问题做决定。

在与客户进行问题讨论时，准备几种可选择的方案。从业务角度而不是技术角度，介绍方案的优缺点，及潜在的成本和利益。和他们讨论每个可选的方案对时间和预算的影响，以及如何权衡。让客户了解一切之后再做决定。当客户做了决定之后，再进行其他的需求要求时，可以公正谈判成本和时间。

Tips：

记录客户做出的决定，并注明原因。

不要问过于具体和没有价值的问题。但不要随意假设某一问题没有价值。

判断问题是否有价值：对于业务是否有影响。

业务负责人如果回答不知道，可能是他们没想到那么远，可能是他们需要看到运行的实物才能评估。

让设计指导而不是操作开发

好的设计应该是正确的，而不是精确的。

敏捷方法，建议在开发早期就开始编码。但也要先进行设计，例如画关键工作图，花时间思考讨论不同选择的缺陷和益处，以及如何权衡。一是无法把握确切的需求，二是对需求的理解会不断发展变化。

前期的设计是战略，在没有深入理解需求的时候，进行总体战略的描述，不涉及细节。

后期的设计是战术，在项目开发的时候再具体的展开。战术设计使用CRC（类名，职责：应该做什么，协作者：要完成工作需要和其他什么对象一起工作）卡片法。

判断设计是否是一个好的设计：如果需求有了小的变化，容易实现，那么是好的。如果导致了一大批基础代码的破坏，那么此设计需要改进。

合理地使用技术

新技术应该像新的工具，可以帮助你更好的工作，而不是成为你的工作。

首先决定什么是你需要的，然后为这些具体问题评估技术。对于任何要使用的技术，多问一些挑剔的问题，并真实地做出回答。

技术方案评估需要考虑：

1. 是否真正能解决你的问题。清晰了解技术的功能，不要道听途说技术的功能，如果需要，先做一个小的原型。
2. 是否会被套牢。是否是开放技术或者专利技术，如果开放，开放到什么程度。当更换技术时，是否会产生致命打击。
3. 考虑维护成本。

Tips：

不要开发能够下载到的东西。不要重复造轮子。

写的代码越少，需要维护的东西就越少。

保持可以发布

已经提交的代码应该随时可以行动。不要让系统不可以发布，又不可以撤销。

防止提交破坏系统的代码，可以：

1. 在本地运行测试。本地编译通过，单元测试通过，其他系统测试通过。
2. 检出最新的代码。先从git/svn中拉取最新的代码，再编译和运行，查看是否出现冲突。
3. 提交代码。

使用持续集成系统，可以自动集成并报告集成结果。

Tips：

如果不得不让系统长期不可以发布，那么就做一个（代码和架构的）分支版本。

提早集成，频繁集成

早期进行集成的时候，可以看到子系统之间的交互和影响，就可以估算他们之间通信和共享的信息数据。

对于集成次数：

如果大部分时间在集成而不是写代码，那么集成次数太多。

如果大部分时间在解决集成带来的问题，那么集成次数太少。

提早实现自动化部署

使用部署系统安装你的应用。而不是手工安装应用。

安装过程应该包括，检查软硬件依赖关系。

质量保证团队，应该既可以测试应用，又可以测试安装过程。确保他们能提前告诉你运行的软件版本，避免出现混乱。

使用演示获得频繁反馈

例如每次迭代结束，就与客户会晤，并演示已经完成的新功能。积极获得他们的反馈。

Tips：

维护项目术语表，确保沟通时的双方-程序员和业务员/客户-在讨论同一件事。

使用跟踪系统来系统地记录反馈：修正，建议，变更要求，功能增强，bug修复等。

项目开发的过程：使用短迭代，增量发布

确保产品可用且不可缺少的核心功能，不要想象华而不实的用户界面，放在生产环境中，尽早给用户使用。

1. 迭代：在小且重复的周期内完成一系列开发任务：分析，设计，实现，测试，获得反馈。
2. 增量开发---发布带有最小却可用功能块的产品。每个增量开发中，使用1～4周左右迭代周期。增量的发布必须可用。
3. 嵌套敏捷开发周期：【每日多次：本地构建，提交代码】--【1-4周：迭代，演示活动】--【1-6月：增量，发布】
4. 迭代时间选择：
   1. 如果发布的功能背离了用户需求，那么多半是因为迭代时间太长。
   2. 如果每次迭代的时间都不够用，要么任务太大，要么是迭代时间太短
   3. 迭代不一定要紧跟下一次迭代，中间可以根据需要增加维护阶段等

敏捷团队的难点：固定价格的评估

由于工作方式是持续、迭代和增量，要提前知道需要花费的时间和成本是不符合实际的。

可以尝试

1. 主动提议先构建系统最初的、小的和有用的部分。第一次交付的时间不多于6-8周。解释给客户，不是完全剋发，而是进行一次足够用户使用的交付。
2. 第一次迭代结束时客户有两个选择：可以选择一些新的功能，进入下一个迭代，或者取消合同，仅支付第一个迭代的几周费用，他们要么把现在的成果扔掉，要么找其他团队来完成它。
3. 如果 客户选择进一步迭代，此时的迭代工作是可以较好的预测。在下一个迭代结束的时候，客户依然具有选择权。

对于客户来讲，优点是，项目不可能会死亡。他们可以很早的看到项目的进度或者不足。可以控制项目，随时停止项目，可以控制项目先完成哪些功能，可以精确知道需要花费的资金。

敏捷并不意味着“开始编码，我们最终知道何时可以完成”。你需要根据当前的知识和猜想，做一个大致的评估，解释如何才能达到这个目标，并给出误差范围。