前言

• 從2015年看板和敏捷SCRUM的引入，到2019年7月全面規(guī)模化精益研發(fā)轉(zhuǎn)型，招行經(jīng)歷了四年多的時(shí)間。
• ThoughtWorks全球團(tuán)隊(duì)怎么做敏捷，我們商定了一個(gè)“60%Scrum+40% XP”
• ThoughtWorks敏捷開發(fā)的核心原則：價(jià)值驅(qū)動(dòng)與技術(shù)卓越。

image-20210219145336644

• 開發(fā)人員貼在顯示器前彩色的任務(wù)拆分小紙條

image-20210219145358123

• 常用的工具是燃起圖（Burn-Up）和累積流量圖（CFD來源于Kanban）。
• Scrum的燃盡圖并不推薦，原因是很容易營造一種遵循計(jì)劃的假象。對于客戶／業(yè)務(wù)和項(xiàng)目管理者，從燃起圖能夠看到實(shí)時(shí)需求范圍的變化，按期交付風(fēng)險(xiǎn)也能夠?qū)崟r(shí)推測。
• 累計(jì)流量圖在成熟團(tuán)隊(duì)廣泛應(yīng)用，它能夠直觀告訴開發(fā)團(tuán)隊(duì)瓶頸在哪里，驅(qū)動(dòng)改進(jìn)。

image-20210219145922348

• ThoughtWorks由于歷史原因，用各種平臺(tái)都有，目前最多的是Jira、Mingle和Rally。但實(shí)際上這些平臺(tái)主要還是為了方便離岸敏捷交付團(tuán)隊(duì)，本地的交付團(tuán)隊(duì)很多是物理墻+Excel（或Trello）。
• ThoughtWorks持續(xù)集成紀(jì)律有兩個(gè)核心

1. 第一是必須每次提交觸發(fā)構(gòu)建；
2. 第二是每次提交必須基于上次的成功構(gòu)建

這兩條紀(jì)律是底線。

image-20210219145955374

• 如果有人說哪個(gè)團(tuán)隊(duì)CI紅著沒有修復(fù)，基本就等于說這個(gè)團(tuán)隊(duì)沒有干活兒，因?yàn)槔碚撋蠈χ〉臉?gòu)建提交代碼是無效的
• 主干開發(fā)的代碼管理成本是最低的，但同時(shí)也引入了較高的代碼實(shí)踐能力和協(xié)同紀(jì)律的要求
• ThoughtWorks開發(fā)團(tuán)隊(duì)有共識(shí)的是測試前置，落地過程中有兩個(gè)經(jīng)典方法，即開發(fā)的TDD和提前驗(yàn)收（提前驗(yàn)收或叫Shoulder Check）。
• 但先寫單元測試是ThoughtWorks程序員基本素養(yǎng)。代碼走查形式多樣，但成熟團(tuán)隊(duì)一般都從單元測試開始，如果你跟骨灰級程序員新老頭走查，他的第一句會(huì)是“給我看看你的測試。”
• 大家對代碼走查和結(jié)對編程這些開發(fā)過程中的質(zhì)量實(shí)踐更看重，但這些實(shí)踐的頻繁運(yùn)用在很多團(tuán)隊(duì)都受到了成本的約束，并非普遍。
• 一個(gè)團(tuán)隊(duì)的代碼集體走查現(xiàn)場

image-20210219150200493

• 開發(fā)人員的結(jié)對開發(fā)，往往會(huì)達(dá)到1+1>2的效率增長

image-20210219150214232

基于效能和周期時(shí)間的持續(xù)改進(jìn)

• 持續(xù)改進(jìn)是每個(gè)團(tuán)隊(duì)必須做的，Retro（回顧會(huì)議，全稱Retrospective）是基本形式，回顧的內(nèi)容很多，從交付質(zhì)量、實(shí)踐到團(tuán)隊(duì)氛圍。但實(shí)質(zhì)上最基本的改進(jìn)還是圍繞Velocity（即迭代交付的Story點(diǎn)數(shù)）和Cycle Time（交付時(shí)間）。
• Kanban告訴我們流速快的團(tuán)隊(duì)效率高、響應(yīng)力快。如果不注意Cycle Time而去“改進(jìn)”（Velocity），很可能造成更多的WIP（Kanban引入的“在制品”概念）堆積在迭代內(nèi)，最后大家趕工埋下質(zhì)量隱患，得不償失。在ThoughtWorks兩個(gè)百人以上規(guī)模的大型團(tuán)隊(duì)合用中，都強(qiáng)調(diào)團(tuán)隊(duì)集體學(xué)習(xí)Kanban實(shí)踐。
• 一個(gè)團(tuán)隊(duì)三個(gè)半月的累計(jì)流量圖，體現(xiàn)了某個(gè)階段的WIP和交付周期時(shí)間并分析潛在的問題

image-20210219150315347

基于客戶深度參與的統(tǒng)一團(tuán)隊(duì)

• “站會(huì)”：都能夠體會(huì)到這種模式下快速建立的信任關(guān)系。

1. 迭代站會(huì)不超過15分鐘
2. 需求澄清每次不超過一個(gè)小時(shí)
3. 展示會(huì)一個(gè)小時(shí)以內(nèi)
4. 回顧會(huì)不超過兩小時(shí)

ThoughtWorks敏捷開發(fā)管理體系

1. 需求管理：包含從需求澄清到需求最終實(shí)現(xiàn)的整個(gè)生命周期。
2. 技術(shù)管理：包含開發(fā)、測試技術(shù)的選擇和運(yùn)用。
3. 質(zhì)量管理：包含開發(fā)過程中的質(zhì)量管理及軟件交付前的質(zhì)量保障。
4. 迭代管理：包含開發(fā)團(tuán)隊(duì)迭代運(yùn)作規(guī)則及紀(jì)律。

• Story的質(zhì)量其實(shí)是一個(gè)核心問題，ThoughtWorks從來不提倡一句話Story描述，即僅僅表面上遵循了As…I want…So that的經(jīng)典模式，驗(yàn)收條件對于一個(gè)Story來說至關(guān)重要

image-20210219150455375

image-20210219150521220

書

1. 《代碼管理核心技術(shù)及實(shí)踐》
2. 《敏捷軟件開發(fā)：用戶故事實(shí)戰(zhàn)》
3. ThoughtWorks洞見網(wǎng)站 ：https://insights.thoughtworks.cn
4. Thoughtworks洞見公眾號

第1章　敏捷宣言到底有幾句

敏捷軟件開發(fā)宣言

1. 我們一直在實(shí)踐中探尋更好的軟件開發(fā)方法，身體力行的同時(shí)也幫助他人。由此我們建立了如下價(jià)值觀：
2. 個(gè)體和互動(dòng)　高于　流程和工具
3. 工作的軟件　高于　詳盡的文檔
4. 客戶合作　高于　合同談判
5. 響應(yīng)變化　高于　遵循計(jì)劃
6. 雖然右項(xiàng)也具有價(jià)值，但我們認(rèn)為左項(xiàng)具有更大的價(jià)值。

第2章　開發(fā)人員的客戶思維

• 在團(tuán)隊(duì)中，只有所有人都對業(yè)務(wù)有一致的理解，所有的努力都朝著一致的方向，才有可能獲得成功。
• 有客戶思維的開發(fā)人員，能夠把工作當(dāng)作為客戶提供服務(wù)：自己是服務(wù)提供方，而同事和老板就是客戶。他們積極地從客戶角度思考需求的真正來源，在開發(fā)過程中與客戶保持溝通，適時(shí)給出合理的建議。
• 不管是工程師提前想到了這個(gè)結(jié)論，還是與產(chǎn)品經(jīng)理及時(shí)溝通了自己的技術(shù)方案計(jì)劃，都可以提早防止浪費(fèi)。

第3章　基于統(tǒng)一迭代節(jié)奏的全功能團(tuán)隊(duì)

自組織全功能團(tuán)隊(duì)

• 為了盡量縮短每一輛車從開始裝飾到完成交車的整個(gè)過程，也就是縮短單個(gè)車的Lead Time，我觀察到整個(gè)團(tuán)隊(duì)是在以一種幾乎完美的方式協(xié)同工作。

1. 首先，所有的工作被高度并行化。例如我的車最多的時(shí)候有四個(gè)人在同時(shí)施工，一個(gè)人在縫真皮方向盤套，一個(gè)負(fù)責(zé)貼車左側(cè)窗戶的膜，一個(gè)負(fù)責(zé)貼車右側(cè)的膜，一個(gè)負(fù)責(zé)貼前后擋風(fēng)的膜。
2. 其次，大家并沒有清晰的角色劃分，縫方向盤套的人在完成手頭的工作后，立刻自覺加入到貼膜的工作之中；而兩側(cè)的膜貼完后，兩名工人立刻開始幫車打蠟和做內(nèi)飾清潔；整個(gè)過程自然而連貫，完全自組織，
3. 所有人都掌握了縫方向盤套、貼膜、打蠟和內(nèi)飾清洗的工作技能，并沒有嚴(yán)格的角色分工，很難說清楚誰是貼膜師，誰是打蠟師，他們每個(gè)人都像一個(gè)專業(yè)的全棧工程師。

