首页 > 代码库 > 《构建之法》学习(6)——敏捷流程

《构建之法》学习(6)——敏捷流程

《构建之法》学习(6)——敏捷流程

 

1.敏捷的流程

 

     “敏捷流程”是一系列价值观和方法的集合。

 

1.1敏捷开发原则

 

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

     敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势

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

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

     以有进取心的人为项目核心,充分支持信任他们

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

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

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

     只有不断关注技术和设计,才能越来越敏捷

     保持简明——尽可能简化工作量的技艺——极为重要

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

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

 

1.2敏捷流程概述

 

     找出完成产品需要做的事情——Product Backlog

     决定当前的冲刺需要解决的事情——Sprint Backlog:团队成员能主导任务的估计和分配,他们的能动性得到较大的发挥

     冲刺:这一措施较好地平衡了“交流”和“集中注意力”的矛盾

     得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进

 

2.敏捷流程的解法

 

         燃尽图

         以时间为度量的燃尽图更有效果

         实际剩余时间:每个团队成员所有任务的剩余时间的总和

         预估剩余时间:根据每个人每天的理论进度推算的剩余时间

         实际花费时间:实际花费的时间

 

3.敏捷的团队

 

  自主管理

  自我组织

  多功能型

 

4.敏捷总结

 

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

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

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

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

  创业公司的团队其实经常是运行在Scrum的模式中。

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

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

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

 

  敏捷不是万能的。敏捷的方法能帮助你更早地知道你是否如期完成任务,仅此而已。敏捷的方法能帮你尽快让用户看到项目的部分价值。

 

《构建之法》学习(6)——敏捷流程