用敏捷解决形式主义 CMMI

1. 用敏捷解决形式主义CMMI 张克强 王庆付 http://weibo.com/zhangkeqiang http://www.weibo.com/helloscrum 苏州敏捷之旅

2. 目录 • CMMI简介 • 形式主义CMMI • 敏捷之道 • Q&A 苏州敏捷之旅

3. CMMI简介 • 能力成熟度模型（Capability Maturity Model Integration） • 软件CMM（CMM for Software）：1991年发布 持续优化 已量化管理 已定义 已管理 初始 苏州敏捷之旅

4. 形式主义CMMI 苏州敏捷之旅

5. 形式主义CMMI 苏州敏捷之旅

6. 敏捷之道 • 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 • 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷体系掌控变化。 • 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 • 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 • 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 • 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 • 可工作的软件是进度的首要度量标准。 • 敏捷体系倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 • 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 • 以简洁为本，它是极力减少不必要工作量的艺术。 • 最好的架构、需求和设计出自自组织团队。 • 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 原则不要违背 苏州敏捷之旅

7. 1. 文档+文档 形式主义CMMI Agile • Just enough • 文档不一定是word • 各种工具存储 wiki,Jira, Mantis • 客户需要的文档不能少 • 代码即文档 • 大量的组织过程文档 • 写不完的项目文档 • CMMI需要证据，所以项目必须有大量的文档 • 文档是用来交流信息的 • 为了文档而文档 • 为了评估而文档 苏州敏捷之旅

8. 2. 各种计划 形式主义CMMI Agile • 集成的计划 • 多级计划 • 减少非项目团队成员的干预 • 开发计划 • CM Plan • QA plan • Measurement Plan • 培训计划 • 干系人管理计划 • 沟通计划等等 • 一份集成计划 • 分级计划 • CMMI GP2.2需要的（评估证据） • 各个计划文件相独立 苏州敏捷之旅

9. 3. 形式会议 形式主义CMMI Agile • Value orient • Result orient • Confirmed with Demo • Information radiator • White board • Screen at Gate • Electric white board • Kanban • 会议时间长 • 大部分都是一个人在讲 • 会议记录多份，而且很长 • 会议类型较多 • 会议没有发现问题 5名同行参加了3个小时的评审 • 10000/22 = 455 • 455/8 = 57 • 57 * 15 = 853 (元） • 会议有时间盒（TimeBox） • 会议人人参与 苏州敏捷之旅

10. 4. 都“重要”的需求 形式主义CMMI Agile • 需求列表中的优先级属性全部是“重要” • Product Backlog的优先级序列 • PO对需求优先级负责 • Sprint 计划会上选择Backlog • 都很“重要”就失去了优先级的意义 • 通过迭代这个实践制度化优先级这个属性 苏州敏捷之旅

11. 5. 100页以上的word需求 形式主义CMMI Agile • Requirement Item • User Story • Use Case • Feature point • Searchable • Edit separately • 领导或客户需要需求规格书作为交付物，为需求规格书设计了详尽的word模板，项目组织实际中往往会合并得到超过100页的word文档。然后，召开一个需求里程碑评审会，不超过3小时，然后大家签字通过。 • 你喜欢看100页的文档吗？ • 从文档使用者的角度写文档 苏州敏捷之旅

12. 6. 需求可追溯性 形式主义CMMI Agile • User Story • Acceptance criteria • ATDD / TDD • Test Case track to User Story • 需求矩阵 • 关联设计 • 关联代码 • 关联客户 • 关联测试 • 一份复杂的Excel • 通过可操作的实践固化为制度 苏州敏捷之旅

13. 7. 没有“根”的估算 形式主义CMMI Agile • 扑克计划游戏 • Velocity • Capacity • 项目成员未参与或者根本就不知道 • 估算完成就完成了，后续没有使用 • 估算没有参考，相对粗略 • 60人月 = 6个人 × 10个月 • 人人参与 • 相对估算 苏州敏捷之旅

14. 8. 无用的数据 形式主义CMMI Agile • Just enough • 识别关键指标 • 人工收集数据：用例数， • 代码行，文档页数，缺陷 • 数，工作量 • 数据散落在系统、文件中 • 没人知道这些数据对项目有什么用，怎么用？ • 燃尽图 • 对“Done”的定义 • 持续集成工具自动收集数据 • 状态墙 • 为了数据而数据 • 为了报告而数据 苏州敏捷之旅

15. 8. “惊人相似”的风险缓解措施 形式主义CMMI Agile • 风险缓解在各项敏捷实践中 • 通过Sprint的切割降低交付风险 • 通过每日晨会降低沟通那个风险 • 通过持续集成降低质量风险 • …… • 管理余下的重点风险 • 有不能按时交付的风险，措施都是：加强监控 • 有沟通不及时导致影响进度的风险，措施都是：加强沟通 • 用具体实践，并制度化，有效降低甚至规避了风险 • 风险缓解措施其实什么也没有做 • 风险缓解措施放在哪里解释都行 苏州敏捷之旅

16. 9. 看不见的集成 形式主义CMMI Agile • 持续集成 • 自动Build工具，脚本实现单元测试，代码审查工具，覆盖率审查工具，自动文档生成，自动部署 • 只有一堆集成文档和最后的产品 • F5就算集成了 • 没有独立的集成环境 • 每个Sprint都可以让用户看到可以工作的软件 • 集成环境和开发、测试环境一样 • 集成顺序仅仅写在文档中 • 集成过程和集成标准形同虚设 苏州敏捷之旅

17. 10. 没有用户参与的确认 形式主义CMMI Agile • 现场用户 • Demo • 尽早交付 • 需求需要确认 • 计划需要确认 • 交付物需要确认 • 用户合作 胜过 合同谈判 • 明确PO角色和职责 • 用户参加每个Sprint评审会 • 模拟的用户验收环境 • 模拟的用户视角 • 我们能代表用户 • 客户不是很懂 • 用户没有时间 苏州敏捷之旅

18. 11. 鸡毛蒜皮的质量保证工作 形式主义CMMI Agile • 团队自身回顾 • 敏捷教练指导 • Scrum中 Scrum Master • 项目每个月接受一次QA检查，项目经理为了通过这次QA检查，事先要花不少时间来准备，项目经理认为这是CMMI所要求，虽然没大用，但组织既然要这样搞，那就应付下. • 为团队服务 • 对过程负责 • 但其实这真的没啥用。 苏州敏捷之旅

19. 12. 依赖外来的和尚 形式主义CMMI Agile • 团队回顾 • 值得改进 • 值得保持 • 跨团队分享 • 人人贡献的Wiki • 自组织团队 • 95%以上的改进建议（或叫改进提议）来自于外部咨询、评估或外审。 • 总有一天和尚会离去 • 高昂的团队士气 • 积极的团队氛围 苏州敏捷之旅

20. 其他方面 形式主义CMMI Agile • 此处省去1000字…… • 此处省去500字…… 苏州敏捷之旅

21. 小结 • CMMI简介 • 21年了，Agile 11年 • 形式主义CMMI • 形式主义很害人——“吃力不讨好” • 敏捷之道 • 用敏捷实践解决CMMI中的“顽症” • 通过实施敏捷让整个开发体系有效落地，让整个组织“活”起来 —— 四两拨千斤 • Q&A 敏捷 敏捷 苏州敏捷之旅

22. Q&A http://weibo.com/zhangkeqiang http://www.weibo.com/helloscrum 苏州敏捷之旅

23. 谢谢！ http://weibo.com/zhangkeqiang http://www.weibo.com/helloscrum