敏捷項目管理

目 錄 D

I

R

E

C

TO

R

YPART 01PART 02PART 03重 新 認 識項 目 管 理敏 捷 型項 目 管 理敏 捷 轉(zhuǎn) 型成 長 之 路PART01重

新

認

識

項

目

管

理如

何

應(yīng)

對

互

聯(lián)

網(wǎng)

巨

變

時

代無處不在的項目項 目 管 理 做 什 么交付：范圍、時間、質(zhì)量·····組織：團隊、氛圍、能量、文化、目標(biāo)······項目管理定義將知識、技能、工具與技術(shù)應(yīng)用于項目活動，以滿足項目的要求——PMBOK指南在項目活動中運用專門的知識、技能、工具和方法，使項目能夠在有限資源限定條件下，實現(xiàn)或超過設(shè)定的需求和期望的過程——百度百科項

目

管

理

五

大

過

程

組啟動千里之行

始于足下

規(guī)劃運籌帷幄

決勝千里

執(zhí)行言出必行

行必結(jié)果

監(jiān)控審時度勢

沉著應(yīng)變

收尾慎終如始

如履薄冰

項目管理五大過程組項目管理=重要通用能力執(zhí)

行

力責(zé)

任

心自

驅(qū)

力覺

察

力 感

知

力客觀開放全

局

觀項目管理的常量和變量范 圍時 間成 本產(chǎn) 品類 型生 命周 期團 隊階 段經(jīng) 典 項 目 管 理 鐵 三 角時

間資源

/

成本

范圍

/

質(zhì)量

◆

所謂“鐵三角”，指的是三者中任意一方的變動都會對其他二者產(chǎn)生影響。◆

項目管理的目標(biāo)是平衡三者的關(guān)系，使之達到最佳的效果。計劃鐵 三 角 有 所 思時

間成本

范圍

◆

各因素相互

牽制

◆

對

需求

的管理是源頭

◆

單純加人是個

“焦油坑”

◆

時間

總是最易確定的因素

，也是最易被重視的維度

◆

要求

克制追求時間

的沖動

◆

最易傷害：

長期質(zhì)量

◆

衡量什么，就得到什么

價值項 目 管 理 思 維目標(biāo)管理全局眼光項目分解流程管理風(fēng)險意識目 標(biāo) 管 理◆

點頭之前多問幾個“為什

么”

◆

期望管理：結(jié)果 V

S 過程

◆

“奇怪”的期望

◆

成功交付，是唯一的目標(biāo)

嗎？

目 標(biāo) 管 理專職項目經(jīng)理

①

項目經(jīng)理直接入駐項目，深入了解項目日常情況，在項目中因地制宜實

施項目管理方法和流程。作為項目經(jīng)理，一方面對各版本項目的成功交

付負責(zé)，另一方面也需關(guān)注團隊的長期健康成長。

②

項目的成功交付

是指根據(jù)項目實際情況所需達成的重要交付目標(biāo)

,

包括

但不限于時間、范圍、質(zhì)量等因素，通常是這幾項因素的綜合結(jié)果。

③

團隊的長期健康

成長是指隨著產(chǎn)品各版本的推出，團隊在執(zhí)行力、協(xié)作

氛圍等方面的日漸增強，以及團隊日益形成的自我組織和自我管理

.全 局 眼 光低頭抬頭前

后

上

下

通

吃假象演繹想 象 沙 盤歸納聯(lián)系問題、風(fēng)險、懂了追求“小而美”哪怕應(yīng)對的

“排山倒?！?/p>

凡事皆可拆事、人、物

交付增量式

（快速、試錯、風(fēng)險）

改進每次一小步

（接納、適應(yīng)）

團隊功能團隊

交付能力、克服劃

水、自組織、激活

項 目 分 解流 程 管 理基本框架上的因地制宜遵循但不死板重視流程背后的原則而不是流程行動本身◆

