返回 登录
0

软件开发中的deadline该怎么定

原文: How should deadlines be used in software engineering?
作者: Ryan Spraetz
翻译: 孙薇
责编: 钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008申请入群,备注姓名+公司+职位。

图片描述

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

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

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

问题及解决方案

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

1)对deadline的理解因人而异

A:“下周才是deadline,我还有大把的闲余时间!”
B:“为什么要担心这个?没关系的,deadline什么的当不得真。”
A:“但我不想被炒鱿鱼啊!”

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

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

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

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

A:“嘿,我们得完成这项工作【插入一个真的非常难的未知项目】,什么时候能干完?”
B:【快速搜了一下到底是什么工作】“额,我不确定。”
A:“我需要一个确切的deadline。”
B:“三,呃四个……月嗯周……月吧,四个月!”
A:“好极了,到时候见。”

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

3)deadline更新频度不够

A:“这个项目要在5天内完成,目前进度ok吗?”
B:“有一点落后,不过不要紧,我们会按期完工的。”
A:“好极了!”
【4天23小时后】
A:“再检查一下项目,准备好发布了吗?”
B:“额,还没,出了点问题,目测还得一个礼拜。”
A:“$%@!*”

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

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

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

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

A:“这个功能多久能交付?”
B:“两周。”
【两周后】
A:“怎么没完工?”
B:“额,技术上来说已经完工,我们现在在测试,要给它新建一个部署机制,会先发布一个beta版。另外上周我休假了。”

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

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

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

关于评估:令人不适,但却是必要的

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

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

评估任务

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

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

  • 这个项目是新建的,还是之前就有的?
  • 这部分代码质量如何?
  • 我对这部分代码的熟悉程度如何?
  • 对涉及的编程语言熟悉程度如何?
  • 与其他代码段在哪里有接触或集成点?
  • 现有的测试覆盖率如何?
  • 这项工作是否涉及关键业务(写入路径、计费、负载均衡器、注册)?
  • 之前是否有人参与过这项工作?他们有何想法?
  • 有哪些问题需要做出权衡?
  • 这项任务的目标是什么?
  • 这项任务究竟是否需要完成?

评估工程项目

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

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

  • 我们实际要在这个项目上花费多久时间?
  • 这个工程项目的目标是什么?
  • 是否有已知会安排的休息时间?
  • 所有要完成的任务有哪些?
  • 是否对其他团队有依赖,还是障碍性的?
  • 项目中是否有任务对其它任务产生障碍?
  • 该项目是否需要新的基础设施或硬件?
  • 该项目的完工标准是什么?

完工标准

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

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

  • 部署到生产环境;
  • 全自动化测试;
  • 与公司内部或第三方人员沟通;
  • 在公司内部或外部进行了一定量的测试;
  • 为生产环境编制文档;
  • 完成对销售或推广团队的讲解;
  • 发布登录页面;
  • 分析并追踪;
  • 操作运行手册与系统可观测性。

总结

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

评论