這本書在豆瓣上的評分很高，評價也很好，經過各種糾結，最終決定讀這本書，雖然這本書最厚。
這本書基本上是從乙個管理人員的角度去寫的，但是沒有把視角限定在某乙個固定的管理職位上，也就意味著這本書不討論具體的做法。
我主要發現了下面幾個問題：
1. 風險管理
做什麼事都有風險，做任何決策也都有風險，軟體開發也不例外。軟體工程是乙個很複雜的過程，其中的「風險」很難量化評估和控制。即使很難量化和控制也要盡可能準確的評估，並且有效的控制，否則乙個乙個軟體專案幾乎不可能成功。常見的風險識別方法是進度計畫風險，在風險分析的過程中要顧及損失的大小，評估損失發生的概率。而且不同的風險有不同的優先順序，通過監控來避免並且化解風險。風險管理這個名詞我第一次接觸，我們組的team project也沒有涉及風險管理，所以不太熟悉。2. 激勵機制
激勵機制實在是太重要了！在team project中我是pm，如何激勵大家開心高效的寫**讓我費了不少腦筋。書中提到了最重要的5個激勵因素：成就感，發展機遇，工作樂趣，個人生活，成為技術主管的機會。感覺這五個激勵因素離我們都還很遠，太專業了，我們還是學生，似乎在一起多吃吃飯更有效果。。。在飯桌上大家都混得非常熟，很多問題都在飯桌上解決了，反正大家都是要吃飯的，還不如組裡的同學一起吃。另一點就是鼓勵大家分享，因為我們組各位同學的任務都差不多，幾乎是平行的，所以乙個人遇到的問題，其他人也會遇到。當乙個人解決了乙個技術難題之後，我們鼓勵他把方法分享出來，這在某種程度上也激發了大家的開發熱情。3. 面向客戶的開發
這一點我感觸比較深。書中提到了客戶對於快速開發的重要性，它可以提高效率，減少返工，降低風險，消除矛盾。在具體實踐中，我們也深深體會到了客戶的重要性，因為無論如何，你的軟體最終是要給客戶用的。我們腦子中所設想的使用者通常和真正的使用者有很大區別。很多我們希望實現的feature對於使用者而言根本就沒有用。比如說，我們最開始準備支援建立活動，後來發現如果乙個使用者想要建立乙個活動，他根本不會在手機上這麼做，這麼複雜的動作他必然會在電腦上完成。況且實現這個feature需要花不少時間，基本不會有人用，最終我們決定不做這個feature了。4. 團隊結構
團隊結構這個問題又是涉及到人的問題，又是乙個很複雜的問題。書中提到了很多很有意思的團隊模型，比如「戲劇團隊」，「搜尋救援團隊」，「專業運動員團隊」，「主程式設計師團隊」等等。專業的團隊結構必然要分工明確，溝通暢通無阻。說實話，我們team的團隊結構有很多問題，比如我們沒有學設計的同學，做出來的東西很難看，我們沒有設專門的測試人員，每個人都開發，每個人也都測試，我們的pm也要寫**(pm比較喜歡寫**)，這些問題在專業團隊中都是要盡量避免的。5. 為什麼叫做「快速軟體開發」
書中第一章專門介紹了什麼叫「快速」，並且給出了很多建議。然而單單快速就可以了嗎？顯然不是，書中的第二部分介紹的就是有效開發，可見快速不是以犧牲質量為前提的。在startup界有乙個非常有名的說法，是「iterate fast and release often」，覺得很是贊同。需求在變，使用者在變，市場在變，如果不能做到快速，很快就會被淘汰。陶宇
《快速軟體開發》讀書心得
這本書在豆瓣上的評分很高，評價也很好，經過各種糾結，最終決定讀這本書，雖然這本書最厚。這本書基本上是從乙個管理人員的角度去寫的，但是沒有把視角限定在某乙個固定的管理職位上，也就意味著這本書不討論具體的做法。我主要發現了下面幾個問題 1.風險管理 做什麼事都有風險，做任何決策也都有風險，軟體開發也不例...
軟體開發心得
在我剛開始學習程式設計的時候，就對乙個程式的實際落實性產生了更大的興趣，也就是能否落地，在大一上學期的c語言學習裡，我們詳細的學習了c語言的基礎知識，為下學期的c 學習中的軟體開發打好了基礎，在下學期開始學習物件導向的程式設計並嘗試進行軟體設計時，那種茫然瞬間湧上心頭，在此之前，我從未接觸過任何有關...
DSP軟體開發心得
如何學習一款dsp？了解dsp，重點是了解它的核心能力是什麼？它有哪些外設？它的外設都有提供哪些工作模式？系統工程師可以結合它的核心能力及外設提供什麼樣的功能來支援上層應用的實現。對，這也是我們拿到乙個專案後，對dsp進行選型的關鍵。回想之前我重點總是放在學習如果使用dsp的某個模組，如何通過操作暫...