資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學敏捷如何提升客戶滿意度和改進？
尋求結構化、重點突出的敏捷方法的軟體開發團隊，這種方法可以擴充套件到整個產品組織併產生明確的結果，可能會發現 FDD 是一個不錯的選擇。
特性驅動開發 (FDD)
特性驅動開發 (FDD) 是一種敏捷軟體開發方法，以客戶為中心，迭代遞增，旨在頻繁有效地交付切實的軟體成果。在敏捷的 FDD 的所有級別都鼓勵狀態報告，這有助於監控進度和成果。
FDD 允許團隊頻繁更新專案並快速發現錯誤。此外，客戶可以隨時獲得大量結果和資訊。因為它有助於減少開發行業中兩個眾所周知計程車氣殺手——混亂和變通方法，所以 FDD 是開發團隊的首選方法。
特性驅動開發階段
與所有敏捷方法一樣，收集資料是 FDD 的第一步。這包括清楚地瞭解專案的內容和背景，以及對目標受眾需求的共同理解。在這一階段，團隊應儘量多地瞭解他們即將啟動的專案的“為什麼”、“什麼”和“誰”（接下來的幾個步驟將有助於闡明“如何”）。此資料收集可以被認為是零階段，但不能跳過。這是研究和論文開發步驟，因此可以將其與撰寫研究論文進行比較。
一旦團隊清楚地瞭解了他們的目標、目標受眾以及當前（和可能的未來）需求，FDD 的第一個命名階段就可以開始了：建立綜合模型。
開發總體模型
建立綜合模型，遵循研究論文的類比，在這個階段起草提綱。團隊將使用“論文”（也稱為主要目標）作為指南來開發詳細的領域模型。這些模型將組合成一個單一的總體模型，作為系統的大綱。隨著它的發展和團隊的學習，細節將被新增。
建立特性列表
使用第一步中收集的資訊，建立所需的特性列表。請記住，客戶重視的輸出是一個特性。建立一個可在 14 天內完成的特性列表。請記住，這些特性不應該是任務，而是目的或更小的目標。
進入基於特性的計劃
規劃團隊成員可以完成的任務，這些任務與每個特性的複雜性相關。所有團隊成員都應該參與規劃階段的特性的評估，考慮每個開發階段的視角。然後，可以使用複雜性評估來確定每個特性將被實現的順序以及將被分配到每個特性集的團隊成員。
此外，在這個階段應該確定類所有者——分配給類的單個開發人員。由於特定的開發人員負責正在開發的特性的每個類，因此該開發人員也負責該類的概念原理。如果需要更改多個類，則這些類的所有者必須共同努力才能實施這些更改。
此外，特性團隊和類所有者對 FDD 都至關重要。特性團隊鼓勵不同的觀點並明確定義角色。這確保在設計時考慮了不同的想法和視角。
按特性設計
將要設計和構建的特性將由首席程式設計師選擇。此外，在定義特性優先順序時，他或她將選擇相關的類所有者和特性團隊。部分團隊可能關注技術設計，而其他團隊可能關注框架。在繼續之前，整個團隊在設計階段結束時完成了設計審查。
按特性構建
此步驟將所有需要做的事情付諸行動以幫助設計。在此構建特性原型和使用者介面，以及技術設計中描述的元件。單元測試、審查和批准後，即可將完成的特性新增到主構建中。每個設計和構建時間超過兩週的特性都將進一步細分為特性，直到滿足兩週規則。
FDD 的優點
透過避免多次會議來使用文件進行溝通。
更好地瞭解專案的範圍和背景。
它遵循模組化方法，以迭代版本的方式交付模組化的工作。
這是一種可擴充套件的方法，適用於長期的大型專案。
它使用以使用者為中心的方法，其中客戶被視為終端使用者。
FDD 的缺點
即使專案開發團隊使用了大量文件，也缺乏向客戶提供書面文件。
它不適合小型專案。
由於它強調個人的程式碼所有權，因此缺乏對特性的共享團隊所有權。
結論
總之，特性驅動開發是一種實用的敏捷策略，非常適用於長期且複雜的專案。對於尋求可擴充套件、結構化且簡單的敏捷方法以產生可預測結果的開發團隊來說，這是一個不錯的選擇。
瀏覽量：190
