1 軟件開發(fā)涉及哪些環(huán)節(jié)　　

　　我認(rèn)為軟件開發(fā)涉及的環(huán)節(jié)有：團(tuán)隊管理、開發(fā)模式選取、需求管理、開發(fā)管理、測試管理、配置管理、發(fā)布管理、變更管理。打造出高水平的研發(fā)團(tuán)隊，開發(fā)出高質(zhì)量的軟件產(chǎn)品，要理順其中相關(guān)的各個環(huán)節(jié)。

2 團(tuán)隊管理

　　團(tuán)隊管理包括公司或部門級的能力，也有產(chǎn)品或項目級的。

　　團(tuán)隊管理主要涉及：研發(fā)管理制度、研發(fā)管理軟件、績效評價體系及針對某個產(chǎn)品的研發(fā)團(tuán)隊的組建。

　　當(dāng)然，團(tuán)隊建設(shè)還涉及其它方面，如人員培訓(xùn)體系建設(shè)、知識庫建設(shè)等等，本文就不探討了。

2.1 建立配套研發(fā)管理制度

　　研發(fā)管理制度一般是公司級，至少是部門級的。

　　此處主要針對研發(fā)流程、各節(jié)點的具體要求而制定的研發(fā)制度。

　　不同公司體量和發(fā)展階段不斷，不能生搬硬套，需要建立符合公司或部門實際情況的研發(fā)管理制度，目的是規(guī)范研發(fā)的流程，以研發(fā)團(tuán)隊目前的能力水平盡可能高效地開發(fā)出可靠、可用的軟件產(chǎn)品。

1）規(guī)定研發(fā)流程，由哪些環(huán)節(jié)組成，每個節(jié)點的輸入、輸出及關(guān)鍵工作內(nèi)容，對輸入、輸出資料的格式或內(nèi)容要點的要求；

2）規(guī)定使用的研發(fā)管理軟件平臺；

3）規(guī)定研發(fā)團(tuán)隊的開發(fā)約定，如：

• 代碼規(guī)范；

• 評審制度；

• 代碼配置規(guī)范；

• 代碼merge審核規(guī)范；

• 單元測試規(guī)范；

• 設(shè)計規(guī)范（如C4模式）；

• 數(shù)據(jù)庫設(shè)計和變更的規(guī)范；

• 日志或ELK埋點規(guī)范；

• 復(fù)雜業(yè)務(wù)邏輯的策略模式代碼規(guī)范要求；

• 高可靠性消息隊列的訪問規(guī)范；

• 項目階段性復(fù)盤規(guī)范；

• code review規(guī)范；

• 項目迭代的MVP編制規(guī)范；

• 等等...。

 

　　這些研發(fā)管理制度及相關(guān)子項應(yīng)有具體的文件和使用指南（比如發(fā)布在知識庫中，便于訪問和更新），并輔以充分培訓(xùn)和檢查，使之深入人心。

　　研發(fā)管理制度，是軟件質(zhì)量保障體系的制度保障。

2.2 選擇合適的研發(fā)管理軟件平臺

　　一個好的研發(fā)管理軟件，可以為研發(fā)團(tuán)隊帶來極大的便利，大幅度降低溝通成本，是研發(fā)管理的利器。

　　研發(fā)管理軟件有很多，如禪道、華為軟件開發(fā)云、碼云Gitee、Redmine、Teambition、JIRA等。

　　有些軟件有開源版，或針對小型團(tuán)隊免費。

　　研發(fā)管理軟件，最好能覆蓋軟件項目各個環(huán)節(jié)，即所謂的一站式，包括需求管理、開發(fā)管理、測試管理、發(fā)布管理，及相關(guān)的文檔管理。

　　但是目前各款軟件都有側(cè)重和優(yōu)劣，還有免費和收費的區(qū)別。

　　我認(rèn)為，對于中小型團(tuán)隊，使用禪道開源版就差不多夠了，其令人詬病的文檔支持能力，可以使用其它系統(tǒng)來補(bǔ)充，如FTP服務(wù)器、網(wǎng)盤或知識庫。

　　用好研發(fā)管理軟件，是公司研發(fā)軟實力的組成部分。

