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

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

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

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

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

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


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

后来我通过Scrum了解到，这个其实就是“猪和鸡”的区别。



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

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


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

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

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

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



敏捷团队里面很强调"信任",但同时也需要"热情",这个"热情",大概就是从成员对于项目的主人翁精神和态度上来说的。从常理上来讲,要我们信任一个人，至少是某些方面要过得去，最好能达到"优秀"。

敏捷项目框架可以被裁减和调整，因为敏捷本身是一个目标，而不是具体的做法或者手段。有些项目要实施敏捷，在一些场合中会非常困难，例如人员技能素质无法实施TDD测试驱动开发；或者由于工作单位体制以及文化的原因，竭力阻止敏捷所带来的变革和各团体利益之间新的冲突。

总之搞不成敏捷，不够优秀肯定不行（但50%的敏捷也许够，事在人为，有那份心最重要），够优秀也未必行。

引用
现在IT人太多从码农的视角看问题的了，事实上码代码只是项目活动的很小一部分，我们理解上的项目也只是真实项目的一部分，比如商务不去跑到单子，我们PM连立项都搞不成
而实际上我们常常把码代码看成近似于项目的全部， 把其他参与项目的角色当成酱油、忽悠
太强调自己在项目中的作用，那当然有我们不愿意看到的效果
因为责权利是一致的，如果自己都认为项目成功基本是靠码代码，那项目完不成的时候你不加班谁加班?

敏捷项目环境其实是一个理想国，现今阶段还是比较少见。敏捷项目倾向于非固定期限、非固定合同总价的，作为咨询类型项目，按工料合同签订的项目，与敏捷应该是一个比较理想的搭配。当然是否能够敏捷，首先要从销售阶段解决问题，客户是否认同是关键。
除了项目类型的定性；另外一方面也是因为牵扯到一群人一起做事，涉及到人性因素，个中因素有时候会变得微妙和不必要的复杂。

固定期限固定总价的合同项目，在市场竞争和成本压力下，出现很多“不可能完成的任务”，项目的环境已经被扭曲，再加之所处的项目链上如果是在下游，这个时候不是敏捷不敏捷的问题，基本上没有救药。不敏捷也许更好。

我个人把敏捷当做一个理想状态，能带来的好处不只是工作上的，"敏捷是一种生活方式”，因为它让你的工作和生活更加均衡。
还有很远的路要继续走......


8 楼 seeckt 2011-04-14 热情这个东西在中国很不好说
西方的码农已经到了自我实现层面了，从出生保医疗，成长保教育，结婚给房子外带家电家具，失业了还有一两年救济金拿……
中国呢，哪怕高收入，来个通货膨胀、结婚生子或者家庭成员重病，生活就没保障，谈何自我实现
对于3、4K收入的底层员工，公司企业文化做的再好、再关系员工生活关系员工职业发展，房租涨个500、1000的，该走人还是走人
社会保障不起来，垄断不消灭，却要求企业搞产业结构改革而不再靠低人工成本的血汗工厂纯粹在推卸责任，这种形势下引进敏捷、CMMI、PMP什么的都是企业在自救，但是由于先天畸形，成长也是不完全的，全盘照读是找死，就算按自己的情况转化管理思想，也是背了国家转嫁过来的巨大风险 9 楼 hongbo.wu 2011-04-14 因为加班可能没有多少加班费或者没有，所以才这么想的。

如果加班按 1.5 倍或2倍计算。可工作时间却是1倍，猪都会算啊。加班效率会降低

将加班纳入项目计划的人基本上管理不到位。
除非真的是没办法，短时间内必须的。 10 楼 seeckt 2011-04-14 还真说对了，我觉得给加班费才能促进管理水平的提高，必须想各种方法提升生产力，减少浪费。不给加班费，那管理者就变成纯粹当监工，不管订饭还是陪加班或者给压力，一切为了让大家多坐位子上。 11 楼 tchen8 2011-04-14 seeckt 写道还真说对了，我觉得给加班费才能促进管理水平的提高，必须想各种方法提升生产力，减少浪费。不给加班费，那管理者就变成纯粹当监工，不管订饭还是陪加班或者给压力，一切为了让大家多坐位子上。

老板们花钱了肉痛了，才会研究是什么导致加班，有没有办法控制加班成本。否则看似“免费午餐”何时了。 12 楼 xingzhizhou 2011-04-17 现在的公司是一有项目就加班，加班不给加班费。