大型软件产品的敏捷案例 分享

• 分割及组织团队
• 分割及编排计划
• 立即开始并持续改进
• 逐步克服长期挑战

分割及组织团队

tips：

1.把团队组织在一个开放空间中
2.尽可能在多放置白板
3.调转座椅就能开会

分享１：跨职能团队＋特性团队

 跨职能团队：

1. 完成一项功能的设计，开发和测试的过程不需要进行文档化的握手过程
2. 极大的减少了沟通和传递中的噪音和偏差，并且大大降低了沟通成本
3. 群体决策成为可能，使得集体的智慧（Wisdom of the crowds)得以发挥，给了每个成员更大的技术视野

特性团队：

1. 同一团队关注在同一功能模块，在同一时间段大家联合做同一个功能。
2. 成员间通过帮、传、带使领域知识不只是积累在文档中，而且积累在团队中，使得每个人都不是不可替代的。

是否一定要由Senior成员构成的团队才能发挥Scrum的作用?：

1. 不一定。更多的Senior的成员能提升团队的效率，但是团队的最终效率是由团队成员的配合度来决定。
2. Scrum方法中大家高度协作，每个人的主动性被激发起来后，能很好的提升团队的整体作战能力，Junior成员也能很快的从Senior成员那边学到很多东西。
3. 由于同一个团队关注的是相近的功能，采用ＰＰ的方法，能很好的促进学习，并能极大的营造团队的学习气氛。

分享２：做好开发服务是发挥作用的关键

工程基础设施专人专职：

1. 专人负责开发测试环境的维护，持续集成体系的构建和看护
2. 使得每个开发团队不需要分心于基础设施
3. ＰＯ及用户故事团队全程参与，随叫随到：
4. 对需求的澄清随时可以进行
5. 需求人员在开发过程中即参与需求的验证和纠正

专职教练：

 　　旁观者清，需要一个看得清楚，并一直思考的人来持续的发现问题并促进集体思考

专职教练能很好的帮助团队对抗团队惯性（或者叫“组织重力”）

2.分割及编排计划
　　　　1.严格的保证10个工作日的Sprint长度，节假日不例外
　　　　2.如果一个Sprint不能在固定时长内结束，在中间要进行内容的调整，但是不能延长时间
　　　　3.Scrum执行成功的关键是帮助团队找到固定的节奏感

分享３：基于”客户价值“的计划

编排目标，而非编排任务：

1. 先把每一个Subrelease和每一个Sprint的业务目标定下来，根据业务目标来分解用户故事。
2. 永远先做优先级高的事情，优先级低的事情由用户故事团队持续的与客户协商。

及早开始，逐步清晰，及时调整：

1. 让用户故事的细化与开发并行起来，尽早开始开发，为开发工作腾出更多的时间使用Sprint0来解决大的方案和技术风险
2. 在每个Sprint中预留１０％～２０％的时间准备下一个Sprint

不断调整，不停检视：

1. 每个Subrelease结束前一个Sprint重新进行Release planning，进行大的变更管理
2. 每个Sprint review结束后，调整Product backlog的内容及优先级

• 立即开始并持续改进

分享４：改进，改进，再改进

  定义清晰的ＤＯＤ：

1.   DOD是一种Commitment，而不是一种监管手段
2.   Owner of DOD的使命是让团队理解，而不是强迫团队执行
3.   质量来自于团队意识，而不是来自于测试

  让团队自学习：

1.   Sprint不是微型的瀑布，让团队成员自己打配合
2.   尽量多的ＰＰ
3.   允许团队犯错误，帮助团队分析原因

  稳定然后再提高：

1.   Scrum不会加快开发速度，团队配合效率的提高才能提高速度
2.   假设一个Velocity然后不断的较正
3.   尽量确保团队稳定

• 逐步克服长期挑战

  技术债务

1.   慢慢的补齐欠缺的单元测试及自动化
2.   定期的组织重构活动
3.   每个Sprint的review中加入defect review and summarize

  协调敏捷的方法与ＰＭＯ监管

1.   争取公司管理层的认同
2.   将用户故事测算转化成传统PMP的测算值
3.   鼓励PMO参与Sprint review

  打造高效的团队

1.   团队发展的三个层次:forming, storming, performing
2.   给团队适中的压力
3.   组织长效的培训计划，鼓励学习与分享
4.   保持团队稳定