[转]软件开发中的deadline该怎么定?

[转]软件开发中的deadline该怎么定?

前言

嗨!大家好啊!今天又给大家带来了一篇关于软件开发中时间项目周期如何确定,怎么看待开发期限这个问题已经如何建立好的期限标准,的一篇优秀的文章.

如原文作者不希望转载,请联系!

附上:

喵了个咪的博客:http://w-blog.cn

原文地址:**Ryan Spraetz的**How should deadlines be used in software engineering?

deadline的现状

日常谈话中有多少次你在谈到deadline（期限）时，曾至少有一个人对这个概念嗤之以鼻？我已经听过太多次了，甚至连我自己也这么干过，不过现在我想改正这一习惯。

软件领域较之于传统的印刷媒体（print media）有很大的不同，而deadline的概念就是从传统的印刷媒体中得来。然而，不能仅因为目前在软件领域尚无通用的deadline概念，就以为该摒弃这个概念，或以为它没有价值。

就工作的规划和并行处理来说，deadline是极其重要的。如果没有预计的完工期限，所有团队都必须连轴工作，同时也会大大减少交付次数。而且如果不明白deadline的真正含义，那么deadline可能会让人感到沮丧，甚至产生相反的效果。

问题及解决方案

以下是根据我的经验总结出来的，在工程公司中与deadline最为相关的问题，以及最有可能解决问题的办法。

对deadline的理解因人而异

A：“下周才是deadline，我还有大把的闲余时间！”

B：“为什么要担心这个？没关系的，deadline什么的当不得真。”

A：“但我不想被炒鱿鱼啊！”

这组对话就很形象地展示了对同一个deadline，A和B两人在理解上有着巨大的差异，这也会导致整个团队在努力实现deadline时出现困惑与挫败感。

事实上，deadline必须要有号召力，每个人都得知道deadline重要的原因，他们必须明白错过deadline会对整个圈子有什么样的影响，包括对其他团队的、对客户的或者对公司整体的影响。

更重要的是，那些达成的deadline需要热烈的庆祝，而这一点常被忽视掉。比起责备那些错过deadline的员工，建立起为达成deadline庆祝的企业文化才是上上之策。

在项目的生命周期中过早设定deadline

A：“嘿，我们得完成这项工作【插入一个真的非常难的未知项目】，什么时候能干完？”

B：【快速搜了一下到底是什么工作】“额，我不确定。”

A：“我需要一个确切的deadline。”

B：“三，呃四个……月嗯周……月吧，四个月！”

A：“好极了，到时候见。”

向一个各方面都属于未知状态的项目要求一个deadline简直后患无穷，也让项目涉及到的员工压力很大，为项目立起了失败flag。所以，先深呼吸，耐心等两天，让大家完成探索工作。虽然搜集信息花费了时间，但之后我们却能给出有意义的评估，这些信息会帮助我们设定更加准确的deadline。

deadline更新频度不够

A：“这个项目要在5天内完成，目前进度ok吗？”

B：“有一点落后，不过不要紧，我们会按期完工的。”

A：“好极了！”

【4天23小时后】

A：“再检查一下项目，准备好发布了吗？”

B：“额，还没，出了点问题，目测还得一个礼拜。”

A：“$%@!*”

在这个案例中，在新问题出现时，开发人员并未调整或重新评估deadline，B没能立即提出问题，而是等到deadline才告知他人，于是A也受此牵连，而整个团队也会因为要赶工另一个deadline而倍感压力。

设定deadline不应当是为了强迫员工超额负荷，把人当牲口用，而应用以设定外部对项目的预期，让计划呈现可预期性。Deadline必须尽可能准确地反映现实情况，否则一旦出现信任危机，这个概念也就失去了传递可预期性的功能。当然，我不提倡每小时或每天更新deadline的行为，但也许每周更新，或至少按标准计划的节奏来更新是个不错的主意。

更新deadline并不拘于延长时间，也可以缩短周期。至于具体怎么做，又或者兼而有之，都得工程师和产品团队商榷后确定。

未将所有“已知工作”都纳入考虑范围，仅考虑到了有趣的那些

A：“这个功能多久能交付？”

B：“两周。”

【两周后】

A：“怎么没完工？”

B：“额，技术上来说已经完工，我们现在在测试，要给它新建一个部署机制，会先发布一个beta版。另外上周我休假了。”

在设定这个deadline时，相关人员对要完成的工作以及要投入的时间缺乏完整的理解，更别提该案例中B也出现了上面第三条的问题。

在设定deadline时，我们应当确保将所有已知的挑战都涵盖在内，是否会因某个已知原因而浪费一些时间，比如说度假、公司断网、因为生日派对宿醉而迟到？

另外我们是否可能遗忘了某些不起眼的任务？这个项目打算写多少测试？如何将这玩意儿发布到生产环境中？跟着这些问题放慢脚步，仔细思考下整个过程以及可用的资源。这样做会让设定deadline简单得多，同时这样设定出的deadline也更经得起考验。

关于评估：令人不适，但却是必要的

工程师所设定的deadline很大程度上是通过评估形成的，也就是说团队中的每个人都要习惯犯错，犯很多错——将自己知道不对或是没信息的地方说出来，可能会很困难。

我们必须达成共识，尽可能准确地作出评估，并随着时间评估地越来越准确。评估是一项技能，反复使用会熟能生巧。初期可能会让人不适，但这是我们需要做到的。

评估任务

在定下大型项目的交付时间前，我们应当将整个项目拆分成小的任务，每个任务应当能在约五个工作日内完成。

以下问题对评估任务十分有用：

这个项目是新建的，还是之前就有的？

这部分代码质量如何？

我对这部分代码的熟悉程度如何？

对涉及的编程语言熟悉程度如何？

与其他代码段在哪里有接触或集成点？

现有的测试覆盖率如何？

这项工作是否涉及关键业务（写入路径、计费、负载均衡器、注册）？

之前是否有人参与过这项工作？他们有何想法？

有哪些问题需要做出权衡？

这项任务的目标是什么？

这项任务究竟是否需要完成？

评估工程项目

工程项目通常被视为一个较大的任务，可以让多人并行完成。

下面这些问题有助于评估项目：

我们实际要在这个项目上花费多久时间？

这个工程项目的目标是什么？

是否有已知会安排的休息时间？

所有要完成的任务有哪些？

是否对其他团队有依赖，还是障碍性的？

项目中是否有任务对其它任务产生障碍？

该项目是否需要新的基础设施或硬件？

该项目的完工标准是什么？

完工标准

即便要知道某项工作是否完工都是很困难的，团队中不同角色可能会有不同的“完工”标准，因此我们需要指定某个项目的具体完工标准。

下面是典型完工标准的一些样例：

部署到生产环境；

全自动化测试；

与公司内部或第三方人员沟通；

在公司内部或外部进行了一定量的测试；

为生产环境编制文档；

完成对销售或推广团队的讲解；

发布登录页面；

分析并追踪；

操作运行手册与系统可观测性。

总结

随着公司的壮大与管理能力日趋成熟，交付能力成为必须，而deadline是其中主要的工具之一，合理善用将有无与伦比的功效。不过，想要利用deadline，还需时日在实践中慢慢磨合。因此我建议：工程类公司应当将其视为一个活生生、有生命力的东西，不间断地去学习了解，并通过文档在全公司内部，乃至与整个行业分享经验。