Find N3入網：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經正式入網，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
PMO 是干什么的？不就是個拉會的嘛？
這種根深蒂固的誤解，就像，你說你是學計算機的，別人以為你是修電腦的。如果你是這么想的，那這篇文章應該會重新認識項目管理，以及PMO這個角色。
我們之所以寫這篇文章，一是覺得國外傳到中國來的PMO守則、指導方針等，存在水土不服的問題，我們現在遇到的問題甚至可能都比國外還要復雜。二是，我們在得物飛速發展的過程中結合理論與實戰積累了一些經驗，希望可以跟相關從業者探討和交流。
文章從得物技術團隊的發展不同階段遇到的挑戰出發，PMO在不同階段的工作方向重心，實踐沉淀，能力建設演進等。
近幾年來，得物的業務百倍增長，得物技術團隊作為業務快速擴張的重要支撐，團隊規模在2年多時間內也發生了指數級的變化，以20倍+的速度快速增長，在此過程中，得物項目管理團隊-PMO和技術er協同摸索、實踐總結出了一套得物技術千人量級的規模化敏捷實踐。
圖片
與單個敏捷團隊通常選擇Scrum或者Scrumban的模式相比，得物PMO認為需要在此基礎上選擇適合自己的大規模敏捷框架，同時需要根據團隊發展的不同階段及時調整框架，而不能照搬業界熟知的框架，需要進行自創和優化。
本文將從得物技術部的敏捷迭代在落地過程中的實踐出發，對比敏捷行業敏捷實踐的共性及差異性，以大規模團隊的實踐做為切入點，以點帶面帶大家了解千人規模的敏捷迭代在得物的落地實踐。
電商業務本身屬于長流程業務，從產品上架到用戶下單再到履約，涉及到商品管理、訂單處理、支付結算、物流配送等多個方面。長流程的業務存在較重的上下游依賴情況，業務模式的復雜度疊加組織快速發展：新人快速進場、多地協同，端到端交付的協作復雜度呈指數級上升。
這些問題在不同行業、不同團隊規模、不同團隊成熟段階段都可能會遇到，大家都會有不同的切入點和解決方式，我們把上面的問題，歸因到兩類：
首先來看團隊劃分，團隊的組織形式和工作方式的選擇始終要與公司的發展階段相匹配，得物技術部從早期的100+人規模到現在的千人規模，過程中也伴隨著業產研團隊協作方式的變化，資源要根據公司的發展階段，以業務順利開展為第一調整目標快速做到支撐。
團隊組織方式的變化，先看下面的圖例：
圖片
可以看到在調整之前，團隊交付的組織形式是職能型的架構組織，資源按照共享的方式在使用，因為各業務都有自己的優先級，資源使用每次都要經過多輪溝通后才能達成一致，資源使用的溝通成本很高；在這個痛點下，與業務及產品溝通后，將技術部團隊交付組織形式進行了調整，調整后的團隊按照各個業務線進行了資源歸屬的劃分，一個業務線團隊支持著這個業務線下不同的產品或者功能交付；從這個虛擬團隊的組織形式可以看到Spotify的影子，Spotify Tribe對應業務線；Spotify Squard與該業務線下下一級的功能交付團隊相對應；Spotify Charter對應前后端等團隊的職能組織。
這樣的實踐經過百人規模向千人發展之后，逐漸進行了沉淀，形成了最終特性團隊(Feature Team)模式設計的矩陣型組織結構，旨在與業務模式相匹配，實現研發協同與管理模式的有效設計。該組織設計涉及橫向職能維度和縱向交付維度的雙向發力，具體體現在以下方面：
根據業務領域劃分特性團隊：將研發職能團隊劃分為多個特性團隊，每個團隊負責一個或多個業務板塊的研發交付工作，實現持續端到端交付用戶價值。
設置業務域PM統籌各職能角色：業務域PM負責統籌各職能角色，協同推動特性團隊實現業務目標。
職能TL專注組織發展：組織建設、人才發展，通過招聘、培訓和指導，提升團隊成員的技術能力和職業發展。
職能TL專注架構演進：職能TL聚焦技術基建、架構演進等工作，推動技術發展和創新。
通過這種組織架構設計，得物技術部能夠實現跨職能協作、端到端交付、業務目標導向和技術創新驅動等目標。特性團隊模式的應用有助于提高團隊的敏捷性、創新性和協作效率，使得技術部門更好地適應快速變化的市場需求和業務挑戰。
圖片
得物敏捷迭代在推廣落地過程中并沒有死搬硬套行業內的一些敏捷框架，諸如團隊級的敏捷框架Scrum甚至是組織級的大規模敏捷框架SAFE等，而是結合自身業務和團隊的特點，借鑒和落地好的敏捷實踐，形成了自己特色的解決方案。
其次我們來看業產研的協同，除了在組織架構的設計上保持靈活性之外，還結合敏捷項目管理方法，定義了適合得物產研的協同模式。
敏捷開發中，產研交付以用戶價值為導向，傳統項目管理的鐵三角（成本、時間、范圍）轉變為“約束”，在固定的時間周期內（Timebox），結合可用資源，交付高價值&高質量的需求。
圖片
需求在沒有上線之前只是假設（假設這樣做可以解決用戶的問題），敏捷開發中，通過需求拆分，高優先級需求識別及迭代交付機制，盡快將一個需求從提出推進到上線，能夠盡早收集用戶反饋，驗證需求價值，并及時響應變化。
圖片
基于以上，得物選擇了雙周迭代模式。基于的思考如下，1周時間較短，無法交付相對復雜的需求，同時對于存在App端的互聯網公司，頻繁發布也會打擾用戶。3周時間較長，對在做創新或者需要快速迭代的業務模式起不到試錯的效果。所以2周是一個相對剛好的節奏。
但是2周是一個整體節奏，并不是意味著所有需求必須等到2周才能發布，2周是最晚的發布窗口，在版本結束之前達到發布標準的可以任何時間發布，但是如果沒有趕上2周的窗口，那只能等下一趟；可以參考SAFe中的ART（Agile Release Train）的概念，火車不等人。
這里強調一下迭代周期和發布能力是要區分開的，對于APP的迭代周期來說是以兩周作為維度，但是發布是可以根據實際情況單周進行甚至任意時間點進行的動作。
得物有很多的業務線和對應的業務類項目，在每個迭代周期結束后，所有團隊都會同時調整資源的投入方向，甚至可能會在不同的業務域之間進行資源調配；在同一時間節點調整避免了因多迭代周期節奏在不同的窗口期調整帶來的協作成本并降低了人為風險。
另外，團隊規模變大后，一些效能相關度量指標及統計報告都會以迭代周期統計，如果各個業務域節奏不一，會導致數據的橫向沒有可比性，這也是在制定迭代周期時容易被忽視的地方。
最后，當解決了團隊資源和產研協同的問題之后，持續改進效率問題就變得尤為重要，在這里我們不討論coding本身的效率，一起來探討如何有效的設置研發效能度量指標才能真正的幫助到我們做到持續改進。
沒有度量就沒有改進的方向，設置合理的度量指標事半功倍，否則度量會變成笑話，給團隊帶來負面影響。
舉個簡單粗暴的例子：人均完成需求數/每迭代；我相信大家都不會選擇這個指標是因為軟件開發本身是一個基于變量（需求大小、人員成熟度、開發環境及上下游環節）進行的工作，這與機械制造行業的流水線工序是完全不同的工作，不能夠用工業標準的思維來衡量軟件質量開發。所以要做好研發效能的度量要有一些基本的原則，才能用指標更好的評估現狀，為團隊持續改進提供正確的方向。
得物技術部基于以上的原則制定了研發和測試過程指標，從交付速率，內建質量，持續發布能力及線上質量幾個維度定義了一系列指標，在此我們不一一展開。
對以上的思路進行整理，我們用以下一些字母來進行釋義，可以簡單的稱之為：Type-P：
在整體闡述Type-P時，為了方便理解，引用主流的規模化敏捷LESS、SAFE作為參考。
Type-P、LESS、SAFE是基于不同的背景、邏輯所構建的項目管理實踐方法，只有左右之別，不存在高低之分。借鑒意義并非是非此即彼的。
圖片
各類資源數各域固定；
各域單獨一份product backlog，業務一號位決策，域內優先級決策高效。
在抽象出Type-P的核心原則的過程中，發現和Type-C的命名非常相似，也期望得物所特有的Type-P在經過過去、現在、未來的努力之后，不僅是得物特色，也能同Type-C一樣，成為一種業界通用的“標準接口”，給更多同業/同行更多的參考、借鑒意義。
敏捷實踐過程的落地離不開PMO團隊，這個過程中PMO首先承擔了以下的一些工作。
這些工作其實業內大部分團隊是一樣的，但是隨著團隊人數的增多，團隊成熟度的變化，敏捷實踐階段的改變，PMO團隊的定位和方向也是隨著變化的。
從“吞吐優先”向“價值優先”過渡。流程落地、項目管理工具落地是在實踐過程的前期一定會去做的事情，這個落地過程中的問題也會因為各種因素層出不窮，這個階段的落地目標也會把團隊的吞吐情況作為第一目標去完成。
當落地階段完成之后，常規PMO團隊所需要完成的事項就變成了基礎工作，團隊目標也從“吞吐率”轉向了“價值”，這里的價值有兩層含義：第一是需求和項目的交付更注重業務本身的價值，形成端到端的閉環，從需求提出本身的價值角度判斷優先級，提升團隊交付的意義。在業內，很多團隊的閉環交付受到業務形態和外部因素的影響，在尾部復盤階段會推行的很艱難。第二是PMO自身在職能團隊和業務團隊中的價值，幫助團隊找到流程卡點和人效洼地，提出改進方案和提升研發團隊效能產出。這需要PMO和團隊建立足夠的信任感，提升自身在團隊的影響力，信任感的建立不是一朝一夕的，需要在日常的工作中真正幫助到了團隊，才會逐漸形成。
這個目標看似簡單，但是實際過程中還是會有很多難點，需要得物的PMO具備更強的個人綜合實力和軟技能，業務感知力、數據分析能力、談判技巧、團隊洞察力、社交能力等，迭代和項目管理是基本盤，需要花更多的時間在技術團隊的人效提升上，哪怕是交流溝通去建立信任，也是一件花時間的事情。
本文先從團隊發展的角度，看我們遇到的一些挑戰；第二部分針對這些挑戰，不斷去嘗試解題思路；這些挑戰是從實際出發，結合實際問題我們歸納到兩類，一個是資源，一個是協同。那從資源協同的角度，我們怎么抽象化地解這個問題？解這個問題就兩個思路，一個是解資源的，另一個是解協同的，協同上又用到了價值導向、小步快跑和雙周迭代的思路。不管是協同、資源、還是問題也好，都會牽涉到「研發效能度量」，通過上文的思路和舉措，基本上就是把我們遇到的挑戰給解決了。另外，也補充說明了得物特色的敏捷管理思路Type-P，區分主流項目管理框架，因地制宜，打造了得物特色千人敏捷項目管理。
每家公司所處的行業，階段各不相同，敏捷宣言也已經從1.0升級到了2.0，隨著AI時代的到來，符合各自敏捷場景的落地又會有更多的變化和挑戰，希望通過上面的一些介紹，能給大家在敏捷落地過程中有一些啟發，也希望大家可以擁抱變化，一起交流，共同進步，開創一個屬于我們自己的敏捷時代。
本文鏈接：http://www.www897cc.com/showinfo-26-80830-0.html千人規模敏捷迭代實踐分享，你學會了嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： .NET WebAPI 自定義返回類：實現統一與靈活的API響應
下一篇： 面試官：聽說你很懂線程池？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號