藥，不可多吃！◆

規(guī)范性vs靈活性◆

持續(xù)改進◆

落實重于制定◆

要找到

試點沒有一勞永逸的流程來自團隊意愿每次一小步◆

只相信你有權(quán)相信的開發(fā)對測試說，我的代碼沒bug了…◆

風(fēng)險識別，貫穿始終◆

拓展信息來源，讓信息匯向你◆

致命風(fēng)險，不僅僅是上交◆

兩份風(fēng)險列表，一份不公開◆

悲觀心態(tài)看項目，樂觀心態(tài)看團隊◆

不再成天救火風(fēng) 險 意 識PART02敏捷型的項目管理

如何應(yīng)對互聯(lián)網(wǎng)時代管理

變

化靈

活團

隊檢驗適應(yīng)什 么 是 敏 捷？敏捷（Agile）是一種關(guān)注價值、消除浪費、以人為核心、迭代、循序漸進的開發(fā)方法。透明價

值效

率用

戶傳統(tǒng)項目常見模型傳統(tǒng)開發(fā)面臨的問題交付周期長6-10個月甚至更長軟件質(zhì)量差趕上線而犧牲質(zhì)量團隊士氣弱死亡行軍及不關(guān)注結(jié)果進度延期久計劃和估算全靠拍腦袋溝通效果差文檔化的溝通不及時按時發(fā)布低技術(shù)債務(wù)增多無法發(fā)布傳統(tǒng)和敏捷有什么區(qū)別傳統(tǒng)思維VS敏捷思維敏 捷 思 維是

流

程

的

問

題是

員

工

的

問

題優(yōu)

化

各

部

分

的

工

作系

統(tǒng)

思

考

，

優(yōu)

化

整

體快速交付和高質(zhì)量意味著多花錢快速交付和高質(zhì)量互為手段、目的針對個人進行考核

針對流程進行考核

激勵并管理員關(guān) 注 計 劃為了更好的預(yù)測，

做全面的分析清除員工面臨的障礙，

開發(fā)員工關(guān) 注 價 值頻繁的預(yù)測才是可依賴的方法大

而

集

中

能

提

高

效

率小

而

靈

活

才

是

美傳 統(tǒng) 思 維VS為 什 么 要 敏 捷為啥要變化呢？不能一開始多花點力氣，想明白呢？?

細節(jié)無法提前全都想明白?

世界變化太快，原本有價值的東西，可能會變得不那么有價值了?

不確定性太多，可能連用戶自己都沒意識到自己到底想要的是什么敏捷軟件開發(fā)優(yōu)勢快速交付1-4周迭代結(jié)束即可交付可運行的軟件降低風(fēng)險短周期迭代持續(xù)反饋，提高預(yù)見性適應(yīng)變化小步快跑，快遞驗證產(chǎn)品需求及調(diào)整方向滿意度高高ROI的需求快速交付早期實現(xiàn)商業(yè)價值持續(xù)改善迭代結(jié)束后進行回顧頻繁檢查團隊動向質(zhì)量更好持續(xù)集成及頻繁測試保證代碼質(zhì)量更高敏捷型項目管理特點快！離用戶近！范

圍時

間質(zhì)

量來

源

廣

泛擁

抱

變

化快

速

試

錯透 明全

民

測

