读《构建之法》第六章

  在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。

敏捷开发有12条原则：

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

 

敏捷流程概述：

第一步：找出完成作品需要做的事情——Product Backlog

第二步：决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog

第三部：冲刺（Sprint），

 

敏捷流程的经验教训：

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

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

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

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

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

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

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

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

  总的来说：我们需要敏捷（agile）的开发流程，但是不需要匆忙（rushed）或忙乱（chaotic）的开发流程

转载于:https://www.cnblogs.com/1551338zzj/p/6842590.html