image-20210219151351527

領(lǐng)導(dǎo)與管理

• 一頭扎進(jìn)充滿煙霧車廂的人就是這家店的老板。是的，他還是我上面提到的四名工人之一，分別完成縫方向盤套、新車除味和右側(cè)的貼膜工作。
• 在我的眼里，他就是一個(gè)稱職的帶頭人。凡事沖在前面，以身作則，勇于承擔(dān)一些困難甚至危險(xiǎn)的工作。

image-20210219151418703

團(tuán)隊(duì)的精進(jìn)之道

• 把項(xiàng)目成功交付看作能力建設(shè)的副產(chǎn)品”口號的一種樸素實(shí)現(xiàn)。
• 在ThoughtWorks，我們認(rèn)為，軟件開發(fā)中的一切問題，根本上都是人的能力問題。如何發(fā)展每個(gè)成員才是問題的關(guān)鍵。如果成員沒有進(jìn)步，始終是治標(biāo)不治本的。
• 團(tuán)隊(duì)的精進(jìn)之道就是把交付過程中的一切活動(dòng)都看作能力建設(shè)，把整個(gè)團(tuán)隊(duì)構(gòu)造成促進(jìn)每個(gè)成員成長的生態(tài)系統(tǒng)。
• 一個(gè)人要?jiǎng)澣蝿?wù)、估時(shí)間、在做的時(shí)候計(jì)時(shí)、根據(jù)實(shí)際結(jié)果進(jìn)行反思。我們可以把這個(gè)方法做成非常邪惡的、仿佛流水線上工人的強(qiáng)制要求。我不關(guān)心你為什么超時(shí)，就通過這種方法來控制程序員，要求每個(gè)人都嚴(yán)格按照一個(gè)死板而僵化的步驟做一些簡單重復(fù)的機(jī)械動(dòng)作。也可以用這個(gè)方法來鍛煉一個(gè)人的自我認(rèn)知和發(fā)現(xiàn)知識(shí)漏洞等能力，促使他以最快的速度成長，等他成長起來馬上給他更重要的任務(wù)，比如評估技術(shù)、評估項(xiàng)目、帶新人、做架構(gòu)等等。
• 這其中的不同早在很多年前，就被一些大牛們觀察到，作為敏捷宣言里的一句話表達(dá)了出來：“個(gè)體與交互　高于　流程和工具。”

第4章　基于用戶故事的需求及范圍實(shí)時(shí)管理

估算的目的

• 所以，任何時(shí)候想做估算時(shí)，都應(yīng)當(dāng)非常清楚哪一項(xiàng)決策需要依賴這個(gè)估算。如果你找不到這樣一項(xiàng)決策，或者那個(gè)決策并不是那么重要，這就是一個(gè)信號：此時(shí)做估算是在浪費(fèi)時(shí)間。當(dāng)你找到這樣一個(gè)決策時(shí)，那要知道問題的上下文是什么，為什么估算會(huì)很重要。同樣還要搞清楚期望的精度和準(zhǔn)確性。
• 估算是有適用期限的。我曾經(jīng)記得有一位經(jīng)歷頗豐的項(xiàng)目經(jīng)理說過，計(jì)劃和估算就像是生菜，剛過幾天還很新鮮，過了一周有點(diǎn)枯萎了，幾個(gè)月后就完全看不出來是什么了。

需求風(fēng)險(xiǎn)的壞味道和對策

• 作為一個(gè)大型項(xiàng)目的負(fù)責(zé)人，一旦進(jìn)入交付落地階段，就應(yīng)該進(jìn)入“風(fēng)險(xiǎn)模式”。
• 而“控制需求”成為了“控制風(fēng)險(xiǎn)”中最重要的一環(huán)，換言之，對于一個(gè)失敗的項(xiàng)目而言，需求未得到有效的控制，往往是最重要的原因。

識(shí)別壞味道

• “這個(gè)需求我們實(shí)現(xiàn)過，只需要一周時(shí)間就可以完成。”

一個(gè)優(yōu)秀的項(xiàng)目管理者首先需要做的是讓客戶完全了解你的工作量估計(jì)系統(tǒng)是如何工作的，并不斷強(qiáng)調(diào)你的工作量估計(jì)是合理、公平和有效的。

• “關(guān)于這個(gè)需求，你做個(gè)方案給我選一選。” “這兩個(gè)方案我都不喜歡，要不你們再想想？”

這代表你的客戶不理解在軟件開發(fā)中，“需求分析”也是工作量的一部分

• “這是領(lǐng)導(dǎo)要的，我也沒辦法。”

這代表你的客戶正在拋開自己的決策責(zé)任，嘗試用最不負(fù)責(zé)任的方式逼迫你答應(yīng)需求，一旦成功，這種行為就變成一個(gè)肆無忌憚的借口。

• “沒有這個(gè)功能，我們不能上線。”

必須據(jù)理力爭，請堅(jiān)信，沒有阻止上線的功能，只有阻止上線的、不理智的、缺乏安全的客戶。

盡可能靠近決策者

• 軟件工程同樣是一個(gè)“社會(huì)工程”，軟件項(xiàng)目的失敗往往是因?yàn)槠渖鐣?huì)性的復(fù)雜，導(dǎo)致身處其中的人無法處理所負(fù)責(zé)的合作、組織、政治和職責(zé)關(guān)系。

• 在上一個(gè)客戶中我們做了以下幾件事情。

• 為客戶包裝向他的上級匯報(bào)的PPT

• 總結(jié)他的上級的想法，例如用可視化的方式概括他的上級在說什么

• 將工作過程拍成視頻，供他在組織內(nèi)傳播

• 每周一次Newsletter，制作一些易于傳播的圖片和小視頻等。

• 使得你和你的客戶不再是甲乙方的關(guān)系，而是合作者，明確這個(gè)地位，才是接近決策者的重要意義。

做系統(tǒng)決策人

• 一個(gè)優(yōu)秀的系統(tǒng)決策人需要對以下決定產(chǎn)生影響。

1. 是否應(yīng)該引入新的概念
2. 是否應(yīng)該將某一概念變復(fù)雜
3. 是否應(yīng)該建立新的關(guān)系
4. 是否應(yīng)該將某一關(guān)系變復(fù)雜

image-20210219152008858

不要給選擇

• 給選擇的目的永遠(yuǎn)是讓客戶選擇我們期待他選擇的那一項(xiàng)，如果不給選擇也是其中一個(gè)選項(xiàng)，那么盡量不給客戶選擇。
• 我所使用的策略有如下幾種。

1. 采用完美的系統(tǒng)思維邏輯幫助客戶認(rèn)定我們選定的就是最優(yōu)選擇
2. 對我們的方案給出完整的思考和選擇過程、而不是最終方案而已
3. 給出大量的假設(shè)讓客戶認(rèn)為反正都不知道最后結(jié)果是怎樣，選什么其實(shí)都沒那么重要
4. 最后才是給出多個(gè)方案，對優(yōu)缺點(diǎn)進(jìn)行分析

管理結(jié)果而非解決方案

image-20210219152104077

• 切記，不是因?yàn)闁|西難就不做，也不是因?yàn)闁|西簡單就做，而是思考一個(gè)需求對于整體結(jié)果的影響。
• 需求是結(jié)果的副產(chǎn)品，應(yīng)該由產(chǎn)品經(jīng)理、設(shè)計(jì)師、架構(gòu)師來保證，你只需要和客戶討論最終產(chǎn)品在多大程度上可以滿足預(yù)期的結(jié)果。
• 如果沒有影響，無論有多簡單，都不應(yīng)該做，如果至關(guān)重要，無論多難，都應(yīng)該完成。

建立游戲規(guī)則

1. 沒有東西是免費(fèi)的：所有東西都是有價(jià)格的，花時(shí)間的，這里包括需求的討論、編碼、改動(dòng)、測試、調(diào)試、溝通等等。
2. 講不清楚的需求很可能是沒價(jià)值的
3. 這是系統(tǒng)思考：任何一個(gè)新概念的產(chǎn)生或者一個(gè)新關(guān)系的出現(xiàn)，都意味著系統(tǒng)其他部分的成本、變動(dòng)、甚至破壞，謹(jǐn)慎一切新概念、新關(guān)系的產(chǎn)生。
4. 社交游戲：復(fù)雜問題最終都是復(fù)雜的社交游戲，能通過政治或者社交解決的問題，盡可能不用技術(shù)解決，
5. 每個(gè)階段都有該階段專屬的規(guī)則：特別在需求的前期，討論越多需求，流入后期的需求范圍就越大。在一開始就應(yīng)該建立“需求規(guī)則”的概念，什么該談、什么不該談，而不是簡單跳過
6. 交付大于一切：永遠(yuǎn)不進(jìn)行項(xiàng)目延期，目標(biāo)是在交付期中保證交付既定的結(jié)果，而非之前約定的需求列表，可以容忍瑕疵、但不容忍延期。
7. 尊重估算：不要嘗試花時(shí)間質(zhì)疑估算，你所有的懷疑會(huì)變成工程師巧妙的“套路”，他們會(huì)在另外的地方找補(bǔ)回來，反正你不懂，若相信，請深信。

