《知行合一： 实现价值驱动的敏捷和精益开发》读后感5

5.1 应对变化的敏捷计划：波浪式的版本规划

 

>> 这个公式就是要求富士通的产品团队，争取以最小的代价为客户实现最大的价值。这也是敏捷的核心价值之一。

 

>> 通过MMF，你是在推销产品愿景，最小功能集是给有远见的客户而不是给所有人的。

 

 

5.2 Scrum迭代中的管理：频繁反馈，及时调整

 

>> Scrum计划包括以下3个层次

 

即发布计划

>> 版本计划

 

>> 版本计划

 

>> 5个会议

 

5个会议/仪式

>> 个会议

 

>> 作为“角色”，我希望完成“活动”，这样可以获取“业务价值”。

 

>> 每日例会的后续会议。

 

>> 敏捷企业应该是学习型企业，好的敏捷团队一定是一个善于学习的团队。

 

 

5.4 Scrum中的风险管理

 

>> 假设为了充分测试5个全职开发人员写的代码并保证进度，我们需要3个全职测试人员，如果团队只有1.5个测试人员，那么测试会拖项目的后腿。

 

同样的问题，项目目标不清晰

>> 检查团队迭代计划时，我们发现迭代计划目标性不强，没有关注实现相对独立、对用户有价值的功能特性。迭代需求列表中所选的用户故事没有清晰的关联性，团队在选取迭代需求时，

 

>> 检查团队迭代计划时，我们发现迭代计划目标性不强，没有关注实现相对独立、对用户有价值的功能特性。迭代需求列表中所选的用户故事没有清晰的关联性，团队在选取迭代需求时，

 

>> 价值交付定义为每轮迭代最重要的度量指标；

 

>> 每次迭代必须有一个主题，大部分用户故事应该是围绕这个主题提出的。

 

>> 应该实现一个MMF。

 

>> 客户同时要求团队遵循一些极限编程的工程实践，这些实践及Scrum流程都已经文档化。目前这个团队正在执行第二年合同的内容，虽然客户有些意见，但团队的努力还是得到了认可。

当时我很少接触过外包类的敏捷开发模式，这让我对这个位于二线城市的小企业有了很大的兴趣。我耐着性子了解了另外3个团队的情况，很显然，这3个团队至少需要18个月的时间才能达到CMMI三级的要求，6个月的时间连过程试点一轮都不够。

针对罗总的期望，我提出了一个简单的方案。

将评估范围限制在他的Scrum团队，我把它称之为“三一”评估：一个客户、一个团队和一个过程。评估不包括其他3个团队。

争取在10个月内完成评估。

请适当增加一些评估预算以支持必要的改进咨询、培训工作。

 

 

第6章 把握好敏捷的度——敏捷工程及质量控制实践

 

>> 如果我们不能把控好敏捷和自律的平衡点，项目的质量有可能会失控。

 

>> 敏捷对质量控制的一大贡献是抓住了质量控制应该关注的点，更加明确了质量是所有人的责任，而不仅仅是测试人员的责任。