理順軟件開發各個環節-1

 

目錄 

1 軟件開發涉及哪些環節

2 團隊管理

　　2.1 創建配套研發管理制度

　　2.2 選擇合適的研發管理軟件平臺

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

　　2.4 組建研發團隊

　　　　2.4.1 產品經理

　　　　2.4.2 項目經理

　　　　2.4.3 開發團隊

　　　　2.4.4 測試團隊

　　　　2.4.5 配置管理員

　　　　2.4.6 運維人員

 

 

1 軟件開發涉及哪些環節

　　我認爲軟件開發涉及的環節有：團隊管理、開發模式選取、需求管理、開發管理、測試管理、配置管理、發佈管理、變動管理。打造出高水平的研發團隊，開發出高質量的軟件產品，要理順其中相關的各個環節。

2 團隊管理

　　團隊管理包括公司或部門級的能力，也有產品或項目級的。

　　團隊管理主要涉及：研發管理制度、研發管理軟件、績效評價體系及針對某個產品的研發團隊的組建。

　　固然，團隊建設還涉及其它方面，如人員培訓體系建設、知識庫建設等等，本文就不探討了。

2.1 創建配套研發管理制度

　　研發管理制度通常是公司級，至少是部門級的。

　　此處主要針對研發流程、各節點的具體要求而制定的研發制度。

　　不一樣公司體量和發展階段不斷，不能生搬硬套，須要創建符合公司或部門實際狀況的研發管理制度，目的是規範研發的流程，以研發團隊目前的能力水平儘量高效地開發出可靠、可用的軟件產品。

1）規定研發流程，由哪些環節組成，每一個節點的輸入、輸出及關鍵工做內容，對輸入、輸出資料的格式或內容要點的要求；

2）規定使用的研發管理軟件平臺；

3）規定研發團隊的開發約定，如：

• 代碼規範；

• 評審制度；

• 代碼配置規範；

• 代碼merge審覈規範；

• 單元測試規範；

• 設計規範（如C4模式）；

• 數據庫設計和變動的規範；

• 日誌或ELK埋點規範；

• 複雜業務邏輯的策略模式代碼規範要求；

• 高可靠性消息隊列的訪問規範；

• 項目階段性覆盤規範；

• code review規範；

• 項目迭代的MVP編制規範；

• 等等...。

 

　　這些研發管理制度及相關子項應有具體的文件和使用指南（好比發佈在知識庫中，便於訪問和更新），並輔以充分培訓和檢查，使之深刻人心。

　　研發管理制度，是軟件質量保障體系的制度保障。

2.2 選擇合適的研發管理軟件平臺

　　一個好的研發管理軟件，能夠爲研發團隊帶來極大的便利，大幅度下降溝通成本，是研發管理的利器。

　　研發管理軟件有不少，如禪道、華爲軟件開發雲、碼雲Gitee、Redmine、Teambition、JIRA等。

　　有些軟件有開源版，或針對小型團隊免費。

　　研發管理軟件，最好能覆蓋軟件項目各個環節，即所謂的一站式，包括需求管理、開發管理、測試管理、發佈管理，及相關的文檔管理。

　　可是目前各款軟件都有側重和優劣，還有免費和收費的區別。

　　我認爲，對於中小型團隊，使用禪道開源版就差很少夠了，其使人詬病的文檔支持能力，可使用其它系統來補充，如FTP服務器、網盤或知識庫。

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

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

　　合適的績效評價體系，對激發和保持研發團隊戰鬥力是很是重要的。固然，不合適的績效評價體系，可能拔苗助長。績效評價體系通常是公司級，至少是部門級的。

　　根據個人經驗，大部分研發團隊基本符合2/8法則，即20%的人員作了80%的工做。所以，如何激發80%的人員，使之能夠承擔更多比例的工做，對團隊管理很是重要。

　　這裏有主觀意願因素，也有能力因素和業務熟悉度問題，做爲研發管理者，應努力提升團隊的各個體的能力，激發上進心，營造融洽的溝通文化。

　　所以，績效評價體系必不可少，不然容易致使劣幣驅逐良幣，也就談不上高效的研發團隊。

　　績效評價分爲客觀部分和主觀部分。客觀部分由工做量和工做質量組成，主觀部分通常是主管和協做同事或部門評價打分，包括各類能力和態度。

　　關於開發工做量評估，個人經驗，是在部門創建專家組（高級程序員），評價任務工做量時，抽出2個高級，加上team leader，再臨時召集2箇中級，做爲工做量評估小組。

　　針對一批任務，先由team leader講解任務內容，而後你們各自寫出工做量（以代碼開發任務以中級程序員能力爲基準），以小時爲單位，而後你們亮出結果，若是最高和最低相差較大，則須要闡述理由，你們以爲理由充分，就投票決定工做量；若是相差不大，取中位數的工做量便可。評估後的工做量，做爲標準工做量，無論誰來完成該任務，其標準工做量是不變的。

