敏捷是一種很“年輕態”的思路/策略，是以“萬事萬物都在不停地發展變化”為指導去組織軟件工程的需求分析、內部的調和、代碼編寫甚至維護，所以我讀起來會覺得很有共鳴。然而並不是所有的地方都適合讓“敏捷”去闖一闖。

1.敏捷開發原則

【適應瞬息萬變的形式，力求在大潮中可持續發展；年輕態】

【個人進行了分析組合】 1. 可用的、盡早交付的軟件是項目進展的主要指標 2. 保持可持續的發展，以需求作為發展優勢 3. 自我管理。無論是交流還是信任還是共同工作

2.敏捷流程

1. 找出product backlog【與之前的需求分析不同，這裏的backlog不是很“厚”】
2. 決定當前的sprint即sprint backlog【分解為16小時以下的backlog，團隊成員根據任務量和自身條件認領backlog】
3. sprint【每日一例會，各自匯報做了什麽，有什麽困難，下一步計劃】

另外，如何讓敏捷流程不流於形式？

• 定義好任務量。特別是“還剩多長時間”
• sprint的時候團隊保持高度運轉，不以外力作用而（暫時）停工或者受到其他影響
• sprint之後如果發現大問題，還要DCR（design change request）
• 任務都完成了不等於可以高枕無憂了。至少（往往）20%的測試任務要花掉80%的時間

3.關於敏捷的另外幾條神來之筆

1. 敏捷的團隊非常“自我”——自我管理、自我組織，好像非常易於變型的填充物，很多成員都可以有很多“功能”；
2. 不要和管理層談“過程”，他們只要結果【見人下菜】
3. 大多數被測試、被研究的新東西都很有效果。
   • 參考http://baike.baidu.com/link?url=beVwHx-Synb517sWsjPQ2bsHuzc5qCCX0QrSZ8Ow91TvoPEEEhES7R43S
     UI_ylpAKv0O5hBoWNwwePhGntQ05lTlqJtpZ7bdIBhSatWAXo-aZcVU8UM0qGoD1n3NruSxt-oMS41qOn9lQWSQBvhK
   • 很有意思的心理學實驗結論；似乎做表面文章的時候經常會和這個結論打交道。然而“任何刺激因素（如薪水）都不是非常有效的，因為它總有效用飽和的那一刻”
4. 我們需要敏捷（agile）的開發流程，而不是匆忙（rushed）或者忙亂（chaotic）的流程
5. 敏捷不是萬能，它只是能夠幫助你更早知道自己能否如期完成任務【因為產品會很早就迎來用戶“檢查”】

構建之法 第六章 敏捷流程