主要講述了」團隊與流程「與第二章的」個人技術流程「有關聯，」非團隊與團隊「」個人與團隊「團隊的模式相較於個人模式，團隊模式更多，更為複雜多樣化，也更具趣味性；
團隊1. 團隊有一致的集體目標，團隊要一起完成這目標。
2. 團隊成員有各自的分工，互相依賴合作，共同完成任務。
在團隊的合作中會出現很多的不一樣的相處模式，這需要根據自己的實力，跟團隊其他人的實力來定論；在每個模式中都會有不同的相處方式，只有找到適合自己團隊的相處方式，才會合作愉快，更加團結；其中包括：
1、主治醫師模式（有乙個核心人物，其他人各司其職，我個人觀點這是一種很舒服的相處方式，每個人都有每個人的任務，根據能力來決定工作）
2、明星模式(主治醫師模式運用到極點，可以蛻化為明星模式，在這裡，明星的光芒蓋過了團隊其他人的總和)
3、社群模式（每個人參與自己感興趣的專案，貢獻力量，大部分人不拿報酬）
4、業餘劇團模式（不同的人會挑選不同的角色，但是在下乙個專案的時候可能會挑選下乙個不一樣的角色，可以隨時的挑戰自己，但是可能也會有一定的風險，專案的完成率跟精準率同時會受到一定的影響）
5、秘密團隊（在秘密狀態下進行，別人不知道他們具體在做什麼，有好處是可以專心致志的完成專案，團隊成員有極大的投入）
6、**團隊（由一些有特殊技能的專業人士組成，負責解決一些棘手而有緊迫性的問題）
7、交響樂團模式（）
8、爵士樂模式
9、功能團隊模式（具備不同能力的同事們平等協作，共同完成乙個功能）
10、官僚模式
這種模式如果應用不好，最後會變成「老闆驅動」的開發流程
開發的流程：
寫了再改模式（這樣積累的錯誤會很多，然後會很亂）、瀑布模型，生魚片模型、等等
主要講述了敏捷流程（個人和交流、可用的軟體、與客戶合作、響應變化）及其原則（共12條）
第一步：找出完成產品需要做的事情backlog
第二步：決定當前的衝刺需要做的事情；
第三步：衝刺；
敏捷的團隊中主要包括1.自主管理 2.自我組織 3.多功能型三個方面還在敏捷流程中總結出了經驗教訓；如果在較複雜的專案中，要讓一致團隊成員做決定；
如果想要變成敏捷團隊需要做到以下幾點：1、自助管理2、自我組織3、多功能型
關於敏捷流程的經驗教訓也有進行總結：
1、敏捷宣言標明的是一些優先順序，不必當做聖旨；
2、一些專案需要很多暗箱操作和政治角力才能搞定，很多的問題直接擺在明面就可以；
3、在複雜的專案中，讓有能力的一線成員來決定；
4、不要與管理層談論流程，他們只關心結果；
敏捷的方法（迭代的方式）能幫你盡快讓使用者看到專案的部分價值。當你盡早交付部分價值時，也許使用者對你目前交付的東西已經很滿意了，這樣你就不用再花時間來實現其他需求。
msf原則：
1. 推動資訊共享與溝通
2. 為共同的遠景而工作
3. 充分授權和信任
4. 各司其職，對專案共同負責
5. 交付增量的價值
6. 保持敏捷，預期和適應變化
7. 投資質量
8. 學習所有的經驗
9. 與顧客合作
msf團隊模型：
在團隊模型中定義了小組成員的角色跟職責：
任何技術專案都必須達到特定的關鍵質量目標，才能夠被認為是成功的專案。任何乙個角色無法實現其目標，都將危及整個專案；
更急強調與使用者之間的交流；保障其中的質量（質量不過關，每個人都有責任）；
構建之法閱讀筆記03
通過這幾天的閱讀，基本對本書又有了新的認識，讀完這本書是一回事，要想深入的理解又是另一回事。本書第一版出自2014年，當時軟體工程正在中國蓬勃發展，在此書出來之前大學裡的教材有些還是外國書籍的翻譯版本。豆瓣上對此書的介紹是 軟體工程牽涉的範圍很廣,同時也是一般院校的同學反映比較空洞乏味的課程。但是軟...
構建之法閱讀筆記03
今天自己又回過頭來詳細的閱讀了一遍 構建之法 的第二章，下面分享一下自己的體會。一.單元測試 之前自己在程式設計的過程中，從來沒有對自己的程式進行過單元測試，總覺得輸出了題目要求的結果就行了，沒有考慮過程式執行的中間過程或是對占有的記憶體進行釋放等問題。而書中詳細介紹了單元測試的重要性和如何進行單元...
構建之法閱讀筆記03
又到了一周的結尾，時間過得真快。這一周，閱讀了 構建之法 關於團隊和流程的部分。正好，這周我們用的就是結對開發的模式。算是理論加上實踐吧。和以往的單獨程式設計不同的是，團隊開發增加了與同學的交流討論，在問題的解決與實現方面不再是一人單扛，可以交換不同的思路，用不同的角度思考問題，把問題更好的解決。這...