PMP^®項目案例：PM如何快速上手敏捷模型開發(fā)？

一、本期話題

如何快速上手敏捷模型開發(fā)？

二、背景介紹

新入職一家公司，行業(yè)跨度很大(從應用軟件轉(zhuǎn)為操作系統(tǒng)那種)，完全不了解新公司的業(yè)務。

項目管理方式區(qū)別也很大，以前的項目類型是定制化的交付項目，采用傳統(tǒng)瀑布型模式管理，現(xiàn)在的項目的內(nèi)部研發(fā)項目，采用SCRUM敏捷模型開發(fā)。領導又著急讓新人上手。

目標：如何快速接手敏捷項目？

三、嘉賓分享

01用戶昵稱：Fiona

這邊我想幾個我個人比較看重的敏捷的幾個要點：

1、盡早和持續(xù)的交付有價值的軟件給客戶；

2、敏捷歡迎變更，對每個故事進行優(yōu)先級排序(做到一半的時候，有新的緊急的需求進來，那么產(chǎn)品可以考慮重新排列優(yōu)先級，在當前迭代中可以把優(yōu)先級較低的需求移到下一個迭代，擁抱變更不是指無限增加工作!)；

3、敏捷不做長期詳盡的規(guī)劃，一般只做短期規(guī)劃(比如這2周或者這1個月要完成的目標)。

我下面會從5個會議以及我目前使用的看板進行闡述下。敏捷需要做好的5個會議：

1、需求評審會

澄清需求，很多公司比如我們之前沒有進行需求澄清，導致開發(fā)不理解需求，基本是按照開發(fā)自己怎么想就怎么做，最后的結(jié)果就是返工了，評審會建議團隊都參加，確保有問題可以及時理清。

2、計劃會

分配這1-2周需要完成的故事點數(shù)，故事拆分要遵從INVEST原則，我們開發(fā)中的經(jīng)驗是更注重，小的，獨立的，可測試的，拆分故事可以使用的方法很多，比如計劃撲克，相對規(guī)模估計等等，這個之前群里有討論過，這里就不贅述了;目前我公司拆分的故事原則是一個故事不超過2周，并且故事要明確驗收規(guī)則。

3、每日站會

溝通進度，站會上只溝通 昨天做了什么;今天要做什么;目前有遇到什么問題;時間限制在15分鐘內(nèi);團隊成員最佳在5-9人，如果團隊過大，建議劃分成小組進行;目前我公司是有使用看板，每日站會都在看板前進行

4、產(chǎn)品迭代功能演示會

開發(fā)在完成產(chǎn)品功能后，需要先演示給產(chǎn)品看，確認功能符合期望，避免驚喜

5、回顧會

目前我們公司是每2周一次，總結(jié)回顧(15分鐘-1小時)，這邊要注意下，回顧會不是批判會議，可以不邀請大領導參加會議，不然容易變成大家都不敢說或者變成甩鍋大會;回顧會重要的一點是要形成改進措施，在下一個階段可以有所進步，保證迭代更加穩(wěn)定的進行。

（這是我目前在用的看板規(guī)劃）

（用戶故事）

（任務貼）

當然要做好敏捷，還有很長的路要走，指導團隊了解理解敏捷；目前我們公司每個季度會對每個小組的敏捷成熟度進行評估，可以建議公司在每個季度前，讓小組設定敏捷季度OKR目標，比如：1、團隊成長目標 2、效能提升目標 3、質(zhì)量提升目標。

除了OKR評分，每個季度我們還會進行敏捷成熟度的評估，一下子做好敏捷很難，但是大家可以一點一點累積。

我建議題主可以從以上5個會議以及OKR進行敏捷切入指導團隊共同參與敏捷，使用敏捷。

02用戶昵稱：李昀

看到這位道友能提出這樣的問題，應該是已經(jīng)懵了。

換到一個新的環(huán)境，不只是你，很多人都有這樣的困惑，特別是中途接手一個既不熟悉業(yè)務，至于如何快速的熟悉流程，特別是敏捷環(huán)境的流程可以議一議。

從組織背景和行業(yè)背景來看，這個企業(yè)規(guī)模不小。

從組織形式來看，我猜測，這是一個剛剛做敏捷轉(zhuǎn)型不長的企業(yè)，且這個轉(zhuǎn)型在我看來也不算是太成功，類似于一個將特性迭代加入門禁控制的螺旋結(jié)構(gòu)的產(chǎn)品開發(fā)，我們暫且不論他是不是敏捷，至少他里面有一些Scrum的影子，且我大膽猜測這個項目組之前在人員上出現(xiàn)了一些問題，才會有這種情況

