Week 2 《構建之法》讀書筆記

關於敏捷開發的二三感想。

本周因課程原因，並未急於對書目進行大量的閱讀。而集中精讀了該書敏捷過程一章，先將該章主要內容和個人感悟總結如下。

首先的問題就是，什麽是敏捷流程？就我個人粗淺的理解，該敏捷的說法是相對於傳統開發模式的“笨重”而言的。眾所周知，對於一個軟件開發項目，需要在開發前有詳盡的調研，再和客戶要求反復商討後得出詳盡的計劃書，後續所有的開發都需要嚴格的按照計劃書來執行。雖說整個流程顯得很嚴謹，但確實顯得有那麽一點點笨重。相反，敏捷流程則采取了與之完全相反的一條道路，簡單來說有如下兩條：

1. 盡早並且持續地交付軟件。並非傳統流程中的那樣在詳盡計劃中的一步到位，而是有點類似於得過且過的想法？先盡可能早的拿出一個有一定功能的軟件來，就像一個概念原型機一樣，也許會在後續的使用中出現一些問題，但至少還是能一定程度上去使用他了。接下來，最重要的就是持續的發布可用的軟件，簡單來說就是查缺補漏。對於出現的問題，步步跟進，並去解決它。

2. 與客戶的合作交流和新需求。傳統的開發中，客戶的需求在軟件開始開發前便被確定下來了，就在那一份可能來來回回扯皮了不知道多少個版本的計劃書中定好了。後期的一切工作都以計劃書為準。而敏捷開發則不同，它的開發十分歡迎新需求的提出。這往往能夠給開發人員帶來新的靈感，同時一個新的Backlog也是一個新的開始，對於充滿熱情的開發人員來說，這不僅不會讓他們惱怒，反而帶來新的挑戰和動力。

當詳細到具體的敏捷開發流程上來時，書中以Scrum方法論為例來講述。簡單來說，這樣一個流程就提出一個打得目標（Product Backlog），然後將其進一步細化，也就是拆分成更為詳細的任務（Sprint Backlog），最後就是去完成這些拆分好的小任務。為了確保完成人物的效率，書中又提出了每日例會（Scrum Meeting）和燃盡圖（Burn Down Chart），成員間每日去報告自己完成了什麽，將要去完成什麽，所剩的工作量也被標註在了燃盡圖上。

看似來說很簡單也很美好，但文中對其的幾個至關重要的問題提出了疑慮。個人認為最為重要的，就是如何去生成一份合理的Backlog。對於客戶需求來說，僅僅是一些簡單的自然化語言描述。如何將其轉化為一個合理的技術要求，再對其做出恰當合適的時間評估，這是個人認為在實際的敏捷開發中面臨的重大問題。在我們自己的團隊項目中，也暫定采取了敏捷開發流程，如何能夠將調研所得到的結果一步步剖析，最終拿出一份令人滿意的Burn Down Chart來，在我看來是小組所需面對的第一個難題，甚至對於沒有開發經驗的我們來說，要比後續的一些技術層面的問題還要難以去解決。

讀書筆記 2018-3-13