敏捷和小瀑布的相愛相殺
原創(chuàng)：?陳輝?敏捷視界?9月5日
敏捷和小瀑布的相愛相殺
光環(huán)學(xué)友會 ? 敏捷實戰(zhàn)分享
本文作者 ?陳輝
8月31日，我們有幸請到宿昱老師給大家分享了自己在日常工作和經(jīng)驗中看到的和了解到的，有關(guān)團(tuán)隊執(zhí)行敏捷和團(tuán)隊執(zhí)行小瀑布的一些情況。
分享嘉賓/
宿昱，光環(huán)國際管理咨詢集團(tuán)高級咨詢顧問，近8年敏捷經(jīng)驗，先后服務(wù)于興業(yè)銀行、隆正、海關(guān)電子口岸、平安保險、伊利、IBM等企業(yè)。擅長工程實踐類敏捷實踐方法，重視項目管理的可視化，敏捷工件的使用。在自動化測試等實踐上有豐富的實踐經(jīng)驗，通過有效的使用優(yōu)秀的敏捷工件解決產(chǎn)品研發(fā)過程中遇到的瓶頸問題，精進(jìn)產(chǎn)品交付。
敏捷有自己的5大價值觀和12原則。
核心價值觀：客戶合作高于合同談判。
敏捷核心原則：可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。
只有這些價值觀和原則，我們的項目如何落地?。坷碚撜娴牟恢匾獑幔课覀冊撊绾慰创碚撛陧椖恐械淖饔媚?？為了讓大家有更清晰的認(rèn)知，我們來講個故事。
舉例一個團(tuán)隊，小明是項目經(jīng)理，團(tuán)隊使用敏捷方法來執(zhí)行的。
項目團(tuán)隊是一個大團(tuán)隊。分別是他們的產(chǎn)品團(tuán)隊、設(shè)計團(tuán)隊、研發(fā)團(tuán)隊、測試團(tuán)隊、項目團(tuán)隊和運(yùn)維團(tuán)隊。每一個團(tuán)隊下都會附帶著很多的職責(zé)。
產(chǎn)品團(tuán)隊有產(chǎn)品經(jīng)理；設(shè)計團(tuán)隊有設(shè)計師；研發(fā)團(tuán)隊包括前端開發(fā)和后端開發(fā)；測試團(tuán)隊包括功能測試和自動化測試，還有性能和技術(shù)測試；項目團(tuán)隊包含了很多的項目經(jīng)理；運(yùn)維團(tuán)隊包含了部署和配置人員，還有運(yùn)維人員和網(wǎng)絡(luò)人員。
這就是小明團(tuán)隊的組織架構(gòu)。每個團(tuán)隊都有自己的負(fù)責(zé)人。像產(chǎn)品總監(jiān)、設(shè)計總監(jiān)，研發(fā)團(tuán)隊和測試團(tuán)隊都隸屬于CTO旗下，項目團(tuán)隊有自己的項目總監(jiān)，運(yùn)維團(tuán)隊有自己的運(yùn)維總監(jiān)。
團(tuán)隊使用的是迭代的開發(fā)方法。每個月迭代一次，每個月的月末都要進(jìn)行上線。項目經(jīng)理需要將所有的項目需求匯總，召集產(chǎn)品和業(yè)務(wù)PK一下決定優(yōu)先級，然后讓團(tuán)隊進(jìn)行評估，確定前端和后端的聯(lián)調(diào)時間，以及提測時間和外部系統(tǒng)聯(lián)調(diào)時間（如果有外部聯(lián)接的話）。
那么，他們迭代的開發(fā)流程是什么樣子的呢？
業(yè)務(wù)部門提出自己的一些想法和需求，交由產(chǎn)品部進(jìn)行分析，然后輸出一些需求文檔和原型圖交付給設(shè)計團(tuán)隊。設(shè)計團(tuán)隊基于原型圖進(jìn)行視覺上的設(shè)計，切好圖之后交給前端開發(fā)，產(chǎn)品將需求文檔交給后端開發(fā)。前端開發(fā)和后端開發(fā)進(jìn)行一段時間的開發(fā)之后，約定相應(yīng)的時間進(jìn)行前端和后端的聯(lián)調(diào)，聯(lián)調(diào)通過之后統(tǒng)一地交由測試團(tuán)隊進(jìn)行功能測試。功能測試完成之后可能會上UAT，或者SIT環(huán)境去進(jìn)行集成測試。集成測試完成之后再進(jìn)行上線。
如上就是小明團(tuán)隊的迭代開發(fā)流程，從第一步業(yè)務(wù)部門的提出直到最后一步上線，這樣一個開發(fā)過程。
那么小明作為一個項目經(jīng)理，在其中應(yīng)該做什么樣的決定呢？他需要排一個工期表，按照開發(fā)+測試+UAT的時間可以囊括在一個月內(nèi)的話，則把這次迭代上線的內(nèi)容，要求在月底必須完成作為迭代的目標(biāo)傳遞給團(tuán)隊。
當(dāng)他們在進(jìn)行的過程中，出現(xiàn)了一些問題。在需求宣講的時候，A需求與外部系統(tǒng)對接產(chǎn)生了一些變化，需要對需求進(jìn)行一些變更。但這個任務(wù)的前端開發(fā)已經(jīng)完成，后端也完成大半，很快就要按原計劃聯(lián)調(diào)了。負(fù)責(zé)A需求的產(chǎn)品經(jīng)理找到了小明，希望小明出面讓團(tuán)隊解決這個問題。
經(jīng)過深思熟慮，小明決定支持這項變更。這個任務(wù)客觀上來說已經(jīng)快要完成了，要是廢棄掉太得不償失了，不如徹底改好做完它。所以，小明讓負(fù)責(zé)A需求的產(chǎn)品經(jīng)理分別跟前端和后端開發(fā)進(jìn)行了對應(yīng)的溝通，溝通之后繼續(xù)進(jìn)行迭代操作。
團(tuán)隊有自己的任務(wù)看板，任務(wù)板上內(nèi)容非常詳盡。按照設(shè)計、前端開發(fā)、后端開發(fā)、測試、聯(lián)調(diào)、部署、驗證，每一個泳道都有很多的內(nèi)容，站會就是在這個任務(wù)板前進(jìn)行的。
小明團(tuán)隊有一個慣例，要做測試用例的對應(yīng)評審。測試用例寫完之后，需要團(tuán)隊成員，包括前端開發(fā)、后端開發(fā)和產(chǎn)品一起做測試用例評審。小明為了節(jié)省團(tuán)隊的時間，對應(yīng)的開發(fā)、對應(yīng)的測試和對應(yīng)的產(chǎn)品，按照不同的模塊不同的功能分別參與測試用例的評審。
評審的方式非常簡單，由測試對測試用例進(jìn)行一些說明。在這個過程中出現(xiàn)了三種情況：
需求A：外部產(chǎn)生變更，但產(chǎn)品忘了跟測試說這件事，導(dǎo)致測試的測試用例出現(xiàn)的情況和實際開發(fā)了解到的情況是不一樣的。由于這個功能還沒有進(jìn)行測試，甚至還沒進(jìn)行提測。測試在聽完新的變更講解之后決定修改自己的測試用例。
需求B：聯(lián)調(diào)已經(jīng)完成，并且也進(jìn)行了正式的提測。測試用例進(jìn)行評審的時候，這個功能的準(zhǔn)備測試工作也已經(jīng)完成了，包括環(huán)境、各種測試用例都已經(jīng)準(zhǔn)備完成了。但是測試卻和開發(fā)的理解不太一致。在某一個邏輯上，開發(fā)和測試用例中表述的內(nèi)容產(chǎn)生了一些嚴(yán)重的偏差，產(chǎn)品經(jīng)理本身對測試用例的內(nèi)容也比較認(rèn)可。但是之前給團(tuán)隊寫的文檔模棱兩可，所以只能接受開發(fā)實現(xiàn)的邏輯，因為開發(fā)修改起來比較難。
需求C：本身比較復(fù)雜，已經(jīng)快進(jìn)入提測環(huán)節(jié)了，產(chǎn)品經(jīng)理一直想要把這個功能往后放。開發(fā)已經(jīng)開發(fā)了一部分，但還沒有進(jìn)行測試。產(chǎn)品要求先不著急做，于是……
“這個不做了”
“為啥”
“產(chǎn)品說不著急”
“那先做哪個？”
“先做這個和這個”
“行，那我就先準(zhǔn)備這兩個了”
測試用例評審之后，帶來的一個問題就是，開發(fā)和測試在測試用例評審會上，就產(chǎn)品、需求和功能進(jìn)行一個深度的討論。這個討論往往和最一開始會產(chǎn)生一些偏差，隨之而來的就是一部分優(yōu)先級要做對應(yīng)的取舍。究竟要舍棄哪個呢？這個動作有三項。
第一，??需求是誰提的？
第二，??需求的重要緊急程度？
第三，??這個任務(wù)當(dāng)前的執(zhí)行情況？
最終，在一片緊急重要且的優(yōu)先級中，找到一個感覺還可以進(jìn)行舍棄。決定之后，小明和團(tuán)隊進(jìn)行一個充分的溝通。
通過測試用例的變更，需求也對應(yīng)產(chǎn)生了一些調(diào)整，提測的時間也就進(jìn)行了相應(yīng)的后置。而迭代的周期到月底結(jié)束，上線也是在月底完成，測試的壓力就很大。
UAT測試，就是業(yè)務(wù)的驗收測試。UAT是小明公司上線之前業(yè)務(wù)方對完成的內(nèi)容進(jìn)行驗證的工作。UAT測試完成后上線，出現(xiàn)了各種各樣的問題。
這一切仿佛是敏捷的鍋。我們要是用傳統(tǒng)開發(fā)，就沒有這些問題了，一開始就會讓業(yè)務(wù)方簽字確認(rèn)。那么小明公司的現(xiàn)狀，真的是敏捷的鍋嗎？
他們執(zhí)行了敏捷的活動，但真是執(zhí)行了Scrum嗎？如何調(diào)整小明公司的狀態(tài)，才得以真正地執(zhí)行敏捷呢？
我們的開發(fā)是為了什么？
大家都知道，開發(fā)團(tuán)隊開發(fā)是為了交付價值。交付價值最明顯的方式就是上線，不上線的代碼毫無意義。
怎么樣才能讓代碼上線？以小明團(tuán)隊之前的流程來看，最后一步就是UAT。不通過業(yè)務(wù)的驗收測試是不能上線的。
開發(fā)是為了通過驗收測試嗎？
驗收測試是基于什么來進(jìn)行測試的呢？需求文檔？測試用例？
而大部分情況下，驗收測試會有自己配套的驗收測試用例。
驗收測試用例，才是開發(fā)應(yīng)該認(rèn)真對待，基于此做分析設(shè)計開發(fā)。
我們的開發(fā)是為了什么？那么答案就很明顯了，就是為了通過測試。
不是測試人員引領(lǐng)開發(fā)人員，而測試工作引領(lǐng)開發(fā)工作。
我們產(chǎn)品成功的標(biāo)準(zhǔn)是什么？公司是靠什么來盈利的？團(tuán)隊是靠什么來表證自己績效的？產(chǎn)品和技術(shù)是相輔相成，而不是相互制約的。
產(chǎn)品的上線時間是誰來決定的呢？就小明團(tuán)隊的這種開發(fā)方式，是開發(fā)決定的？還是業(yè)務(wù)決定的？
真正的產(chǎn)品什么時候上線，這次迭代能上線什么內(nèi)容，是由技術(shù)決定的。技術(shù)水平和技術(shù)瓶頸會直接制約產(chǎn)品上線的能力。所以，往往產(chǎn)品真正核心是它的價值和內(nèi)容，而影響我們的是技術(shù)。
我們?nèi)绾谓鉀Q這個問題呢？
最核心：讓價值交付代替功能交付。
確定完成價值之后，判斷優(yōu)先級。
優(yōu)先級的正確打開方式：MoSCoW原則
Must：必須有
Should：應(yīng)該有
Could：可以有
Won’t：不應(yīng)該有
M、S、C三檔究竟有什么意義呢？有兩大意義：
第一，M、S、C是對比出來的。
第二，可以在一次迭代內(nèi)進(jìn)行不一樣的劃分。在一次迭代內(nèi)，M最多只能有60%的工作量，Should20%，Could20%。既可以保證整個過程順利執(zhí)行，又可以保證收益達(dá)到最高。
當(dāng)我們確定了優(yōu)先級，確定了內(nèi)容。小明要做的就是，要讓他的團(tuán)隊可以做到獨(dú)立交付。也就是說，團(tuán)隊?wèi)?yīng)該包含了設(shè)計，開發(fā)，測試，項目經(jīng)理，產(chǎn)品經(jīng)理。只有做到這一點(diǎn)，我們才能真正地開始執(zhí)行敏捷，或者說真正地實現(xiàn)敏捷。
當(dāng)我們有了獨(dú)立的團(tuán)隊，接下來我們要想順利的執(zhí)行敏捷，要考慮的另一點(diǎn)，不要讓一個模塊只能一個人做。
如何解決“不要讓一個模塊只能一個人做”呢？給大家推薦一個方法，叫做“結(jié)對編程”。
如何執(zhí)行“結(jié)對編程”呢？我們可以采用一些優(yōu)秀的方法，類似于“老代新”，一個老同事代一個新同事，又類似于“技能復(fù)制”，A同學(xué)技能復(fù)制給B同學(xué)。
估算，排計劃是非常重要的。
如何避免工時估算造成的問題呢？
推薦方法：故事點(diǎn)估算，又叫對比估算。并且通過三個維度，進(jìn)行對比估算。
工作量
復(fù)雜程度
不確定性
為什么故事點(diǎn)估算會比工時估算更有效呢？
工時估算會帶著很強(qiáng)的個人屬性，技術(shù)成熟度和業(yè)務(wù)成熟度會對內(nèi)容產(chǎn)生很大的估算偏差。而故事點(diǎn)估算，是通過工作量、復(fù)雜程度和不確定性三個維度來進(jìn)行估算，對個人屬性相對地進(jìn)行了一些調(diào)整。
工時估算和故事點(diǎn)估算最大的區(qū)別是什么？
故事點(diǎn)估算可以非常好地去做預(yù)測。一個敏捷團(tuán)隊的優(yōu)秀與否并不看他單位時間完成的故事點(diǎn)的規(guī)模大小，而是看在單位時間內(nèi)，多次的單位時間內(nèi)，相同的單位時間內(nèi)團(tuán)隊完成的情況是否穩(wěn)定。故事點(diǎn)就是這個穩(wěn)定的單位。
敏捷管理中的看板也被廣泛使用。
從上面幾張圖，大家可以看出來，最大的問題出在了部署環(huán)節(jié)。部署環(huán)節(jié)是制約團(tuán)隊流動的真正瓶頸。所以，限制在制品起到的最好的作用，就是發(fā)現(xiàn)團(tuán)隊的瓶頸。
所有在部署環(huán)節(jié)出現(xiàn)的問題，我們就去解決部署。只要把部署解決，所有的條就可以流動。所以，優(yōu)化瓶頸才是最好的消除浪費(fèi)，而看板就是一種非常好的一種方式。
看板不是建立就可以，而是要使用起來才是真正的核心。
建立反饋機(jī)制，然后請說人話。
評什么？
l? DEMO
l? 所有可看出來的交付物，包括文檔
怎么評？
l? 基于故事的演示重點(diǎn)在驗收標(biāo)準(zhǔn)上（基于測試用例，盡量不要基于需求文檔）
l? 最好一個代表從頭演示到尾
結(jié)論如何？
l? 不需要出什么評審文檔，但是需要出來可用的版本給業(yè)務(wù)方
l? 不需要會議紀(jì)要，但是最好能留存下故事
l? PO需要對團(tuán)隊進(jìn)行評價，團(tuán)隊自己看看承諾的情況完成的如何
如果是Scrum團(tuán)隊，找一個PO，然后找一個SM?？梢岳斫鉃?，找一個團(tuán)隊的負(fù)責(zé)人，再找一個團(tuán)隊的管理者。需要強(qiáng)調(diào)的一點(diǎn)是，無論是PO還是SM，都是對于團(tuán)隊所講的。
敏捷和小瀑布，并沒有誰優(yōu)誰劣。在不同的環(huán)境內(nèi)，不同的場景內(nèi)，使用最合適的方法才是最好的。?END
陪你前進(jìn)每一步
“?Walk you every step of the way.”
本文作者 / 王歡
發(fā)布 / 敏捷視界
未經(jīng)允許，禁止轉(zhuǎn)載
每當(dāng)我迷失在黑夜里
您就像夜空中最亮的星
不斷指引我前行
感謝老師的栽培和引導(dǎo)
幫助我從困惑中頓悟
在彷徨中相信，在焦慮中堅持
教師節(jié)馬上來臨，畫一幅畫作
送給你心目中最美的老師吧
我們會在教師節(jié)當(dāng)天發(fā)布中獎?wù)呙麊闻秪
點(diǎn)擊閱讀原文，也可以參與活動哦~
閱讀?767
?在看4
寫下你的留言
