如何在一個小團隊中處理多個項目

Question

我們剛開始使用scrum進行項目管理。我們是一個非常小的團隊（2個開發人員，1個UI/Web deisgner），我們有很多正在運行的項目。

你如何處理在scrum模型中同時運行多個項目？大多數情況下，我們有一個主要項目和一些小型項目。你如何有效地結合多個衝刺？

編輯：不要固定在scrum上。我們是一個小結構，非常靈活。 Scrum只是我的出發點。如果你有其他的系統對你或者你的小團隊有效，我完全接受任何類型的輸入。

Answer 1

AFAIK Scrum的基礎是團隊一次參與一個項目。無論採用哪種方法，任務切換開銷都會「並行」處理多個項目，效率非常低。

你可以做的是嘗試將不同的項目安排到單獨的衝刺中，即完成專門針對項目1的衝刺，然後完成項目2中的下一衝刺等。如果項目的範圍非常不同，則可以考慮改變衝刺的長度，例如在一個大型項目上進行爲期3周的衝刺，然後在一個小型項目上進行爲期1周的衝刺。

在純Scrum中，sprint的長度確實是刻在石頭上的，但是IMO的重點並不是獲得「純Scrum實現者」徽章，而是爲您的團隊創建一個真正的實際流程。

（免責聲明：我不是Scrum Master的:-)基於評論

更新：我看到你的問題。您需要快速響應來自其他產品客戶的小支持（改進/錯誤修復）請求，同時仍需要以可預測的方式處理更大的項目。

一種可能性是計劃Scrum中大項目的衝刺，但是「時間盒」有一些時間用於接收支持任務。例如。如果您平均每個衝刺每5天花在支持其他項目上，那麼您將爲每次衝刺分配5天的資源（但是您會計算時間）以獲得支持。

另一種選擇可能是考慮其他方法，如Kanban，其中沒有衝刺或計劃，而是團隊完全（或主要）基於客戶的需求工作。

Answer 2

如果你有很多小型工作必須快速完成，那麼項目管理並不是正確的範例。你正在處理的是運營管理，通常涉及定義明確的，經過驗證的現成工作程序。因此，我建議您將管理層面上需要項目管理的那些活動與那些需要運營管理的活動分開。如果你還沒有定義工作程序（以及經過試驗和測試的等），那麼你可能不得不建立一個項目來開發它們（或者如果你想以這種方式來想象它們，就要編寫它們）。

軟件開發項目（或應該）運行的方式與幫助臺的運行方式之間存在巨大差異。僅僅因爲你是一位在項目管理模式方面經驗豐富的軟件開發人員（我認爲我們大多數人都是這樣）並不意味着這是一切正確的方法。

一旦你完成了這個轉換，你會發現你可以在1或2個項目中繼續縮減（或者任何其他項目），然後轉動機器上的把手來完成剩下的工作。

Answer 3

您需要1周衝刺。每個衝刺只有1個項目。這是一個謬論，您可以通過一次處理多個項目來更快地交付軟件。更大的項目可能需要幾次衝刺才能開發一個發佈版本，與您的小型項目一樣，您可能會在每次衝刺之後發佈。

如果您的項目是針對不同的採購訂單/客戶，那麼更重要的是，您一次只能處理一件;否則你的優先事項幾乎總會有衝突。

Answer 4

如何處理在scrum模型中同時運行多個項目？大多數情況下，我們有一個主要項目和一些小型項目。你如何有效地結合多個衝刺？

一種選擇是在並行運行多個短跑和，即使它不是理想的，是幾支球隊的一部分（顯然不是100％專用）。雖然我不確定這在你的情況下是否合理，但我不相信用Scrum運行這些小項目會增加價值。

另一個（也許更合適）選項是在您的產品待辦事項中爲衛星項目/任務所需的工作準備一個項目，從而爲他們分配一些時間。如果你需要那個時間，把它燒掉。如果沒有，只需在衝刺結束時從主項目中挑選一些額外的待辦事項。

Answer 5

棘手。您的情況可能不是Scrum的完美搭配，但我認爲Scrum中有一些元素適用於您的情況。

例如，我發現在Scrum中最有用的一件事是回顧會議，因爲它是在那些改善工作方式的會議中。但是爲了使回顧有用，你需要測量你正在做的工作，以便對你設定的一些項目進行評估。那麼爲什麼不能有類似衝刺的東西，並且爲未來1-2周的項目制定衝刺計劃（較短的一週似乎更適合您的案例）。每天進行一次Scrum會議，以便你們三個人都知道其他人正在做什麼，並且可以根據需要填寫。然後在衝刺之後，你可以坐下來思考如何改進。如果沒有別的，回顧的結果會告訴你這是否適合你。

我不相信嘗試修改嚴格的Scrum項目方案，如果這意味着並行運行衝刺或者一次只執行一個項目執行較短的衝刺，則每隔一週就會讓其他項目不受影響。