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

 

     我们在开发软件的过程中往往会遇到这种情况：如果承诺的太多，开发就会在继续进行的过程中碰到麻烦，程序员知道他们在劫难逃，他们就不会做出最佳业绩，他们就不会态度明朗的沟通，政治老手们在玩“进度游戏”，其中谁是第一个指出前面的任务是不可能的，谁就会被称为失败者，而不是一个“团队工作者”，当然我们不能这样做，其实在规划极限这杯书中就说到，我们选择在多数情况下相当起作用的简单规则：比如你明天要做的工作和今天实际做的一样多。书中提到了一个天气预报的故事，想要更准确的天气预报就要做到明天的天气和今天一样，虽然有些难懂，但是后面又做出了一些解释，大概的意思就是如果这个月你完成的量是五个的话，那么你下个月保底的量就是五个月，你这个月承诺了五个量，你下个月你至少要完成五个月的量，除非你下个月想要轻松一点，这个月你可以完成6个下个月你就可以完成4个的量，简单的意思就是这样。

“除了编码和其他活动，我们在工作场所的人际关系也会影响到生产率和自信心。成功既需要技术又需要好的合作关系，极限编程致力于同时解决这两个问题。”极限编程具体分成了哪些类型的内容呢？有价值观、原则和实践三部分。关于“管理”： “XP是我在自己的软件开发实践中协调人性和生产率并共享这一协调的一种尝试。我已经开始注意到，我越是有人情味地对待我自己和别人，我们大家的生产率就越高。成功的关键不在于自我禁欲，而在于承认我们是人，我们生活在人与人之间交往的环境中。”XP特别强调人性，大多数方法论往往忽略了“人”本身，而XP非常强调人性化。关于“时间不够”：“你可能有足够的时间、资金和团队技能，也可能没有。如果你有6周时间去完成一个项目，你惟一能够控制的是你自己的行为。你不能控制别人的期望，但你可以告诉他们你所知道的关于项目的所有事情，这样他们的期望才有跟现实匹配的可能性。当我知道了这一点，我对最后期限的恐惧就消失了。'管理'其他人的期望不是我的工作，而是他们自己需要操心的，我要做的就是尽可能地沟通清楚。”

    很多人应该都遇到过相同的问题吧，产品经理或者其他leader跟你说“我想xxxx功能，什么什么时候你要把这个完成。”这种最后期限会给工程师很大的压力，很多时候，这种要求是几乎不可能的。“当我还是个年轻的软件工程师时，学会了根据三个变量来管理项目：即速度、质量和价格。项目发起人会设定其中的两个变量，而团队则评估第三个。如果计划不被接受，那么谈判也将随之开始了。

    这个模型在实践中运行得并不好。时间和成本通常在项目范围之外确定，这使得质量成为你惟一能够操作的变量。降低你工作的质量并非明显是你的责任。你以这种方式制造工作进展的假象，但这是以减少成就感和损害团队关系为代价的。我们所说的成就感应来自于完成高品质的工作。