參考位址
http://developer.51cto.com/art/200907/136850.htm
角色
一天，一頭豬和一隻雞在路上散步，雞看了一下豬說，“嗨，我們合夥開一家餐館怎麼樣？”，豬回頭看了一下雞說，“好主意，那你準備給餐館起什麼名字呢？”，雞想了想說“餐館名字叫火腿和雞蛋怎麼樣？”，“我不這麼認為”，豬說, “我全身投入，而你隻是參與而已”
豬是全身投入項目和Scrum過程的人，有三種角色：産品負責人（Product Owner）、ScrumMaster、團隊（Team）。
| 角色 | 職責 |
| ProductOwner | 确定産品的功能 決定釋出的日期和釋出内容 為産品的profitability of the product (ROI)負責 根據市場價值确定功能優先級 在30天内調整功能和調整功能優先級 接受或拒絕接受開發團隊的工作成果 |
| ScrumMaster | 排除産品開發和産品負責人之間的障礙，確定産品負責人流程推動開發工作 教授産品負責人如何實作投資回報最大化，以及如何利用Scrum達成目标 激發創造力和放權，進而改善開發團隊的環境 千方百計實踐和工具，確定每個功能增量都具備潛在可傳遞行 向各方確定團隊工作進展實時更新并高度可視 |
| Scrum Team | 具有不同特長的團隊成員，人數控制在7個左右 确定Sprint目标和具體說明的工作成果 在項目向導範圍内有權利做任何事情已確定達到Sprint的目标 高度的自我管理能力 向Product Owner示範産品功能 |
雞角色并不是實際Scrum流程的一部分，但是必須考慮他們。 靈活方法的一個重要方面是使使用者和利益相關者參與到過程中的實踐。參與每一個評審和計劃，并提供回報對于這些人來說是非常重要的，管理者就屬于雞。
基本流程
在知道Scrum的主要角色後，我們看看下圖中的過程圖：它由Product backlog開始，經過sprint會議從Prdouct backlog挑選出一些優先級最高的故事（story）形成疊代的sprint backlog（一個sprint一般為1個月）。在sprint中會進行每日站會，疊代結束時會進行示範和回顧會議。
術語
Backlog
Product Backlog
在項目開始的時候，Product Owner要準備一個根據商業價值排好序的客戶需求清單。這個清單就是Prodct Backlog，一個最終會傳遞給客戶的産品特性清單，它們根據商業價值來排列優先級。Scrum team會根據這個來做工作量的估計。Product backlog應該涵蓋所有用來建構滿足客戶需要的産品特性，包括技術上的需求。高優先級的一些産品特性需要足夠的細化以便于我們做工作量估計和做測試。對于那些以後将要實作的特性可以不夠詳細。
Sprint Backlog
Sprint Backlog 是Sprint規劃會上産出的一個工作成果.當Scrum team選擇并承諾了Product backlog中要遞交的一些高優先級的産品功能點後，這些功能點就會被細化成為Sprint Backlog:一個完成Product Backlog功能點的必需的任務清單.這些點會被細化為更小的任務，工作量小于2天。Sprint backlog完成後，Scrum team會根據它重新估計工作量，如果這些工作量和原始估計的工作量有較大差異，Scrum team和Product Owner 協商，調整合理得工作量到Sprint中，以確定Sprint的成功實施。
會議
Sprint Planning Meeting（Sprint規劃會）
根據Product Owner制定的産品或項目計劃在Sprint的開始時做準備工作。Product Owner可以是客戶或者客戶代表或代理。對于産品型的公司，客戶就是市場，Product Owner扮演市場代理的角色。一個Product Owner需要一個确定産品最終目标的遠景，規劃出今後一段時間産品發展的路線圖，以及根據對投資回報的貢獻确定的産品特性。他要準備一個根據商業價值排好序的客戶需求清單。這個清單就是Prodct Backlog，一個最終會傳遞給客戶的産品特性清單，它們根據商業價值來排列優先級。
當為一個Sprint定義好足夠多的Product Backlog，并且排列好優先級後Scrum就可以開始了，Sprint規劃會是用來細化目前疊代的開發計劃的。規劃會開始的時候，Product Owner會和Scrum team一起評審版本，路線圖，釋出計劃，及Product Backlog。Scrum Team會評審Product Backlog中功能點的時間估計并确認這些估計盡可能的準确。Scrum Team會根據資源情況看有多少feature可以放在目前的Sprint中。Scrum Team按照優先級的高低來确定開發的先後是很重要的。
當Sprint backlog确定後，ScrumMaster帶領Scrum Team去分解這些功能點，細化成Sprint的一個個任務. 這些任務就是細化的來實施這些功能點的活動. Sprint Planning的這個階段需要控制在4個小時。
Daily Scrum Meeting（每日站會）
一旦計劃階段結束，30天周期的Sprint就開始了。ScrumMaster需要組織團隊成員每天開站會. 這個會議是用15分鐘的時間來讓大家過一下scrum的狀态。在會上，每個團隊成員需要問3個問題：我昨天做了什麼，今天做什麼，遇到哪些障礙。誰都可以參加這個會議，但隻有Scrum團隊成員有發言權。這個會議的目标是得到一個項目的全局觀，用于發現任何新的依賴，定位項目成員的要求，實時的調整當天開發計劃.
Sprint Review Meeting（Sprint評審會）
在Sprint結束的時候召開Sprint評審會. 這個會議最多不超過4個小時.會議的前一半時間用來示範在這個Sprint中開發的産品功能給 Product Owner. Produc Owner會組織這階段的會議并且邀請相關的利益相關者參加。 業務，市場，技術都要做相關的評審。由Product Owner來決定Product Backlog中的哪些功能已經開發完成。會議的下半部分，是由Scrum Master和Scrum Team一起回顧目前的Sprint。團隊評估大家在一起的工作方式，找出好的方式以後繼續發揚，找出需要做的更好的地方，想辦法提升。Sprint評審會結束後，新一輪的疊代又繼續開始（中間最好修整半天或者隔個周末），疊代會一直繼續，直到開發了足夠多的功能去傳遞一個産品。
燃盡圖
概念
燃盡圖Burdown Chart也叫燃燒圖，是罕見的靈活度量，以至于每當有人問起“靈活中有度量嗎”的時候，第一反應就是它。
燃盡圖的全稱，應該是“總剩餘時間的燃盡圖”，就是本次疊代中，所有故事（或拆分的任務，以下僅稱故事）的剩餘時間總和，随日期的變化而逐日遞減的圖。
圖中左側460是疊代開始的第一天，所有故事的未完成時間相加為460天，而在最右側則表明在第17天，所有故事的剩餘時間相加變為0，也就是所有故事都完成了。
為什麼總和會遞減呢？因為每個組員每天都要彙報一件事情：目前正在做的故事，還剩餘幾天，如果昨天剩餘3天，今天剩餘2天，那麼就為燃燒圖貢獻了1天的進度。
由于可能出現“昨天剩餘3天，又工作了一天後本以為會隻剩下2天，結果感覺可能還要3天（甚至變成5天了！）”這種情況，是以燃盡圖常常有一些起伏。
燃盡圖的“指紋”
圖中的燃盡圖盡管有一些起伏，依然是屬于比較完美的燃盡圖。實際上每個團隊完成疊代的過程差别很大，常見的情況包括：
先鼓起後落下
原因是計劃會以常常漏掉一些事情，是以開工後不但不燃盡，還發現了很多新的任務。
先完美燃燒，然後突然停止燃燒
一種很常見的情況，如果任務劃分太粗，比如長達10天，很容易“做了1天，剩9天；做了1天，剩8天；……到剩2～3天的時候，哎呀，好像搞不定了”。
先緩慢燃燒，然後到快燃盡的時候剩下一堆沒完成的任務，被推遲到下個疊代
之前提到過靈活開發的MoSCoW方法，有些故事是次要的“可以不做的”，是以這種燃燒圖也很常見；但是常常有團隊沒有使用MoSCoW方法，隻是被動地發現有些故事沒有完成。
Scrum和xp的差別
參考位址：http://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
Scrum和xp是靈活開發中兩個重要的方法，他們相似度很大。如果你的團隊用了其中一個方法，你可能還分不清楚你到底是在一個Scrum團隊還是xp團隊。他們的差別很小，但是很重要：
1. 疊代周期不通，scrum一般是兩到四周，xp一般是一或者兩周。
2. 疊代是否允許修改，在xp中如果一個user story還沒有實作，則可以考慮用另外的需求将其替換。替換的原則是時間量相等。而scrum使不允許的，一旦scrum planning會議開完，任何需求都是不允許改變的，由scrum master把關，避免開發團隊受到幹擾。
3. XP是務必要遵守優先級别的。 但Scrum在這點做得很靈活， 可以不按照優先級别來做，Scrum這樣處理的理由是： 如果優先問題的解決者，由于其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。另外一個原因是，如果按優先級排序的User Story #6和#10，雖然#6優先級高，但是如果#6的實作要依賴于#10，則不得不優先做#10.
4. Scrum不規定工程師如何去做，XP就規定了。比如TDD，測試驅動，自動化測試，重構等。XP這些很好，但是卻有個誤區：“你是自管理的，我相信你，但是你必須去做TDD,重構。。。”
在管理模式上啟用Scrum，而在實踐中，創造一個适合自己項目組的XP(“start with Scrum and then invent your own version of XP.”)
靈活開發中對進度的把握
參考位址：
http://developer.51cto.com/art/200906/130031.htm
在靈活開發方式中，先由使用者和設計人員粗略估計各個功能子產品的相對規模和難度，給出一定的分值。分值不代表具體人月，起相對比較的作用。例如有查詢、顯示、修改三個子產品，如果實作顯示子產品的工作量是10分，那麼查詢子產品可能是15分，而修改為20分。
下一步，選擇一個工作量估分最低的子產品，例如這裡是顯示子產品，然後進一步考量其工作量。例如要準備資料庫、設計界面、執行查詢，顯示内容等等。假設這輪估算得出此子產品需要10人天，進而得出機關分值對應的人天為1；那麼，整個項目就需要45人天。
這個估算建立在對項目的初步了解上，主要依賴項目經理的經驗。有偏差？沒關系。接下來通過疊代來求精。先來實作顯示子產品，如果事實上花費了12人天，那麼根據比例關系，剩餘内容的估算大約就是42人天。
當然，比例關系也不是一成不變的。随着子產品的逐個完成，項目經理對項目的認識也在加深，他可以再調整剩餘子產品的相對分值。
在實際操作中，項目經理首先按照優先級排列功能子產品。然後把高優先級的子產品盡可能地細分，再選擇分值最小的子產品開始開發。統計總工作量時，按比例累加其他子產品的工作量，并加一定的調整系數，因為子產品的複雜度不是線性增長的。每次疊代開發完成後，逐漸降低調整系數。通常4~5次疊代後，可以将調整系數歸零。
在上面的例子中，第一次估算的初步結果是45人天，因為完全是憑經驗，是以要給較大的調整系數，比如說0.4，是以給出的估算工作量區間為[45*0.6,45*1.4],即27到63人天之間。為保險起見，項目經理上報的工作量為70人天。
第二次估算，剩餘内容的初步估算為42，調整系數下降為0.3，是以給出估算區間為30到50人天之間。依此類推，通過不斷疊代，對剩餘工作量的估算将越來越精确。
在每天的例會上，開發人員被要求對目前任務的剩餘開發時間做重估。不同于Project 統計每人每天在任務中花費了多少時間，靈活方式隻關心這項任務還需要多少時間去完成，直到歸零，然後再來統計實際的工作時間。
在每天例會中，項目經理需要注意時間曲線保持水準的成員，他是不是遇到瓶頸了，是否需求幫助？也要留意時間曲線下降幅度過大的成員，他發現了什麼好的辦法，有沒有低估需求？這樣，項目經理會更面向結果，隻要按計劃保證品質完成任務就行，成員到底花了多少時間是個人的事。傳統做法記錄每個人每天的工作内容，第一是因繁瑣而失真。其次，一旦上級發現某人工作時間不夠（即便他完成了任務），忍不住會派新任務，進而造成越幹活越多，反過來打擊程式員的積極性。
靈活估算的關鍵之處，是把成員能力這個變量的估算，交給最合适的人去做，即程式員本人。然後通過比較曆次疊代時的預估和實際時間，給出校正系數，以避免程式員過于保守或過于樂觀。這肯定不是絕對準确的，但效果往往比項目經理自己拍腦袋估算，然後強行指定deadline 要好得多。
我的問題：
1. 如何加入新功能。
2. 靈活開發疊代中途加入新的任務，加班，項目延期？是否需要重新評估，是否需要修改burndown chart？
3. 靈活開發發現時間估算錯誤，或者以前的任務實作方法行不通，如何辦？
4. 做産品訂單的時候是否需要細化，評估出完成的時間，因為這個需求是可能變化的。
5. 任務的粒度大小？
6. 不同專項的人如何預估時間？
7. 進度和品質如何保證，因為task是團隊成員自己估算的，兩者有沖突？