首页 > 代码库 > 第六章 敏捷流程

第六章 敏捷流程

6.1 敏捷的流程

现有的做法 敏捷的做法
流程和工具 个人和交流
完备的文档 可用的软件
为合同谈判 与系统合作
执行原定计划 相应变化

 

 

 

 

     

      敏捷开发的原则:1.尽早并持续地交付有价值的软件以满足顾客需求。

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

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

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

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

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

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

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

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

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

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

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

      敏捷流程概述(在这里剖析Scrum这个方法论):

          第一步:找出完成产品需要做的事情——Product Backlog。

          第二步:决定当前的冲刺需要解决的事情——Sprint Backlog。

          第三步:冲刺。

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

6.2 敏捷流程的问题和解法

6.3 敏捷的团队

      敏捷对团队的要求很简单:自主管理、自我组织、多功能型。

6.4 敏捷总结

      敏捷流程的经验教训:

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

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

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

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

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

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

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

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

6.5 敏捷的问答

      敏捷(Agile)是一种思潮,又或者说是一种价值观,它涵盖了好几种软件开发的方法论(Methodology);这些方法论有事建立在许多行之有效的最佳实践方法(Best Practices)之上的。

第六章 敏捷流程