需求的冰川

1. 用戶需求：從用戶自身角度出發(fā)產(chǎn)生的“自以為的”需求
2. 產(chǎn)品需求：由綜合提煉用戶的真實(shí)需求而產(chǎn)生的符合組織和產(chǎn)品定位的解決方案。

• 讓產(chǎn)品從能用到好用，恐怕第一大忌就是“想當(dāng)然”。

用戶研究與驗(yàn)證

• 他們不是不愿意做好用戶研究與驗(yàn)證，而是不一定具備這種能力；即使做好了，也很難知道如何準(zhǔn)確地把合適的信息傳遞給業(yè)務(wù)分析師和交付團(tuán)隊(duì)。 我們不止一次地強(qiáng)調(diào)復(fù)合型人才對產(chǎn)品構(gòu)建和組織轉(zhuǎn)型的重要性，在需求分析領(lǐng)域，用戶研究和驗(yàn)證或許是呈給業(yè)務(wù)分析師的第一份考卷。
• 我們不止一次地強(qiáng)調(diào)復(fù)合型人才對產(chǎn)品構(gòu)建和組織轉(zhuǎn)型的重要性，在需求分析領(lǐng)域，用戶研究和驗(yàn)證或許是呈給業(yè)務(wù)分析師的第一份考卷。

『了解用戶』無法一勞永逸

• 在產(chǎn)品進(jìn)入穩(wěn)定的交付階段后，業(yè)務(wù)分析師應(yīng)該繼續(xù)積極了解用戶，不斷驗(yàn)證并挖掘需求；用戶和環(huán)境都在改變，該重新組織產(chǎn)品規(guī)劃設(shè)計(jì)工作坊的時(shí)候，不能搪塞了事。

保持好奇，保持初心

• Stay hungry，stay foolish
• 面對客戶的需求，多問一個(gè)為什么；面對用戶的答案，多想一個(gè)為什么；能最大程度地避免“想當(dāng)然”，或許就能最大程度地做好“用戶研究和驗(yàn)證”。

淺談軟件項(xiàng)目規(guī)模估計(jì)，到底在估什么

• 尼爾斯·玻爾說過：“預(yù)測是一件非常困難的事情，尤其是預(yù)測未來。”

非功能需求

• 非功能需求更需要引起我們的重視，這往往是項(xiàng)目最容易忽略而掉到坑里的地方。
• 最基本的要考慮以下兩點(diǎn)。

1. 瀏覽器的兼容性問題：兼容哪些瀏覽器和兼容版本？
2. 移動(dòng)端的兼容性問題：兼容哪些手機(jī)設(shè)備、操作系統(tǒng)和版本號？

• 除此之外還包括性能、可維護(hù)性、可測試性、可用性、可移植性及可擴(kuò)展性等

開發(fā)部署環(huán)境

• 包括但不限于CI環(huán)境、開發(fā)環(huán)境、QA環(huán)境、SIT環(huán)境、UAT環(huán)境、Pre-Prod和Prod環(huán)境。

與三方的集成

• 集成往往不是個(gè)小問題。目前的軟件項(xiàng)目，往往都是基于現(xiàn)有的系統(tǒng)進(jìn)行開發(fā)，所以集成的工作必不可少。契約的制定、數(shù)據(jù)的遷移、其他供應(yīng)商三方系統(tǒng)開發(fā)工作的推進(jìn)以及接口的集成聯(lián)調(diào)等，往往都是項(xiàng)目全周期的工作重點(diǎn)。

測試

• 敏捷項(xiàng)目中的測試，與傳統(tǒng)先開發(fā)再測試這種方式極為不同的一點(diǎn)是：沒有固定的測試人員，而是全員來保證軟件的質(zhì)量。

1. 自動(dòng)化測試，包括單元測試／集成測試／功能測試
2. 迭代內(nèi)探索性測試
3. 業(yè)務(wù)回歸測試
4. 性能測試
5. 安全測試
6. 代碼質(zhì)量測試

驗(yàn)收交接流程

• 軟件的整個(gè)驗(yàn)收流程、代碼交接、文檔撰寫工作，

軟件項(xiàng)目規(guī)模估計(jì)，怎么估？

估計(jì)者的估算的點(diǎn)數(shù)是否能代表團(tuán)隊(duì)估算的點(diǎn)數(shù)？

• 在估計(jì)的過程中，至少要引入新手，能夠從不同經(jīng)驗(yàn)的角度來看待同樣的問題，使估計(jì)不會(huì)過分“樂觀”。

是否有故事卡片之外的工作時(shí)間沒有考慮到？

1. 回復(fù)電子郵件（溝通成本）
2. 面試（內(nèi)部耗損）
3. 參加會(huì)議（包括內(nèi)部會(huì)議，比如站會(huì)、retro、code diff、技術(shù)研討會(huì)議和客戶溝通會(huì)議等）
4. 為當(dāng)前發(fā)布提供支持（上線支持）
5. 培訓(xùn)？（內(nèi)部的）
6. 任務(wù)之間切換／被人打斷（程序員出棧入棧的消耗……）
7. 修復(fù)bug（一定會(huì)有bug，一定會(huì)花時(shí)間修……）
8. 寫各種文檔（對于比較看重文檔的客戶，這一部分會(huì)占用不少的時(shí)間）

故事卡的需求是否清晰呢？

• 往往只考慮了最簡單的快樂通道（Happy Path），然而大部分項(xiàng)目中（尤其是ToB項(xiàng)目），異常才是相對復(fù)雜的，這些異常情況往往需要花費(fèi)更多的時(shí)間完成。

問題可能的答案

1. 首先，要進(jìn)行集體估計(jì)。集體估計(jì)可以緩解因?yàn)閭€(gè)人能力不同所引發(fā)的單點(diǎn)偏差，不同開發(fā)成員對某個(gè)需求從不同角度進(jìn)行的闡述，也容易讓大家對需求有更全面的理解，也易于發(fā)現(xiàn)潛藏在需求中的風(fēng)險(xiǎn)。
2. 其次，是方法。《敏捷估算與規(guī)劃》介紹了兩種基本的方法：理想人天法和故事點(diǎn)法。

理想人天法

• 就是“在需求非常明確的情況下，進(jìn)行編碼和測試工作所花費(fèi)的時(shí)間”。
• 在實(shí)際應(yīng)用中，在估完理想人天之后如何進(jìn)行實(shí)際人天的換算仍然是個(gè)大問題，所以……最好不用。

故事點(diǎn)法

• 點(diǎn)數(shù)代表的不是所需的人天，而更多的是難度系數(shù)。
• 給項(xiàng)目加些緩沖（buffer）。緩沖分兩種，一種是功能緩沖，一種是進(jìn)度緩沖。

功能緩沖

• 全部故事列表進(jìn)行估計(jì)，假設(shè)得到總點(diǎn)數(shù)是100點(diǎn)，挑出其中的MVP（要少于總量的70%），作為必須要做（Must Have）的部分。剩下的30%作為做了更好、不做也不影響主要功能（Nice To Have）的部分，通過這種方式來緩沖項(xiàng)目里程碑的風(fēng)險(xiǎn)。

進(jìn)度緩沖

• 用來緩沖估計(jì)之外的異常情況引發(fā)的項(xiàng)目時(shí)間的拉長。
• 不過根據(jù)Leach（2000）準(zhǔn)則提出的建議，至少要保持整個(gè)項(xiàng)目的20%以上，否則也許不能為整個(gè)項(xiàng)目提供足夠的保護(hù)。

不是小結(jié)的小結(jié)

1. “輸出高于結(jié)果”（output over outcome）。客戶更關(guān)注功能列表的完成，而不是產(chǎn)生的業(yè)務(wù)價(jià)值。
2. 開發(fā)團(tuán)隊(duì)傾向于裁剪用戶故事的功能，3個(gè)點(diǎn)的故事卡，盡量控制在規(guī)定時(shí)間內(nèi)完成，即使可以花更多時(shí)間把事情做得更好
3. 控制需求變更。可以進(jìn)行需求變更，但這個(gè)過程更像是一個(gè)異常的情況，而不是喜聞樂見的
4. 當(dāng)我們發(fā)現(xiàn)更好的業(yè)務(wù)點(diǎn)和想法的時(shí)候，會(huì)傾向于隱瞞，以免額外的業(yè)務(wù)功能會(huì)增加工作量。需求變更往往會(huì)涉及客戶談判，尤其是在客戶觀念是傳統(tǒng)供應(yīng)商管理策略時(shí)，即“我來控制需求的全景，能多做點(diǎn)就多做點(diǎn)”
5. 在客戶合作和談判的天平上，客戶關(guān)系會(huì)向談判的方向傾斜。

