[[419124]]

【51CTO.com快譯】本文介紹了人們需要了解的關于Scrum、極限編程、動態系統開發方法(DSDM) 和特征驅動開發(FDD)等內容。

敏捷軟件開發使企業能夠在短時間內將產品推向市場。為了讓企業高管了解敏捷方法是否適合，文中分享了敏捷軟件開發的基本原則、首選團隊結構、常見方法等信息，例如Scrum、極限編程(XP)、動態系統開發方法(DSDM)和特征驅動開發(FDD)。

1.什么是軟件開發的敏捷方法?

敏捷是一種獨特的軟件開發方法，它考慮了不同的組件，例如客戶的需求、持續學習和測試、迭代開發、每兩周后的有形增值等因素。

2.敏捷軟件開發的基本原則

(1)溝通與反饋

不同軟件開發團隊成員之間的溝通可能是一個挑戰，尤其是在冠狀病毒疫情蔓延期間，因為大多數人都在家遠程工作。在這種情況下，可以使用通信工具使軟件開發團隊成員的工作保持同步，同時密切合作以創建最小可行性產品(MVP)。

在使用敏捷方法時，團隊成員在同一時間工作，他們可以幾乎實時地協作、分享關注點、提供反饋，并高效地協同工作。

在敏捷軟件開發過程中需要遵循“更少的計劃變更”的概念。經過幾個sprint周期之后，這些變更將生效，需要仔細分析客戶反饋。根據分析，在當前或即將到來的sprint周期中選擇的待辦事項列表中添加更多的更改。

(2)適應性

創建敏捷軟件開發過程時應該考慮的兩個基本要求是：一是以恒定的速度推進項目;二是處理壓力的能力，例如由于需求變化而導致的截止日期、預算增加等。為了有效管理和提高生產力，可以先開展快節奏的sprint工作，然后休息一段時間。在所有sprint周期中保持更高的生產力和快節奏的工作是可以強制的，但這種方法通常是不可持續的。

(3)信任

選擇團隊成員使用敏捷方法進行軟件開發項目是重要的一個步驟。選擇過程的另外重要部分是考慮技能組合和責任，此外還應該有工作環境的個性化匹配。團隊成員應該是優秀的專業人士，能夠自我管理并且能夠相互信任。

自我管理的質量在敏捷方法中至關重要，因為工作節奏通常很快，并且需要獨立解決問題。另一方面需要避免微觀的管理或指導，因為這些做法通常需要花費更多時間。團隊成員事先清楚了解軟件開發要求很重要，這也意味著需要了解產品路線圖。

(4)協作

在軟件開發中，有兩種常見的開發模型——瀑布模型和敏捷模型。在瀑布模型中只收集一次需求，這也意味著客戶可以一次性參與。而在敏捷模型中，客戶在開發過程中一直參與以收集需求。因此，客戶在維護產品待辦事項方面將發揮積極作用。在其他時候，客戶可能會在修改需求方面發揮積極作用，例如在提供產品演示、在日常會議期間等等。

3.敏捷軟件開發的首選團隊結構

作為敏捷軟件開發的核心，協作扮演著重要的角色。協作發生在具有特定角色的不同團隊成員之間。考慮到Scrum框架，其名稱和角色解釋如下：

• 業務主管：業務主管在最小可行性軟件產品(MVSP)的開發中發揮積極作用。業務主管主要與Scrum主管和產品主管進行協調。
• 產品主管：產品主管在創建最小可行性軟件產品(MVSP)的同時確保從開發工作中獲得最大的投資回報(ROI)。產品主管通過設置優先級來做到這一點。產品主管的三個主要職責是：管理Scrum待辦事項、發布以及利益相關者管理。
• Scrum主管：Scrum主管負責將產品主管或業務主管共享的方向轉化為有形價值。為此，Scrum主管協助管理待辦事項，并協助開發團隊自我組織、管理潛在障礙等工作。
• 設計、開發和測試團隊：在理想情況下，設計、開發和軟件測試團隊成員緊密協作。一旦開發了Web應用程序的前端，開發團隊成員就會添加功能。最后，測試團隊成員將通過開發不同的案例來檢查功能。
• 主題專家：潛在客戶需要解決其行業難點的解決方案。端到端Web和移動應用程序開發服務提供商可能擁有協助開發團隊以及Scrum主管的主題專家。

4.敏捷中的通用方法和框架

(1)Scrum

Scrum是一種廣泛流行的用于開發軟件產品的框架。其重點主要是產品的設計、開發、測試和部署。開發是在sprints中完成的，通常需要兩到三周的時間。Scrum團隊由產品主管、Scrum主管、開發團隊、主題專家等成員組成。

敏捷軟件開發項目的進度是通過每天在15分鐘內完成的Scrum會議來衡量的。

(2)Scrum框架的工作流程

Scrum框架由不同的組件組成，例如sprint、sprint規劃、每日Scrum、sprint審查、sprint回顧、待辦事項細化以及取消sprint。以下是對上述每個術語的簡要概述。

