devops最近成了熱詞，望文生義，你也能猜個**不離十，它就是在說"研發團隊"與"運維團隊"之間的那點事兒。那麼，到底什麼是"devops"呢？
wikipedia上說："devops是軟體開發、運維和質量保證三個部門之間的溝通、協作和整合所採用的流程、方法和體系的乙個集合。它是人們為了及時生產軟體產品或服務，以滿足某個業務目標，對開發與運維之間相互依存關係的一種新的理解。"這恰好體現了精益管理中的客戶價值原則，即：以客戶的觀點來確定企業從設計到生產交付的全部過程，實現客戶需求的最大滿足。我們也可以把devops看作是一種能力，在缺乏這種能力的組織中，開發與運維之間存在著資訊"鴻溝"。
如何獲得這種能力呢？關鍵有兩點：一是全域性觀：要從軟體交付的全域性出發，加強各角色之前的合作；二是自動化：人機互動就意味著手工操作，應選擇那些支援指令碼化、無需人機互動介面的強大管理工具，比如各種受版本控制的script，以及類似於nagios這樣的基礎設施監控工具，類似於puppet、chef這樣的基礎設施配置管理工具。
既然devops關注於價值交付的全過程，那就讓我們看看該產品線常見的交付過程吧。
對於單個專案來說，它大體上是乙個典型的瀑布開發過程。首先是需求收集與整理，撰寫mrd(marketing requirement document)或總體設計後，進行評審。如果涉及到多模組，每個模組的開發人員會對各自負責的模組進行詳細設計，給出大致的開發計畫，並商定聯調時間點。之後，開發人員會從主幹上拉出專案分支，並在該分支上進行開發。當到最後聯調點時，幾個開發人員才會在將**合在一起，進行聯調。當調通之後，開發人員再申請提測。測試人員接到提測申請單後，進行測試，記錄bug，通知開發人員修復，直致質量達到標準。之後，開發人員會填寫上線申請單，經運維人員確認後，運維人員操作進行上線部署工作。如圖所示。
開發的複雜性還在於：該產品線有很多並行專案，為了避免互相干擾可能帶來的衝突，每個專案啟動後都會重新在主幹上拉出分支，在上線前才進行合併。如下圖所示。
另外，並行專案太多，導致每個開發人員會同時參與多個處於不同階段的專案。那些週期較長的專案雖然會被分解成多個迭代，但每個迭代內都是同樣的開發流程，只是最後僅有一次上線而已。
總而言之，突出的問題表現在：
同一角色多個人員的合作開發；
各角色部門之間的協作以各自的產品物為目標，如mrd、產品**、測試用例、上線操作單；
基於人機互動方式的內部流程管理平台。
從精益思想出發，為了盡早交付價值，必須首先找出整個流程中的浪費，並將其消除，從而提高流程效率，讓"乙個想法從提出到實現"可在最短時間裡完成。那麼，浪費到底表現在**呢？
另外，該產品的乙個重要特徵是需要不斷地嘗試調整程式演算法策略，以得到最佳的流量效果，而這種調整的頻率較高（至少每週一次）。當需要調整策略時，開發人員修改**後重新進行編譯打包，由於產品**發生變化，所以測試人員仍需要進行大量的回歸測試，而運維人員在部署時也需要將對二進位制檔案包進行整體部署，整個週期比較長。
從上面這些內容中，我們不難發現，流程中更傾向於將問題推遲到後面解決（比如最後整合聯調），將工具（平台、郵件、即時通訊）作為協作的基礎，而角色間的溝通幾乎完全依賴於前乙個環節的產物（比如mrd、產品**、上線步驟）。那麼我們使用哪些對策進行優化，達到消除浪費的目的呢？
新的開發流程如下圖所示。
分支開發策略變更為single branch模式。
通過以上改進措施，讓團隊的合作方式發生了重大變化，從"碉堡防禦"走向了"戰線統一"。
原來，各角色僅關注於自己本身的工作，雖然大家都同處於乙個專案中，但各自劃分了"領地"，產品經理就應該將mrd寫得清清楚楚，如果開發人員認為不清楚，那就回去再改。開發人員只管按照mrd上的內容進行開發，很少考慮可測性和易測性問題。測試人員只管按照mrd中內容來測試，有問題通過內部工作流平台提交問題單。運維人員只管根據開發人員提交的上線操作單進行操作。似乎各角色之間的溝通介質只有各自的"交付物"。
現在，各角色都能夠共同合作，以專案的最終交付為目標，積極討論需求，優化實現。因為角色之間的這種緊密合作讓所有人對不同角色都有了深入的了解。開發人員耐心為產品經理解釋技術實現，說明計畫安排，測試人員與開發人員共同討論驗收條件，避免遺漏需求。開發人員讓運維人員了解架構設計， 細心聽取運維人員的建議，進行技術改造，使部署工作更快捷有效。
通過這些活動，大家都認識到原有內部管理平台僅是個公文流轉的支撐平台，要想提高工作效率，就要將這種"辦公自動化工具"進一步提公升為"全面自動化工具"，使所有人更關注於端到端的價值，而非各角色之間的分界點。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...