話題緣起

01

今天在DevOps案例深度研究討論群里，群友們圍繞一種開發模式展開了討論：DDD（Deadline Driven Development），期限驅動開發，大家似乎更愿意將其翻譯成“上吊繩驅動開發”。

這種開發模式是說在接到新的需求后，給開發者脖子上加一根繩子，這根繩子會隨著時間收緊，如果規定時間內沒有完成開發任務，開發者會被“吊死”。

好嚇人，開發咋還有繩命危險了呢....麻麻，我要回家

下圖是中英文對照。

“我們一直在實踐中探尋更苦逼的軟件開發方法，持續加班的同時也幫助他人加班...” what!“幫助他人加班”這是什么神仙操作，這位翻譯同學你確定不是在逗我嗎？？

另外，群友針對價值觀有補充解釋：

• 預算內，挑戰預算內算優秀，帶buffer預算內算完成；

• 范圍內，實現關鍵需求算完成，實現所有需求算優秀；

• 預期內，計劃時間內完成為優，不影響業務實際使用時間為完成。

“DDD 上吊繩驅動開發”的優勢

02

雖然稱其為“上吊繩驅動開發”有一些戲謔的成分，但其中體現的是一種“倒排期”的開發方法，在項目管理中列出每一個開發任務必須要完成的時間節點，不影響下一個任務或其他協作人員的工作進度，“倒排期”開發在很多開發團隊中都有應用，其優勢就在于：

1、需要自上而下的目標拆解，將一個整體的指標拆解為具體可執行的工作任務，這很像OKR工作法中的工作拆解思路，這樣的好處在于每個人都很清晰自己當下要做什么，完成之后對下一個環節有什么影響，以及我們最終要做什么，工作目標就是達成這個可預期的工作結果，這會讓開發過程更加靠譜和高效。

2、明確的任務完成時間和任務內容，讓每個人都有清晰的工作目標，在敏捷工作法里，我們通常會用看板的方式來跟進關鍵工作的進度，盡管在工作過程中有些需求會發生變動，但大家保持一個高頻的溝通會進一步降低項目風險。

3、有了明確的死線，或者說上吊繩勒緊的時間以后，大家會更加專注，更少去響應一些無關的或非重要不緊急的需求，這會讓每一個執行人員專注于手中的任務，而不會有過多的想法導致整個項目進度變得拖沓。

如何做到“DDD上吊繩驅動開發”

03

假如我們要在團隊中去執行上吊繩驅動開發的方法，也就是給每一個任務確定一個完成的死線，需要做好什么前提呢？

我們認為會有3個關鍵點：

首先，根據目標和預算做清晰的任務拆解。這里包含3個步驟，

• 一是對最終目標有一個清晰的認識，團隊內通過頭腦風暴的形式達成共識；

• 二是做好需求管理和排序，砍掉不必要的需求保留關鍵需求，同時對每個階段需要實現的需求做梳理；

• 三是確定需求完成的先后順序，根據整體項目交付時間倒推做各任務的時間排序。

一個項目通常會涉及到多個主線，梳理清楚每個線程間的協作關系和流程，同時使用敏捷小組的工作方式和目標拆解思路來保證任務的清晰、準確以及協作上的高效。

其次，及時溝通項目過程中的問題，始終保持最小化可交付的理念去推進。在任務執行和推進的過程中，常常會產生一些意外情況影響項目進度，基層人員有可能會把這個事情想得特別復雜，那么作為推進者就需要保持冷靜思考，時刻以最小化可交付和最小化實驗驗證的理念來推進工作，避免產生甚至去滿足無效需求。

第三，任務安排要分為低頭看和抬頭看2個階段。低頭看階段是一個新項目的初始期，這是一個摸著石頭過河的階段，通向對岸的路有很多，但你不知道你選擇的那個上岸的點一定會有石頭讓你踩，這個階段要算清楚我們有什么，我們能做什么，盡快嘗試去往前走一步。

到了下一個階段就需要抬頭看，知道了哪條路有石頭可以踩以后，就要找到一個最佳的上岸地點，排兵布陣地走過去，達到目標。

第三點在拆解任務和做任務排序時，兩個階段都要快，但不能亂，否則可能導致項目過程中出現很多無法實現或者無效的工作，浪費死線內的時間。

總結

04

驅動開發工作效率提升的方法有很多，除了今天討論的DDD（上吊繩驅動開發），還有PDD（屁股驅動開發），TDD（踢人驅動開發），TPDD（踢人屁股驅動開發）MDD（罵人驅動開發）BDD（嗶嗶驅動開發）...你認為哪一種驅動開發的方式更高效呢？去留言區寫下你的看法吧~

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結

以上是生活随笔為你收集整理的DDD“上吊绳驱动开发”，开发要想不被“吊死”，该如何自救？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。