2.3 配套合適的績效評價體系

　　合適的績效評價體系，對激發(fā)和保持研發(fā)團(tuán)隊?wèi)?zhàn)斗力是非常重要的。當(dāng)然，不合適的績效評價體系，可能適得其反?？冃гu價體系一般是公司級，至少是部門級的。

　　根據(jù)我的經(jīng)驗，大部分研發(fā)團(tuán)隊基本符合2/8法則，即20%的人員做了80%的工作。因此，如何激發(fā)80%的人員，使之可以承擔(dān)更多比例的工作，對團(tuán)隊管理非常重要。

　　這里有主觀意愿因素，也有能力因素和業(yè)務(wù)熟悉度問題，作為研發(fā)管理者，應(yīng)努力提高團(tuán)隊的各個體的能力，激發(fā)上進(jìn)心，營造融洽的溝通文化。

　　因此，績效評價體系必不可少，否則容易導(dǎo)致劣幣驅(qū)逐良幣，也就談不上高效的研發(fā)團(tuán)隊。

　　績效評價分為客觀部分和主觀部分?？陀^部分由工作量和工作質(zhì)量組成，主觀部分一般是主管和協(xié)作同事或部門評價打分，包括各種能力和態(tài)度。

　　關(guān)于開發(fā)工作量評估，我的經(jīng)驗，是在部門建立專家組（高級程序員），評價任務(wù)工作量時，抽出2個高級，加上team leader，再臨時召集2個中級，作為工作量評估小組。

　　針對一批任務(wù)，先由team leader講解任務(wù)內(nèi)容，然后大家各自寫出工作量（以代碼開發(fā)任務(wù)以中級程序員能力為基準(zhǔn)），以小時為單位，然后大家亮出結(jié)果，如果最高和最低相差較大，則需要闡述理由，大家覺得理由充分，就投票決定工作量；如果相差不大，取中位數(shù)的工作量即可。評估后的工作量，作為標(biāo)準(zhǔn)工作量，不管誰來完成該任務(wù)，其標(biāo)準(zhǔn)工作量是不變的。

　　這種做法，只能是相對客觀，但確實是發(fā)揮了研發(fā)團(tuán)隊的大致能力。當(dāng)然，還是可以通過度量、復(fù)盤來持續(xù)改進(jìn)（多次迭代），提高工作量評估的準(zhǔn)確性。

　　至于不同崗位相對于標(biāo)準(zhǔn)工作量，可以有一個系數(shù)，如初級工程師來做，實際工作時間要超過標(biāo)準(zhǔn)工作量，但相對于其能力來說，已經(jīng)做得很好了，因此需要適當(dāng)補(bǔ)償。具體怎么量化，大家可以自行估計，可通過多次迭代，使之符合研發(fā)團(tuán)隊現(xiàn)狀，這也是成熟研發(fā)團(tuán)隊的軟實力的一部分。

　　建立合理績效評價體系，讓我們可以更專注工作本身，而不必拘泥于所謂的996或007的加班形式，避免出現(xiàn)老板與員工關(guān)于工作付出和收益之間博弈，提高團(tuán)隊的凝聚力。

2.4 組建研發(fā)團(tuán)隊

　　研發(fā)團(tuán)隊，R&D Team，這里是指圍繞特定軟件產(chǎn)品組建的研發(fā)隊伍。

　　組建研發(fā)團(tuán)隊是整個研發(fā)工作的基礎(chǔ)。如果隊伍陣容不整，軟件項目的成功將面臨更多挑戰(zhàn)。

　　對軟件產(chǎn)品而言，一個相對健全的研發(fā)團(tuán)隊包含產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)團(tuán)隊（包括開發(fā)項目經(jīng)理、系統(tǒng)分析員或高級程序員、UI&UE設(shè)計人員、若干前后端開發(fā)人員）、測試團(tuán)隊（測試組長及若干測試人員）、配置管理員、運維人員。

　　管理者要根據(jù)產(chǎn)品或項目的特點組建合適的研發(fā)團(tuán)隊。要認(rèn)識哪些崗位是不可或缺的，對不可或缺的崗位，可以安排兼任，但不能丟棄其職責(zé)。

