2015. 7.1, 我在杭州….
这一路走来真的是相当的不容易; 这一周多来, 大夥跟著我这个 “疯子顾问”, 经历了不停的交流,辩论, 实践, 验证, 深度思考◦ 终于, 踏上了产品级敏捷的这条路…..
- 以外部客户的视角, 制订出可使客户对产品有信心的版本节奏; PI (Program Increment) ◦
- 拉通产品的特性负责人, 开发骨干与测试经理, 经由可视化的需求看板与 “加法, 减法” 的协作模式, 识别每一轮 PI 所需完成的开发与集成测试的特性场景◦ 已使每一轮 PI, 都能以最少的产出, 却能对客户产生最大的影响◦
- 拉通 Product Owner, 开发骨干与测试骨干人员, 以轻量级的 Context Map, 设计每一轮 PI 的架构设计并识别每一轮 PI 架构上的风险◦ Product Owner 并根据每一轮 PI 架构上的风险, 客观的评估出每一轮 PI 可完成开发与集成测试的 User Story 数量◦
- 拉通开发与测试人员, 经由可视化的 “业务场景树”, 轻量级却精准的设计 UserStory 的业务场景, 业务实体与业务实体的验证纬度◦ 所以, 经由业务场景树, 开发与测试人员不仅可对 UserStory 的需求达成一致的共识, 更可依照业务实体所形成的关注点, 共同设计各关注点的测试用例;共同评估各关注点发生故障的概率与发生故障时对产品的影响◦ 最重要的一点便是, 开发与测试人员可根据业务实体的验证纬度, 各关注点发生故障的概率与发生故障时对产品的影响, 决定 User Story 中那些的关注点是只需开发人员自保证质量便可; 那些的关注点却是需开发与测试人员共同保证质量的◦ 在这样一个开发与测试人员高度协作的模式下, 将能提升开发人员代码的质量, 同时更能大幅提升测试人员的测试效率与质量◦
- 开发人员依照软件的架构, 将 “业务场景树” 转化为 “实践场景树” ◦ 实践场景树, 将能确定开发人员在正式开发前, 是否已有一清晰且正确的开发 User Story 的逻辑思路◦ 开发人员亦能利用实践场景树, 结合适当的设计模式, 设计出可适应变化与易扩展的 User Story 的简单设计◦
- 测试人员将与特性负责人, 开发人员协作, 依照特性端到端的业务场景, 设计 “特性业务场景树”, 并根据特性业务场景树, 设计特性端到端的测试用例◦
- 开发与测试人员在每一轮 PI 即将结束前, 将依照Product Owner 与团队其他成员对其工作上的评比, 提出在下一轮 PI 自我改善的计划◦
产品级敏捷经由团队的高度协作与自主, 逐步的形成一高效的产品开发生态系统◦ 在这生态系统中, 团队成员不仅能高效的完成版本开发, 更重要的是能发挥 “集体的智慧” 做出最佳的决策◦ 而使每一轮 PI, 都能以最少的产出, 却能对客户产生最大的影响◦
