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

兩種敏捷開發方式的工做流

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

Scrum flow

項目計劃從定義backlog開始，即交付完成的產品時應該完成的用戶需求列表。

• 產品 backlog - 列出團隊主要的 「To Do」 list。 產品的代辦事項列表應該包括所有的特性和 bug 修復。以便在項目結束時確認已經完成。產品的代辦列表須要在工做中按照新的需求或者發現的錯誤持續的更新。產品的負責人負責待辦事項，使其與客戶的反饋和建議以及團隊的工做進度同步。一些Item的優先級應該被提高或降低，一些item應該根據需求的變化增長或者減小。
• Sprint backlog - 包含在特定sprint中要完成的任務。sprint backlog的項目被選擇爲在sprint結束時交付一個完成的特性或組件。雖然sprint backlog也容許必定的靈活性和修改，可是sprint的目標應該保持不變，而且變動應該保持在最小。
• Sprint goal or increment - 做爲sprint結果交付的可用產品。一般，sprint以展現完成的特性或組件的演示結束。在這方面，一個重要的概念是「done」的定義，它指的是要將每一個用戶工做視爲完整的。「done」的定義可能會根據用戶的狀況而有所不一樣:它可能包含多個任務，例如開發、測試、設計、文檔和表示，還可能涉及不一樣的團隊成員。

每一個sprint都從一個計劃階段開始，在下一個sprint中選擇任務。對於計劃階段，整個團隊一般都會到場，包括產品負責人和Scrum Master。團隊決定在sprint結束時能夠交付什麼，並從產品backlog中選擇相應的用戶工做。經過這種方式，他們將sprint backlog放在一塊兒。

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

在sprint以後，涉衆將審查完成的特性。在sprint評審期間，團隊有機會收到關於他們工做的反饋，以及變動建議(若是有的話)。

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

Kanban flow

在 Kanban中，沒有要求須要在一個肯定的時間點完成必定數量的工做。相反，Kanban專一於平衡團隊的當前正在進行的工做的能力。

一個 Kanban 項目流程從通常的backlog開始,包含全部的應該完成的任務。每一個團隊成員從backlog中爲本身挑選一個任務，並集中精力完成它。當任務完成時，成員選擇下一個任務，以此類推，直到全部任務完成爲止。待辦事項列表的優先級是將最緊急的任務放在頂部，由團隊首先處理。

在Kanban中，重要的是在項目期間的任什麼時候候，正在進行的工做量都不能超過團隊的能力。爲此目的，有可能根據現有的能力爲任何類型的工做定一個限度。

產品負責人能夠儘量頻繁地設置和更改backlog中的優先級，由於backlog管理對團隊的性能沒有影響。團隊只關心正在進行的工做，只有在當前任務完成後才返回到backlog。

每一個任務都沿着「To Do」—「Work in Progress」—「Done」路線進行。固然，Kanban也支持「完成」定義的概念，這是每一個任務接受的標準。

總而言之，咱們能夠說Scrum的主要區別在於它試圖在指定的時間內完成預約的工做，而Kanban確保正在進行的工做永遠不會超過設定的限制。

如何選擇

若是你一直在等待這個問題的最終答案，咱們可能會讓你失望。到目前爲止，咱們但願已經成功地證實了這兩種方法都有它們的優勢，而且均可以幫助創建敏捷開發過程。然而，咱們提供了一些指導方針，能夠幫助您選擇最適合您的團隊的方法。

使用 Scrim

• 你能夠相對容易地將工做劃分爲邏輯塊，這些邏輯塊能夠在兩週內完成。
• 你須要對整個項目有高度的可預測性。Scrum專一於將sprint中的變動保持在最小。
• 你的團隊裏有不少新成員。使用Scrum，若是須要的話，他們會更容易理解團隊紀律並作出改進。

使用 Kanban

• 你指望項目中有不少頻繁的變動。
• 很難隔離可以在兩週內交付的產品組件。
• 你的團隊紀律嚴明，能夠信任他們會在沒有嚴格截止日期的狀況下安排他們的活動。