您需要了解的有關軟體開發方法的一切：初學者的趨勢、原則和陷阱

軟體開發是一個複雜的業務流程。這意味著 IT 需要使用最佳化、規劃和運算的語言。 了解管理概念為雇主和開發人員提供了重大優勢，並有助於將協作提升到新的水平。

初學者註意事項：模型、方法和一般困惑

首先需要澄清一點：軟體開發有單獨的模型，並且這種開發有單獨的方法。模型預測系統的未來行為。系統需要方法論才能按其需要的方式運作。混淆軟體開發模型和方法是每個 IT 初學者的神聖任務，因此這不被視為嚴重錯誤。然而，這些模型是經典的瀑布式瀑布模型，具有線性、每個階段明確的目標設定和對截止日期的嚴格控制。這些模型是螺旋式的，重點是早期識別和減輕專案風險。螺旋式發展從小規模開始，先解決局部問題，然後再解決更複雜的問題。最終模型是IID，它將專案生命週期分解為一系列迭代，每個迭代都類似於一個「迷你專案」。一般來說，模型是描述軟體開發過程的東西。但方法論是控制、評估和監控指定任務工作的系統。 方法論是現代發展的胡蘿蔔加大棒，需要方法論來控制發展過程的各個環節。它們是根據專案的方向、預算和最終產品的時間選擇的。此外，可以根據專案經理及其團隊的性格來選擇方法。甚至基於公司或客戶的理念。讓我們看看最流行的方法。

1.Scrum 方法論

Scrum 是一種敏捷專案管理方法。它基於“衝刺”——短迭代，時間嚴格限制（通常為 2-4 週）。會議的持續時間減少到最短，但頻率增加。每個衝刺都包含一系列任務，直到迭代結束，每個任務都有自己的「權重」。在會議期間，團隊討論誰做了什麼、他們將要做什麼以及有什麼問題。Scrum 使用衝刺日誌進行規劃。在這種方法中，團隊中經常出現Scrum Master，他建立整個團隊的持續工作，為其創造舒適的條件。同樣在專案中，產品負責人的角色也出現了——開發經理，監控產品的人，並充當客戶請求和團隊結果之間的主要紐帶。

優點：

• 以盡可能低的預算快速啟動專案；
• 日常監控工作進度，經常進行專案展示；
• 隨著專案的進展進行更改的能力。

缺點：

• 由於缺乏固定預算而難以簽訂合約；
• 不與團隊資質低、低估工作期限或預算的情況合作；
• 在衝刺之間不斷進行更改的能力可能會造成混亂。

適合誰：

此系統適用於最多十人的專案 - 獨立專案或大公司內部的專案。如果團隊工作量大且生命週期長，迫使他們改變並適應新的市場條件，這會很方便。

2. 看板方法

看板最重要的特點是專案生命週期的可視化。建立列是為了完成單獨提交的任務。這些列標有標記，例如：待辦事項、正在進行、程式碼審查、測試中、完成（當然，列的名稱可以更改）。每個團隊成員的目標是減少第一列的任務數量。看板方法是可視化的，可以幫助您了解問題所在。看板結構並不是明確且不可撤銷地確定的：根據項目的具體情況，可以添加臨時欄。例如，某些團隊使用的系統需要在執行任務之前定義任務準備的標準。然後新增兩列 - 指定（指定參數）和執行（開始工作）。

優點：

• 規劃靈活性。團隊只專注於當前工作，任務的優先順序也已確定；
• 能見度。當所有參與者都可以存取資料時，全球問題就更容易被注意到；
• 高度參與開發過程。流程視覺化增強了自組織和自控制。

缺點：

• 不與超過五人的團隊合作；
• 不適合長期規劃；
• 不適合在沒有動力的團隊中工作。在看板中，沒有為每項任務設定最後期限，且該方法沒有規定延遲的處罰。

適合誰：

看板在團隊有動力發展和取得成果的公司中效果很好。顯而易見，這是一個小團隊。甚至可能是部門或團隊的一部分。

3.RUP方法論

RUP 方法使用迭代開發模型。在每次迭代結束時（需要 2 到 6 週），團隊應該實現計劃目標並擁有專案的臨時但有效的版本。RUP 涉及將專案分為四個階段，每個階段都在新一代產品上完成工作：專案啟動階段、細化、建置和實施。在階段結束時，輸入階段完成標記（專案里程碑）。專案里程碑可以被視為團隊評估所取得的成果的時刻。因此，該方法意味著在第一階段發布主要功能，並在後續階段添加附加功能。

優點：

• 讓您能夠應對來自客戶和工作期間出現的不斷變化的任務；
• 確保產品的持續改進。在迭代過程中，可以仔細檢查設計；
• 讓您在工作初期識別並消除風險，有效控制開發品質。

缺點：

• 相當複雜的方法，很難在小團隊或公司中實施；
• 依賴專家設定任務的能力；
• 需要過多的需求文件。

適合誰：

當產品需要盡快發佈時，具有明確定義的需求和定義的風險的大型專案。即使以犧牲功能為代價，為了快速佔據其利基市場，然後才細化細微差別。

多種方法，一種趨勢

除了無可否認流行的 Scrum 和看板（它們基於通用名稱“敏捷”下的靈活性原則）以及頑強的迭代 RUP 之外，公司還使用許多不同的方法。有些人喜歡極限編程並做出最快、最簡單的決策，有些人喜歡測試驅動開發，而有些人則喜歡快速應用程式開發 (RAD)。同時，主要且無條件的趨勢是同時使用多種方法。或甚至將模型和方法結合到一個獨特的控制系統中。 現代公司努力消除官僚障礙，在組織內營造一種團隊合作的氛圍，而不是在部門和部門之間轉移責任。根據Scrumalliance 報告，70% 的 IT 公司使用 Scrum。其中包括Google、亞馬遜、Salesforce、微軟、Adobe等巨頭。新創公司和年輕項目更傾向於看板，但豐田和 Wargaming 的遊戲玩家也使用它。規模較小的 CIS 公司 Prom.ua、Bigl.ua、Kabanchik.ua 同時使用 Scrum 和看板方法，但用於不同的任務。Scrum - 作為計畫工具，看板 - 用於監控工作進度。至於RUP，最常由擁有500-200名員工、收入在1-1000萬美元的西方公司實施。但與此同時，IBM 透過發布 OpenUP 方法論——“RUP，只有敏捷”，改變了 RUP，使其更接近敏捷原則。同樣被吹捧的敏捷性現在主宰著 IT 領域。如今，這不僅僅是一種時尚——它仍然具有創新性，並且在許多大公司中確實有效。敏捷在矽谷使用，Facebook和Uber也在使用。

底線

每個專案都有自己的軟體開發方法，具體取決於團隊、資金、時間表和客戶要求。不存在通用的管理技術：即使是廣受歡迎的敏捷也無法提供開發流程的最佳方法。因此，方法論的選擇是謹慎的，有時甚至是根本性的。如此之多以至於你可以用它來得出有關公司本身或其客戶的結論。方法論是混合的，以模型為補充，並進行調整以適應自身的需要。以至於它們催生了新的方法。儘管最終管理領域仍然掌握在 Scrum 和看板手中，並且意外地包含了瀑布模型或迭代 RUP。