共计 1671 个字符，预计需要花费 5 分钟才能阅读完成。
话题缘起
明天在 DevOps 案例深度钻研探讨群里，群友们围绕一种开发模式开展了探讨：DDD（Deadline Driven Development），期限驱动开发 ，大家仿佛更违心将其翻译成 “上吊绳驱动开发”。
这种开发模式是说在接到新的需要后，给开发者脖子上加一根绳子，这根绳子会随着工夫收紧，如果规定工夫内没有实现开发工作，开发者会被“吊死”。
好吓人，开发咋还有绳命危险了呢 …. 麻麻，我要回家!
下图是中英文对照。
“咱们始终在实践中探寻更苦逼的软件开发办法，继续加班的同时也帮忙别人加班 …”what!“帮忙别人加班”这是什么神仙操作，这位翻译同学你!
另外，群友针对价值观有补充解释：
- 预算内，挑战预算内算优良，带 buffer 预算内算实现；
- 范畴内，实现要害需要算实现，实现所有需要算优良；
- 预期内，打算工夫内实现为优，不影响业务理论应用工夫为实现。
“DDD 上吊绳驱动开发”的劣势
尽管称其为“上吊绳驱动开发”有一些戏谑的成分，但其中体现的是一种“倒排期”的开发方法，在项目管理中列出每一个开发工作必须要实现的工夫节点，不影响下一个工作或其余合作人员的工作进度，“倒排期”开发在很多开发团队中都有利用， 其劣势就在于：
1、须要自上而下的指标拆解，将一个整体的指标拆解为具体可执行的工作工作， 这很像 OKR 工作法中的工作拆解思路，这样的益处在于每个人都很清晰本人当下要做什么，实现之后对下一个环节有什么影响，以及咱们最终要做什么，工作指标就是达成这个可预期的工作后果，这会让开发过程更加靠谱和高效。
2、明确的工作实现工夫和工作内容，让每个人都有清晰的工作指标 ，在麻利工作法里，咱们通常会用看板的形式来跟进要害工作的进度，只管在工作过程中有些需要会产生变动，但大家放弃一个高频的沟通会进一步升高项目风险。
3、有了明确的死线 ，或者说上吊绳勒紧的工夫当前，大家会更加专一，更少去响应一些无关的或非重要不紧急的需要，这会让每一个执行人员专一于手中的工作，而不会有过多的想法导致整个我的项目进度变得拖沓。
如何做到“DDD 上吊绳驱动开发”
如果咱们要在团队中去执行上吊绳驱动开发的办法，也就是给每一个工作确定一个实现的死线， 须要做好什么前提呢？
咱们认为会有 3 个关键点：
首先，依据指标和估算做清晰的工作拆解。 这里蕴含 3 个步骤，
- 一是对最终目标有一个清晰的意识，团队内通过头脑风暴的模式达成共识；
- 二是做好需要治理和排序，砍掉不必要的需要保留要害需要，同时对每个阶段须要实现的需要做梳理；
- 三是确定需要实现的先后顺序，依据整体我的项目交付工夫倒推做各工作的工夫排序。
一个我的项目通常会波及到多个主线，梳理分明每个线程间的协作关系和流程，同时应用麻利小组的工作形式和指标拆解思路来保障工作的清晰、精确以及合作上的高效。
其次，及时沟通我的项目过程中的问题，始终保持最小化可交付的理念去推动。 在工作执行和推动的过程中，经常会产生一些意外状况影响我的项目进度，基层人员有可能会把这个事件想得特地简单，那么作为推进者就须要放弃沉着思考，时刻以最小化可交付和最小化试验验证的理念来推动工作，防止产生甚至去满足有效需要。
第三，工作安顿要分为抬头看和低头看 2 个阶段。 抬头看阶段是一个新我的项目的初始期，这是一个摸着石头过河的阶段，通向对岸的路有很多，但你不晓得你抉择的那个上岸的点肯定会有石头让你踩，这个阶段要算清楚咱们有什么，咱们能做什么，尽快尝试去往前走一步。
到了下一个阶段就须要低头看，晓得了哪条路有石头能够踩当前，就要找到一个最佳的上岸地点，排兵布阵地走过来，达到目标。
第三点在拆解工作和做工作排序时，两个阶段都要快，但不能乱，否则可能导致我的项目过程中呈现很多无奈实现或者有效的工作，节约死线内的工夫。
总结
驱动开发工作效率晋升的办法有很多，除了明天探讨的 DDD（上吊绳驱动开发），还有 PDD（屁股驱动开发），TDD（踢人驱动开发），TPDD（踢人屁股驱动开发）MDD（骂人驱动开发）BDD（哔哔驱动开发）… 你认为哪一种驱动开发的形式更高效呢？去留言区写下你的认识吧~
起源：IDCF 社区