1、小項資訊
關注項目管理領域的那些人和事兒，為您帶來最新的管理政策、發展趨勢；參與我們的討論，讓我們知道您的需求，為您答疑解惑、獻計獻策。
2、小項是誰？
項目管理辦公室的一群項目管理員，主要從事組織級項目管理工作，這是一群愛工作愛生活、積極樂觀、極富責任心的人們。始終堅信：您的支持是我們服務的動力。
3、項目管理大家談
作為組織級項目管理員，我們打交道最多的是項目經理，最需要了解的是項目經理遇到的困難。通過前幾期同大G、小新等采訪對象的交流，我們對于項目經理眼中的“痛點”和“槽點”進行剖析，對新項目管理辦法下工作流程的變化提出了更多可供改進之處。文章發表后，引起了很多項目經理、項目成員的共鳴，小項也收集很多切實可行的建議，在這里感謝大家的支持！
被訪談人員均被隱去真名，這也是個小小的伏筆，等系列訪談結束后，我們將統一公布被訪談人員真名，敬請期待！
本期我們采訪到的是中心一位資深的項目經理Y先生，同時也是中心公認的技術、管理雙料大拿，本次小項也是抱著虛心學習的態度，帶領大家一起去了解一下，開發中心關于敏捷的那些事兒。
小項：Y先生，您好。首先感謝您接受我們的訪談。最近敏捷是業界大熱的一個話題，聽說咱們項目組也在嘗試推行敏捷開發方式，能不能請您給我們介紹下大概情況。
Y先生：好的。其實對于敏捷方法的嘗試，我們一直在路上。從最早的互聯網銀行開始，我們就引入了敏捷開發模式中的Kanban(看板)方法，對項目各個階段的任務進行管理，大約進行了一年多，這個是我們最早期的敏捷嘗試。
小項：說到Kanban，之前沒有接觸過敏捷領域的人來說可能還比較陌生，您能詳細說說么？
Y先生：好。Kanban是敏捷開發（Agile Development）的一種方法，它最初起源于豐田公司的即時管理模式（JustIn Time， JIT），在軟件研發管理領域，我們最常見的模式就是通過在項目工作場所的墻上張貼卡片來呈現和分享項目狀態來實現對項目任務的管理。舉個栗子，以下就是一個日常工作中典型的Kanban。
在面板上，工程任務用卡片（即時貼）來代表，并通過把卡片貼在面板中不同區域來象征任務的狀態，這些區域被標注為“pending(待辦)”、“analysis（分析中）”、“development（開發）”、“test（測試）”、“deploy（發布）”，標注的名稱可以根據需要而變化。同時，在每一列的最上方可以根據項目組情況標注可承受最大任務數WIP，這樣的Kanban有利于可視化地跟蹤任務并限制處理中任務的數量，根據項目組實際情況及時進行調整，真正做到團隊自治和對項目進度的把控。對于項目經理而言，最擔心的就是項目進度不可控，不知道每位開發人員具體的工作進度；對于開發經理而言，最擔心的就是資源分配不合理，忙的人忙死，閑的人閑死，有了Kanban一切都是那么一目了然。對于開發人員而言，最擔心的就是績效考核不公平，“憑什么我做的比他多，拿的工資卻比他少？不公平啊！”。通過Kanban的合理使用，這些問題基本都能得到解決。
小項：這么看來Kanban真是個不錯的工具呢，這也正符合我們目前正在進行的項目精細化管理課題研究中涉及的理念。但說到敏捷，現在業界大熱的，恐怕要說到SCRUM了，不知道咱們是否在項目中有引入此類方法呢？
Y先生：有的，SCRUM的核心在于快速交付和持續改進，我們在這之后更大規模的項目群中引入了SCRUM的管理方法。對于我們來說，不僅要考慮到中心對于項目群大版本投產的要求，同時也結合了各項目的實際情況，將整個項目生命周期劃分為若干個迭代（2-4周），保證每個迭代結束都能提供一個完整可發布的版本，并快速得到反饋。我們會將合理的反饋內容納入下一個迭代計劃，對程序進行持續優化和改進。但是在當前階段，鑒于項目群規模太大，具體涵蓋到每個項目組的實際情況存在一定的差異，所以敏捷的實現也就比較局限，像用戶故事、站會和回顧等等這些SCRUM普遍采用的方法，并沒有在整個項目群的范圍內實現。
小項：那現階段我們是如何推行敏捷開發方式的呢？
Y先生：我們將SCRUM與Kanban兩種方法相結合來實現項目開發過程中的敏捷轉型。目前各項目組基本都是以2周為一個迭代周期，每個迭代開始時召開計劃會議，制定本次迭代的任務目標和計劃，讓所有項目成員能在接下來的日子里更流暢地進行各自的工作。在這個會議上，項目經理會和團隊一起對用戶故事進行工作量評估，并拆分成具體的任務點，項目組成員根據自身情況主動領取任務，如果存在困難應該在這個會上提出，大家共同商議出解決方案。（迭代+計劃會議+拆故事+領任務）
小項：用戶故事，這是個新的概念，您能具體介紹一下么？
Y先生：用戶故事（User Story）是從用戶的角度來描述用戶渴望得到的功能，對于敏捷開發來說，它是開發的基礎。不同于傳統的瀑布式開發方式，用戶故事是把原本需求拆成最小粒度的Story，以方便拆分Task，估計開發時間，領取開發任務，它應遵循INVEST規則（Independent 獨立性、Negotiable 可談判性、Valueable 有價值性，Estimable 可估計性、Sized Right 合理的尺寸、Testable 可測試性）。
用戶故事的拆分有兩個層面：大故事拆分成小故事，小故事拆分成任務。大故事拆解成小故事除了能通過“小規?；?span style="color: #333333">故事”防止小瀑布，同時也有助于識別出需求的某些細節；而小故事到任務的拆分，也就是我們常說的任務分解，可以看作類似瀑布模型中的詳細設計，在這種方式中，每個任務都能在較短的時間（1-2天）完成，完成所有任務后能達到高質量實現用戶故事的目的。有的人認為任務很難拆分，甚至沒有必要拆分，這種思想就像是在瀑布開發模型中不做詳細設計一般，設計思路還沒有理清就撲入了代碼的海洋，這種做法寫出來的代碼質量可想而知。任務分解同時可以用來制定工作計劃，分解出來的任務就是在實現故事的過程中要做的事情，每個任務需要的時間就是做這些事情分別需要的時間。從這個角度來看，如果我們很夠很好地將故事分解成任務，準確地評估故事的規模，無論是使用物理看板還是TFS等工具進行任務管理，都能較好地做好迭代計劃并順利執行。下面是一個簡單的在線購書網站的用戶故事拆分示例：
小項：那么采用用戶故事評估出來的工作量會與中心目前采用的功能點估算結果相沖突么？
Y先生：這個情況我們也有考慮到，目前我們是以中心功能點估算的結果為依據，將工作量分配到以用戶故事分解出來的任務下，所以不存在沖突的問題。
小項：了解了，那除了任務分解方面，咱們還有哪些其他做法與敏捷相關？取得的效果又如何呢？
Y先生：站會，這個非常重要?，F在每天早上8點半到9點來我們辦公室，會看到所有的小組基本都在開站立會議，這個會議很短，一般在15分鐘以內，每個人只需要回答三個問題：上次會議后完成了什么？下次會議前需要完成什么？遇到什么困難和阻礙？這個步驟一般都是在看板前完成，各項任務可視化的討論方式有利于對項目整體執行情況的把握，問題能夠盡快地被發現和得到解決，保證項目按計劃進行。另外還有每個迭代結束時的迭代評審和迭代回顧，這個我們通常作為一個會議來開，時間一般定在每個迭代結束的當日下午，在這個會議上大家會展示本階段的項目成果，這是個重要溝通和反饋的過程，同時在這個會議中，會對本次迭代所有的故事、度量、事件從以下三方面進行歸類：做的好的、做的不對的、改進意見。通過這個會議的開展，達到項目過程的不斷改進和團隊的不斷進步。
總之敏捷是一種思想，要想真正達到完全實現我們仍需不斷探索，還是開頭那句話：敏捷嘗試，我們一直在路上。
小項：好的，這次的訪談就到這里吧，感謝Y先生帶領我們了解了敏捷那些事兒，屏幕前的你有沒有覺得受益匪淺呢？還是你也有些話不吐不快？如同前幾期所說，項目管理方面不管您有任何的問題和疑問，或者是好的經驗想要分享，歡迎聯系小項，我們將會懷著最大的誠意，歡迎您的到來！
（本資訊于2017-08-30首次發布）
