測量開發速度

  你想知道在當前迭代版本中自己的表現如何嗎？常用的方法就是通過燃盡圖來看：

  上圖中有五天的工作時間，假設我們能完成該迭代版本中的十個關鍵功能點。圖中的每個點的數值代表每天結束時待完成的需求。綠色線表示一種理想的狀態：每天都固定完成兩個功能點。而紅色線則表示我們實際工作完成情況，或者說是真實的開發速度。
  這幅圖並不是在任務板上的圖片，但我們團隊通常會拿A4紙為每個專案做一份燃盡圖，放到任務板上。當一天結束的時候，團隊裡會有個人來負責記錄當天工作的完成情況。如果程式設計師們一條一條實現需求時，很容易就能知道還剩多少需求未完成。
  沒有完成一半的需求，完成就是完全完成，沒完成的話不能記錄到燃盡圖上。
  當然，這個假設基本會失敗。一開始會和估計的一樣，但接下來發生的事情則不可避免。由於無法準確預測你能實現多少個功能點，實際上第一張燃盡圖可能會像這樣：

  我們的第一張燃盡圖肯定是和這張圖類似的。我認為我們甚至連承諾的一半都完成不了。為什麼呢？因為預估是很困難的。無論你做什麼，或者你多麼有能力，當別人問你如何完成一件你之前從未做過的事時，你很難能給出一個準確的預估。不過不要難過，儘自己最大努力就好。隨著時間的推移，這樣的事情將漸漸變得容易。在面對小版本的功能點時，也許你能夠達到70%的準確預估。如果版本比較大，那準確率可能也會低一些，因為會有更多的功能點需要預估，這時導致錯誤的因素也在增加。
  當發生上述情況時，你做了些調整。在下個專案中，你只用了四個節點，像這樣：

  這又是一種不好情況：你太過保守，因此將任務提前完成了。基於之前失敗的預估來看，團隊經過調整之後出現這種結果是很正常的。但從另一方面來看，這還是失敗了。
  問題出在哪兒呢？當完成計劃任務後你都做了什麼？另一個需求嗎？你是如何將這些進度記錄到燃盡圖中的？此時不能再按原本的線來畫燃盡圖。
  當使用燃盡圖來記錄工作時，建議對最後的3-5張圖取平均，作為下一個專案的參考依據。當然，一開始你沒有這些資訊，所以失敗也是很正常的，沒有關係。
  一段時間後，你的燃盡圖將會越來越像第一張例圖：大部分情況下，能夠維持不變的速率處理一個又一個關鍵點。

速率？

  這個詞表示開發速度，與你在專案中能夠做多少事情有關。敏捷開發中有一個很關鍵的概念之一便是持續不變的速率，使團隊能夠持續交付。在傳統的專案管理中，專案做得越久，速率就會越慢。有一種複雜而又強硬的力量使得開發速度減慢。
  敏捷開發的方法論和技術的目的都是維持持續的開發速度：現在交付得快，以後要交付得更快。這要如何實現呢？Scrum是問題的關鍵之一。其他關鍵點也包含了開發讓程式碼和開發過程更順暢的技術，例如XP（極限程式設計），結對程式設計，TDD（測試驅動開發）等。所有這些合起來，能夠讓一個團隊更加出色。
  所以，我們想要測量速率的話，真正該做些什麼？

提示：測量速率是為了能更好地做出預估，而不是用來判定一個團隊或其成員的能力。

  通過速率來確認團隊能做什麼、想做什麼、收穫更多、變得更好。永遠不要用速率來評判團隊或計算程式設計師的生產率。

不停地回顧和提升

  隨著最初幾次迭代的進行，我們的流程管理員完成了整個團隊的搭建。開始時的幾周，他一直在問我們有沒有什麼地方做得很好或做得不足的。一開始你可能會對此感到不舒服，但這的確非常重要。描述過去幾周你感受到的不足之處，這會形成一種意識。另外這也能提醒你哪些地方做得很好。
  這些會議更像是一種回顧，給了一定範圍來突出好和不好的事情。以下是幾個我自己回顧的例子。

不足之處

• 團隊成員間的爭吵過多
• 團隊成員X和Y在結對程式設計的時候不能很好地合作
• 我們在許多小事上浪費了太多時間，比如X事件和Y事件
• 我們並沒有全程都結對程式設計
• M模組沒有進行單元測試

  當在討論問題時，儘量不要代入個人情感，說說哪些事情困擾了你。這是團隊解決問題的唯一方法。最重要的是，要立刻給每個問題提供一個解決方案。不能只是將問題列出來，然後就忘記，應該要停留幾分鐘，讓整個團隊一起考慮在接下來的一週怎麼避免出現同樣的問題。

做得好的地方

• 我們按時完成任務
• 我們不用吵架，可以正常溝通
• 我們中的一部分人變得更加尊重建議和想法
• 我們用TDD方法完成所有程式碼的編寫

  重申一遍，特別是在專案剛開始的時候或是對一個初級的程式設計師來說，應該儘可能多地突出做得好的地方。例如，能夠將所有程式碼都按照TDD方法完成，對於一個新團隊來說算是一個比較大的成就了，讓他們為之興奮，並想要做得更多。這對於一個老團隊來說也是同樣有效的，找些別的事來突出就好。

