如何有效的在一個研發團隊中推行Scrum？

12-26

團隊以前沒有推行過Scrum，了解Scrum的人不多。

我覺得最好的推廣方法就是不要提scrum的概念。把scrum的實踐換一種說法。
計劃會議第一部分：叫做需求分析會議。由產品經理給大家講解需求，大家討論。
計劃會議第二部分：叫做任務分解會議。由研發團隊來對需求進行分解，確定任務的負責人和初始的估算。
站立會議：改為晨會，或者碰頭會議。
演示和總結，可以仍然叫做演示和總結會議。

不要提po, team, scurm master的概念，沿用傳統的概念。
很多時候研發團隊只是為了反對而反對，他們反對的只是新的概念，對他們來講陌生的東西而已。需求分析，誰都不會反對。任務分解也沒有人會反對。

開發實踐方面做好自測、互測，加強平時的互動，設計到對外介面的地方一定要評審，代碼規範要加強。做好scrum還是可以的。

1. 拉（pull）比推（push）更有效。如果團隊沒有意識到這東西有價值，而是被人應推給他們，結果如何應該是可以想像得到的。
2. 如何創造出「拉」的需要呢？首先可以做一些知識普及型的工作，幫助團隊了解Scrum，知道有Scrum這麼一個東西；其次是幫助團隊去理解，Scrum和當前團隊所面臨的一些問題之間是否有關係、有何關係；隨後，等團隊逐漸理解Scrum可以帶給他們好處的時候，再推動Scrum的實施採納就是順理成章的事情了；再之後就是提供各種支持幫助他們切實地使用起來了。
3. 隨後還要繼續跟蹤，觀察使用Scrum的初衷有否被實現，以便採取相應的行動。

敏捷是一種做事方法。

首先找到團隊使用敏捷方案的必須點，也就是痛點。對症下藥更容易找到切入點。

其次作為scrum master的角色要對敏捷的理論瞭然於胸，有好的自我管理，時間管理能力，才能影響團隊，培訓團隊採用更高效的開發模式。

不管什麼模式，都是實踐中不斷回顧和總結。自我管理的團隊是一個終極目標。

首先要看你們是不是真的需要敏捷吧，很多項目瀑布式可以解決不一定非要上敏捷，成員能力或者認同度不夠，強迫上就有可能變成偽敏捷。當然我覺得敏捷需要一種提倡，一旦一個團隊開始嘗試敏捷，在渡過了初始難熬的四五個Sprint 之後，就能一定程度上體驗敏捷的好處，這種理念的貫穿也對團隊成員的成長非常有好處。

我們的首席給了敏捷四個價值觀：

個體的互動要高於流程和工具；
可工作的軟體要高於詳盡的文檔；
客戶的合作高於合同談判；
響應變化高於遵循計劃。

這四點價值觀是最能體現敏捷開發的核心的東西，其精髓就是擁抱變化，而不是控制變化。
敏捷最被誤解的一點應該就是「照章辦事」，能夠吸取敏捷的一些細節，對於研發團隊的改進就有了很大助益，懂得選擇合適的方式和工具也是敏捷之道。最好是先小Team 的人認同Scrum 然後小範圍內試驗，推行起來之後再往其他團隊推廣，其中很重要一點也是上面石同學提到的，領導要支持。

申明：利益相關。推薦Worktile 讓工作更簡單，非常適合研發團隊做協作，產品的設計理念跟敏捷也較為相似，出的解決方案 - Worktile 研發管理解決方案也展現了一些實現細節，一定程度後上提高研發團隊工作效率，敏捷是一種理念，在團隊成員能力每個人都非常高的情況更容易理解和實現，如果達不到，在目前的工作方法上有一些改善和提升，個人覺得就非常有幫助了。
附上線上討論過Scrum 怎麼玩的總結：Scrum到底怎麼玩兒？——BB-Talk #001回顧-Worktile
再附上我們研發同事研究的Scrum 怎麼玩的腦圖

如果是純研發項目，而不是需要快速交付的，建議不要採用scrum。
任何一種方式，都一定是要在有確實需求的前提下採用，不要為敏捷而敏捷。

