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）
構建之法讀書筆記
場景 故事 版權 版本 維護人 1.背景 a.典型使用者 姓名 性別 年齡 職業等 b.使用者需求 痛點 c.假設 2.場景 關於這個場景的文字描述角色 與軟體互動的角色，如使用者等其他實體，甚至時間 主要成功場景 一系列步驟 步驟 描述每一步的互動 擴充套件場景 描述一些意外情況 軟體功能說明書 ...
《構建之法》讀書筆記
乙個軟體除了穩定 功能強大，使用者體驗也很重要。程式開發人員和測試人員在強調其功能和效能的同時，還有一點很注重的就是使用者體驗。在我們學習的最初階段老師們就強調對於軟體開發來說使用者體驗的重要性，無論軟體還是硬體，都有很多功能部件，各個部件還要郵寄的結合起來，才能滿足使用者的需求。其中有一點特別，就...
構建之法讀書筆記
在上一次，我讀了大道至簡，在大道至簡中，我理解了軟體開發所需要的是簡化與便捷，這是軟體工程需要思考的地方。而在構建之法中，我學到了軟體開發中更符合我的問題的東西。書中說，軟體工程師的成長分為四個階段 玩具時期，愛好者時期，探索者時期，行業時期。在這四個時期中，我處於玩具時期。還沒有掌握最基本的東西。...