軟件開發方法

在許多面試中，您可能會被問及方法論。這不是最重要或最困難的問題，但有備忘單會很好。在本文中，我們將嘗試傳達什麼是開發方法並對它們進行比較。軟件開發方法論是用於開發特定產品的過程，也就是說，它是開發人員團隊組織開發的一種方式。有許多不同的開發模型，每種模型都定義了自己的方法。不能說他們中的任何一個都應該用於每個項目。正確的做法完全取決於具體情況。我打算更詳細地考慮其中三個。

瀑布

瀑布方法是最古老的方法之一，涉及嚴格的順序實施：每個階段都必須在下一個階段開始之前完成。換句話說，過渡到下一階段意味著前一階段的工作已 100% 完成。圖片顯示了它是如何工作的：首先，我們分析問題（記錄任務，討論挑戰），然後我們設計（項目的結構在這個階段形成），然後我們編碼和測試。不允許返回到之前的階段。對於要求事先已知且不太可能更改的小型項目，建議使用此方法。 優點：

• 每個階段完整且一致的文檔
• 使用方便
• 穩定要求
• 預定義預算和截止日期

缺點：

• 大量文檔
• 不太靈活
• 客戶看不到產品的演示版本
• 沒有向後移動的選項

敏捷

Scrum 是一種將整個過程劃分為迭代的軟件開發方法。在每次交互結束時，團隊準備提供產品的演示版本。該圖顯示團隊並行進行所有開發階段，從而可以在每次迭代結束時完成項目的一部分。 我將嘗試使用簡單的詞來簡要解釋方法論的本質，但術語很多。我認為最重要的是理解本質。您會根據經驗記住這些術語。所有開發都分為衝刺（通常為 2-3 週）。有積壓（任務列表）針對整個開發階段和每個單獨的衝刺。每個任務都有自己的故事點（難度等級）。該過程中的每個參與者都有一個角色：

• Scrum 團隊由從事項目工作的專業人員（開發人員、測試人員、設計師）組成。
• Scrum 主管是確保 Scrum 原則得到尊重的人。
• 產品所有者是客戶。

這種方法論依賴於溝通，所以有大量的會議：

• 站會——這是一個簡短的會議，每天舉行，所有團隊成員都參加。每個參與者回答 3 個問題：我做了什麼？我該怎麼辦？有哪些阻塞問題？
• 計劃會議——該會議在衝刺開始時舉行。在這次會議上確定了下一個衝刺必須執行的任務。
• 回顧——這次會議在衝刺結束時舉行，其目的是確定哪些方面做得好，哪些方面可以改進。

優點：

• 客戶可以在開發過程中看到結果
• 開發過程的日常監控
• 在開發過程中進行調整的能力
• 與所有團隊成員建立溝通
• 少量文檔

缺點：

• 難以評估開發所需的勞動力和其他成本
• 開發開始前難以識別瓶頸
• 需要讓每個人都參與其他團隊成員的工作。

看板

看板是一種基於可視化團隊任務完成進度的方法。主要思想是減少當前正在執行的任務數量（在“進行中”列中）。在 Scrum 中，團隊專注於成功完成衝刺。在看板中，任務佔據著至高無上的地位。這對於處於維護階段的項目非常有用，在該階段已經實現了基本功能，並且保留了最少的改進和錯誤修復。在看板中，任務是單獨分配的。一項任務獨立於其他任務，經歷了板上的所有階段，一旦完成，就可以向客戶展示。看板由多個列組成，每個列代表一個單獨的開發過程。某些列（例如，“進行中” ) 限制他們可以承擔的任務數量。這有助於快速輕鬆地找到任務分配中的問題區域。圖片顯示了這樣一塊板的示例。列數及其名稱可以變化。我將介紹最常見的：

• To Do – 必須完成的任務列表
• In Progress——正在進行的任務
• 代碼審查——完成並提交審查的任務
• In Testing – 準備測試的任務
• 完成——完成的任務

優點：

• 使用方便
• 可見性（幫助定位瓶頸，簡化理解）
• 團隊高度參與流程本身
• 高度靈活的開發

缺點：

• 不穩定的任務列表
• 難以申請長期項目
• 沒有嚴格的截止日期

關於軟件開發方法論的最後一句話

擔任或渴望擔任管理職位的人必須徹底了解軟件開發方法，但每個人至少需要了解基礎知識。方法論是開發過程不可或缺的一部分，不僅用於 IT 領域。感謝您花時間閱讀我的文章。希望對您有所幫助。我試圖盡可能簡單易懂地只描述關鍵點。因此，本文並不詳盡。我很樂意聽取您的意見並回答您的問題。一切順利！