現在已經讀完這本書了，感覺自己又充實了。
首先了解了敏捷開發的基本原則：
1.盡早並持續地交付有價值的軟體以滿足顧客需求。
2.歡迎需求的變化
3.經常發布可用的軟體，間隔時間盡可能的短
4.團隊每天共同工作
5.以有進取心的人為專案核心
6.面對面的交流
7.發布可用的軟體
8.領導、團隊和使用者應該能按照目前的步調持續合作下去
9.不斷關注技術和設計
10.盡可能的簡化工作量
11.團隊每個成員都要有自我管理意識
12.善於總結
而所謂敏捷也就是快，但是在敏捷開發中，千萬不要把快作為唯一的指標，而敏捷開發的原則也只是作為參考，建議，肯定是不能套著他來的，要懂得變通，結合自己的團隊和實際的專案情況來做出調整。
1. 推動資訊共享與溝通
2. 為共同的遠景而工作
3. 充分授權和信任
4. 各司其職，對專案共同負責
5. 交付增量的價值
6. 保持敏捷，預期和適應變化
7. 投資質量
8. 學習所有的經驗
9. 與顧客合作
msf敏捷開發模式吸收了近幾年來在軟體業界流行的各種「敏捷」開發模式的優點，認識到目前大部分軟體是以網路應用相聯絡的，強調和使用者更緊密地交流，快速迭代，避免不必要的過程。在這樣乙個開發模式下，質量被放在了首位，防止缺陷發生成為了團隊質量控制的首要任務。只有把可能的缺陷扼殺在設計階段，並將其在**中避免，才能減少在案的缺陷記錄，提高軟體的質量。
軟體的需求是本書中最後提到的內容，其實在我感覺，需求分析才是軟體設計與開發的重中之重。畢竟只有了解社會需要什麼、使用者需要什麼樣的軟體。我們做出來的產品才有人使用。在需求分析的過程中，一定要充分考慮到使用者的需要，使用者期望中產品的功能，產品的開發過程的需求以及一些其他可能涉及到的方面，有了這樣乙個系統的分析，軟體的開發目標才更加的明確，軟體的價值也能夠更好的體現。
但我們現在做的軟體，就不太好，沒有照顧到使用者的需求，（只是自己根據調查，得出的使用者需求），這也是現階段需要改進的
構建之法讀書筆記（三）
project manager 專案經理乙個神秘的角色，他就是夾在銷售人員與程式設計師之間的溝通媒介，銷售人員的方式程式設計師理解不了，程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理，負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式，這樣開發的效率就會大大的提高，同時專案經理不僅僅...
《構建之法》讀書筆記（三）
構建之法 讀這本書教會了我在團隊開發時的團隊合作。首先是 規範 1.風格規範。2.設計規範。一.風格規範 1.縮排 一般用四個空格的距離，從可讀性來說正好。2.行寬 行款可以限定為100字元。3.斷行與空白的 行 盡量 if a else 4.分行 不要把多條語句放在第一行。5.命名 在變數名中不要...
構建之法讀書筆記三
在做專案開發上，團隊協作尤為重要。之前也說過 需求分析 的問題，但在讀書過程中我發現了乙個問題，假如使用者方出現了需求更改，或者在原有的基礎上新增了乙個棘手的需求，導致工作變更怎麼辦？回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情 開發與溝通。但要是跟使用者協商溝通，雖然能達到乙個妥...