2016年作為項目經理管理了一個40多人的xxxx項目，從需求調研到產品上線、出票歷經三個多月。項目實施是一個臨時抽調研發、產品、測試的研發團隊開展敏捷的項目，為了完成這個項目用了各種能想到的辦法（敏捷、看板管理、封閉開發等等），經歷各種項目風險，回頭來看還是有很多寶貴的經驗。

在項目上線后POST-MORTEM問卷中，有研發人員寫到：

1研發：我們最大的問題在于變化太快，沒有想好的需求就去實現以至于最后返工。

2產品：我們的困難在于溝通，我需要一遍遍的講解需求才能讓研發、測試人員理解。我們甚至在每天的早晨都要過一遍相關的事情。晨會的時候我發現對方壓根沒理解。

3子項目經理：我們有很大的項目依賴，要實現這個功能，我要修改abcdefg內部各系統。至少三個月改完，并且還需要abcdefg部門配合我修改，并且在我上線前改完：（目前對方沒有回復我的郵件）。

4群眾：我覺得這個項目不是真正敏捷。

最后一個意見對我的打擊比較大，因為這個項目的所有研發經理都參加過項目經理培訓。至少在項目共識上是沒問題的。為什么研發人員對此過程有這么大的意見？我開始反思敏捷的意義。

形：在敏捷方法中，尚未完成的工作被稱為backlog積壓工作。如果您開始將工作分配給小交付增量（被稱為sprint沖刺），分配給某個沖刺的工作被稱為沖刺積壓（sprint backlog）。分配給未來沖刺的剩余工作被稱為項目積壓（projectbacklog）。我們在實施的時候，盡可能將更多的變更分解為合理的backlog，并且安排資源在sprint中去實現這些被人工安排的sprint backlog。對于形來說項目經理只是一個做庖丁解牛的屠夫和烹飪的大師傅。

知其形而不理解其意才會誤解自己所做的事情，不是真正的敏捷。實際的意是什么？

意：敏捷概念是將工作拆分成為易于管理的小塊。更加容易的去管理這種小塊；以及更早地改正錯誤；更科學的隔離風險。這樣可以避免它們稍后在項目中發展成為更大、更難解決的問題。好處之一是能夠提供在項目時間表中多個日期進行構建和測試的更小的功能性發布。通過驗證分片的交付，每個交付都降低了項目風險。另一個顯而易見的好處是應付突如其來的變更，部分變不能影響全局。

經歷過痛苦的項目過程后，我開始將敏捷的管理思路投入到實際研發過程管理中。

1實際遇到的管理問題在于第一個管理的面太大，需要切分成塊進行管理。合而為之；分而治之。各塊需要管理好自己的事情。對于改變世界的程序員來說，dogfooding自己的狗糧自己吃。

2管理方式需要根據團隊實際情況，了解同行后發現各個互聯網公司全面實行敏捷的并不多。這其中原因很多，主要問題還是資源足夠多，對質量要求比較高。另一個實際原因是目前研發團隊達不到有一個統管全局的Scrummaster和一個解決所有問題的fire man。我們實際要的是把事情做成，對形式并不在乎。只要能夠達到敏捷管理的意，并不需要太重于形。

3需要一步步解決實際問題，不能只看到冰山一角忽視了水下風險。很多事情只是表面問題，鬧哄哄的爭執，實際并不是提測晚了可能是研發資源不夠。如果要是只關注當下不去解決實際問題。可能下次你還會遇到。

對于CI

(continuous integration)來說，敏捷管理、持續集成、自動化測試是最為關鍵的三部分。重點分享下目前我們的敏捷管理、和自動化測試部分的經驗。（以下不涉及技術層面，單列討論）

1管理手段：告別人工管理進入自動化系統管理。首先是度量，沒有度量就沒有管理（引用：彼得格魯克）。如果不知道目前現有的研發水平你會無從下手。第一件事情就是要建立起研發管理體系，將所有研發過程數據進入監控。我們分批次分優先級，經歷了半年多將50多個過程指標納入過程管理。并建立起項目、測試、質量三種維度的報表。

2研發過程的管理次序：優先保證結果，再看過程。我們是先從上線抓起的。做好上線管理加強測試、上線計劃和過程的結果，優先做好交付部分。結果保證后，加強過程管理。通過研發管理系統保障，從研發后期的階段往前推進，做好提測、編碼、需求等等各種過程。一步步來，先做好后面一步再往前推進。

3研發過程的層次：研發部分錯綜復雜，需要分層次管理。長期的優先級高的走項目管理，上線后正常運營的走迭代需求管理。特別高層次的項目需求，安排專人跟蹤進入重點項目和總裁需求管理。分層次、不同管理方式將各種品類、研發過程建立起高速、省道、和航線。高速的在天上飛，低速的在地面跑。第一流的團隊優先承擔高優先級項目，新人多、不成熟的團隊先從迭代練起。另一個要講的就是要有始有終，進入研發管理。就需要從開始到結束，不能做到一半就不管了。所有的項目、需求從開始必須走到結束或者暫停、延期。

4質量管控：

4.1做好了過程，結果自然有；質量并不是測試人員一個角色能夠搞定的。從研發過程就有質量意識，做好測試覆蓋、上線管理以及線上質量保證。質量管控并不是很難的事情。看你是不是重視質量，投入多少資源去做。

4.2先做好研發質量再看產品質量，通過業務監控，正向的推動產品質量的進一步完善。形成業務、質量的雙向正向循環。

4領導力的層次要求：領導力的五個層次至少需要達到第三層貢獻。認同和貢獻是相輔相成的。認同你所作出的貢獻，配合你的工作。這樣各種角色才能夠互相協作起來，把事情做好。很多人只埋頭做事情，并不重視影響力，這也是很多時候工作難以推進的地方！

5自動化測試實踐：自動化測試作為工作重點，需要長期的投入。互聯網變化快，需要大量的regressiontest。資源卻只能剛剛滿足feature test,每周幾百個變更如何保證質量？顯而易見的自動化回歸必須做起來，將正確的功能和變更部分隔離開。這里的思路和GIT（配置管理工具）的思路是一致的，知道變更在哪，隔離風險。對于遇到各種疑難雜癥的時候常用大絕招不過于重啟、回滾和擴容三招，那么自動化測試對于CI來說太關鍵了。重啟、回滾壓根沒有必要上到生產才發現，我們在后端的環境就能察覺，這種風險變更壓根不會發到生產區。另一個要強調的就是自動化測試強調執行和持續改進。

6展望：哈哈太多了，只想一步步把眼前事情做好。

喜歡和大家溝通，歡迎多提意見。謝謝大家對工作的理解。

請勿轉發