所谓“项目缓冲”其实只不过是加班?

现如今，关于软件项目管理的话题以及衍生出来的各种软件管理流程，确实不少；但是仅就软件项目的特点，究其本质，仍然没有太多变化，基于三角约束（范围、进度、成本）下的可交付、以及基于客户满意的软件质量。

同时，软件项目通常所面对的各种压力，与其它行业中常见的情形，也没有太多的变化，但是我们通常所看到的项目问题，往往表现为“进度问题”，为了解决这个问题，于是很多的项目都掉进了“加班赶进度”大坑，直到软件交付、回款到位。最后本着“下一个项目我们会改进”的意愿，不幸的掉入下一个大坑。

我们想“潇潇洒洒的活”，最后只不过是个“窝窝囊囊的活”，或者“窝窝囊囊的死”。

所谓的进度问题，掩盖了很多问题背后的问题，这个似乎是源自我们与生俱来的、并且受环境影响和不断强化的时间度量观念。
当还是小孩的时候，更容易被问及：还要多久才到家、还要多久才把饭吃完、还要多久才能把作业做完，而不是问：还有多远才到家、还有多少饭没吃完、还有多少作业没做完。当参加工作的之后，不断被问及的似乎就是：还有多少时间把这个功能完成、这个项目究竟还有多久才能搞定，而不是问这个功能还有多少验收条件待完成、这个项目(在当前的范围定义下)还有多少故事点/功能点没有完成。
即便是我们口头上说工作量，也会翻译成时间：某任务甲工作量比较大，5天；某任务乙工作量比较小，半天。

同时人们也非常关心钱，因此我们所做的软件项目大部分都是固定期限下的固定总价合同项目。

很多项目都不容易，需求范围蔓延、需求不断变化，期限固定、合同总价上限，没有英雄出面的情况下，只好咬紧牙关加班。


在总项目时间为6个月的启动会议上，某项目参与者用关键路径法在白板上一划，指出来这个是关键路径，我们要加项目缓冲，然后扯谈什么赚值分析法，什么加班会导致成本增加之类的，云云；另外一个人鬼扯了一通，然后基于当前的需求我们赴汤蹈火立即开始，后面需求变化了再作调整。
然后他们一同抬起屁股消失了。在后面6个月时间里，开发团队在兢兢业业工作，而他们不是在开会，就是在去开会的路上。
你期望发生的事情都不会发生，倒霉的担心最终变为现实。项目缓冲就是加班，调整就是加班，而且成本不会增加。这个我不多说，你懂的。

后来我通过Scrum了解到，这个其实就是“猪和鸡”的区别。
[img]http://dl.iteye.com/upload/attachment/445355/434f0d14-266c-34fb-b120-26822d9f8e6c.jpg[/img]


PMI在他们的那本砖头书《项目管理知识体系指南》对于加班说的比较委婉，叫做“赶工”，同时紧接着煞有介事的说赶工会带来成本的增加。

Ken Schwaber 在《Scrum敏捷项目管理》中，对于如何将Scrum应用于固定期限项目上，坦诚的表示暂时没有答案，但是可以将Scrum的实践部分应用于前期阶段的需求分析和软件架构搭建。Mike Cohn在《敏捷估计与规划》中，也提到了如何面对传统类型项目(相对于敏捷项目），他针对于此讨论了两种项目缓冲：功能缓冲、或者进度缓冲。前者严格遵循固定期限，但是可能会裁剪部分预期功能；后者则估计一个期限范围，并且通过渐进明细的方式使得这个期限范围更精确。在敏捷项目的语义中，唯一提到加班的地方只有一处：“不提倡加班”。


乔布斯说“工作本身就是一种奖励”大概也包括加班。在国内，据说某人也提到过“加班是不对的，但是把该完成的事情放到加班时间去做也是不对的。”这就似乎包含强制加班了。

对于一线人员，正常情形下都会比较关心 强制加班。
现如今的加班强人们不但包括了“铁人”，也包括了“牛人”（牛，都是任劳任怨的）。以Scrum为例，在敏捷的语义中，由于错过了沾手可得的机会，他们成了不受善待的猪。
敏捷不是神器，也不是银弹，但是它从几个方面提供了关于“加班”的更多观点：敏捷项目不是固定期限的，这个更符合软件项目的自然属性；敏捷项目针对于“工作量”除了给出传统时间度量定义，也提供了另外的理解；敏捷项目关注软件质量，在加班缓冲对于软件质量的伤害这个问题上，有着更客观的理解。

加班本身只是一个项目管理工具，用于对冲项目负面风险损失，或者用于争取项目正面风险价值。工具本身没有错，但是很多时候，我们的项目从一开始就把加班作为必要工具滥用之。

再回到我们前面说的“进度问题”，如果有人说，你们出现进度问题，是因为加班所致，逻辑上真的似乎不太讲得通；而如果有人说，万米长跑落败了，是因为一开始就太用力跑的缘故，这下子大家都懂。