不用過多的強調你是敏捷scrum什麼的。有些基礎都是要做：
1.樹立願景.
2.強化基礎設施, 引入共享工具, 以增加項目信息的透明(transparent), 交流, 共享.
3.工作自動化的提取.
4.反饋/溝通得到及時處理, 換位思考.
5. 持續改進(檢驗(inspect)-&>調整(adapt).

建議先從比較容易的實踐開始，讓大家容易上手並看到效果，比如站會和白板。

整本《硝煙中的Scrum和XP》,InfoQ上有，也出書了最近，然後照著做。其實推Scrum的過程實踐很容易，但是關鍵還得看兩個點。一是團隊的敏捷基因的培養，大家接受不接受？有沒有敏捷的精神？如果沒有怎麼培養？這是最難的。另一個就是技術架構，比如測試框架，能不能做到很容易寫單元測試，單元測試寫的到不到位，還是為了寫測試才寫測試，還是該測得都沒測，測得全是不用測的；CI環境是否已經搭建，代碼質量監控體系是否搭建，這些都是必要的。

人的因素永遠是第一位的, 首先要有共同的價值觀, 共同的目標, 人人為我,我為人人, 團隊里要是有一兩個人不負責任, 不願遵循敏捷的原則, 那麼最好改組團隊, 敏捷的實踐不是一朝一夕就能一蹴而就的, 從少到多,從易到難, 先把測試驅動,持續集成等基礎工作做好, 改變思想, 每一個scrum sprint都是一個小瀑布,不過咱們一次少做一點, 做好一點

Scrum的執行需要結合項目的實際，向要扭轉觀念不是一朝一夕的事情，可以將Scrum中一些好的搬出了進行應用，這樣如果大家獲得了甜頭（效率的提高帶來的正常下班等等），才會逐步認可Scrum的東西，當然更重要是獲取到領導的支持，要為失敗做準備，為失敗買單可能是難免的。
另外：Product BlackLog這個東西還是比較難搞的，搞不好就會走很多的彎路，這要求Product Owner需要有很強的需求分析和協調、溝通能力，確認之後，再進行優先順序排序；Sprint的時候，需要提前認清任務之間的依賴關係，避免一些麻煩

先做一些培訓吧。
關鍵是定好每個迭代周期，嚴格控制進入scrum的需求，確定開發里程碑和交付的內容。

首先，Scrum是開發活動的方法論，沒有領導的支持是沒戲的。
其次，Scrum只是敏捷開發眾多的方法論之一。在實踐之中，很少有純粹的Scrum。大多數時候都是根據團隊和業務將各種敏捷方法論中的可取之處拿過來。
最重要的一點是搞Scrum這些東西的目的，不是為了新鮮好玩，而是為了提高生產力。不能出活兒的東西不要搞。

上面是一些原則，如果你有領導的支持、有決心推行Scrum、覺得Scrum能夠改善大家的生活，那麼至於怎麼開始搞，愚見如下：
1、從個別小團隊開始搞，培養氣氛積累經驗，搞出成果了再慢慢擴散
2、條件允許的情況下，至少請敏捷教練對骨幹進行培訓，手把手的教效果最好
3、流程搭建不難，難的是執行不走樣，Scrum的很多流程需要team lead付出很多時間，這些時間不能省，否則團隊的執行效果會大打折扣
4、CI的重要性甚於測試，CI的收益很高，但是成本也是很高的，至少需要一個專人來維護和開發，要有心理準備

先從培養團隊的敏捷態度開始吧...

可以了解一下ADAPT模型：

A(Awareness)意識：當前的過程已經不能實現可接受的結果

D(Desire)渴望：把Scrum作為一種手段來解決當前的問題

A(Ability)能力：有成功實施Scrum的能力

P(Promotion)推廣：通過分享經驗來推廣Scrum，從而能讓我們記住並且讓他人看到我們的成功

T(Transfer)傳遞：把實施Scrum的影響傳遞到整個公司

具體的實施細節我們可以私下聊聊，把你的QQ通過私信發給我，我加你

我現在一家小私企工作，領導讓我擔任Scrum Master，我之前沒有接觸這個概念，也沒有開發經驗和管理經驗。然後我網上查找，理解了一些淺顯的理論。目前公司是招聘我來試行推廣敏捷開發。但是我在公司實踐感覺非常困難。不知道從何開始入手。現在公司的項目有些是外包的在客戶那邊。也有一個項目在公司內部。公司招聘了一些實習生，應屆生。培訓他們TDD技術。然後現在這個項目是培訓生來做。我很想做好我的工作，該多看哪些書籍？怎麼去發現問題，提高溝通協調能力和管理能力？

最近也打算在目前服務的公司推行Scrum，最需要得到解決的有兩點：1.團隊能的人對Scrum了解不多；2.需要公司高層的強有力的支持

先由引入人指導小規模試用（3-5人左右規模），然後進行全體培訓，然後強制推廣。