第9章　沒有規矩，不成方圓（3）

阿捷點了點頭，“是啊！這是我們實施Scrum以來出現的一個新問題，以前有大塊的時間用於Coding，所以Review也不會像現在這麼急，所以需要大家發表一下意見，看看我們有沒有什麼好的辦法。”

“在做Sprint計劃的時候，針對每個需要Review的文件或者程式碼，給需要Review的每個人都預留出來一定的Review時間，這樣大家應該就不會緊張了。”小寶說道。

“讓別人Review的時候，應該給出最晚回覆時間，要不然別人也不知道緊迫性。”

“被邀請Review的人，如果不能及時Review，應該提前告訴對方。”

“最好是做一個郵件模板，把需要Review的內容，如文件或者程式碼的儲存位置、修改原因、最遲答覆時間等，都放在裡面，這樣資訊集中。”

大家七嘴八舌地提著建議，看來這個問題還是比較容易解決的。

“好，那我們就按照上面大家提的意見試驗一段時間。”阿捷總結道。

“還有一個非常關鍵的問題，就是關於Burndown　Chart的。大家都知道，想讓這個Burndown　Chart反映出我們專案的真實狀況的話，那我們每天對每個任務剩餘工作量的估計，就應該準確及時。可我發現，有時候我們中總有人忘記更新，譬如在　Daily　Standup　Meeting上說某個任務已經完成了，但看Sprint　Backlog，該任務的狀態還是In　Progress，還有一定的剩餘時間。”

“呵呵，這好辦，忘記更新的接著罰款。”阿紫這個CFO時時不忘增加收入的機會。

“有時候也不是故意不更新的，一忙就忘記了。”小寶好像不更新的次數最多，趕緊出來解釋。

“要不這麼著吧，我們就留三次免罰機會吧。”阿捷建議。

“每個人三次？總共才三個禮拜的Sprint，這樣下來還是不能反映實際狀況。”大民立刻表示反對。

“就是就是！”阿朱也表示贊同大民的意見，“要不然，咱們就給整個Team留三次免罰機會，如何？”

“這個方法可以，跟100米賽跑的規則差不多，雖然不太公平，但可行。”大民表示贊同，小寶、阿紫等人也都沒有異議。

“好！這個問題也有解決方案了，看看大家，誰還有啥建議？或者還有哪裡需要改進？”

大家一片沉默，看來都沒有什麼話題了。

“好！我們今天的成果還是挺豐富的，我下去整理一下，把我們今天討論的這些東西跟以前的總結到一起，形成咱們自己的Scrum　Rule！那今天就到這！”

大家邊走邊聊，陸陸續續走出“桃花島”。

阿紫說：“大家覺得我們下次Team　Building去哪裡玩比較好？”

“我提議去打真人CS，非週末的時候，平均每人100多些。”阿捷這個CS迷，本性不改。

“我覺得去爬爬香山也不錯，好久沒去了！”阿朱提議。

“去後海吧！先划船，然後泡吧、殺人！”大民這個*分子，每次的提議都很奢侈。

小寶插了一句：“去打Golf吧，我都建議了好幾次了！”

“好啊！好啊……你請客我們就去！”阿紫開始起鬨。

大家吵吵呼呼地回到格子間，引來其他Team的一陣側目。阿捷這個團隊的傳統一直就是這樣，人不多，但每次開會都能聽到他們的笑聲。

回來的路上，阿捷順路到產品經理李沙那裡，討論了一下關於Product　Backlog條目更改的問題。讓阿捷沒有想到的是，李沙認為這個問題根本不是問題，只要大家新增新條目的時候，利用ScrumWorks工具軟體裡面的主題功能，對每個新條目施加一個“Not　Reviewed”的主題即可，這樣李沙就知道這些新條目了。但是，李沙還是重複強調，對於其他已經存在的Backlog條目，一定不能修改，特別是先後順序。

阿捷回來重新整理了一下Scrum　Rule；　然後分發給大家。

1．每日站立例會遲到，罰款￥5。

2．對於未及時更新任務狀態和剩餘工作量的，整個Team留三次免罰機會，以後再有人違反，則罰款￥5。

3．對於