• 估計(jì)和計(jì)劃會(huì)使團(tuán)隊(duì)和客戶更多聚焦在工作量而不是工作的價(jià)值上。如果能夠引導(dǎo)客戶從輸出導(dǎo)向思維轉(zhuǎn)變?yōu)榻Y(jié)果導(dǎo)向

書

1. 《敏捷估算與規(guī)劃》

第5章　基于持續(xù)集成和測試前置的質(zhì)量內(nèi)建

關(guān)于Gitflow

• Gitflow是基于Git的強(qiáng)大分支能力所構(gòu)建的一套軟件開發(fā)工作流，最早由德里森（Vincent Driessen）在2010年提出。最有名的大概是下面這張圖。
• Github在企業(yè)軟件開發(fā)中甚至不是一個(gè)最佳實(shí)踐。
• Gitflow太復(fù)雜。還對整個(gè)團(tuán)隊(duì)的紀(jì)律性提出了很高的要求。

image-20210219153531245

合并就是合并

• 在軟件開發(fā)的世界里，如果一件事很痛苦，那就頻繁地去做它。比如集成很痛苦，那我們就每夜build或持續(xù)集成（continuous integration），比如部署很痛苦，那我們就頻繁發(fā)布或持續(xù)部署（continuous deployment）。合并也是一樣。

如果不用Gitflow呢？

• Trunk-Based Development，那你應(yīng)該先了解一下，趕緊用起來。
• 所有的開發(fā)工作都在同一個(gè)master分支上進(jìn)行，同時(shí)利用持續(xù)集成確保master上的代碼隨時(shí)都是production ready的。從master上拉出release分支進(jìn)行release的追蹤。

image-20210219153631172

• 可是feature分支可以確保沒完成的feature不會(huì)進(jìn)入到生產(chǎn)部署呀！——Feature Toggle技術(shù)

• 如果系統(tǒng)有一項(xiàng)很大的修改，比如替換掉目前的ORM，如何采用這種策略呢？你可以試試分支by Abstraction——分支by Abstraction。

改善單元測試的新方法

我們?yōu)槭裁匆獙憜卧獪y試？

• 寫單元測試的兩個(gè)動(dòng)機(jī)：驅(qū)動(dòng)（如TDD）和驗(yàn)證功能實(shí)現(xiàn)。

基于用例的測試（By Example）

• 單元測試最常見的套路就是Given，When，Then三部曲。

1. Given：初始狀態(tài)或前置條件
2. When：行為發(fā)生
3. Then：斷言結(jié)果

• 壞處。

1. 第一是測試的意圖。用例太過具體，我們就很容易忽略自己的測試意圖。測試即文檔，既然是文檔，就應(yīng)該明確描述待測方法的行為，而不是陳述一個(gè)例子。
2. 第二是測試完備性。因?yàn)槭∈率⌒牟⑶一貓?bào)率高，我們更樂于寫happy path的代碼。

生成式測試

• 測試方式“生成式測試”（Generative Testing，也稱Property-Based Testing）。這種測試方式會(huì)基于輸入假設(shè)輸出，生成許多可能的數(shù)據(jù)來驗(yàn)證假設(shè)的正確性。
• 假設(shè)我們不寫具體的測試用例，而是直接描述意圖，讓程序自動(dòng)生成入?yún)⒉Ⅱ?yàn)證結(jié)果。

超越“審，查，評”的代碼回顧

• 代碼回顧（Code Review）應(yīng)該是軟件開發(fā)團(tuán)隊(duì)“共同學(xué)習(xí)、識(shí)別模式和每日持續(xù)”的過程，而不是帶有“審，查，評”等令人感到緊張氣氛的過程。
• 代碼回顧的目的，是團(tuán)隊(duì)成員聚在一起共同學(xué)習(xí)，而不是相互“挑錯(cuò)”。在相互挑錯(cuò)的場合里，人的內(nèi)心會(huì)本能地封閉起來，來抗拒那些針對自己的批評意見。

image-20210219153855821

• 代碼回顧的學(xué)習(xí)重點(diǎn)，是團(tuán)隊(duì)成員共同識(shí)別模式。這里的模式指的是程序員編寫代碼的習(xí)慣，包括“好模式”和“反模式”。像富有表達(dá)力的類名、單一職責(zé)的方法、良好的格式縮進(jìn)等等，都是“好模式”。而像那些令人迷惑的縮寫、幾百行的一個(gè)類文件、負(fù)責(zé)的if-else嵌套等，都是“反模式”。
• 代碼回顧的形式，應(yīng)該是每日持續(xù)進(jìn)行的。因?yàn)橹挥羞@樣，才能持續(xù)改進(jìn)團(tuán)隊(duì)的代碼編寫水平。也需要將每日代碼回顧的時(shí)間控制在半小時(shí)以內(nèi)。因?yàn)榇a回顧的重點(diǎn)是識(shí)別模式，而模式就是習(xí)慣，習(xí)慣在很少的代碼中就能體現(xiàn)出來。每日的代碼回顧僅需要在半小時(shí)內(nèi)大家一起看200～300行隨機(jī)抽取的當(dāng)天寫的代碼就夠了。
• 下面是我在客戶現(xiàn)場實(shí)踐上述代碼回顧的具體做法。

1. 團(tuán)隊(duì)7～8位程序員，下班前半小時(shí)聚在會(huì)議室里，在一位主持人的引導(dǎo)下做代碼回顧。
2. 主持人問：“咱們今天回顧哪段新寫的代碼？”一位志愿者在投影儀上調(diào)出今天編寫的一段代碼的新舊對比圖。
3. 主持人說：“我們知道，如果代碼編寫得好，那么作者以外的其他的人就能在沒有作者幫助的情況下讀懂。我希望一位不是這段代碼作者的志愿者，來為大家解釋一下這段代碼是做什么的。”一位非作者的志愿者上來逐行解釋代碼，并回答大家的疑問。
4. 主持人等代碼解釋完后，問大家：“這段代碼大家還有看不懂的地方嗎？”
5. 大家都看懂代碼后，主持人問：“大家說說這段代碼有沒有好的編寫模式咱們可以繼續(xù)發(fā)揚(yáng)？”
6. 提完了好模式，主持人問：“大家說說這段代碼有沒有可以改進(jìn)的反模式？”大家開始提反模式。注意，不要提誰是作者。
7. 主持人在整個(gè)過程中注意計(jì)時(shí)，快到半小時(shí)的時(shí)候，可以這樣結(jié)束代碼回顧：“今天時(shí)間也快到了，代碼回顧的重點(diǎn)在識(shí)別模式，而不是看全部的代碼。希望大家繼續(xù)發(fā)揚(yáng)今天識(shí)別到的好模式。另外在明天做代碼回顧時(shí)，把今天識(shí)別到的反模式改進(jìn)為好模式。”

不做代碼審查又怎樣

• 代碼審查是一個(gè)很好的實(shí)踐，可以幫助團(tuán)隊(duì)里的同學(xué)了解其他同學(xué)在做什么，可以分享項(xiàng)目的上下文，可以分享技術(shù)上的一些小魔法，可以發(fā)現(xiàn)很多潛在的代碼缺陷，可以提高代碼質(zhì)量，還可以有很多很多好處……

溝通的收益和成本

• XP中的結(jié)對編程（Pair programming）和現(xiàn)場客戶（Onsite Customer）等。
• 無論是20世紀(jì)80年之前就出現(xiàn)的PDCA環(huán)還是前兩年大熱的精益創(chuàng)業(yè)，都是在強(qiáng)調(diào)快速反饋和基于反饋的快速迭代，

測試金字塔

• 和測試金字塔一樣更靠近金字塔頂端的（例如迭代計(jì)劃會(huì)）溝通頻率越低，成本越高，但越接近業(yè)務(wù)；越靠近金字塔底端的（例如結(jié)對編程）溝通頻率越高，成本越低，越接近實(shí)現(xiàn)。

交付價(jià)值高于遵循實(shí)踐

• 日本劍道有個(gè)心訣，叫“守破離”：“守”，最初階段須遵從老師教誨，認(rèn)真練習(xí)基礎(chǔ)，達(dá)到熟練的境界；“破”，基礎(chǔ)熟練后，試著突破原有規(guī)范讓自己得到更高層次的進(jìn)化；“離”，在更高層次得到新的認(rèn)識(shí)并總結(jié)，自創(chuàng)新招數(shù)，另辟出新境界。

結(jié)對編程的正確姿勢，你學(xué)會(huì)了嗎？

結(jié)對編程

• 極限編程首次被用于（當(dāng)時(shí)Smalltalk領(lǐng)域的大師級人物）肯特·貝克（Kent Beck）1996年受聘領(lǐng)導(dǎo)克萊斯勒公司一個(gè)綜合工資項(xiàng)目開發(fā)C3（Chrysler Comprehensive Compensation）中首次采用，并在1999年10月出版的《解析極限編程》一書中被正式提出。
• 極限編程中的“極限”（Extreme）是指將我們認(rèn)同的有效軟件開發(fā)原理和實(shí)踐應(yīng)用到極限，
• 軟件從此不再是一個(gè)人單打獨(dú)斗的工作，而是要求越來越多的多角色多任務(wù)的協(xié)作。軟件行業(yè)的工作者必須要有比以往更多的溝通和協(xié)作技巧。而這對于習(xí)慣了一個(gè)人的軟件開發(fā)者而言是一個(gè)巨大的挑戰(zhàn)，必然要有一個(gè)改變和適應(yīng)的過程。這也是為什么結(jié)對編程會(huì)成為最具爭議的實(shí)踐。

