軟體開發方法論

你好。在最後兩次訪談中，我被問及方法論。這不是最重要或最困難的問題，但最好有一個答案的備忘單。在這篇文章中，我將嘗試給出什麼是發展方法論的概念，並比較我親自遇到或被問到的那些方法論。 軟體開發方法論是描述如何開發特定產品的過程，即組織團隊開發的方法之一。這樣的過程有許多不同的模型，每種模型都描述了自己的方法，並且不能說其中有一個應該在每個項目中使用，一切都純粹是情境性的。我建議更詳細地考慮其中三個。

瀑布

瀑布（級聯、瀑布）是最古老的方法之一，意味著所有階段嚴格依序執行，每個階段必須在下一個階段開始之前完成。也就是說，進入下一階段意味著上一階段工作的全面完成。如圖所示，首先我們分析任務（記錄任務，討論困難），然後進行設計（此階段專案結構形成），然後編碼和測試。後續階段不予退款。建議在小型專案中使用這樣的系統，因為這些專案的需求是預先知道的，而且它們改變的可能性很小。 優點：

• 每個階段的完整且一致的文檔；
• 使用方便;
• 穩定的要求。
• 預算和期限已預先決定

缺陷：

• 大量的文檔；
• 不是一個非常靈活的系統；
• 客戶無法查看產品的試用版；
• 沒有辦法後退一步。

Scrum

Scrum 是一個基於將整個流程劃分為迭代的軟體開發系統，在每個迭代結束時，團隊準備提供產品的演示版本。該圖顯示團隊並行地經歷了開發的所有階段，這使我們能夠在每次迭代結束時完成專案的一部分。 我將嘗試用簡單的語言簡要解釋該方法論的本質，但這裡有很多術語。我認為最重要的是理解本質，術語隨著經驗就會記住。所有開發都分為多個衝刺（通常為 2-3 週）。整個開發週期和每個衝刺都有一個待辦事項清單（任務清單）。每個任務都有自己的故事點數（難度等級）。過程中的每個參與者都有一個角色：

• Scrum 團隊是致力於專案的團隊（開發人員、測試人員、設計人員）。
• Scrum Master 是確保 Scrum 原則得到遵守的人。
• 產品所有者——客戶。

由於這個系統強調的是溝通，所以有大量的集會：

• 站立會議是一個簡短的會議，每天舉行，所有團隊成員都參加，每個參與者回答 3 個問題：你做了什麼？它會做什麼？阻礙因素是什麼？
• 規劃－在衝刺開始時舉行，在這次會議上確定下一個衝刺應完成哪些任務。
• 回顧是在衝刺結束時進行的，其本質是找出哪些方面做得好，哪些方面可以改進。

優點：

• 客戶可以在開發過程中觀察結果。
• 對開發過程的日常控制。
• 能夠在開發過程中進行調整。
• 與所有團隊成員建立良好的溝通。
• 少量文檔。

缺陷：

• 難以估計開發所需的勞動力和成本
• 在開發開始之前很難確定最大的瓶頸。
• 需要讓每個人都參與其他團隊成員的發展。

看板

看板是一個基於可視化完成團隊任務的過程而建構的系統。這個系統的主要思想是減少目前正在進行的任務數量（在「進行中」欄中）。在 Scrum 中，團隊專注於成功完成衝刺；在看板中，任務是第一位的。適合處於支援階段的項目，該階段的主要功能已經開發完畢，並且仍保留很少的改進和錯誤修復。在看板中，任務是單獨提交的。無論其他任務如何，該任務都會經歷板上的所有階段，一旦完成就可以向客戶展示。看板由多個列組成，每個列代表一個單獨的開發過程。某些欄位（例如，正在進行中）會對可以存在的任務數量施加限制。這有助於輕鬆快速地找到任務分配中的問題區域。圖片顯示了這種簡單板的範例。列數和名稱可能有所不同，但我將列出最常見的：

• 待辦事項 - 需要完成的任務列表
• 進行中 – 目前正在處理的任務
• 程式碼審查－已完成並送審的任務
• 測試中 – 準備測試的任務
• 完成——已完成的任務。

優點：

• 使用方便。
• 視覺化（有助於發現瓶頸，簡化理解）
• 團隊對流程本身的高度參與。
• 開發彈性高。

缺陷：

• 任務清單不穩定。
• 難以用於長期專案。
• 沒有嚴格的最後期限。

關於軟體開發方法的總結

在我看來，擔任管理職位或渴望擔任管理職位的人需要對軟體開發方法有透徹的了解，但建議每個人至少了解基礎知識。這是開發過程中不可或缺的一部分，不僅用於 IT 領域。感謝您花時間閱讀我的文章，希望您覺得它有幫助。我試著盡可能清晰、簡短地描述要點，因此本文並不詳盡。我很高興聽到您對此的看法並回答您的問題。一切順利！