試階段性質(zhì)量敏捷推崇的工作方式開發(fā)項目的復(fù)雜分類需求、技術(shù)明確，采用傳統(tǒng)項目管理即可需求、技術(shù)都不確定的復(fù)雜類型，適合敏捷預(yù)定義過程VS經(jīng)驗性過程復(fù)雜的環(huán)境會干擾我們對目標(biāo)的判斷，讓我們偏離目標(biāo)不斷的偵測目標(biāo)，收益反饋，調(diào)整方向，完成目標(biāo)敏 捷 宣 言個體和交互可工作的軟件客戶合作響應(yīng)變化流程和工具面面俱到的文檔合同談判遵循計劃勝過勝過勝過勝過雖然右項也具有價值，但我們認為左項更具有更大的價值敏 捷 項 目 階 段立項 建立愿景 商業(yè)論證啟動 項目章程 工作協(xié)議 人物角色初步Backlog 高層次估算產(chǎn)品roadmap 用戶故事地圖發(fā)布計劃 用戶故事分解 估算定義DoD 發(fā)布迭代Splike 迭代計劃 開發(fā)及測試 每日站會 評審會議 回顧會議Backlog梳理收尾 回顧會議 感恩游戲 總結(jié)經(jīng)驗教訓(xùn) 成功交接 文檔歸檔 行政收尾敏捷原則-12條準則敏捷原則1我們的最高目標(biāo)是通過盡早和持續(xù)的交付有價值的軟件來使客戶滿意敏捷原則3經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，且時間間隔越短越好敏捷原則4在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須每天在一起工作即使在項目開發(fā)的后期，仍歡迎對需求提出變更。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢敏捷原則2敏捷原則-12條準則敏捷原則5要善于激勵項目人員，給他們所需的環(huán)境和支持，并相信他們能夠完成任務(wù)敏捷原則7可工作的軟件是衡量進度的首要指標(biāo)敏捷原則8敏捷過程提倡可持續(xù)的開發(fā)。項目方、開發(fā)人員和用戶應(yīng)該能夠保持恒久、穩(wěn)定的進展速度團隊內(nèi)部和各個團隊之間，最有效的溝通方法是面對面的溝通敏捷原則6敏捷原則9對技術(shù)卓越和好的設(shè)計的持續(xù)關(guān)注有助于增強敏捷性敏捷原則11最佳的架構(gòu)、需求和設(shè)計出自自組織團隊敏捷原則12團隊要定期回顧和反省如何能夠做到更有效，并相應(yīng)的調(diào)整團隊的行為敏捷原則-12條準則盡量做到簡潔，盡最大可能減少不必要的工作這是一門藝術(shù)敏捷原則10你的團隊還好嗎?有人績效很差，但沒什么問題會越開越多，越開越長，但決策越來越難群里po個信息，沒人理，全天沒幾條信息開會就是各自開小差關(guān)于一個問題，各種討論，但遲遲沒有定論除了測試和運營，團隊很少人日常使用自己的產(chǎn)品重要問題，很少有人提反對意見郵 件 中 打 仗明明覺得有問題，但懶得說不想再提，因為提了也沒用各種病假事假遲到早退團建沒幾個人參加團 隊 問 題團隊建設(shè)四個階段相對獨立成熟期Performing凝聚力規(guī)范期Norming沖突振蕩期Storming依賴于領(lǐng)導(dǎo)者形成期Forming確定方向組織架構(gòu)公開的數(shù)據(jù)流動問題解決團 隊 管 理形

成

期定義方向、任務(wù)、期限、規(guī)范，啟動會，團建，學(xué)習(xí)震 蕩 期協(xié)調(diào)情緒、加強溝通、建立信任、隨需調(diào)整、認同方向規(guī)

范

期共同目標(biāo)、信任、鼓勵協(xié)作、流程制定和改進、松弛有度成 熟 期自我管理、肯定鼓勵、處理突發(fā)、關(guān)注大局團 隊 發(fā) 展 注 意 點◆

團隊可能一直處于、也可能隨時重新進入形成期

-震蕩期

-正規(guī)期◆

業(yè)務(wù)績效、關(guān)鍵人員、大批新人……◆

團隊負責(zé)人起著關(guān)鍵作用，當(dāng)ta不再被信任時，團隊將持續(xù)處于震蕩期，最終的結(jié)果是解散◆

每個新人進入一個團隊，都將經(jīng)歷這四個階段，