2.4.1 產(chǎn)品經(jīng)理

　　按照百度百科的說法，產(chǎn)品經(jīng)理（Product Manager）是企業(yè)中專門負(fù)責(zé)產(chǎn)品管理的職位，產(chǎn)品經(jīng)理負(fù)責(zé)市場調(diào)查并根據(jù)產(chǎn)品、市場及用戶等的需求，確定開發(fā)何種產(chǎn)品，選擇何種業(yè)務(wù)模式、商業(yè)模式等。并推動相應(yīng)產(chǎn)品的開發(fā)組織，他還要根據(jù)產(chǎn)品的生命周期，協(xié)調(diào)研發(fā)、營銷、運營等，確定和組織實施相應(yīng)的產(chǎn)品策略，以及其他一系列相關(guān)的產(chǎn)品管理活動。

　　對于大一點的公司，有專門的產(chǎn)品部門。

　　對于產(chǎn)品類軟件，產(chǎn)品經(jīng)理是不可或缺的。

　　產(chǎn)品經(jīng)理一頭是對外的，對接市場、銷售和客戶，其負(fù)責(zé)規(guī)劃、裁剪和導(dǎo)入產(chǎn)品需求，制定產(chǎn)品路線圖（RoadMap），編制階段性大版本的功能性能需求集合。其對需求的取舍有最終的裁決權(quán)，因為其對最終交付的軟件產(chǎn)品負(fù)責(zé)。

　　產(chǎn)品經(jīng)理往往是業(yè)務(wù)領(lǐng)域的專家，至少要努力成為業(yè)務(wù)領(lǐng)域的專家，這樣才能準(zhǔn)確理解和把握客戶的需求。對業(yè)務(wù)領(lǐng)域不熟悉的產(chǎn)品經(jīng)理，對整個團(tuán)隊而言，可能是致命的。

　　產(chǎn)品經(jīng)理另一頭是對內(nèi)的，對接開發(fā)、測試、運維團(tuán)隊。產(chǎn)品經(jīng)理不必是技術(shù)專家，但其需要能夠理解開發(fā)團(tuán)隊的訴求，包括開發(fā)測試資源（或環(huán)境）需求的滿足，對存在技術(shù)實現(xiàn)障礙或?qū)崿F(xiàn)代價較大的需求是否進(jìn)行需求降級的取舍。

　　對于工程項目類的定制開發(fā)軟件，也是需要產(chǎn)品經(jīng)理的。

　　如果公司接觸的是全新的業(yè)務(wù)領(lǐng)域，此時往往客戶方是業(yè)務(wù)領(lǐng)域的專家，公司往往會指定開發(fā)項目經(jīng)理來對接技術(shù)。此時要求客戶方作為產(chǎn)品經(jīng)理的角色足夠投入，并且需要相互信任和理解對方，容易溝通，不會在問題發(fā)生時強(qiáng)調(diào)責(zé)任歸屬而扯皮，否則項目實施的風(fēng)險就會很大。

　　如果公司在某個業(yè)務(wù)領(lǐng)域有類似經(jīng)驗，公司應(yīng)將有經(jīng)驗的產(chǎn)品經(jīng)理加入團(tuán)隊，由其對接客戶，可大大提高項目的成功率。這種情況，產(chǎn)品經(jīng)理可以兼顧多個同類項目。

　　遺憾的是，很多項目大都是由對業(yè)務(wù)不熟悉的開發(fā)項目經(jīng)理（Team leader）負(fù)責(zé)，其可能是軟件技術(shù)方面的高手，但由于不熟悉業(yè)務(wù)，于是項目團(tuán)隊不知要踩多少個坑，結(jié)果往往不太理想。

2.4.2 項目經(jīng)理

　　按照百度百科的說法，項目經(jīng)理（Project Manager），簡稱PM，主要負(fù)責(zé)統(tǒng)籌規(guī)劃項目進(jìn)度及產(chǎn)品生命，其工作職能直接對公司高層負(fù)責(zé)。作為項目的管理者，PM通常會參與到一個或多個項目的管理與決策工作中。主要工作要求即在有限的資源約束下，運用系統(tǒng)的觀點、方法和理論，對項目涉及的全部工作進(jìn)行有效地管理。從項目的投資決策開始到項目結(jié)束的全過程進(jìn)行計劃、組織、指揮、協(xié)調(diào)、控制和評價，以實現(xiàn)項目的目標(biāo)。

