“产品级敏捷” 的这条路; 逐步的形成一高效的产品开发生态系统

2015. 7.1, 我在杭州….

这一路走来真的相当的不容易; 这一周多来, 大夥跟著一个 “疯子顾问”, 经历了不停的交流,辩论, 实践, 验证, 深度思考? 终于, 踏上了产品级敏捷的这条路…..

1. 以外部客户的视角, 制订出可使客户对产品有信心的版本节奏; PI (Program Increment) ?
2. 拉通产品的特性负责人, 开发骨干与测试经理, 经由可视化的需求看板与 “加法, 减法” 的协作模式, 识别每一轮 PI 所需完成的开发与集成测试的特性场景? 已使每一轮 PI, 都能以最少的产出, 却能对客户产生最大的影响?
3. 拉通 Product Owner, 开发骨干与测试骨干人员, 以轻量级的 Context Map, 设计每一轮 PI 的架构设计并识别每一轮 PI 架构上的风险? Product Owner 并根据每一轮 PI 架构上的风险, 客观的评估出每一轮 PI 可完成开发与集成测试的 User Story 数量?
4. 拉通开发与测试人员, 经由可视化的 “业务场景树”, 轻量级却精准的设计 UserStory 的业务场景, 业务实体与业务实体的验证纬度? 所以, 经由业务场景树, 开发与测试人员不仅可对 UserStory 的需求达成一致的共识, 更可依照业务实体所形成的关注点, 共同设计各关注点的测试用例;共同评估各关注点发生故障的概率与发生故障时对产品的影响? 最重要的一点便是, 开发与测试人员可根据业务实体的验证纬度, 各关注点发生故障的概率与发生故障时对产品的影响, 决定 User Story 中那些的关注点是只需开发人员自保证质量便可;
   那些的关注点却是需开发与测试人员共同保证质量的? 在这样一个开发与测试人员高度协作的模式下, 将能提升开发人员代码的质量, 同时更能大幅提升测试人员的测试效率与质量?
5. 开发人员依照软件的架构, 将 “业务场景树” 转化为 “实践场景树” ? 实践场景树, 将能确定开发人员在正式开发前, 是否已有一清晰且正确的开发 User Story 的逻辑思路? 开发人员亦能利用实践场景树, 结合适当的设计模式, 设计出可适应变化与易扩展的 User Story 的简单设计?
6. 测试人员将与特性负责人, 开发人员协作, 依照特性端到端的业务场景, 设计 “特性业务场景树”, 并根据特性业务场景树, 设计特性端到端的测试用例?
7. 开发与测试人员在每一轮 PI 即将结束前, 将依照Product Owner 与团队其他成员对其工作上的评比, 提出在下一轮 PI 自我改善的计划?

产品级敏捷经由团队的高度协作与自主, 逐步的形成一高效的产品开发生态系统? 在这生态系统中, 团队成员不仅能高效的完成版本开发, 更重要的是能发挥 “集体的智慧” 做出最佳的决策? 而使每一轮 PI, 都能以最少的产出, 却能对客户产生最大的影响?

版权声明：本文为博主原创文章，未经博主允许不得转载。