本周學習的是第六章——敏捷流程

在軟件工程的語境裏，“敏捷流程”是一系列價值觀和方法論的集合。從2001年開始，一些軟件界的專家開始倡導“敏捷”的價值觀和流程，他們肯定了流行做法的價值，但是強調敏捷的做法更能帶來價值。

現有的做法vs.敏捷的做法

現有的做法 敏捷的做法
流程和工具 個人和交流
完備的文檔 可用的軟件
為合同談判 與客戶合作
執行原定計劃 響應變化

1. 盡早並持續地交付有價值的軟件以滿足顧客需求
2. 敏捷流程歡迎需求的變化，並利用這種變化來提高用戶的競爭優勢
3. 經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短
4. 業務人員和開發人員在項目開發過程中應該每天共同工作
5. 以有進取心的人為項目核心，充分支持信任他們
6. 無論團隊內外，面對面的交流始終是最有效的溝通方式
7. 可用的軟件是衡量項目進展的主要指標
8. 敏捷流程應能保持可持續的發展。領導、團隊和用戶應該能按照目前的步調持續合作下去
9. 只有不斷關註技術和設計，才能越來越敏捷
10. 保持簡明—盡可能簡化工作量的技藝—極為重要
11. 只有能自我管理的團隊才能創造優秀的架構、需求和設計
12. 時時總結如何提高團隊效率，並付諸行動

敏捷的團隊

1. 自主管理：以前領導布置了任務，我們實現就可以了，現在要自己挑選任務；每次Sprint結束之後，還要總結不足，提出改進，並且自己要實施這些改進。“自主管理”不等於“沒有管理”。
2. 自我組織：以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對項目負責，有人工作落後了還要幫助他改進，項目缺少某類資源還要自己頂上去。
3. 多功能型：以前規格說明書由PM來寫，測試由測試人員來做，現在每個人都全面負責，自己搞定規格說明書，和別人溝通，同時自己搞定測試。

1. 敏捷宣言表明的是一些優先級，不必當作聖旨或者教條來爭論。
2. Scrum Master不是一個官，而是一個沒有行政權力的溝通者，就像微軟的PM那樣。他/她同時還要在團隊中做具體的工作。直接把原來的“經理”變成Scrum Master，大多行不通。
3. 一些項目需要很多暗箱操作和政治角力才能搞定，Scrum會把這些矛盾都擺到明處。這有好處，也有風險。
4. 在復雜的項目裏，要讓一線團隊成員做決定。
5. 創業公司的團隊其實經常是運行在Scrum 的模式中（只不過大家太忙，沒工夫論證自己到底有多麽Scrum）。
6. 在Scrum計劃階段的估計不是一個“合同”，領導們不要把它當成一個合同。估計總是不準的。堅持短期的Sprint，這樣即使不準的估計也不會有大的損害。
7. 不要和管理層談“流程”，他們只關心“結果”。
8. 在大型團隊、跨地區的團隊，或者復雜項目中，Scrum並沒有非常完美的答案，Scrum的創始人也承認這一點。

構建之法學習（6）