1敏捷原則與實(shí)踐
什么是敏捷？
“敏捷方法”是一個(gè)囊括了各種框架和方法的涵蓋性術(shù)語。圖 1結(jié)合上下文將敏捷定位為一個(gè)總稱，它指的是符合《敏捷宣言》價(jià)值觀和原則的任何方法、技術(shù)、框架、手段或實(shí)踐。還將敏捷方法和看板方法視為精益方法的子集。這樣做的原因是，它們都是精益思想的具體實(shí)例，都反映了諸如以下概念：“關(guān)注價(jià)值”、“小批量”和“消除浪費(fèi)”。敏捷是一種思維模式。
敏捷宣言四大價(jià)值觀
2001 年，軟件業(yè)思想領(lǐng)袖共同發(fā)表《敏捷宣言》，正式宣告敏捷開發(fā)運(yùn)動(dòng)的開始。一直在實(shí)踐中探尋更好的軟件開發(fā)方法，身體力行的同時(shí)也幫助他人。由此建立如下價(jià)值觀：
1、個(gè)體和互動(dòng)高于流程和工具；
2、工作的軟件高于詳盡的文檔；
3、客戶合作高于合同談判；
4、響應(yīng)變化高于遵循計(jì)劃。
右邊的項(xiàng)目固然有價(jià)值，但我們更重視左邊（加粗）的項(xiàng)目。
個(gè)體和互動(dòng)高于流程和工具
Agile項(xiàng)目非常重視團(tuán)隊(duì)合作及授權(quán)，因?yàn)檫^程及工具雖然對(duì)項(xiàng)目有所幫助，但實(shí)際執(zhí)行項(xiàng)目的仍是團(tuán)隊(duì)。故團(tuán)隊(duì)才是項(xiàng)目的核心執(zhí)行力。盡早發(fā)展項(xiàng)目團(tuán)隊(duì)、提升工作生產(chǎn)力及團(tuán)隊(duì)有效溝通，可促使項(xiàng)目成功。項(xiàng)目是被客戶所接受的，范圍是由人員所界定的，故應(yīng)花更多時(shí)間在人員及互動(dòng)上，但是并不代表過程及工具不重要。
工作的軟件高于詳盡的文檔
項(xiàng)目的目標(biāo)通常是創(chuàng)造有價(jià)值及高質(zhì)量的產(chǎn)出。例：軟件、解決方案或可用的產(chǎn)品。但是，卻很容易因?yàn)檫^程中繁復(fù)及過度的文檔（例：由組織或規(guī)范所要求的）而失焦，甚至困擾項(xiàng)目團(tuán)隊(duì)。這并不代表不需要文檔，因?yàn)橛行┪臋n是必要或?qū)?xiàng)目是有益處的。文檔需保持Barely sufficient（剛剛好夠用就好）。與其花時(shí)間在繁復(fù)的初始規(guī)格文檔，不如花2-4周短期時(shí)間，分階段產(chǎn)出軟件，再來修正規(guī)格文檔。
客戶合作高于合同談判
項(xiàng)目團(tuán)隊(duì)與客戶應(yīng)建立彼此互信關(guān)系，客戶是最知道項(xiàng)目需求的人，所以項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該與客戶往相同的方向前進(jìn)、協(xié)同合作并站在客戶立場(chǎng)，為其產(chǎn)出價(jià)值，而非與其對(duì)立或?qū)?。許多項(xiàng)目往往為保護(hù)各自利益，過度專注于合同條款中硬性規(guī)定的協(xié)商，卻忽略了與客戶協(xié)同合作和保持合同彈性的重要。Agile合同可以提供客戶修改及變更的彈性。
響應(yīng)變化高于遵循計(jì)劃
在變動(dòng)的環(huán)境、初期信息不足、客戶情境改變、客戶看到半成品欲修改或其他不可預(yù)期的因素，項(xiàng)目難免變動(dòng)。此時(shí)應(yīng)適時(shí)的調(diào)整，而不是僵持按原計(jì)劃執(zhí)行。這并不代表項(xiàng)目不需要做規(guī)劃，而是計(jì)劃不需要一開始就做太多貨太詳細(xì)，可滾動(dòng)式規(guī)劃在逐步修正即可。傳統(tǒng)的項(xiàng)目是期望在項(xiàng)目進(jìn)度過程中，客戶盡量不要提出變更，故有很嚴(yán)謹(jǐn)?shù)淖兏刂瞥绦颉gile項(xiàng)目則是歡迎客戶變更，所以每個(gè)過程迭代都設(shè)計(jì)有規(guī)劃會(huì)議及Demo（展示）會(huì)議，皆可讓客戶借由反饋而完成變更。
敏捷12原則
源自這些價(jià)值觀的十二大原則：
1、通過早期連續(xù)交付高價(jià)值工作來滿足客戶的需求。
2、大工作分成可以迅速完成的較小組成部分。
3、識(shí)別最好的工作是從自我組織的團(tuán)隊(duì)中出現(xiàn)的。
4、要善于激勵(lì)項(xiàng)目人員，給予他們所需的環(huán)境和支持，并相信他們能夠完成任務(wù)。
5、創(chuàng)建可以改善可持續(xù)工作的流程。
6、維護(hù)完整工作不便的步調(diào)。
7、歡迎對(duì)需求提出變更，即使在項(xiàng)目開發(fā)后期也不例外。
8、在項(xiàng)目期間每天與項(xiàng)目團(tuán)隊(duì)和業(yè)務(wù)所有者開會(huì)。
9、在定期修正期，讓團(tuán)隊(duì)反映如何能高效，然后進(jìn)行相應(yīng)地行為調(diào)整。
10、通過完成的工作量來計(jì)量工作進(jìn)度。
11、不斷地追求完善。
12、利用調(diào)整獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。
敏捷的作用？
1、更容易地滿足最后的期限要求；
2、減少軟件bug；
3、代碼容易維護(hù)；
4、客戶滿足度增加；
5、敏捷團(tuán)隊(duì)效率高，很少加班。
敏捷思維
敏捷不是一套固定的流程，是一種在工作時(shí)所應(yīng)有的思維與方向；是一個(gè)在了解敏捷宣言中提及的4大價(jià)值與12大準(zhǔn)則后所應(yīng)有的心態(tài)或觀點(diǎn)；是一個(gè)不被任何單一學(xué)說、架構(gòu)、方法論綁死的團(tuán)隊(duì)協(xié)同合作方式。
Being Agile
一味地追趕潮流采用的敏捷，既不了解敏捷精神，也不清楚敏捷適用的環(huán)境，這樣會(huì)造成重大失敗而舍棄敏捷，所有要成功的應(yīng)用敏捷，必須要：了解敏捷的優(yōu)勢(shì)與適用項(xiàng)目，確定可提供施行敏捷的必要資源，最后在聚集與如何操作敏捷的手法。在迭代之間歡迎變更，在迭代之中專注不變。
2Scrum方法
Scrum團(tuán)隊(duì)三大角色
由PO、SM和DT組成且缺一不可，團(tuán)隊(duì)數(shù)量一般7±2（5-9人）包括PO和SM。
PO即Product Owner 字面意思是產(chǎn)品或業(yè)務(wù)負(fù)責(zé)人，SM即Scrum Master，字面意思是敏捷教練、敏捷專家或者敏捷大師；DT即Development Team,字面意思是開發(fā)團(tuán)隊(duì)，角色可以互相支援。
1、是跨職能的自組織團(tuán)隊(duì)；
2、自組織團(tuán)隊(duì)自己選擇如何最好地完成工作，而不是由團(tuán)隊(duì)外的人指導(dǎo)；
3、跨職能團(tuán)隊(duì)擁有完成工作所需要的全部技能，不需要依賴團(tuán)隊(duì)以外的人；
4、這種團(tuán)隊(duì)模式的目的是最大限度地優(yōu)化靈活度、創(chuàng)造力和生產(chǎn)效率。
專業(yè)名詞
Sprint（沖刺）
Product Backlog（產(chǎn)品待辦事項(xiàng)列表）
Sprint Planning Meetings（沖刺規(guī)劃會(huì)議）
Sprint Backlog（沖刺待辦事項(xiàng)列表）
Sprint Execution （沖刺執(zhí)行）一般是2至4周時(shí)間
Daily Stand-up Meeting（每日站會(huì)）
Sprint Review?Meeting（沖刺審查會(huì)）
Sprint Retrospective?Meeting（回顧會(huì)議）
什么是Iteration或Sprint？
Iteration（迭代）是敏捷項(xiàng)目的一段周期，又稱為Sprint（沖刺），工作包含：規(guī)劃這段周期要做什么、執(zhí)行開發(fā)、展示完成品給客戶審查、開展Retrospective會(huì)議；迭代長(zhǎng)度約2-4周，通常越短越好。因?yàn)榭梢猿迷绨l(fā)現(xiàn)問題、調(diào)整方向及實(shí)現(xiàn)客戶的價(jià)值；在展示增量成品給客戶時(shí)，客戶可以提早看到他所要的功能，讓客戶IKIWISI（I Know It，When I See It；眼見為真）進(jìn)而確認(rèn)開發(fā)的方向。同時(shí)，可以調(diào)整下一個(gè)迭代的用戶故事優(yōu)先級(jí)。
Scrum 管理五大事件Events
1、Sprint（沖刺）：一個(gè)時(shí)間盒迭代，一般是2周sprint，不超過30天的sprint也很常見。
2、沖刺規(guī)劃會(huì)議：30天sprint時(shí)間盒是8小時(shí)，2周sprint時(shí)間盒是4小時(shí)。
3、每日站立會(huì)儀：一般在早上開15分鐘左右。
4、沖刺審查會(huì)議：一般30天sprint時(shí)間盒是4小時(shí)。
5、沖刺回顧會(huì)議：一般30天sprint時(shí)間盒是3小時(shí)?；仡檿?huì)議時(shí)間盒到期，這個(gè)sprint就結(jié)束。
每日站會(huì)內(nèi)容
1、昨天做的什么？
2、今天準(zhǔn)備做什么？
3、遇到什么問題或阻礙？提出來然后我們大家去解決。
仆人式領(lǐng)導(dǎo)
敏捷方法強(qiáng)調(diào)，仆人式領(lǐng)導(dǎo)是一種為團(tuán)隊(duì)賦權(quán)的方法。通過對(duì)團(tuán)隊(duì)服務(wù)來領(lǐng)導(dǎo)團(tuán)隊(duì)的實(shí)踐，它注重理解和關(guān)注團(tuán)隊(duì)成員的需要和發(fā)展，旨在使團(tuán)隊(duì)盡可能達(dá)到最高績(jī)效。作用促進(jìn)團(tuán)隊(duì)發(fā)現(xiàn)和定義敏捷。仆人式領(lǐng)導(dǎo)實(shí)踐并傳播敏捷。仆人式領(lǐng)導(dǎo)按照目的、人員、過程從事項(xiàng)目工作。目的：與團(tuán)隊(duì)一起定義“為什么”或目的，以便他們能圍繞項(xiàng)目目標(biāo)進(jìn)行合作互動(dòng)。整個(gè)團(tuán)隊(duì)在項(xiàng)目層面而不是人員層面優(yōu)化；人員：目標(biāo)確立后，鼓勵(lì)團(tuán)隊(duì)創(chuàng)造一個(gè)人人都能成功的環(huán)境。要求每個(gè)團(tuán)隊(duì)成員在項(xiàng)目工作中做出貢獻(xiàn)。過程：不要計(jì)劃遵循“完美”的敏捷過程，而是要注重結(jié)果。如果跨職能團(tuán)隊(duì)能夠常常交付完成的價(jià)值并反思產(chǎn)品和過程，團(tuán)隊(duì)就是敏捷的。團(tuán)隊(duì)將其過程叫什么并不重要。
仆人式領(lǐng)導(dǎo)職責(zé)
仆人式領(lǐng)導(dǎo)通過管理關(guān)系，在團(tuán)隊(duì)內(nèi)和組織中建立溝通與協(xié)作。這些關(guān)系可以幫助領(lǐng)導(dǎo)在組織中得心應(yīng)手地為團(tuán)隊(duì)提供支持。這種支持有助于消除障礙，促進(jìn)團(tuán)隊(duì)理順過程。由于仆人式領(lǐng)導(dǎo)了解敏捷，在應(yīng)用具體方法時(shí)踐行敏捷，因而他們能幫助滿足團(tuán)隊(duì)的需求。以下仆人式領(lǐng)導(dǎo)特征讓項(xiàng)目領(lǐng)導(dǎo)變得更加敏捷，促進(jìn)團(tuán)隊(duì)的成功：
1、提升自我意識(shí)；
2、傾聽；
3、為團(tuán)隊(duì)服務(wù)；
4、幫助他人成長(zhǎng)；
5、引導(dǎo)與控制；
6、促進(jìn)安全、尊重與信任；
7、促進(jìn)他人精力和才智提升。
教育相關(guān)方，使其了解為什么要敏捷以及如何敏捷；通過指導(dǎo)、鼓勵(lì)和幫助為團(tuán)隊(duì)提供支持；通過技術(shù)項(xiàng)目管理活動(dòng)，如量化風(fēng)險(xiǎn)分析幫助團(tuán)隊(duì)；慶祝團(tuán)隊(duì)的成功，為團(tuán)隊(duì)與外部團(tuán)隊(duì)合作提供支持，并起到橋梁的作用。
Scrum3大工件Artifacts
1、Product Backlog（產(chǎn)品待辦事項(xiàng)列表）完成最終產(chǎn)品前所有應(yīng)完成的工作事項(xiàng)，并按照優(yōu)先級(jí)排序。是項(xiàng)目唯一的范圍和需求來源。產(chǎn)品待辦事項(xiàng)列表會(huì)在項(xiàng)目開發(fā)的過程中動(dòng)態(tài)調(diào)整；待辦清單的用戶故事內(nèi)容。優(yōu)先級(jí)越高的越詳細(xì)，估算也較精確。低優(yōu)先級(jí)的用戶故事內(nèi)容則尚不需發(fā)展。
2、Sprint Backlog（沖刺待辦事項(xiàng)列表）是產(chǎn)品待辦清單里。被選定在該沖刺周期需完成的用戶故事。通常包含如何達(dá)到該Sprint goal的計(jì)劃。團(tuán)隊(duì)可用此預(yù)測(cè)該沖刺應(yīng)完成的產(chǎn)品功能或特性。由開發(fā)團(tuán)隊(duì)來負(fù)責(zé)管理機(jī)更新。
3、Increment（增量成品）在沖刺中產(chǎn)出的增量成品。增量成品要符合Scrum團(tuán)隊(duì)定義的Definition of Done（完成的定義）一定要具有可用性、可操作性。增量是這個(gè)sprint結(jié)束時(shí)實(shí)際完成和交付的所有產(chǎn)品待辦事項(xiàng)列表的總和。
客戶價(jià)值優(yōu)先級(jí)排序
客戶價(jià)值優(yōu)先級(jí)排序是一種以客戶觀點(diǎn)確認(rèn)價(jià)值的優(yōu)先級(jí)手法，項(xiàng)目團(tuán)隊(duì)與客戶一起排序工作的優(yōu)先級(jí)。以確保項(xiàng)目的方向是正確的。新增加或修正的用戶故事會(huì)記錄在產(chǎn)品待辦清單。在后續(xù)迭代規(guī)劃會(huì)議時(shí)，在評(píng)估其優(yōu)先級(jí)。排序價(jià)值活動(dòng)時(shí)，需讓客戶及團(tuán)隊(duì)共同參與。以增加彼此對(duì)價(jià)值的認(rèn)知。
Scrum價(jià)值觀
Scrum的五大價(jià)值觀分別為承諾、勇氣、專注、尊重和開放。
唯有scrum團(tuán)隊(duì)能充分內(nèi)化于實(shí)踐這五大價(jià)值觀，三大支柱才能成為現(xiàn)實(shí)。Scrum團(tuán)隊(duì)成員通過Scrum的角色、事件、工件來學(xué)習(xí)與探索這些價(jià)值觀；組織提供支持，團(tuán)隊(duì)勇于承諾，有勇氣面對(duì)工作挑戰(zhàn)。專注于項(xiàng)目產(chǎn)品的開發(fā)，并尊重組織與干細(xì)系人交付的資源。已以開放及信任的心態(tài)，與其他成員互動(dòng)完成項(xiàng)目目標(biāo)。
Scrum三大支柱
1、Transparency（透明）
過程的關(guān)鍵環(huán)節(jié)，對(duì)相關(guān)負(fù)責(zé)人員必須是明顯易見的。透明度要求的是一套共同標(biāo)準(zhǔn)，以定義所有的關(guān)鍵環(huán)節(jié)所有觀察者對(duì)所見的事物需有相同認(rèn)知。
2、Inspection（檢查）
Scrum使用者必須頻繁地檢查Scrum的工件以及達(dá)成Spring goal的進(jìn)度；Scrum同時(shí)也強(qiáng)調(diào)檢查不應(yīng)過度頻繁且阻礙到開發(fā)工作本身。
3、Adaptation（適應(yīng)）
當(dāng)檢查人員發(fā)現(xiàn)過程有一個(gè)或多個(gè)面向偏離到可接受范圍之外，可能導(dǎo)致客戶無法接受相關(guān)產(chǎn)品，必須調(diào)整此過程；調(diào)整必須盡快及時(shí)，以免偏離擴(kuò)大。
盡可能晚做決策
針對(duì)產(chǎn)品方向及未來目標(biāo)的不確定性，強(qiáng)調(diào)任何重大的決策越晚做決定越佳。信息越晚越明確，故越晚做決策，可挑選的決策選項(xiàng)就越來越少了。確保決策的正確性?？纱蠓冉档鸵蛱缱鰶Q策而造成晚期大量變更所帶來的風(fēng)險(xiǎn)，最晚的決策點(diǎn)是（最晚回應(yīng)時(shí)刻）在這個(gè)時(shí)刻之后就沒有必要再做決定了。Sprint規(guī)劃會(huì)議不怕時(shí)間短，可以后續(xù)慢慢分解工作。
沖刺展示會(huì)議
沖刺展示會(huì)議又稱為沖刺評(píng)審會(huì)議在sprint結(jié)束前舉行，用于已檢查Increment及調(diào)整Product backlog；
于Sprint Revive開發(fā)團(tuán)隊(duì)和干系人協(xié)同討論本次Sprint所完成的工作；這是非正式會(huì)議。產(chǎn)品增量展示是為了讓所有人反饋意見及鼓勵(lì)大家共同討論。通常1月的sprint會(huì)有4小時(shí)展示會(huì)議，sprint越短，會(huì)議也越短。
沖刺回顧會(huì)議
提供開發(fā)團(tuán)隊(duì)一個(gè)自我檢驗(yàn)的機(jī)會(huì)，并規(guī)劃下一個(gè)Sprint的改善計(jì)劃?；仡檿?huì)議緊接在展示會(huì)議之后，而在下一個(gè)Sprint plaanning 之前。通常一個(gè)月的Sprint會(huì)有3小時(shí)的會(huì)議，Sprint越短，會(huì)議也較短。SM以作為團(tuán)隊(duì)成員身份參加此會(huì)議，確保Scrum過程舒暢。目的檢驗(yàn)本次Sprint關(guān)于人員、關(guān)系、過程及工具的運(yùn)作情況，提出檢討與改善。找出并排序什么做得很好及需要改善的部分；建立改善計(jì)劃使開發(fā)團(tuán)隊(duì)能持續(xù)優(yōu)化敏捷運(yùn)作。
SM在Scrum的過程框架內(nèi)，鼓勵(lì)開發(fā)團(tuán)隊(duì)改善其開發(fā)過程，讓下一個(gè)Sprint更有效率，更愉快。在每個(gè)沖刺回顧會(huì)議開發(fā)團(tuán)隊(duì)適當(dāng)?shù)馗倪M(jìn)工作過程，調(diào)整完成的定義，以提高產(chǎn)品質(zhì)量。會(huì)議最后開發(fā)團(tuán)隊(duì)?wèi)?yīng)該找出下一個(gè)Sprint應(yīng)實(shí)施的改善行動(dòng)。實(shí)施改善是開發(fā)團(tuán)隊(duì)的自我檢驗(yàn)與調(diào)整的結(jié)果。雖然這些改善可于任何時(shí)間點(diǎn)實(shí)施，但回顧檢討會(huì)議提供了專注檢查與調(diào)整的正式機(jī)會(huì)。
3敏捷通用實(shí)踐
用戶故事（User Story）
用戶故事是敏捷項(xiàng)目的需求記錄，采用活潑生動(dòng)述說故事的方式，以取代傳統(tǒng)項(xiàng)目對(duì)于客戶需求格式化的描述。用戶故事宜短不宜長(zhǎng)?；靖袷剑荷頌槭裁唇巧?，我想要產(chǎn)品擁有什么特性，如此可以實(shí)現(xiàn)什么價(jià)值。
用戶故事從客戶角度來描述其對(duì)于項(xiàng)目產(chǎn)出所期望的功能，且大約能在1-3天完成的工作量大小。將用戶故事整合后成為用戶故事待辦清單，或稱產(chǎn)品待辦列表。用戶故事相當(dāng)于傳統(tǒng)文檔而言相對(duì)簡(jiǎn)單、有趣、易于溝通，而且?guī)椭覀兂掷m(xù)更正。
每個(gè)用戶故事皆需要具備三個(gè) 要素：Card（卡片）、Conversation（對(duì)話）、及Comfirmation（確認(rèn)）。
1、card
將用戶故事寫在約1/4A4大小的卡片上，內(nèi)容不是為記錄完整客戶需求為目的，而是提供恰好足夠的說明 ，以協(xié)助識(shí)別客戶需求?？ㄆ嫌涗泝?yōu)先級(jí)與成本的簡(jiǎn)要信息，卡片通常在進(jìn)入工作排程時(shí)，會(huì)交給負(fù)責(zé)團(tuán)隊(duì)成員，工作完成之后，卡片會(huì)遞回到客戶手里。
2、conversation
用戶故事要便于團(tuán)隊(duì)與PO雙方的持續(xù)對(duì)話，這些對(duì)話絕大多數(shù)都是口語的面對(duì)面談話。借由持續(xù)的對(duì)話溝通以達(dá)成共識(shí)。（po與團(tuán)隊(duì)之間對(duì)話，版本發(fā)布規(guī)劃階段，團(tuán)隊(duì)需要估算哪些用戶故事迭代規(guī)劃階段，團(tuán)隊(duì)執(zhí)行哪些用戶故事）
3、confirmation
確認(rèn)是用戶故事重要的一環(huán)。用戶故事接收原則，在迭代規(guī)劃前就被制定、并在規(guī)劃過程中得到雙方的認(rèn)可。在版本發(fā)布規(guī)劃階段，有客戶制定完成的定義，用戶故事開發(fā)完成后，可以借此判定是否滿足，并在展示時(shí)看有沒有滿足客戶的接收原則。
故事的6大特性
6.Testable（可測(cè)試的）：一定要具備接收原則，以供項(xiàng)目團(tuán)隊(duì)測(cè)試去確認(rèn)完成。
相對(duì)故事點(diǎn)數(shù)
故事點(diǎn)數(shù)是一種相對(duì)估算法，估算的單位是故事點(diǎn)數(shù)（SP? Story Points）。敏捷使用此工具讓項(xiàng)目能快速的進(jìn)行估算。
此估算方法可解決以下2個(gè)常見的估算問題：
1.人們通常無法精確估算工作大小。
2.精確的估算流程是復(fù)雜且不受歡迎。
比如：若要確切的估算出奇異果、橘子或哈密瓜幾公分大是很難的。但我們可以在瞬間將水果由小到大排序這就是相對(duì)確切的估算。
最佳估算用戶故事的作法：
1、當(dāng)特定的用戶故事信息有新信息涌現(xiàn)時(shí)，估算者可以隨時(shí)改變估算想法。
2、同時(shí)適用于大型用戶故事（史詩）及小型用戶故事。
3、前期不需要花太多時(shí)間估算，因?yàn)楣浪銛?shù)據(jù)的逐步完善是敏捷項(xiàng)目的常態(tài)。
4、提供對(duì)項(xiàng)目進(jìn)度和后續(xù)工作有利的信息。
5、應(yīng)容忍估算的不精確。
6、可用于規(guī)劃版本發(fā)布日期。
進(jìn)行用戶故事估算注意事項(xiàng)
1、團(tuán)隊(duì)需負(fù)責(zé)故事點(diǎn)數(shù)大小的定義，由團(tuán)隊(duì)負(fù)責(zé)定義SP的大小。每個(gè)項(xiàng)目的故事點(diǎn)數(shù)大小不盡相同，無法相互比較。
2.由于故事點(diǎn)數(shù)不是理想時(shí)長(zhǎng)，所以估算時(shí)需要考量所有可能因素。故事點(diǎn)數(shù)的估算已涵蓋所有活動(dòng)，不需增加額外的時(shí)間。（例：估算某工作為2個(gè)故事點(diǎn)數(shù)，這時(shí)間包含問題處理、等待、實(shí)際工作及溝通協(xié)調(diào)時(shí)間）
3.在正常運(yùn)作的節(jié)奏下，項(xiàng)目團(tuán)隊(duì)可量測(cè)及預(yù)測(cè)項(xiàng)目開發(fā)的Velocity（速度）?！纠纾哼^去2個(gè)迭代周期平均完成20個(gè)故事點(diǎn)數(shù)，若項(xiàng)目目標(biāo)還剩下100個(gè)故事點(diǎn)數(shù)，則整個(gè)項(xiàng)目推測(cè)尚需5個(gè)迭代方能完成項(xiàng)目】
4.尺寸大小需前后相對(duì)應(yīng)
3個(gè)sp的用戶故事，所投入的工作量必須大約是1個(gè)sp的用戶故事工作量的三倍。同一個(gè)項(xiàng)目中所有用戶故事的故事點(diǎn)數(shù)大小需維持一致。
規(guī)劃撲克牌
撲克牌上的數(shù)字，可代表單位的大小。例：開發(fā)天數(shù)或Story Point（sp；故事點(diǎn)數(shù)）規(guī)劃撲克牌也使用斐波那契數(shù)列因?yàn)榍昂髷?shù)字之間有明確的差異，可剔除估算者之間的微小差異。
操作方法
1.參與者每人發(fā)一副規(guī)劃撲克牌。
2.會(huì)議主持人朗讀一張用戶故事卡片，團(tuán)隊(duì)互相討論以對(duì)于故事需求產(chǎn)生共識(shí)。
3.參與者根據(jù)自己對(duì)用戶故事的估算，選出一張撲克牌。
4.所有人一起掀牌，讓彼此可以看到撲克牌數(shù)字。
結(jié)果分為2種：
第一種所有人數(shù)字都差不多，可取眾數(shù)。
第二種其中1-2人的數(shù)字和大家差很多，這可能是異常點(diǎn)，此時(shí)差很多分?jǐn)?shù)的成員說明意見后，再重新估算。
規(guī)劃撲克牌的優(yōu)點(diǎn)
可分多次循環(huán)估算，讓參與者同時(shí)提出估算，以去除從眾效應(yīng)和光環(huán)效應(yīng)，可收斂團(tuán)隊(duì)對(duì)估算結(jié)果的看法。
理想時(shí)長(zhǎng)（Ldeal Time）
成員在項(xiàng)目過程中受到干擾是無法被完全避免的。例如：打擾、突發(fā)狀況、日常會(huì)議、執(zhí)行非項(xiàng)目工作。估算項(xiàng)目工時(shí)因此充滿許多變數(shù)。使用（Ldeal time）理想時(shí)長(zhǎng)估算工時(shí)，可簡(jiǎn)化估算流程?？梢允褂妹朗阶闱騺肀扔鞔烁拍?，一場(chǎng)足球只有四節(jié)，每節(jié)15分鐘。理想時(shí)長(zhǎng)1小時(shí)完成。但是，每場(chǎng)球賽平均時(shí)間是3小時(shí)，因?yàn)橹虚g要加上暫停，電視廣告、犯規(guī)、中場(chǎng)休息等非正式比賽運(yùn)行時(shí)間。
理想時(shí)長(zhǎng)的假設(shè)前提如下：所有上班時(shí)間都投入在產(chǎn)品開發(fā)的工作，工作不會(huì)被打斷；不需要參加會(huì)議，不需要等待，已具備所有工作上需要的資源。
通常會(huì)再搭配一個(gè)真實(shí)工作時(shí)間的計(jì)算系數(shù)：例如一天有8小時(shí)理想工作時(shí)間*0.7（真實(shí)工作時(shí)間）5.6小時(shí)實(shí)際工作時(shí)間。
任務(wù)板（Task Board）
任務(wù)板通常有白板或者一面墻即可使用，是信息發(fā)射源的概念，確保有效地將信息發(fā)布到整個(gè)團(tuán)隊(duì)。任務(wù)板的信息通常在每個(gè)迭代開始時(shí)重設(shè)，以對(duì)應(yīng)新的迭代規(guī)劃；并且在每日站會(huì)會(huì)議中由開發(fā)團(tuán)隊(duì)更新進(jìn)度。可成為每日站會(huì)會(huì)議的焦點(diǎn)，讓團(tuán)隊(duì)于項(xiàng)目進(jìn)度及障礙。就算是分布在不同地理位置的團(tuán)隊(duì)，也可應(yīng)用電子化的任務(wù)板來管理跨地區(qū)的項(xiàng)目。
任務(wù)板通常使用多個(gè)欄位標(biāo)示，以促進(jìn)團(tuán)隊(duì)的自我組織；有五欄位和三欄位標(biāo)示法。任務(wù)板可用來區(qū)分一般用戶故事與缺點(diǎn)改善活動(dòng)的差別。使用特定顏色代表有障礙的Task；當(dāng)團(tuán)隊(duì)每日看到任務(wù)板的卡片自左到右移動(dòng)，會(huì)有很大成就感。
燃起圖（Burn Up）/燃盡圖（Down Chart）
燃起圖與燃燒圖是用以展示項(xiàng)目進(jìn)度的工具，也可以追蹤其他變數(shù)；這2個(gè)圖形最大功用，可以輔助判定項(xiàng)目進(jìn)度，并且預(yù)測(cè)下一個(gè)版本何時(shí)可以完成發(fā)布。
燃盡圖無法展現(xiàn)因變更造成的范圍變化；燃起圖可將進(jìn)度與范圍分別展示出來，不會(huì)因?yàn)榉秶淖冏屵M(jìn)度的信息失真；和燃盡圖相比，在進(jìn)度展示方面，燃起圖信息比較豐富；燃起圖的另一好處是可協(xié)助計(jì)算團(tuán)隊(duì)的開發(fā)速度。
速度（Velocity）
Velocity是敏捷項(xiàng)目的指標(biāo)，用以測(cè)量出團(tuán)隊(duì)在單一迭代周期能夠完成多少的工作量；速度也可用以估算及預(yù)測(cè)后續(xù)的迭代數(shù)量、版本發(fā)布或是整個(gè)項(xiàng)目所需要的時(shí)間是多少；敏捷項(xiàng)目速度的計(jì)量單位與團(tuán)隊(duì)用來估算工作的單位相同；（例如：工時(shí)、工作日、理想時(shí)間或故事點(diǎn)數(shù)）
項(xiàng)目初期，速度是以初始迭代團(tuán)隊(duì)能夠完成的工作量作為后續(xù)估算的基礎(chǔ)。通常初期開發(fā)速度不穩(wěn)定，但歷經(jīng)數(shù)個(gè)迭代之后，團(tuán)隊(duì)成員在項(xiàng)目工作的經(jīng)驗(yàn)積累，加上工具使用的熟練度提高，開發(fā)速度會(huì)逐漸上升并呈現(xiàn)持平趨勢(shì)，此時(shí)團(tuán)隊(duì)可借由穩(wěn)定的速度來估算剩余工作進(jìn)度與可能完成日期。
例：團(tuán)隊(duì)平均一個(gè)迭代完成50個(gè)sp，若待辦清單尚有500個(gè)未完成的sp，接續(xù)只要500除以50，即可估算出此項(xiàng)目還需要10個(gè)迭代才能完成。
故事地圖（Story Map）
是一極佳的視覺工具，其主要用途是展示功能重要性，項(xiàng)目產(chǎn)出所涵蓋不同的范圍。
區(qū)分：骨干、可行走骨架、附加特性。
骨干：系統(tǒng)必要的特性。如引擎、剎車系統(tǒng)。
可行走的骨架：掛在骨干下，讓系統(tǒng)可順利運(yùn)作的最基本特性。如輪胎、車架、剎車組件。
附加特性：增加系統(tǒng)附加價(jià)值，但無此功能特性，系統(tǒng)還是可以運(yùn)作。如天窗、導(dǎo)航系統(tǒng)、油電混合。
用戶畫像（Persona）
讓團(tuán)隊(duì)成員可以站在虛擬人物的角度能夠更加了解，推論出用戶的真正需求，且更利于成員之間相互溝通。優(yōu)勢(shì)：
1、幫助成員了解不同群組的屬性以及特定需求，以及明確使他們意見達(dá)成一致。
2、經(jīng)由合乎個(gè)別用戶畫像的需求，提出合適的解決方案。
3、用一張面孔來激發(fā)團(tuán)隊(duì)成員于特殊族群的同理心。
在項(xiàng)目初期，團(tuán)隊(duì)要能深入了解最終使用項(xiàng)目產(chǎn)出的用戶群組，最有效的方式就是使用用戶畫像；用戶畫像針對(duì)相關(guān)方群組特性的快速關(guān)鍵描述，越寫實(shí)越好，單用戶畫像描述的是虛構(gòu)而非真實(shí)人物。
用戶畫像4大內(nèi)容
1.名字（加上昵稱利于記憶）
2.圖片（代表性的人物圖示）
3.描述（此人物如何與項(xiàng)目產(chǎn)出的互動(dòng)）
4.價(jià)值（其對(duì)項(xiàng)目最終價(jià)值交付的認(rèn)知，這個(gè)人物期望最后能得到什么，不是專注人物的what與how，而是聚焦于why）
回顧檢討會(huì)議
回顧檢討會(huì)議是敏捷開發(fā)特殊的自我學(xué)習(xí)及調(diào)整會(huì)議，所有的敏捷方法皆有此機(jī)制。主要目的是Learning（學(xué)習(xí)）、Reflection（意見反映）和Readjustment（重新調(diào)整）工作項(xiàng)目或作法。
Retrospective發(fā)生在每一個(gè)迭代/沖刺結(jié)束前，團(tuán)隊(duì)成員集合在一起，共同檢查及調(diào)整團(tuán)隊(duì)的做事方法和協(xié)同合作方式。
由于Retrospective是發(fā)生在項(xiàng)目過程中，所得到的修正作法，可以馬上運(yùn)用到接下來的迭代循環(huán)中，當(dāng)下進(jìn)行中的項(xiàng)目因此立即收益。
PMBOK中傳統(tǒng)經(jīng)驗(yàn)教訓(xùn)會(huì)議，與敏捷項(xiàng)目中的回顧檢討會(huì)議形態(tài)不同，是將經(jīng)驗(yàn)記錄于文檔。并期望下一個(gè)相同特性的項(xiàng)目可以應(yīng)用。但是有以下缺點(diǎn)：
1.下一個(gè)項(xiàng)目的特性（例：技術(shù)、團(tuán)隊(duì)、PM、商業(yè)需求）未必相同。
2.觀看前一位項(xiàng)目經(jīng)理所做的經(jīng)驗(yàn)教訓(xùn)文檔時(shí)，由于項(xiàng)目并非自己所做，故不會(huì)很認(rèn)真看待。
3.經(jīng)驗(yàn)教訓(xùn)的頻率太少，僅每個(gè)項(xiàng)目或階段（例：三個(gè)月或半年）執(zhí)行一次，可能因時(shí)隔已久而淡忘。
回顧檢討會(huì)議五個(gè)步驟，都充滿著許多實(shí)用的Workshop（研討會(huì)），可解決團(tuán)隊(duì)在每日站立會(huì)所匯報(bào)遇到的問題和障礙，并在回顧檢討會(huì)議依據(jù)團(tuán)隊(duì)的反映與觀察識(shí)別出問題點(diǎn)或需要改善的地方。五個(gè)步驟的工具在“Agile Retrospective Making Good Teams Great” by Esther Derby 有詳細(xì)描述，此書為PMI的書單之一。
回顧檢討會(huì)議皆是與“關(guān)系”、“工具”、“流程”、及“人”有關(guān)的內(nèi)容，可為項(xiàng)目帶來的好處為：
1.改善生產(chǎn)力：可降低返工；
2.改善能力：可強(qiáng)化不足的知識(shí)。當(dāng)團(tuán)隊(duì)有更多人知道這些知識(shí)，則可更有效的執(zhí)行工作；
3.改善質(zhì)量：找出問題及缺陷并消除原因；
4.改善產(chǎn)能：找出流程效率不足的地方，用以提升團(tuán)隊(duì)的產(chǎn)能。
一、開場(chǎng)
回顧會(huì)議開始時(shí)，需要設(shè)定開場(chǎng)氣氛，以協(xié)助參與者專注于思考工作進(jìn)行的狀況，讓參與者做好接下來的Gather data（收集數(shù)據(jù)）和Generate insights（產(chǎn)生見解）過程的心理準(zhǔn)備。開場(chǎng)的目的是創(chuàng)造會(huì)議氣氛，讓參與者可以很自在的發(fā)表意見。開場(chǎng)的技巧，是讓參與者越早發(fā)言越好。若參與者沒有在回顧會(huì)議一開始時(shí)有機(jī)會(huì)發(fā)言，他們會(huì)認(rèn)為不需要發(fā)言或保持沉默是可以被接受的。但不發(fā)言或保持沉默會(huì)導(dǎo)致無生產(chǎn)力的回顧會(huì)議。
開場(chǎng)常用工具通常為：簽到（Check-ins）、ESVP。
簽到：就是協(xié)助參與者拋開其顧慮，專注在回顧會(huì)議，可以使用圓桌會(huì)議的輪流發(fā)言方式（一般5-9人），請(qǐng)參與者簡(jiǎn)單說明以下任一個(gè)問題：
1、你期望可以從回顧會(huì)議獲得什么？
2、你對(duì)于回顧會(huì)議的主要想法？
3、你現(xiàn)在在想什么？
ESVP：活動(dòng)的目的是了解參與者對(duì)回顧會(huì)議的看法，用以量測(cè)參與者的參與活動(dòng)及投入程度。步驟如下：
1、參與者匿名選擇回顧會(huì)議所扮演的角色：
Explorers（探索者）：樂于學(xué)習(xí)任何事物，像海綿吸水一般。
Shoppers（采購者）：尋找對(duì)他們有用的信息，參與此次的回顧會(huì)議有他們特別的目的。
Vacationers（渡假者）：對(duì)回顧會(huì)議沒有興趣，但是可以暫時(shí)離開工作崗位，來這里渡假很開心。
Prisoners（囚犯）：感覺被強(qiáng)迫參加回顧會(huì)議，像是關(guān)在會(huì)議室里，心里非常抗拒。
2、匿名的結(jié)果被收集后，為避免填寫者有壓力，由第三者把統(tǒng)計(jì)結(jié)果寫在白板上。如下圖
3、經(jīng)過統(tǒng)計(jì)后，主持人應(yīng)該公開的把所有紙條撕掉，讓參與者安心。
4、最后詢問參與者對(duì)統(tǒng)計(jì)結(jié)果的看法，并討論這結(jié)果對(duì)他們回顧會(huì)議的意義。
二、收集數(shù)據(jù)（Gather Data）
利用回顧會(huì)議收集團(tuán)隊(duì)成員關(guān)于該次迭代循環(huán)執(zhí)行狀況的感受，用以建立團(tuán)隊(duì)對(duì)于問題的共同看法。
若缺乏數(shù)據(jù)，團(tuán)隊(duì)對(duì)于哪些地方需要改變或改善都只能猜測(cè)，或只聚焦于片面的改善活動(dòng)而喪失全面性改善的機(jī)會(huì)。
收集數(shù)據(jù)不止于定量數(shù)據(jù)，也有可能是定性的數(shù)據(jù)，客觀描述或事實(shí)也是數(shù)據(jù)的一部分。收集數(shù)據(jù)方法：時(shí)間軸（Timeline）、顏色代碼點(diǎn)（Color Code Dots）
例1：項(xiàng)目迭代完成100個(gè)SP。
例2：資深成員A在Demo meeting（演示會(huì)議）時(shí)常常遲到。
例3：客戶對(duì)第3次迭代的演示結(jié)果贊賞有加。
時(shí)間軸：透過模擬項(xiàng)目工作期間發(fā)生的主要事件，從不同面向建立工作執(zhí)行狀況的畫面。用以協(xié)助團(tuán)隊(duì)收集并識(shí)別該次迭代循環(huán)的問題狀況，團(tuán)隊(duì)成員使用便利貼，寫下載此次迭代期間，Good（好的）、Problematic（有問題）、Significant（有意義）的事件，并將其依時(shí)間順序貼到白板上。會(huì)議主持人接著讓團(tuán)隊(duì)成員討論這些事件，以了解當(dāng)時(shí)大家對(duì)事件的感覺。
操作步驟：
1.主持人在白板畫出時(shí)間軸，并切分出相對(duì)的時(shí)間隔欄位。如下圖? 1-7代表時(shí)間天數(shù)
2.對(duì)團(tuán)隊(duì)解說活動(dòng)目的。請(qǐng)團(tuán)隊(duì)將事件填入時(shí)間軸，以建立此次迭代期間，不同面向的全貌。
3.分組，每組成員小于5人（含），并給各小組便利貼。
4.請(qǐng)每位參與者回想，并使用不同顏色的便利貼寫下此循環(huán)時(shí)間內(nèi)發(fā)生的Good（好的）、Problematic（有問題）、Significant（有意義）的事件。
5.將便利貼貼在時(shí)間軸上，并討論這些事件，依據(jù)討論的結(jié)果在時(shí)間軸圖的下方畫出心情曲線，以追蹤每一段時(shí)間周期內(nèi)的團(tuán)隊(duì)心情變化。
顏色代碼點(diǎn)（Color Code Dots）
是一種團(tuán)隊(duì)心情意見展現(xiàn)技術(shù)。此技術(shù)可與時(shí)間軸技術(shù)結(jié)合。用以收集參與成員的心情。成員使用不同顏色的圓形貼紙顯示情緒的高低，貼在時(shí)間軸事件上。操作步驟如下：
1.發(fā)給每位參與者7~10點(diǎn)的2種顏色的圓形貼紙，并說明哪個(gè)顏色代表高能量，哪個(gè)代表低能量。（例：藍(lán)色代表心情好，紅色代表心情不好）
2.請(qǐng)參與成員將圓形貼紙貼在時(shí)間軸的事件上，以顯示每段時(shí)間的團(tuán)隊(duì)心情指數(shù)。如下圖
三、產(chǎn)生見解（Generate Insights）
產(chǎn)生各種各樣的見解，主要是針對(duì)收集數(shù)據(jù)階段收集到的數(shù)據(jù)進(jìn)行分析，此階段主要促進(jìn)團(tuán)隊(duì)分析問題、了解問題的影響，以利于在下一個(gè)階段提出解決方案。以下5種常見的產(chǎn)生見解技術(shù)：
1、Brainstorming（頭腦風(fēng)暴）
2、Five whys（五個(gè)為什么）
3、Fish bone（魚骨圖）
4、Dot Voting（記點(diǎn)投票）
5、Identify themes（識(shí)別主題）
魚骨圖是一種視覺化的根本原因分析工具，通常與5個(gè)問什么技術(shù)合并使用。團(tuán)隊(duì)透過識(shí)別某問題或狀態(tài)的原因與其影響，尋找可能的問題真因。是一種Top-down（自上而下）的作法，從造成問題的各項(xiàng)原因依序往下探索發(fā)掘真因。步驟如下：
1、畫出一個(gè)空白的魚骨圖在白板上，并在魚頭寫上需要改善的問題或狀況。
2、分析可能造成問題的主要因素類別，并寫在魚骨上。
五個(gè)為什么是透過問題原因及其影響的關(guān)聯(lián)性，進(jìn)而找出問題的Root cause（根本原因），此活動(dòng)通常使用2人小組或小組的方式實(shí)施。透過小組內(nèi)一次次的對(duì)談（Ask “Why？”）逐漸找出問題的根本原因。小組討論時(shí)，針對(duì)目前討論的議題問5次Why，以取得慣性思考之外的思維。五個(gè)為什么僅為代表性的說法，主要是期望團(tuán)隊(duì)借由對(duì)問題的不斷討論，找到根本原因。
記點(diǎn)投票又稱為Prioritize with dots，是排序優(yōu)先級(jí)的活動(dòng)，可使用在回顧會(huì)議時(shí)期產(chǎn)生見解或Decide what to do（決定行動(dòng)方案）階段，此活動(dòng)協(xié)助團(tuán)隊(duì)從一連串的建議清單中找出執(zhí)行的優(yōu)先級(jí)，是通過多人投票技術(shù)，以決定優(yōu)先級(jí)，操作步驟如下：
1、假設(shè)有40個(gè)方案可選擇，每人分到8個(gè)點(diǎn)，每個(gè)方案不限定只能給1點(diǎn)，若投票者覺得此方案重要可將8點(diǎn)全投在統(tǒng)一方案。所有的點(diǎn)數(shù)都要用完。
2、待全部人完成投票后，在依據(jù)總和點(diǎn)數(shù)排出優(yōu)先級(jí)。（偷電數(shù)可以是公開或不記名的，以防止某人影響最終方案或給予記名投票者潛在的壓力）
四、決定行動(dòng)方案（Decide What To Do）
決定行動(dòng)方案是針對(duì)產(chǎn)生見解過程識(shí)別出的主題與跟本原因，制定后續(xù)的行動(dòng)方案，此階段利用各種技術(shù)建立明確的改善目標(biāo)與實(shí)施方案，并決定后續(xù)追蹤實(shí)施方案的績(jī)效與進(jìn)度的方式。以下是四種常見的Decide what to do 活動(dòng)：
1、Short subjects（簡(jiǎn)短主題）
2、SMART goals（SMART目標(biāo)）
3、Retrospective panning game（回顧規(guī)劃游戲）
4、Circle of questions（問題圈）
簡(jiǎn)短主題可以協(xié)助團(tuán)隊(duì)快速達(dá)成問題解決行動(dòng)的共識(shí)，此活動(dòng)應(yīng)用在團(tuán)隊(duì)產(chǎn)生見解過程產(chǎn)出之解決問題的Ideas上，將這些想法分類成簡(jiǎn)短主題并寫上白板，讓團(tuán)隊(duì)聚焦于這些主題中，快速討論，達(dá)成行動(dòng)的共識(shí)。簡(jiǎn)短主題分類范例如下：
哪些做得很好、哪些下次可以改善Keep（保留）、Drop（移除）、Add（新增）、Start doing（開始做）、Stop doing（停止再做）、Do more of（可多做一些）、Do less of（可少做一些）。