包括PM自己用戶角色Persona建模在很多項目中，需求分析人員只是從一個角度去寫用戶故事，這樣往往容易忽略一些需求(故事)，因為有些故事針對的并不是系統(tǒng)的一般用戶。以用戶為中心的設(shè)計和交互設(shè)計讓我們明白在編寫故事前識別用戶和虛構(gòu)人物會有很多好處類別姓名求職者張三初次找工作者李四裁員受害者王二大學(xué)生小朋監(jiān)控者小芳工作發(fā)布者…建立閱讀者…用 戶 故 事 是 什 么用戶故事描述了對用戶、系統(tǒng)或軟件購買者有價值的功能 一份書面的故事描述 有關(guān)故事的對話，用于具體化故事細節(jié) 可驗收測試，用于表達和編檔故事細節(jié)且可用于確定故事何時完成Independent獨立Estimable可估算作為XXXX，我想要XXXX，這樣我可以XXXX角色：誰要使用這個功能功能：需要完成什么樣的功能價值：為什么需要這個功能，能帶來什么價值INVEST原則Negotiable可協(xié)商Valuable有價值Testable可測試No.S01 優(yōu)先級

12作為：一個賣家我希望：發(fā)布我的商品信息1、顯示名稱、規(guī)格、價格等屬性2、支持上傳圖片3、在線編輯目的：讓更多的買家查找到商品估算：5

story

point

計劃完成時間：2019.10.01用 戶 故 事 估 算故事估算方法

依據(jù)經(jīng)驗和其他故事做比較分解成更小的故事計劃撲克估算理想日估算

集體估算，只有開發(fā)人員才能估算

估算不是承諾

準確而不是精確

使用相對值

避免長時間討論

大的故事可分解再估算

需要PO澄清期間的問題用 戶 故 事 排 序Simple

schemeMoSCoW100-PointKano

Analysis

按客戶價值進行優(yōu)先排序

優(yōu)先選取能交付最高價值給客戶的

讓客戶參與到優(yōu)先排序過程

在制約下優(yōu)先交付一組有用的功能

MMF(最小可售單元)Product

BacklogDSDM(優(yōu)先級列表)價值優(yōu)先級排序方法建立產(chǎn)品Backlog

類似于傳統(tǒng)的系統(tǒng)需求

全程可視化的功能列表

按優(yōu)先級排序的

每個Sprint開始時調(diào)整優(yōu)先級

由PO準備和維護

包含驗收測試標(biāo)準

估算：故事點Backlog

條目估算(故事點)優(yōu)先級作為一個博客讀者，我想設(shè)置發(fā)布文章的背景圖片，以便于我的讀者閱讀的時候感受到文章的意境8100作為一個博客讀者，我想讓我的讀者對我的文章進行評價，以便于收集讀者反饋，日后改進1080作為一個博客讀者，我想通過博客發(fā)布我的照片，以便于我的讀者們認識我2060……3014……506產(chǎn)品Backlog的屬性詳略得當(dāng)

優(yōu) 先 級估算過的

夠用就好

定期梳理

漸進明細，文檔夠用就好從優(yōu)先級最高開始開發(fā)優(yōu)先級越高估算的越精確適合自己的，逐漸演進

每次新的Sprint開始前梳理調(diào)整產(chǎn)品Backlog特點故事主題故事史詩創(chuàng)建用戶故事地圖管理賬戶注冊瀏覽圖書清單下單購買購書消費者登陸圖書詳情收獲信息確認購買修改密碼維護地址手機驗證微信綁定書名檢索購物車書號檢索分類瀏覽修改訂單配送員發(fā)貨清單退貨線下付款配送支付配送清單支付寶配送單退貨申請微信支付信用卡退貨處理退款高低商業(yè)價值