• sprint：sprint通常持續兩周的時間。在sprint期間會生成一個待辦事項，其中包含有關當前sprint的可交付成果的信息。
• sprint計劃：sprint計劃流程以邀請Scrum團隊的會議開始。團隊就目標達成一致，并確定有助于實現該目標的待辦事項。
• 每日Scrum：每日Scrum會議是一個限時15分鐘的活動。在進行日常Scrum時要遵循某些指導方針，例如開發人員發言、識別瓶頸和風險等等。
• sprint評審：在sprint周期結束之后，進行sprint評審。在理想情況下，產品主管應該在場，因為可交付成果向利益相關者展示。這提供了接收反饋的機會。
• Sprint回顧：由于Scrum框架補充了持續學習的理念，因此在sprint完成后的回顧會議中討論學習情況。其總體思路是討論哪些進展順利，哪些不順利。如果事情沒有按計劃進行，那么也將討論其背后的原因。
• 待辦事項細化：為了保持待辦事項中的質量，添加了細化步驟。待辦事項細化步驟使團隊成員能夠將較大的需求分解為較小的需求、識別依賴關系、修改優先級等等。
• 取消sprint：如果在sprint:中沒有實現目標，產品負責人可以取消sprint。

(3)極限編程

極限編程主要側重于廣泛的測試，為此使用了“結對編程”的概念。考慮到將常規軟件開發實踐提升到極端水平的一般方法，該名稱包括“極端”這個術語。

極限編程中的常見活動：

• 編碼：極限編程中的編碼實踐包括來自其他程序員的大量反饋，因為該框架主要以“測試”為重點。
• 測試：在軟件開發階段之后，測試對于消除錯誤(bug)至關重要。根據測試階段所用的時間，軟件產品的質量可能會有所不同。在極限編程中，將測試的概念發揮到極致，以消除數量最大的錯誤。這是通過“結對編程”實現的。極限編程中有兩種不同的測試方法——單元測試和驗收測試。
• 傾聽：在極限編程中，程序員通過傾聽客戶的需求發揮著重要作用。為此，程序員應該清楚哪些功能可以真正幫助客戶，以及可能需要哪些業務邏輯更改。
• 設計：良好的軟件設計易于維護。它還通過避免可能增加復雜性的依賴關系來增加價值，因為修改軟件的一個模塊可能需要更改多個其他模塊。

(4)動態系統開發方法(DSDM)

在動態系統開發方法(DSDM)中，預先確定了成本、質量、時間這三個因素。此外，動態系統開發方法(DSDM)采用MoSCoW優先級方法來修改優先級。這樣做可以及時交付軟件。

DSDM的原則：

• 關注業務需求：在DSDM中，業務目標與軟件的交付日期同等重要。關注業務需求的管理方式是通過某些實踐完成的，例如MoSCoW優先級劃分、通過時間盒將大任務分解為小任務、改進可交付成果等。
• 準時交付：強調使用MoSCoW優先級、截止日期管理和時間盒技術來交付可交付成果。
• 協作：協作的概念在DSDM中實施，而利益相關者參與項目。了解贊助商和用戶的需求很重要，主管將向團隊成員傳達這一點。
• 永不妥協的質量：測試階段在DSDM的早期引入，并在整個開發過程中發揮積極作用。
• 從堅實的基礎上逐步構建：“充分的預先設計”方法使客戶以及敏捷軟件開發人員能夠理解基本需求。在每次迭代中，團隊成員可以重新考慮優先級，并考慮來自利益相關者的反饋。
• 迭代開發：迭代方法為項目增加了價值，因為它涉及不斷的測試。迭代軟件開發方法還補充了對相關利益反饋的接受。
• 持續而清晰的溝通：在DSDM中，通過非正式的日常站立會議加強溝通，這是一個討論各種想法的好地方，研討會以保持產品與利益相關者的期望保持一致。
• 展示控制：管理軟件開發項目和使用DSDM需要主動管理技能。這包括讓利益相關者和團隊成員保持一致，有效使用報告和分析，并專注于交付的需求。

(5)特征驅動開發(FDD)

要理解特征驅動開發(FDD)，需要考慮其三個基本組成部分。創建FDD的第一個組件是對象建模，第二個組件是使用特征列表來管理需求，功能驅動開發的創建者Jeff De Luca利用自己的專業經驗設計了第三個組件。

特征驅動開發(FDD)中的活動：

• 開發整體模型：在這項活動中，軟件開發項目的范圍通過高級演練最終確定。創建不同的模型并在同行評審會議中進行評審，選定的模型最終會合并到整體模型中。
• 構建特征列表：在第一項活動完成之后，需要將復雜的特征簡化并轉換為小特征。這些特征代表了客戶需求和業務活動的混合。在理想情況下，每個特征預計在兩周內在特征驅動開發(FDD)中開發。
• 按性質規劃：一旦最終確定特征，它們將被進一步劃分并分配給每個程序員，然后他們努力改進類。這是一個三步過程;首先確定開發順序，將業務活動分配給首席程序員，再將類分配給其他開發人員。
• 按特征設計：考慮到時間盒方法，最終確定特征列表。在特征選擇后不久，序列圖就被創建。最后進行設計檢查。
• 按特征構建：在這個迭代活動中進行實際編碼。單元測試在代碼檢查之后很快執行。如果沒有發現錯誤，則將代碼添加到主構建中。

結論

敏捷軟件開發方法在過去幾年中發生了根本性的變化。敏捷的應用可以在其他領域找到，例如營銷和銷售等領域。有了切實的成果，企業高管和項目經理必須了解敏捷軟件開發的重要性并實施相關實踐，并創建以客戶為中心的產品或提供更多以客戶為中心的服務。

原文標題：Agile Software Development: Principles, Team Structure, and Frameworks，作者：Ramesh Lal

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】