《规划极限编程》阅读笔记02

任务太多

当你超负荷工作时，不要想灭有足够的时间，而想要做的事情太多。你无法给自己更多时间，但是你可以让自己少做一些，至少目前如此。

在书中写到，他们曾经一起从事过一个项目，团队将这个项目从近在眼前的湮灭中挽救出来。在第一次发布临近的一段时间，大家心里都很清楚我们尽量不要错过发布的时间。一天他们开了一个碰头会来讨论这个问题，他们轮流回答“什么阻碍着我们投产？”这个问题，回答很是一致。

　　　　“我的时间不够。”

　　　　“我的时间不够。”

　　　　“我的时间不够。”

没有任何人会有足够的时间，但是没有任何摆明的答案。

　　在我们的开发过程中，这个问题也比较明显，对于时间问题，往往问到做了什么的时候，都说没有时间，才没有做工作，一个工程就一直往后拖，直到最后也拖，最后完不成任务的时候，又把责任推来推去，每个人分的任务都是一定的，但是思想觉悟不一样，根本没有团队的意识，给他安排了任务都不主动的完成，每次都等着催，然后还不完成，很是令人生气，现在开始后悔当时的决定了。

　　当你处于项目结尾时，你实际上只知道自己的位置。因此你需要每几周结束项目——那就是我们使用迭代的原因。迭代迫使我们每几周看一下时间控制杆，以便我们不可避免的看到更改范围的结果。我们需要这样的计划风格：

　　保持程序员的信息，计划是可行的。

　　保持客户的信息，他们所获得的和他们能获得的一样多。

　　执行起来花费尽可能的小。

昨天的天气

不能讲十磅的东西放在五磅的袋子中。——曾经尝试过这样做的任何人。

作为计划的基础，假定你这周要做的工作同上周一样多。

　　袋子有多大 ？这个购物的隐喻完全不错，但是预算是什么？你承诺要在以后的n个月做多少工作呢？如果承诺的太多，开发就会在继续进行的过程中碰到麻烦。程序员知道他们在劫难逃，他们就不会做出最佳业绩，他们就不会态度明朗地沟通。

　　在实际开发过程中，也确实有这样的现象，承诺了很多，但是却不能按时完成自己承诺过的任务，这其实是很严重的事情，团队商量好要在什么时候要进行功能测试，可是在规定时间里你并没有完成自己承诺的事情，那么，团队的进度就会被拖掉，原本的计划也会被打乱。

　　其实个人感觉，这样的队友不要也罢，只会夸夸其谈，却不能付诸行动，在一个团队里也只是在拖团队后腿，不能给团队带来任何的好处。