每天走進(jìn)辦公室，第一件事情是沖上一杯咖啡，在Pantry和同事聊會天。然后回到辦公桌前，查收前一天未讀的郵件。
項目經(jīng)理和商業(yè)分析師打開產(chǎn)品代辦列表（Product Backlog），看看當(dāng)前項目的進(jìn)展。大家還會檢查開發(fā)環(huán)境、測試環(huán)境和模擬的生產(chǎn)環(huán)境，如果有問題，這是需要第一時間盡快修復(fù)的。
產(chǎn)品待辦列表是團(tuán)隊在進(jìn)行迭代式開發(fā)時經(jīng)常使用的一種工具，來管理在未來迭代中將要實現(xiàn)的用戶需求。出現(xiàn)在“產(chǎn)品待辦列表”中的用戶需求一般以“用戶故事”為單位來組織。
傳統(tǒng)的“堆棧式”產(chǎn)品待辦列表強(qiáng)調(diào)按用戶故事的優(yōu)先級排序，越靠近棧頂?shù)挠脩艄适聝?yōu)先級越高，且拆分得要足夠細(xì)，以便讓團(tuán)隊在下一個迭代開始時從中選取要開發(fā)的用戶故事。
迭代啟動會議（IPM）通常發(fā)生在每個迭代的第一天，團(tuán)隊成員一起制定迭代計劃。這個會議由商業(yè)分析師主持，團(tuán)隊一起同步幾個方面的內(nèi)容：
下一個迭代的用戶故事;
對下一個迭代的期望和計劃;
風(fēng)險的評估和總結(jié)。
不同的人對需求的理解是不同的，所有團(tuán)隊成員都要明確用戶故事的相關(guān)內(nèi)容、所要實現(xiàn)的功能、滿足了哪些條件用戶故事才算完成。迭代會議的主要產(chǎn)出是下一個迭代中需要完成的用戶故事，這些用戶故事即為下一個迭代所要完成的主要目標(biāo)。?
?站會（Standup Meeting）是團(tuán)隊一天協(xié)同工作的開始。團(tuán)隊在物理墻前快速開一個會議，團(tuán)隊成員逐個更新自己的狀態(tài)：
昨天完成的工作；
今天計劃做的工作；
面臨什么阻礙，需要什么幫助；
自己手頭用戶故事的進(jìn)展，是否存在技術(shù)風(fēng)險。
并不意味著每個團(tuán)隊必須一直使用這個日程，團(tuán)隊會根據(jù)自己的情況，調(diào)整站會的安排。舉個例子，運(yùn)行了幾個迭代后，團(tuán)隊發(fā)現(xiàn)講述“昨天做了什么”并沒有帶來實際價值，而及時暴露潛在的風(fēng)險更為重要，于是團(tuán)隊會將站會的時間更多地放在“我的任務(wù)有什么風(fēng)險”的更新上。
既然是快速的會議，站會的時間就不宜過長，10分鐘左右為佳。建議團(tuán)隊成員站著開會，因為研究表明，當(dāng)人們坐著開會的時候，會議的時間會被無形中拉長——會議的重要目的是讓每個人在自己以及同事面前作出承諾，這個承諾是團(tuán)隊之間的承諾。
站會結(jié)束后大家就開始了一天的工作。在敏捷開發(fā)中，所有需求都會以“故事卡”的形式拆分、細(xì)化、并傳遞給開發(fā)團(tuán)隊。
用戶故事開卡（Story Kick-off）常常是一天敏捷軟件開發(fā)的開始。在每個用戶故事開發(fā)之前，要確保BA、DEV和QA對用戶故事理解一致。這個溝通活動通常由DEV講解該用戶故事要完成的功能及驗收條件（AC：Acceptance Criteria），一旦發(fā)現(xiàn)任何疏漏，BA會及時補(bǔ)充。DEV有任何疑惑也需及時提出來，當(dāng)場確認(rèn)，使這些功能得以正確實現(xiàn)。在后續(xù)開發(fā)中如果碰到任何疑惑，也應(yīng)及時找BA了解清楚。QA會嚴(yán)格按照AC來驗收用戶故事。
結(jié)對編程（Pair Programming）是指兩位程序員坐在同一工作臺前開發(fā)軟件。
結(jié)對編程將代碼評審做到極致：錯誤發(fā)現(xiàn)地越早，修復(fù)成本越低；
結(jié)對編程是關(guān)于代碼的標(biāo)準(zhǔn)、結(jié)構(gòu)的變化（重構(gòu)）、架構(gòu)演化的知識，在 Dev們之間盡可能以無縫的形式流動，取得共同理解和學(xué)習(xí)的過程，并減少代碼對特定人的絕對依賴。
Dev把自己對應(yīng)的卡開發(fā)完成并提交代碼后，需要和需求輸出方（商業(yè)分析師）在測試環(huán)境下desk check以驗收需求，否則不可以將卡挪到下一個泳道，這個過程叫Story Sign Off。
時空的距離不應(yīng)成為團(tuán)隊協(xié)同工作的阻礙，如果能有超過四個小時的工作時間重疊，Always on（由電視、Mac Mini和即時通訊工具組成的無間斷視頻）一定要有。實時視頻能增加許多親切感和趣味，拉近團(tuán)隊成員的距離；更能讓包括站會、desk check在內(nèi)的很多敏捷實踐變得容易。有了Always On，信息不回抬頭喊一喊，開會了朝屏幕招招手，方便直接，即使大家相隔千里，也能隨時就問題展開討論。
敏捷團(tuán)隊非常重視學(xué)習(xí)和分享，通過做session實現(xiàn)能力培養(yǎng)和知識傳遞是一種很常見的方式。一天的中午，各個團(tuán)隊會有計劃性地舉行session分享。為了將知識分享的供需可視化，可以建立一個session墻，分成兩部分：一邊由團(tuán)隊成員寫出想要了解的技術(shù)、業(yè)務(wù)知識，相當(dāng)于是需求方；另一邊寫著根據(jù)需求而安排的session，相當(dāng)于是提供方，這樣清楚明了，便于跟蹤。
在一天的工作中，有時候會組織功能演示（Showcase）。Showcase是敏捷開發(fā)流程中的又一個實踐，通常發(fā)生在每個迭代的最后一天。團(tuán)隊把一個迭代中開發(fā)好的功能給相關(guān)人員演示，并收集反饋，以便在下一個迭代中可以對變化作出快速響應(yīng)。同時每個利益干系人可以清楚地看到項目當(dāng)前的進(jìn)展，也許會超出預(yù)期，也許會低于預(yù)期。但不論是讓人驚喜還是沮喪，都給大家看到了項目進(jìn)度的真相，因此Showcase也是對項目檢查和調(diào)整的反饋環(huán)。
在迭代結(jié)束的時候，團(tuán)隊做改進(jìn)和調(diào)整的活動有兩個：Showcase是對項目的改進(jìn)和調(diào)整；回顧會議（Retrospective）是對團(tuán)隊工作方式的改進(jìn)和調(diào)整?；仡檿h可以讓團(tuán)隊停下來思考并審視：我們哪些地方存在問題，需要改進(jìn)；哪些地方做得好，需要保持。團(tuán)隊的工作流程、團(tuán)隊之間的協(xié)作方式等都可以是回顧會議的思考框架。
開發(fā)團(tuán)隊在完成每天代碼之后，會聚在一起評審當(dāng)天的代碼，我們稱之為代碼審查（Code Review) 。團(tuán)隊經(jīng)過一天的高強(qiáng)度的思考與編碼，適當(dāng)?shù)赝Ｏ聛恚纯雌渌藢懙拇a，同時將自己的代碼講解出來，往往能意外地獲得一些靈感，或許能解決自己面臨的阻礙。
團(tuán)隊會保證代碼能夠與已有代碼進(jìn)行集成，并且在一天的工作中也會盡可能頻繁地把代碼撿入到單個主線分支中。如果構(gòu)建失敗，團(tuán)隊會把修復(fù)CI當(dāng)作第一優(yōu)先級的事情來做。
完成Code Review，忙碌而有趣的一天結(jié)束了。在《選擇三件事》這本書中，作者建議讀者只要放棄什么都想做的執(zhí)念，我們的生活就會更充實。每天我們應(yīng)當(dāng)在工作、睡覺、家庭、朋友和健身這五件事中，選擇做三件主要的事情?；氐郊遥闩慵胰?、看看書、早點(diǎn)休息。新的一天會更加精彩！
后記——敏捷文化 OVER 敏捷實踐
我在文化四象限中寫過組織文化模型，包括協(xié)作型、控制型、培養(yǎng)型和技能型。每一種文化都有其優(yōu)勢和劣勢，不能說哪種更好。只是對于某些類型的工作，或其當(dāng)下所處的場景，一種文化也許比其他文化更適用。大部分組織都有一個主導(dǎo)的文化類型，并以其他三種文化的元素為輔。
敏捷有很強(qiáng)的文化特征，其核心是協(xié)作型文化，其次是培養(yǎng)型文化。在協(xié)作型、培養(yǎng)型文化為主導(dǎo)的組織里，敏捷開展就會容易得多，這是因為這樣的組織天生就有敏捷的基因。反之，在控制型為主導(dǎo)的組織里，敏捷文化和企業(yè)自身文化的摩擦就會比較多。
本文講到了很多敏捷實踐。最好的方法是我們在開展這些敏捷實踐的過程中，潛移默化地牽引大家思想的轉(zhuǎn)變，逐漸讓團(tuán)隊所有成員理解實踐背后的意義，從而讓大家自然而然地接受敏捷思想。隨著時間的推移，個體與個體、個體與團(tuán)隊、團(tuán)隊與團(tuán)隊在敏捷實踐中的頻繁互動，團(tuán)隊里的大部分人的思想和行為產(chǎn)生了改變，文化也就自然發(fā)生了改變。
這樣的團(tuán)隊不只是實踐敏捷，更是掌握了敏捷思想，學(xué)會了用敏捷的價值觀和原則思考，逐步達(dá)到知行合一，我們稱之為文化敏捷。
閱讀：
本文作者萬學(xué)凡，ThoughtWorks首席咨詢師，武漢。作者保留本文一切權(quán)利，未經(jīng)許可請勿轉(zhuǎn)載。
