CMMI环境下的敏捷实践分享1

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