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