Scrum 過程實踐小記

摘要：從去年10月份到現在，在我負責的項目中進行了一些scrum實踐的嘗試，做個小結。
嚴格來說，不能算是真正的scrum實踐，但實踐敏捷的過程本身也是一種“敏捷方法”，所以就算是“敏捷實踐之敏捷開發方法－scrum過程”吧。

一、理論參考：Scrum的實踐（該部分摘自網路）
1.Scrum團隊（5-7個人的小項目組）。　　
2.
Backlog: 急待完成的一系列任務，包括：未細化的產品功能要求、Bugs、缺陷、使用者提出的改進、具競爭力的功能及技術升級等，按優先順序定義出來，這些任務可能不是完整的，甚至可能隨時會更改或添加。
3.
Sprint(衝刺): 通常為30天的迭代時間，把Backlog中的每一項安排在Sprint中，由團隊估算出所需要的時間（按小時記）。
每一次Sprint之後，一定要有可以交付使用的功能。
4.
Scrum會議: 這是與傳統方式最大的區別，每天15-20分鐘的Scrum會議，通常在每天的同一時間和同一個房間內舉行(通常在午飯後舉行)。 Scrum團隊所有人都參加，也可以有旁聽者（但不允許旁聽者指手劃腳）。
在這個15分鐘的會議上，Scrum Master會詢問每個成員三個問題:
　　a) 自上次Scrum會議後的1天裡你做了什嗎？
　　b) 從現在到下次Scrum會議的1天時間裡你準備做什嗎？
　　c) 你在工作中遇到了哪些困難？
每個成員在Backlog條目上所花費的時間會被記錄到Spring
backlog中。 Scrum Master在會上對存在的問題提出即時的解決方案或指導，使團隊不斷向著目標前進。Scrum會議不同於項目會議，對團隊來說，它起到了快速簡報的作用。
5. 通過Sprint Backlog的分析，可以瞭解Backlog的進度，儘早的瞭解所發生的問題；
6.
管理者不在是項目或者團隊的``老闆", 而是協助團隊解決問題的協調者或是助手；
7. 每一次Sprint之後要review，團隊按照既定的Sprint Backlog目標來示範完成的內容。

二、實踐小記：

1．目前的團隊剛好7人，且項目背景提供了可實踐scrum的良好土壤；

2.  小版本迭代：從項目啟動開始，採用最多不超過３周的階段計劃；各個階段根據情況發布系統組建；
注意與傳統方法區別，沒有按固定周期月之類定計劃，而是按目前能預見的周期內定計劃。事實也是如此，根據幾個月的實踐經驗，最多隻能預測三周。

3.  每次階段計劃的時候：功能要求、Bugs、缺陷、使用者提出的改進、具競爭力的功能及技術升級等，先從各成員處收集匯總成為專案工作，並以半天為單位，預估工作量；集體討論確定優先順序，然後排工作量，優先順序低的任務被去除；
可惜的是無法做到讓客戶來幫我們定優先順序；
不到期間我們通過“現場開發”（與客戶方常駐一起）的方式，盡量讓客戶每天能看到系統，提出修改意見；實踐證明，這種開發效率的確要高很多。

4.   每次階段計劃末：統計上個階段每個人任務完成情況、團隊階段任務完成情況、成員工作自我評估滿意度等，並在一個較大周期（一般是3月5日個小階段）後繪製統計曲線；
注意這個曲線一方面可作為項目績效參考，一方面也能夠清楚反映專案計劃、進度控制中的各種問題；

5.      每周都進行有1－2次進度溝通（每次２０－３０分鐘）：互相瞭解開發進度、遇到什麼問題如何解決，需不需要調整細節計劃、內部調整；其中一次是隨機的，一次是固定的，每周五例會。
注意，在周五例會的時候，除了正常的工作溝通，還會進行心情指數、壓力指數調查，並安排相應的娛樂活動，關注每個成員的情緒狀態和滿意度；
關於心情指數，壓力指數，工作滿意度等也會在一個大周期後繪製統計曲線，作為項目階段總結，以持續改進；
其實每周例會最忌諱的是“公事公辦”，應該盡量隨意點，成為大家坦誠溝通的平台，談工作，談生活，發牢騷，情緒宣洩越暢快越好；有條件就到室外去開。
後來我們在周例會中還加入了３０分鐘技術交流時間，輪流有人自發就本周工作中的體會或經驗進行簡短技術交流，不用花太多時間準備，但對團隊知識積累非常有益（交流完了，資料要求進入知識庫）

