04构建之法阅读笔记之一

第六章 敏捷流程

6.1 敏捷的流程

 

①敏捷开发原则：

 

（1）尽早并持续地交付有价值的软件以满足顾客需求

 

（2）敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势

 

（3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短

 

（4）业务人员和开发人员在项目开发过程中应该每天共同工作

 

（5）以有进取心的人为项目核心，充分支持信任他们

 

（6）无论团队内外，面对面的交流始终是最有效的沟通方式

 

（7）可用的软件是衡量项目进展的主要指标

 

（8）敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去

 

（9）只有不断关注技术和设计，才能越来越敏捷

 

（10）保持简明——尽可能简化工作量的技艺

 

（11）只有能自我管理的团队才能创造优秀的架构、需求和设计

 

（12）时时总结如何提高团队效率并付诸行动

 

②敏捷流程概述：找出完成产品需要做的事情→决定当前的冲刺（Sprint）需要解决的事情→冲刺（冲刺期间每天开每日例会）→得到软件的一个增量版本并发布

 

6.3 敏捷的团队

 

自主管理：自己挑选任务、自己提出改进并实施改进

 

自我组织：每个人联合起来对项目负责

 

多功能型：每个人都全面负责，自己搞定规格说明书，和别人沟通，自己搞定测试

 

6.4 敏捷总结

 

在迭代开始时，团队审视摆在他们面前的任务，选择他们认为可以在迭代期间完成的那些任务（Plan）。然后团队独立地尽最大努力完成这些任务（Do）。在迭代结束时，团队给利益关系人展示成果（Check），并对开发流程进行调整（Act/Adjust）。

 

这里有一些实践者的经验教训：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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