Scrum是最經常使用的一種敏捷技術。它不是編碼相關的;相反,它更側重於組織和專案管理。如果你有空,讓我告訴你關於我所工作的團隊,和我們團隊如何採用Scrum技術。

一個小故事

Scrum的根源實際上早於敏捷時代。

  Scrum的根源實際上早於敏捷時代。第一次提到這種技術可以追溯到1986年,由 Hirotaka Takeuchi 和 Ikujiro Nonaka為商業產品開發所提出的。首次正式定義Scrum是由傑夫•薩瑟蘭和Ken Schwaber在1995年在論文中寫到的。
  在2001年，敏捷宣言出版後，由Ken Schwaber和Mike Beedle合著的SCRUM的敏捷軟體開發這本書和SCRUM 越來越受歡迎.

一些事實

  Scrum給出了一系列規範,鼓勵團隊去跟進。它還定義了幾個演員——或稱為角色（如果你更喜歡這個術語）——加上產品和定期計劃的迭代過程。這裡有幾個工具很適合Scrum過程。我將在本文中引用一些,但我認為最有用的工具是白板和便籤。

“Scrum最佳實踐”列表是不存在的,因為團隊和專案背景的實際情況勝過其他注意事項。——Mike Cohn

角色

  就從豬和雞開始說吧。雞問豬是否有興趣一起開一家餐館。雞說,店名可叫做“火腿和雞蛋。豬回答:“還是算了吧,謝謝。這樣我是生產人員,但你只是個參與者!”
  這就是Scrum !它指定一系列具體的角色,其中分為了兩組:

• 生產人員——那些直接負責生產和最終產品的交付的人。這些角色作為一個整體,包含了團隊、其中的成員、scrum負責人和產品所有者。
• 參與人員——代表著對這個專案感興趣,但不直接參與生產和交付過程的人。這些角色通常是利益相關者和經理。

我們是怎麼開始的

  一切都要基於奉獻和意願。如果希望團隊高效、有創造力、並且能夠按時交付，就需要有人去嘗試一些敏捷技術。不管scrum是否適合你的團隊，但是毫無疑問從它開始是一個好的選擇。發現你的團隊中有人願意幫助別人，或者你願意承擔引入Scrum的責任。
  你可能會問為什麼你應該關注其他像我這樣做Scrum的團隊。因為你應該關注的是我們都是如何通過借鑑由其他人做成功的，尤其是那些做的很好的事例，來學習和做好Scrum的。——Mike Cohn
  我的團隊是一個很有才的團隊，已經瞭解很多關於敏捷的東西了。我們從瀑布開發轉向一個更敏捷的過程，並且經常釋出。我們成功地每三到六個月釋出一次，並且每個版本的bug數量都很少。
但是，我們依然遠沒有達到我們今天的水平。我們忽略了過程，或者說是規則，這迫使我們去改變對於產品和過程的一些看法。就在那時，我們的團隊經理向我們介紹了我們那時從來沒有聽過的一個詞——Scrum。
這個人承擔的角色是Scrum管理者

Scrum管理者

  Scrum管理者無疑是最重要的角色之一。這個人是負責連線產品所有者（下文中定義）和團隊（下文中定義）的橋樑。這個人通常擁有強大的技術知識，並且積極參與開發過程。他或者她也會與產品所有者溝通使用者需求，並且安排一些代辦需求。
  Scrum管理者協調的是整個開發過程，不關注微管理（這個團隊自己組織）。但是為了提高團隊的互動和自組織能力，在這個過程開始的時候，Scrum管理者可能會選擇部分團隊的模組來進行微管理。
  Scrum管理者有很多責任，我將在這個講解的過程中逐一提到。

介紹術語“小版本迭代”

  在我看來，我們三到六個月釋出一次沒有任何問題，但我原先無法想象我們有如此頻繁的釋出計劃。我認為這太快了，而且並沒有提供完整的除錯產品所需的時間。不過接著我們的Scrum管理者給我們介紹了這個詞“小版本迭代”。
  迭代：是搭建Scrum的基本單元。通常經過一週至一個月的版本迭代，產品會處於一個穩定的狀態。
  這聽起來很不可思議。版本每週都穩定—-這不可能！但是事實上是很有可能的。首先，我們減少我們的生產週期，從三個月到1個半月，直到只需要一個月。在這期間，我們的做法不作任何變化。需要做的只是再製定一些讓週期小於30天的版本迭代規則。規則不是有魔力的；只是必須對專案有益。
  如果我沒記錯的話，第一個明顯改變是出現在構建過程中引入版本迭代計劃。

版本迭代計劃

  這是其中一個Scrum會議推薦的建議。在新的版本迭代之前，團隊、產品負責人、Scrum管理者就要開始計劃下一次迭代。會議可以開一整天，但是更小的版本只需要2個小時左右。
  我們這個過程主要是審查產品需求，並且決定哪部分的使用者需求要被納入下個版本。這些是由整個團隊、Scrum管理者和產品負責人共同討論後決定的。

產品負責人

  通過設想哪些小功能將提供最大的價值來制定產品方向，這可能是最難的任務。
  這個人負責定義使用者需求和維護產品需求。他或者她也是團隊和更高的管理層之間的橋樑。產品負責人需要評估來自股東、更高的管理層、使用者和其他渠道反饋來的需求（如bug報告、使用者調查等）。
  他或者她應該重視這些需求，為股東在最短時間內獲得最大的價值。產品負責人可以通過制定一個可以及時完成的最有價值的使用者需求來實現。這聽起來很複雜—-確實是這樣！實際上，通過設想哪些小功能將提供最大的價值來制定產品方向，這是最難的任務。但從另外一個角度來看是很簡單的。比如有可能有一千個使用者需要這個特定功能。在這種情況下，正確的選擇是顯而易見的。
  若是一些使用者代表了大部分的使用者群，這會為你新增這個特殊功能增加了保障。
  但是，怎麼樣實現到讓100%的使用者群的對這個特定功能都有需求？這是一個艱難的抉擇。所以你可以選擇增加當前使用者的忠誠度，或者增加使用者群。哪個是正確的選擇？這一切都取決於當前的業務方向和產品負責人為產品所做的一些定位。
  在我們公司，這些決策會知照到整個團隊。這不是一個Scrum過程的要求，但這個方法對於新團隊來說很有用。資訊的分享有利於大家理解為什麼會有這些決策，以及理解為什麼有些可能看似很明顯的功能被推遲或放棄實現。