這個(gè)問題其實(shí)來源于一次面試，在聊完一堆的技術(shù)架構(gòu)之后答憔，面試官拋出一個(gè)問題：“你是怎么進(jìn)行研發(fā)管理的工作的味赃？”當(dāng)時(shí)我的回答是：“主要是應(yīng)用Scrum來進(jìn)行管理∨巴兀”后續(xù)的情況不細(xì)說心俗，但是我覺得我這句話來概括之前近10年的管理經(jīng)歷，實(shí)在是太弱了蓉驹。后面我就思考該如何真正回答好這個(gè)問題城榛，我也去讀了廈大的MEM，下面就是我覺得可以很好回應(yīng)的一個(gè)答案态兴。
引言
廣義上的管理狠持，指的是一定組織中的管理者實(shí)施的行為 ，目的是達(dá)到共同目標(biāo)诗茎。管理有五個(gè)核心要素：計(jì)劃工坊、組織、領(lǐng)導(dǎo)敢订、協(xié)作、控制罢吃。組織中常見的資源有人力楚午、財(cái)力、物力尿招、信息等矾柜，所以我們的管理專業(yè)知識體系應(yīng)當(dāng)覆蓋人力資源管理阱驾、金融財(cái)務(wù)管理、市場營銷管理怪蔑、信息系統(tǒng)等里覆。管理是一門人與人之間的實(shí)踐科學(xué)，所以我們還應(yīng)當(dāng)了解組織行為學(xué)和心理學(xué)缆瓣，才能夠很好的對單個(gè)人或者一個(gè)群體進(jìn)行溝通聯(lián)系喧枷。
但是我們一般是在一個(gè)完整的企業(yè)組織內(nèi)部的一個(gè)中心或者部門，研發(fā)相關(guān)的組織應(yīng)當(dāng)如何管理呢弓坞。上面提到的知識體系實(shí)際上仍然需要隧甚，我們還是要對組織內(nèi)的各種資源進(jìn)行掌控，只是責(zé)任重心不同渡冻，或者有其他部門協(xié)助管理戚扳。針對研發(fā)相關(guān)還需要實(shí)施的管理行為，我認(rèn)為分為兩部分族吻。一部分是研發(fā)組織文化體系建設(shè)帽借、另外一部分是軟件工程管理。把研發(fā)組織文化體系建設(shè)放在前面超歌，是因?yàn)槲矣X得團(tuán)隊(duì)的習(xí)慣和目標(biāo)的高度砍艾，決定了產(chǎn)出的上限（或者說團(tuán)隊(duì)的管理者決定了整個(gè)團(tuán)隊(duì)的上限）。假如整體團(tuán)隊(duì)建設(shè)的高度不足握础，即使工程管理控制的再精妙合理辐董，也不會(huì)有超出預(yù)期的結(jié)果。
組織文化體系
組織文化體系建設(shè)的核心禀综，就是要以各種輔助手段简烘，統(tǒng)一整體團(tuán)隊(duì)習(xí)慣和目標(biāo)，達(dá)到團(tuán)隊(duì)效率最大化定枷。我將其分為兩部分孤澎，研發(fā)環(huán)境建設(shè)與研發(fā)制度建設(shè)。
研發(fā)環(huán)境建設(shè)：
-
研發(fā)標(biāo)準(zhǔn)工具集
IDE
系統(tǒng)分析/建模工具
編譯/反編譯/構(gòu)建工具
SCM工具
運(yùn)行環(huán)境
常用工具（數(shù)據(jù)庫相關(guān)/遠(yuǎn)程訪問）
-
過程管理
- Jira（迭代控制欠窒，Tempo工時(shí)）
-
知識庫
Confluence
Nexus
-
質(zhì)量管理
編碼規(guī)范（阿里規(guī)約（IDE集成））
Fisheye/Crucible
SonarQube
-
持續(xù)集成/交付（CI/CD）
Jenkins
Docker/Kubernetes
研發(fā)制度建設(shè)：
目標(biāo)制度（KPI覆旭，OKR）
培訓(xùn)制度（ 迭代/工作總結(jié)， 分享/定期培訓(xùn)岖妄， 新人入職培訓(xùn)）
職級/考核/晉升
這里期望使用各種工具和制度型将，能夠建立起一套完整、可靠荐虐、高效七兜，并且能夠量化輸出的輔助環(huán)境，最終引導(dǎo)形成“嚴(yán)謹(jǐn)福扬、高效腕铸、可靠惜犀、進(jìn)步”的研發(fā)團(tuán)隊(duì)文化。
軟件工程管理
大學(xué)時(shí)學(xué)習(xí)的課程就是Software Engineering狠裹，工作中更常提的概念是ALM（Application Lifecycle Management）虽界，使用的是(Computer Aided Software Engineering）CASE tools。
最早時(shí)我們學(xué)習(xí)的是瀑布涛菠、迭代莉御，那時(shí)候的生命周期基本劃分為需求、分析碗暗、設(shè)計(jì)（概要颈将、詳細(xì)）、編碼言疗、測試（單元晴圾、集成、系統(tǒng)）噪奄、交付死姚。當(dāng)時(shí)的互聯(lián)網(wǎng)沒有那么發(fā)達(dá)，項(xiàng)目往往是針對大型企業(yè)的定制管理系統(tǒng)勤篮，或者自己產(chǎn)品的定制系統(tǒng)（比如人月神話中的Brooks所主導(dǎo)的IBM360系統(tǒng)）都毒，在如今的互聯(lián)網(wǎng)時(shí)代，需求變化和響應(yīng)要求已經(jīng)越來越快碰缔，完整和重度的模式使用起來也就越來越困難账劲。但是也不能直接全盤否定，大型的ALM管理方法一般都會(huì)明確的劃分階段金抡、階段性里程碑與產(chǎn)物瀑焦，這些往往在敏捷的思想中是缺失的部分。所以我們最終整合出的ALM的管理方法就是以敏捷為核心思想梗肝，有選擇的使用大型過程管理方法作為實(shí)踐行為的理論指導(dǎo)榛瓮。這句話看起來有點(diǎn)的拗口，我們展開來講一下巫击。
我們的ALM方法實(shí)際上就是傳統(tǒng)與敏捷的方法整合禀晓，敏捷選擇的是Scrum，傳統(tǒng)（重量）的選擇的是RUP坝锰。先介紹一下這兩個(gè)方法的核心概念粹懒。
Scrum
Scrum的定義是一套敏捷框架用于知識工作的管理，實(shí)際上目前很多領(lǐng)域都嘗試在應(yīng)用并且僅僅限制于軟件開發(fā)顷级。Scrum是為3-9人的小組設(shè)計(jì)崎淳，用于在一個(gè)較短的時(shí)間段內(nèi)分解并且最終完成目標(biāo)的方法。當(dāng)中包含幾個(gè)核心概念：
角色（Roles）：Product owner愕把，Development team拣凹，Scrum master
工作流（Workflow）： Sprint， Sprint planning恨豁， Daily scrum嚣镜， Sprint review，Sprint retrospective等
產(chǎn)物（Artifacts）：Product backlog橘蜜，Sprint backlog菊匿， Product increment
這里給出兩張圖來介紹
1. Scrum的總覽，各個(gè)角色在工作流中的作用计福，以及何處產(chǎn)生產(chǎn)物跌捆。
2. 單純的迭代過程
評價(jià)：Scrum的特點(diǎn)是簡單。它設(shè)定了很少的角色象颖、流程佩厚、產(chǎn)物，目的是達(dá)到快速生產(chǎn)快速交付的目標(biāo)说订。對于中間產(chǎn)物的形態(tài)抄瓦、規(guī)格也沒有提到。乍一看大家都能理解陶冷，但是在實(shí)踐過程當(dāng)中钙姊，中間的詳細(xì)過程如何計(jì)劃、協(xié)作埂伦、控制就顯得模糊煞额，如果你不做任何要求或者規(guī)范甚至?xí)Э亍?/p>
RUP
相比RUP（Rational Unified Process），相信更多人聽過的應(yīng)該是CMMI（Capability Maturity Model Integration沾谜，即能力成熟度模型集成）膊毁，CMMI分為5級：
1. 初始級
軟件過程是無序的，有時(shí)甚至是混亂的类早，對過程幾乎沒有定義媚媒，成功取決于個(gè)人努力。管理是反應(yīng)式的涩僻。
2. 可管理級
建立了基本的項(xiàng)目管理過程來跟蹤費(fèi)用缭召、進(jìn)度和功能特性。制定了必要的過程紀(jì)律逆日，能重復(fù)早先類似應(yīng)用項(xiàng)目取得的成功經(jīng)驗(yàn)嵌巷。
3. 已定義級
已將軟件管理和工程兩方面的過程文檔化、標(biāo)準(zhǔn)化室抽，并綜合成該組織的標(biāo)準(zhǔn)軟件過程搪哪。所有項(xiàng)目均使用經(jīng)批準(zhǔn)、剪裁的標(biāo)準(zhǔn)軟件過程來開發(fā)和維護(hù)軟件坪圾，軟件產(chǎn)品的生產(chǎn)在整個(gè)軟件過程是可見的晓折。
4. 量化管理級
分析對軟件過程和產(chǎn)品質(zhì)量的詳細(xì)度量數(shù)據(jù)惑朦，對軟件過程和產(chǎn)品都有定量的理解與控制。管理有一個(gè)作出結(jié)論的客觀依據(jù)漓概，管理能夠在定量的范圍內(nèi)預(yù)測性能漾月。
5. 優(yōu)化管理級
過程的量化反饋和先進(jìn)的新思想、新技術(shù)促使過程持續(xù)不斷改進(jìn)胃珍。
從層級的命名可以看出這是一個(gè)從無管控到有管控最終到精細(xì)化管控的過程梁肿。相信經(jīng)歷過CMMI評級的朋友能夠體會(huì)其中的復(fù)雜度。你會(huì)需要一個(gè)委員會(huì)觅彰、若干的角色來主持整個(gè)生命周期吩蔑，過程中無數(shù)的文檔（word和excel）讓我印象極度深刻（也極度反感）。
相對于CMMI填抬，RUP更會(huì)讓我們產(chǎn)生好感烛芬。RUP的創(chuàng)作公司是Rational（IBM于2002年12月收購了Rational），UML就是由Rational公司的Grady Booch, Ivar Jacobson 和James Rumbaugh在1994–1995年設(shè)計(jì)的痴奏，Rational Rose也是UML建模最好用的軟件了蛀骇。這樣Rational公司不單單是ALM方法論，還配合UML和建模工具读拆，可執(zhí)行性會(huì)更強(qiáng)（但仍然是重型方法）擅憔。
RUP的核心概念包括：
角色：分析師（Analysts），開發(fā)者（Developers）檐晕，管理人員（Managers）暑诸，產(chǎn)品&支持（Production & Support），測試（Testers）辟灰，其他（General Roles）
四個(gè)順序的階段：初始階段（Inception）个榕、細(xì)化階段（Elaboration）、構(gòu)造階段（Construction）和交付階段（Transition）
-
九個(gè)核心工作流：
六個(gè)核心過程工作流（Core Process Workflows）：業(yè)務(wù)建模（Business Modeling），需求（Requirement），分析和設(shè)計(jì)（Analysis & Design）捣染，實(shí)現(xiàn)（Implementation），測試（Test）械馆，部署（Deployment）
三個(gè)核心支持工作流（Core Supporting Workflows）：配置和變更管理（Configuration & Change Management），項(xiàng)目管理（Project Management）武通，環(huán)境（Environment）
六個(gè)最佳實(shí)踐：迭代式開發(fā)（Develop iteratively）霹崎，管理需求（Manage requirements），組件化復(fù)用（Use components）冶忱，可視化建模（Model visually）尾菇，驗(yàn)證軟件質(zhì)量（Verify quality），控制軟件變更（Control changes）
RUP的階段和核心工作流：
舉例，初始階段的工作分解（WBS）
舉例：配置與變更管理工作流的工作流（Workflow）與工作分解（WBS）
評價(jià)：RUP提供了針對每個(gè)階段和核心工作流的詳細(xì)指導(dǎo)：who（角色）when（在什么階段/節(jié)點(diǎn)）how（如何做派诬，給定任務(wù)和目標(biāo)）what（目標(biāo)需要的結(jié)果產(chǎn)物）劳淆，在圖片中也能看到單個(gè)節(jié)點(diǎn)中若干個(gè)任務(wù)目標(biāo)的先后順序，前置步驟千埃，模型信息憔儿，任務(wù)類型，可計(jì)劃性等等放可。基本就是一個(gè)完整的指令集朝刊，如果有一個(gè)對于RUP深入理解的團(tuán)隊(duì)來主導(dǎo)耀里，能夠指揮幾百上千人為了某一個(gè)項(xiàng)目目標(biāo)共同努力。但是問題在哪里拾氓？冯挎？問題就是太復(fù)雜，如果這是一支軍隊(duì)咙鞍，RUP的戰(zhàn)術(shù)是很難被士兵甚至軍官所理解的房官，所有的行動(dòng)都必須由指揮團(tuán)隊(duì)發(fā)出，軍隊(duì)只能被動(dòng)的接收從而反應(yīng)续滋，無法主動(dòng)的采取行動(dòng)翰守，可以想象整個(gè)反應(yīng)過程會(huì)有多長∑Ｗ茫互聯(lián)網(wǎng)時(shí)代沒有這么多時(shí)間給到企業(yè)蜡峰，不沖鋒就長眠。
Scrum+RUP
Scrum的松散和RUP的復(fù)雜應(yīng)當(dāng)如何融合來散發(fā)更閃耀的光芒呢朗恳？我的理解就是使用Scrum來控制節(jié)奏湿颅，使用RUP來指導(dǎo)行動(dòng)。
項(xiàng)目組的角色分為Product owner（需求方）粥诫，Development team（產(chǎn)品研發(fā)測試）油航，Scrum master（迭代管理者）
迭代過程整合了Scrum與RUP的核心概念：
根據(jù)上圖，實(shí)際上主要分為三個(gè)部分：迭代邊界確認(rèn)怀浆，研發(fā)谊囚，測試與發(fā)布。
迭代邊界
迭代邊界確認(rèn)最終產(chǎn)生的是backlog揉稚，實(shí)際上就是一個(gè)任務(wù)清單（Epic/Story）秒啦，但是如何交付或者說結(jié)果呈現(xiàn)是什么呢？我們在很多Scrum的書籍中都看到看板搀玖，無論是電子還是實(shí)體余境，一個(gè)小紙條在不同區(qū)間內(nèi)移動(dòng)，顯然很多復(fù)雜需求如此管理是不夠的。我們從RUP的建模-需求-分析階段的要求中來尋找答案芳来。
RUP的業(yè)務(wù)建模圍繞的核心就是功能模型（用例圖）含末，需求分析設(shè)計(jì)主要的產(chǎn)出動(dòng)態(tài)模型（時(shí)序圖、活動(dòng)圖即舌、狀態(tài)圖）和對象模型（類圖佣盒、對象圖）。
我們實(shí)際工作中把迭代邊界的角色與產(chǎn)出做了如下定義：
- Development team 中的產(chǎn)品通過用例（UseCase）與PO確認(rèn)/分析需求顽聂。
1. 核心：Development team 中的產(chǎn)品通過用例（UseCase）最終產(chǎn)生產(chǎn)品原型（AxureRP）肥惭，原型需要包含PRD的規(guī)則說明部分。這樣實(shí)際最終交付就是產(chǎn)品原型（AxureRP文件紊搪，有審核）蜜葱，交付的目標(biāo)對象是Product owner，Development team中的開發(fā)耀石。
Development team 中的UI最終交付Sketch Measure標(biāo)注的設(shè)計(jì)文件牵囤。
Development team 中的研發(fā)根據(jù)需求描述做出粗略的研發(fā)內(nèi)容（接口數(shù)量與規(guī)模，業(yè)務(wù)邏輯變更點(diǎn)滞伟，數(shù)據(jù)結(jié)構(gòu)變更等）揭鳞，拆分任務(wù)，粗估工時(shí)梆奈。
Development team 中的測試根據(jù)需求描述編寫測試用例（我們使用的是Jira的Zephyr）野崇。
研發(fā)
研發(fā)的工作內(nèi)容主要是在開發(fā)和測試中進(jìn)行，研發(fā)的角色和產(chǎn)出定義如下：
Development team 中的開發(fā)人員進(jìn)行分析與設(shè)計(jì)鉴裹，通過產(chǎn)品和UI提供的交付物產(chǎn)生流程圖/時(shí)序圖/狀態(tài)圖等用于描述業(yè)務(wù)邏輯舞骆，類圖用于描述實(shí)體結(jié)構(gòu)變更和接口方法命名及參數(shù)。
Development team 中的開發(fā)人員使用***Flow工作流進(jìn)行代碼分支管理径荔，按照代碼規(guī)約和SonarQube的提示進(jìn)行代碼調(diào)整督禽，編寫單元測試。
1. Jenkins進(jìn)行持續(xù)集成总处，Development team 中的開發(fā)或者開發(fā)管理使用Fisheye/Crucible進(jìn)行代碼審核狈惫。
- Development team 中的測試根據(jù)測試用例進(jìn)行測試執(zhí)行與循環(huán)。
測試與發(fā)布
為什么是把測試和發(fā)布放在一起鹦马，而不是和研發(fā)放在一起呢胧谈？實(shí)際上研發(fā)階段部分完成的內(nèi)容就已經(jīng)會(huì)提交到測試環(huán)境進(jìn)行測試了，但是我們迭代的環(huán)境分為研發(fā)-測試-預(yù)發(fā)布-正式四個(gè)荸频，逐個(gè)推進(jìn)菱肖，而其中的主要推進(jìn)力量就是測試，也就是說功能只有測試通過的前提下才可以推進(jìn)至下一環(huán)境旭从。
Development team 中的測試在Bug修復(fù)后使用Jenkins發(fā)布到下一個(gè)待驗(yàn)證環(huán)境稳强。
Development team 中的測試使用Jira中的數(shù)據(jù)生成測試報(bào)告场仲。
總結(jié)
在上面的流程中，沒有提到的例如Daily scrum退疫， Sprint review等也是我們需要注意的執(zhí)行內(nèi)容渠缕。所以我們做到在Scrum的框架內(nèi)，使用RUP來進(jìn)行具體的行動(dòng)指導(dǎo)從而產(chǎn)出對于研發(fā)有實(shí)際意義的中間產(chǎn)物褒繁。但這個(gè)方案也不是完全固定的亦鳞，即使在CMMI和RUP中，實(shí)際上都有強(qiáng)調(diào)可裁剪棒坏，需要根據(jù)實(shí)際的項(xiàng)目和團(tuán)隊(duì)的情況（知識積累燕差、工期情況等等）來決定需要實(shí)施哪些步驟和內(nèi)容，最好是有一個(gè)能夠深入了解的教練式的領(lǐng)導(dǎo)來帶領(lǐng)俊抵。我們要達(dá)到的目標(biāo)就是文章頭部管理的定義：計(jì)劃谁不、組織、領(lǐng)導(dǎo)徽诲、協(xié)作、控制吵血。所有的人事物都是可管理的谎替，所有的目標(biāo)也都是可實(shí)現(xiàn)的。
