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