需求拆分驱闷。需求拆分是一個基礎實踐，沒有該實踐空免，后續(xù)的很多實踐就無從談起或者效果會打很大的折扣空另。在Scrum指南中也有指出product backlog是逐步細化并且是持續(xù)的過程。
拆分在此作為一個基礎實踐在很大程度上是可以影響scrum團隊每迭代交付能力的蹋砚。比如現(xiàn)實中經(jīng)常遇到的一個問題就是團隊說需求沒辦法拆分扼菠。尤其是To B行業(yè)的需求或者平臺類的需求更是如此，比較大的需求粒度會對于后續(xù)的實踐比如估算造成影響坝咐，粒度越大對于估算準確性的影響越大循榆，較大的粒度還會影響透明，因為一個需求level的卡片會長時間保持一個狀態(tài)墨坚，更大的粒度甚至能影響是跨迭代交付還是在一次迭代內(nèi)交付秧饮。想象一下，極端情況下如果在一個Sprint里面只有一個US泽篮，那么跟瀑布的區(qū)別有多大盗尸？拆分才能更好的排列優(yōu)先級，比如一個登錄功能帽撑，只有拆分了泼各，我們才能知道先做的是手機號驗證登錄、郵箱登錄還是微信一鍵登錄油狂。否則優(yōu)先級無從談起历恐；拆分才能幫助漸進明晰寸癌，產(chǎn)品可以細化最高優(yōu)先級的需求专筷，可以更快的交付價值得到反饋，從而調(diào)整后續(xù)的需求設計和優(yōu)先級蒸苇；拆分才能按價值交付磷蛹，而不是迭代結束非零即一，比如搜索功能溪烤，可以拆分成按照ID搜索味咳、按照關鍵字搜索、模糊搜索檬嘀、根據(jù)搜索結果智能推薦等槽驶，拆分了在迭代結束可能交付前三個可用功能，而不會功能都處于待開發(fā)不可用狀態(tài)鸳兽。作為一個實踐掂铐，需要注意的是拆分的方式，不能為了拆而拆分，比如按照組件切片全陨，正確的方式在用戶故事的相關書籍和資料中有諸多描述爆班，不再贅述。
持續(xù)集成辱姨。持續(xù)集成也是技術實踐中非呈疗校基礎的一個。嚴格來說持續(xù)集成并不是跟敏捷綁定的實踐雨涛，也不是一個新的概念枢舶。在諾記工作的時候，公司里的CI做的比較成熟替久，從代碼提交祟辟、分支管理、靜態(tài)檢查侣肄、單元測試旧困、系統(tǒng)測試、冒煙測試直到硬件測試稼锅，已經(jīng)做的比較完善吼具。一度我以為這就是工作的常態(tài)，從諾記出來才發(fā)現(xiàn)跟敏捷一樣矩距，有好多好多的團隊和工程師只是用這么一個名詞拗盒，甚至是互聯(lián)網(wǎng)企業(yè)也是，依然沒有持續(xù)集成锥债，而這正阻礙團隊在每迭代的交付陡蝇。只有實施了持續(xù)集成，才能將PDCA的周期降的足夠短哮肚，也就是小時和分鐘級登夫。敏捷也好，甚至只是為了縮短交付周期允趟，沒有持續(xù)集成將會是非常困難的一件事兒恼策。持續(xù)集成實際上是把人與人之間的集成變成了人與機器集成，或者是代碼與代碼的集成潮剪，隨著疫情的發(fā)展涣楷，跨地理位置和時區(qū)的協(xié)作越來越是常態(tài)，那么持續(xù)集成更是變得重要抗碰。不同的工程師狮斗、不同的組件、不同的模塊弧蝇，隨時可以集成到同一個分支碳褒，并且迅速得到反饋迄汛。好的持續(xù)集成可以幫助團隊及早甚至隨時處于可交付狀態(tài)，而不是“我的工作做完了骤视，但是....”的情況鞍爱。
UT。如果說前兩個實踐是沒有多少爭議的专酗，充其量是做的好一些差一些睹逃，那么UT卻是一個理論上多數(shù)人認可，但是實踐上千差萬別的一個實踐祷肯。UT代表了很多工作方式的改變沉填，比如測試左移、比如開發(fā)工程師保證質(zhì)量而不是專職的測試人員佑笋、比如測試驅(qū)動開發(fā)（并不總是如此）翼闹，道理或多或少大家能接受，但是真實的工作中蒋纬，能把UT做好的猎荠，卻是相對較少。原因有這么幾個蜀备，一是不會关摇，或者說不熟悉。以往的工作中大家都沒有先寫UT的習慣碾阁，上來就是擼代碼输虱，質(zhì)量好壞看測試人員的。改為UT以后需要學習UT怎么去寫脂凶，如果先寫代碼后寫UT宪睹，由于代碼沒有考慮可測試性，往往會遇到各種障礙蚕钦，難度和所需時間都比較多亭病，開發(fā)人員很容易退縮；如果先寫UT后寫代碼冠桃，跟原來的工作習慣差別很大命贴，需要先考慮清楚要實現(xiàn)的功能道宅，在沒有一定自驅(qū)力的情況下食听，不太容易做這個改變。還有一個場景是UT并沒有抓住多少bug污茵，但是投入?yún)s比較大樱报。極限編程的擁躉者認為寫UT不會增加整體的開發(fā)時間，但是大部分人做不到泞当，寫UT確實增加了他們的開發(fā)時間迹蛤。在諾記UT覆蓋率非常高，但是抓取bug的比例并不高，尤其是跟系統(tǒng)測試比較盗飒，所以對于UT的爭議始終存在嚷量。但是后來起碼與我自己的理解是UT是重構的基礎，是集體代碼所有制的基礎逆趣，是持續(xù)集成的基礎蝶溶，沒有UT，頻繁重構就不是很現(xiàn)實宣渗，因為回歸測試就無法保證抖所，沒有UT，也就沒有辦法保證現(xiàn)有的代碼不被其他人新寫的代碼破壞掉痕囱，所以UT的必要性還是有的田轧。還有種場景是有的組織中業(yè)務不明朗，希望糙快猛的上線功能去試錯鞍恢，等穩(wěn)定下來再談UT傻粘，建議是核心代碼加上UT保護“锏簦回到本文的主題抹腿，有了足夠覆蓋率的UT，可以持續(xù)的保持并改進每迭代的交付能力旭寿，因為UT對于新功能的擴展和更頻繁的代碼提交提供了回歸測試和保護警绩。