　　比較認(rèn)同網(wǎng)上的一個觀點：產(chǎn)品經(jīng)理對產(chǎn)品成功負(fù)責(zé)，項目經(jīng)理對完成項目負(fù)責(zé)。

　　對于大一點的公司，有專門的項目部門。

　　項目經(jīng)理強(qiáng)調(diào)過程控制并確保項目有計劃、有序的、風(fēng)險受控方式的開展和完成，而產(chǎn)品經(jīng)理則強(qiáng)調(diào)結(jié)果，需要產(chǎn)品成功交付或銷售額達(dá)到一定數(shù)額。

　　如果公司較大，項目團(tuán)隊的成員分屬多個部門，此時項目經(jīng)理是不可或缺的，需要他來發(fā)揮組織、協(xié)調(diào)、管理進(jìn)度和質(zhì)量的作用。

　　對于小型團(tuán)隊，項目經(jīng)理不是必需的，此時往往由開發(fā)項目經(jīng)理來兼任。

　　具體而言，項目經(jīng)理是協(xié)助產(chǎn)品經(jīng)理，來組織管理產(chǎn)品的每一次交付集合的開發(fā)工作。包括：

• 組建項目實施團(tuán)隊并為項目和團(tuán)隊命名；

• 協(xié)調(diào)研發(fā)團(tuán)隊各方并起草項目開發(fā)計劃；

• 度量和評價項目進(jìn)度和質(zhì)量指標(biāo)；

• 當(dāng)進(jìn)度或質(zhì)量指標(biāo)發(fā)生異常時，及時介入并會同研發(fā)團(tuán)隊想方法解決；

• 協(xié)調(diào)研發(fā)團(tuán)隊各參與方的有序銜接，消除無人負(fù)責(zé)的灰色地帶；

• 組織相關(guān)評審工作；

• 組織變更的分析、評估、評審和實施；

• 組織配置管理（版本管理）的基線管理；

• 組織版本的發(fā)布工作。

2.4.3 開發(fā)團(tuán)隊

　　開發(fā)團(tuán)隊，Development Team，這里指針對特定軟件需求的開發(fā)隊伍，負(fù)責(zé)軟件開發(fā)實現(xiàn)。主要職責(zé)為：

• 軟件需求分析；

• 系統(tǒng)設(shè)計（或稱架構(gòu)設(shè)計）；

• 接口設(shè)計；

• UI&UE設(shè)計；

• 子系統(tǒng)或模塊的概要設(shè)計；

• 重要功能的詳細(xì)設(shè)計；

• 編碼實現(xiàn)；

• 單元測試和聯(lián)調(diào)測試。

 

　　軟件開發(fā)團(tuán)隊的核心成員是開發(fā)項目經(jīng)理，即技術(shù)負(fù)責(zé)人，一般是高級程序員或開發(fā)總監(jiān)來擔(dān)當(dāng)。其帶領(lǐng)整個開發(fā)團(tuán)隊進(jìn)行開發(fā)活動。如果項目不大，軟件開發(fā)團(tuán)隊縮小為一個軟件開發(fā)小組，開發(fā)項目經(jīng)理即為開發(fā)項目組長，即Team Leader。

　　如果公司較大，有專門的系統(tǒng)部，系統(tǒng)分析員或架構(gòu)師歸屬于該部門。

　　對于中小型公司，仍需要有系統(tǒng)分析員或架構(gòu)師（中小型項目一般由Team Leader兼任）來參與到項目中，其主要職責(zé)是：

• 軟件需求分析；

• 系統(tǒng)設(shè)計（或稱總體設(shè)計、架構(gòu)設(shè)計）；

 

　　軟件需求分析對軟件項目是十分重要且必要的。軟件需求與產(chǎn)品需求并不是一回事，軟件需求來源于產(chǎn)品需求，然后轉(zhuǎn)化為軟件需求，包括功能需求、性能需求及各種質(zhì)量屬性需求（如靈活性、安全性、可靠性、可移植性、可用性、可維護(hù)性、國際化等等）。做好軟件需求分析，等于項目成功了一半。詳細(xì)闡述在需求管理章節(jié)中展開。

