點滴記錄裡有兩篇文章梳理和回顧了我學習PMP和ACP的經歷，這邊文章記錄我從項目經理到ScrumMaster的點滴。
把敏捷框架實際運用到我項目裡是在2016年的一個項目，也是我第一次當ScrumMaster，該項目是從0到1 建設一個大數據平臺，當時採用敏捷和傳統並行的開發模式通過小步快跑和整體規劃的方式，團隊人數15人在半年時間內完成大數據平臺的落地，併為公司所有上層業務系統提供底層數據能力。裡面用到敏捷框架主要是Scrum，也結合了傳統的項目管理模式，畢竟一個團隊要想一上來就完全適應敏捷並順利開展項目實施是非常困難的，這也算是從傳統轉敏捷吧。
在項目剛開始，我並未完全採用Scrum框架裡所有流程，而是先讓研發人員敏捷起來，項目裡開始有了迭代的概念，有了Sprint Backlog，有了站立會，有了迭代回顧，並且上了看板「物理白板，上面有迭代裡任務進展情況」。現在回頭看從傳統項目轉敏捷，我的最佳實踐就是上看板，先保障項目組內的所有信息透明化，並且讓需求和任務在看板上流動起來。這個最佳實踐到現在我也經常採用。
當時沒有完全採用Scrum框架裡的所有流程，主要是考慮項目組實際情況，在一個從來沒有接觸過敏捷的項目組裡，需要逐漸適應敏捷而不是一刀切，當時我選擇上面幾點（迭代，Sprint Backlog，站立會，回顧會，看板）先運用到項目裡，也是考慮這幾個流程對原有項目管理模式融入度較高，項目組只需要稍微調整和改變就能適應，當項目裡的小夥伴逐漸適應和熟悉敏捷思想和框架後，我在進一步指導他們實施敏捷。通過這樣逐漸轉敏捷，後來分析效果是達到了我的預期。要是一來就全搬Scrum框架，PO就要承擔非常重的職責「PO的能力上限，決定了迭代交付物對用戶產生的價值，研發也不適應採用用戶故事的方式進行需求開發」，在當時行不通會嚴重影響交付物落地。只有真正熟悉敏捷，掌握敏捷思想和理念後在進行敏捷實施才能起到敏捷所期望達到的效果。
我們當時定的迭代週期是兩週，目的是想讓團隊儘快的把敏捷玩起來，在迭代過程中有啥問題和阻力能儘早的暴露。這也是我們團隊的敏捷口號：如果我們會失敗，那就讓失敗來的快些。
就這樣項目逐漸的實施起來，在進行了4個迭代後，我們團隊成員逐漸熟悉了Scrum框架流程，特別是產品經理也對PO在敏捷裡的作用和職責有了深入的瞭解「主要靠ScrumMaster的培訓和指導」，我們團隊開始嘗試著進行Scrum全流程，也就是從：Product Backlog -> 用戶故事 -> 故事優先級 -> Sprint計劃會 -> Sprint Backlog -> 物理看板 -> 每日站立會 -> 燃盡圖 -> Sprint評審會 -> Sprint 回顧會 -> 下一個迭代。
這是我實施的第一個敏捷項目，這裡回顧也只是記錄一個整體過程，從傳統項目管理轉敏捷可遠遠不止我回顧的這麼簡單和容易，裡面有著非常多的理論和思想需要ScrumMaster去掌握和領會的，Scrum框架裡的每個流程點都需要深入進去了解它背後的設計理念，後續我在深入到細小流程點去梳理和回顧。
我們常常看到行業裡的專家或大神，我覺得他們其實就是針對某個知識領域瞭解或掌握了比常人更多的知識或實踐「專研的更深入」，然後通過自己的實戰經驗和認知提煉形成了一些自己的方法論和觀點。做到這點之前需要深入理解和學習該知識領域的知識並通過實踐來獲得屬於自己的認知。
「專家」 = 「學習比別人多 + 實踐比別人多 + 總結比別人多」
以下是我作為ScrumMaster的心得體會：
- 需要緩慢地給團隊灌輸敏捷實踐。「不能急，心急吃不了熱豆腐」
- 敏捷變化需要時間，ScrumMaster需要耐心，要像呵護嬰兒一樣地開展工作。
- 在敏捷轉型中，提高情商是提高影響力的基礎。
- 敏捷團隊不是管理他們，而是指導他們。
- 需要學會一對一指導。
- 從“管事”轉變成“交友”。
閱讀更多 小Rain點滴 的文章
