這篇文章來源于一段真實(shí)的經(jīng)歷：
我的一位朋友曾經(jīng)和我講起他的擔(dān)憂：這位朋友白手起家，現(xiàn)在管理的軟件公司已經(jīng)有三十多人。因?yàn)闅v史的原因，公司的開發(fā)一直比較混亂。代碼管理問題，版本丟失和沖突經(jīng)常出現(xiàn)。測(cè)試沒法做得很好。給客戶交付的軟件質(zhì)量都很讓人擔(dān)心。計(jì)劃之類基本上也都是靠拍腦袋。他問我：怎么才能開始讓公司有一套比較完善的開發(fā)流程？哪個(gè)流程比較適合他們呢？
各位讀者大人，你們碰到過這樣的事情嗎？最終又是怎么做的呢？
在這篇文章里，我將和大家分享我們?cè)谶@個(gè)具體案例上是怎么做的。這些做法很可能也適用于你身邊的情況，因?yàn)楹芏嘬浖髽I(yè)也都經(jīng)歷過這樣的陣痛與轉(zhuǎn)型。這也是為什么我推薦大家看完這篇文章的原因。
我們?cè)谶@個(gè)案例中的做法是基于以下的考慮（事實(shí)上這些觀點(diǎn)的正確性也在后面的實(shí)踐中得到了驗(yàn)證）：
- 流程改進(jìn)要切忌生搬硬套或者用力過猛，需要結(jié)合自身情況進(jìn)行漸進(jìn)式的改善。
- 先列出需要解決的痛點(diǎn)，首先思考如何通過一些工具或者流程來解決這些痛點(diǎn)，然后再來思考大的流程。
- 流程改進(jìn)需要有優(yōu)先級(jí)，很多事情同時(shí)進(jìn)行，不一定能兼顧得過來。
- 在實(shí)踐中總結(jié)和觀察改進(jìn)的效果。并不斷修正。
列出需要解決的痛點(diǎn)
痛點(diǎn)有很多。我們采取的方法是首先和老板和幾個(gè)經(jīng)理聊了一下，了解他們眼里的問題。之后又和員工開了幾次頭腦風(fēng)暴，最后把這些問題總結(jié)出來大體如下：
- 項(xiàng)目估算時(shí)，每個(gè)人說法都不一致，吵來吵去最后只好拍腦袋。
- 需求了解不清楚，有時(shí)候開發(fā)了好長(zhǎng)時(shí)間的功能，突然在溝通中發(fā)現(xiàn)根本不是客戶想要的。只能重做。
- 團(tuán)隊(duì)溝通也有問題，比如項(xiàng)目客戶說一個(gè)事情，可能項(xiàng)目經(jīng)理和不同的人說，最后每個(gè)人說法都不一樣了，而且有時(shí)候項(xiàng)目經(jīng)理自己都忘了是怎么回事。
- 開發(fā)缺乏設(shè)計(jì)，經(jīng)常做到中間才發(fā)現(xiàn)需要推倒重來。
- 代碼缺乏規(guī)范，可讀性也差，一個(gè)人寫的代碼，另外一個(gè)人很難看懂。
- 因?yàn)榇a的問題，有時(shí)候一個(gè)開發(fā)工程師辭職了，整個(gè)項(xiàng)目要受到很大影響。
- 測(cè)試不充分：因?yàn)闀r(shí)間不足，很多測(cè)試不夠全面。而且測(cè)試組人手有限，代碼修改頻繁，也很難一遍又一遍做回歸測(cè)試。
- 項(xiàng)目缺乏可追蹤性和可預(yù)測(cè)性：每個(gè)人對(duì)項(xiàng)目做了多少，還需要多久都有自己的看法，有時(shí)候觀點(diǎn)差異很大。
- 工作缺乏計(jì)劃性，每個(gè)人都很忙，開發(fā)忙著寫代碼，改bug，測(cè)試忙著一遍又一遍測(cè)試，效果卻不大好。
- 質(zhì)量無法控制，同一個(gè)bug經(jīng)常反復(fù)出現(xiàn)，改了一個(gè)bug又可能引起了新的bug
- 客戶那里，最后發(fā)布的產(chǎn)品時(shí)間經(jīng)常達(dá)不到逾期，而且出了很多質(zhì)量問題。
這些問題，也許讀者大人們會(huì)很熟悉，因?yàn)檫@幾乎也是發(fā)生在許多軟件公司的事情。而這，也是為我們說這篇文章里的實(shí)踐具有借鑒意義的重要原因。
事實(shí)上除了這些，我們所記錄的痛點(diǎn)還有很多，比如很多員工抱怨知識(shí)得不到更新升級(jí)之類，但是因?yàn)楸疚钠?，我們僅列出了比較重要也比較有共性的一些點(diǎn)。
確定改進(jìn)目標(biāo)和優(yōu)先級(jí)
問題有很多。不過就像我們之前指出的那樣，人的精力是有限的。在這種情況下，總結(jié)出一些重要的改進(jìn)目標(biāo)并排出優(yōu)先級(jí)就很必要了。
我們總結(jié)出的改進(jìn)目標(biāo)如下：
- 改進(jìn)需求管理和客戶溝通，以避免因需求導(dǎo)致的返工和推倒重來的現(xiàn)象。同時(shí)盡力細(xì)化需求以改進(jìn)估算。
- 加強(qiáng)產(chǎn)品質(zhì)量管理，包括測(cè)試流程再定義，推進(jìn)版本管理和配置管理等。
- 改善團(tuán)隊(duì)協(xié)作
- 增強(qiáng)代碼質(zhì)量和設(shè)計(jì)優(yōu)化
上面的排序就是優(yōu)先級(jí)的排序，越往前的目標(biāo)優(yōu)先級(jí)越高。
有一些朋友可能會(huì)問：這種優(yōu)先級(jí)的排序是否合理呢？ 比如代碼質(zhì)量難道不重要？其實(shí)這只是基于當(dāng)時(shí)這家公司的具體情況作出的考慮。需求和產(chǎn)品質(zhì)量對(duì)于一個(gè)小公司來說幾乎是致命的因素。如果不能做出客戶想要的產(chǎn)品，或者產(chǎn)品質(zhì)量影響了客戶使用，那么這家公司隨時(shí)可能受到毀滅性的打擊。因此我們把他們排列在了前兩位。
漸進(jìn)式改進(jìn)
流程改進(jìn)表
確定了流程改進(jìn)的目標(biāo)和優(yōu)先級(jí)。我們開始指定具體的改進(jìn)策略和步驟。我們?cè)诰唧w實(shí)踐中使用了一種叫做流程改進(jìn)表的表格，以方便公司所有人了解我們要怎么做。
下面就是一個(gè)流程改進(jìn)表的實(shí)例：
| 要解決的問題 | 具體如何改進(jìn) | 涉及到的人 |
|---|---|---|
| 前期需求過于抽象，有時(shí)候客戶不知道自己想要什么 | 在需求階段就通過poc之類快速做出原型讓用戶有直觀印象 | 項(xiàng)目經(jīng)理，開發(fā) |
因?yàn)楸砀窭锏膬?nèi)容字?jǐn)?shù)較多，讀者大人們用手機(jī)觀看時(shí)閱讀體驗(yàn)不大好，所以在下文我們不再展示實(shí)踐中所用具體的表格，而是把表格里的內(nèi)容以文字或者列表的形式展現(xiàn)出來。
用表格有什么好處呢？一是簡(jiǎn)明，二是便于張貼和傳播，三是便于日后反饋和追蹤。我也推薦您在類似的工作中試一下，效果應(yīng)該會(huì)很不錯(cuò)的。
好了，說完了形式化的流程改進(jìn)表。讓我們步入正題，說一說具體進(jìn)行哪些方面的流程改進(jìn)。
流程改進(jìn)之需求分析
每個(gè)軟件團(tuán)隊(duì)都會(huì)進(jìn)行需求分析，也幾乎每個(gè)團(tuán)隊(duì)都在需求上吃過虧。好的需求分析工作往往能讓后續(xù)的設(shè)計(jì)和開發(fā)事半功倍，而不好的需求分析則可以讓一個(gè)項(xiàng)目剛開始就步入失敗的軌道。因此我們首先做的改進(jìn)就是關(guān)于需求搜集和分析的。具體的措施如下：
讓開發(fā)和測(cè)試加入到需求討論中
要求項(xiàng)目經(jīng)理在與客戶討論需求時(shí)，至少叫上一個(gè)開發(fā)和測(cè)試一起討論。包括拜訪客戶時(shí)，也盡量帶一個(gè)或者兩個(gè)人過去。這樣做的目的包括：
- 不同的人可以提供不同的視角
- 避免出現(xiàn)溝通傳達(dá)錯(cuò)誤
- 可以鍛煉普通工程師的溝通理解能力。
以文檔的方式細(xì)化和記錄需求
將需求以樹形結(jié)構(gòu)用簡(jiǎn)短文字記錄下來，并不斷細(xì)化。比如一開始可能記錄了系統(tǒng)需要注冊(cè)功能，之后就可以把注冊(cè)功能分解成幾個(gè)子功能：普通用戶注冊(cè)，管理員注冊(cè)。普通用戶注冊(cè)又可以再分為手機(jī)注冊(cè)，郵箱注冊(cè)。手機(jī)注冊(cè)又分為發(fā)送驗(yàn)證碼，正確注冊(cè)，注冊(cè)后跳轉(zhuǎn)，檢驗(yàn)錯(cuò)誤等等。
我們實(shí)際使用的是excel，因?yàn)閑xcel中可以不停增加列，只要你愿意，這個(gè)功能列表幾乎可以無限細(xì)化下去。
之前他們公司里面項(xiàng)目組成員（大多是項(xiàng)目經(jīng)理）在與客戶交談后，記錄的文檔格式多種多樣，有的就只有本人能看明白。而且也保存在各種不同的地方。時(shí)間久了，很多東西都找不到了。
我們建立了一個(gè)共享文件服務(wù)器，按照客戶 - 項(xiàng)目 - 模塊的層級(jí)建立多層目錄。之后要求每次和客戶溝通后都要維護(hù)這樣的文件。包括電話或者郵件溝通，也需要更新需求文檔。這也為之后的開發(fā)和測(cè)試提供了依據(jù)。
值得一提的是，具體實(shí)踐中不同的企業(yè)在管理需求方面可以有不同的工具/方法。Excel是最原始的一種。您可以選擇適合自己的工具或方法。
盡早做出原型并在需求中與客戶討論
原型或者叫POC是很多企業(yè)都在用的需求工具。這里要強(qiáng)調(diào)的是原型不必做得太完善，只要能向客戶展示未來他們會(huì)大概怎么使用這個(gè)產(chǎn)品即可。一些細(xì)節(jié)方面不必做得太細(xì)。當(dāng)然，如果客戶有針對(duì)性的提出一些細(xì)節(jié)上的意見，一定要搞明白背后的需求，有時(shí)候看似細(xì)節(jié)的地方恰恰是和用戶的關(guān)鍵使用習(xí)慣相關(guān)的。
原型的工作應(yīng)該在項(xiàng)目需求討論一開始就做，這對(duì)了解客戶真實(shí)需求會(huì)起到很大作用。而且很多原型代碼在后期仍然可以在產(chǎn)品開發(fā)中使用。
流程改進(jìn)之需求/任務(wù)管理
使用一種協(xié)作工具管理需求（任務(wù)）
早期的需求討論告一段落之后，正式的開發(fā)和測(cè)試就要開始了。之前團(tuán)隊(duì)里開發(fā)做什么測(cè)試做什么全靠感覺和口頭交流。我建議他們使用一種協(xié)作工具將需求或者任務(wù)管理起來。
目前軟件團(tuán)隊(duì)可使用的協(xié)作工具非常多。最流行和功能最全的當(dāng)屬JIRA/Confeluence 和微軟的TFS。在本案例中最終他們選擇了bugzilla，原因主要還是不想用付費(fèi)的軟件。工具最重要的是選擇適用自己的。
雖然bugzilla主要用于管理bug，我們也把所有需求都登記在了上面。
實(shí)踐中，我們?cè)陧?xiàng)目初期就要求測(cè)試團(tuán)隊(duì)把需求登記在bugzilla上，并要求項(xiàng)目經(jīng)理把開發(fā)任務(wù)指派給對(duì)應(yīng)的開發(fā)。模塊開發(fā)完成并提交代碼到git以后，開發(fā)把對(duì)應(yīng)任務(wù)的狀態(tài)修改成Resolved并指派給測(cè)試人員測(cè)試。測(cè)試完成以后就直接關(guān)掉對(duì)應(yīng)的任務(wù)。而如果發(fā)現(xiàn)bug也是登記在bugzilla上。
具體實(shí)踐中，其實(shí)這里有很多相關(guān)工作。比如這里需要持續(xù)集成的工具（類似jenkins）。后文我們還會(huì)提到相關(guān)內(nèi)容。
流程改進(jìn)之質(zhì)量管理
在上一節(jié)中，我們提到了使用協(xié)作工具（JIRA/TFS/Bugzilla等）。其實(shí)這已經(jīng)涉及到了質(zhì)量管理。包括前文提到的盡早使用原型等，其實(shí)也會(huì)對(duì)質(zhì)量管理產(chǎn)生積極效應(yīng)。
持續(xù)交付并獲取客戶反饋
案例中的企業(yè)和很多企業(yè)類似，習(xí)慣于產(chǎn)品做好了才讓客戶進(jìn)行UAT。其實(shí)盡早讓客戶參與進(jìn)來使用比這樣更好。
早期處于開發(fā)中的產(chǎn)品，可能功能不完備，而且bug很多。很多人擔(dān)心會(huì)給客戶留下負(fù)面印象。其實(shí)如果和客戶做好溝通工作，并做好規(guī)劃就沒有問題。當(dāng)然，也不能讓客戶代替測(cè)試團(tuán)隊(duì)去測(cè)試產(chǎn)品。不過如果完成了某些功能（指測(cè)試驗(yàn)收通過）能盡早讓客戶體驗(yàn)并獲得客戶反饋，對(duì)于產(chǎn)品的最終質(zhì)量是會(huì)有積極作用的。
在實(shí)踐中，我們會(huì)在項(xiàng)目一開始就和客戶說明我們會(huì)希望他們?cè)陂_發(fā)中階段性的測(cè)試完成的功能并提供反饋，并要求客戶指派專人負(fù)責(zé)這方面的溝通。最后也取得了比較良好的效果。客戶實(shí)際很喜歡這種方式，因?yàn)樗麄円蚕Ｍ吹阶约焊兜目钅苡幸恍┛吹靡娒弥倪M(jìn)度。而在開發(fā)團(tuán)隊(duì)這邊，則是獲得了早期客戶的反饋與及時(shí)的調(diào)整。
那么這種階段性UAT以多久為宜呢？只能說沒有固定答案，必須視項(xiàng)目情況和客戶的情況而定。在本文提到的案例中，大概每?jī)蓚€(gè)星期左右我們就會(huì)交付一部分新功能讓客戶進(jìn)行測(cè)試。
提高項(xiàng)目的自動(dòng)化測(cè)試水平
自動(dòng)化測(cè)試有很多層面，比如針對(duì)UI的Selenium測(cè)試，還有類似SoapUI之類的服務(wù)測(cè)試，以及JUnit單元測(cè)試。
我們這里談提高項(xiàng)目的自動(dòng)化測(cè)試水平，但并沒有談一定要覆蓋率達(dá)到多少多少。這是基于我們前面說的漸進(jìn)式改善的觀點(diǎn)。
自動(dòng)化測(cè)試的價(jià)值在于減少回歸測(cè)試。所以如果你在自動(dòng)化測(cè)試上花的時(shí)間少于可能的回歸測(cè)試的時(shí)間（可以基于經(jīng)驗(yàn)和歷史估算），那么這種自動(dòng)化測(cè)試就是合理的。否則你可以繼續(xù)手動(dòng)測(cè)試。當(dāng)然，如果是大企業(yè)或者成熟的團(tuán)隊(duì)，可能需要考慮的因素就更多一點(diǎn)。
另外一個(gè)值得注意的問題是，Selenium之類的自動(dòng)化工具有的是支持錄制屏幕和操作的。如果能用錄制而不是編程的方式來創(chuàng)建自動(dòng)化測(cè)試腳本，則又可能省掉一些時(shí)間。
在實(shí)踐中，我們是要求項(xiàng)目組自己探索一個(gè)合適的自動(dòng)化測(cè)試方式。我們也建立了一些工具幫助項(xiàng)目組。比如我們用SonarQube來分析單元測(cè)試覆蓋率。雖然我們沒有對(duì)覆蓋率做強(qiáng)制要求，但我們隔一段時(shí)間會(huì)讓項(xiàng)目組一起在對(duì)SonarQube的報(bào)告做一些分析，找出哪些方面寫單元測(cè)試可以取得最大的效果/時(shí)間比。
流程改善之改進(jìn)團(tuán)隊(duì)協(xié)作
前面提到的協(xié)作工具，其實(shí)已經(jīng)涉及到了改善協(xié)作的內(nèi)容。至少改變了溝通基本靠吼的局面。不過團(tuán)隊(duì)協(xié)作涉及到很多層次的內(nèi)容。這里總結(jié)幾點(diǎn)我們覺得很有價(jià)值的實(shí)踐。
需求/計(jì)劃討論會(huì)議與回顧會(huì)議
做軟件開發(fā)的人很多都不喜歡開會(huì)。不過有些會(huì)確實(shí)有必要。這里有幾個(gè)開會(huì)的要點(diǎn)：
- 避免繁文縟節(jié)。領(lǐng)導(dǎo)在會(huì)上更多起主持串聯(lián)和傾聽的作用。避免領(lǐng)導(dǎo)在會(huì)上說一大堆自己的觀點(diǎn)。也避免太多無用的程序。
- 避免會(huì)議太過密集
- 避免開大會(huì)，盡量只找相干的人開會(huì)
- 針對(duì)具體的事情進(jìn)行討論。討論過于抽象就不好了。
- 做好會(huì)前準(zhǔn)備，比如如果討論的事情大家不熟悉，可以把相關(guān)材料早點(diǎn)發(fā)送給與會(huì)者并提醒閱讀
- 給每個(gè)人發(fā)言的機(jī)會(huì)。
- 對(duì)會(huì)上重要的觀點(diǎn)要做記錄
對(duì)于開發(fā)團(tuán)隊(duì)來說，在一個(gè)階段的開發(fā)開始之前，開會(huì)討論一下需求和計(jì)劃，會(huì)有積極的作用。如果需求和計(jì)劃都很清楚，大家可以簡(jiǎn)短討論一下就結(jié)束了。而如果有不清楚的地方，不一定非得在會(huì)上搞清楚，可以記錄下來線下解決（以避免會(huì)議過于冗長(zhǎng)）。
每個(gè)開發(fā)周期結(jié)束之后，也應(yīng)該開一個(gè)回顧會(huì)議，讓大家討論一下哪些地方做得好，哪些地方需要改善。這些意見會(huì)成為漸進(jìn)式流程改進(jìn)的重要輸入。
流程改進(jìn)之改善設(shè)計(jì)與代碼
改善設(shè)計(jì)與重構(gòu)
我們?cè)诒景咐胁扇〉膶?shí)踐稱之為“輕設(shè)計(jì)”。也就是在項(xiàng)目初期，由開發(fā)團(tuán)隊(duì)討論出一個(gè)比較輕量級(jí)的設(shè)計(jì)，這個(gè)設(shè)計(jì)大體包括程序的分層結(jié)構(gòu)和數(shù)據(jù)交互格式，公用庫(kù)的引用，事務(wù)，持久化以及一些基礎(chǔ)類等等。這些設(shè)計(jì)很快就落實(shí)在了代碼中，而不需要寫太多文檔。而在之后的開發(fā)中，由開發(fā)團(tuán)隊(duì)進(jìn)行持續(xù)的改善和重構(gòu)。
代碼和設(shè)計(jì)的重構(gòu)都需要時(shí)間，而對(duì)于很多中小項(xiàng)目來說，時(shí)間非常重要也非常有限。因此對(duì)于代碼質(zhì)量，設(shè)計(jì)質(zhì)量的追求，都要盡量追求在有限時(shí)間里取得最好的效果。這方面類似Checkstyle，PMD之類的工具能減少你發(fā)現(xiàn)代碼問題的時(shí)間。
代碼風(fēng)格與質(zhì)量
而在代碼風(fēng)格方面，最好可以使用一些編輯器的內(nèi)建自動(dòng)格式化功能。這可以大大節(jié)省開發(fā)在格式化代碼方面消耗的時(shí)間。代碼規(guī)范最好使用業(yè)界流行的規(guī)范，比如Java可以用Sun的代碼規(guī)范，C#可以用微軟的代碼規(guī)范。切忌聽一些“大?！钡母愠鲆惶坠之惖拇a規(guī)范。
正如我們前面所說，對(duì)于很多中小企業(yè)來說，設(shè)計(jì)/代碼質(zhì)量并不是關(guān)系到他們生死攸關(guān)的問題，因此優(yōu)先級(jí)可以低一點(diǎn)。但這并不是我們可以什么都不做的借口。通過綜合考慮可能付出的時(shí)間與收效，制定一個(gè)漸進(jìn)式改善設(shè)計(jì)/代碼質(zhì)量的計(jì)劃，并定期對(duì)設(shè)計(jì)/代碼質(zhì)量進(jìn)行回顧，會(huì)讓團(tuán)隊(duì)變得越來越好。
而且，如果解決了需求，質(zhì)量和交付方面的重要問題，也就應(yīng)該考慮改善設(shè)計(jì)與代碼質(zhì)量的事情了。
至此本文就結(jié)束了。在本文中我們借用一個(gè)真實(shí)的案例探討了怎么讓軟件團(tuán)隊(duì)從無序走向有序的方法：通過漸進(jìn)式的流程改進(jìn)對(duì)主要的問題逐個(gè)解決。你可能注意到我們沒有提到諸如Scrum，UP等具體的流程。這是因?yàn)槲闹械倪@些原則可以應(yīng)用在任何一種軟件生存周期（SDLC）中。我真心希望這篇文章對(duì)您或者您的企業(yè)有所啟發(fā)。
本文較長(zhǎng)，感謝您的耐心閱讀。如果您都已經(jīng)花時(shí)間讀到這里了，就隨手加個(gè)關(guān)注唄。也歡迎您隨時(shí)留言。再次真誠(chéng)地感謝。