6. 核心任務，或項目中的關鍵路徑，採取更緊湊的日進度溝通：通常是對裡程碑任務和新加入成員，採取日進度溝通。形式上不是“站立式會議”，多以該面對面隨意聊天、或立即訊息、個人或團隊工作日誌進行。
個人更推薦隨意的面對面聊天，更符合我們的習慣，主導該關鍵任務的人，每天 早上來了，跟任務相關的人打打招呼：
“ｈｉ，搞定了沒？”
 “這麼快啊，你傢伙很厲害嘛。。。”
“哦，請假了啊，沒關係的，先讓××幫你看看。。。”
通過這種很隨意的方式，即達到了進度溝通的目的，又讓大家覺得親切如朋友。如果太嚴肅，反而會隱藏很多問題。

7.      持續改進：一般在3－5個階段過後，往往會進入項目下一“新進程”，這個時候把前面所有的進度統計、成員滿意度統計、問題跟蹤統計、技術問題等資料統統收集起來，進行分析總結，並確定下一階段的改進措施和工作目標。
問題和改進措施非常重要。一般的做法是讓每個人都提3-5個認為團隊工作最需要改進的方面；然後集體再去排優先順序，討論可行的改進措施，然後制定成問題改進跟蹤表（有個軟體平台最好），到下個進程再迴圈；
以我們的實踐經驗，只要前面做好了，這份總結很容易，半天就可以整理好。
總結中一個非常重要的方面，就是對成員的管理。這個大階段內，有人進步非常快，有人一直承擔核心任務，有人總是趕在進度之前（是不是下次應多分配點任務），有人進度延遲較多，滿意度也不高（是不是個人情緒問題，生活中有什麼事情影響了工作？）
針對這些情況，私下裡或正式或隨意的面談溝通非常重要。不解決好人員問題，後面就有很多不可控的風險。

 8.     
人員管理為核心：團隊成員角色識別、個性搭配、技術能力搭配、團隊成員技術發展目標和能力發展目標，及時面談溝通等。
“授之以漁，非授之以魚”：任何能夠讓成員提高的事情，都要絕對遵循這個原則，哪怕相對要花較長時間，但絕對是值得的；任何團隊都會受制於很多現實條件，或許
團隊裡面有2個豬八戒，或許團隊裡面除了一個孫悟空，其他的都還不及沙僧，或是人員變更，這都是不可避免的，所以要提前做好預測，識別團隊角色上的缺陷，儘早進行培養，才不至於落得被動。
關於成員發展問題，以前的太簡單了，好像成員就是發展為專案經理，這就叫職業規划了，其實完全不對路。團隊裡面，當確定目標的時候，一定要從小處入手：如技術方面，某一方面的技術能力擷取突破成為公司專家；某一技術弱項快速提高，達到中等層次；知識面拓寬；
如工作能力方面：語言表達、溝通能力達到團隊最好水平，文檔能力達到團隊最高水平；如角色方面；發展為技術管理角色；發展為整合員和品質保證角色；發展為管理角色等。
這種發展目標實實在在，每個人都能很快看到自己的進步。當然，如果某位成員有成為專案經理的機會，也要鼎力向上級推薦。

 9.     
關於“結對”編程：在某些關鍵任務的設計、調試階段，採用結對方法；
另外：新成員學習期間，每天有1-2小時的結對時間；項目進行單元測試期間，“變相結對”，首先：交換測試（你實現的我測，我實現的你測），然後共同解決問題。

 10.     其他，針對專案經理：

1) 你是否還在當“隊長”，而不是當“教練”？你是否還在“管事”，而不是“管人”？你是否還在懼怕你的成員能力超越了你？如果是，後面都不用看了，無法做到的。
2) 要做到前面所說，前期鋪墊是非常重要的，你的團隊成員都接受了你？你是否已經初步和他們建立了坦誠、同甘共苦的合作關係？
3) 你是否真的花了70％的時間在溝通和協調？
4) 你的團隊角色都選好了嗎？你的工作是否得到了上級支援？
5) 你是否總是主動向客戶和上級彙報工作進展，書面的，面對面的？
6）你是否持續用分解的小目標來鼓勵士氣？
7) 是否經常在小目標達成之後通過各種方式激勵大家（公布問題改進跟綜表讓大家隨時看到團隊的進步？一起活動，上班期間半小時聊天休息，邀上公司領導一起聚餐）
8）除了工作外，你是否瞭解每個成員的個人生活狀況，並隨時能靈敏感覺到部分成員的消極情緒？你是否盡全力幫他們解決了工作上，甚至生活上的問題？
9) 在去除某個資源障礙時，你是否真正做到了絕對客觀和問心無愧？