专注于完成用户故事理念的实践

初中的时候，每天放学第一件事情就是流窜到学校附近的街机房，买上2,3个游戏币，操练几把街头霸王。街头霸王里，我最喜欢用的，就是KEN，江湖人称红疯子，而红疯子的招式里，我最喜欢用的，当然是这招嚎尤根了。

嚎尤根这招的特点就是，集中全身的力量在一点，向上打击敌人。这一式要讲的，是敏捷项目里专注于完成用户故事理念的实践。

之前在第五式 答应我，往这儿打 里也简单介绍过专注这个价值观在敏捷实践中是怎么体现的。同学们一定听到过 Stop Starting, Start Finishing这句话，我不清楚这句话的原始出处在哪里，我是在Henrik Kniberg的《精益开发实战》这本书里第一次看到的。这本书实际上讲的是KANBAN方法在软件开发领域中的实践，而KANBAN是精益体系里延伸出来的一种方法，它是2004年David.J.Anderson在丰田的TPS（Toyota Production System），高德拉特的TOC（Theory of Constraint）基础上发明出来的一种适用于软件开发的理论和方法。

在各个群里，经常看到有些老法师就敏捷，精益，SCRUM，KANBAN这些理论方法的优缺点，适用性，理论基础来回的争论，或许大家各有各的立场，各有各的观点，这些争论对我而言就是看着神仙打架，没有实际的意义。而对于一个企业来说，只需要关心这些方法在自己环境中的适用性就可以了，完全不必去纠结我们到底用敏捷，还是用精益，到底是用SCRUM，还是用KANAN。

Scrum的3,3,5,5，我们非得全都用么？我们只用了其中的product backlog，daily standup和retrospective，行不行？不是纯的Scrum就不纯好了，难不成Scrum alliance还能起诉企业用了不纯的Scrum么？Scrum和KANBAN难道就不能同时用么？我们用SCRUM 的sprint概念来管理迭代，用KANBAN来管理sprint内的价值流动，行不行？我们才不管这些方法是属于哪个门派，哪个体系，哪个领域，只要对企业有价值的，我们就会用，不合适的，我们就放在一边，就这么简单。

如果我们审视敏捷和精益，Scrum和KANBAN背后的核心观念，几乎是一样的，价值导向，快速反馈，持续改进，杜绝浪费，如果说敏捷体系是葵花宝典，那精益就是辟邪剑法，反正都得自宫了才能练。

抱歉，又扯远了。现在再来看一下Stop Starting, Start Finishing这句话，中文翻译是：聚焦完成，停止开始（暂缓开始）。 但是我认为，停止开始或者暂缓开始并不是很恰当，用“谨慎开始”或许能更符合企业的实际状况。我们不必非要按照字面来翻译这句话，理解它真正的含义，完全可以用更适合我们情况的语言来替代。

接下来，我们来看一看，具体我们是怎么实践专注这个价值观的。来看一下这样一块板：

（图例中的这块板的布局，出于更方便的介绍这一式内容的考虑，我做了简化，并不是我们真正使用的板，而下面的规则，在这里也稍微做过微调，但不会有影响）

这块板呈现了我们最基本的用户故事流动的方向和规则，我们在这个板上设立了这样几条规则：

  1. 用户故事在每一列中按照优先级顺序从上向下排列

  2. 测试环节测出有BUG的用户故事，放到Bug fix列的最下方

  3. Bug fix列中修复完的BUG，放到测试列的最上方

  4. 你猜？

请同学们思考一下，如果你们的项目也有这样一块板，作为敏捷教练，你会引导你的团队成员怎样去投入他们的时间呢？有这样几个选项：

A. 尽可能的控制投入同一个用户故事的开发人员数量，提高开发并行度，保证每个人都有活干

B. 每一列都放入指定的人，各司其职，明确分工

C. 我有别的想法

在我们的实践中，我们选择了C，因为A和B都不符合“聚焦完成”的理念。基于聚焦完成的理念，我们的策略是，尽可能向右上角投入资源，直到投入了资源也无法加快完成。所以我把这一式命名为“嚎尤根~~~”，团队需要向上发力。

为什么这样做就是聚焦完成了呢？道理很简单，因为越往上的用户故事优先级越高，当然要得到优先处理，而越靠右的用户故事，越接近完成，只有完成的故事才有价值。10个完成了90%的用户故事加在一起的价值是0，而1个100%完成的用户故事就已经具备了价值。我们不希望接近完成的用户故事还留一个小尾巴，所以要尽快的解决它，然后聚焦完成下一个用户故事。

现在，同学们想出了上面的第四条规则是什么了么？这条规则是这样的：

4. 当开发人员同时面对Bug fix和新故事开发的工作的时候，首先处理Bug fix。

原因是Bug fix比起新用户故事开发的工作，更靠右，更接近完成，当然应该优先得到处理。

最后聊一下基于聚焦完成这个理念，又延伸出来的思考。同学们应该能够理解，如果我们采用敏捷的方法来交付软件项目，往往最大的瓶颈会出现在测试和Bug fix环节。一个用户故事，真正写代码的时间只占了很小的比例，联调可能会占据比较大的比例，剩下的全都是测试，Bug 沟通，分析，诊断，解决，和再验证这些工作，工作量占比非常高，所以提高测试环节的效率可以大大提高整个项目的交付效率。那怎么样能提高测试环节的效率呢？方法大家也知道：

• 质量内建，加强单元测试，减少BUG数量，这是最有效的提高测试环节效率的办法；

• 提高BUG诊断和修复的效率，这就要求自动化测试工具，在测试报告中直接提供足够多的线索让开发人员可以快速诊断和分析BUG的原因；

• 提高测试本身的效率，这也是可以通过自动化测试的工具来解决的问题，让原来繁复的手工操作让电脑来替代；

所以没有工程上的自动化，一个软件项目到后期是很难敏捷下去的，而工程自动化绝不是仅仅是引入一套工具链那么简单，没有扎实的面向对象设计与开发的基本功，单元测试的功效就会大打折扣，单元测试的功效不到位，自动化工具链能起到的作用就很有限。

我曾做过一次敏捷中各种方法实践之间的关系梳理，最后得到的结论就是业务端需要解耦需求，技术端也需求解耦代码，这两端都达到要求了，Scrum或者用KANBAN才能最大程度的发挥作用。以后若有机会再和同学们分享这个分析过程。

到这里这一式也讲完了，这一式的内容不多，但是很重要，这一式是告诉项目团队，努力的方向是去完成用户故事，在开始一个新的工作之前，先看一看，我是不是还能为未完成的用户故事出一份力？这就是聚焦完成，谨慎开始。

本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。