第六章 敏捷流程
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的創始人也承認這一點.
構建之法閱讀筆記之一
第一章 概論 這一章主要是講解了軟體工程的基礎知識 軟體 程式 軟體工程，並進一步的出擴充套件結論 軟體企業 軟體 商業模式。第二章 個人技術和流程 該章講解了個人開發，psp是每個軟工人都必須要掌握的個人開發流程，要學會對自己的 進行單元測試，學會效能分析 抽樣和 注入，掌握合適的效能分析工具。第...
構建之法閱讀筆記之一
在以前的我眼裡，所謂軟體，也不過只是複雜一點的程式罷了。直到今天，我才明白，軟體並不只是乙個複雜而又龐大的程式，軟體 程式 軟體工程。程式，僅僅只是一些 而軟體工程，包括許多。乙個複雜的軟體不但要有合理的軟體架構 軟體設計與實現，還要有各種檔案和資料來描述各個程式檔案之間的依賴關係 編譯引數 鏈結引...
構建之法閱讀筆記04
夢斷 01 人類文明執行於軟體之上。但是，軟體建立藝術卻隱於暗處，即便對於專家們也是如此。在歷史上，我們從未如此的完全依賴於這樣一種人類自己不知道怎麼樣做得好的產品。在對軟體系統的加速依賴和踱著步學習怎樣做好軟體之間，有一條巨大且有時叫人恐懼的壕溝。對軟體的依賴以指數級增長，而做軟體的技能 和應用技...