敏捷項目管理

Question

如果您將Scrum用於項目的軟件開發部分，是否仍然使用PMBOK或其他項目管理方法來處理項目中的「其他」任務。業務，營銷，培訓任務。什麼是非軟件開發任務的項目管理，即傳統的項目管理？

Answer 1

我們已經將scrum擴展到公司的其他部門，建模，紋理和動畫藝術家。我們不得不稍微調整這個方法，但它確實很好地工作。我們遇到了使用敏捷方法解決的問題。一些較小的部門（音頻，特殊效果）已經正常工作，所以我們沒有試圖修復未被破壞的部分。敏捷會爲他們增加不必要的開銷。

公司所有部門都沒有必要使用相同的方法，最好的方法是適應每個人的需求。但是Scrum可能是程序員之外的其他人的解決方案，但可能需要一些適應。每日站立，衝刺，積壓，這些對於許多類型的工作都是好事。

Answer 2

Scrum不是軟件開發方法，而是項目管理方法。

除了Scrum往往引入​​或其他人爲因素（搜索「59分鐘Scrum」）。 因此，它可以用來處理項目的所有任務，無論它們的性質如何。

Answer 3

雖然瞭解這些技術非常好，但我能否建議您主要關注的焦點實際上是運行項目並完成任務？

編輯：這是一個嚴重的問題，而不是一擲千弄。

Answer 4

項目在PMBOK中被定義爲固定範圍，持續時間和預算。該項目的失敗被定義爲違背這個「鐵三角」三個方面之一。 Scrum是基於敏捷價值觀處理各種知識工作的一系列原則和一些具體實踐，專門用於可能不是項目或可能具有靈活範圍，持續時間或預算的開發工作。

你說得對，Scrum只涉及軟件開發過程的幾個方面，比如規劃。它只定義了一些角色，會議和工件，這是爲了儘可能保持靈活性。 Scrum可以也應該在軟件開發本身之外解決部分價值流問題。但是，正如您所提到的，它不涉及很多事情，如軟件工程實踐，並分析業務案例。

通常，標準Scrum解決方案是「讓團隊決定」哪些事情不是由Scrum直接指定的。通常，處理這些問題的準則來自敏捷世界中的其他文化和價值或原則系統，例如XP或精益軟件開發。爲Scrum團隊提供有用內容的其他文化包括Real Options，增量資助法，Evo。

一些PMBOK的東西對於Scrum團隊中的「項目經理」或PO是有用的，但是必須謹慎，因爲PMBOK意味着一個與Scrum基於的不同的價值系統。通常最好在敏捷文化中尋找解決方案。儘管如此，一些PMBOK的東西仍然適用於敏捷的環境。

如果您在尋找與「敏捷項目管理」相關的郵件列表，您會發現很多蓬勃發展的社區討論這些主題。

Answer 5

如果您的軟件開發工作只是大型項目的一個方面 - 例如推出一個新的金融產品 - 那麼您一定會採用某種項目管理方法來編排所有的工作參與其中。但是，將基於Scrum的軟件開發工作納入根據PMBOK原則管理的項目可能具有挑戰性，然而，由於PMBOK規定了線性分階段的項目執行方法，而Scrum與其他敏捷方法一樣，通過迭代促進了漸進式改進。這並不是說兩者不能共存。像所有其他事情一樣，它歸結爲實施。只要記住務實，並根據需要調整方法，而不是相反。

Answer 6

敏捷開發和PMBOK不應混用。如果你這樣做，你很可能會以Scrummerfall結束。我看到這種情況發生在傳統項目經理身上，他們轉化爲敏捷。他們只是不明白，似乎回落到舊模式。

但是，在我看來，SCRUM並未涵蓋項目管理所需的一切。它有點缺乏統治的總體戰略。一種可能性是將SCRUM與EVO project/value management或其他價值管理方法相結合。然而，它需要與客戶簽訂不同類型的法律合同。因此，項目更像是一個持續的過程，受時間限制，受到預算的限制，或者當顧客感覺他的收益低於其投資（使用業務案例和目標度量）時結束。另外一個好處是，客戶會把你看作是一個長期合作伙伴而不是短期供應商。