背景

最近我去一家科技公司做敏捷咨詢(xún)荠割，通過(guò)梳理該公司的研發(fā)過(guò)程妹卿，發(fā)現(xiàn)了該公司的研發(fā)過(guò)程中許多可以改進(jìn)的地方，于是我便記錄下來(lái)，與大家分享學(xué)習(xí)夺克。

本文會(huì)剖析該公司的研發(fā)過(guò)程箕宙，把每個(gè)環(huán)節(jié)詳細(xì)分析一遍，以找出研發(fā)過(guò)程中的問(wèn)題和可以改進(jìn)的地方铺纽。然后再講解如何做敏捷改造扒吁。

研發(fā)過(guò)程分析

全景圖

下圖是該公司的研發(fā)全景圖，從時(shí)間線來(lái)看室囊，上面一條時(shí)間線可以看出整個(gè)需求流轉(zhuǎn)的生命周期雕崩，下面一條時(shí)間線可以看出整個(gè)代碼流轉(zhuǎn)的生命周期。

全景圖

下面我們就把每個(gè)環(huán)節(jié)拆開(kāi)來(lái)仔細(xì)分析一下融撞。

需求管理

現(xiàn)狀

現(xiàn)在是通過(guò)共享Excel來(lái)管理所有的需求盼铁，業(yè)務(wù)方在表格里面填寫(xiě)想要的需求，包括新需求或bug等尝偎，并為每個(gè)需求生成一個(gè)序號(hào)方便追蹤饶火。

大概長(zhǎng)下圖的樣子。這是非常典型的傳統(tǒng)需求管理方式致扯。

需求管理

問(wèn)題

1. 大顆粒的需求可以這樣管理肤寝，但是不能所有階段都這樣管理，會(huì)造成需求粒度太大抖僵，細(xì)節(jié)太多鲤看，邊界太模糊。
2. 如果不做story拆分耍群，這樣的需求離能開(kāi)發(fā)還有很多空間义桂，需要做拆分、細(xì)化蹈垢、轉(zhuǎn)化慷吊，最后才能開(kāi)發(fā)。
3. 這樣的需求表格缺乏很多細(xì)節(jié)曹抬，比如UI長(zhǎng)什么樣子溉瓶，某個(gè)業(yè)務(wù)邏輯有多少條分支等。
4. 這樣的表格無(wú)法知道業(yè)務(wù)方和研發(fā)方對(duì)需求的理解是否一致谤民，很容易出現(xiàn)返工堰酿。
5. 此類(lèi)表格管理需求，不便于業(yè)務(wù)方追蹤需求進(jìn)度和狀態(tài)赖临，以及可視化需求的轉(zhuǎn)化過(guò)程胞锰。

需求評(píng)審

現(xiàn)狀

產(chǎn)品經(jīng)理會(huì)和業(yè)務(wù)方一起開(kāi)會(huì)，針對(duì)表格里面的某個(gè)需求兢榨，來(lái)確定這個(gè)需求的細(xì)節(jié)，以及怎么做。確保雙方的理解是一致的吵聪。

問(wèn)題

1. 需求評(píng)審會(huì)的時(shí)候沒(méi)有記錄過(guò)程中確認(rèn)的結(jié)論凌那，導(dǎo)致會(huì)后大家又忘記當(dāng)時(shí)的結(jié)論是什么。
2. 由于需求粒度過(guò)大吟逝，很多細(xì)節(jié)無(wú)法詳盡的確認(rèn)清楚帽蝶，容易導(dǎo)致返工。
3. 由于需求粒度過(guò)大块攒，需要比較長(zhǎng)的時(shí)間來(lái)完成需求評(píng)審励稳，通常會(huì)花2小時(shí)以上。
4. 沒(méi)有sign off囱井，無(wú)法判定需求是否通過(guò)了業(yè)務(wù)方的認(rèn)可驹尼。
5. 需求澄清是一個(gè)隨時(shí)隨地的動(dòng)作，但該公司缺乏能隨時(shí)做需求澄清的氛圍或文化庞呕。

產(chǎn)品設(shè)計(jì)

