项目进度管理

软件工程这个概念首次提出是在1968年，其主要定义是

应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的
软件产品的定义、开发、和维护的工程或进行研究的学科

在《持续交付 2.0》中写道，

质量与速度根本不存在平衡，只有在产品能够承受的一定质量水准基础上，追求交付的速度才有意义。
持续交付要解决的问题是，如何在满足质量要求的前提下，快速的交付产品价值。

项目为什么会失败？

项目经理对项目失去把控，项目进度过于乐观，软件开发交付周期过长都会主观原因大概有以下几点

项目需要保持良好得“可见性”，项目的所有关注者，都应该对项目了如指掌，这是事项优先级排定的基础。

保持项目的 “可见性” 良好，“任务加塞” 就会变得有据可依。我们不是没时间做事，而是没时间做这件“低优先级” 的事情。

所以有时候可以这样说，
没时间是好事，可以促使人们想清楚，什么才是最重要的事情。

能不能加人，取决于事项能不能分解成多人并行执行的任务。
比如在 web 开发过程中，在一定程度上，前后端开发任务是具备 “可并行性” 的。
那么加人就能使这段 “可并行” 的任务提前交付。

但是，并行的任务迟早还有 “合并” 的时候，这时又要有沟通成本了。
因此，加不加人，以及加人能否解决延期问题，就要评估并行开发的任务占比。

瓶颈点一般是跟 “代码” 无关的，而是跟 “人” 有关。

比如，事先如果没有沟通好具体事项，那么就容易在做完后频繁返工。
或者，在开发过程中遇到不确定性时没有上报，私自做出的决策也有可能在后期被推翻。
又比如，项目需要某个人拍板后决定，但是这个人的回复又比较慢。

这些都是有办法解决的，关键在于没有 “识别” 出来。

对进度落后的项目进行治理，是一件 “技术活”，并不是加人多写点代码就能解决的。更多的是需要项目经理不断思考，沟通，发现。