我想知道你在這次迭代中做了什麼

  demo是用來告訴利益相關人員（和產品負責人）專案進展如何。
  標題來自我的流程管理員。在某種程度上，他也可以算是產品負責人。在一次迭代結束的時候，他會讓我們上報我們都做了些什麼。我們準備一個demo或在可控環境中的工作示例。
  Scrum在每次迭代結束的時候需要這些demo，demo要在上述的回顧會議之前做好。團隊要準備好特殊的環境，確保產品能夠正常展示這次迭代中的所有功能特性。demo是用來告訴利益相關人員（和產品負責人）專案進展如何。
  你可能會好奇為什麼在每次迭代結束時，對於開發完成的產品要特意提到可控環境。產品的確是要儘可能開發完成，但一些功能特性本身可能還未完成。通常，會有一些功能點較大，需拆分多個版本完成。即產品是穩定的，但有功能特性還未實現。當利益相關人員在看demo的時候，他們希望看到這些功能特效能正常執行。因此在大多數情況下，為了展示這些未完成的功能特性，需要先準備一個特殊的環境。
  另外，通過這些demo，產品負責人將判定這些大功能點是否好用，並決定是否要給客戶釋出一個新版本。大部分情況下，一個功能特性並不完善，但版本釋出能夠帶來有價值的使用者反饋，此時再逐步完善這一功能特性，儘可能地使更多使用者感到滿意。
  這聽起來還挺容易的。你們是一個敏捷團隊，保持和綠線一樣的工作速度，產品將會處於穩定的狀態。快速地準備一個demo有多難？比你想象的更難！
  如果我沒記錯的話，我們團隊需要做至少五次的嘗試才能做出正確的demo。幸運的是，前幾次在展示失敗的demo時，利益相關人員並不在場。

我們仍需要更多的指導

  正是這個時間，我們的流程管理員打算開一個每日例會。是的！每天，每個早上，一個小時！
  我覺得這對一個新團隊來說是件好事，因為成員間互相不熟悉，對專案也不熟悉。像這樣的每日例會叫做Daily Scrum，每天某個固定時間點在團隊內部開會。這個會議要在各自的工作開始之前進行。我們團隊是每天早上10進行例會，這並不容易。不過這個決定是正確的。
  每日的Scrum會議都比較簡短（不過超過十五分鐘）。這能使團隊裡的每個人都知道誰在做什麼事情，並討論出開發專案中的難點和瓶頸。

提示：為了確保會議時間較短，我們都站著開會。人們通常站15分鐘之後感到疲勞，用來開會剛剛好！如果你的同事找了個地方坐著休息，那麼會議時間通常會持續較久。

在站會中，每個人都必須回答這三個問題：

• 你昨天做了什麼？-要簡潔地回答-最多2~3句話。
• 你今天打算做什麼？-同樣要簡潔地回答，像這樣“我今天打算完成這個需求。”
• 你的進度有什麼問題嗎？如果答案為是的話，這些問題能快速解決嗎？如果知道答案的話，回答時要突出問題和解決方案，但不要對細節進行討論，會議仍繼續進行。流程管理員需記錄下這些問題，和團隊成員一起解決這些問題，不過要在會後進行。

  對團隊來說，解決開發人員的困難和阻礙是高優先順序的事，以便他們能儘快繼續開發工作。通常情況下，個人的問題都能自己解決；有些時候他們需要團隊其他人的幫助；還有一些時候，問題比較嚴重，需要整個團隊的人停下手上的工作，一起解決一個問題。
  我記得我的團隊有幾次在不同情況下遇到過這樣的大問題。有一些任務和需求，剛看的時候相當明確，但當有開發人員深入鑽研這個問題時，明確的地方慢慢變得有問題或是錯的。我們多次發現第三方庫無法提供基本功能的支援，然後停下手中的工作去找一個更完整的庫，甚至我們自己寫一個庫來解決這一問題。
  我們大部分程式是基於PHP開發。在某些時候，我們不得不將我們的專案接入VMWare。我們重新看了一半VMWare API的正式庫，發現有Java和Perl的版本，也有非官方的Ruby版本。當確認我們能夠使用其中一個版本後，只要在PHP中加入一些exec()呼叫，獲取輸出資訊轉化為字串。我們認為解析資訊是件很簡單的事。
  但結果是，接下來的步驟更加難以實現。沒有任何API庫能做到我們想要的樣子。基本上不是棄用了，就是不完整，幾乎沒可能解析出輸出資訊。最後，我們只好做了件沒人做過的事情：在PHP中引用VMWare的 API庫。不幸的是，除此之外沒有任何可行的方法。
  問題很嚴峻，導致進度推遲了一週！當然，我們的產品負責人立刻注意到了這個情況，之後我們制定了新的計劃，添加了新的需求，其中就包括建立API庫。
  通常你的問題會小很多。人們經常會被複雜的邏輯繞暈，但這種情況通常在第二天早上的時候就能夠有想法和解決方案。其他情況下有可能只是走錯了方向，只要團隊成員幫忙回到正軌就好。這些基本上就是典型的問題了。

結論

  至此我們可以得出結論。至少，這些是我們團隊開始Scrum方法的經驗。有些規則是非常有用的，有些則還好。進一步來說，有些規則只在短期內有用，而有些至今仍受到我們團隊的推崇。
  我只能說你若想實現敏捷過程，試一試Scrum方法，並總結自己的觀點。我相信你一定會找到點兒什麼運用到你的團隊中。想要敏捷，要從你的工作方式開始改變，為了你的專案和個人，不要害怕加入你自己的規則。
  畢竟，敏捷是適應，不是盲目地遵循一套事先就決定好的規則。