名詞解釋
scrum: scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。包括了一系列實踐和預定義角色的過程骨架。scrum中的主要角色包括同專案經理類似的scrum主管角色(scrummaster)負責維護過程和任務，產品負責人(po, product owner)代表利益所有者，開發團隊(team)包括了所有開發人員
一、為什麼scrum是有效的開發組織方式
(一) 經驗型流程vs預定義型流程
如果所需實現的物件清晰,技術準備充分,則適用於預定義型流程.如果所需實現的物件模糊,技術準備不充分,則適用於經驗型流程.
在這裡,流程不僅僅是軟體開發中的流程,這是乙個廣義的定義,包含各個行業生產中產生的流程.對於預定義型流程,很經典的例子就是造汽車.比如造一輛奧迪a6,工作人員只需要拿到圖紙,根據圖紙上提供的資訊去裁割鋼板,定型,組裝.在預定義型流程下,一輛a6將很快的開下生產線.對於經驗型流程,如果還是以汽車為例的話,那就可以放在如何降低汽車的風阻?如何降低油耗?如何使駕駛人更舒服?這些事情,在以前可能做過,也可能沒有做過,這就需要根據我們以往的經驗去考慮問題,但這裡經驗起的作用只是一本字典,更多的事情,需要我們在經驗的基礎上去昇華解決.
對於scrum,適合的是經驗型流程.在較短的迭代中(2周左右),需要我們快速的整理好po提出的使用者情景(user story)(po提出的需求在這裡稱作使用者情景),然後選定技術(這個技術也可能是新技術)進行快速開發.
(二) 軟體專案中的兩個複雜度
簡單專案=熟悉的技術+固定的需求;複雜專案=技術不確定+變更.
試想,在我們以前做過的專案中,有多少是」簡單專案」呢?因此,scrum在不斷迭代的過程中,遮蔽或者減少了需求的不確定性以及不確定技術帶來的弊端.
(三) 案例分析
假如公司希望遷移sharepoint伺服器,並和當前流行的社交**如facebook進行整合.
你覺得會有哪些問題?
1、 我們有哪些可用的技術？
2、 如何使用這些技術來實現所需功能?
3、 對於目標,我們要實現到何種程度?
4、 最糟糕的,po並不清楚他需要什麼!
解決方式:
1、 縮短迭代；
2、 增加與po的溝通頻率；
3、 將技術調研和實現放在不同的迭代中進行。
(四) 經驗型流程控制
1、 需要通過檢查和適應來改進流程(需要很好的透明度來支援)
2、 透明度的實現需要企業文化的支援
在scrum模式中，團隊的規模應控制在5~9人之間，充分發揮每個成員在團隊中的作用。在應用scrum模式進行開發過程中,需要建立人與人之間的信任,充分調動團隊成員的積極主動性,也就是注重每個團隊成員在團隊中發揮的作用,而不是下派、監控這種不是以人為本的模式。那麼在這種情況下，就需要很好的透明度來支援，要讓團隊成員知道scrummaster都和哪些人說了什麼，po提出了新什麼需求，面臨著什麼新問題，甚至是上級的壓迫也要上團隊成員知道。
二、計畫質量
(一) scrum是否需要計畫？
無可置疑，在scrum中，需要更多的計畫。在這裡介紹一下戴明環。
作為幫助我們做出進一步決策的迭代型方法，戴明環通過4 個簡單的步驟來驗證所獲取的經驗，以便幫助我們做出更好的決策。
(二) 質量和成本的關係
1、 關注質量將會最終降低成本並提供更好的質量
2、 關注成本，將會犧牲質量同時遠期成本反而增加
那麼該如何提高質量呢？
停止使用通過檢查來提高質量的方式，而通過完善的計畫在產品開發的一開始就構建質量。理解起來可能稍微有點難以接受，但是集合上面的兩點並結合戴明環，不難理解，質量應該是乙個度，乙個高度，乙個保證，因為你不能保證你生產的家電永遠不會壞掉。
(三) 來看scrum的計畫（plan）和執行（do）
scrum通過在迭代中不斷的計畫和執行來推進，通過不斷的計畫，不斷的完善計畫，相應的質量也會隨之提高，相比傳統的（計畫——執行——穩定）具有更高的可操作性和可控性。
三、scrum」以人為本」的體現
我們可以來做乙個實驗來證明scrum的優越性。
情景一：有n個小隊，每個小隊有乙個隊長，所有小隊的成員成矩形聚攏在一起（很緊湊），然後每個小隊的隊長給隊員發號施令（在矩形內移動30步，然後移動出矩形）。
情景二：有n個小隊，沒有隊長，每個小隊的成員成矩形聚攏在一起，然後每個小隊成員在矩形內移動30步，然後移動出矩形。
四、scrum角色介紹
(一) scrummaster：
保證scrum團隊可以遵守scrum的價值，實踐和規範
幫助scrum團隊和組織採用scrum模式進行專案流程組織
指導並帶領團隊變得更加高效，實現更高質量
保護團隊不要受到外界因素的干擾
保證各個不同角色之間的良好寫作，消除障礙
幫助po更好地利用團隊的能力
不要管理團隊
給scrummaster的一些建議：
1、協助甄選po人選，並幫助po了解其職責; 如果po不了解 如何很好的利用團對的價值，scrummaster需要承擔負責
2、scrummaster 永遠不能同時擔任po
3、scrummaster 可以由團隊的成員來擔任，但是在這種情況下他將有很重的負擔
如果打破了第二點，scrummaster同時兼任po，那麼就打破了scrum的價值和規範，因為scrummaster+po=pm。而在scrum中是沒有pm這個概念存在的。
(二) 產品負責人po
1、po 是乙個人並只能由乙個人來擔
2、負責管理產品待辦事項表（product backlog）並保證其 對於客戶和團隊保持透明度
3、對產品代辦事項表進行優先順序排序
4、與團隊一起來進行工作量估算
5、對於專案的成功負責並保證投資回報率（roi）
給po的一些建議：
1、 客戶專案：最佳的po人選應該由客戶的代表來擔任
2、 內部專案：最佳的po人員應該由業務經理擔任
3、 po可以由團隊成員擔任，但永遠不能由scrummaster擔任
(三) 團隊team
1、 最佳團隊大小：5-9 人
2、 多功能團隊：程式設計師，測試人員，設計師，資料庫管理員和架構師
3、 保證團隊成員全職參與開發
4、 自我管理，沒有頭銜之分，不組建子團隊
5、 成員更替只能在迭代之間進行，最佳方式是在發布之間進行
需要注意的是，第三點提到的全職參加是指完成了分配到的任務額即為全職參加。並不是指全程參加。
五、在每次迭代過程中包含的內容
(一) 每日站立會議
1、 站立進行
2、 在固定的時間，固定的地點
3、 問題：
你昨天完成了哪些工作？你今天要完成哪些工作？遇到了什麼困難？
4、 僅僅作為資訊溝通用途，不解決任何問題
5、 不向任何人匯報
6、 15分鐘
(二) 發布計畫會議
進行產品規劃
1、僅對啟動專案所必須的內容進行規劃
2、在開發過程中適時進行進一步的規劃
可交付物
1、 針對產品特性和功能的整體規劃
2、 下乙個發布的目標
3、 主要任務
4、 按優先順序排序的產品待辦事項表
(三) 迭代計畫會議
1、進行迭代規劃
2、po向團隊介紹產品待辦事項表
3、團隊在po的協助下充分了解產品待辦事項
4、確定迭代目標和迭代合約
迭代合約包含的內容有：
1) 團隊組成（成員列表、角色分配）
2) 完成規範
3) 團隊對迭代目標的承諾
4) 迭代長度
5) 迭代代辦事項的估算
6) 迭代評審和下一次計畫會議的時間和地點
5、對產品待辦事項進行細分並建立迭代待辦事項
(四) 迭代
解釋：團隊用來實現迭代目標（可發布產品）的時間區間。
時間區間：1-4周，最佳2周。
優點：為團隊提供保障。
(五) 迭代評審會議
團隊展示完成的功能並收集反饋
對未完成的功能進行描述並說明原因
po接受/不接受當前迭代
邀請所有人，包括客戶參與
4小時(六) 迭代回顧會議
那些做的好？
那些做的不好？
那些可以改進？
僅團隊成員參與
4小時六、定義需求
使用者情景應該包括：作為……我需要……從而……，以及使用者接受標準。
使用者情景應該理解為使用者+情景，不能僅僅考慮使用者本身，所有的使用者情景都應該從某類使用者開始。
使用者情景最佳實踐：
1、 縱向分配原則-對於採用分層設計的業務用例實現盡可能 由乙個開發人員完成所有的層次的元件實現（介面/邏輯/資料）
2、 任務的劃分粒度到1個工作日內完成
3、 對於任務而言，只有完成和不完成兩種狀態
4、 業務用例的工作量使用的相對值，表明的是一種對於用例工作量和評定
在Scrum開發模式下，為Sprint起名字的藝術
在過去的幾個月中，我們在每個 sprint 計畫會議 上，都會花上幾分鐘的時間，一起為當前的sprint起名字，現在回顧一下，還是非常有意思的。敏捷精靈 看一下我們為專案a起的sprint名字 熟悉加里森敢死隊的同學一定會很興奮的，因為我們這裡面用了 加里森敢死隊 好幾集的名字，之所以選擇 加里森敢...
Scrum敏捷開發
只有實踐起來才能提出有針對性的改進建議 在這個框架中，整個開發過程由若干個短的迭代週期組成，乙個短的迭代週期稱為乙個sprint，每個sprint的建議長度是2到4周 網際網路產品研發可以使用1周的sprint 在scrum中，使用產品backlog來管理產品的需求，產品backlog是乙個按照商業...
敏捷開發 Scrum 實戰
最近把之前學習 scrum 的資料整理為一篇文件，在接下來的團隊和專案開發中，根據專案的情況引入 scrum 的一些實踐，提高團隊成員之間的協作能力和專案的交付質量。scrum 工具 scrum 中的角色 scrum master 專案負責人 專案經理 保護團隊不受外界干擾，是團隊的領導和推進者，負...