業(yè)務(wù)流程時間線發(fā)布1發(fā)布2發(fā)布3發(fā) 布 計 劃確定滿意條件估算故事規(guī)?？梢园慈我忭樞蜻M行選擇迭代長度估計團隊速率確定優(yōu)先排序確定發(fā)布日期Sprint特點容易做計劃和承諾投入產(chǎn)出比高反饋快檢查點多產(chǎn)生的錯誤更少快速激勵和開始時 間 盒時間計劃首先是迭代方式：版本、固定時間盒基于WBS和估算的時間計劃當(dāng)你遭遇時間倒排時：范圍、緩沖背后的原則強制排定優(yōu)先級增強可預(yù)見性、避免鍍金展示進度、促進技術(shù)S p r i n t 計 劃 會會議目標(biāo)1、明確該Sprint做什么，輸出Sprint

Backlog2、足夠深入理解需求參與人員Team、Scrum

Master、PO議程1、討論產(chǎn)品Backlog中高優(yōu)先級項2、團隊挑選部分作為該Sprint目標(biāo)3、分解估算產(chǎn)品

Backlog故事1故事2故事3……Sprint

Backlog故事1故事2…每日站會昨天我做了什么？今天我要做什么？碰到了什么阻礙的問題

團隊聚在故事板旁邊，可以圍成環(huán)形

從左邊第一個開始，向團隊伙伴說明他到現(xiàn)在完成的工作

然后該成員將任務(wù)板上的任務(wù)放到正確的列中

如果該成員遇到問題或障礙，就要將其報告給

Scrum

Master

每個團隊成員重復(fù)步驟2到步驟5

最多不超過15分鐘燃 盡 圖

有助于預(yù)測問題

有助于生產(chǎn)力評價

有助于對個人或總體任務(wù)的跟蹤

團隊每天更新燃盡圖

剩余的工作量每日站會的作用同事間互相的壓力每天做出承諾可視化促進協(xié)作提出阻礙的問題關(guān)注在少數(shù)事情上探針大家都喜歡的站會找到團隊關(guān)心的問題合 適 的 時 間010204大家覺得每日站會沒用通常情況下都是下面幾個原因造成的03每日站會沒什么可說的團隊可能平時工作中也是這種情況，團隊協(xié)作較少，可能之間不太熟悉其他人說的內(nèi)容我不關(guān)心視野停留在自己的任務(wù)層，工作內(nèi)容差異較大？

互相關(guān)系不夠融洽？每日站會時間太長人太多說的太多，不是核心三個要點每日站會的常見問題Sprint評審會會議目標(biāo)1、展示成果2、收集反饋3、驗收功能參與人員Team、PO、干系人等形式1、向PO和干系人展示產(chǎn)品2、只展示100%完成的部分3、來自干系人的直接反饋01ONE02TWO03THR04FOU反饋產(chǎn)品負責(zé)人和客戶對演示的成果進行反饋終結(jié)意味著本次Sprint的終結(jié)總結(jié)總結(jié)本次Sprint相關(guān)的經(jīng)驗教訓(xùn)調(diào)整根據(jù)反饋提出的修改或新增調(diào)整后續(xù)BacklogSprint Review的作用會議目標(biāo)1、持續(xù)的評估2、階段性改進3、調(diào)整和適應(yīng)形式1、頭腦風(fēng)暴2、確定改進項(一兩個最優(yōu)先即可)3、針對改進和優(yōu)化流程4、在開發(fā)的氛圍中解決問題S p r i n t 回 顧 會Sprint回顧會的好處14183341555758606065850102030405060708090改善團隊內(nèi)部溝通創(chuàng)作相互信任的氛圍提升工作質(zhì)量提升團隊生產(chǎn)力提升敏捷實踐獲得成就感減少團隊沖突快遞發(fā)現(xiàn)團隊障礙更好的進行項目提升預(yù)測性改進客戶關(guān)系0102030405060708091011敏 捷 相 關(guān) 書

籍PART03敏捷轉(zhuǎn)型成長之路互

聯(lián)