《快速軟體開發》讀書心得

這本書在豆瓣上的評分很高，評價也很好，經過各種糾結，最終決定讀這本書，雖然這本書最厚。

這本書基本上是從一個管理員的角度去寫的，但是沒有把視角限定在某一個固定的管理職位上，也就意味著這本書不討論具體的做法。

我主要發現了下面幾個問題：

1. 風險管理

做什麼事都有風險，做任何決策也都有風險，軟體開發也不例外。軟體工程是一個很複雜的過程，其中的“風險”很難量化評估和控制。即使很難量化和控制也要儘可能準確的評估，並且有效控制，否則一個一個軟體項目幾乎不可能成功。常見的風險識別方法是進度計劃風險，在風險分析的過程中要顧及損失的大小，評估損失發生的機率。而且不同的風險有不同的優先順序，通過監控來避免並且化解風險。風險管理這個名詞我第一次接觸，我們組的team project也沒有涉及風險管理，所以不太熟悉。

2. 激勵機制

激勵機制實在是太重要了！在team project中我是PM，如何激勵大家開心高效的寫代碼讓我費了不少腦筋。書中提到了最重要的5個激勵因素：成就感，發展機遇，工作樂趣，個人生活，成為技術主管的機會。感覺這五個激勵因素離我們都還很遠，太專業了，我們還是學生，似乎在一起多吃吃飯更有效果。。。在飯桌上大家都混得非常熟，很多問題都在飯桌上解決了，反正大家都是要吃飯的，還不如組裡的同學一起吃。另一點就是鼓勵大家分享，因為我們組各位同學的任務都差不多，幾乎是平行的，所以一個人遇到的問題，其他人也會遇到。當一個人解決了一個技術難題之後，我們鼓勵他把方法分享出來，這在某種程度上也激發了大家的開發熱情。

3. 面向客戶的開發

這一點我感觸比較深。書中提到了客戶對於快速開發的重要性，它可以提高效率，減少返工，降低風險，消除矛盾。在具體實踐中，我們也深深體會到了客戶的重要性，因為無論如何，你的軟體最終是要給客戶用的。我們腦子中所設想的使用者通常和真正的使用者有很大區別。很多我們希望實現的feature對於使用者而言根本就沒有用。比如說，我們最開始準備支援建立活動，後來發現如果一個使用者想要建立一個活動，他根本不會在手機上這麼做，這麼複雜的動作他必然會在電腦上完成。況且實現這個feature需要花不少時間，基本不會有人用，最終我們決定不做這個feature了。

4. 團隊結構

團隊結構這個問題又是涉及到人的問題，又是一個很複雜的問題。書中提到了很多很有意思的團隊模型，比如“戲劇團隊”，“搜尋救援團隊”，“專業運動員團隊”，“主程式員團隊”等等。專業的團隊結構必然要分工明確，溝通暢通無阻。說實話，我們team的團隊結構有很多問題，比如我們沒有學設計的同學，做出來的東西很難看，我們沒有設專門的測試人員，每個人都開發，每個人也都測試，我們的PM也要寫代碼(PM比較喜歡寫代碼)，這些問題在專業團隊中都是要盡量避免的。

5. 為什麼叫做“快速軟體開發”

書中第一章專門介紹了什麼叫“快速”，並且給出了很多建議。然而單單快速就可以了嗎？顯然不是，書中的第二部分介紹的就是有效開發，可見快速不是以犧牲品質為前提的。在startup界有一個非常有名的說法，是“Iterate Fast and Release Often”，覺得很是贊同。需求在變，使用者在變，市場在變，如果不能做到快速，很快就會被淘汰。

陶宇