CMMI环境下的敏捷实践分享

CMMICMMICMMICMMI环境下的敏捷实践分享环境下的敏捷实践分享环境下的敏捷实践分享环境下的敏捷实践分享张克强2010-9-292010-10-7}敏捷和CMMI的冲突有哪些？调查？调查？调查？调查？2010-10-7•CMMI下引入敏捷•团队上级领导、项目经理•文档处理•验证和确认•需求可追溯•一个敏捷类生命周期的例子•敏捷下的QA和EPG•其它目录目录目录目录2010-10-7•CMMI中的试行–OPF组织过程焦点•处理改进建议–IPM集成项目管理•项目中的不一样实践-引入敏捷实践方法•敏捷不是洪水猛兽•敏捷带来了改进机会•在CMMI下试验敏捷是容易的–过程改进的环境已经建立CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷11112010-10-7}选择个别项目中试行 项目经理要有热情、知识 领导、EPG、QA要允许 大部分规章可以免遵守 项目团队、EPG、QA一起定义要遵守的规则CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷22222010-10-7}小结项目的敏捷实践 主观和客观结合 决策分析DAR 再试 总结好的做法得到敏捷类的新生命周期模型CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷33332010-10-7}推荐敏捷实践做法 发布相应文件 组织培训 发布相应模板CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷44442010-10-7}持续改进 敏捷本身在发展 敏捷本身很庞杂◦CMMI在发展 团队和组织也在发展CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷55552010-10-7}推荐先期引入的敏捷实践 不超过8周的迭代 用户试用、DEMO展示 简单设计 白板 早会 每日集成、持续集成CMMICMMICMMICMMI下引入敏捷下引入敏捷下引入敏捷下引入敏捷66662010-10-7}CMMIGP2.10GP2.10GP2.10GP2.10GP2.10与上层管理人员进行状态与上层管理人员进行状态与上层管理人员进行状态与上层管理人员进行状态审查审查审查审查 每每每每个过程域都有个过程域都有个过程域都有个过程域都有GP2.10GP2.10GP2.10GP2.10}敏捷需要敏捷需要敏捷需要敏捷需要““““自组织的的的的团队””””}敏捷确实对团队领导提出了要求 敏敏敏敏捷期望团队领导是服务型捷期望团队领导是服务型捷期望团队领导是服务型捷期望团队领导是服务型 而而而而不是指令型不是指令型不是指令型不是指令型团队上级领导团队上级领导团队上级领导团队上级领导11112010-10-7•敏捷中的“屏蔽”–按要求写文档，参加会议，并做出很关注的样子……这样别人看起来你好像是在按照所谓的‘官方流程’在走•作为管理层，需要注意倾听，需要开诚布公，在前期就注意敏捷团队有没有抱怨管理层不合理的要求；发现屏蔽存在时，不能草率的责备敏捷团队，需要与团队一起分析原因，最终的原因有可能就是原有规章不合理的要求。团队上级领导团队上级领导团队上级领导团队上级领导22222010-10-7}作为敏捷团队 如果团队认为需要避免管理层的“干扰”与管理层沟通也没有好结果，不愿意与管理层坦诚沟通 这不会有好结果}沟通团队领导，不一定要说服，只要获取试验的机会 坦诚}状态报告？团队上级领导团队上级领导团队上级领导团队上级领导33332010-10-7}自组织团队建设非一日之功 引入敏捷时，原有项目经理没有必要放权 前期避免“敏捷乌托邦”人人像鲨鱼抢食不考评个人，就能有很好的激励人人努力，自我提升能力，成为多面手}深入理解敏捷和CMMI 避免情绪化的判断 敏捷和CMMI都不简单项目经理项目经理项目经理项目经理11112010-10-7}充分利用已经掌握的项目管理知识◦PMP的历史CMMI◦PMP的历史Agile}大胆尝试，多沟通 摸清各方的底线项目经理项目经理项目经理项目经理22222010-10-7•无用的文档---CMMI的最大不足？•CMMI真的要求有大量的文档吗？–RD需求开发REQM需求管理–TS技术方案–VER验证VAL确认•文档一定要用Word写吗？–Wiki–Bugzilla,mantis,vsts–IBMRTC文档处理文档处理文档处理文档处理11112010-10-7•JustEnough文档的2种价值：–帮助后续开发维护•通过文档，只要让明天加入这个团队的新人了解所要知道的内容就行了–如果有人明天离开，怎么办？•通过文档，可以处理当前项目结束后的维护，或者是后续跟进项目–客户需要的文档–应付内部检查算不算有价值？文档处理文档处理文档处理文档处理22222010-10-7}需求文档，比如userstory,usecase,SRS 利用工具，比如Mantis,VSTS,RTC,贴纸状态流转自动历史记录【导出成word】}JustEnough的规则 只写有用的东西•50页以上的Word文档必然是需求跟踪的噩梦}需求评审利用生成的文档，仅做展现文档处理文档处理文档处理文档处理33332010-10-7}设计文档 关注于架构4页之内 简单设计设计文档的价值随着规模增加其边际效应衰减，达到临界点后，价值反而减少Word格式设计文档在10页以后的价值趋向于0，30页以后的基本是累赘}例外，如果设计工具具备可用的代码正反向功能文档处理文档处理文档处理文档处理44442010-10-7}测试文档}用户文档---交付物}宣传文档---交付物文档处理文档处理文档处理文档处理55552010-10-7}关于“补文档”---既然没有文档的情况下，软件都开发出来了，为什么还需要补文档？}如果原因是“所补的文档是用户使用手册，用户在使用中是需要的”}如果原因是“所补的文档是需求规格说明书和设计书，没有这个，XXX部不让结题”，这个看起来就没有价值，从流程上取消文档环节也不妨碍软件开发。}如果原因是“合同规定了有这些文档，不写，拿不到尾款”，这个没啥说的，问题是下次合同时要么取消这个文档条款，要么按合同要求写文档。 设计文档可以利用工具从代码反向生成。文档处理文档处理文档处理文档处理55552010-10-7}如果原因是“所补的文档是需求说明，没有这个就没法对应测试用例，测试不能保证完整性”，软件已经开发出来了，已经可以运行了，也有使用说明，那么测试用例已经可以设计，测试已经可以开展了。测试用例没有必要一定对应需求的文字了。运行的软件+使用说明本身可以理解为需求的一种表达形式。}如果“我们后续修复缺陷，都是直接查代码，从来不看老需求和老设计”，那么文档的作用几乎没有了。}如果“参加CMMI评估，需要补某某文档”?关于关于关于关于““““补文档补文档补文档补文档””””22222010-10-7}CMMIREQM有需求可追溯的要求 建立原始需求（backlog）–usecase–testcase–bug的双向关联 建立UserFeedback与原始需求或bug的双向关联}代码、设计与需求的双向关联？◦JustEnough需求可追溯需求可追溯需求可追溯需求可追溯2010-10-7}CMMI多处要求达成承诺、达成一致的理解等等，有验证和确认过程域}敏捷中对应确认的实践有： 交付 反馈◦DEMO展示会◦SCRUM的计划会议◦【现场客户】确认确认确认确认2010-10-7}敏捷中对应验证的实践有： 持续集成或每日集成◦TDD 结对}继续开展同行评审 代码同行评审检查表？验证验证验证验证2010-10-7发布包K-1发布包K交付包n-2项目结束交付包n-1交付包0项目起始交付包n敏捷类生命周期的一个例子敏捷类生命周期的一个例子敏捷类生命周期的一个例子敏捷类生命周期的一个例子总体生命周期流程图2010-10-7}交付包为处理限定范围的需求或/和缺陷的一组工作产品和相关的活动，英文为DeliverablePackage。典型的交付包比如有：针对一个VIP用户新需求的解决；又如：针对三个缺陷的解决。}交付包的信息记录在交付包说明书上，其载体可以是卡片，可以是电子文档，可以是Sharepoint的一条记录，要求在团队内部共享、交流方便。}交付包对等于Scrum中的Sprint，敏捷中的迭代，交付包的工期一般是3周到6周，一般是4周。交付包交付包交付包交付包2010-10-7}交付包是可以交付的。交付包是迭代式开发的，新的交付包是在原有的基础上进行，交付包完成后，得到可以交付的软件。}交付包的属性有： 工期 工作量 交付包规模-用例点 缺陷交付包交付包交付包交付包----续续续续2010-10-7}发布包为1个或多个交付包组成的}发布包的工作产品是正式发布。}一般的2~4个交付包组成一个发布包，发布包的预计结束时间需要考虑对外的发布要求发布包发布包发布包发布包2010-10-7}选择交付包需求}评审交付包说明书}开发交付包}基线测试（可选）}展示或交付}回顾交付包交付包的交付包的交付包的交付包的主主主主流程流程流程流程2010-10-7}项目组会同需求干系人在原始需求列表挑选出当前交付包需要完成的需求以及要修复的缺陷。}项目组开展简要的用例分析，将用例分为简单、普通、复杂三类，分别对应为5、10、15个用例点。这样可以得到这些需求总的用例点数量。结合项目历史数据，估算完成这么多用例点所需要的工作量。}根据交付包的工期和安排的开发人员情况，可以估算本交付包可以提供的工作量。}匹配这两个工作量情况，采取必要的调整，两者的差应当控制在一定范围之内，以保证协调的安排，不至于出现无法完成的情况或者交付包后期无事可做的情况。}以上活动须有项目组全体共同参与。选择交付包需求选择交付包需求选择交付包需求选择交付包需求2010-10-7}项目组书写交付包说明书，必须说明如下内容：◦a)主要处理的需求、缺陷的范围◦b)交付包起止时间◦c)团队成员初步分工◦d)规模估算◦e)工作量估算◦f)交付方式}交付包说明书要求进行正式评审，评审会议时间不超过1.5小时。评审时间不迟于交付包开始后第5天。评审交付包说明书评审交付包说明书评审交付包说明书评审交付包说明书2010-10-7}TDD}每日集成编译+静态代码检查+单元测试}测试保护开发 在功能代码实现后，加上界面自动化测试}每日测试（可选）开发交付包开发交付包开发交付包开发交付包2010-10-7}独立测试组}黑盒测试 自动化 手工}发布包的最后一个交付包必须安排基线测试基线测试（可选）基线测试（可选）基线测试（可选）基线测试（可选）2010-10-7}展示会}交付}用户或用户代表必须参加展示展示展示展示或交付或交付或交付或交付2010-10-7}回顾所得要成文 注重团队之间的经验分享}统计交付包实际的 工期 工作量 规模-用例点 缺陷回顾交付包回顾交付包回顾交付包回顾交付包2010-10-7}每日会议}交付包燃尽图 利用“用例”状态所代表的挣值}白板跟踪}代码100%同行评审 结对被认为是同行评审的一种形式}总体燃尽图}交付包过程能力支持工作支持工作支持工作支持工作-1-1-1-12010-10-7}原始需求 状态管理◦100%收集}用户反馈管理 与用户共享 关联原始需求和缺陷 状态管理支持工作支持工作支持工作支持工作-2-2-2-22010-10-7}关注于Agile的流程执行，是否符合Agile的要求，更重要的是给团队于必要的指导；而不必再拿着原有的Checklist来检查}关注于团队的决策结果，团队后续的实践是否符合既定的团队决策}促进多个团队的有效实践能够横向交流，将单个团队的经验分享到多个团队}分析原有规程，识别哪些在Agile下是不必遵守，哪些还是要遵守，如果还有EPG，那么这个过程要EPG参与QA-1QA-1QA-1QA-12010-10-7}发现问题，不再是马上记录QA问题，通过先期与管理层和项目团队协商，识别哪些类重要的QA问题需要记录，哪些类问题如果不解决的话，还是要提升到管理层，一般的问题就