結(jié)對編程的好處

培養(yǎng)新人，促進(jìn)溝通，提升團(tuán)隊(duì)整體能力。

• 包括快捷鍵、算法、語法、SQL、設(shè)計(jì)、解決問題的思路、做事方式等，1對1面對面師傅帶徒弟式的學(xué)習(xí)是新技能最快的方式之一。

更好的知識(shí)共享和信息交流，促進(jìn)團(tuán)隊(duì)協(xié)作。

• 結(jié)對中可以互相分享代碼的上下文，交換對代碼的理解，促進(jìn)質(zhì)量改進(jìn)和團(tuán)隊(duì)協(xié)作，同時(shí)也使得代碼集體所有制成為可能，減少團(tuán)隊(duì)對某些成員的依賴，降低團(tuán)隊(duì)風(fēng)險(xiǎn)。

促進(jìn)團(tuán)隊(duì)成員的溝通，提升團(tuán)隊(duì)凝聚力。

如何進(jìn)行結(jié)對？

image-20210219154222285

1. 領(lǐng)航員和駕駛員（Driver-Navigator），鍵霸出沒，請小心

• 駕駛員編寫實(shí)現(xiàn)當(dāng)前任務(wù)的代碼，而領(lǐng)航員需要引領(lǐng)代碼的編寫并負(fù)責(zé)審查代碼。
• 領(lǐng)航員通常還要考慮當(dāng)前的實(shí)現(xiàn)方法是否正確，是否有別的做法，它是否會(huì)影響到其他功能模塊，下一步是什么。
• 合作場景：適應(yīng)于各種組合，尤其一老一新組合。

2. 乒乓模式

• 測試驅(qū)動(dòng)測試。結(jié)對雙方可以一個(gè)人編寫失敗的測試，一個(gè)人寫實(shí)現(xiàn)通過測試；然后交換角色，不斷循環(huán)。對于結(jié)對雙方經(jīng)驗(yàn)相當(dāng)?shù)那闆r下，由于交互和交換的頻率很快，就如打乒乓一般，
• 合作場景：適用于各種組合，尤其是雙方經(jīng)驗(yàn)相當(dāng)?shù)膱鼍啊Ｆ古夷Ｊ接捎谒慕巧止で逦粨Q頻率相對較快，

3. 鼠標(biāo)和鍵盤模式

• 這是駕駛員和領(lǐng)航員的一種具體表現(xiàn)方式，其中一方使用鼠標(biāo)，是領(lǐng)航員；另一方使用鍵盤完成代碼的編寫，是駕駛員。
• 合作場景：適用于一老一新組合。

幾點(diǎn)提示

1. 多溝通：彼此尊重，多溝通。
2. 確定開發(fā)任務(wù)列表。協(xié)商開發(fā)任務(wù)列表，能夠提高對開發(fā)任務(wù)理解的一致性，確保開發(fā)節(jié)奏順利進(jìn)行。
3. 定期交換小伙伴。定期交換小伙伴可以使得知識(shí)得到充分分享，
4. 可持續(xù)的結(jié)對工作。真正的結(jié)對會(huì)比一人工作更專注，緊湊，所以一天8小時(shí)的結(jié)對會(huì)很累，比如一個(gè)小時(shí)或兩個(gè)小時(shí)休息一次，從而保證可持續(xù)的工作。
5. 多給新人機(jī)會(huì)。與新加入的小伙伴結(jié)對，需要耐心，多給予她／她上手的時(shí)間與空間。通常建議開始時(shí)多講解，多展示，給她／他學(xué)習(xí)的機(jī)會(huì)；比如一開始可以由熟悉代碼的小伙伴寫測試，而新加入的寫實(shí)現(xiàn)；隨后可采用鼠標(biāo)鍵盤方式或者乒乓結(jié)對方式。
6. 勇敢加勇敢。對于新加入的小伙伴，如果跟不上怎么辦？要勇敢地叫停，打斷結(jié)對的小伙伴，弄懂這個(gè)問題，這樣做才是達(dá)到了結(jié)對的目的。更推薦及時(shí)解決，當(dāng)然，深度需要把握得當(dāng)。
7. 反饋。反饋往往是最后一環(huán)，也是最有效的一環(huán)，是幫助自己和結(jié)對小伙伴的必要工具之一，溫暖的“小黑屋”是可以經(jīng)常光顧的。
8. 不是所有的場景都適合結(jié)對。對于那些結(jié)果需要維護(hù)，能夠促進(jìn)溝通、知識(shí)傳遞等價(jià)值的開發(fā)行為，都建議結(jié)對。諸如方案調(diào)研和一些非常簡單的問題（微小的缺陷修復(fù)如拼寫錯(cuò)誤）等是可以不用結(jié)對。

第7章　組建人人深度參與的統(tǒng)一團(tuán)隊(duì)

開不好站會(huì)？因?yàn)椴煌A段站會(huì)的目的不一樣

• 布魯斯·塔克曼（Bruce Tuckman）的團(tuán)隊(duì)發(fā)展階段模型

1. 組建期
2. 激蕩期
3. 規(guī)范期
4. 執(zhí)行期
5. 休整期

• 團(tuán)隊(duì)在不同的階段，面對的問題不一樣，站會(huì)作為一個(gè)團(tuán)隊(duì)實(shí)踐，它提供的價(jià)值應(yīng)該也會(huì)不一樣。

組建期和激蕩期：建立信任

• 什么樣的團(tuán)隊(duì)成員能得到其他人的信任呢？
• 搞定問題的能力 積極主動(dòng)的態(tài)度
• 團(tuán)隊(duì)合作的意識(shí)
• 我昨天完成了什么？我擁有專業(yè)能力，能搞定一些工作。
• 今天準(zhǔn)備做什么？我積極思考，主動(dòng)承擔(dān)任務(wù)。
• 我遇到了什么問題？我不是萬能的，但我信任團(tuán)隊(duì)，我會(huì)把搞不定的問題暴露出來。

規(guī)范期和執(zhí)行期：關(guān)注價(jià)值流動(dòng)

• 軟件開發(fā)過程中，對于一個(gè)功能特性，只有真正被用戶使用才能產(chǎn)生價(jià)值。所以我們要盡量縮短從需求分析到開發(fā)、測試、部署的周期，而這其中一個(gè)很大的浪費(fèi)就是“等待”。
• 這時(shí)，我們可以采用看板推崇的“拉動(dòng)”的方式，大家站在看板前，不再講三個(gè)經(jīng)典問題，而是以需求為中心，從看板的右邊往左邊，討論每一個(gè)需求卡片的狀態(tài)，以及還需要做什么才能移動(dòng)到右邊一列。

執(zhí)行期：儀式感

• 團(tuán)隊(duì)每天按部就班地工作，激情很容易流失，團(tuán)隊(duì)容易進(jìn)入得過且過的狀態(tài)。這時(shí)站會(huì)更多的是一個(gè)儀式，產(chǎn)品經(jīng)理要經(jīng)常分享產(chǎn)品在市場上的反饋，比如用戶的表揚(yáng)信，又新增了多少用戶，產(chǎn)品又掙了多少錢等。讓大家看到工作產(chǎn)生的價(jià)值，持續(xù)獲得成就感。
• 敏捷不是遵循“最佳”實(shí)踐，而是要搞清楚實(shí)踐在什么環(huán)境下解決什么問題，然后再合理地對實(shí)踐進(jìn)行裁剪和改進(jìn)，這樣才能保持敏捷力！

展示會(huì)的七宗罪

準(zhǔn)備工作沒做好

• 浪費(fèi)了很多寶貴的時(shí)間，尤其是對于PO等重要人物來說。

正確做法：充分做好準(zhǔn)備工作

從業(yè)務(wù)的角度把整個(gè)要演示的功能盡可能串起來，準(zhǔn)備好展示的步驟。 演示數(shù)據(jù)也需要準(zhǔn)備好，展示的時(shí)候可以直接使用，只需要操作所演示功能部分，不需要臨場創(chuàng)建準(zhǔn)備數(shù)據(jù)。 演示環(huán)境要提前準(zhǔn)備好，包括部署好需要演示的應(yīng)用程序版本，而且要告訴團(tuán)隊(duì)不要破壞準(zhǔn)備好的環(huán)境。

沒有上下文鋪墊

• 既不先介紹一下要演示功能的來龍去脈，也不說明這個(gè)功能是干嘛的。

正確做法：開始演示前要先介紹上下文。

逐條過AC

