第 11 章 遭遇风暴 —— 陷入谷底，绝处逢生
1、PMO和研发团队一起解读每一份需求文档。
2、PMO把需求文档拆成用户故事并排序，然后研发团队开始实际的交付，在交付的过程中，研发团队和PMO阐述具体需求细节和验收条件。
3、估算不可能精确的，不应该在追求所谓的估算‘精确性’上花太多时间，那是没有太多意义的。
4、设计一份简单的报价单，可以根据需求里面需要的组件数量来计算时间和成本。当然，它不是一个所谓精确的估算，但可以让我们节约大量时间。
5、报价单。
6、正式因为项目重要，所以才要一起定义MVP，让业务部门可以在IT投入最小的情况下开展业务，这才是降低风险的办法。
7、很多时候，计划并不是为了执行，而是提前做好各种情况的预案，集结资源，以应对将来可能的各种变化。
8、业务部门作为甲方是需要确定性的，我们不能只是告诉他们软件开发是个不确定的过程，尽管这是事实，但他们不会接受。所以我们需要技巧和策略来管理他们的预期。
9、用户故事类型的JIRA Issue模板内容：
（以下关键信息都能被记录在Issue中，成为详尽的交付文档）
· 需求描述（原始的需求描述）；
· 确认理解（复述对需求的理解并要求需求提出方确认理解，适用于所有的任务分配）；
· 问为什么（询问需求提出者为什么需要这个需求和为什么现在就需要）；
· 验收条件（可作为验收测试用例的具体例子，即实例化需求，适用于任何事情）；
· 详细设计与实现（记录满足该需求的具体设计以及实现）；
· 集成测试结果（包括CI[持续集成]的结果）；
· 用户验收测试（用户验收测试过程与测试结果）；
· 上线备忘（有些用户故事的上线所需要的一些额外步骤）。
10、行为驱动开发（BDD）
利用自动化测试框架Cucumber[插图]，通过代码来执行这些实例，从而使这些文档可执行并内化到代码库中，以实现验收测试自动化，而且可以纳入到持续集成里。
Cucumber的文档则与业务人员确定了对系统的期望行为，这个过程也叫行为驱动开发（Behavior DrivenDevelopment，BDD）。
Cucumber可以把左边的业务人员能看懂的行为测试用例与右边的测试执行代码“粘合”起来。
11、立即进行具体的可行性研究和成本估算。
12、采用演进式的设计方法和微服务的架构。
13、微服务架构
就是把整个应用按照业务拆分成独立的应用，它有以下的特点：
1）每个应用可独立开发、部署和扩容，甚至有独立的数据库；
2）每个应用的职责单一、松耦合，和其他应用通过远程接口调用，没有代码依赖；
3）基于以上原因，每个应用的开发、查错和变更速度快，它能更快地响应业务需求，提高敏捷性；
4）由于采取去中心化结构，每个应用可以采取完全不同的技术栈，包括不同的开发语言，在技术选型上自由度大。
14、微服务架构降低了每个微服务应用的复杂性，却增加了整个架构的复杂性。其实只要业务是复杂的，系统的整体复杂度就不会降低，只是体现在不同的层面上而已。微服务架构大大增加了集成测试、部署、监控等方面的复杂性。
15、敏捷使用的估算单位是故事点，它是一个和复杂度或规模有关的相对数，我们希望它是一个更被大家认可的常量，而不是一个变量。
16、用户故事的复杂度或规模，是一个相对时间更稳定的常量。而且，故事点是一个相对数，不是一个绝对数。
17、扑克牌游戏
在估算会议上，团队的每个成员手上都有一副扑克牌，每副扑克牌包含一个不同的数字，建议使用斐波纳契数列0，1，1，2，3，5，8，13，……，或者是较简单的T-Shirt尺码号XS，S，M，L，XL，……，对应的故事点分别为1，2，4，6，10，……。当大家都消化完一个用户故事时，同时通过出牌的方式来展示每个人的估算结果。给出最高和最低估算的两人要解释和辩论。最后团队得出一个大家都认同的估算值。
参与者彼此之间必须互相独立，在给出自己的答案前不能互相沟通。保持群体中每一个个体的独立性，是群体智慧发挥作用的重要前提。
18、敏捷估算和计划
需要知道团队的交付速度才能知道时间，这就需要测速。
敏捷是迭代式开发，可以通过观察团队在头一、两个迭代中可以实际交付多少个故事点来预测团队的交付速率，从而计算完成所有故事点需要多少个迭代。
在Scrum里，迭代的周期是固定的，这也意味着知道有多少个迭代便知道需要多长时间。要注意，这里观察的是团队的交付速率，不是个人的，因为团队的交付速度相对稳定。
19、燃尽图（burn down chart）
是在项目完成之前，对需要完成的工作的一种可视化表示。
燃尽图有一个Y轴（故事点）和X轴（时间）。
理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。
燃尽图向项目组成员提供了项目进展的一个公共视图。在迭代进行过程中，通过燃尽图来持续观察团队的交付速率是在提升还是下降，从而做出及时调整。
20、采用‘小步推进、快速行动’的策略
从最简单的开始，验证想法，输出模板方法。有了好的基础和模板，后续的开发其他工程师可以依葫芦画瓢。
21、时间盒
22、接受挑战，能更多地参与实战，是强化顾问能力的大好机会。
23、契约测试
所谓的契约测试是基于消费者驱动契约测试的理念的。
API之间的集成测试，涉及彼此独立的不同系统和依赖，相当复杂和昂贵，会大大拖慢交付进度。
API存在提供者和消费者两个角色。提供API的一方称为提供者，调用API的一方称为消费者。
在开发时，双方根据消费者的验收条件拟定一份契约，契约放在一个双方都可以访问的公共区域中，双方通过运行这份契约来测试彼此是否满足要求。这个手段可以使双方的开发过程解耦，解除测试的依赖关系，而且实现像单元测试那样得快速和稳定。
在微服务架构下，应用之间都是通过Restful API互相调用，契约测试解决了微服务集成测试难的问题。
本章知识点小结：
· 实例化需求；
· 行为驱动开发（BDD）；
· 微服务架构；
· 敏捷估算和计划；
· Scrum燃尽图；
· 契约测试。
