近百人的企业云存储的开发团队, 却面临着 2/3 的开发人员, 无法承担复杂度高的需求开发, 而使得产品的开发速度与质量赶不上市场变化上的要求。
2/3 的开发人员, 无法承担复杂度高的需求开发, 主要的原因是: 团队的资深骨干人员, 因只担心版本无法交付, 所以, 在各个版本中, 便将大部分的需求,独自承揽,独自开发, 而使得 2/3 的开发人员,只分配到简单的需求或打杂性的工作。
经过一周极度辛苦的交流与实践 , 产品级敏捷在团队中建立起一讲求个人价值与责任, 团队协作的生态系统:
- 由团队的开发人员自主的认领, 自身在每一版本中所需负责的 User Stories。由最 “新进” 的开发人员开始认领 User Stories; 最 “资深” 的开发人员最后认领 User Stories。如此的作法, 将能激励 “资浅” 的开发人员, 主动的承担与挑战 , 每一版本中具价值的需求, 并使 “资浅” 的开发人员能在最短的时间内, 获得能力上的提升。
- 经由可视化且轻量级的敏捷工程实践; 例如: 上下文地图、 业务场景树、 实现场景树与表格式测试用例, 使团队的架构师、 开发人员、 测试人员均可共同的协作, 对 User Stories 的需求、架构、测试用例进行分析与设计。更重要的是, 团队成员能随时识别出需求中场景遗漏的地方, 业务规则上下文不匹配的地方, User Story 与外部模块 (系统) 间接口的依赖。因而, 可大幅降低缺陷的产生与因接口上的依赖, 所产生在开发与测试上等待的时间。
- 开发与测试人员协作: 开发与测试人员协作, 共同对 User Story需求的理解、分析、设计、测试用例设计, 负起完全的责任。如此, 将能驱使开发与测试人员, 需在最短的时间内, 站在外部使用者 (系统) 的角度, 思考最符合外部使用者 (系统) 行为的业务场景为何? 因而, 不仅可大幅提升产品开发的效率与质量, 更可使产品的易用性大增。
- 开发与测试人员分工: 开发人员将对 User Stories 功能上的质量负起完全的责任; 测试人员则对 User Stories 间, 整合上的功能与非功能上的测试, 负起完全的责任。如此, 将可使测试人员, 有更多的时间, 得以从事 “产品层级”上的质量把控工作。
- 开发与测试人员, 共同所分析、设计的业务场景树, 表格式测用例, 需经 Product Owner 认可; 确认开发与测试人员均已完全理解需求; 开发与测试人员方可进行各自的开发与测试工作。如此, 将可避免开发与测试上因误解需求, 所造成产品开发与效率上严重的浪费。
- 针对团队运作的现况, 设计能真正解决团队问题的敏捷实践; 则团队在产品的开发效率与质量, 方能获得根本上的提升与持续不断的改善。
期待这支产品级敏捷的生力军, 能持续的在敏捷开发的这条路上不断的前进, 而能为人类的 “云” 世界, 做出正面具且有决定性的影响。
