英國政治家拇舀，溫斯頓.丘吉爾 說過一段話：
如果你讓我說2分鐘逻族，我需要3周的時間準備。
如果你讓我說半小時骄崩，我需要1周的時間準備聘鳞。
如果你讓我說1小時，我現(xiàn)在就準備好了要拂。
達芬奇 留下了6000多頁的手稿抠璃，其中包含了一句話：
簡單就是終極的復(fù)雜。
今天脱惰，讓我們來聊聊不一樣的度量搏嗡。
對于一個敏捷團隊，怎樣說明團隊做得很好拉一？
以終為始采盒，我們希望團隊達到怎樣的狀態(tài)？
1.擁有穩(wěn)定的迭代速率
2.擁有接近100%的迭代故事完成率
3.達成迭代目標
4.交付的產(chǎn)品質(zhì)量高蔚润，問題少磅氨，用戶體驗佳
5.系統(tǒng)穩(wěn)定運行
6.達成業(yè)務(wù)目標
想要達到這樣的結(jié)果，我們需要關(guān)注哪些指標嫡纠？
1.迭代速率
2.迭代計劃完成率
3.迭代目標達成率
4.業(yè)務(wù)目標達成率
5.線上產(chǎn)品缺陷數(shù)
6.產(chǎn)品體驗用戶反饋
其他：
功能發(fā)布后烦租，系統(tǒng)性能數(shù)據(jù)變化趨勢
系統(tǒng)連續(xù)運行無故障時間
核心的六個指標决瞳，外加兩個系統(tǒng)性能（防微杜漸，關(guān)注趨勢變化）和穩(wěn)定性（穩(wěn)定大于一切）指標左权。
你也許會問皮胡，為什么DevOps的核心指標：吞吐量，流動效率 都沒有包含在內(nèi)赏迟？
因為前面假設(shè)了屡贺，這是敏捷團隊，假設(shè)團隊以固定的迭代周期（1-2周）交付需求锌杀，并采用了點數(shù)估算的方式甩栈。這種情況下，這兩個指標的作用減弱糕再，屬于非核心指標量没。
敏捷不應(yīng)該追求盡可能快么？
敏捷追求的快突想，不是開發(fā)動作的快殴蹄，而是價值交付的快。
將需求價值從高到低排列猾担，始終遵循二八原則袭灯，優(yōu)先交付價值最高的需求。
敏捷講究的是以價值為中心绑嘹，以持續(xù)穩(wěn)定的迭代節(jié)奏稽荧，高質(zhì)量的交付價值。
為什么是這6個指標工腋？
迭代速率
?--?衡量團隊的真實交付能力姨丈，便于對后續(xù)需求進行估算和排列交付計劃。
迭代計劃完成率
-- 迭代計劃完成率代表著迭代前期的準備工作是否充足擅腰，代表著團隊對承諾的兌現(xiàn)蟋恬。
曾經(jīng)有產(chǎn)品研發(fā)團隊，因為這一項做的很好惕鼓，并且在迭代過程中嚴格控制需求變化筋现，而對業(yè)務(wù)產(chǎn)生了巨大的正面影響唐础，帶來了產(chǎn)品數(shù)據(jù)的巨大增長箱歧。因為迭代計劃完成率倒逼著產(chǎn)品人員在迭代前期完善好產(chǎn)品需求，控制好自己迭代過程中修改和插入需求的欲望一膨，促使產(chǎn)品經(jīng)理進一步的去思考產(chǎn)品功能呀邢。并且也代表著研發(fā)團隊對承諾的兌現(xiàn)，這是整個團隊執(zhí)行力的表現(xiàn)豹绪。（迭代周期通常為1-2周价淌，時間已經(jīng)很短了申眼，要盡可能做好前期準備工作，有時候盲目追求快蝉衣，會帶來非常多的副作用括尸。）
迭代目標達成率
--?每一個敏捷迭代，都會有迭代目標病毡，就像每一場球濒翻，都有進球目標。團隊做了很多事情啦膜，但是最終因為個別故事有送、問題或資源，導致迭代目標未完成僧家，這會導致窮忙的狀態(tài)雀摘，目標卻未達成，導致團隊士氣低落八拱。
SCRUM GUIDE中提到阵赠，迭代（SPRINT）過程中不能做出有害于迭代目標的變化，如果迭代目標過時肌稻，可以取消迭代豌注。迭代過程中的各種活動，都是圍繞迭代目標進行灯萍，確保迭代結(jié)束時目標達成轧铁。
業(yè)務(wù)目標達成率
--?產(chǎn)品上線了某些功能模塊，上線后的效果和最初的設(shè)計是否一致旦棉，有多少偏差齿风？有哪些值得我們思考的地方？以及后續(xù)如何改進和設(shè)計绑洛？
做到這一點很重要救斑，需要配合數(shù)據(jù)埋點的效果統(tǒng)計分析，并且將分析結(jié)果真屯，定期在團隊內(nèi)部溝通和討論脸候。
例如：
1）業(yè)務(wù)目標：XX功能上線，用戶量在一周內(nèi)新增10萬绑蔫。（功能上線一周后运沦，新增了幾千人。遠未達到目標配深，然后就沒有然后了携添，無人反思和追蹤產(chǎn)品功能的設(shè)計初衷，而繼續(xù)開始開發(fā)新的功能篓叶。）
2）業(yè)務(wù)目標：XX功能上線烈掠，交付業(yè)務(wù)團隊使用羞秤。（功能上線了，業(yè)務(wù)團隊卻因為部分功能或種種原因左敌，遲遲未使用起來瘾蛋，系統(tǒng)功能的業(yè)務(wù)價值并未得到體現(xiàn)。）
這些情況矫限，本質(zhì)上造成了大量的浪費瘦黑，業(yè)務(wù)目標并未實際達成。
線上產(chǎn)品缺陷數(shù)
-- 衡量產(chǎn)品上線后奇唤，有無質(zhì)量問題幸斥。將開發(fā)和測試融為一體，共同為產(chǎn)品質(zhì)量負責咬扇。團隊共同為質(zhì)量負責的同時甲葬，也可以進一步分析缺陷類型和情況，進行系統(tǒng)思考和根因分析懈贺，找到改善質(zhì)量的根本問題经窖，并解決掉。
產(chǎn)品體驗用戶反饋
--?產(chǎn)品功能上線后梭灿，需要建立產(chǎn)品功能用戶體驗的反饋和收集渠道画侣。真正聽聽用戶的聲音，用來對我們規(guī)劃的產(chǎn)品功能模塊上線后的實際效果獲得反饋堡妒。
例如：
1）小米的產(chǎn)品功能上線后配乱，會在米粉社區(qū)獲得產(chǎn)品功能的反饋，并且根據(jù)反饋調(diào)整產(chǎn)品功能皮迟。
2）蔚來汽車搬泥，也建立了類似的用戶體驗反饋渠道，來獲得用戶的反饋伏尼，并且持續(xù)改進產(chǎn)品體驗忿檩。
一個迭代一個迭代，團隊共同做出了努力爆阶，那么我們努力實現(xiàn)的成果燥透，是否最終產(chǎn)生了實際的業(yè)務(wù)價值？
這應(yīng)該是所有團隊需要重點關(guān)注的事情辨图。
需要建立需求復(fù)盤機制班套，在開放包容的環(huán)境下，大家仔細討論需求上線后實際效果和前期規(guī)劃時的偏差徒役，討論分析研究后孽尽，持續(xù)改進窖壕，并且對改進效果跟蹤分析忧勿。
可惜很多團隊杉女，實際上都處于一直趕進度的狀態(tài)下，團隊持續(xù)付出了很多努力鸳吸，最終卻帶不來業(yè)績的增長熏挎，造成團隊士氣低下。作了一個功能晌砾，又做一個功能坎拐，產(chǎn)品也變成了功能的堆砌。
好的產(chǎn)品絕不是功能的堆砌养匈，微信的成功哼勇，一直秉承了少即是多的原則。
喬布斯一直提倡“極簡主義”呕乎，他相信“少即是多”的哲學思想积担，極簡主義滲透到他蘋果產(chǎn)品的設(shè)計以及他個人的生活，他一生都在踐行這極簡主義猬仁。
好的團隊絕不會讓自己陷入長期持續(xù)忙碌的狀態(tài)帝璧，SCRUM的迭代名叫SPRINT（沖刺），為什么要這起這個名字湿刽？
我思考下來的烁，全力以赴的沖刺后，會有短暫的休息诈闺、調(diào)整渴庆、思考改進。
這就像是比賽雅镊，一場比賽全力以赴達成目標把曼，然后休息調(diào)整、思考改進漓穿，最終向總冠軍的獎杯邁進嗤军。
我國古語云：一張一弛，文武之道晃危。
以上是我對敏捷團隊度量指標的思考叙赚，雖零散不成體系，但也希望可以關(guān)注真正應(yīng)該解決的問題僚饭，最終可以給團隊帶來些許幫助震叮。
