角色注釋：
產(chǎn)品負(fù)責(zé)人 產(chǎn)品負(fù)責(zé)人是利益相關(guān)方的代表，最重要的職責(zé)就是與客戶交談，了解和分析需求，將其制作成用戶故事并將需求轉(zhuǎn)述給程序員。同時，產(chǎn)品負(fù)責(zé)人也要代替客戶負(fù)責(zé)功能驗收測試。他負(fù)責(zé)向團(tuán)隊介紹產(chǎn)品的愿景。他負(fù)責(zé)給出一份明確的，可度量的，合理的產(chǎn)品Backlog，并從業(yè)務(wù)角度出發(fā)對Backlog中各項問題按優(yōu)先級排序。
商業(yè)價值是產(chǎn)品負(fù)責(zé)人關(guān)注的最終目標(biāo)。和客戶進(jìn)行交流，最終目的就是挖掘出客戶的商業(yè)目標(biāo)。可能大家會經(jīng)常有這樣的經(jīng)驗，客戶說，我要這個功能，我想要怎么怎么樣。這時候要特別注意，他說的這些東西并不是真正的需求。產(chǎn)品負(fù)責(zé)人需要詳細(xì)的問客戶為什么，挖掘出他真正的目標(biāo)。
在這個目標(biāo)下，產(chǎn)品負(fù)責(zé)人開始進(jìn)行需求的分析：我們到底是否真的需要這個需求?有沒有更好的解決方案?有沒有簡單并且低廉的方式?換一種形式是不是也能達(dá)到這樣的需求?這個需求有多少地方涉及到以前的軟件變更?
搞清楚這些事情后，就可以寫出用戶故事。用戶故事的書寫遵循一定的原則，一般包括三部分："作為(系統(tǒng)的一個涉眾)，我想要(做一件事)，從而(達(dá)到一個商業(yè)價值)"。
Scrum Master Scrum Master是整個團(tuán)隊的導(dǎo)師和組織者，他負(fù)責(zé)提高團(tuán)隊的開發(fā)效率。他常提出培訓(xùn)團(tuán)隊的計劃，列出障礙Backlog。Scrum Master控制著檢查和改進(jìn)Scrum的周期，他維護(hù)這一團(tuán)隊的正常運行，并與產(chǎn)品負(fù)責(zé)人一起讓利益相關(guān)方獲得最大的投資回報。他關(guān)心的是這些敏捷開發(fā)思想是否能得到利益相關(guān)方的理解和支持。
團(tuán)隊 團(tuán)隊盡一切可能去完成任務(wù)——發(fā)布產(chǎn)品。團(tuán)隊需要全面的能力，這意味著小組內(nèi)擁有實現(xiàn)產(chǎn)品的全部技術(shù)和技能。團(tuán)隊還需要充分的理解產(chǎn)品負(fù)責(zé)人所描述的產(chǎn)品愿景以及Sprint目標(biāo)，以更好地支持可能需要進(jìn)一步開發(fā)的產(chǎn)品的發(fā)布。
產(chǎn)品Backlog 產(chǎn)品Backlog包括了所有需要交付的內(nèi)容，其內(nèi)容根據(jù)業(yè)務(wù)需求的價值順序排列。每個Backlog項的優(yōu)先級是可調(diào)整的，需求是可以增減的，因此產(chǎn)品Backlog將根據(jù)不斷增長的需求來持續(xù)驅(qū)動維護(hù)。
既定產(chǎn)品Backlog 既定產(chǎn)品Backlog是Sprint計劃會議的產(chǎn)物，它定義了團(tuán)隊所接受的工作量。在整個Sprint過程中它將保持不變。
Sprint Backlog Sprint Backlog涵蓋了最終版本的既定產(chǎn)品Backlog的任務(wù)。團(tuán)隊通過它來協(xié)調(diào)開發(fā)進(jìn)度。
障礙Backlog 障礙Backlog列舉了所有團(tuán)隊內(nèi)部和團(tuán)隊相關(guān)的和阻礙項目進(jìn)度的問題。Scrum Master需要確保所有的障礙Backlog中的問題都已分配并可以得到解決。
//————————————————————————————————————————
前奏：User Story
我們可以把User Story看作是從用戶角度考慮的軟件需求，為產(chǎn)品負(fù)責(zé)人編寫產(chǎn)品Backlog提供依據(jù)。
User story是對軟件的用戶或買主有價值的功能點的描述。User stories 由以下三點組成：
·用來制定計劃和作為提醒的一段書面描述
·用來充實story的細(xì)節(jié)的談話
·測試用例，用來表達(dá)和記錄細(xì)節(jié)并且能夠在story實現(xiàn)的時候?qū)M(jìn)行驗證
三要素：
1.角色：誰要使用這個功能。
2.活動：需要完成什么樣的功能。
3.商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。
用戶故事通常按照如下的格式來表達(dá)：
作為一個<角色>, 我想要<活動>, 以便于<商業(yè)價值>
舉例：作為一個“網(wǎng)站管理員”，我想要“統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他們帶來什么收益?！?span lang="EN-US">
重點強(qiáng)調(diào)：
·客戶和軟件的最終用戶應(yīng)該在編寫story 的過程中扮演一個很積極的角色，最好從考慮系統(tǒng)的用戶類型入手來開始story 編寫
·story必須拿業(yè)務(wù)語言來寫，而不是技術(shù)術(shù)語
編寫Story：
一個好的story需要具備以下六點：
·獨立性（Independent） 應(yīng)該盡可能的注意避免引入story之間的依賴性。
·可協(xié)商性（Negotiable） Story卡片是功能點的簡要描述，它不是軟件必須要如何實現(xiàn)的書面合同或者需求。
·對客戶或用戶有價值（Valuable to Purchasers or Users） 保證每個story都對客戶或用戶有價值的最好的方法就是客戶編寫story。story card是用來提醒稍后要進(jìn)行的討論，而不是記錄明確的需求。
·可估算（Estimatable） 對開發(fā)人員來說，能夠估算一個story的大小和開發(fā)這個story的時間是非常重要的。
·短?。?span lang="EN-US">Small）
·可測試的（Testable） 成功通過測試證明story被成功開發(fā)。
采集Story：
創(chuàng)建story最有價值的技巧是：
·用戶訪談
·調(diào)查表
·觀察
·現(xiàn)場編寫story
單單詢問客戶“那么，你需要什么呢？”是不夠的。很多客戶不是很習(xí)慣去理解，尤其是表達(dá)他們的真實需要。通過你詢問的問題來尋找客戶最本質(zhì)的需求，是最好的辦法。問一個開放式的問題讓回答者表達(dá)更多詳細(xì)、深入的觀點是好很多的。某時候，你需要問一些非常詳細(xì)、具體的問題，而不是上下文無關(guān)的問題。但是，通過詢問一個上下文無關(guān)的問題開始，你打開了從客戶那獲得更大范圍內(nèi)的問題的機(jī)會。你會發(fā)現(xiàn)一些你問非常確定的問題的時候無法發(fā)現(xiàn)的故事。
//————————————————————————————————————————
（1）編寫產(chǎn)品Backlog（需求，或故事，或特性等組成的列表）
由產(chǎn)品負(fù)責(zé)人根據(jù)User Story劃分、編寫，并按重要性進(jìn)行優(yōu)先級排列。注意，只有產(chǎn)品負(fù)責(zé)人有權(quán)對Backlog進(jìn)行重要性及優(yōu)先級設(shè)置。
|
|
| ID： |
| 統(tǒng)一標(biāo)識符 |
| Name： |
| 簡短的、描述性的故事名 |
| Importance： |
|
|
| Initial estimate： |
|
|
| How to demo： |
| 大概描述了這個故事應(yīng)該如何在Sprint演示上進(jìn)行示范，本質(zhì)就是一個簡單的測試規(guī)范。 |
| Notes： |
| 相關(guān)信息、解釋說明、資料引用等。 |
| 注明： ·“Importance”項只能由產(chǎn)品負(fù)責(zé)人決定； ·“Initial estimate”項只能由團(tuán)隊決定，可以在“評估會議”中由團(tuán)隊討論決定； |
關(guān)于編制產(chǎn)品Backlog的一些說明：
可以參考以下流程來編制產(chǎn)品Backlog：
1.針對產(chǎn)品編制幾個較大的產(chǎn)品Backlog，可以較籠統(tǒng)，幾個較大的產(chǎn)品Backlog組成一個完整的產(chǎn)品。比如，手機(jī)短信軟件，大的Backlog可以籠統(tǒng)劃分為發(fā)送短信、接收短信和查看短信等。
2.針對每個較大的產(chǎn)品Backlog進(jìn)行二次劃分成若干較小的產(chǎn)品Backlog，比如發(fā)送短信可以劃分成可以群發(fā)、可以單發(fā)、可以轉(zhuǎn)發(fā)等。
3.針對每個較小的產(chǎn)品Backlog三次劃分為若干任務(wù)。比如新建短信、輸入、編輯、發(fā)送、存儲等。
//————————————————————————————————————————
（2）全員會議（評估會議）
·由產(chǎn)品負(fù)責(zé)人向團(tuán)隊所有成員詳細(xì)介紹產(chǎn)品（以客戶角度描述產(chǎn)品及其用途等）；
·由產(chǎn)品負(fù)責(zé)人介紹產(chǎn)品中會涉及到的技術(shù)或產(chǎn)品的（已有）技術(shù)框架，產(chǎn)品的（新）開發(fā)框架也可以由團(tuán)隊Leader討論制定；
·由產(chǎn)品負(fù)責(zé)人介紹產(chǎn)品的Backlog（包括詳細(xì)用例）；
·由團(tuán)隊討論，每個Story的Initial estimate；
（注意：此處無須每個人都要對每一個Story做出評估，只是可能會執(zhí)行或有能力執(zhí)行某個Story開發(fā)的成員針對此Story進(jìn)行評估，如果針對一個Story，幾個可能參與開發(fā)的成員評估的時間不同，將進(jìn)行一個小型的討論，重新評估；如果某個Story無人對其評估，那么這個Story將成為一個潛在的問題Story，因為在開發(fā)過程中可能會出現(xiàn)無人執(zhí)行的風(fēng)險；同時根據(jù)對每個Story進(jìn)行評估的成員數(shù)量，可大概預(yù)測哪些Story具有普遍性，即相對容易執(zhí)行，哪些Story具有專屬性，即只有專門的成員能夠開發(fā)，這就需要在必要的時候進(jìn)行硬性的任務(wù)分配，因為有些專屬性較強(qiáng)的任務(wù)可能都是要由一個成員執(zhí)行，那么就要把其他具有普遍性的任務(wù)交由其他成員執(zhí)行，同時注意對整個周期開發(fā)計劃的依賴性持續(xù)關(guān)注。）
·由Scrum Master制定Sprint周期以及估算團(tuán)隊的生產(chǎn)率；
·定義“完成”，并達(dá)成共識；
·明確產(chǎn)品的設(shè)計結(jié)構(gòu)；明確組織人員的設(shè)定（成員的技術(shù)特長，成員是否有開發(fā)側(cè)重，團(tuán)隊成員技能如果不能滿足產(chǎn)品開發(fā)所有技術(shù)，由誰去彌補）；明確團(tuán)隊針對產(chǎn)品開發(fā)采取的開發(fā)模式和開發(fā)方法，以及需要完成的一些準(zhǔn)備工作；
注明：除產(chǎn)品負(fù)責(zé)人以外，其他人也可以向產(chǎn)品Backlog（故事列表）中添加故事，但必須經(jīng)過團(tuán)隊討論以及產(chǎn)品負(fù)責(zé)人認(rèn)可，且無權(quán)設(shè)置故事的重要性及優(yōu)先級。
考慮：討論在第一個sprint周期中（或在項目正式啟動前），團(tuán)隊共同開發(fā)出一個產(chǎn)品的demo（盡管可能極其簡化），并將其作為產(chǎn)品的原型，在以后的開發(fā)周期中基于產(chǎn)品原型進(jìn)行迭代開發(fā)。目的在于使團(tuán)隊每個人都可以在周期結(jié)束（或任何時候）通過產(chǎn)品的即時demo來檢測本周期工作所達(dá)到的實際效果。
//——————————————————————————————————————————
（3）Sprint計劃會議（第一層迭代）
重要前提：確保產(chǎn)品Backlog的井然有序。包括：
——產(chǎn)品Backlog必須存在。
——對于一個產(chǎn)品而言，只能有一個產(chǎn)品Backlog和一個產(chǎn)品負(fù)責(zé)人。
——所有重要的Backlog條目都已經(jīng)根據(jù)重要性被評過分。
·制定本次Sprint目標(biāo)；
·由Scrum及團(tuán)隊討論決定，把哪些故事（按照優(yōu)先級的先后順序）放入本次的Sprint周期中；
·對每個故事進(jìn)行任務(wù)分解；
其他，確定Sprint演示日期，以及確定每日Scrum例會的時間和地點。
//———————————————————————————————————————————
（4）Scrum每日例會（15分鐘站立會議）（第二層迭代迭代）
·團(tuán)隊成員總結(jié)昨天做的工作，以及遇到的問題，是否需要其他人的幫助；
·團(tuán)隊成員確定今天要做的工作，“領(lǐng)取”任務(wù)，并在任務(wù)卡片中標(biāo)識領(lǐng)取人；
·Scrum Master在公示板（白板）上設(shè)置每個任務(wù)的狀態(tài)，并根據(jù)“燃盡圖”檢測團(tuán)隊的工作狀態(tài)以及項目預(yù)期；
注明：如果發(fā)現(xiàn)某個任務(wù)無法在一個人-天內(nèi)執(zhí)行完畢，則需要對此任務(wù)分解。同時，每日例會的目的是：加強(qiáng)團(tuán)隊交流和信息共享?；ハ嗔私獗舜硕荚谧鍪裁垂ぷ?，完成了什么任務(wù)。這樣，每日的信息傳遞，可以讓每個人可以更多的了解整個項目的業(yè)務(wù)和技術(shù)狀況。并且如果在工作中遇到障礙或問題，也可以在這時候提出來，請求大家的幫助（其實，一般在敏捷團(tuán)隊中，遇到問題，都會當(dāng)場就提出來，或直接去找相關(guān)的同事，問他們有沒有處理過類似的問題，或者有沒有一些建議）；促使每個人在早上做好一天的工作計劃。這樣，每個人一天的工作就會有明確具體的目標(biāo)。這會直接提高一天的工作效率。
===
關(guān)于人員績效考核的一些說明：可以通過以下公式來判定人員在一段時期內(nèi)的工作績效，
任務(wù)1 * 重要性 + 任務(wù)2 * 重要性 + …… + 任務(wù)n * 重要性 = 工作績效
由于“重要性”一般的浮動區(qū)間較大，但為了更好的掌握人員的工作績效，團(tuán)隊Leader可以對產(chǎn)品Backlog的重要性（由產(chǎn)品負(fù)責(zé)人制定）的數(shù)值按照一定統(tǒng)一規(guī)范或標(biāo)準(zhǔn)作出一定的修正，同時也應(yīng)該允許“工作績效”有一定的浮動區(qū)間。
===
關(guān)于開發(fā)隊列任務(wù)容量限制說明：
在有些團(tuán)隊的項目開發(fā)中，開發(fā)和測試是分離的，即一些開發(fā)人員只負(fù)責(zé)編寫代碼，而另一些開發(fā)人員則只負(fù)責(zé)進(jìn)行測試，那么開發(fā)人員和測試人員對彼此的工作進(jìn)度以及對整體項目的有序管理都有著很大的影響。這樣就要嚴(yán)格控制開發(fā)任務(wù)數(shù)量和測試任務(wù)數(shù)量的銜接，即盡可能保證在任何一段時間只有極少量的已完成代碼程序等待測試。可以嘗試規(guī)定等待測試代碼程序的數(shù)量限制，當(dāng)達(dá)到上限時，開發(fā)人員不能在開發(fā)新的代碼程序，而是要協(xié)助測試人員完成代碼測試，減少待測試代碼程序的數(shù)量。也有的團(tuán)隊有專門進(jìn)行代碼程序集成、部署的工作，那么同樣要協(xié)調(diào)開發(fā)隊列、測試隊列以及集成部署隊列中等待任務(wù)的數(shù)量，分別要規(guī)定待開發(fā)隊列、待測試隊列和待集成部署隊列中任務(wù)的數(shù)量上限，以保證在任何開發(fā)環(huán)節(jié)中都不會出現(xiàn)任務(wù)堆積現(xiàn)象，保證整個開發(fā)流程的順暢進(jìn)行。任何一個環(huán)節(jié)出現(xiàn)了潛在的任務(wù)堆積現(xiàn)象，與其上下相關(guān)的人員都應(yīng)該參與解決。（這部分更詳細(xì)的參考資料可以查閱《敏捷開發(fā)資料匯總》中“One day in Kanban land”）
另外補充，如果采用測試驅(qū)動編程的話，由于測試和開發(fā)幾乎是同時由一個開發(fā)人員或一組開發(fā)人員（結(jié)對編程）完成，可以在一定程度上避免發(fā)生如上所述的任務(wù)堆積現(xiàn)象。
===
關(guān)于嚴(yán)格限制產(chǎn)品負(fù)責(zé)人參與每日Scrum會議說明：
嚴(yán)格上，產(chǎn)品負(fù)責(zé)人不允許參加每日Scrum會議，如果有必要，產(chǎn)品負(fù)責(zé)人在參與每日Scrum會議時必須保證不能作任何發(fā)言及表態(tài)，不能對開發(fā)團(tuán)隊的人員及工作做出任何評價，更不允許提出任何需求或變更。
在每個長周期迭代（比如三個星期）中應(yīng)該劃分若干短周期（比如一個星期），在每個短周期中規(guī)定將達(dá)到的演示目標(biāo)。
產(chǎn)品負(fù)責(zé)人如果對項目產(chǎn)品需求有變更，只允許與Scrum經(jīng)理直接溝通，Scrum把需求及變更進(jìn)行匯聚，并由產(chǎn)品負(fù)責(zé)人制定重要性，Scrum經(jīng)理會在本次短周期結(jié)束時，與團(tuán)隊交流需求和變更，重新制定下一個短周期的計劃及演示目標(biāo)。由Scrum經(jīng)理與產(chǎn)品負(fù)責(zé)人溝通變更結(jié)果，包括下個短周期的演示結(jié)果，以及整個項目進(jìn)度的延后時間和變更成本，如果客戶確認(rèn)，在下個短周期將執(zhí)行新計劃，否則仍按原計劃進(jìn)行。如果開始新計劃，那么團(tuán)隊擇時評估本次長周期的最終演示結(jié)果，Scrum經(jīng)理與產(chǎn)品負(fù)責(zé)人進(jìn)行溝通。
切記，保證產(chǎn)品負(fù)責(zé)人（客戶）與團(tuán)隊在項目產(chǎn)品開發(fā)過程中絕對隔離。
===
關(guān)于敏捷中所謂的“不加班”的一些說明：
所謂的“不加班”，不應(yīng)該嚴(yán)格的理解為就是排斥一切加班的行為，而應(yīng)分清加班的誘因或說主導(dǎo)因素。所謂的“不加班”，因時在對每日的工作任務(wù)安排中，保證每個人分得（或領(lǐng)?。┑娜蝿?wù)的工作量為1人-天，這個基本可以確定，因為在前期對Story進(jìn)行task分割時，即是按照每個task的工作量不超過1人-天進(jìn)行分割的，所以基本保證了每個人每天所領(lǐng)取的task的工作量最多為1人-天，所以在整個項目的安排上已經(jīng)排除了“加班”的因素。但是，由于個人原因，而耽誤或延長了task的完成時間，那么所帶來的后果，就是這個人以加班為代價彌補對效率的損失。即這個加班的行為是項目本身計劃之外、由個人原因引起的行為。這個加班就不應(yīng)該劃定在敏捷中所謂的“不加班”的范圍中。
//————————————————————————————————————————————
（5）Sprint評審會議（第一層迭代）
·團(tuán)隊成員按產(chǎn)品Backlog中的Story，逐個地介紹這次Sprint的結(jié)果，和演示新功能；
·產(chǎn)品負(fù)責(zé)人可以就新功能或新想法，向Backlog中添加新的Story；
·Scrum和團(tuán)隊成員總結(jié)本次Sprint中的問題和經(jīng)驗；
===
關(guān)于在一定程度上增加項目需求（或變動）而不延長整個項目開發(fā)周期的說明：
如果產(chǎn)品負(fù)責(zé)人在項目的開發(fā)過程中添加了額外的產(chǎn)品需求，而又拒絕延長項目開發(fā)周期，那么在團(tuán)隊本身可以嘗試通過以下方法解決：
1.增加團(tuán)隊開發(fā)力量，即增加開發(fā)人員。
2.提高團(tuán)隊工作效率。因為每個團(tuán)隊的實際工作效率都是介于0-100之間，我們在團(tuán)隊效率評估的初期或許會留有一定的空間，比如我們以結(jié)對編程的工作時間為有效工作時間（因為結(jié)對編程效率較高且疲勞度高），初期我們可能估計每天每人有4個小時的結(jié)對編程時間（以日工作8小時計算），那么團(tuán)隊的工作效率可以看做是50%。當(dāng)我們必須提高團(tuán)隊工作效率的時候，我們可以規(guī)定每天每人有6個小時的工作時間，那么團(tuán)隊的工作效率可以看作是75%。
要注意的是，按照初期對團(tuán)隊工作效率的評估，按照1人-天劃分的task，在團(tuán)隊工作效率提高到75%的時候，相同的task則只需要0.75天，此時我們可以對剩下的task進(jìn)按照75%的團(tuán)隊工作效率進(jìn)行重新分割，即盡管項目需求增加，但通過提高團(tuán)隊生產(chǎn)率，來確保項目按原開發(fā)進(jìn)度進(jìn)行。
另外，關(guān)于上述兩個方法的選擇，應(yīng)該以第2種為主，當(dāng)團(tuán)隊的工作效率提高到一個所謂的極限的時候，再去考慮采取第1種方法作為對第二種方法的補充。
//————————————————————————————————————————————
（6）Sprint回顧會議
·總結(jié)：問題、經(jīng)驗，哪些需要改進(jìn)的，對問題以及需要改進(jìn)的工作明確負(fù)責(zé)人，并由負(fù)責(zé)人著手進(jìn)行處理；
//————————————————————————————————————————————
（7）項目整體測試
·按照之前達(dá)成的對“完成”的共識，進(jìn)行驗收性測試（軟件交付前的黑盒測試）；