• 展示會(huì)的過程就是按照用戶故事（Story）的驗(yàn)收標(biāo)準(zhǔn)（AC，Acceptance Criteria）一條一條地過一遍，沒有連貫性。

正確做法：以功能為單位演示。

不要一個(gè)一個(gè)用戶故事的演示，而是將整個(gè)功能串起來，

企圖覆蓋所有路徑

• 在系統(tǒng)功能中，通常會(huì)有“用不同路徑實(shí)現(xiàn)相同或類似功能”的情況，比如一個(gè)上傳文件的功能有多個(gè)入口，
• 有人在演示這個(gè)文件上傳功能的時(shí)候，企圖把所有入口的文件都完整演示一遍，

正確做法：只演示最關(guān)鍵路徑。

過多提及跟演示功能無關(guān)內(nèi)容

正確做法：只提及要演示的功能。

展示可以考慮只演示最主要的功能，那些小的反饋就不需要展示了，

也不要提及任何還未完成的功能模塊，特別是對于團(tuán)隊(duì)正在開發(fā)的技術(shù)卡或者還不成熟的技術(shù)方案等，一定不要提及。

認(rèn)為展示僅僅是BA或QA的事情

正確做法：人人都可以展示

盡量多參加展示會(huì)，這是一個(gè)了解系統(tǒng)、聽取客戶反饋的絕佳機(jī)會(huì)。

不熟悉的新人負(fù)責(zé)展示

正確做法：展示前先充分了解系統(tǒng)和業(yè)務(wù)

但不建議采用給青澀新人提供展示機(jī)會(huì)的方式來幫助他們提高能力，如果要給新人鍛煉機(jī)會(huì)，可以讓新人在結(jié)

淺談敏捷離岸團(tuán)隊(duì)溝通

按需互訪

image-20210219154843532

• 合作雙方的互訪則是建立信任的捷徑，通過這扇窗戶

• 一方面可以了解雙方的企業(yè)文化、工作習(xí)慣用到個(gè)人的性格特點(diǎn)

• 另一方面能夠利用面對面工作坊高效梳理規(guī)劃，最大程度保證后續(xù)項(xiàng)目推進(jìn)方向的正確性。在條件允許的情況下，在項(xiàng)目伊始就建立互訪機(jī)制

1. 在項(xiàng)目的重要節(jié)點(diǎn)，例如合作初始、項(xiàng)目里程碑、檢查點(diǎn)進(jìn)行在岸交流
2. 設(shè)立雙向固定互訪周期，如每三個(gè)月/半年

巧用工具

• RealtimeBoard：如果讓我列舉『2017年度最好用工具』，它一定榜上有名：它是我目前能找到的最好的貼板，是組織遠(yuǎn)距離工作坊的最佳搭檔

image-20210219155206818

第8章　為什么你的Scrum會(huì)失敗

三個(gè)角色

角色一：PO的任職資格

• 如果是一個(gè)產(chǎn)品項(xiàng)目，面向多個(gè)潛在客戶，那么你們組織中誰對產(chǎn)品的成敗負(fù)有首要責(zé)任，誰就是PO

角色二：Scrum Master的悖論

• Scrum Master的使命就是把自己做沒，不是做媒，是做沒
• 教會(huì)團(tuán)隊(duì)自組織、教育PO、教育開發(fā)團(tuán)隊(duì)、教育組織里其他干系人。評價(jià)教練的唯一標(biāo)準(zhǔn)就是被教的人不再需要他/她了

角色三：開發(fā)團(tuán)隊(duì)自組織的假象

• Scrum團(tuán)隊(duì)不是自組織，而是沒組織。原先的職責(zé)隨風(fēng)而去，現(xiàn)在統(tǒng)一稱團(tuán)隊(duì)（Team）

四個(gè)會(huì)議

Sprint計(jì)劃會(huì)議：實(shí)際上就沒課分開的兩個(gè)會(huì)

• 計(jì)劃會(huì)議有兩個(gè)主題：做什么（What）和如何做（How）

IPM

• 某種程度上是不需要開發(fā)團(tuán)隊(duì)參與的。PO應(yīng)該根據(jù)干系人的輸入，從業(yè)務(wù)優(yōu)先級上選出下個(gè)Sprint的Backlog。這個(gè)過程可稱為IPM（iteration planning meeting），應(yīng)該在本Sprint開始前進(jìn)行，也就是推薦在上個(gè)Sprint的末尾進(jìn)行，PO完全可以一個(gè)人搞定或者跟業(yè)務(wù)方的干系人來商定，具體如何取決于PO

IKM

• IKM（Iteration Kickoff Meeting），在本Sprint開始時(shí)進(jìn)行，主要目的是PO和開發(fā)團(tuán)隊(duì)對這個(gè)sprint的目標(biāo)進(jìn)行交互，解釋、答疑和達(dá)成共識(shí)

總結(jié)一下，PO自己搞定規(guī)劃，PO和團(tuán)隊(duì)一起開工，團(tuán)隊(duì)自己搞定怎么做。IPM不占開發(fā)團(tuán)隊(duì)時(shí)間

每日站會(huì)：關(guān)注接力棒，而不是運(yùn)動(dòng)員

• 站會(huì)正確的關(guān)注點(diǎn)是：進(jìn)度、障礙、新知及是否要進(jìn)行調(diào)整
• 站會(huì)是以天為周期的PDCA環(huán)中重要的一步，負(fù)責(zé)檢查和提出行動(dòng)建議
• 評價(jià)站會(huì)效果的唯一方式是，會(huì)后有沒有根據(jù)會(huì)上的信息做出相應(yīng)調(diào)整

Sprint回顧會(huì)議

• 只要回顧會(huì)議有效果，其他問題再大都是小問題。當(dāng)回顧會(huì)議沒有效果的時(shí)候，問題就大了
• 站會(huì)/回顧/評審會(huì)議，都涉及調(diào)整。開完會(huì)后沒什么調(diào)整，這個(gè)會(huì)就白開了

第9章　技術(shù)領(lǐng)導(dǎo)者即服務(wù)

• 技術(shù)領(lǐng)導(dǎo)者（Tech Lead）需要扮演三種重要的角色

1. 技術(shù)決策者
2. 流程監(jiān)督人
3. 干擾過濾器

責(zé)任拆解

1. 制訂適合該項(xiàng)目要求的技術(shù)方案。他要參與架構(gòu)設(shè)計(jì)，了解平臺(tái)和編程語言、主要的框架和庫、集成點(diǎn)、部署策略、數(shù)據(jù)遷移策略，確認(rèn)總體技術(shù)方案能夠支撐系統(tǒng)的業(yè)務(wù)要求
2. 保障交付順利開展。他要確保環(huán)境的一致性，搭建和管理持續(xù)集成流水線，指導(dǎo)并監(jiān)督團(tuán)隊(duì)遵循持續(xù)集成的流程和實(shí)踐
3. 管理和提升團(tuán)隊(duì)的能力。需要確認(rèn)團(tuán)隊(duì)是否熟悉用到的技術(shù)棧和工具，幫助團(tuán)隊(duì)成員組織刻意練習(xí)來提升能力

技術(shù)棧管理

• 只有方案、交付、能力三者有很好的協(xié)同，項(xiàng)目和團(tuán)隊(duì)才能健康成長。
• 制訂組織統(tǒng)一的技術(shù)棧，并從技術(shù)棧推導(dǎo)出對應(yīng)的能力評估模型和刻意練習(xí)課程。就得到了下圖所示的以技術(shù)棧為核心的IT能力三環(huán)聯(lián)動(dòng)模型

image-20210220075555803

第10章　項(xiàng)目管理中的敏捷實(shí)踐

• 項(xiàng)目管理中三個(gè)典型難題

1. 團(tuán)隊(duì)目標(biāo)不一致
2. 團(tuán)隊(duì)成員不熟悉
3. 信息發(fā)布不順暢

敏捷的項(xiàng)目管理：追求最大價(jià)值的成功

• 傳統(tǒng)項(xiàng)目管理的定義是：『在有限資源限定的條件下，實(shí)現(xiàn)或超過設(shè)定的需求和期望』。一句話概括了傳統(tǒng)項(xiàng)目管理的鐵三角：需求是范圍，資源包括時(shí)間和成本

image-20210220080207683

那么，這個(gè)定義是正確的嗎？

• 『傳統(tǒng)項(xiàng)目管理鐵三角』概念忽略了『價(jià)值』這一重要因素

用戶故事

• 一個(gè)用戶故事通常包括三個(gè)要素

1. 角色：誰要使用這個(gè)功能
2. 活動(dòng)：需要完成什么樣的功能
3. 商業(yè)價(jià)值：為什么需要這個(gè)功能，這個(gè)功能帶來什么價(jià)值

展示形式：作為一個(gè)<某種類型的用戶角色>，我要<達(dá)成某些目的>，只有這樣我才能夠獲取<商業(yè)價(jià)值>

• 只有當(dāng)所有AC（驗(yàn)收條件，Acceptance Criteria）被覆蓋到，測試人員完成測試，發(fā)現(xiàn)所有功能是可測試的、可運(yùn)行的，這個(gè)用戶故事才算完成了

