現有的做法vs. 敏捷的做法
現有的做法敏捷的做法
流程和工具
個人和交流
完備的文件
可用的軟體
為合同談判
與客戶合作
執行原定計畫
響應變化
1.盡早並持續地交付有價值的軟體以滿足顧客需求。2.敏捷流程歡迎需求的變化，並利用這種變化來提高使用者的競爭優勢
3.經常發布可用的軟體，發布間隔可以從幾周到幾個月，能短則短
4.業務人員和開發人員在專案開發過程中應該每天共同工作
5.以有進取心的人為專案核心，充分支援信任他們
6.無論團隊內外，面對面的交流始終是最有效的溝通方式
7.可用的軟體是衡量專案進展的主要指標
8.敏捷流程應能保持可持續的發展。領導、團隊和使用者應該能按照目前的步調持續合作下去
9.只有不斷關注技術和設計，才能越來越敏捷
10.保持簡明——盡可能簡化工作量的技藝——極為重要
11.只有能自我管理的團隊才能創造優秀的架構、需求和設計
12.時時總結如何提高團隊效率，並付諸行動
我們在這裡剖析scrum這個方**。
第一步：找出完成產品需要做的事情——product backlog
第二步：決定當前的衝刺（sprint）需要解決的事情——sprint backlog
第三步：衝刺（sprint）
第四步：得到軟體的乙個增量版本，發布給使用者。然後在此基礎上又進一步計畫增量的新功能和改進。
如果你的團隊很弱，那麼強行把敏捷（或者其他高階方法）套在上面也沒有用，也許還會適得其反，往往需要多次sprint才能讓scrum走上正軌。換句話說，如果你的團隊已經有這麼厲害（自我管理、自我組織、多功能型）的一幫人，那麼用不用scrum都能寫好軟體！
和質量控制理論的模型如經典的戴明環（pdca）相似。
六西格瑪理論中的也有相似的流程。
1.敏捷宣言表明的是一些優先順序，不必當作聖旨或者教條來爭論。2.scrum master不是乙個官，而是乙個沒有行政權力的溝通者，就像微軟的pm那樣。他/她同時還要在團隊中做具體的工作。直接把原來的「經理」變成scrum master，大多行不通。
3.一些專案需要很多暗箱操作和政治角力才能搞定，scrum會把這些矛盾都擺到明處。這有好處，也有風險。
4.在複雜的專案裡，讓一線團隊成員做決定。
5.創業公司的團隊其實經常是執行在scrum的模式中（只不過大家太忙，沒工夫論證自己到底有多麼scrum）
6.在scrum計畫階段的估計不是乙個「合同」，領導們不要把它當成乙個合同。估計總是不准的。堅持短期的sprint，這樣即使不准的估計也不會有大的損害。
7.不要和管理層談「流程」，他們只關心「結果」。
8.在大型團隊、跨地區的團隊，或者複雜專案中，scrum並沒有非常完美的答案，scrum的創始人也承認這一點。
《構建之法》讀書筆記第3章
第三章講的是軟體工程師的發展。主要從軟體工程師的評價方法，團隊期望和技能的反面進行闡述，並對應的分為3個小節。在第一小節中講的是個人能力的衡量與發展。對於初級軟體工程師的成長，從以下5個方面開始 積累軟體開發相關的知識，提公升技術技能 積累問題領域的知識和經驗 例如 對醫療或金融行業的了解 對通用的...
《構建之法》讀書筆記第1 2章
之前因為助教工作閱讀過一遍 構建之法 現在回頭重新翻看這本書，越發覺得這本書值得深入閱讀。本週先將前兩周的讀書筆記記錄如下 第一章從淺入深，以航空業的發展歷程作為模型，模擬軟體工程的發展。玩具 紙飛機 業餘愛好 沙灘椅 氦氣球 探索 萊特兄弟 產業 容納百萬人就業的航空業。類似的，軟體也從簡單的 h...
構建之法第4 17章讀書筆記
第四章 兩人合作 問題1 4.2中注釋這一版塊，因為之前有學長跟我強調過 規範的問題，所以對這方面比較重視，後來當使用每個ide的時候，都會去注意 縮排的快捷鍵，比如idea的ctrl alt l等等 我對自己寫的 還算比較滿意，但是在注釋這一塊確毫無頭緒，不知道什麼是標準，以前看過標準的注釋，記得...