我们是在用敏捷方法实现一个糟糕的瀑布吗？
前些天和同事聊天，他问我“我们现在做的是敏捷吗？是不是只是把瀑布拆成了小迭代、而且还做得挺不理想的？”
他举例：星空笔记这个功能的第一个用户故事很大，团队打扑克估的结果超过 20 个故事点。于是大伙一起动手剔肉斩骨，把用户故事裁剪为只能发表文字、评论和点赞。2 周后我们在迭代评审会上把开发好的功能呈现出来，现场客户很不爽地告诉我们，不支持发图片笔记让他没办法把这个功能用起来。
同事问我：“我们是否为了敏捷而敏捷，结果做出来了一个残破的功能。我们是否应该用瀑布把功能做完善？”
我回答：我不这么看。我认为就我们团队的情况而言，敏捷是更优的方法。
具体来说是这样，瀑布和敏捷的基本假设不同：
- 瀑布假设我们能通过细致的需求调研弄清楚用户需要的是什么。所以我们可以通过一份完备的需求文档和按月计时的版本，交付一个让用户满意的功能。
- 敏捷假设一次做对很难，但我们可以逐步做对。我们用按周计时的小迭代开发出一个小东西，让用户使用和反馈，我们基于反馈调整工作计划。如此反复，最终满足用户的需要。
如果用瀑布方法，我们需要把星空笔记（评论的回复、评论的赞、收藏、分享等）及其附属功能（比如管理后台）都设计好。然后梳理会（Product Backlog Refinement）上团队估算需要 2 个月，最后实际需要 3 个月，因为越庞大的工作越难估算。但最让人难过的是等我们把功能呈现给客户之后，他可能会地告诉我们“这不是我想要的”。这样的故事在我们这么多年的工作中屡见不鲜。这位同事和我都经历过不止一次。
按照敏捷的方法，我们用一个 2 周的迭代开发一个小东西，拿给客户提意见，再用一个迭代去完善，再收集客户反馈。经过这样几个迭代后，我们最终会从客户那里得到一个肯定的答复。
这段聊天让我觉得有必要在找个时机向团队再次说明：我们可能无法一次就达成客户期望，我们开迭代评审会（Sprint Review）的目的也不是为了博得满堂彩，而是开诚布公地接受检视和收集反馈。所以做好迎接吐槽的心理准备，然后继续演进。客户的反馈是一个评估器，告诉我们做对了什么做错了什么，并最终指引我们达成某个目标。
回头来看前述星空笔记的案例，我们从客户的反馈中吸取了一个经验：以后可以在剔肉斩骨之后、动手做之前，听听客户的意见。这样我们也许会在第一个迭代里把图片功能做上。
可能我们还会再掉进这个坑，但我们终能记住并做得更好。敏捷，是一个从实践中学习和成长的方法。