image-20210220080347937

估計(jì)和迭代計(jì)劃

• 需求優(yōu)先級矩陣

image-20210220080455746

站會(huì)和用戶故事開卡

• 站會(huì)的時(shí)候，介紹一種有意思的實(shí)踐，使用Token，也就是使用一個(gè)實(shí)物作為『令牌』，準(zhǔn)備發(fā)言的人首先取得『令牌』，發(fā)言完成后將『令牌』傳給下一個(gè)人。令牌要醒目，可以是毛絨玩具，也可以是一頂帽子
• 用戶故事開卡（Story Kick-off）指的是在每個(gè)用戶故事開發(fā)之前 ，要確保BA、DEV和QA對用戶故事理解 一致。這個(gè)溝通活動(dòng)通常表現(xiàn)為由DEV講解這個(gè)用戶故事要完成的功能及AC，一旦發(fā)現(xiàn)任何疏漏，BA及時(shí)補(bǔ)充。DEV有任何疑惑，也需要及時(shí)提出來，當(dāng)場確認(rèn)，使這些功能得以正確實(shí)現(xiàn)。在后續(xù)開發(fā)中如果碰到任何疑惑，也應(yīng)及時(shí)找BA了解清楚。QA會(huì)嚴(yán)格按照AC來驗(yàn)收用戶故事

代碼審查和回顧

• 代碼審查（Code Review）是指開發(fā)團(tuán)隊(duì)在完成每天代碼之后，聚在一起評審當(dāng)天的代碼，好處是

1. 團(tuán)隊(duì)經(jīng)過一天高強(qiáng)度的思考與編碼，適當(dāng)停下來，看看其他人寫的代碼，同時(shí)將自己的代碼講解出來，往往能獲得一些意外的靈感，或許能解決自己面臨的阻礙
2. 互相了解設(shè)計(jì)思路，獲得更好的建議和進(jìn)行思路重構(gòu)，提高代碼質(zhì)量
3. 及早發(fā)現(xiàn)潛在缺陷，降低事故成本：如果這個(gè)時(shí)候發(fā)現(xiàn)代碼的壞味道和一些需要改進(jìn)的地方，代碼審核結(jié)束后可以花少量時(shí)間進(jìn)行更改

• 回顧的關(guān)注點(diǎn)也多種多樣

1. 項(xiàng)目開發(fā)
2. 敏捷成熟度
3. 團(tuán)隊(duì)角色和職責(zé)
4. 人員技能提升

• 回顧的形式和方法非常多，最常見的是下圖所示的Well & Less Well

image-20210220080924185

最大程度的可視化

• 除了gefi表示項(xiàng)目狀態(tài)、項(xiàng)目團(tuán)隊(duì)還會(huì)可視化其他的元素，比如團(tuán)隊(duì)?wèi)?yīng)堅(jiān)持的規(guī)則、項(xiàng)目上的經(jīng)驗(yàn)分享以及項(xiàng)目的里程碑

image-20210220080938509

image-20210220081015663

溝通計(jì)劃

• Inception是啟動(dòng)軟件設(shè)計(jì)和交付項(xiàng)目的方法，是通過集中式、互動(dòng)式的設(shè)計(jì)工作坊，幫助客戶在最短時(shí)間內(nèi)對項(xiàng)目范圍達(dá)成一致，快速進(jìn)入項(xiàng)目交付。而Inception的一個(gè)產(chǎn)出就是溝通計(jì)劃（Communication Plan）。比如在這個(gè)溝通計(jì)劃中會(huì)討論

1. 以什么頻率、什么形式作項(xiàng)目的更新。比如說每周五以周報(bào)的形式作一些主要信息的更新；
2. 站會(huì)和迭代會(huì)議什么時(shí)候召開，需要邀請哪些人，比如業(yè)務(wù)負(fù)責(zé)人和技術(shù)負(fù)責(zé)人等

image-20210220081203821

團(tuán)隊(duì)目標(biāo)不一致

1. 用電子墻和物理墻展示 用戶故事、需求全景圖、項(xiàng)目進(jìn)度燃盡圖
2. 通過迭代會(huì)議和功能演示會(huì)議對齊迭代計(jì)劃，項(xiàng)目進(jìn)度、識(shí)別項(xiàng)目風(fēng)險(xiǎn)

團(tuán)隊(duì)成員不熟悉

• 基于敏捷實(shí)踐，創(chuàng)造更多的溝通機(jī)會(huì)，比如回顧會(huì)議、代碼審查和站立會(huì)議。通過不斷創(chuàng)造這樣的溝通機(jī)會(huì)讓團(tuán)隊(duì)成員配合更默契

信息發(fā)布不順暢

1. 共享信息，制定溝通計(jì)劃
2. 最大程度的可視化

行為心理學(xué)家研究認(rèn)為

1. 21天以上的重復(fù)就會(huì)形成習(xí)慣。任何一個(gè)運(yùn)作，重復(fù)21天就會(huì)變成習(xí)慣性的運(yùn)作
2. 任何一種想法，重復(fù)21天或者重復(fù)驗(yàn)證21次，就會(huì)變成習(xí)慣性的思維方式

結(jié)語

• 劍道中有這樣一個(gè)心訣：守、破、離

1. 守：最初階段須遵從老師教誨，認(rèn)真練習(xí)基礎(chǔ)，達(dá)到熟練的境界
2. 破：基礎(chǔ)熟練后，試著突破原有規(guī)范讓自己得到更高層次的場景化
3. 離：在更高層次得到新的認(rèn)識(shí)并總結(jié) ，自創(chuàng)新招數(shù)，另辟新境界

第11章　也談精益

• 精益思想為什么適合于軟件行業(yè)

1. 追求快速價(jià)值交付的小批量生產(chǎn)模式
2. 追求極致卓越的匠藝文化

image-20210220081623286

第12章　團(tuán)隊(duì)敏捷轉(zhuǎn)型的三個(gè)階段

階段1：建立敏捷流程，縮短交付周期

• 這個(gè)階段，引入迭代或者建立看板是重點(diǎn)
• 主要目標(biāo)是將需求的反饋、開發(fā)質(zhì)量的反饋、以及改進(jìn)周期縮短在一個(gè)迭代內(nèi)

image-20210220081839788

• 教練主要采取以下行動(dòng)

1. 培訓(xùn)，給團(tuán)隊(duì)培訓(xùn)敏捷流程、各角色的職責(zé)以及各種工具的使用
2. 現(xiàn)場指導(dǎo)，先帶領(lǐng)團(tuán)隊(duì)走完整的敏捷流程，通常會(huì)有幾個(gè)迭代；然后觀察團(tuán)隊(duì)自己執(zhí)行流程，并幫助團(tuán)隊(duì)改進(jìn)；最后不再參與這類活動(dòng)
3. 需求梳理，指導(dǎo)PO和BA建立需求全景圖（比如用戶故事地圖）、拆分Story、排優(yōu)先級以及和團(tuán)隊(duì)其他成員協(xié)作等；制定Story編寫規(guī)范，Story價(jià)值流和建立Story看板

• 主要培養(yǎng)目標(biāo)：Scrum Master，讓他們能了解 敏捷流程的運(yùn)作方式，并能帶領(lǐng)團(tuán)隊(duì)在教練不在場的情況下，依然按敏捷流程運(yùn)作

階段2：引入技術(shù)實(shí)踐，質(zhì)量內(nèi)建，減少返工

• 主要目標(biāo)：提升開發(fā)人員的質(zhì)量意識(shí) ，從而提升開發(fā)階段產(chǎn)出的質(zhì)量水平，減少后續(xù)環(huán)節(jié)的返工。用質(zhì)量內(nèi)建的話來說，在缺陷時(shí)就立刻修復(fù)

image-20210220082126135

• 為了提升生產(chǎn)過程的質(zhì)量，減少返工，提高效率，我們會(huì)引入技術(shù)實(shí)踐，以縮短質(zhì)量驗(yàn)證的反饋周期，主要包括以下實(shí)踐

1. 單元測試
2. 集成測試：包括API測試和組件測試、契約測試等
3. UI自動(dòng)化測試
4. CI：將以上測試定期運(yùn)行并可視化報(bào)告，讓所有團(tuán)隊(duì)看到。同時(shí)要求團(tuán)隊(duì)第一時(shí)間修復(fù)CI
5. CD：建立自動(dòng)部署流水線到生產(chǎn)環(huán)境，并集成冒煙 測試，同時(shí)實(shí)現(xiàn)回滾
6. Git：建立使用git規(guī)范，建立分支策略或者指導(dǎo)客戶做純主干開發(fā)，培訓(xùn)客戶使用git高級功能
7. Operation相關(guān)技術(shù)：指導(dǎo)客戶實(shí)踐藍(lán)綠部署、云和容器、金絲雀發(fā)布等

image-20210220082335812

階段3：提升價(jià)值交付效率和響應(yīng)力

