当团队所有的开发人员都能按照 User Story 所估算的人天交付时, 是不是就能保证版本交付的质量?

2015.7.24, 深圳, Ken Fang

当团队所有的开发人员都能按照 User Story 所估算的人天交付时, 是不是就能保证版本交付的质量?

答案有时是否定的; 甚至版本交付的质量有时还会越来越糟, 每况愈下。

为何?

因为….

1. 开发人员只是将能在 User Story 所估算的人天内能提交代码, 当成是自身的唯一的工作。所以, 普遍常见的情况便是：一个 User Story 估算需 8 人天, 开发人员往往是先东晃晃, 西玩玩个 6, 7 天, 等到最后一刻, 再提交代码, 应付了事。

2. 团队的 Team Backlog 往往看不到 “技术债务” 与 “自我学习” 的 working items; Team Backlog 的管理只看得到各方的扯皮, 却看不到一丝的专业。

所以, 别再只是按照敏捷的教科书, 将 User Story 所估算的人天当成是 “绝对值”。 这样的作法至多只是使开发人员在毫无目标的情况下, 做到时间管理, 准时提交代码; 却往往是提交一堆问题单的代码。

开发人员与测试人员能自主的协作和使开发人员做好 "目标管理", 而不是时间管理, 才能使开发人员, 开发的效率与提交代码的质量获得明显的提升：

       I.   经由开发与测试人员自主的协作, 运用 Story 场景树明确定义出 User Story 完成的标准。

       II.  开发人员经由 Story 场景树明确定义出自身每日需完成的 "目标" 为何?

       III. 经由开发与测试人员自主的协作, 由测试人员决定开发人员每日开发的状态 (进度) 为何?

部门的领导不要再吝啬于给团队成员解决技术债务与自我学习的时间; 当团队成员有时间去解决技术债务且自我的能力能不断的提升时, 则最终反馈在产品开发的效率与产品质量上的 “价值”, 将会是无穷无尽的, 将会是无限的。