我心中的敏捷(6)----SCRUM之如何規劃每一天
本文作者:sodme
本文出處:http://blog.csdn.net/sodme
宣告: 本文可以不經作者同意, 任意複製, 轉載, 但任何對本文的引用都請保留文章開始前三行的作者, 出處以及宣告資訊. 謝謝.
引言：
上一篇文章中，我談到了SCRUM方式下對專案的逐層分解概念，而其實，我們的目的並不在於分解本身，我們的目的是在於加強對專案的控制力度，是想讓一個比較大的專案，能按一個比較可控的進度進行研發。逐層分解後，落實在實實在在的研發中時，那就要看具體到每一天的工作來如何安排了。其實，有很多其它的開發方式有比SCRUM更好的專案分解方法，但為什麼那些方式都很容易陷入進度不可控的泥潭呢？我想，其中一個很重要的原因就是，每一天的具體控制沒有作好。OK，那就讓我們一起來看看如何在SCRUM的開發方式下，作好每一天的工作。
正文：
從上一篇文章中，我們可以看到，SCRUM把一個完整的專案研發逐層分解成每2~3個月、每2周，乃至細到每一天的控制粒度，而在每一天的開發實踐中，又會具體到今天準備要完成什麼內容。所以，問題的最終，都歸結於：每一個團隊成員，如何合理規劃自己每一天的工作，如何高效率的完成每一天的工作，如何在每一天的工作中都獲得成長和進步，從而每一天都能獲得成就感、推動產品前進？
作規劃，我們每個人可能每天都在作，但其實，對於很多人來說，“合理、準確的規劃”本身，就不是一件輕鬆的事：無論我們計劃的多周全，總會有各種各樣意外事件出現，從而影響我們原本的計劃，無法在預定的時間內完成。所以，從某種意義上可以這樣說：不存在絕對準確的規劃控制，我們只能從各自的實踐出發，預估到儘可能多的意外情況，提前預留出時間作好處理意外的準備，把在意外事件上消耗的時間儘可能控制在一個可控的範圍內。
總結下來，對於程式設計師而言，我們日常所面臨的工作，大致可以分為：自己單獨完成的工作，以及與別人協同的工作。而具體到每一個人每一天的工作內容上，我的大致體驗是，可以按這樣的順序來提高我們處理事情、以及有效控制事情執行的能力：從簡單到複雜，從單線到多線，從個體到群體，從眼前到長遠。把事情按輕重緩急列出三個優先順序：緊急、重要、一般，然後按優先順序處理這些事情。
限於每個人的技術水平，每個開發者在成長過程中，對自己所面臨的開發任務，都必然要經歷從生疏到熟練的過程，在技術上，也必然都要經歷從探索到使用既有框架的過程。對於一個新手，剛剛開始在一個新領域的開發過程時，總會在這個新領域裡遇到新的問題，有經驗的人，會從自己的經驗庫裡找到針對於新問題的類似求解方案，而沒有經驗的人，只能從頭開始逐漸積累自己的經驗，這是個人成長所必須經歷的一個自然而然的過程。我們需要作的是，要積極思考、積極實踐，如何更快速的去讓新人獲得這種經驗，同時，儘可能減少新人由於缺乏經驗而給專案本身帶來的損失。
再回到新人的每日規劃本身，最主要面臨的困難可能是，由於個人經驗不足無法預估出自己作某功能開發所需要的具體時間。這同樣不是一件可以輕易解決的事，我的建議是：在決定今天準備完成的內容之前，先儘可能細緻的分析這個功能本身所涉及到的資料結構、流程、介面，甚至相關的資源，比如美術資源，策劃文件的配置資源等。有了對於此功能相關內容的完整分析，再來初步評估每一方面的大致耗時，可控點和不可控點。
剛開始作時，可能你的時間預估非常不準確，但是沒關係，只要你堅持這樣細緻分析的作法，隨著個人經驗的不斷積累，你對時間的預估就會越來越準確，你對一件事情的分析和執行也會越來越到位。對於有條件的團隊，如果能有老同事在這個階段輔導、幫助一下新人，協助他們確定每日的工作目標是再好不過的了，當然，這個 “老同事”的角色不見得非要是團隊中的一員，在人手緊張的情況下，專案經理或者其他技術較為深厚、對專案瞭解深入的同事也可以協助新人來完成這件事，不論是誰來充當這個角色，其目的都是如何更好的幫助新人確定好他今天要作的事。
大體上說，規劃自己每天工作內容的方法，也仍然是：細緻分析、逐層分解。但是，為了保證目標的達成，你需要在每日工作目標的設定裡，額外考慮有沒有哪些不可控點，這些不可控點可能會產生哪些問題，如何消除或者更進一步的確認這些不可控點？有沒有什麼方法可以把這些不可控點變成可控的？
“把事情作出來”，“更好的把事情作出來”，以及“又快又好的把事情作出來”，是作事的三個境界。
這是一個永無止境，不斷精益求精的過程，只要你堅持關注“如何把事情作好”這一個根本問題，你就會找到各種各樣可以把事情作得更好的方法和途徑。而，“把每一天的事情都儘可能可控的完成”，是SCRUM開發方式下，提高開發者素質最基本、最有效，同時也是最務實和最根本的要求。
當然，這種方式，對於開發者的自律精神要求很高，即使是我們非常專注於“完成”，不同的開發者也會有不同的想法和作法。懶一點或者不負責任一點的開發者，可能即使自己能在每一天作得更多一點，也會有意的把目標訂得少一點，以達到每日都能完成的狀態。我想說，出現這種情況，都是正常的，但無論開發者如何“偷懶”，不耽誤單個Sprint(每2周)的開發目標是最低限度，不管你如何平衡自己的開發時間，屬於這個Sprint的內容，你都要儘可能按期完成。
從另一方面來說，我們應該鼓勵、嘉獎那些總是每日完成得更多一點的同事，應該努力在團隊中形成你追我趕的氣氛，對於超前完成或者超額完成的人，可以給予不同形式的獎勵，這個獎勵可以是物質上的（獎金），也可以是精神上的（完成狀態通報郵件），或者可以是時間上的（提前完成的，剩下的時間可以休息、放假或安排跟專案相關的自己的計劃，比如看看書，找找資料，瞭解一些本行業的最新資訊等）。
也就是說，從團隊成員個人而言，我們可以通過細緻分析目標需求，逐層分解自己的工作目標，從而制定出更加符合自己實際情況的開發時間計劃。對於團隊而言，則可以通過懲戒後進、獎勵先進的方式來鞭策大家形成一個你追我趕的研發氛圍。從對專案的控制上來說，我個人非常反對那種慵懶的工作作風，作事情不緊不慢，作規劃不明不白，整天糊里糊塗混日子。
富有激情的開發狀態，來源於你給自己設定的開發目標以及為此目標所作的各項努力，在這些努力裡，準確規劃是第一件需要作的事。作規劃，剛開始時，不用把目標設定的太高、太遠，要儘可能近、儘可能容易實現，這樣，你就會在“不斷按期完成開發任務”的成就感裡不斷追求新的更高的目標。
而同時，SCRUM開發方式本身，也給開發者提供了最好的自律手段：晨會。
根據習慣的不同，每個人作規劃的方式可能都不一樣，我是這樣來作的：
1.每天下班前，想一想明天準備作哪些事，考慮一下作這件事大致需要的步驟、環節、所涉及的人與資源，理出銜接關係和先後順序；
2.使用google calendar記錄下明天準備完成的所有事情；
3.第二天來上班時，按google calendar上記錄的內容參加晨會以及驅動自己今天的工作。
除google calendar外，用於記錄每日工作內容的軟體，還有一個用得比較多的Rainlendar，它與google calendar相比，優點是可以把今天的工作目標直接顯示在桌面上，可以時時看到，缺點是，不象google calendar那樣，在任何地點都可以知道哪一天我具體完成了哪些工作，甚至，google calendar可以讓你向別人共享你的規劃內容並設定訪問許可權，這一點特別適用於團隊開發，很便於團隊成員之間互相瞭解彼此每日的工作內容。大家可以根據自己的喜好來選擇一款軟體記錄自己每天的工作內容，當然，如果你只用紙和筆來記錄也可以，但那樣你就無法方便的回顧歷史，反思教訓，總結經驗了。
下一篇文章，我會繼續與大家分享我的敏捷和SCRUM體會，主題將是：SCRUM之資訊共享。