摘要：從去年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) 在去除某個資源障礙時，
你是否真正做到了絕對客觀和問心無愧？
Scrum實踐步驟
1.挑選一位產品負責人 productowner 這個人必須知道自己帶領的團隊需要做什麼 製造什麼產品以及取得什麼成果，必須全面考慮到風險與回報 什麼具有可行性 什麼能做以及他們對什麼富有熱情。2.挑選乙個團隊 team 真正做事的是誰？這個團隊必須能夠落實產品負責人的願景。團隊規模宜小不宜大，一般...
實踐scrum隨筆
1.產品backlog 2.對於backlog的估算 3.燃盡圖 burndown 4.了解團隊的生產率 5.掌握scrum眾多的基礎實踐 scrum和極限程式設計 xp 都要求團隊在每一次迭代的結尾完成一些 可以交付的工作片段。迭代要短，有時間限制。將注意力集中於在短時間內交付可工作的 這就意味著...
漫話 敏捷Scrum研發技術與過程管理實踐
作為一名從事6年研發工作的軟體研發人員，帶領團隊採用敏捷研發技術完成了多個中型專案的開發 整合 測試等工作，具備了3年敏捷專案實戰經驗，體驗到敏捷專案管理過程帶來的好處，提公升了研發團隊的效能，增強了研發團隊的凝聚力。但是，在此過程中，也存在著一系列問題和疑惑。為響應公司關於提高一線技術人員設計研發...