　　系統(tǒng)設(shè)計，也是非常重要的。好的架構(gòu)設(shè)計，可以大大延長軟件產(chǎn)品的生命期。很多年前，流行一句話：好的產(chǎn)品都是設(shè)計出來的，確實如此。

　　UI&UE設(shè)計，即用戶界面及交互設(shè)計。UI&UE設(shè)計，低保真模型，用于產(chǎn)品需求的原型，是非常合適的；高保真模型，可用于軟件需求的一部分，指導(dǎo)前端開發(fā)，及前后端的接口開發(fā)。

　　開發(fā)團(tuán)隊的主體是軟件開發(fā)小組，小組的數(shù)量取決于軟件涉及的子系統(tǒng)的數(shù)目。中小型軟件，只需一個軟件開發(fā)小組。

　　軟件開發(fā)小組的成員組成，與項目選取的技術(shù)棧有很大關(guān)系。如采用前后端分離模式，后端使用Java語言Spring boot框架，前端使用VUE，則要求相關(guān)人員按此需求來配置。

　　軟件開發(fā)小組主要工作是編碼實現(xiàn)，但應(yīng)包括子系統(tǒng)或模塊的概要設(shè)計文檔，接口文檔；視需要，重要功能也應(yīng)該有詳細(xì)設(shè)計文檔。

　　軟件開發(fā)小組還需要實現(xiàn)單元測試。要充分利用已有的單元測試框架，如Java的JUnit，以提高單元測試的效率。

　　代碼提交測試人員測試前，還需要完成聯(lián)調(diào)測試，如果聯(lián)調(diào)測試都通不過，而直接提交測試部門測試，將造成測試資源的極大浪費。

 

2.4.4 測試團(tuán)隊

　　測試團(tuán)隊，Test Team或QA，是保障軟件質(zhì)量的重要單元。對于中小型軟件，可以是一兩個軟件測試工程師，甚至一個軟件測試工程師兼顧多個項目。

　　但測試人員是必不可少的。

　　測試團(tuán)隊使用軟件測試方法，根據(jù)需要，提供下列測試：

• 功能測試（黑盒測試）；

• 接口測試；

• 性能測試（壓力測試）；

• 視需要與開發(fā)人員共同完成白盒測試；

• 必要時，搭建自動化測試框架，以更好地支持回歸測試。

 

　　測試人員和開發(fā)人員的視角不同，不可相互替代。

2.4.5 配置管理員

　　配置管理包含版本管理，對于較復(fù)雜的系統(tǒng)，其涉及多個子系統(tǒng)，每個子系統(tǒng)又有依賴的組件版本，這些構(gòu)成了全部的配置項。

　　對于Java，有Maven工具，幫助管理組件的版本，可以省心不少。

　　配置管理員一般由開發(fā)項目經(jīng)理兼任，如果項目較大，可以另行專門指定一個配置管理員。

　　配置管理員協(xié)助項目經(jīng)理（PM）和開發(fā)項目經(jīng)理（Team Leader），完成配置管理工作。

　　代碼的版本管理，一般使用版本管理工具，如VSS、SVN、Git?，F(xiàn)在一般用git。

　　配置管理員創(chuàng)建必要的代碼分支，并進(jìn)行代碼merge審核，設(shè)置代碼基線（或tag）。

　　沒有良好的配置管理，導(dǎo)致代碼版本混亂不堪，質(zhì)量保證就無從談起。

2.4.6 運維人員

　　現(xiàn)在項目大多是云部署的項目。涉及web服務(wù)器、數(shù)據(jù)庫服務(wù)器、消息隊列、Redis等，從可靠性和性能角度，還可能集群或分布式部署，還要考慮網(wǎng)絡(luò)安全等因素。

　　因此，如果項目涉及云部署，應(yīng)該有專門的運維人員，他可以兼顧多個項目。

　　運維人員往往兼任數(shù)據(jù)庫管理員，及版本上線發(fā)布。