1、千萬別害怕，不會學就是。沒有誰生來就會，不會或者不懂都是正常的，環(huán)境切換是要花費一些學習成本的，不會就學是人類與其他物種的最根本區(qū)別，最基本的情況是，盡快的把scrum的基本方法的過程熟悉起來，對3355要有個理解，更進一步的要對應到你熟悉的知識領域，一方面，要了解一下《Scrum指南的內(nèi)容》，另外一方面要去找一些網(wǎng)絡的資料，比如說創(chuàng)造營中的分享【敏捷是什么】， 另外如果有精力，去學個PMI-ACP^®或者CSM是最好的。

2、把組織過程了解清楚，我沒有看到整體的組織過程和項目方法，我猜測該組織的過程方法跟Scrum還是有一定的差距的，不管是內(nèi)訓資料，還是已定義過程，相信組織中一定是有的，看看去絕不會吃虧，最好是能夠?qū)⒆约旱膯栴}列一個清單，去一個一個的解決。

3、不要看人家怎么說，看看實際的情況是什么樣的。深入的項目中，很多情況下，你看到的培訓資料跟實際情況是有一定的出入的，從組織結(jié)構(gòu)來看，受診人的角色也不是一個意義上的SM，更像是一個迭代組織者。

那我建議關注的焦點就在于一些基于迭代的特性上，比如說backlog的建立和規(guī)劃，速率，潛在交付成果關口定義，過程質(zhì)量內(nèi)建，回顧和改進。

從一個瀑布的PM到一個scrum的SM是會顛覆一些認知的，但是客觀情況對這些認知是起一定的塑造作用的，事是怎么辦的最重要，知道該怎么辦更重要，書上怎么說的，不重要。

總的來說，我們遵循這樣的過程，應該可以盡早的融入一個過程中：

1、建立信心，不懼挑戰(zhàn)，相信自己的專業(yè)程度和業(yè)務能力；

2、了解組織過程，并提出自己的問題，學習相關的知識和理論，盡早解決；

3、深入項目，從實際出發(fā)，回溯到理論基礎和組織過程，形成焦點關注和項目原則；

4、持續(xù)更新，持續(xù)學習。

最后，scrum的5大價值觀送給大家

承諾– 愿意對目標做出承諾

專注– 把你的心思和能力都用到你承諾的工作上去

開放– Scrum 把項目中的一切開放給每個人看

尊重– 每個人都有他獨特的背景和經(jīng)驗

勇氣– 有勇氣做出承諾，履行承諾

03/ 我有話說 /

聰少-廣州-無業(yè)閑人：

“1、先了解公司業(yè)務，不用急著上手，公司做什么都不了解，如何帶好一個團隊。

2、按各位大神所講，找有經(jīng)驗的人，先了解瀑布式與敏捷式開發(fā)的不同之處。

3、查看相關項目的組織過程資產(chǎn)?！?/p>

04/ QA /

Q：scrum里面有沒有項目經(jīng)理？

A：理論上沒有.

Q：Scrum master 不是類似PM嗎？

A：完全不類似，sm要保證團隊使用正確的方法做正確的事向正確的目標。

Q：現(xiàn)在很多團隊在弱化測試人員， 敏捷開發(fā)對人員要求高，數(shù)量有限，是配專門配測試人員，還是采用研發(fā)間互相測試更合適？

A：敏捷中對這方面沒有具體的定義，但是會有質(zhì)量內(nèi)建這個概念，也就是說，在團隊內(nèi)部對質(zhì)量負責，但具體是誰，要看具體情況。

Q：或者立項的項目 開發(fā)團隊不做呢？

A：通常來說，這個時候，會有人站出來，通常我們管這類人，叫PMO。如果說，你把每個階段獨立來看，他就有個上下游的關系，通常這個時候，我們會考慮分階段管理，給每個階段設立Gate

Q：既然 敏捷組織中 沒有項目經(jīng)理， 那么PMO 在這個組織中 是什么樣的角色呢？

A： 敏捷組織中沒有項目經(jīng)理，不意味著項目沒有管理者。作為pmo，這時候就不是項目經(jīng)理的管理者，而應該是資源協(xié)調(diào)者，目標灌輸者，或者是戰(zhàn)略統(tǒng)一者等等，層次要高一點。

總結(jié)：從5個會議以及okr進行敏捷切入指導團隊共同參與。建立信心，了解組織過程，深入項目，從實際出發(fā)，持續(xù)更新，持續(xù)學習。