转载

软件估算的五大定律

编者按:软件估算往往很扯,就像《人月神话》里面说的那样,认为一切都将运作良好,每项任务仅花费它所 “应该” 花费的时间基本上就是鬼话,但是估算又是不得不做的事情。怎样才能做好这又扯蛋又不得不做的事情呢?资深的软件架构师 Steve Smith 总结了 软件估算的 5 大定律 ,供做开发的、做销售的各位参考,也方便让客户理解一下。

估算是软件开发的必要之恶。不幸的是,大家往往认为写新软件就跟搞建筑或者修车差不多,所以软件工程师也应该像承包商或修理工一样,事先能够给出工作量的完美估算。建筑或修车的确能够做到,因为他们用的材料和手段都是已知的。车险公司事先就知道你的车应该可以走多远,每一种零部件维修应该需要多少钱。但是定制软件里面很多东西都是要从头做起,而且如何组合、最终如何工作、软件究竟应该干什么等这些都是运动目标。一开始的时候路径和目的都是未知的,所以很难知道什么时候能干完。

估算是定制软件开发的难题,不过还是存在一些普遍规律的:

估算第一定律:估算纯属浪费

在估算上花费的时间实际上是没有产生价值的。在开发者需要多少时间才能完成工作上这是一场零和游戏—如果估算要求很紧急并且打断了开发者正常的开发工作的话情况可能会更糟。如果开发者平均每周(40 小时)要花 2-4 小时的时间去进行估算,那就是 5-10%的生产力损失(因为用来估算的时间本来可以去写代码的)。如果开发者是兼职或只能用部分时间写程序的话情况会更糟糕。

若干年前,微软的一个部门在不增加任何新资源或者改变软件工程任务(设计)代码、测试)执行方式的情况下 把生产力提升了 150% 。其主要变化是任务估算的时机和方式。讽刺的是,原来大部分的频繁和及时估算都是管理层要求的,为的是提高透明度,希望看看团队生产力能够如何改进。即便这些估算都是粗数量级的估计,但频繁的估算仍然显著破坏了团队的整体生产力。

估算第二定律:估算不可互换

软件估算不可互换,这主要是基于团队成员不可互换的推论。也就是说,对一个人的估算并不能用来预测另一个人多久才能完成工作。

被迫根据团队另一位成员的工作来完成估算已经够糟的了,但更糟的是你被为了拿下单子的销售做出的估算设定了任务的截止期限。

如果估算者和实现者水平相当甚至在同一团队工作的话,估算的可转移性显然会有改善。像 计划扑克 这样的技术在估算任务时会利用整个团队的经验,确保不错失某些关键的考虑因素而导致估算过于乐观。这有助于确定估算或估算范围,但是显然也会消耗数倍(团队成员规模)的估算时间。

估算第三定律:估算是错的

估算不是承诺。是猜测,而且往往是范围越大未来的估算活动越深入,出错的可能性就越大。这又被称为 不确定圆锥 。

由于估算较小较近期的任务要比较大较远期的精确,所以把任务分解是有意义的。理想情况下,用户可以交互和测试的独立子功能应该成为估算过程的单元,如果这些是垂直切块的话,从客户或产品业主哪里获得对新开发的功能快速反馈是可能。排队论还认为,当系统中的工作很小且规模统一的情况下,吞吐量会得到提升,这进一步支持了把工作分解为较小的、一致的工作事项的做法。

对个人工作事项和项目的估算往往越临近工作完成就越精确。最精确的估算,就像最精确的天气预报一样,告诉你的是昨天发生了什么,而不是明天的。

估算第四定律:估算是暂时的

估算很容易变质。其保质期相对较短。开发者在项目开始前可能估计特定功能需要 1 周的开发时间。等项目开展 3 个月后,知道和拍板了很多事情后,同样的功能也许就只用几小时或者 1 个月了,或者由于优先级或方向的原因干脆放弃了。无论是哪一种情况,估算的价值都很小甚至是负面的,因为估算后太多事情都发生了改变。

为了处理这个问题,一些团队和开发方法论建议定期对积压工作的所有事项进行重新估算。然而,尽管这么做解决了估算容易过期的问题,但却又会加大第一定律所说的浪费。你是愿意团队对同一批积压事项重复进行 5、6 次估算却从不开始工作,还是愿意他们每周哪怕提交一项功能也好?最好还是再看看微软的 白皮书 ,看看重复估算是如何摧毁整个团队的生产力的。

我们从估算第三定律得知,估算越往后往往越准。也就是说,估算约合理地往后推迟,准确度就可以越高。这跟精益软件开发的推迟决定直到最后责任时刻原则很接近。估算也应该在最后责任时刻完成,以确保最高的精确度以及最少的重复。某些情况下,“估算” 实际上可以在工作完成后进行,这样精确度可以达到 100%(而且成本几乎为 0!)。

估算第五原则:估算是必要的

尽管前面四条原则说的似乎都是估算的坏处,但估算是必要的。如果对软件开发的时间和成本没有概念,企业就无法做出是否开发的决定。作为应用建设提案或赢得项目的一部分,服务型公司经常必须提供估算。仅仅因为上述定律是正确的并不意味着估算就可以不要了。然而,你可以更好地管理客户、项目经理、销售团队等涉及到的人的期望和花在估算上的时间,在定制软件估算时让大家理解这些事实。

总结

以上就是软件估算的五大定律。这些定律基本上适用于我碰到的每一个定制软件项目。天下没有免费的午餐,估算也一样会产生真正的成本,考虑把估算作为软件开发过程的核心之前必须考虑清楚这一点。一旦项目审批前进行了足够的高级估算和 ROI 分析,更多的估算工作未必会比实际工作的快速交付产生更多的价值。

本文编译自: ardalis.com ,如若转载,请注明出处:http://36kr.com/p/5040514.html

“看完这篇还不够?如果你也在创业,并且希望自己的项目被报道,请戳这里告诉我们!”

正文到此结束
Loading...