敏捷 vs 偽敏捷

　　敏捷 vs 偽敏捷

　　一個真正有效方法 vs 一個混亂的借口

　　你可能是偽敏捷：

　　抵觸所有的文檔，因為“敏捷不需要文檔”，也不需要需求文檔。

　　2周的沖刺(Sprint)完成了，只是在所有人強制把6周努力“塞到”這2周里面的情況下完成的。

　　用戶故事描述的細節比一條微博還要簡短，史詩級的(低優先級，更大塊的)用戶故事描述的是項目大多數的悲劇地方(Epic describes the proportions of most project catastrophes)【譯者注，后半句不太明白】。

　　要么沒有回顧會議，要么沒有采取任何行動，要么行動沒有分配到具體負責人那里。

　　功能演示或用戶驗收測試完全取代了標準測試(如單元測試，系統測試，集成測試或性能測試)。

　　最終用戶被迫接受不達標的功能特性和忍受使用中的大量問題，并接受功能將會改進優化的承諾。

　　你的敏捷教練并沒有進行指導。

　　燃盡圖成了一個真正的燃盡圖(The burn down chart is really a burn out chart)【譯者注，應該是想表達沒有關注曲線數據的含義】。

　　你試圖組建一個分布在大企業中或者跨地域的虛擬敏捷團隊。

　　“完成”的定義跟日期，版本構建，部署或者除可工作的軟件以外的任何其他機制相關。

　　自組織團隊退化，惡徒把他們的意愿強加到其余團隊成員上。(Self Directed Teams have degraded into bands of thugs imposing their wills upon the rest of the team.)

　　你試圖重新定義，測試實際是什么，如聲明單元測試和系統測試對應的活動。

　　你企業的PMO和資金(關卡)(Your Enterprise PMO and Funding (Tollgate))模型非常適應瀑布模式項目，但你強迫他們去適應到敏捷。

　　“團隊”不愿意做在他們職位的“工作描述”之外的事情(例如：開發人員測試，測試人員開發)。

　　你看到積極的行為和產出，并認為都是你的敏捷實踐的直接結果，然而忽視所有不好的行為和產出，并認為都是個人的問題。

　　敏捷軟件開發宣言

　　在2001年2月11日至13日，在猶他州Wasatch山脈中雪鳥滑雪勝地的小屋中，17個人聚在一起交流，滑雪，放松，并嘗試找到共同點。從本次會議上達成的是一個所有參與者簽署的敏捷軟件開發宣言：

　　我們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

　　個體和互動 高于 流程和工具

　　工作的軟件 高于 詳盡的文檔

　　客戶合作 高于 合同談判

　　響應變化 高于 遵循計劃

　　也就是說，盡管右項有其價值，我們更重視左項的價值。來源：agilemanifesto.org

　　偽敏捷宣言

　　交付的速度 高于 交付的質量

　　敏捷不是一個方法論……

　　……但是方法論的一個分類

　　敏捷事實

　　敏捷是一種沒有相關技術的運動。

　　敏捷運動轉移松散的、跨部門的軟件工程方法到單一專注于軟件開發的團隊(排除QA和運維) [The Agile movement shifts the broad, inter-departmental process of software engineering to one that is focused on software development to the exclusion of QA and operations.]。

　　敏捷運動通過源代碼的頻繁變更，把需求的所有權從業務轉移到開發[The Agile movement transfers business ownership of requirements to development ownership of requirements through frequent source code changes.]。

　　敏捷實踐，致力于更少更快的工作，以便得到持續前進的反饋。

　　敏捷宣言里沒有的，卻又和它的原則相關的幾個詞：質量保證，測試，運維。

　　敏捷是一個以開發人員為中心的運動。

　　“敏捷困境”

　　當企業對速度和靈活性的追求被曲解時，內在的風險和混亂就產生了。比如，敏捷可能不適合所有組織或項目時，依然強制推廣開展以開發人員為中心的敏捷運動。

　　28%的敏捷踐行宣布他們是成功的。

　　19%的報告表示沖刺(Sprint)如預期一樣，在制定的時間內完成了所有工作。

　　44%的報告表明他們并不知道什么是返工等級。

　　67%的缺陷是在產品發布后的第4個沖刺里被修復的。

　　59%的敏捷項目里商務人員沒有適當參與到其中。

　　Voke 研究：市場報告：敏捷的現實情況 2012.7

　　我們遵循這些原則

　　我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。以簡潔為本，它是極力減少不必要工作量的藝術。經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期?？晒ぷ鞯能浖沁M度的首要度量標準。最好的架構、需求和設計出自自組織團隊。業務人員和開發人員必須相互合作， 項目中的每一天都不例外。敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。來源：agilemanifesto.org原則1：給客戶帶來價值

　　我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。

　　敏捷偽敏捷可工作的軟件，以更短周期、可管理的方式，開發部署到生產環境，為客戶最大化價值。集中精力在2周的沖刺(Sprint)里，開發代碼再部署到生產環境，以便滿足項目的時間表。專注于提交可工作的軟件。專注于提交的周期。更快地為客戶帶來價值，帶來更高質量的產品。為客戶帶來的價值有限，客戶必須忍受有缺陷的軟件，直到被修復為止。原則2：變更 - 來吧!

原文轉自：http://blog.csdn.net/ocean1ee/article/details/8873688