敏捷開發指導方針
敏捷開發的誕生源于項目對高效和品質的追求。高效地開發出有品質的軟件對各個行業的企業都是至關重要的，對最終用戶尤為重要。軟件企業不再能忍受18個月的產品周期，它們正在尋求各種方式變得更加靈活和多變以適應不斷變化的市場需求。
盡管我們需要一個高效的軟件開發計劃，但目前多數的開發項目仍然在進行中并且按傳統的模式要求事先定義下所有的需求，同時這些需求在日后幾乎不允許改變。問題是按這種方式多數客戶都不能準確定義出它們的需求。夾雜著技術進步帶來的變化，結果是令人氣餒的。美國的一家研究公司Standish Group發現百分之九十的軟件項目延期，百分之六十六的可以認為失敗，以及百分之三十的完全報廢。
敏捷開發是一個使公司能夠更快速地提交軟件產品的開發過程方法。 它是一個漸進的，協作的方法，其目標是有效及時地生產出高質量的軟件。
在敏捷的初期，它適用于較小的范圍和相對簡單的商業應用項目。 如今，局面已發生了顯著變化。 當公司想要把敏捷開發應用在更廣泛的項目上， 那么敏捷開發就需要處理當前軟件開發組織所面臨的大量業務、結構、和技術的復雜問題。
正確的分析出轉向敏捷的代價，你必須權衡利弊，同時開了開發風險的減少。例如，實施敏捷方法需要改變工程師花費時間的方式和他們如何完成所有的軟件開發活動。這里強調一些進行轉換應該關注的要點。
◆個人和交互（針對流程和工具）
◆工作軟件（針對全面文檔）
◆客戶的合作（針對合同談判）
◆響應變化（針對遵循計劃）
經理們必須考慮他們扮演的角色。多數敏捷精益開發經理使用更加放手的方式。他們讓隊員在特定的方向作先鋒從而培育出成功轉向敏捷精益開發的環境所需要的。
敏捷增加了團結的軟件交付效率，從而轉化為客戶滿意度和收益。效率可以消除在特定活動上的浪費，它可能也許不能對大的目標產生影響。但是，效率不會告訴你正在做的事情是否正確，或者告訴你正確的做事順序。效率更重要的是它幫助你實現目標。
和其它重要的敏捷開發原則一樣的一條是開發階段的客戶介入，如同前面提到過的，持續的團隊協作。相關人員關于可工作代碼的反饋和測試驅動開發對成功推出一個項目至關重要。相關人員包括業務相關者、軟件使用人、客戶支持、和其它企業IT部門人員，需要他們盡早的多多介入到敏捷項目整個開發周期中，積極參與建模和測試，有時甚至是參與開發。這一層次的介入使得他們能夠看到軟件開發的內部工作。這樣促使開發人員關注于客戶的優先級上而不是個人的優先級，這樣可以提高產品的可用性。
這些敏捷開發指導方針為企業提供了一個基礎，一個使企業知道如何快速響應并準備好應對需求變化的基礎。例如使用Scrum（混戰：一個敏捷開發借用橄欖球運動中的術語），一個每天舉行的“混戰”（也就是會議）邀請所有項目相關人員。 每天開發人員回答三個問題：
◆從昨天到今天你完成了什么？
◆從今天到明天你打算做什么？
◆你遇到什么問題使你無法完成計劃的目標？
這個每日例會要求每個人清楚說明他所做的事情，這樣其它隊員可以在轉為災難之前指出錯誤和不兼容。它也可以確保在緊急情況出現時有人可以作出及時補救。
敏捷開發常常被人批評為是過于隨意的，這是不符合事實的。溝通交流和規則是敏捷開發的兩個基本組成部分。敏捷***的驅動原則是定期提交可工作的軟件。提交周期越短，對規則的要求越高 － 例如，每次迭代都必須以可工作軟件形式提供具體的可以度量的商業價值。
雖然關于敏捷是否過于隨意和無紀律的爭論還在繼續，但有一個事實：人們對敏捷模式和精益開發的關注興趣越來越強。僅僅在IBM一家，過去的兩年中，敏捷項目的數量從5個增加到了200多個。
【編輯推薦】
