在今天开发人员的周例会上，大家吵的不可开交，我们在讨论在敏捷开发中是否应该将“故事点(story point——敏捷开发中的一种工作量单位)”分配给修改bug和代码整理工作——将它们跟软件功能需求一样对待。我们使用的story类型都是 Pivotal Tracker系统里缺省指定的。概括起来，通常认为软件功能单位是一种能够给用户带来价值的“story”(所有你可以对它们使用这样的套话“做为一个用户，我想要的是…”)，但bug和代码整理工作不属于这类(尽管它们有些是必须处理的，例如偿还技术债务)。

根据Pivotal Tracker系统里的设定，只有软件功能特征才配分配给”故事点“。团队的“成绩”依仗于在过去的3-4个迭代开发周期里完成的“故事点”的多少，所以，如果你将大量的时间浪费在重构代码和修改bug上，你的“成绩”就会下滑。于是，经理会极力反对将“故事点”分配给代码整理和修改bug，因为“只有把时间用在开发功能上，客户才会认可我们的努力工作”。

遇到这种情况，勾起了我对往事的一段回忆，那是我在童年时整理房屋的事情。如果你跟我小时候一样邋遢懒惰，你会像我一样将脏袜子、糖纸丢的满地都是，几乎看不到地板。妈妈会反复唠叨说“每天记住把袜子丢进洗衣机，把糖纸丢进垃圾桶，这样你就永远不需要打扫房间。”但有时候，这些事情看起来需要太多的努力，于是垃圾总是越积越多，直到无法忍受。

问题是，正确的保持室内整洁的方法给人太大的压力。于是，大家最终还是选择了将脏衣服不断的塞到衣橱里，用力的推衣橱门关上(用力，不然会塌落出来)，这样屋里似乎整洁了。但事实上，脏乱依旧存在，尽管你看不见(不想看见)它。

修改Bug和整理代码的努力对于软件开发来说是同样的道理。敏捷开发中使用“故事点”的最大好处是，用给用户创造了多少价值来衡量一个程序员的生产效率，这样正确的激励程序员的工作积极性。将“故事点”分配给bug修改？花一个月时间里重构代码中的数据库层？你的“成绩”的下降是指警告你某些事情有问题。你需要思考，需要明白这是为什么，以及如何纠正。

也许是你的需求不完整，或根本就是错误的，你并没有开发客户真正想要的东西。也许你没有写出足够的单元测试和集成测试，所以在开发迭代中bug越来越多。也许你们的编码速度太快，没有充分的规划，所以你的架构设计无法接入新来的需求，需要频繁、大量的重构。

不管是哪种情况，如果必须把“故事点”分配给bug和代码整理，这是存在底层问题的一种反映，就像是整理房间一样。让“故事点”充分发挥它的作用，让它提示你在你们的开发过程中存在潜在的问题。但不要只理解我的话的表面意思，就像你妈妈如何告诉你整理房间的话一样。

Matt

分享这篇文章：