敏捷開發的敏捷方法，敏捷開發的敏捷開發原則

敏捷方法起源於 20 世紀 90 年代的 IT 軟體開發行業。 2001 年，軟體開發行業的 17 位領導者在美國猶他州會面，並發表了《軟體開發的敏捷宣言》，從中推導出了 12 條敏捷原則：

1） 我們的首要目標是通過盡早和持續地交付有價值的軟體來取悅我們的客戶。

2）歡迎對需求進行更改，即使在專案開發的後期階段也是如此。敏捷流程利用適應變化來幫助客戶創造競爭優勢。

3）持續交付可用的軟體，週期從幾周到幾個月不等，越短越好。

4）業務人員和開發人員必須在專案期間一起工作。

5）善於激勵專案人員，給予他們所需的環境和支援，相信他們能夠完成工作。

6）團隊內部和團隊之間最有效的溝通方式是面對面的溝通。

7）可用的軟體是進步的主要指標。

8）敏捷過程促進可持續、平穩的發展。專案所有者、開發人員和使用者應該能夠保持恆定穩定的開發速度。

9）敏捷性將通過技術的改進和設計的改進來增強。

10） 簡單性 – 盡可能減少不必要的工作。這是一門藝術，它是根本。

11） 最好的架構、需求和設計來自自組織團隊。

12）團隊應該定期反思如何才能更有效，並相應地調整團隊的行為。

以上就是敏捷開發的12條原則，希望它們能回答你的問題。

1.快速迭代。

相較於半年一次的 Major 版本，次要版本的需求、開發和測試更簡單、更快捷。 有些公司一年只發布 2 或 3 個版本，發布過程緩慢，仍然使用瀑布式開發模型，更嚴重的是，對敏捷開發模型存在誤解。

2.讓測試人員和開發人員參與需求討論。

需求討論以討論組的形式最有效。 研討會需要包括測試人員和開發人員，這樣可以更輕鬆地定義、分組和確定可測試需求的優先順序。 同時，它還可以利用團隊成員的互補性。

這種已確定的需求往往比需求討論會議更有效、更積極、更具參與性。

3.編寫可測試的需求文件。

首先使用“使用者故事”方法來編寫需求文件。 這種方法使我們能夠專注於需求，而不是解決方案和實施技術。 過早提及技術實現會減少對需求的關注。

4.多溝通，儘量減少文件記錄。

溝通是任何專案中的常見問題。 良好的溝通是敏捷開發的先決條件。 你在圈子裡混得越久，你就越強調良好和有效溝通的重要性。

團隊需要確保日常溝通，而面對面的溝通比電子郵件要好得多。

5.做好原型設計。

建議使用草圖和模型來闡明使用者介面。 不是每個人都能理解複雜的文件，但每個人都可以看圖片。

6.考慮盡早進行測試。

在敏捷開發的早期考慮測試是很重要的。 在傳統的軟體開發中，測試用例寫得很晚，導致發現需求中的問題太晚，使得改進成本過高。 盡早開始編寫測試用例，當需求完成時，可接受的測試用例基本完成。

首先，目標。 目標1：更快地交付價值，即更早交付。

目標2：有效學習和靈活應對變化。

2. 價值觀：

1.個人和互動勝過流程和工具。

2.可以執行的軟體勝過全面的文件。

3.客戶合作勝過合同談判。

4.應對變化比遵循計畫要好。

3. 12項原則。

1.通過盡早和持續地交付有價值的軟體來滿足客戶需求。

2.即使在開發的後期階段，也歡迎不斷變化的需求。 敏捷流程利用變革為客戶創造競爭優勢。

3.以數週到數月的週期，盡可能快速、持續地交付工作軟體。

4.在整個專案開發過程中，業務人員和開發人員必須每天一起工作。

5.建立以員工積極進取為核心的專案團隊，為他們提供所需的環境和支援，並充分信任他們的工作。

6.在團隊中傳遞資訊的最有效和最高效的方式是面對面。

7.衡量專案進度的第乙個基礎是操作軟體。

8.敏捷過程促進可持續發展，負責人、開發者、使用者應努力保持長期、恆定的發展速度。

9.始終專注於技術卓越和良好的設計，以提高敏捷性。

10.簡單是根本。

11.最好的架構、需求和設計來自自組織團隊。

12.每隔一段時間，團隊就會反思如何更有效地工作並相應地調整他們的行為。

四、執行機制。

1.乙個團隊有自己的待辦事項列表，並且待辦事項列表被分解。

2.按客戶價值確定優先順序，產品經理負責價值排序。

3.小型、穩定、跨職能的團隊。

4.多個團隊是鬆散耦合的（具有低依賴性），以調整迭代時間和戰略目標。

5. 團隊角色。

1.產品負責人。

負責管理產品積壓工作的唯一所有者。

在專案上代表客戶，例如負責人。

定義產品的所有特性。

負責產品的輸入和輸出。

負責最大限度地提高產品和開發團隊的工作價值。

2.主管（流程主管）。

擔任教練，帶領團隊實施 Scrum 實踐並展示其價值。

消除團隊遇到的困難，使團隊緊密協作，使團隊個人具備多職能工作的能力。

確保您的團隊能夠勝任工作並保持高效。

保護團隊免受不必要的影響。

3.開發團隊。

每日會議：每天 5 分鐘。

評審會：約1小時。

衝刺回顧：保持 30-60 分鐘的持續時間。

包括定量和定性分析。

定量分析：迭代目標、迭代指標（包括速度、迭代燃盡圖、迭代計畫故事和實際完成故事、計畫發布日期與實際發布日期、客戶滿意度、團隊滿意度、生產環境中的 bug 數量、生產 bug 解決時間、使用者故事等）。

除了敏捷方法的獨特功能外，它與其他方法也有很多共同點，例如迭代開發，注重互動溝通，減少中介過程不必要的資源消耗。 敏捷方法的適用性通常可以從以下幾個方面來衡量：從產品的角度來看，敏捷方法適用於需求萌芽和變化迅速的情況，比如系統對關鍵性、可靠性、安全性有比較高的要求，可能不適合整個世界; 從組織結構的角度來看，組織結構的文化、人員、溝通決定了敏捷方法是否適用。

組織文化必須支援談判者之間的信任，少數但精幹的人，對開發人員決策的認可，成員之間快速溝通的設施，也許最重要的是專案的規模。 隨著規模的擴大，面對面的溝通變得更加困難，因此敏捷方法更適合更小或更少的團隊。 大規模敏捷軟體開發仍然是乙個活躍的研究領域。

另乙個問題是，在專案開始時，大量的假設或快速收集需求可能會導致誤解，尤其是在客戶不知道他們需要什麼的情況下。 同樣，創造乙個人帶頭並引導專案目標和設計朝著錯誤方向發展的情況是人類的天性。 開發人員通常能夠將不合適的解決方案授予客戶並獲得客戶的支援，直到最終發現問題。

雖然快速互動的過程理論上可以限制這些錯誤的發生，但只有在有有效的負反饋的情況下，否則錯誤會迅速爆發。

敏捷開發是一種以人為本、迭代、循序漸進的開發方法。 在敏捷開發集群中，將乙個軟體專案的建設劃分為多個子專案，每個子專案的結果都經過測試，具有整合和可操作的特點。

換句話說，乙個大型專案被劃分為較小的專案，這些專案相互關聯，但也可以獨立執行，並單獨完成，而軟體保持可用狀態。