現(xiàn)狀

拿到需求后新翎，產(chǎn)品經(jīng)理會(huì)根據(jù)需求以及和業(yè)務(wù)方的溝通，達(dá)成一致后開(kāi)始設(shè)計(jì)產(chǎn)品文檔住练，把需求涉及到的原型圖地啰，業(yè)務(wù)邏輯等全部畫(huà)到產(chǎn)品文檔上，以提供給開(kāi)發(fā)人員進(jìn)行開(kāi)發(fā)讲逛。

問(wèn)題

1. 需求通常都很大亏吝，產(chǎn)品經(jīng)理很少把需求拆分成story，也很少在JIRA等工具上拆卡建卡來(lái)管理所有的需求盏混。導(dǎo)致產(chǎn)品設(shè)計(jì)周期很長(zhǎng)顺呕，細(xì)節(jié)很多，無(wú)法一次性考慮全面括饶。
2. 產(chǎn)品經(jīng)理設(shè)計(jì)產(chǎn)品文檔的時(shí)候株茶，通常是自己設(shè)計(jì)，設(shè)計(jì)好了再給業(yè)務(wù)方或者開(kāi)發(fā)看图焰。沒(méi)有頻繁反饋和需求澄清启盛，導(dǎo)致需求可能被腦補(bǔ)，并不是業(yè)務(wù)方想要的技羔。
3. 產(chǎn)品文檔目前是用版本管理工具來(lái)管理的僵闯，比如git，不便與查找和歸檔藤滥。
4. 需求鳖粟、產(chǎn)品文檔、代碼沒(méi)有關(guān)聯(lián)關(guān)系拙绊，不方便后期查找某個(gè)需求相關(guān)的產(chǎn)品文檔和代碼向图。

技術(shù)評(píng)審

現(xiàn)狀

目前泳秀，產(chǎn)品經(jīng)理設(shè)計(jì)完成后，會(huì)拉上開(kāi)發(fā)和業(yè)務(wù)一起進(jìn)行技術(shù)評(píng)審榄攀，確保設(shè)計(jì)的產(chǎn)品文檔三方能達(dá)成一致嗜傅。

問(wèn)題

1. 由于需求太大，評(píng)審時(shí)間太長(zhǎng)檩赢，通常超過(guò)2小時(shí)吕嘀，久而久之大家會(huì)越來(lái)越反感這樣的評(píng)審會(huì)議，并且會(huì)議后期大家的注意力也不集中了贞瞒。
2. 細(xì)節(jié)太多偶房，容易忽略某些細(xì)節(jié)，導(dǎo)致最后開(kāi)發(fā)依然有不確定的開(kāi)發(fā)細(xì)節(jié)军浆，并且開(kāi)發(fā)的結(jié)果和業(yè)務(wù)方的期望不匹配棕洋。

開(kāi)發(fā)

現(xiàn)狀

拿到產(chǎn)品文檔之后，后端會(huì)根據(jù)文檔中的業(yè)務(wù)邏輯瘾敢，開(kāi)發(fā)完成服務(wù)端的功能拍冠，前端會(huì)根據(jù)文檔中的原型圖或者高保真UI設(shè)計(jì)圖，開(kāi)發(fā)完成客戶(hù)端的功能簇抵。

再來(lái)說(shuō)說(shuō)該公司的分支管理模式庆杜。

他們把分支分為了：線上分支（master），測(cè)試分支（stable）碟摆，開(kāi)發(fā)分支（dev）等晃财。

保證不同的分支做不同的事情，防止分支污染典蜕。

1. 線上分支（master）：是預(yù)上線環(huán)境和線上環(huán)境的分支断盛，以這個(gè)分支為準(zhǔn)，其他分支都是以這個(gè)分支為基礎(chǔ)拉取愉舔。
2. 測(cè)試分支（stable）：測(cè)試環(huán)境分支钢猛，是給測(cè)試團(tuán)隊(duì)測(cè)試使用，如果有些功能在本地及開(kāi)發(fā)不容易測(cè)試轩缤，開(kāi)發(fā)人員可以到測(cè)試分支進(jìn)行自測(cè)命迈。
3. 開(kāi)發(fā)分支（dev）：開(kāi)發(fā)人員自測(cè)。