• 目標(biāo)：培養(yǎng)成員的自我提升意識(shí) ，團(tuán)隊(duì)的自我改善能力，并幫助團(tuán)隊(duì)建立自我改進(jìn)的習(xí)慣

1. 更高級的能力建設(shè)：如引入微服務(wù)、代碼共享和特性團(tuán)隊(duì)等
2. 以教練指導(dǎo)為主：我們教的內(nèi)容會(huì)變少，指導(dǎo)的內(nèi)容會(huì)變多，會(huì)讓客戶自己組織更多的分享，鼓勵(lì)客戶自學(xué)，并建立學(xué)習(xí)型文化
3. 與業(yè)務(wù)走得更近：團(tuán)隊(duì)可以更好地理解 業(yè)務(wù)，同時(shí)能給業(yè)務(wù)提供更有價(jià)值的建議，因此很多業(yè)務(wù)在決策早期就會(huì)引入技術(shù)團(tuán)隊(duì)的成員

第13章　績效考核，敏捷轉(zhuǎn)型的鴻溝

敏捷轉(zhuǎn)型過程中的必然挑戰(zhàn)

image-20210220082618053

績效考核的困境

• 傳統(tǒng)績效考核與敏捷價(jià)值觀之間的沖突
• 傳統(tǒng)績效考核已經(jīng)成為敏捷團(tuán)隊(duì)走向成熟的掣肘

image-20210220082649891

如何破局？

正如《管理3.0：培養(yǎng)和提升敏捷領(lǐng)導(dǎo)力》所說，所有變革最后的失敗都是管理的問題。應(yīng)該把績效考核這種管理手段當(dāng)成『敏捷鐵三角』中一角來對待，那就是調(diào)整約束

image-20210220082755692

image-20210220082903186

清華大學(xué)管理學(xué)教授寧向東一針見血地批出，管理，其本質(zhì)就是關(guān)于如何『破局』的智慧。所謂『局』就是管理者周圍的各種資源相互聯(lián)系，相互作用的一種狀態(tài)。以上約束，也是軟件工程表現(xiàn)出來的組織復(fù)雜性，也是一種局

書

1. 《管理3.0：培養(yǎng)和提升敏捷領(lǐng)導(dǎo)力》

第14章　一個(gè)交付故事

• 調(diào)整團(tuán)隊(duì)結(jié)構(gòu)，給予團(tuán)隊(duì)更大的自治，從而釋放生產(chǎn)力，這是高效交付的秘訣
• 每個(gè)成功的互聯(lián)網(wǎng)公司都有一個(gè)基礎(chǔ)平臺(tái)來更好支撐和實(shí)施自己的業(yè)務(wù)戰(zhàn)略，專注在如何提升開發(fā)團(tuán)隊(duì)的體驗(yàn)、關(guān)注在如何打造一個(gè)平臺(tái)來為開發(fā)團(tuán)隊(duì)提供更多的自治，從而釋放出更大的生產(chǎn)力

第15章　又一個(gè)交付故事

• 技術(shù)領(lǐng)導(dǎo)者（Tech Lead）的傾向從追逐『正確』的決策，變成了開始作出『合適』的技術(shù)決策
• 交易成本的不斷降低，打破了壁壘，促進(jìn)了無數(shù)的人投身創(chuàng)業(yè)一樣，技術(shù)成本的不斷降低，技術(shù)壁壘的不斷降低，也會(huì)帶來更大范圍的結(jié)構(gòu)性變化

比如自動(dòng)化測試技術(shù)干掉了傳統(tǒng)的測試部門，數(shù)據(jù)庫的自動(dòng)化技術(shù)干掉了DBA，部署、運(yùn)營的自動(dòng)化干掉了運(yùn)營，云化、安全內(nèi)嵌也許將要干掉采購和安全。當(dāng)這些東西，因?yàn)榧夹g(shù)的進(jìn)步而標(biāo)準(zhǔn)化后，當(dāng)全面的數(shù)字化平臺(tái)就緒之后，那么剩下的就僅僅是業(yè)務(wù)解決方案、技術(shù)棧與實(shí)現(xiàn)代碼了，王老師把決策權(quán)交給開發(fā)團(tuán)隊(duì)是一個(gè)自然而然的選擇……

第17章　如何在團(tuán)隊(duì)建設(shè)工程師文化？阿里資深技術(shù)專家這么做

工程師文化的特征

小團(tuán)隊(duì)

7-12人的團(tuán)隊(duì)是比較適合的團(tuán)隊(duì)大小。有人用畢節(jié)團(tuán)隊(duì)來形容一個(gè)團(tuán)隊(duì)大小（兩張比薩可以喂飽這個(gè)團(tuán)隊(duì)）。臉書和谷歌經(jīng)常有兩三個(gè)人的團(tuán)隊(duì)。小團(tuán)隊(duì)特征

1. 不破不立
2. 以少為多，精準(zhǔn)打擊
3. 勇敢追求卓越

技術(shù)創(chuàng)新

技術(shù)決策權(quán)大

• 尊重技術(shù)決策的前提就是信任技術(shù)決策

技術(shù)數(shù)據(jù)可視化

• 圈復(fù)雜度、測試覆蓋率、重復(fù)率等

分享多會(huì)議少

測試原則

1. 用given/when/then語態(tài)寫單元測試
2. 要讓測試代碼更容易寫
3. 合理使用mock/stub技術(shù)，測試你要測的，讓你的測試更有效
4. 異步測試不要用sleep
5. 最好的debug手段就是測試
6. 單元測試耗時(shí)最短，多用單元測試覆蓋代碼邏輯
7. 越是集成測試數(shù)量應(yīng)該越少，因?yàn)榇鷥r(jià)很大，性價(jià)比不高
8. 靜態(tài)代碼質(zhì)量分析應(yīng)該伴隨每次持續(xù)集成

分支策略

• 分支盡量少，持續(xù)集成越?jīng)]意義，合并（merge）成本越高，團(tuán)隊(duì)分支最多也不能超過下圖

image-20210220101910212

結(jié)對編程

1. 一個(gè)主機(jī)，兩個(gè)鍵盤，一個(gè)顯示器
2. 新老員工結(jié)對是新員工掌握實(shí)踐的最快手段
3. 結(jié)對讓員工有機(jī)會(huì)互相學(xué)習(xí)對方良好的編程方式，形成團(tuán)隊(duì)獨(dú)有的代碼風(fēng)格，而不是個(gè)人代碼風(fēng)格
4. 時(shí)不時(shí)的結(jié)對不會(huì)降低開發(fā)效率，會(huì)提高學(xué)習(xí)熱情

代碼回顧

• 很難說還有哪個(gè)實(shí)踐比這個(gè)實(shí)踐對代碼質(zhì)量更有意義，回顧的方式有

1. 團(tuán)隊(duì)代碼回顧，總共最好1個(gè)小時(shí)左右
2. 每天代碼回顧
3. 每個(gè)人的代碼都要回顧，每個(gè)人都要講解
4. 發(fā)現(xiàn)的問題當(dāng)天就改掉

第18章　敏捷轉(zhuǎn)型下的團(tuán)隊(duì)管理：來自一線管理者的思考

• 初入管理往往會(huì)陷入兩個(gè)誤區(qū)

1. 集中控制管理
2. 微觀管理

杰克 韋爾奇先生的一句名言：『在GE，我做得最棒的一件事情是創(chuàng)造了一臺(tái)準(zhǔn)確報(bào)時(shí)的鐘』在企業(yè)中，即使是僅僅管理一個(gè)小型團(tuán)隊(duì)的一線管理者，管理者的目標(biāo)也應(yīng)該是打造一座可以自動(dòng)運(yùn)轉(zhuǎn)并精確報(bào)時(shí)的時(shí)鐘，而不是自己去報(bào)時(shí)

• 此后，我做了很多針對公司和部門流程在團(tuán)隊(duì)工作層面的細(xì)化，我稱之為『工作細(xì)則』，將所有日常團(tuán)隊(duì)可以通過自身機(jī)制自動(dòng)處理的工作都落實(shí)成團(tuán)隊(duì)中眾所周知的規(guī)則 。自己更多開始關(guān)注自身和團(tuán)隊(duì)中每一個(gè)人的學(xué)習(xí)和成長，團(tuán)隊(duì)的異常事務(wù)的處理，團(tuán)隊(duì)目標(biāo)的設(shè)定和更高目標(biāo)的找尋

敏捷轉(zhuǎn)型下管理者應(yīng)該如何自處？

• 團(tuán)隊(duì)管理的終極目標(biāo)是打造一個(gè)『自組織』的團(tuán)隊(duì)，比打造『時(shí)鐘』的隱喻更進(jìn)一步，要打造一個(gè)『生命體』，不僅可以自動(dòng)報(bào)時(shí)，還可以響應(yīng)變化 ，自我成長

需要團(tuán)隊(duì)管理者首先要做到信任和放手

• 團(tuán)隊(duì)通過自己的成長持續(xù)的把事情做對，以致做得更好

書

1. 《走出硝煙的精益敏捷：我們?nèi)绾螌?shí)施Scrum和Kanban》