您的位置:首页 > 其它

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

2011-09-17 23:53 155 查看
[b]分割及组织团队[/b]

[b]分割及编排计划[/b]

[b]立即开始并持续改进[/b]

[b]逐步克服长期挑战[/b]

[b]分割及组织团队[/b]

tips:

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

分享1:跨职能团队+特性团队

跨职能团队:

完成一项功能的设计,开发和测试的过程不需要进行文档化的握手过程

极大的减少了沟通和传递中的噪音和偏差,并且大大降低了沟通成本

群体决策成为可能,使得集体的智慧(Wisdom of the crowds)得以发挥,给了每个成员更大的技术视野

特性团队:

同一团队关注在同一功能模块,在同一时间段大家联合做同一个功能。

成员间通过帮、传、带使领域知识不只是积累在文档中,而且积累在团队中,使得每个人都不是不可替代的。

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

不一定。更多的Senior的成员能提升团队的效率,但是团队的最终效率是由团队成员的配合度来决定。

Scrum方法中大家高度协作,每个人的主动性被激发起来后,能很好的提升团队的整体作战能力,Junior成员也能很快的从Senior成员那边学到很多东西。

由于同一个团队关注的是相近的功能,采用PP的方法,能很好的促进学习,并能极大的营造团队的学习气氛。

分享2:做好开发服务是发挥作用的关键

工程基础设施专人专职:

专人负责开发测试环境的维护,持续集成体系的构建和看护

使得每个开发团队不需要分心于基础设施

PO及用户故事团队全程参与,随叫随到:

对需求的澄清随时可以进行

需求人员在开发过程中即参与需求的验证和纠正

专职教练:
  旁观者清,需要一个看得清楚,并一直思考的人来持续的发现问题并促进集体思考
专职教练能很好的帮助团队对抗团队惯性(或者叫“组织重力”)

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

分享3:基于”客户价值“的计划

编排目标,而非编排任务:

先把每一个Subrelease和每一个Sprint的业务目标定下来,根据业务目标来分解用户故事。

永远先做优先级高的事情,优先级低的事情由用户故事团队持续的与客户协商。

及早开始,逐步清晰,及时调整:

让用户故事的细化与开发并行起来,尽早开始开发,为开发工作腾出更多的时间使用Sprint0来解决大的方案和技术风险

在每个Sprint中预留10%~20%的时间准备下一个Sprint

不断调整,不停检视:

每个Subrelease结束前一个Sprint重新进行Release planning,进行大的变更管理

每个Sprint review结束后,调整Product backlog的内容及优先级

[b]立即开始并持续改进[/b]

分享4:改进,改进,再改进

定义清晰的DOD:

DOD是一种Commitment,而不是一种监管手段

Owner of DOD的使命是让团队理解,而不是强迫团队执行

质量来自于团队意识,而不是来自于测试

让团队自学习:

Sprint不是微型的瀑布,让团队成员自己打配合

尽量多的PP

允许团队犯错误,帮助团队分析原因

稳定然后再提高:

Scrum不会加快开发速度,团队配合效率的提高才能提高速度

假设一个Velocity然后不断的较正

尽量确保团队稳定

逐步克服长期挑战

技术债务

慢慢的补齐欠缺的单元测试及自动化

定期的组织重构活动

每个Sprint的review中加入defect review and summarize

协调敏捷的方法与PMO监管

争取公司管理层的认同

将用户故事测算转化成传统PMP的测算值

鼓励PMO参与Sprint review

打造高效的团队

团队发展的三个层次:forming, storming, performing

给团队适中的压力

组织长效的培训计划,鼓励学习与分享

保持团队稳定
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: