兩種敏捷開發方式的工作流介紹

敏捷開發時當今很流行的一種開發軟體方式，接下來主要介紹一下兩種主要的敏捷開發方式的工作流

專案計畫從定義backlog開始，即交付完成的產品時應該完成的使用者需求列表。

每個sprint都從乙個計畫階段開始，在下乙個sprint中選擇任務。對於計畫階段，整個團隊通常都會到場，包括產品負責人和scrum master。團隊決定在sprint結束時可以交付什麼，並從產品backlog中選擇相應的使用者工作。通過這種方式，他們將sprint backlog放在一起。

在sprint期間，團隊每天開會進行「每日scrum」，討論他們的進展以及可能遇到的任何障礙。每日scrum的目的是盡早發現問題，並快速找到解決方案，以免中斷sprint流程。

在sprint之後，涉眾將審查完成的特性。在sprint評審期間，團隊有機會收到關於他們工作的反饋，以及變更建議(如果有的話)。

與此同時，團隊開會進行sprint回顧，分析他們剛剛完成的sprint，並找到可以改進的地方。回顧之後，流程被重置，新的sprint從計畫階段開始。

在 kanban中，沒有要求需要在乙個確定的時間點完成一定數量的工作。相反，kanban專注於平衡團隊的當前正在進行的工作的能力。

乙個 kanban 專案流程從一般的backlog開始,包含所有的應該完成的任務。每個團隊成員從backlog中為自己挑選乙個任務，並集中精力完成它。當任務完成時，成員選擇下乙個任務，以此類推，直到所有任務完成為止。待辦事項列表的優先順序是將最緊急的任務放在頂部，由團隊首先處理。

在kanban中，重要的是在專案期間的任何時候，正在進行的工作量都不能超過團隊的能力。為此目的，有可能根據現有的能力為任何型別的工作定乙個限度。

產品負責人可以盡可能頻繁地設定和更改backlog中的優先順序，因為backlog管理對團隊的效能沒有影響。團隊只關心正在進行的工作，只有在當前任務完成後才返回到backlog。

每個任務都沿著「to do」—「work in progress」—「done」路線進行。當然，kanban也支援「完成」定義的概念，這是每個任務接受的標準。

總而言之，我們可以說scrum的主要區別在於它試圖在指定的時間內完成預定的工作，而kanban確保正在進行的工作永遠不會超過設定的限制。

如果你一直在等待這個問題的最終答案，我們可能會讓你失望。到目前為止，我們希望已經成功地證明了這兩種方法都有它們的優點，並且都可以幫助建立敏捷開發過程。然而，我們提供了一些指導方針，可以幫助您選擇最適合您的團隊的方法。