Scrum作為目前互聯(lián)網(wǎng)公司實施敏捷（Agile）最流行的一種方式，也在不斷地被越來越多的實施者們以他們的方式進行“改進、優(yōu)化”。很多時候，流程方面的裁剪確實是必要的，或許是軟件的形式不同、公司的氛圍不同，可一些最基本的游戲規(guī)則都被更改至面目全非，那還能稱之為Scrum嗎？

這個系列會分享一些“偽”敏捷的實踐，希望能夠幫助大家在實施敏捷的過程中避免注入此類的情況。

重申角色的定位

敏捷宣言的創(chuàng)始人之一Ron Jeffries把“偽”敏捷的實踐戲稱為“Dark Agile”，“黑暗”敏捷，也就是軟件開發(fā)界的黑暗料理啊。讓我們來看看這些實踐是如何把敏捷帶入深淵的。

Scrum中有三個角色組成了Scrum Team，

• Product Owner
• Scrum Master
• Development Team

實際上真正輸出用戶價值、商業(yè)價值的Development Team，是他們（通常為開發(fā)、測試、實施人員）將需求真正轉化為產品輸出。那么其他兩個角色的價值在哪里？

Product Owner

首先是Product Owner（PO），這個角色的名稱其實會讓人產生一些誤解，中文通常翻譯為“產品負責人”，其實最終負責產品交付、質量的，還是Development Team。那這個負責人負責什么呢？

Scrum Alliance的Scrum Guide里寫道：

The Product Owner is the sole person responsible for managing the Product Backlog.

Product Owner其實是Product Backlog Owner，他負責管理“產品待辦列表”。通常來講，PO作為所有需求方的代表，管理產品要提供的功能，換言之，任何人想要更改需求，都要先通知PO，由PO決定是否更改產品待辦列表。

PO還要負責能夠清晰地向Development Team解釋需求，并且讓產品待辦列表開放可見。同時負責排列事項的優(yōu)先級以保證產品價值的交付。

所以如果你身邊的PO，或者你自己就是一個PO，檢查以下幾點，看看是不是已經“黑化”了：

• 給Development Team設置deadline
  Scrum按照Sprint的方式進行迭代式的交付，deadline本身就不應該出現(xiàn)。更何況PO并不應該直接對Development Team進行指揮或者管理。Development Team應該是自組織、自管理的。
• 插任務到Sprint Backlog
  前面說過，PO負責管理Product Backlog，Sprint Backlog不在PO的管理范圍之內。決定Sprint要交付的內容的，并不是PO，而是Development Team。PO只負責根據(jù)優(yōu)先級排列Product Backlog。
  而在Sprint過程中插入Task，這種做法非常不可取，不僅會打亂team的節(jié)奏，也會讓team之前的承諾變得毫無意義。
• Product Backlog混亂
  如果PO無法提供一個清晰可理解的Product Backlog，那也會是開發(fā)人員的噩夢。許多PO無法在下一個Sprint開始之前確定任務的優(yōu)先級，這將直接導致Sprint無法正常開展，更別說交付有價值的內容了。

合格的PO，是一個充分了解產品的“產品代言人”，開發(fā)團隊能夠從PO這里直接或間接得到所有關于產品的問題明確的答案。這樣才能讓開發(fā)團隊在“需求無障礙”的環(huán)境中火力全開。

Scrum Master

Scrum Master首先得是個Master，也就是中文里的“大師”或者“師傅”，需要精通Scrum，能夠幫助Team良好的運行于Scrum的各個過程中。

再來看一下Scrum Guide:

The Scrum Master is a servant-leader for the Scrum Team.

這里有兩點需要注意，第一，Scrum Master是一個servant-leader，并不是一個領導者，而更偏向于服務者。第二，Scrum Master服務的對象是Scrum Team，也就是說包括了PO和Development Team。

看看以下幾個“黑化”了的Scrum Master:

• 命令下屬匯報工作
  Scrum Master并不是任何人的上級，Development Team作為Scrum Master的服務對象，更多的是從Scrum Master那兒獲取流程上的建議和幫助，從而提高效率和工作的價值。
• 強行推行政策
  Development Team作為自組織的團隊，Scrum Master不應該強行推行自己的政策，這不僅會打擊團隊的自信心，久而久之也會讓團隊喪失主動性。
• 按照自己的意愿做出承諾
  還是那句話，做出交付承諾的，應該是Development Team，Scrum Master不應該插手或強迫。

Scrum Master應該提供Scrum流程方面的建議，組織各種會議以及幫助團隊形成適合團隊的工作模式，保證團隊成員對產品的認識都在同一水平上，同時在團隊之間消除溝通的隔閡，實現(xiàn)“交流無障礙”。

合格的Scrum Master，是可以“消失”的Scrum Master，當Team完全熟悉Scrum之后，應該可以省略這個角色。

Only members of the Development Team create the Increment

只有Development Team的成員真正創(chuàng)造了產品的增量。

之前也說過，產品的輸出來自于Development Team，所以真正的產品負責人，應該就是Development Team本身，每一個成員都應該對自己的輸出的質量和數(shù)量負責。只要是沒有意識到這一點的開發(fā)人員，都已經“黑化”了。

Development Team對每個Sprint做出交付增量的承諾，都應該基于自己能力和意愿，而不是基于壓力或是誘導。而PO和Scrum Master的存在，可以讓團隊更加專注于自己的工作，減少流程、需求上的噪音。

Scrum Team的三種角色是完全扁平化的，至少在組織架構方面，Scrum沒有上下級的概念。如果你的組織在上面加上了上下級的概念，那就要謹防其帶來的額外障礙了。

“黑暗敏捷”讓本來很輕的Scrum變得很重，或許是妥協(xié)，或許是曲解，都應該盡量避免。