《构建之法》阅读笔记4

 第6章 敏捷流程 阅读笔记

---

 敏捷的流程

       敏捷开发原则：
       1. 尽早并持续地交付有价值的软件以满足顾客需求
       2. 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
       3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
       4. 业务人员和开发人员在项目开发过程中应该每天共同工作
       5. 以有进取心的人为项目核心，充分支持信任他们
       6. 无论团队内外，面对面的交流始终是最有效的沟通方式
       7. 可用的软件是衡量项目进展的主要指标
       8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
       9. 只有不断关注技术和设计，才能越来越敏捷
       10. 保持简明—尽可能简化工作量的技艺—极为重要
       11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
       12. 时时总结如何提高团队效率，并付诸行动

       （每日例会、燃尽图、看板图）

---

敏捷流程的问题和解法

        以时间为度量的燃尽图更有效果。下面是一个实际项目的燃尽图，有三个每天跟踪的时间值

       • 实际剩余时间（Remaining Hour）：每个团队成员所有任务的剩余时间的总和。

       • 预估剩余时间（Projected Remaining Hour）：根据每个人每天的理论进度推算的剩余时间。

       • 实际花费时间（Completed Hour）：实际花费的时间。

---

 敏捷的团队

        假设一个团队做得还不错，现在要变成敏捷流程，那团队要做下面的改变：

       1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。

       2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。

       3. 多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

       如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要多次Sprint才能让Scrum走上正轨。换句话说，如果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么用不用Scrum都能写好软件！

---

 敏捷流程的经验教训

       1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。

       2. Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。

       3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到明处。这有好处，也有风险。

       4. 在复杂的项目里，要让一线团队成员做决定。

       5. 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫论证自己到底有多么Scrum）。

       6. 在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。

       7. 不要和管理层谈“流程”，他们只关心“结果”。

       8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答案，Scrum的创始人也承认这一点。