认识达内从这里开始

软件开发过程中，为了保障项目的顺利进行，有些时候我们是需要注意许多的工作内容事项的。今天，我们就一起来了解一下，软件开发过程中需要关注哪些问题。

事项一：不应跳过估算匆忙进入详细规划，应采用自上而下的估算方法。

任何形式的计划，都好过完全没有计划。自上而下的估算，为详细计划过程提供了有价值的输入。

根据我的个人经验，设置不切实际的期望是项目失败的主要原因。制定准确的目标是企业的核心竞争力，但不少企业尚做得不尽如人意。

部分原因在于，企业在估算项目规模时，倾向于使用传统的范围界定过程，这往往会给出不准确的预测。项目经理在编制项目范围时，传统做法是采用一种自下而上的方式。管理者要求每个团队成员估算自己在特定活动中的工作时长，并根据这些“假设”确定每个成员的日程安排。不幸的是，这种自下而上的过程中缺少了一个关键的因素，那就是“事实”。一项基于QSM项目完成情况数据库的研究显示，有三分之二的公司未能比较计划的绩效与历史上类似项目的实际绩效。比较工作可让团队更好地了解完成工作所需的时间、精力和资金情况。他们竭力做出的估算，也许会导致错过后期限、成本超支、客户不满意，以及开发人员被剥夺权利。

如果项目在开始时采用了自上而下的方式，那么一种非常有效的策略是基于范围的估算。借助于类似项目提供的数据，管理者可以准确地给出完成工作和交付完成工作产品所需的工作量。他们从一开始就全面了解项目的各项功能，并相应地分配资源。

事项二：不应因为后期限迫近，而做出增加员工的决策。

“厨子过多，反而做不出好的肉汤”，这是另一件人们常说的事情。然而，在面对日渐积压的后期限时，许多项目经理的一反应是为项目配备更多的人员。他们秉持的理念是，做事的人越多，事情完成得越快。

当然，这种做法几乎不会很好地发挥作用。为项目添加更多的资源，通常提高了项目的复杂性，并增大了出错的机会。更多的人员会导致沟通的不畅，这可能会增加缺陷，并导致返工。实际上，更多的人员通常会导致项目耗费更多的时间，而非节省时间。

项目经理可以使用自上而下的估算，对投资组合中的适当人员配置和资源需求做可视化展示。估算可在一段特定的时间内按计划和月份进行细分。他们甚至可以将员工按支出率划分，并与预算限额做比较，确保员工适合于特定项目，或是匹配组织当前的和未来的容量需求。下图可视化展示了估算随时间变化的情况。

事项三：不应为计划所奴役。

事先做好计划，并不意味着团队在整个开发过程中都无法改变方向。即便给出了好的计划，但是大多数项目在其生命周期中，不可避免地会遇上一些未知因素，或是需要重新确定优先事项。或许管理层会要求添加一些新功能，或许一些团队成员将被转到其它更为关键的任务上。

不确定性虽然随时可能出现，但是它可以纳入到自上而下的计划过程中，从而降低其潜在的影响。本文前面给出的项目例子就是一个很好的证明。不确定性在于团队可能无法达成100个Story点。在计划中预先纳入这些不确定性，有助于规避项目早期的突发变化。

在整个开发过程中仍然可能存在一些波动，其中的大部分是由于利益相关者的需求的不断变化所导致的。例如，客户可能需要一些新的功能，以满足不断变化的市场动态。这些需求将不可避免地对开发产生直接的影响。团队需要在尽可能维持初共识的情况下，做好调整的准备。

不幸的是，当前进的道路上蹦出这些意外障碍物时，许多组织不知道如何做出调整。估算是易于上下微调的(因此称之为“估算”)，并且可以通过重新预测去适应不断变化的需求和动态。优先事项也是可以完全改变或移除的，以适应新的工作需求。项目范围也可以做改进，为利益相关者提供切实可用的更新后时间表，使项目保持正常进度。调整是一个动态的过程，可与组织推动敏捷开发的过程紧密结合。

作者：Lawrence Putnam Jr

译者：盖磊

节选：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。