　　這種作法，只能是相對客觀，但確實是發揮了研發團隊的大體能力。固然，仍是能夠經過度量、覆盤來持續改進（屢次迭代），提升工做量評估的準確性。

　　至於不一樣崗位相對於標準工做量，能夠有一個係數，如初級工程師來作，實際工做時間要超過標準工做量，但相對於其能力來講，已經作得很好了，所以須要適當補償。具體怎麼量化，你們能夠自行估計，可經過屢次迭代，使之符合研發團隊現狀，這也是成熟研發團隊的軟實力的一部分。

　　創建合理績效評價體系，讓咱們能夠更專一工做自己，而沒必要拘泥於所謂的996或007的加班形式，避免出現老闆與員工關於工做付出和收益之間博弈，提升團隊的凝聚力。

2.4 組建研發團隊

　　研發團隊，R&D Team，這裏是指圍繞特定軟件產品組建的研發隊伍。

　　組建研發團隊是整個研發工做的基礎。若是隊伍陣容不整，軟件項目的成功將面臨更多挑戰。

　　對軟件產品而言，一個相對健全的研發團隊包含產品經理、項目經理、開發團隊（包括開發項目經理、系統分析員或高級程序員、UI&UE設計人員、若干先後端開發人員）、測試團隊（測試組長及若干測試人員）、配置管理員、運維人員。

　　管理者要根據產品或項目的特色組建合適的研發團隊。要認識哪些崗位是不可或缺的，對不可或缺的崗位，能夠安排兼任，但不能丟棄其職責。

2.4.1 產品經理

　　按照百度百科的說法，產品經理（Product Manager）是企業中專門負責產品管理的職位，產品經理負責市場調查並根據產品、市場及用戶等的需求，肯定開發何種產品，選擇何種業務模式、商業模式等。並推進相應產品的開發組織，他還要根據產品的生命週期，協調研發、營銷、運營等，肯定和組織實施相應的產品策略，以及其餘一系列相關的產品管理活動。

　　對於大一點的公司，有專門的產品部門。

　　對於產品類軟件，產品經理是不可或缺的。

　　產品經理一頭是對外的，對接市場、銷售和客戶，其負責規劃、裁剪和導入產品需求，制定產品路線圖（RoadMap），編制階段性大版本的功能性能需求集合。其對需求的取捨有最終的裁決權，由於其對最終交付的軟件產品負責。

　　產品經理每每是業務領域的專家，至少要努力成爲業務領域的專家，這樣才能準確理解和把握客戶的需求。對業務領域不熟悉的產品經理，對整個團隊而言，多是致命的。

　　產品經理另外一頭是對內的，對接開發、測試、運維團隊。產品經理沒必要是技術專家，但其須要可以理解開發團隊的訴求，包括開發測試資源（或環境）需求的知足，對存在技術實現障礙或實現代價較大的需求是否進行需求降級的取捨。

　　對於工程項目類的定製開發軟件，也是須要產品經理的。

　　若是公司接觸的是全新的業務領域，此時每每客戶方是業務領域的專家，公司每每會指定開發項目經理來對接技術。此時要求客戶方做爲產品經理的角色足夠投入，而且須要相互信任和理解對方，容易溝通，不會在問題發生時強調責任歸屬而扯皮，不然項目實施的風險就會很大。

　　若是公司在某個業務領域有相似經驗，公司應將有經驗的產品經理加入團隊，由其對接客戶，可大大提升項目的成功率。這種狀況，產品經理能夠兼顧多個同類項目。

　　遺憾的是，不少項目大都是由對業務不熟悉的開發項目經理（Team leader）負責，其多是軟件技術方面的高手，但因爲不熟悉業務，因而項目團隊不知要踩多少個坑，結果每每不太理想。

2.4.2 項目經理

　　按照百度百科的說法，項目經理（Project Manager），簡稱PM，主要負責統籌規劃項目進度及產品生命，其工做職能直接對公司高層負責。做爲項目的管理者，PM一般會參與到一個或多個項目的管理與決策工做中。主要工做要求即在有限的資源約束下，運用系統的觀點、方法和理論，對項目涉及的所有工做進行有效地管理。從項目的投資決策開始到項目結束的全過程進行計劃、組織、指揮、協調、控制和評價，以實現項目的目標。

　　比較認同網上的一個觀點：產品經理對產品成功負責，項目經理對完成項目負責。

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

　　項目經理強調過程控制並確保項目有計劃、有序的、風險受控方式的開展和完成，而產品經理則強調結果，須要產品成功交付或銷售額達到必定數額。

　　若是公司較大，項目團隊的成員分屬多個部門，此時項目經理是不可或缺的，須要他來發揮組織、協調、管理進度和質量的做用。

　　對於小型團隊，項目經理不是必需的，此時每每由開發項目經理來兼任。

