如何進行軟件技術管理？

目錄

• 引言
• 組織文化體系
• 軟件工程管理
  • Scrum
  • RUP
  • Scrum+RUP

這個問題其實來源於一次面試，在聊完一堆的技術架構以後，面試官拋出一個問題：「你是怎麼進行研發管理的工做的？」當時個人回答是：「主要是應用Scrum來進行管理。」後續的狀況不細說，可是我以爲我這句話來歸納以前近10年的管理經歷，實在是太弱了。後面我就思考該如何真正回答好這個問題，我也去讀了廈大的MEM，下面就是我以爲能夠很好迴應的一個答案。

引言

廣義上的管理，指的是必定組織中的管理者實施的行爲 ，目的是達到共同目標。管理有五個核心要素：計劃、組織、領導、協做、控制。組織中常見的資源有人力、財力、物力、信息等，因此咱們的管理專業知識體系應當覆蓋人力資源管理、金融財務管理、市場營銷管理、信息系統等。管理是一門人與人之間的實踐科學，因此咱們還應當瞭解組織行爲學和心理學，纔可以很好的對單我的或者一個羣體進行溝通聯繫。
可是咱們通常是在一個完整的企業組織內部的一箇中心或者部門，研發相關的組織應當如何管理呢。上面提到的知識體系實際上仍然須要，咱們仍是要對組織內的各類資源進行掌控，只是責任重心不一樣，或者有其餘部門協助管理。針對研發相關還須要實施的管理行爲，我認爲分爲兩部分。一部分是研發組織文化體系建設、另一部分是軟件工程管理。把研發組織文化體系建設放在前面，是由於我以爲團隊的習慣和目標的高度，決定了產出的上限（或者說團隊的管理者決定了整個團隊的上限）。假如總體團隊建設的高度不足，即便工程管理控制的再精妙合理，也不會有超出預期的結果。

組織文化體系

組織文化體系建設的核心，就是要以各類輔助手段，統一總體團隊習慣和目標，達到團隊效率最大化。我將其分爲兩部分，研發環境建設與研發制度建設。

研發環境建設：

• 研發標準工具集
  • IDE
  • 系統分析/建模工具
  • 編譯/反編譯/構建工具
  • SCM工具
  • 運行環境
  • 經常使用工具（數據庫相關/遠程訪問）
• 過程管理
  • Jira（迭代控制，Tempo工時）
• 知識庫
  • Confluence
  • Nexus
• 質量管理
  • 編碼規範（阿里規約（IDE集成））
  • Fisheye/Crucible
  • SonarQube
• 持續集成/交付（CI/CD）
  • Jenkins
  • Docker/Kubernetes

研發制度建設：

• 目標制度（KPI，OKR）
• 培訓制度（ 迭代/工做總結， 分享/按期培訓， 新人入職培訓）
• 職級/考覈/晉升

這裏指望使用各類工具和制度，可以創建起一套完整、可靠、高效，而且可以量化輸出的輔助環境，最終引導造成「嚴謹、高效、可靠、進步」的研發團隊文化。

軟件工程管理

