CMMI环境下的敏捷实践分享

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