The nature of software development 讀書心得

1. 軟件開發本質論
Presented by:
ACD_RD4
Duy

2. About the Author
Ron Jeffries (1939)
敏捷宣⾔言起草⼈人之⼀一
與Ken Beck, Ward CunningHam同為Extreme Programming作者之⼀一
著作
Ron E. Jeffries; Ann Anderson; Chet Hendrickson (October 2000).
Extreme Programming Installed. Addison-Wesley
Ron Jeffries (February 2004). Extreme Programming Adventures in C#
Ron Jeffries (February 2015). The Nature of Software Development:
Keep It Simple, Make It Valuable, Build It Piece by Piece

4. 軟件就像是熔岩
"The floor is lava" game
不接觸地板的前提，藉由物件(沙發，椅⼦子)
通到安全的廚房
踩到地板則發出淒厲哀嚎⽽而死
開發軟體的過程就如該遊戲

5. ⾃自然之路路
存在⼀一條不是由熔岩鋪成的綠⾊色之路路
了了解該道路路原則，減少踩到熔岩的頻率
過程總會偏離，但隨時提醒⾃自⼰己返回
軸⼼心: 尋找價值
Keep it simple, make it valuable, build it piece by
piece

6. 價值
價值: 我們想要的東⻄西
不限於客⼾戶要的東⻄西. ex. 優化項⽬目
當軟件被發布並且使⽤用才能產⽣生價值
現實: 無法⾺馬上創造⼼心中想要的⼀一切

7. 持續交付
⼤大部分user不會使⽤用全部的產品特性
儘早發布MMF (minimal marketable feature)
中途可以較⼩小的代價轉換⽅方向
價值最⼤大化: 持續交付⼩小的，以價值為中⼼心
的feature (20%時間創造80%價值)

8. 計畫
計畫本⾝身是無⽤用的，但計劃是必要的 (By 艾森豪)
詳盡的計畫是浪費時間
隨時掌握實際狀狀況，較能機動調整
任務分解
Project->Sprint(Weeks)->Feature (2-3 days)

9. 估算風險
估算想要精準，結果往往趨於保守
掌握實際情況比知道估算重要

10. 挑戰性⽬目標的危害
⿎鼓勵, 激勵團隊多完成其他特性
不⾃自覺趕⼯工->遺漏測試，代碼髒亂
壓⼒力力具有破壞性
思考過去的開發項⽬目中，壓⼒力力帶來來了了哪些
副作⽤用 ?

11. 堅實的基礎架構
基礎優先 or 功能優先 ?
兩兩者皆會在有限時間內減少推向市場的功能
對於每個功能，建構出最⼩小⽽而實⽤用的基礎，
推出最⼩小可⾏行行產品
在多次迭代中完善各項功能

12. 零缺陷的良好設計
缺陷使得項⽬目進展變得不明確
實際進度 < 表⾯面進度
阻礙⾼高效率開發
評估產品質量量變得困難
能⼒力力是基本要素

13. 測試
時間: 預防問題產⽣生 << 找出並解決問題
代碼測試 (unit test)與業務測試: 找出不同
細度的問題

14. 重構
設計會隨功能增長⽽而退化
改變設計時保持其良好狀狀態 (refactor)預留留
未來來變動空間
放任退化：輕則導致開發緩慢，重則導致
專案失敗

15. 五卡預測法
對⼤大規模的軟件進⾏行行時程預估
列列出3~5個最重要史詩級功能，⽤用⼀一句句話描述功能
並寫在卡片上
將史詩級卡片分解為3~5張更更⼩小卡片，重複該步
驟，直到每個卡片的功能時程預估在⼀一週以內
需注意該⽬目的為盡可能的預估時程，⽽而非⼀一味督
促員⼯工

16. 監督員⼯工更更加努⼒力力⼯工作
曾有⼀一位⾼高級管理理⼈人在被告知某個項⽬目的
進展速度比預期慢時，這樣回答：“看來來
我們只能督促員⼯工更更加努⼒力力⼯工作了了”.
作者認為：很難從管理理者⾝身上聽到比這更更
使⼈人反感的話了了，並且會適得其反

17. 監督員⼯工更更加努⼒力力⼯工作
當壓⼒力力很⼤大時，團隊會處於混亂中，並由於測試變少了了，軟件的
缺陷也就越來來越多，並有些難以發現的缺陷，降低可以交付的價值
當我去調查那些"想要更更多功能"的公司時，幾乎總會發現這些公司
不會說"不". 他們已經變成了了接單員，⽽而非決策者
⼀一種在無形之中給團隊的無形壓⼒力力，即是要求他們加快速度; 團隊
採取的對應措施則是以質量量換取速度
⾯面對壓⼒力力時，團隊可能有意識或無意識對承擔責任趨於保守，將
任務評估的更更⼤大或更更難．這會使⼈人覺得他們速度加快，實際並非如
此

18. 那麼，⾄至少可以根據速度
來來預測完成時間吧？
否 ! 最好的狀狀況為選擇在截⽌止時間時，確保完成最有價值的
功能項⽬目
確保團隊有具備能完成項⽬目的必備技能，且地須是全職的，
不可同時參參與多個項⽬目，盡可能讓所有團員在⼀一起⼯工作
真正能幫助⼯工作效率的是技能⽽而非督促努⼒力力⼯工作
請員⼯工利利⽤用個⼈人時間在晚上或週末學習，是否現實?是否能讓
提升能⼒力力更更為現實 ?
公司應盡可能提升員⼯工的素質