大學時學習的課程就是Software Engineering，工做中更常提的概念是ALM（Application Lifecycle Management），使用的是(Computer Aided Software Engineering）CASE tools。
最先時咱們學習的是瀑布、迭代，那時候的生命週期基本劃分爲需求、分析、設計（概要、詳細）、編碼、測試（單元、集成、系統）、交付。當時的互聯網沒有那麼發達，項目每每是針對大型企業的定製管理系統，或者本身產品的定製系統（好比人月神話中的Brooks所主導的IBM360系統），在現在的互聯網時代，需求變化和響應要求已經愈來愈快，完整和重度的模式使用起來也就愈來愈困難。可是也不能直接全盤否認，大型的ALM管理方法通常都會明確的劃分階段、階段性里程碑與產物，這些每每在敏捷的思想中是缺失的部分。因此咱們最終整合出的ALM的管理方法就是以敏捷爲核心思想，有選擇的使用大型過程管理方法做爲實踐行爲的理論指導。這句話看起來有點的拗口，咱們展開來說一下。
咱們的ALM方法實際上就是傳統與敏捷的方法整合，敏捷選擇的是Scrum，傳統（重量）的選擇的是RUP。先介紹一下這兩個方法的核心概念。

Scrum

Scrum的定義是一套敏捷框架用於知識工做的管理，實際上目前不少領域都嘗試在應用而且僅僅限制於軟件開發。Scrum是爲3-9人的小組設計，用於在一個較短的時間段內分解而且最終完成目標的方法。當中包含幾個核心概念：

• 角色（Roles）：Product owner，Development team，Scrum master
• 工做流（Workflow）： Sprint， Sprint planning， Daily scrum， Sprint review，Sprint retrospective等
• 產物（Artifacts）：Product backlog，Sprint backlog， Product increment

這裏給出兩張圖來介紹

1. Scrum的總覽，各個角色在工做流中的做用，以及何處產生產物。
   

2. 單純的迭代過程
   
   評價：Scrum的特色是簡單。它設定了不多的角色、流程、產物，目的是達到快速生產快速交付的目標。對於中間產物的形態、規格也沒有提到。乍一看你們都能理解，可是在實踐過程中，中間的詳細過程如何計劃、協做、控制就顯得模糊，若是你不作任何要求或者規範甚至會失控。

RUP

相比RUP（Rational Unified Process），相信更多人聽過的應該是CMMI（Capability Maturity Model Integration，即能力成熟度模型集成），CMMI分爲5級：

1. 初始級
   軟件過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決於我的努力。管理是反應式的。
2. 可管理級
   創建了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重複早先相似應用項目取得的成功經驗。
3. 已定義級
   已將軟件管理和工程兩方面的過程文檔化、標準化，並綜合成該組織的標準軟件過程。全部項目均使用經批准、剪裁的標準軟件過程來開發和維護軟件，軟件產品的生產在整個軟件過程是可見的。
4. 量化管理級
   分析對軟件過程和產品質量的詳細度量數據，對軟件過程和產品都有定量的理解與控制。管理有一個做出結論的客觀依據，管理可以在定量的範圍內預測性能。
5. 優化管理級
   過程的量化反饋和先進的新思想、新技術促使過程持續不斷改進。

從層級的命名能夠看出這是一個從無管控到有管控最終到精細化管控的過程。相信經歷過CMMI評級的朋友可以體會其中的複雜度。你會須要一個委員會、若干的角色來主持整個生命週期，過程當中無數的文檔（word和excel）讓我印象極度深入（也極度反感）。
相對於CMMI，RUP更會讓咱們產生好感。RUP的創做公司是Rational（IBM於2002年12月收購了Rational），UML就是由Rational公司的Grady Booch, Ivar Jacobson 和James Rumbaugh在1994–1995年設計的，Rational Rose也是UML建模最好用的軟件了。這樣Rational公司不僅僅是ALM方法論，還配合UML和建模工具，可執行性會更強（但仍然是重型方法）。

RUP的核心概念包括：

• 角色：分析師（Analysts），開發者（Developers），管理人員（Managers），產品&支持（Production & Support），測試（Testers），其餘（General Roles）
• 四個順序的階段：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）
• 九個核心工做流：
  • 六個核心過程工做流（Core Process Workflows）：業務建模（Business Modeling），需求（Requirement），分析和設計（Analysis & Design），實現（Implementation），測試（Test），部署（Deployment）
  • 三個核心支持工做流（Core Supporting Workflows）：配置和變動管理（Configuration & Change Management），項目管理（Project Management），環境（Environment）
• 六個最佳實踐：迭代式開發（Develop iteratively），管理需求（Manage requirements），組件化複用（Use components），可視化建模（Model visually），驗證軟件質量（Verify quality），控制軟件變動（Control changes）

RUP的階段和核心工做流：

舉例，初始階段的工做分解（WBS）

舉例：配置與變動管理工做流的工做流（Workflow）與工做分解（WBS）

評價：RUP提供了針對每一個階段和核心工做流的詳細指導：who（角色）when（在什麼階段/節點）how（如何作，給定任務和目標）what（目標須要的結果產物），在圖片中也能看到單個節點中若干個任務目標的前後順序，前置步驟，模型信息，任務類型，可計劃性等等。基本就是一個完整的指令集，若是有一個對於RUP深刻理解的團隊來主導，可以指揮幾百上千人爲了某一個項目目標共同努力。可是問題在哪裏？？問題就是太複雜，若是這是一支軍隊，RUP的戰術是很難被士兵甚至軍官所理解的，全部的行動都必須由指揮團隊發出，軍隊只能被動的接收從而反應，沒法主動的採起行動，能夠想象整個反應過程會有多長。互聯網時代沒有這麼多時間給到企業，不衝鋒就長眠。

Scrum+RUP

Scrum的鬆散和RUP的複雜應當如何融合來散發更閃耀的光芒呢？個人理解就是使用Scrum來控制節奏，使用RUP來指導行動。
項目組的角色分爲Product owner（需求方），Development team（產品研發測試），Scrum master（迭代管理者）
迭代過程整合了Scrum與RUP的核心概念：

根據上圖，實際上主要分爲三個部分：迭代邊界確認，研發，測試與發佈。

迭代邊界

迭代邊界確認最終產生的是backlog，實際上就是一個任務清單（Epic/Story），可是如何交付或者說結果呈現是什麼呢？咱們在不少Scrum的書籍中都看到看板，不管是電子仍是實體，一個小紙條在不一樣區間內移動，顯然不少複雜需求如此管理是不夠的。咱們從RUP的建模-需求-分析階段的要求中來尋找答案。
RUP的業務建模圍繞的核心就是功能模型（用例圖），需求分析設計主要的產出動態模型（時序圖、活動圖、狀態圖）和對象模型（類圖、對象圖）。
咱們實際工做中把迭代邊界的角色與產出作了以下定義：

1. Development team 中的產品經過用例（UseCase）與PO確認/分析需求。
2. 核心：Development team 中的產品經過用例（UseCase）最終產生產品原型（AxureRP），原型須要包含PRD的規則說明部分。這樣實際最終交付就是產品原型（AxureRP文件，有審覈），交付的目標對象是Product owner，Development team中的開發。
3. Development team 中的UI最終交付Sketch Measure標註的設計文件。
4. Development team 中的研發根據需求描述作出粗略的研發內容（接口數量與規模，業務邏輯變動點，數據結構變動等），拆分任務，粗估工時。
5. Development team 中的測試根據需求描述編寫測試用例（咱們使用的是Jira的Zephyr）。

研發

研發的工做內容主要是在開發和測試中進行，研發的角色和產出定義以下：

1. Development team 中的開發人員進行分析與設計，經過產品和UI提供的交付物產生流程圖/時序圖/狀態圖等用於描述業務邏輯，類圖用於描述實體結構變動和接口方法命名及參數。
2. Development team 中的開發人員使用***Flow工做流進行代碼分支管理，按照代碼規約和SonarQube的提示進行代碼調整，編寫單元測試。
3. Jenkins進行持續集成，Development team 中的開發或者開發管理使用Fisheye/Crucible進行代碼審覈。
4. Development team 中的測試根據測試用例進行測試執行與循環。

測試與發佈

爲何是把測試和發佈放在一塊兒，而不是和研發放在一塊兒呢？實際上研發階段部分完成的內容就已經會提交到測試環境進行測試了，可是咱們迭代的環境分爲研發-測試-預發佈-正式四個，逐個推動，而其中的主要推動力量就是測試，也就是說功能只有測試經過的前提下才能夠推動至下一環境。

1. Development team 中的測試在Bug修復後使用Jenkins發佈到下一個待驗證環境。
2. Development team 中的測試使用Jira中的數據生成測試報告。

總結

在上面的流程中，沒有提到的例如Daily scrum， Sprint review等也是咱們須要注意的執行內容。因此咱們作到在Scrum的框架內，使用RUP來進行具體的行動指導從而產出對於研發有實際意義的中間產物。但這個方案也不是徹底固定的，即便在CMMI和RUP中，實際上都有強調可裁剪，須要根據實際的項目和團隊的狀況（知識積累、工期狀況等等）來決定須要實施哪些步驟和內容，最好是有一個可以深刻了解的教練式的領導來帶領。咱們要達到的目標就是文章頭部管理的定義：計劃、組織、領導、協做、控制。全部的人事物都是可管理的，全部的目標也都是可實現的。