分支命名規(guī)范：姓名+需求名+日期

分支會(huì)根據(jù)上線需要火的，merge到stable進(jìn)行測(cè)試壶愤，或者merge到master進(jìn)行上線。如下圖馏鹤。

分支管理

問(wèn)題

1. 分支管理混亂征椒，每個(gè)分支既可能合并到dev，也可能合并到master湃累，原因是因?yàn)檫@樣可以解決僅部分功能要上線的問(wèn)題勃救，哪個(gè)功能要上線碍讨，就合并哪個(gè)分支到master。
   1. 理論上剪芥，拉了分支開(kāi)發(fā)的代碼都是應(yīng)該要上線的垄开，不上線的代碼會(huì)浪費(fèi)開(kāi)發(fā)資源琴许。
   2. 分支開(kāi)發(fā)的時(shí)間也不應(yīng)該太長(zhǎng)税肪，太長(zhǎng)會(huì)導(dǎo)致代碼沖突變嚴(yán)重，回滾成本變高榜田。
   3. 如果是因?yàn)闇y(cè)試沒(méi)做完而暫時(shí)不上線益兄，那可能是因?yàn)榉种淼墓δ芰６忍罅耍瑴y(cè)試時(shí)間太長(zhǎng)箭券，應(yīng)該從源頭開(kāi)始拆解需求净捅。
   4. 如果是因?yàn)闃I(yè)務(wù)變更而暫時(shí)不上線，應(yīng)該使用feature toggle來(lái)解決辩块。
2. 功能分支雖然寫(xiě)了開(kāi)發(fā)者名字和需求名蛔六，但依然很難關(guān)聯(lián)具體的需求是哪一個(gè)。
3. 雖然規(guī)定了從master拉取分支废亭，但大家有的從dev拉取国章，有的從stable拉取，沒(méi)有統(tǒng)一規(guī)范豆村。
4. 分支命名中的日期意義不大液兽，因?yàn)榉种Ю碚撋洗嬖诘臅r(shí)間應(yīng)該盡量短，才能避免更多的沖突掌动，減少review的工作量四啰，以及減少回滾的成本。其次分支拉出來(lái)的時(shí)間在git上都能清晰的看到粗恢。
5. 開(kāi)發(fā)很少做需求澄清柑晒，會(huì)按照自己的想法實(shí)現(xiàn)某個(gè)需求，遇到不確定的地方?jīng)]有和團(tuán)隊(duì)討論眷射，沒(méi)有找產(chǎn)品匙赞、業(yè)務(wù)確認(rèn)。會(huì)導(dǎo)致最終實(shí)現(xiàn)和業(yè)務(wù)方的期望不匹配凭迹。
6. 沒(méi)有code review罚屋，無(wú)法統(tǒng)一開(kāi)發(fā)團(tuán)隊(duì)成員對(duì)代碼的規(guī)范，無(wú)法及時(shí)發(fā)現(xiàn)代碼中的問(wèn)題嗅绸，無(wú)法做代碼層面的知識(shí)傳遞脾猛。
7. 沒(méi)有寫(xiě)單元測(cè)試，無(wú)法做到研發(fā)自測(cè)與質(zhì)量?jī)?nèi)建鱼鸠，無(wú)法保證代碼的正確性猛拴，無(wú)法保證其他人不會(huì)破壞原有代碼功能羹铅，無(wú)法持續(xù)集成。
8. 沒(méi)有CI/CD愉昆，無(wú)法及時(shí)獲取反饋职员，無(wú)法快速部署，無(wú)法快速發(fā)現(xiàn)問(wèn)題跛溉。

提交測(cè)試

現(xiàn)狀

開(kāi)發(fā)完成開(kāi)發(fā)工作之后焊切，自己測(cè)試通過(guò)了之后，會(huì)交給測(cè)試人員進(jìn)行測(cè)試芳室。測(cè)試人員在提測(cè)之前會(huì)根據(jù)產(chǎn)品文檔先寫(xiě)測(cè)試用例专肪。

