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