　　具體而言，項目經理是協助產品經理，來組織管理產品的每一次交付集合的開發工做。包括：

• 組建項目實施團隊併爲項目和團隊命名；

• 協調研發團隊各方並起草項目開發計劃；

• 度量和評價項目進度和質量指標；

• 當進度或質量指標發生異常時，及時介入並會同研發團隊想方法解決；

• 協調研發團隊各參與方的有序銜接，消除無人負責的灰色地帶；

• 組織相關評審工做；

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

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

• 組織版本的發佈工做。

2.4.3 開發團隊

　　開發團隊，Development Team，這裏指針對特定軟件需求的開發隊伍，負責軟件開發實現。主要職責爲：

• 軟件需求分析；

• 系統設計（或稱架構設計）；

• 接口設計；

• UI&UE設計；

• 子系統或模塊的概要設計；

• 重要功能的詳細設計；

• 編碼實現；

• 單元測試和聯調測試。

 

　　軟件開發團隊的核心成員是開發項目經理，即技術負責人，通常是高級程序員或開發總監來擔當。其帶領整個開發團隊進行開發活動。若是項目不大，軟件開發團隊縮小爲一個軟件開發小組，開發項目經理即爲開發項目組長，即Team Leader。

　　若是公司較大，有專門的系統部，系統分析員或架構師歸屬於該部門。

　　對於中小型公司，仍須要有系統分析員或架構師（中小型項目通常由Team Leader兼任）來參與到項目中，其主要職責是：

• 軟件需求分析；

• 系統設計（或稱整體設計、架構設計）；

 

　　軟件需求分析對軟件項目是十分重要且必要的。軟件需求與產品需求並非一回事，軟件需求來源於產品需求，而後轉化爲軟件需求，包括功能需求、性能需求及各類質量屬性需求（如靈活性、安全性、可靠性、可移植性、可用性、可維護性、國際化等等）。作好軟件需求分析，等於項目成功了一半。詳細闡述在需求管理章節中展開。

　　系統設計，也是很是重要的。好的架構設計，能夠大大延長軟件產品的生命期。不少年前，流行一句話：好的產品都是設計出來的，確實如此。

　　UI&UE設計，即用戶界面及交互設計。UI&UE設計，低保真模型，用於產品需求的原型，是很是合適的；高保真模型，可用於軟件需求的一部分，指導前端開發，及先後端的接口開發。

　　開發團隊的主體是軟件開發小組，小組的數量取決於軟件涉及的子系統的數目。中小型軟件，只需一個軟件開發小組。

　　軟件開發小組的成員組成，與項目選取的技術棧有很大關係。如採用先後端分離模式，後端使用Java語言Spring boot框架，前端使用VUE，則要求相關人員按此需求來配置。

　　軟件開發小組主要工做是編碼實現，但應包括子系統或模塊的概要設計文檔，接口文檔；視須要，重要功能也應該有詳細設計文檔。

　　軟件開發小組還須要實現單元測試。要充分利用已有的單元測試框架，如Java的JUnit，以提升單元測試的效率。

　　代碼提交測試人員測試前，還須要完成聯調測試，若是聯調測試都通不過，而直接提交測試部門測試，將形成測試資源的極大浪費。

 

2.4.4 測試團隊

　　測試團隊，Test Team或QA，是保障軟件質量的重要單元。對於中小型軟件，能夠是一兩個軟件測試工程師，甚至一個軟件測試工程師兼顧多個項目。

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

　　測試團隊使用軟件測試方法，根據須要，提供下列測試：

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

• 接口測試；

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

• 視須要與開發人員共同完成白盒測試；

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

 

　　測試人員和開發人員的視角不一樣，不可相互替代。

2.4.5 配置管理員

　　配置管理包含版本管理，對於較複雜的系統，其涉及多個子系統，每一個子系統又有依賴的組件版本，這些構成了所有的配置項。

　　對於Java，有Maven工具，幫助管理組件的版本，能夠省心很多。

　　配置管理員通常由開發項目經理兼任，若是項目較大，能夠另行專門指定一個配置管理員。

　　配置管理員協助項目經理（PM）和開發項目經理（Team Leader），完成配置管理工做。

　　代碼的版本管理，通常使用版本管理工具，如VSS、SVN、Git。如今通常用git。

　　配置管理員建立必要的代碼分支，並進行代碼merge審覈，設置代碼基線（或tag）。

　　沒有良好的配置管理，致使代碼版本混亂不堪，質量保證就無從談起。

2.4.6 運維人員

　　如今項目大可能是雲部署的項目。涉及web服務器、數據庫服務器、消息隊列、Redis等，從可靠性和性能角度，還可能集羣或分佈式部署，還要考慮網絡安全等因素。

　　所以，若是項目涉及雲部署，應該有專門的運維人員，他能夠兼顧多個項目。

　　運維人員每每兼任數據庫管理員，及版本上線發佈。