让妈妈告诉你如何对单元进行编程）”以修复错误和清理代码——像对待软件功能需求一样对待它们。我们使用的故事类型都是在PivotalTracker系统中默认指定的。综上所述，软件功能单元一般被认为是一种可以给用户带来价值的“故事”（所以你可以对他们套用这样的套话，“作为用户，我想要的是……”），但是错误和代码管家工作不属于此类（尽管其中一些必须处理，例如偿还技术债务）。根据PivotalTracker系统中的设置，只有软件功能被分配给“故事点”。团队的“分数”取决于过去3-4个迭代开发周期中完成的“故事点”的数量，所以如果你花费大量时间重构代码和修复bug，你的“分数”就会下滑。因此，管理者会强烈反对把“故事点”分配给代码清理和bug修改，因为“只有花时间开发功能，客户才会认可我们的努力”。遇到这种情况，勾起了我小时候收拾屋子的回忆。如果你像我小时候一样马虎懒惰，你会把脏袜子和糖果纸扔得满地都是，几乎看不到地板。妈妈会喋喋不休地说：“记得每天把袜子扔进洗衣机，把糖果包装纸扔进垃圾桶，这样你就不用打扫房子了。”它只是堆积起来，直到无法忍受为止。问题是，保持家庭整洁的正确方法压力太大。于是，大家最后选择了把脏衣服不断往衣柜里塞，用力推衣柜门（要用力，不然会倒塌），让房间看起来很整洁。但事实上，混乱仍然存在，即使你看不到（不想看到）它。修复错误和清理代码的工作对于软件开发来说是一样的。在敏捷开发中使用“故事点”最大的好处就是通过为用户创造了多少价值来衡量一个程序员的生产力，从而正确地激发程序员的工作积极性。将“故事点”分配给错误修复？花一个月重构代码中的数据库层？你的“成绩”下降是一个警告，表明有问题。你需要思考，你需要理解为什么以及如何纠正它。也许您的需求不完整，或者根本就是错误的，您还没有开发出客户真正想要的东西。也许您没有编写足够的单元测试和集成测试，因此错误在开发迭代中堆积如山。可能你的编码速度太快，没有足够的规划，导致你的架构设计无法对接新的需求，需要频繁、大规模的重构。在任何一种情况下，如果必须将“故事点”分配给错误和代码整理，那么它反映了一个潜在的问题，比如整理房间。让“故事点”发挥作用，让它提醒您注意开发过程中的潜在问题。但是不要像你妈妈告诉你收拾房间那样相信我的话。Matt的翻译来自：http://www.vaikan.com/how-your-mom-would-want-you-to-develop-software/英文原文：Here'sHowYourMomWouldWantYoutoDevelopSoftware
