上篇分析了我做過(guò)的一個(gè)真實(shí)的項(xiàng)目的研發(fā)過(guò)程中的種種問(wèn)題州丹，那么這篇就來(lái)講解一下我們?nèi)绾吾槍?duì)這些問(wèn)題做敏捷改造封豪。
怎樣用敏捷做改進(jìn)
小瀑布模式的缺點(diǎn)在于它的溝通成本褥影、等待成本飒筑、返工成本依然很高渤涌，因此我們可以考慮從這3個(gè)角度出發(fā)去做改進(jìn)佩谣。
我畫(huà)了一個(gè)圖來(lái)展示小瀑布模式和敏捷開(kāi)發(fā)的詳細(xì)對(duì)比。
圖中紫色管道是小瀑布模式实蓬，藍(lán)色管道是敏捷開(kāi)發(fā)茸俭，兩個(gè)管道是相同的團(tuán)隊(duì)管道容量，換句話說(shuō)，兩種模式的工作載量是相等的。
橫向是時(shí)間線卦尊，從左到右，按需求提出開(kāi)始直到此需求上線腾窝，即為此需求的生命周期。
首先，先說(shuō)一下為什么這3個(gè)成本很高虹脯。
溝通成本
產(chǎn)品經(jīng)理通常需要1-2小時(shí)來(lái)與業(yè)務(wù)方進(jìn)行需求溝通驴娃，溝通完了之后，產(chǎn)品經(jīng)理會(huì)有一個(gè)初步方案归形，然后會(huì)與團(tuán)隊(duì)內(nèi)部的技術(shù)人員托慨，測(cè)試人員等，一起評(píng)審這個(gè)需求暇榴，如果這中間有任何疑問(wèn)厚棵，產(chǎn)品經(jīng)理就需要不停的反復(fù)在業(yè)務(wù)方與技術(shù)人員中間進(jìn)行溝通。因此溝通成本是比較高的蔼紧。
產(chǎn)品經(jīng)理通常也需要1-2小時(shí)來(lái)與技術(shù)人員一起做技術(shù)評(píng)審婆硬，時(shí)間比較長(zhǎng)，很多問(wèn)題細(xì)節(jié)需要來(lái)回反復(fù)確認(rèn)奸例，溝通成本很高彬犯。
總結(jié)一下就是，由于需求粒度比較大查吊，每個(gè)環(huán)節(jié)都比較重谐区，有大量的細(xì)節(jié)需要討論和確認(rèn)，因此帶來(lái)了較高的溝通成本逻卖。
等待成本
開(kāi)發(fā)只有等產(chǎn)品文檔完全設(shè)計(jì)好了宋列，才能開(kāi)始開(kāi)發(fā)，由于需求粒度過(guò)大评也，此設(shè)計(jì)過(guò)程相對(duì)過(guò)長(zhǎng)炼杖，因此開(kāi)發(fā)的等待時(shí)間也長(zhǎng)，沒(méi)有充分利用開(kāi)發(fā)資源盗迟。
同理坤邪，測(cè)試也是，只有等開(kāi)發(fā)提測(cè)了才能做測(cè)試罚缕。但測(cè)試在此之前艇纺，會(huì)先寫(xiě)測(cè)試用例，因此測(cè)試資源浪費(fèi)還算較小怕磨。
但另外一個(gè)問(wèn)題是喂饥，測(cè)試一次性要寫(xiě)非常多的用例測(cè)試，一次性測(cè)那么多用例肠鲫，測(cè)試的完整性完全依賴(lài)于測(cè)試人員的耐心。
返工成本
測(cè)試如果發(fā)現(xiàn)問(wèn)題或粮，會(huì)讓開(kāi)發(fā)返工导饲，由于需求粒度比較大，經(jīng)常出現(xiàn)測(cè)試發(fā)現(xiàn)多個(gè)問(wèn)題的情況，那么就會(huì)來(lái)回的多次返工與測(cè)試渣锦。
甚至有時(shí)候返工會(huì)直接返到業(yè)務(wù)方去重新確認(rèn)需求的細(xì)節(jié)硝岗。
敏捷研發(fā)過(guò)程改進(jìn)
那么敏捷是如何改進(jìn)這個(gè)過(guò)程的呢？
首先敏捷是提倡小步快跑袋毙，擁抱變化型檀。目前由于需求粒度比較大，無(wú)法小步快跑听盖，同時(shí)開(kāi)發(fā)到中間的時(shí)候的胀溺，需求突然變化，應(yīng)對(duì)起來(lái)也比較慢皆看。
那我們就可以根據(jù)下圖來(lái)進(jìn)行改造仓坞。
上圖中最大的變化就是把原來(lái)的需求A拆解成了3個(gè)story。
敏捷提倡小步快跑腰吟，那么管理需求也一樣无埃，只有需求足夠小，才更利于我們快速理解和分析毛雇。而user story（用戶故事）則是敏捷里面的一個(gè)可以工作的最小單位嫉称。
用戶故事在軟件開(kāi)發(fā)過(guò)程中被作為描述需求的一種表達(dá)形式；為了規(guī)范用戶故事的表達(dá)灵疮，便于溝通织阅；包含角色、活動(dòng)始藕、價(jià)值三個(gè)要素蒲稳。
瀑布式的需求管理和敏捷需求管理的區(qū)別在于：
- 瀑布式的需求分析要求在一開(kāi)始就獲取所有需求，分析所有細(xì)節(jié)伍派，并且假設(shè)我們可以對(duì)軟件項(xiàng)目有個(gè)完美的預(yù)測(cè)江耀。
- 而用戶故事則基于我們不能完美預(yù)測(cè)，不能在一開(kāi)始就知道所有細(xì)節(jié)的基礎(chǔ)诉植。因?yàn)槲覀儗?duì)需求的理解是一個(gè)逐漸清晰的過(guò)程祥国。同時(shí)，在項(xiàng)目開(kāi)始時(shí)嘗試編寫(xiě)所有的需求忽略了重要的反饋循環(huán)晾腔。用戶故事承認(rèn)故事的時(shí)間維度舌稀，隨著時(shí)間的推移以及功能的增加，會(huì)有新的用戶故事產(chǎn)生灼擂，或者使故事的相關(guān)性發(fā)生變化壁查。所以要延遲細(xì)節(jié)，融入業(yè)務(wù)到整個(gè)軟件開(kāi)發(fā)過(guò)程中剔应，鼓勵(lì)交流和溝通睡腿。
- 另外语御，做了用戶故事拆分之后，產(chǎn)品經(jīng)理或者BA需要補(bǔ)全細(xì)節(jié)席怪，不停的做需求澄清应闯，和業(yè)務(wù)方做sign off。
- 敏捷需求管理會(huì)借助JIRA等工具進(jìn)行可視化的看板或者scrum管理挂捻。而不是基于傳統(tǒng)的Excel管理碉纺。
- 每個(gè)故事寫(xiě)好之后，會(huì)讓業(yè)務(wù)方做card sign off刻撒，比如在卡下面留言ready to go等骨田。如果每張卡做sign off太頻繁，可以由產(chǎn)品經(jīng)理或BA單獨(dú)找業(yè)務(wù)方用郵件等的形式針對(duì)一個(gè)epic統(tǒng)一做sign off疫赎。
- 敏捷里其實(shí)沒(méi)有一個(gè)專(zhuān)門(mén)給業(yè)務(wù)方和產(chǎn)品經(jīng)理/BA的需求澄清會(huì)盛撑，因?yàn)槟J(rèn)為已經(jīng)發(fā)生在日常工作中了，按理說(shuō)應(yīng)該分析一張卡確認(rèn)一張卡捧搞，才能盡可能減少因一張卡片理解不到位引起的大面積返工抵卫。
拆解成小的用戶故事之后有如下一些好處：
- 原來(lái)產(chǎn)品經(jīng)理和業(yè)務(wù)方的溝通成本隨著需求被拆成小的用戶故事而變小了。
- 由于用戶故事比較小胎撇，分析完成的時(shí)間就變快了介粘，產(chǎn)品設(shè)計(jì)的時(shí)間也變快了，那么開(kāi)發(fā)開(kāi)始的時(shí)間也就變快了晚树，減少了等待成本姻采。
- 由于開(kāi)發(fā)時(shí)間更短，第一個(gè)用戶故事測(cè)試時(shí)間也就提前了爵憎，因此如果出現(xiàn)問(wèn)題需要返工慨亲，那么返工的時(shí)間比原來(lái)就更早，返工修改的內(nèi)容也更少宝鼓，能較快的完成返工并重新測(cè)試刑棵。整體返工成本就變小了。
- 由于各方時(shí)間都提前了愚铡，那么第一個(gè)用戶故事上線的時(shí)間也提前了蛉签，業(yè)務(wù)方就能更早的看到需求的部分功能，就能更早的反饋問(wèn)題沥寥。
- 由于每個(gè)環(huán)節(jié)的溝通成本碍舍，等待成本，返工成本均減少了邑雅，因此整個(gè)需求的交付時(shí)間也就提前了片橡。
從下圖就可以看出，每個(gè)環(huán)節(jié)相比之前都是提前的淮野。敏捷的目的是能夠讓團(tuán)隊(duì)擁抱變化锻全，快速響應(yīng)狂塘。
敏捷開(kāi)發(fā)改進(jìn)
分支改進(jìn)
原來(lái)的分支管理比較混亂录煤，可能造成的問(wèn)題已經(jīng)在前面分析過(guò)了鳄厌。
這里就說(shuō)說(shuō)分支管理的最佳實(shí)踐是什么。
- 現(xiàn)在業(yè)界普遍都采用了git flow妈踊，具體怎么做可以Google一下了嚎，網(wǎng)上有太多文章講這個(gè)，我就不贅述了廊营。這里就展示一張git flow的全景圖歪泳。
-
每次git的commit message的推薦格式：[Card ID][Type]: message
- Type主要有：feature, refactor, fix等。
- 每次git的commit推薦能關(guān)聯(lián)到每個(gè)故事卡的卡號(hào)露筒，這樣方便追溯每個(gè)故事卡相關(guān)的改動(dòng)∧派。現(xiàn)在很多工具都支持通過(guò)message的卡號(hào)直接找到對(duì)應(yīng)的故事卡，反之亦然慎式。
CI/CD
- 從代碼的生命周期開(kāi)始伶氢，CI/CD是保證每個(gè)環(huán)節(jié)快速流轉(zhuǎn)的基礎(chǔ)，同時(shí)也是快速獲取反饋的途徑瘪吏。
- 而CI的基礎(chǔ)則是自動(dòng)化測(cè)試癣防，比如最基本的單元測(cè)試。
- 每完成一張故事卡掌眠，理論上都可以持續(xù)部署到生產(chǎn)環(huán)境蕾盯。而不應(yīng)該等待所有需求都完成了，或者等前后端都完成了蓝丙，再做上線部署级遭。
- 部署的步子越小，回滾的成本也就越低渺尘。
總結(jié)
圖里的敏捷開(kāi)發(fā)一定比上面的小瀑布快嗎挫鸽？不一定，這里還有幾個(gè)因素是需要考慮的沧烈。
- 需求A拆解成story是有成本的掠兄。根據(jù)產(chǎn)品經(jīng)理或BA的能力不同，以及需求復(fù)雜度的不同锌雀，拆卡花的時(shí)間也不同蚂夕。
- 小瀑布模式里面，在沒(méi)有bug的情況下只會(huì)測(cè)試一次腋逆。在敏捷模式下婿牍，相比原來(lái)的小瀑布，會(huì)針對(duì)story1和story2做回歸測(cè)試惩歉。因此增加了測(cè)試時(shí)間等脂。
- 另外俏蛮，決定敏捷開(kāi)發(fā)能否運(yùn)行很好的因素還有很多，只有不斷探尋最佳實(shí)踐上遥，持續(xù)改進(jìn)搏屑，才能無(wú)限逼近我們期望的狀態(tài)。
總結(jié)起來(lái)粉楚，敏捷是通過(guò)小步快跑的方式辣恋，提升了響應(yīng)變化的速度，以達(dá)到提升整體交付速度與質(zhì)量的目的模软。
本文只是通過(guò)一個(gè)真實(shí)的客戶案例伟骨，來(lái)分析如何基于當(dāng)前現(xiàn)狀做敏捷改造，本文并沒(méi)有寫(xiě)完全部敏捷改造的內(nèi)容燃异，因?yàn)槊艚莅膬?nèi)容實(shí)在太多了携狭，如果大家感興趣可以給我留言，后面我會(huì)繼續(xù)分享這個(gè)案例中涉及到的其他敏捷改造回俐。
