规划极限编程读后感（3）

    如果产品经理提出的需求很不合理，我们需要做的并不是迎合他的需求，降低产品质量，而是向他说明我们真实需要的时间。无独有偶，鲍勃大叔在《clean code》中说了同样的话，就像医生不可能因为“病人很急，说你别洗手了，快给我动手术吧”，就真的听病人的话不去洗手一样，病人不了解不洗手的后果，而医生知道。同样的，产品经理不知道降低产品质量带来的后患——无穷无尽的bug，后期维护甚至开发后期的代码沼泽！我们必须严守这一关，不提供低质量的产品。如果产品经理说时间紧，如何做出调整是产品经理的事，并不是工程师的事。这里另外需要提到的一点是，增加人手并不是最好的解决方法，就像《人月神话》中提到的，以人数乘以时间来计量生产力，对于软件开发来说，只是个神话。根据《销烟中的scrum和xp》一书的研究来看，最佳人数是7人，从5~9人都是比较好的，小于5人，大于9人都不能给生产力带来明显帮助。                           所以，最好的办法是限制范围。按照scrum中的方法，每次团队评估本轮sprint中所能完成的用户故事，完成不了的故事就放到下个sprint中。产品经理不能强制说我要这功能我要那功能，只能排优先级，跟团队说哪个重要，优先做哪个。生产力是固定的，工程师不能为了提高生产力而降低质量，这是一切罪恶的源头。没有一个任务在计算上给人留下深刻印象，我们可以在脑子里计算一下然后再将答案写在任务卡上，电子表格可以轻松处理复杂一些的计算，你还可以用这个表格来生成各种非常酷并给人留下深刻印象的报告和图表，其中一些十分有用。

    通过这几次的连续阅读，在前面我明白了计划的重要性也明白制作一个准确无误的计划也是不容易的，去实现它也是不容易的而且我们在实行计划的时候要注意不要掉进计划的陷阱中，我觉得这一部分是我在前面学到的重要的知识，这本书主要是讲xp方面知识，对于主管方面的帮助颇大，开阔视野等等，还有就是帮助解决通常碰到的一些问题和客户与开发者间的一些条例我觉得也十分有用。

    总而言之本书的用处很大，但是有的地方对于我这种菜鸟还是看不懂的，我也尝试着去搜索问题去解决，然后让自己更明白一些那种难懂的词，其实书也引用了大部分实例让读者更易理解。