DDD“上吊绳驱动开发”，开发要想不被“吊死”，该如何自救？| IDCF

话题缘起

今天在DevOps案例深度研究讨论群里，群友们围绕一种开发模式展开了讨论：DDD（Deadline Driven Development），期限驱动开发，大家似乎更愿意将其翻译成“上吊绳驱动开发”。

这种开发模式是说在接到新的需求后，给开发者脖子上加一根绳子，这根绳子会随着时间收紧，如果规定时间内没有完成开发任务，开发者会被“吊死”。

好吓人，开发咋还有绳命危险了呢....麻麻，我要回家!

下图是中英文对照。

“我们一直在实践中探寻更苦逼的软件开发方法，持续加班的同时也帮助他人加班...” what!“帮助他人加班”这是什么神仙操作，这位翻译同学你!

另外，群友针对价值观有补充解释：

• 预算内，挑战预算内算优秀，带buffer预算内算完成；
• 范围内，实现关键需求算完成，实现所有需求算优秀；
• 预期内，计划时间内完成为优，不影响业务实际使用时间为完成。

“DDD 上吊绳驱动开发”的优势

虽然称其为“上吊绳驱动开发”有一些戏谑的成分，但其中体现的是一种“倒排期”的开发方法，在项目管理中列出每一个开发任务必须要完成的时间节点，不影响下一个任务或其他协作人员的工作进度，“倒排期”开发在很多开发团队中都有应用，其优势就在于：

1、需要自上而下的目标拆解，将一个整体的指标拆解为具体可执行的工作任务，这很像OKR工作法中的工作拆解思路，这样的好处在于每个人都很清晰自己当下要做什么，完成之后对下一个环节有什么影响，以及我们最终要做什么，工作目标就是达成这个可预期的工作结果，这会让开发过程更加靠谱和高效。

2、明确的任务完成时间和任务内容，让每个人都有清晰的工作目标，在敏捷工作法里，我们通常会用看板的方式来跟进关键工作的进度，尽管在工作过程中有些需求会发生变动，但大家保持一个高频的沟通会进一步降低项目风险。

3、有了明确的死线，或者说上吊绳勒紧的时间以后，大家会更加专注，更少去响应一些无关的或非重要不紧急的需求，这会让每一个执行人员专注于手中的任务，而不会有过多的想法导致整个项目进度变得拖沓。

如何做到“DDD上吊绳驱动开发”

假如我们要在团队中去执行上吊绳驱动开发的方法，也就是给每一个任务确定一个完成的死线，需要做好什么前提呢？

我们认为会有3个关键点：

首先，根据目标和预算做清晰的任务拆解。这里包含3个步骤，

• 一是对最终目标有一个清晰的认识，团队内通过头脑风暴的形式达成共识；
• 二是做好需求管理和排序，砍掉不必要的需求保留关键需求，同时对每个阶段需要实现的需求做梳理；
• 三是确定需求完成的先后顺序，根据整体项目交付时间倒推做各任务的时间排序。

一个项目通常会涉及到多个主线，梳理清楚每个线程间的协作关系和流程，同时使用敏捷小组的工作方式和目标拆解思路来保证任务的清晰、准确以及协作上的高效。

其次，及时沟通项目过程中的问题，始终保持最小化可交付的理念去推进。在任务执行和推进的过程中，常常会产生一些意外情况影响项目进度，基层人员有可能会把这个事情想得特别复杂，那么作为推进者就需要保持冷静思考，时刻以最小化可交付和最小化实验验证的理念来推进工作，避免产生甚至去满足无效需求。

第三，任务安排要分为低头看和抬头看2个阶段。低头看阶段是一个新项目的初始期，这是一个摸着石头过河的阶段，通向对岸的路有很多，但你不知道你选择的那个上岸的点一定会有石头让你踩，这个阶段要算清楚我们有什么，我们能做什么，尽快尝试去往前走一步。

到了下一个阶段就需要抬头看，知道了哪条路有石头可以踩以后，就要找到一个最佳的上岸地点，排兵布阵地走过去，达到目标。

第三点在拆解任务和做任务排序时，两个阶段都要快，但不能乱，否则可能导致项目过程中出现很多无法实现或者无效的工作，浪费死线内的时间。

总结

驱动开发工作效率提升的方法有很多，除了今天讨论的DDD（上吊绳驱动开发），还有PDD（屁股驱动开发），TDD（踢人驱动开发），TPDD（踢人屁股驱动开发）MDD（骂人驱动开发）BDD（哔哔驱动开发）...你认为哪一种驱动开发的方式更高效呢？去留言区写下你的看法吧~

来源：IDCF社区