敏捷日志2013-2-7

这期的迭代规划，估算完成后，画燃尽图的时候，横轴上的日期不知道怎么定了，当时画了2月份的25日。我当时就说不对，如果25是固定的迭代发布日，那我们前面的估算还有什么意义，反正是要25完成的。

这期估算一共是20个故事点，我们一共是6人，也就是说，理想状态下，不用3.5天就能够完成，但显然不可能。

后来我考虑了一种估算方法，去除我，因为我要给他们支持和代码审核，事实上，一般我也不会去做某个任务，并不是偷懒，而是没有时间，他们会随时有可能打断我。再去除1人，因为有些人还会有其它的工作。剩下4天，我们采用结对编程，算2人，这样，应该是10天完成任务，考虑到春节的影响，又加了1天。

我相信靠谱的计划才能给人动力，所以对员工的估算，我几乎不会扣时间，有时还会放宽一点。因为根据我自己的亲身体会，估算时往往比较乐观，因为只考虑了正常的情况，而没有想到可能会发生的异常。

有一个领导的观点与我截然不同，他的观点是计划要定得紧。例如一个项目正常100天完成，他会定50天，他认为这样能给人压迫感，即使50天不能完成，也能在75天完成，如果计划定100天，则要150天才能完成。在我的前面一个项目中，他跟我说2周完成一个迭代，实际的情况我就不说了，那是一个笑话。

我认为，只有定一个大家认为能够完成的计划，才能激发大家去努力。现在我定的计划，确实是有点松的，主要原因是我自己不想太累，另外，员工的技术能力也确实不足。

结对编程是让我有点纠结的方法，从实际的效果看，并没有提升多少效率。后面我打算做一些对照性的实验，两个类似的功能，一个用结对，另一个不用，看看结果如何。不过至少目前有一个优点是肯定的，就是当一个人有事时，另外一个人能够无缝衔接。我可能需要重新看看《结对编程技术》。我跟他们结对的时候主要目的是培训，我想这不应该是结对编程的一个常态目标。

不过，目前看来，员工的技术水平提高还是很快的，有多少是结对编程的结果就不知道了。

度量也是我目前考虑得很多的一个问题，度量非常重要，它是我们改进的基础，但我不希望把它变成一个扣分的工具。现在我们人也不多，并且经常性的交流，我相信不会有南郭先生的。我希望大家能够很积极主动的去做度量，相信度量能让自己变得更好。

有一个同事看到我们的白板，说他以前的公司也搞过。我问他感觉怎样，他说不好。仔细了解后，发现他那领导把这方法当作一个扣分的手段，并且，他只采用了Scrum计划会议的手段（有一些部分还用错了），XP的一些方法完全没有使用。人的思想才是最根本的，如果仍然是专制的思想，认为员工是不自觉的，只会沾污了敏捷。