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

2015. 7.1, 我在杭州….

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

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, 都能以最少的产出, 却能对客户产生最大的影响◦