6.1 敏捷的流程
①敏捷開發原則：
（1）盡早並持續地交付有價值的軟體以滿足顧客需求
（2）敏捷流程歡迎需求的變化，並利用這些變化來提高使用者的競爭優勢
（3）經常發布可用的軟體，發布間隔可以從幾周到幾個月，能短則短
（4）業務人員和開發人員在專案開發過程中應該每天共同工作
（5）以有進取心的人為專案核心，充分支援信任他們
（6）無論團隊內外，面對面的交流始終是最有效的溝通方式
（7）可用的軟體是衡量專案進展的主要指標
（8）敏捷流程應能保持可持續的發展。領導、團隊和使用者應該能按照目前的步調持續合作下去
（9）只有不斷關注技術和設計，才能越來越敏捷
（10）保持簡明——盡可能簡化工作量的技藝
（11）只有能自我管理的團隊才能創造優秀的架構、需求和設計
（12）時時總結如何提高團隊效率並付諸行動
②敏捷流程概述：找出完成產品需要做的事情→決定當前的衝刺（sprint）需要解決的事情→衝刺（衝刺期間每天開每日例會）→得到軟體的乙個增量版本並發布
6.3 敏捷的團隊
自主管理：自己挑選任務、自己提出改進並實施改進
自我組織：每個人聯合起來對專案負責
多功能型：每個人都全面負責，自己搞定規格說明書，和別人溝通，自己搞定測試
6.4 敏捷總結
在迭代開始時，團隊審視擺在他們面前的任務，選擇他們認為可以在迭代期間完成的那些任務（plan）。然後團隊獨立地盡最大努力完成這些任務（do）。在迭代結束時，團隊給利益關係人展示成果（check），並對開發流程進行調整（act/adjust）。
這裡有一些實踐者的經驗教訓：
（1）敏捷宣言表明的是一些優先順序，不必當作聖旨或者教條來爭論。
（2）scrum master不是乙個官，而是乙個沒有行政權力的溝通者，就像微軟的pm那樣。他/她同時還要在團隊中做具體的工作。直接把原來的「經理」變成scrum master，大多行不通。
（3）一些專案需要很多暗箱操作和政治角力才能搞定，scrum會把這些矛盾都擺到明處。這有好處，也有風險。
（4）在複雜的專案裡，要讓一線團隊成員做決定。
（5）創業公司的團隊其實經常是執行在scrum 的模式中（只不過大家太忙，沒工夫論證自己到底有多麼scrum）。
（6）在scrum計畫階段的估計不是乙個「合同」，領導們不要把它當成乙個合同。估計總是不准的。堅持短期的sprint，這樣即使不准的估計也不會有大的損害。
（7）不要和管理層談「流程」，他們只關心「結果」。
（8）在大型團隊、跨地區的團隊，或者複雜專案中，scrum並沒有非常完美的答案，scrum的創始人也承認這一點.
微軟公司中關於軟體開發的思想和宣言有乙個方**——微軟解決方案框架（microsoft solution framework，msf），也就是微軟推薦的軟體開發方法
7.2 msf基本原則
1. 推動資訊共享與溝通（foster open communications）
2. 為共同的遠景而工作（work toward a shared vision）
「共同的遠景」是指產品的遠景。我們做乙個產品，不管是應用軟體、行業軟體，還是通用軟體，要明確專案的目標是什麼。
3. 充分授權和信任（empower team members）
這一點的關鍵是「授權」這個詞，授權（empower）有兩個意思：
充分授權的管理方式是msf的核心觀念之一。msf團隊模型就是建立在以下兩個原則上的：
這就是為什麼msf團隊模型是網狀，而不是層次結構。這樣做有什麼好處？好處有兩點：
4. 各司其職，對專案共同負責（establish clear accountability and shared responsibility）
在專案進展的過程中，對於每一項任務，每個人都要明確以下幾點。
與「資訊共享與溝通」原則相呼應，這樣的安排能讓所有人都明確自己的職責，同時有「大局觀」—知道別人在做什麼，為什麼，以及整個專案的目標
5. 交付增量的價值（deliver incremental value）
現在的軟體產業，特別是和網際網路相關的產業，變化非常快，使用者希望產品團隊經常提供更新，以適應新的需求。我們要保證在兩個方面保證客戶的利益：
6. 保持敏捷，預期和適應變化（stay agile, expect and adapt change）
軟體工程，唯一不變的是變化。所以乾脆別幻想客戶的需求會在第一時刻很明確，然後保持不會變。要注意，我們是預期變化，不是期望變化
除開外部原因，團隊內部也在變化，我們對技術的掌握每天都在提高，原來認為不可能的事可能變得容易。我們對客觀世界和軟體系統的了解每天都在深化，原來覺得沒問題的小細節忽然成了大問題。甚至原來一起打拼的同事忽然要離開……這些都要求我們團隊保持敏捷的身段
7. 投資質量（invest in quality）
對質量的重視，引起對質量的投資，引起對人、過程和工具的投資。
8. 學習所有的經驗（learn from all experiences）
在學習過去的經驗的同時，也要避免讓過去的經驗妨礙解決現在的問題
這一原則有兩個含義——
msf在每乙個里程碑結束時都要做乙個「里程碑回顧」，這個回顧不必等到整個專案結束才做。這樣做的好處是，大家對最近的成敗都記憶猶新，能提供比較準確和全面的反饋；如果發現了錯誤，可以馬上研究解決辦法，在下乙個里程碑中通過實踐來驗證。另外，一些好的做法可以及時得到總結和推廣。
在專案結束時，msf推薦請團隊以外的專家來主持召開「事後諸葛亮」會，這樣的專家會比較系統地總結團隊的成功經驗和失敗教訓，同時也客觀評價團隊的一些特性和團隊的開發過程管理，這樣能促使團隊成員以客觀、向前看、解決問題的心態來參加「事後諸葛亮」會，避免主觀臆斷或相互指責。
9. 與顧客合作（partner with internal and external customers）
構建之法讀書筆記（三）
project manager 專案經理乙個神秘的角色，他就是夾在銷售人員與程式設計師之間的溝通媒介，銷售人員的方式程式設計師理解不了，程式設計師只想安安靜靜的敲 因此就出現乙個角色 專案經理，負責的就是將銷售人員的方式轉換為程式設計師可以理解的形式，這樣開發的效率就會大大的提高，同時專案經理不僅僅...
《構建之法》讀書筆記（三）
構建之法 讀這本書教會了我在團隊開發時的團隊合作。首先是 規範 1.風格規範。2.設計規範。一.風格規範 1.縮排 一般用四個空格的距離，從可讀性來說正好。2.行寬 行款可以限定為100字元。3.斷行與空白的 行 盡量 if a else 4.分行 不要把多條語句放在第一行。5.命名 在變數名中不要...
構建之法讀書筆記三
在做專案開發上，團隊協作尤為重要。之前也說過 需求分析 的問題，但在讀書過程中我發現了乙個問題，假如使用者方出現了需求更改，或者在原有的基礎上新增了乙個棘手的需求，導致工作變更怎麼辦？回答還是協商。坦白說看到現在我能用兩個詞概況軟體工程要幹的事情 開發與溝通。但要是跟使用者協商溝通，雖然能達到乙個妥...