今天的主角是下面這張圖，它全景式展現了敏捷開發在不同粒度上的關注點。（看不清可以看***的Slideshare）

這張圖主體上是要給敏捷在不同粒度上下一個定義，并且告訴我們它的產出是“Working software”

從最內部的環開始看，什么是持續要做的呢？測試驅動開發（TDD），編譯構建，集成，代碼重構，協作開發，這些事情仿佛是心跳一樣，不僅不能停還要保持一定的節奏?！禖ontinuous Integration》一文對此做了很好的注解?！禖ontinuous Integration》源文檔 http://martinfowler.com/articles/continuousIntegration.html

外一層要描述的就是敏捷開發每天要做的事情了：站立會議和驗收測試。站立式會議在團隊范圍內實現信息共享，簡單，直接，有效。

較之每天的行為，一個粗粒度的概念就是迭代，我個人認為這里是最能體現敏捷精神的地方。我們先看一下迭代需要做的工作：檢查，回顧，制定迭代計劃。檢查是對已完成工作的質量保證的手段，回顧是對之前項目進行中的得失進行反思，而制定計劃是在一個有更多參考參數的情況下安排下一步工作?，F在敏捷社區在提倡“精益”思想，即根據歷史數據動態的調整優化。敏捷開發是一套活理論，不是一堆死方法，這一點我深信不疑。

發布處于迭代外層，可以看到這階段會制定發布計劃，梳理積壓未完成的事情，做出評估。

處于最外層的是策略層，這一層我們看到了目標、視角等等元素。雖然身處開發***線的我們往往感受不到這些東西的存在，但是這些方面如果沒有人考慮或者考慮錯了的影響遠大于一段糟糕的代碼。
 圓圈兩側我們可以看到敏捷開發的倡導的價值觀和代表了其可量化的指標。

從傳統的或者習慣的開發模型遷移到敏捷會有種種困難，需要有形式和行為上的真正變化。如果拋開這種想法呢，換一個角度呢？不搞大變革，大動作，我們能否從敏捷開發中取經來改善我們現有的情況呢？比如我們加快了構建的效率，我們堅持做代碼檢查和站立會議，見縫插針對糟糕的代碼進行重構… …實踐了這些之后或許我們還不是敏捷開發，但是我們已經擁有了“敏捷態度”。

總結

敏捷：不動搖，不懈怠，不折騰