Scrum是用來發現問題的
原文： SCRUM WITHOUT REMOVING IMPEDIMENTS ISN’T SCRUM
作者： MARK LEVISON
譯者：陸其明，愛奇藝公司技術總監，擁有10多年的軟體技術研發和管理經驗。已經出版的著作有《DirectShow開發指南》、《DirectShow實務精選》、《Windows Media程式設計導向》、《指令碼驅動的應用軟體開發方法與實踐》，譯作有《程式碼之道》、《高效能程式設計師的修煉》、《程式設計師的修煉——從優秀到卓越》。
責編：錢曙光，關注架構和演算法領域，尋求報道或者投稿請發郵件[email protected]，另有「CSDN 高階架構師群」，內有諸多知名網際網路公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備註姓名+公司+職位。
機械的Scrum對比真正的Scrum，差別在哪裡？
最近，我和一個朋友聊到了他們公司實施Scrum的情況。他們有些迷茫！在實施Scrum之前，他們經常為了訪問一臺測試機而不得不等上一個小時（甚至更多時間）。實施了Scrum幾年之後，這個問題依然存在。同一家公司，卻把測試伺服器放在另一個國家，於是經常碰到網路問題，導致處於執行狀態的測試中途失敗。這是他們開始採用Scrum之前就存在的問題，一直以來，沒有采取任何措施去解決它。
只有當問題存在於我們的環境之中時，用Scrum去解決才會有效，而且我們必須為之付出努力。
想一想這個基本原則：在每一個Sprint結束的時候，Scrum團隊被要求產出高質量的可用的軟體（或硬體）。質量要達到可釋出的標準。
在每一個Sprint週期內，任何阻止團隊完成可釋出質量的軟體的事情都算是一個障礙，必須要去解決！
而障礙沒有被解決時，通常的原因如下：
- “完成”的定義不存在，不被重視，或者沒有在一個真正公開的地方釋出出來（通常是團隊所在房間的牆上）。【注】“完成”的定義（Definition of Done）是一個檢查清單，是Scrum團隊用來檢驗一個產品積壓工作項是否真正被完成的標準。
- “完成”的定義直到每個Sprint快要結束、至少能釋出的時候才被頻繁更新和改進；最好可以持續釋出。
- 缺少元件支援，或者不是全功能團隊。Scrum對全功能團隊沒有做明確要求，但要求團隊具備足夠的技能，以便在每個Sprint結束的時候都能將軟體的一小塊功能（不只是一個元件）從頭到尾真正地完成。在Scrum框架下允許成立元件團隊，但這樣做會增加協調的成本。【注】全功能團隊（Feature Team）是一個長期存在、跨功能、跨元件的團隊，它能完整地實現客戶提出的很多功能需求，但每次只做一個功能。
- 有壓力，因為每個Sprint都被要求交付更多的成果。很多團隊都有一種持續的壓迫感，他們被要求交付遠遠超出他們能力的成果。這種壓力如此之大，以至於他們常常為了滿足需求而走捷徑。Scrum的設計初衷，就是給做事的人在決定他們能完成多少工作以及如何去完成方面更多的自由。這需要由團隊來表明立場，說清楚他們的能力。只有當團隊張弛有度，有時間暫停、反思和改進，真正的改進才可能發生。
- 組織上的障礙沒有被消除。舉個例子，多個辦公室之間的網路問題，多個團隊之間的協調問題，或者在團隊層面無法解決的其他任何問題。
請記住，Scrum是一種發現問題的工具，而不是解決問題的工具。
為了讓Scrum發揮效力，你的組織必須解決在Scrum實施過程中突顯出來的問題。既然Scrum並不會為你的組織解決問題，如果你對它暴露的問題不跟進解決，你就不是在真正地踐行Scrum。事實上，你只是在機械地搬弄Scrum。
相關閱讀：