問(wèn)題

1. 提測(cè)的過(guò)程靠口頭傳遞，測(cè)試人員無(wú)法可視化的知道開(kāi)發(fā)進(jìn)度堪侯，做了哪些改動(dòng)嚎尤，可以部署哪個(gè)環(huán)境，使用哪個(gè)版本伍宦。

測(cè)試

現(xiàn)狀

測(cè)試會(huì)根據(jù)寫(xiě)好的測(cè)試用例對(duì)功能進(jìn)行測(cè)試芽死，如果發(fā)現(xiàn)問(wèn)題，會(huì)返回給開(kāi)發(fā)次洼，讓開(kāi)發(fā)修復(fù)关贵。

問(wèn)題

1. 測(cè)試用例目前是用單獨(dú)的工具來(lái)管理，沒(méi)有和需求關(guān)聯(lián)起來(lái)滓玖。
2. 測(cè)試完成之后坪哄，沒(méi)有對(duì)業(yè)務(wù)方的showcase，無(wú)法獲取業(yè)務(wù)方的驗(yàn)收反饋势篡。

上線

現(xiàn)狀

每個(gè)需求基本上都包含了前后端翩肌，因此會(huì)等前后端都開(kāi)發(fā)測(cè)試完成后，再一起做上線禁悠。

問(wèn)題

1. 上線內(nèi)容比較多念祭，一旦出了問(wèn)題，會(huì)導(dǎo)致回滾成本比較高碍侦，定位問(wèn)題比較慢粱坤。
2. 上線時(shí)間比較慢，不能讓業(yè)務(wù)方快速看到最終的功能瓷产。

總結(jié)

這樣的研發(fā)過(guò)程梳理完了之后站玄，會(huì)發(fā)現(xiàn)其實(shí)這樣的過(guò)程就是我們俗稱(chēng)的小瀑布。它的特點(diǎn)是相比傳統(tǒng)的瀑布模式它更輕量級(jí)濒旦，但相比敏捷株旷，它又更重量級(jí)。目前很多公司都在采用這樣的小瀑布模式。

• 小瀑布模式的缺點(diǎn)在于它的溝通成本晾剖、等待成本锉矢、返工成本依然很高，還有可以?xún)?yōu)化的空間齿尽。
• 同時(shí)整個(gè)過(guò)程中沽损，需求評(píng)審、技術(shù)評(píng)審循头、用例評(píng)審都做得比較重绵估，每次評(píng)審的內(nèi)容都非常多，時(shí)間非常長(zhǎng)贷岸，細(xì)節(jié)非常多壹士。
• 整個(gè)過(guò)程中的所有產(chǎn)出物并沒(méi)有明確的關(guān)聯(lián)關(guān)系磷雇，也沒(méi)有統(tǒng)一的管理工具和存儲(chǔ)位置偿警，隨著時(shí)間的推移，所有知識(shí)管理將變得越來(lái)越難唯笙，新人的學(xué)習(xí)成本將變得越來(lái)越高螟蒸。軟件項(xiàng)目中的信息量會(huì)在潛移默化中變成異常高的復(fù)雜度。
• 環(huán)節(jié)與環(huán)節(jié)之間沒(méi)有文字記錄明確一個(gè)環(huán)節(jié)的結(jié)束與開(kāi)始崩掘，比如開(kāi)發(fā)到測(cè)試七嫌。基本上是靠成員之間的口頭傳遞苞慢。
• 最后還發(fā)現(xiàn)該公司不是全功能團(tuán)隊(duì)模式诵原，而是按角色分的，一個(gè)角色可能會(huì)同時(shí)負(fù)責(zé)幾個(gè)項(xiàng)目挽放，比如A開(kāi)發(fā)上午在寫(xiě)X項(xiàng)目的代碼绍赛，下午可能在寫(xiě)Y項(xiàng)目的代碼了。

根據(jù)這些現(xiàn)狀問(wèn)題辑畦，具體怎么改造吗蚌，將在下篇來(lái)具體講解。