軟件團(tuán)隊(duì)管理心得雜燴

筆者注：本文內(nèi)容為本人從業(yè)12年以來的心得總結(jié)，僅供參考，謝謝。軟件產(chǎn)品分類理清軟件產(chǎn)品的分類，是我們講述一切問題的根本。按照軟件產(chǎn)品特點(diǎn)共分了5個大類，每個大類軟件都有各自的特點(diǎn)，產(chǎn)品策略、盈利模式、開發(fā)過程和管理模式都是各不相同的。軟件其它維度的分類方式l 按軟件對企業(yè)的作用劃分戰(zhàn)略目標(biāo)、過程手段l 按盈利模式劃分合同項(xiàng)目、通用產(chǎn)品、運(yùn)營、廣告嵌入l 按用戶和研發(fā)的關(guān)系劃分定向用戶、廣泛用戶l 按發(fā)布手段劃分租賃（限期加密鎖）、零售、在線、部署、運(yùn)維l 按產(chǎn)品策略劃分世代劃分模式、滾動更新模式l 按軟件架構(gòu)劃分集中式、分布式（B/S, C/S）l 按軟件技術(shù)特點(diǎn)劃分(1) 模型中心類：以建立數(shù)學(xué)模型、圖形模型或文檔對象模型為中心的軟件。例：文字處理軟件、印刷排版軟件、CAD軟件、編織打版軟件，2D/3D繪圖或制圖軟件、電子游戲軟件等。(2) 技術(shù)中心類：以核心技術(shù)做為支撐，技術(shù)難度大的軟件。例：數(shù)據(jù)安全和備份軟件、網(wǎng)絡(luò)信息安全軟件、網(wǎng)絡(luò)信息監(jiān)控軟件、多媒體信息處理軟件、人體特征識別軟件、壓縮與加解密軟件、以及服務(wù)平臺類中的工具類軟件等。(3) 業(yè)務(wù)中心類：以工藝流程或業(yè)務(wù)流程為中心的軟件。例：服務(wù)平臺類軟件（工具類和內(nèi)容類除外）、業(yè)務(wù)系統(tǒng)類軟件。(4) 內(nèi)容中心類：以提供內(nèi)容為中心的軟件。例：服務(wù)平臺類中的內(nèi)容類軟件。以上四大類軟件，研發(fā)團(tuán)隊(duì)的角色人力配比、各類角色的工作重心、工作計劃策略等都是不相同的，要根據(jù)各類軟件自身的特點(diǎn)來決定，不可一概而論。譬如業(yè)務(wù)中心類的軟件，比較適合于下述的滾動更新模型；工作計劃策略適合于“時間點(diǎn)-成果物”模式（到既定的時間點(diǎn)必須提供要求的成果物）。而模型中心和技術(shù)中心類的軟件，比較適合于下述的世代劃分模型；在開發(fā)前期工作計劃策略比較適合于“步驟-跟蹤”模式（預(yù)先識別技術(shù)難點(diǎn)，制定詳細(xì)可行的工作步驟，定期跟蹤進(jìn)展，動態(tài)調(diào)整下一步工作計劃）；進(jìn)入規(guī)?；_發(fā)期或系統(tǒng)集成期之后，才適和采用“時間點(diǎn)-成果物”模式。軟件開發(fā)過程模型世代劃分模型對于大規(guī)模軟件（指功能量級和代碼量級大）：對于中小規(guī)模軟件：對于技術(shù)中心類軟件： 注：后維護(hù)期一般要持續(xù)到下一世代的第一個正式版本發(fā)布為止。滾動更新模型這種適用于規(guī)模量級較小，不需要維護(hù)期的軟件產(chǎn)品。以上模型中，都強(qiáng)調(diào)了“穩(wěn)定期”的概念，這是很多團(tuán)隊(duì)比較忽略的問題。請記住以下事實(shí)：沒有軟件是沒有Bug的，沒有軟件是一開發(fā)完成即可實(shí)用的，這與軟件規(guī)模量級無關(guān)。軟件版本四級標(biāo)準(zhǔn)I. 可調(diào)試：可以啟動運(yùn)行，進(jìn)行針對功能的開發(fā)調(diào)試。II. 可演示：實(shí)現(xiàn)功能基本效果、跑通一條基本流程，又分為局部可演示和整體可演示。III. 可實(shí)用：功能完整、流程暢通、可以用于實(shí)際生產(chǎn)或應(yīng)用。IV. 產(chǎn)品化：注重細(xì)節(jié)、產(chǎn)品設(shè)計（含美工）優(yōu)秀、用戶體驗(yàn)度高、有很強(qiáng)的市場競爭力。軟件版本劃分周期類別l 開發(fā)過程版：新功能開發(fā)過程中的版本l Alpha版：可用性測試版本l Beta版：穩(wěn)定性測試版本l 正式版：正式發(fā)布版本l 更新版：正式版發(fā)布后，定期更新的版本 經(jīng)過beta版本的測試后，確定了發(fā)布候選版本（RC版, Release Candidate），明確了最終必需修改的問題清單，經(jīng)過一個非常短暫的修改+測試過程，確定正式版本。如果此過程非常短暫，RC版本無需做為一個獨(dú)立的版本周期類別。過程類別例行測試版：以固定周期和時間點(diǎn)發(fā)布給測試團(tuán)隊(duì)的版本。（參見最末節(jié)對軟件測試的闡述。）對外發(fā)布版：可以對外發(fā)布、部署或上線運(yùn)營的版本。軟件研發(fā)團(tuán)隊(duì)角色分工大的分工圖還記得這個圖么（見關(guān)于研究者心態(tài)）：套用到軟件研發(fā)團(tuán)隊(duì)，我們來變化一下：軟件研發(fā)團(tuán)隊(duì)內(nèi)部的分工l 需求（產(chǎn)品）角色決定目標(biāo)、明確方向成果物：產(chǎn)品規(guī)劃文檔、需求規(guī)格文檔、原型設(shè)計、需求追溯表（其他參見下一節(jié)）這里說的是廣義的需求角色，包含軟件產(chǎn)品角色和需求分析角色。另外，也包含用戶體驗(yàn)角色（產(chǎn)品設(shè)計、美工）和用戶教育角色（幫助文檔或用戶手冊編寫）。工藝流程的分析設(shè)計，以及數(shù)據(jù)規(guī)格或SDK接口規(guī)格的匯總統(tǒng)籌工作也包含在內(nèi)。需求導(dǎo)向是市場導(dǎo)向的具體體現(xiàn)，需求應(yīng)是研發(fā)團(tuán)隊(duì)中權(quán)力相對更大的，有對開發(fā)和測試進(jìn)行需求說明和指導(dǎo)的權(quán)利和義務(wù)，有權(quán)決定一個功能是否必須實(shí)現(xiàn)、一個Bug是否必須修改。需求角色有對開發(fā)和測試的工作進(jìn)行監(jiān)督的權(quán)力。l 項(xiàng)目管理和項(xiàng)目助理角色關(guān)注過程成果物（項(xiàng)目管理）：過程管理體系、過程資產(chǎn)庫、過程管理工具成果物（項(xiàng)目助理）：軟件開發(fā)里程碑計劃表（如果企業(yè)不是按項(xiàng)目配置資源的話）項(xiàng)目管理角色應(yīng)屬于“過程管理研究團(tuán)隊(duì)”，對產(chǎn)品研發(fā)團(tuán)隊(duì)的過程管理起指導(dǎo)、支持和監(jiān)督的作用。其工作內(nèi)容包括： (1) 指導(dǎo)職責(zé)：制定過程管理制度體系和執(zhí)行細(xì)則（如依據(jù)CMMI），制定軟件過程各環(huán)節(jié)的成果物文檔模版，維護(hù)企業(yè)的過程資產(chǎn)庫。(2) 支持職責(zé)：選定適合的過程管理工具（如項(xiàng)目管理平臺或Project），對各產(chǎn)品研發(fā)團(tuán)隊(duì)進(jìn)行過程管理體系和過程管理工具培訓(xùn)，接收過程管理工具使用的問題反饋。(3) 監(jiān)督職責(zé)：對各產(chǎn)品研發(fā)團(tuán)隊(duì)執(zhí)行過程管理的情況進(jìn)行巡視和督促，QA專員在軟件產(chǎn)品正式發(fā)布前對其質(zhì)量指標(biāo)進(jìn)行審核確認(rèn)。如果項(xiàng)目管理角色直接介入研發(fā)團(tuán)隊(duì)，做為實(shí)施者，其弊大于利：(1) 團(tuán)隊(duì)成員會覺得自己不被決策者信任，自己的空間被擠占，產(chǎn)生逆反心理；(2) 項(xiàng)目管理角色做為實(shí)施者，會因第一點(diǎn)以及決策者給予的壓力，淪為團(tuán)隊(duì)實(shí)際上的主管，實(shí)際擔(dān)負(fù)了過多的責(zé)任，很累，而自己做為過程管理專家原本的作用反而發(fā)揮不出來了。l 開發(fā)角色關(guān)注方法（包括架構(gòu)、設(shè)計、流程和邏輯），實(shí)現(xiàn)版本成果物（模型或技術(shù)中心類）：總體設(shè)計文檔、功能單元詳細(xì)設(shè)計文檔、關(guān)鍵技術(shù)文檔成果物（業(yè)務(wù)中心類）：概要設(shè)計文檔、詳細(xì)設(shè)計文檔、接口設(shè)計文檔需負(fù)責(zé)單元測試（即理論上的單元測試，針對代碼基本單元進(jìn)行的自動化測試）。l 測試角色參與過程、保證結(jié)果成果物：測試設(shè)計文檔、測試報告文檔。與工業(yè)生產(chǎn)中的質(zhì)?；蚱房夭煌?，軟件測試不僅要保證結(jié)果，也要參與到過程中來。測試要參與需求討論和評審，在開發(fā)做開發(fā)設(shè)計的同時編寫測試設(shè)計（即用例設(shè)計）。測試對于例行測試版本，特別是功能未開發(fā)完全時期，主要關(guān)注已實(shí)現(xiàn)功能的正確性和可用性（即以功能測試為主）；對于（準(zhǔn)）對外發(fā)布版本，關(guān)注版本整體的可用性和穩(wěn)定性（即以綜合測試為主）。在必要的時候，測試需要到開發(fā)現(xiàn)場進(jìn)行現(xiàn)場測試，譬如開發(fā)有重要變更要提交之前，或臨近正式版本發(fā)布的時候，現(xiàn)場測試可以加快開發(fā)與測試的交流、加速版本的穩(wěn)定，起到很好的作用。軟件需求過程上圖體現(xiàn)了需求工作的兩個層次，同時也反映了測試工作的兩個層次。下圖是軟件需求工作流程的一種實(shí)例。軟件測試工作原則分析零信任原則測試對開發(fā)是零信任的。就是說開發(fā)在開發(fā)過程中除單元測試外，當(dāng)然是對功能做過了簡單的集成測試（白盒測試），但是這不意味著測試可以不對功能作細(xì)化的用例覆蓋。因?yàn)闇y試是保證軟件質(zhì)量的最后一道關(guān)口，一旦軟件到了用戶手里暴露出了問題，對軟件產(chǎn)品和團(tuán)隊(duì)的負(fù)面影響很大，有時甚至是致命的。根本原則軟件測試對軟件版本負(fù)責(zé)，保證軟件版本整體的可用性，包括功能、流程和效率。這意味著，需要有與需求規(guī)格一致的、詳細(xì)的測試用例清單，每一個軟件版本的測試對于每一個功能點(diǎn)、每一條流程分支都要覆蓋到位。簡化的原則軟件測試只對變更負(fù)責(zé)，即只保證本次軟件版本變更的部分的可用性。未變更的部分的可用性則由開發(fā)團(tuán)隊(duì)負(fù)責(zé)保證。由于功能或模塊之間總是存在關(guān)聯(lián)影響的（特別是實(shí)現(xiàn)了很多底層機(jī)制的大規(guī)模軟件），這種簡化的測試原則，使得軟件質(zhì)量下降或出現(xiàn)嚴(yán)重問題的風(fēng)險，增加很多。Bug趨勢圖一般來說，新功能提交后，Bug總會有一個從爆發(fā)到收斂的過程，Bug趨勢曲線是判斷軟件版本是否穩(wěn)定、是否可發(fā)布的重要標(biāo)準(zhǔn)。這里不打算對此問題展開贅述了，請參見以下資料：/not_a_baby/article/details/6799558/link?url=d1sfi88-17Uan4oMJD-nNnKDLsUAyT9bmpAJGrVI-dP120XRK8N8OhB58gDQP1x3fEwxEnPPsRth3mW0P3e72nbhelhu_sa9kF5L5Vs-TwGBug數(shù)量做為績效考核指標(biāo)由上，一定要鼓勵測試人員多多提Bug，各方各面的提。Bug數(shù)量足夠，Bug趨勢才能發(fā)揮出作用來。因此，Bug數(shù)量一定是對測試角色的考核指標(biāo)，一定不能是對開發(fā)角色的考核指標(biāo)。這里的意思是說，不要因?yàn)锽ug爆發(fā)而對開發(fā)做績效減分，但Bug數(shù)做為開發(fā)任務(wù)目標(biāo)是可以的，譬如“本迭代周期的正式版本發(fā)布前，人均