IBM敏捷新思想

　　2010年，在Agile@IBM敏捷社區的討論熱點因為集中在“軟件全生命周期敏捷”、“分布式敏捷面臨的挑戰”這兩個話題而使得我對敏捷的價值和敏捷宣言又有了新的理解，也促使我從一開始對“核心敏捷”的糾纏不休，到終于放下，用開放的心態去研究IBM內部的諸多相同有不同的敏捷開發過程，這對于我的研究產生了很大的正面影響。

　　請跟隨，我需要大家再次回顧下敏捷宣言的四條要義：

　　個人與交互 重于 開發過程和工具

　　可用的軟件 重于 復雜的文檔

　　尋求客戶的合作 重于 對合同的談判

　　對變化的相應 重于 遵循固定的計劃

　　我們將敏捷宣言四條要義來詮釋SCRUM方法，且用SCRUM方法中的實踐、策略來反射敏捷的這四句從“語法”上不為完整的宣言，我們新的理解得到了12條“敏捷原則”：

　　1. 我們最優先要做的是通過盡早的，持續的交付有價值的軟件來使客戶滿意。

　　2. 擁抱需求變更，甚至在開發后期。敏捷過程利用變化來為客戶提供競爭優勢。

　　3. 經常交付可以工作的軟件，從幾個星期到幾個月，如果可以優先短的周期。

　　4. 業務人員和開發人員必須每天一起工作。

　　5. 以人為本，激勵個人，同時給予他們所需要的環境和支持，并且信任他們能夠完成工作。

　　6. 團隊內部最有效的溝通方法是面對面的交談。

　　7. “可工作的軟件交付”是首要的項目成功度量方式。

　　8. 敏捷項目必須注重團隊的“可持續性”。投資人，開發者和用戶應該能夠理解和支撐團隊保持一個可持續發展的工作強度。

　　9. 團隊持續地關注技能的卓越，和致力于優秀的設計會增強團隊敏捷能力。

　　10. 簡約 – 最大化生產力的秘密。

　　11. 最好的構架，需求和設計出自于“自組織團隊”。

　　12. 每隔一定時間，團隊將坐在一起反思如何才能更有效的協作，然后相應地調整其行為。

　　實踐證明，我們的12條原則不但可以詮釋敏捷宣言的價值觀，又提供了對SCRUM堅實的支撐。有效的軟件工程理論的發展離不開精確的定義。而我們領導團隊也的確認為IBM需要一個精確的定義。事實上，業界對于敏捷軟件開發一直沒有正式的定義，有可能永遠不會。但IBM的敏捷領導團隊給出了一個可能有用的工作定義(來自前IBM首席方法論學大師 Scott Ambler)：

　　敏捷軟件開發是通過一個價值驅動的、有規律地生產高品質的軟件的、以具成本效益和有時間觀念的方式，也是一種進化性(迭代和增量型)的方法。它是一個高度協作的，有規則有紀律的，自我組織的，其軟件利益相關者積極參與的方法。通過利益相關者的參與，因此得以確保團隊了解并重視解決其利益相關者的、會變化的需求。使用此方法的團隊，即敏捷軟件開發團隊，將基于其面臨的獨特環境，而采用適量的敏捷儀式持續的交付。

　　讓我們來展開這個定義一些關鍵概念：

　　1. 價值驅動的 —— 將每個迭代目標均設定在建設一個潛在可交付的產品、解決方案時，敏捷團隊就持續的為產品注入真正的價值和每次均已可用軟件的形式體現出來......

　　2. 進化 —— 敏捷的共性都是迭代和增量型的。 “迭代”的意思是您正在使用的功能代碼版本通過一系列的過程重復，在原有的基礎之上增加構建內容，完成每個構建、每個版本直至項目完成的活動。但是，這并不意味著工作本身是重復的......

　　3. 有規律的生產高品質的軟件 —— 據說敏捷主義者必注重質量。他們更喜歡早期進入、且反復測試，以及更為嚴格的敏捷從業者甚至會采取一個測試驅動的開發方法，這意味著編寫一個測試代碼和并用剛剛足夠的生產代碼來實現通過這個測試的方式實現每個功能、每個構建(然后他們迭代)......

　　4. 成本效益和時間觀念的方式 —— 敏捷團隊希望實現的功能在優先順序上，按照他們的利益相關者(或能夠代表客戶的人)的期望被定義。因此，團隊以最大限度的提高投入產出比(ROI)為回報，也正是如此，他們更關注工作的高價值功能，通過利益相關者的定義，從而提高成本效益。敏捷團隊也更愿意在每一次迭代中產出可交付的軟件(迭代是一個時間框，通常2-4周的長度)，以致使得他們的利益相關者根據已交付的成果來決定何時可以有一個正式版本的交付，從而提高了時效性。短迭代周期也縮短了反饋的周期，提高了讓敏捷團隊及早發現問題的機會(無論成功、失敗都是快速的)，從而使他們能夠勇于正面解決問題，即使當時他們還顯得缺乏足夠能力和經驗。

　　5. 高度協作的 —— 人們在構建系統，所關系乎開發項目成功的主要決定因素是“個人和他們的協同工作方式”。敏捷團隊致力于盡可能的有效的、緊密的合作，這種特質必須是每個人都具備，即使是領導團隊也都不能例外。

　　6. 有規則有紀律的 —— 敏捷軟件開發事實上需要從業者、團隊擁有更為嚴格的紀律性，這點勝過傳統研發方式下對團隊的要求。

　　7. 自我組織的—— 自我組織的團隊意味著這些從事工作的人，自己做計劃，自己估算工作量。

　　8. 利益相關者的積極參與 —— 敏捷團隊與他們的利益相關者密切合作，這其中包括最終用戶，最終付費的人，企業架構師，支付技術工程師，運營業務人員還有其他許多相關的人。

　　9. 利益相關者的、會變化的需求 —— 隨著項目的進行，當他們面前階段性地呈現了可以工作的產品的部分功能、即使不足夠完整，利益相關者將更好地了解自己想要什么。因此，他們很可能在評審過程中改變初衷、需求。而這個可能的變化源自商業環境的不斷的變化，或者源自組織的任務的優先級調整......

　　10. 適量的敏捷儀式 ——“儀式”是指在項目中使用的流程、規范(方法)。例如，結對編程、文檔的審閱、對代碼質量和方方面面的討論......

　　11. 持續的交付—— 利益相關者顯然不關心你如何實現，如何解決問題; 他們只關心你階段性交付了什么。特別是......

原文轉自：http://blog.csdn.net/u012936954/article/details/18818619