紧时间和排程压力如何影响TCO和交货时间？

Question

一位朋友的父亲是一位软件工程经理，他强调说：“调度超支的首要原因是调度压力。”

研究进展如何？是适度的调度压力令人兴奋，还是我提到的经理是对还是错，还是“调度压力越大，交货时间越长，TCO越多？”它是一种理想的软件工程可以在没有调度压力的情况下工作，但实际上我们必须处理现实世界的限制吗？

任何与软件工程文献的链接将不胜感激。

Answer 1

调度超支的首要原因是调度压力。

我不同意。排满时间的首要原因是没有反映现实的日程安排，而且过于乐观。人性决定了一定的排班压力是绝对必要的。在没有一定排班压力的情况下出现的几个问题就是有趣的问题，“最好的是足够好的敌人。”我们技术人员更愿意致力于解决我们感兴趣的问题，而不是需要解决的问题。去掉最后期限(也称时间表压力)，我们将致力于那些有趣的问题，以损害产品。

另一个问题是产品需要“足够好”。它不需要完美。工程师和科学家认为，在某些特殊情况下，简化的假设并不完全成立。图形设计师会看到其他人看不见的混叠问题。程序员在他们的架构中看到了对产品行为没有任何影响的缺陷。“最好的是足够好的敌人”，这意味着有时我们不得不面对那些不是真正问题的问题。

缺乏调度压力将导致产品的所有权成本非常高。造成超支的原因是日程安排不周。这可以以多种形式出现。低估所需的努力，不考虑依赖关系，将人员添加到一个已经很晚的项目中。举几个例子。

Answer 2

调度压力越大，交货时间越长，TCO越多？

好吧，任何由经理在没有与技术领导讨论的情况下完成的日程安排都很容易出现这种情况。非常明显的事实是，不以事实为基础的调度或估计容易失败。

此外，避免基于证据的调度的经理们也会走向他们的项目的下一个失败。关于这一课题的研究有很多，基于度量的调度是正确的研究方向。

Answer 3

从右到左的日程安排。

管理层的某些人总是认为他们是史蒂夫·乔布斯( Steve )和他著名的现实扭曲区。在产品开发人员对他们进行教育之前，非技术经理可能经常会对日程安排的看法，就像法国早期电影“火箭科学”( “月球之旅”(“月球之旅”) )那样复杂。

这个问题已经存在了一段时间了。Fred谈到了在神话中的男人月中的无肠道估计。巴里·博姆( Boehm )在他关于理论-W管理方法的建议中谈到了这一点。最近，Steve McConnell (“代码完成”一书的作者)将原则性谈判问题的概念引入了“如何为不受欢迎的时间表辩护”。

敏捷将项目的范围推进到一个高度可见的地方。敏捷宣言呼吁“客户协作而不是合同谈判”。我也希望它能赋予那些被追究责任的人权力。规划博弈避免非技术利益相关者强迫开发人员许下他们很久以前就已经被需求变化或新发现所超越的承诺。

如果您的组织拒绝敏捷，那么就有很好的方法来校准基于挣值的计划的估计值。我不认为挣值能很好地解决预测中的一些实际问题，但它可以帮助消除人们对项目速度的幻想，以及对我们所拥有的某种事实的反复估计。

有一句谚语说，你越早开始编码，它的时间就越长。进度表压力会产生强迫方法改变的效果。有时，它是从瀑布到“代码如地狱”。这可能会对质量产生负面影响，更不用说当员工不能尽力而为时，他们的同事和未来的维护人员会看到他们处于最坏的状态，而不是他们的最佳状态。在这样的环境中，可以通过源代码控制、日常构建和测试(或持续集成和单元测试)、代码评审、使用经验丰富的高技能团队、抵制在项目后期增加工作人员的诱惑以及旧的待机和加班来控制某种程度的混乱。

其他时候，方法的改变可能是从瀑布到迭代增量。我的经验是，管理层很难接受敏捷。但过了一段时间，就出现了支持敏捷的新管理层。时间拳击可以像预算一样-它可以迫使我们考虑如何最好地利用有限的资源。Scrum有两个时间框--一个是每天在团队成员之间进行反馈，另一个是每月通过刻录列表进行冲刺。

创作共用许可证-见http://en.wikipedia.org/wiki/File:Scrum_process.svg