逃離傳統項目管理百慕大三角

逃離傳統項目管理百慕大三角

敏捷項目管理的關鍵點

敏捷提倡迭代遞增交付，完全不同以往的開發方式

什么是敏捷？相信大家一定對這個話題比較感興趣，敏捷是相對于其他一種研發模式來講的，比較典型的研發模式稱之為瀑布開發。以大家最熟悉的電商購物來講，在瀑布開發模式里，相當于要在三個月或半年之前跟電商網站說，要買什么東西，把你所要的東西全部列出來，一鍵下單，然后電商網站收到后，過了三個月或半年之后，你收到一個大集裝箱，把你所要的東西全部拿到手里，開始你可能會比較開心，收到了自己期望已久的所有商品，但你很可能又會比較郁悶，因為很多東西已經過時了，現在不太想要了，這是傳統的項目管理映射到在線購物的一種場景。

而敏捷就像現在我們在網上買東西，今天下單明天就可以收到，再有什么需求可以再下單，很容易收到。在敏捷里提倡的是快速響應和快速交付的過程，通過快速交付和快速的驗證需求，也是一個不斷試錯的過程。在現在的電商購物中，我們都喜歡第二種購物方式，今天下單，明天就拿到想要的商品，再有什么新的需求就重新再下一個新的訂單好了。同樣，客戶也會更喜歡敏捷的交互方式，表面意義上，敏捷可能意味著快，但不僅僅是快，敏捷更重要的是在于響應客戶的需求，它通過快，來響應用戶的需求，這離不開一個非常重要的8020準則，也就是軟件開發領域里經常提到的，20%的功能能夠滿足客戶80%的需求。

在這個調查報告的數據中，StandishGroup發現，有45%的功能是用戶從來就沒有用過的，用戶總是在用和經常在用的分別是，7%和13%，這二者加起來是20%，如果說我們把用戶最關注的和最重要的20%甚至30%找出來，就能夠做的少、做的快并且做得更精，而且客戶百分八九十的需求已經得到了滿足，用戶也會更早的實現他希望的結果，這是敏捷之所以能夠快起來非常重要的出發點。

敏捷從不同角度考慮“鐵三角”

基于8020準則，才能夠把傳統的項目管理做一次顛覆，傳統的項目管理實際上是左邊這個三角，其中有一個確定不變的東西是功能，也就是需求，我們會假定所有要做的需求全都不變。基于這個假設情況下，調整兩個參數，時間和資源，如果項目緊，就多放點資源，反之，就少放資源慢慢做，無非是制定一個計劃，按部就班的去執行而已。

在敏捷的項目管理把這個三角形倒過來了，倒三角形里確定不變的是時間和資源，這時候可變的是功能或需求，這意味著我們要在有限的時間和有限的資源的情況下，決定做哪些事情，這意味著我們不能把所有的需求一視同仁，需要進行一個排序，按照客戶價值重要性的維度來進行排序，所以在敏捷經常講客戶價值驅動，也就是說先做對于客戶價值最重要的事情，然后再慢慢地考慮其他事情。

敏捷迭代可及時調整中間過程，直至實現最終目標

這是一個關于打靶的圖，傳統的項目管理相當于什么提前在瞄靶，而且假定這個靶是不變的，很多情況下，我們對需求的理解也就是瞄靶的過程，有可能會出現兩種場景，第一種場景是我們對需求有偏差，相當于我們對用戶的目標，理解錯了也就是瞄靶瞄錯了，還有一種可能是即使理解對了，瞄也瞄準了，但是現在這個靶是移動靶，移動靶意味著客戶在三個月之前提的需求，現在已經在變化了，因為我們已經進入到一個新的時代，在移動互聯網時代，三個月的迭代節奏，相當于過去的一年，實際上是非常快的。在敏捷里要承認，需求會不斷變化，如果面對移動靶，更有效的做事方式應該是邊開槍邊瞄準，也就是說不斷迭代遞增式交付，不斷地去跟客戶去交付產品獲得用戶的反饋，調整做事的過程，一定能夠最終命中目標，取得最大化的商業價值。

正確理解需求是逃離傳統項目管理百慕大三角的出口

需求直接決定一個項目的成功與否

這是一個網上流傳已久的需求漫畫，客戶最早是這樣來描述需求的，他想要一個梯子，能夠掛在樹上，項目經理或者需求分析人員理解的需求還可能被樹給擋住了，這時候架構師會覺得這個需求有些不合理，需要進行修正，架構師做了如下的修正，真正再把需求傳遞到開發人員后，開發人員寫出的代碼可能是這個樣子，測試人員收到的東西并不一定就如開發人員所聲稱的那樣，依然會有偏差，最終測出來的東西再交付給商務顧問去做描述的時候，一般來講銷售人員都比較厲害，能夠把這個事情說的非常好。很多時候項目文檔也不一定能夠展示出來項目的真實場景，軟件安裝的過程再產生一些偏差，這樣直接會導致客戶對這個項目進展和做的產品不滿意，用戶的付款也經常是一波三折，用戶付款之后必然離不開售后支持，我們的支持可能對產品和需求的理解不夠準確，也會出現偏差，回到前面，客戶真正的需求只是需要一個繩子，把輪胎掛樹上就可以了，但是在整個過程中都產生了各種偏差，最終會導致做出的東西跟客戶預期產生不一致。

這是StandishGroup在2006年做過的一個調查，只有35%的項目可以稱為成功，按照傳統項目管理的三角來說，不超過預算、所有需求都完成而且質量沒有任何問題，才算是成功，真正符合這些要求的項目，也就三分之一左右，將近46%的項目其實都有各方面的問題。在這些失敗的項目里，經過分析發現，有八分之五的問題都是跟需求相關，只有八分之三的問題是跟管理相關，大多數問題跟技術沒有任何關系。一個項目如果失敗了，會帶來各種各樣的問題，不僅產品的上市周期會拉長，而且交付的產品不能夠解決客戶的問題，也會導致無人問津、資源產生浪費并且團隊的士氣也開始低落，也有可能會造成人員的流失，所以我們必須保證項目要做的成功。

客戶是慢慢地才能夠知道他想要的是什么，開發人員也是慢慢地才能夠知道，如何更好地進行開發，知道該用什么的技術，以什么樣的方式來跟客戶交流，而且更重要的是事情總會發生變化，這意味著在傳統項目管理里必須采用不同的方式來應對需求。

寫下需求，并不就能解決問題

給大家分享一個小故事，這個故事是郭德綱老師跟于謙老師說過的一個相聲，郭德綱老師說于謙他老爸，以前接過一個特別牛掰的活兒，這活兒完事能掙30萬，在那個年代是一個非常好的活，于是，他老爸拿過圖紙一看，太簡單了，不就是蓋一個40米的煙囪嗎，把煙囪蓋好了請人家來驗收一下，結果發包方看了，非常不滿意，不僅沒給錢還把于謙他老爸給胖揍了一頓，其實人家原始的需求是打一個井，于謙他爸圖紙看反了，理解成一個煙囪，跟原始的需求差的十萬八千里，人家肯定會不開心了。

很多時候我們覺得把需求寫下來，就應該能夠解決問題了，但現實并不會如此。再舉兩個例子，這是從國外的一個網站上找到的圖片，是關于一個蛋糕的圖片，一般大家都知道我們預訂蛋糕的時候都會給蛋糕店打個電話說我要什么樣的蛋糕，一般來講，接線員會問我們上面要不要寫字，有一天，接線員打了一個電話問要不要寫字，客戶說不寫字，留空，留空的英文的意思就是leave blank，于是接線員就把那個蛋糕的需求，關于寫字那一塊就寫了這么一行字，leave blank，蛋糕師傅看到這個需求，于是就把leave blank寫上去了，這個就跟原始需求差了很多。

接線員又接了一個電話，要做兩個蛋糕，兩個蛋糕寫生日快樂，一中一英，所以他就把這兩條需求也寫了下來，蛋糕師傅看到這個，也會非常忠實地按照這個需求去實現，實際上依然做反了，人家原始的需求是生日快樂一個寫中文的，一個要寫英文的happy birthday，這些案例講的是需求寫下來，并不能解決問題，這都是生活中的一些案例。

我們來看真實的科研案例，這是NASA發的關于火星的空氣探測衛星，這個衛星發射出去之后馬上就控制不住，脫軌了，后來大家就開始找衛星就控制不了的原因，原來它是個跨國界的合作項目，不同國家的人對于軌道計算公式的單位是理解不一致的，我們有公制米制英制，各種知識的區別，沒有說清晰，理解錯誤，結果直接造成1.25億被白白浪費了。

共享的一致理解一定是團隊協作成果

很多時候，對于同樣一份需求，每個人可能都覺得我看了一遍，理解了，但其實每個人理解的東西都不一樣，而且人類有一個天然的共性是你愿意去趨同，所謂趨同也就是說，我看了一份文檔，理解之后，我會天然的認為我理解的跟他們的理解是完全一樣的，但實際情況卻完全不一樣，這張圖中，三個人理解的是完全不一樣，有人方框，有人是圓，有人是個三角。在敏捷里，我們采用一些手段，最重要的就是溝通和協作，如果說我們每個人對同樣一份需求理解不一致，那么我們就需要相互溝通互相分享各自的認知到底是什么，通過分享可視化之后會發現每個人理解的需求都不一樣，那我們就討論一下，我們為什么會這樣理解，經過思想碰撞之后，才會發現原來真實的需求是一個多邊多角的圓形。

用戶故事三要素背后的背后

在敏捷里，對需求的一致理解是團隊協作的成果，我們會有一個特殊的技術叫用戶故事，既然說它是個故事，那么就是希望大家從用戶的角度，用自然語言的形式，來描述一個需求。

用戶故事三要素

用戶故事有三個要素，分別是用戶角色role，也就是說，誰要用這個功能，第二個要素是活動activity，用戶需要什么樣的功能，第三個要素非常重要，我們稱之為商業價值也就是why，這個功能對于用戶來講，到底帶來什么價值。對于這三個要素里，功能不是最重要的，更重要的是價值，也就是why，前面在敏捷項目管理三角形里提到過，按倒三角形是按照商業價值來排序的，用戶故事跟前面是完全正好呼應的。

用戶故事例子

舉個例子，做為一個球員，我想查看賽程安排，以便知道下場比賽的時間和地點，作為一個球迷，我想查看賽程安排，以便知道去哪里看比賽，所以同樣一個需求，從不同的用戶角度，背后的商業價值是完全不一樣的，希望大家通過寫故事的形式，把用戶真實的需求，背后的背后描述出來，這一點是非常重要的，用戶故事寫起來很簡單，就是三個要素。

真正寫好用戶故事需要不斷地問用戶，為什么這個商業價值很重要嗎？假如說，客戶提了一個非常明確的需求，客戶說請幫我做一座木橋，我需要在很短的時間內實現這個需求，這個需求很明確，所以就開始設計方案，然后快速的去實施，幫客戶搭一個木橋，但是你把項目做完了，木橋的質量也不錯，你也盡量控制成本，但客戶可能依然不開心，因為我沒有追問客戶，為什么去搭這個木橋，沒準客戶要搭木橋的原因只是簡單的想快速過河，關于過河，我們其實還有很多種方式來實現這個目標，所以我們不知道用戶為什么要去搭橋的背后原因的話，就很難提出更有效的解決方案。

很多時候，用戶也不知道他想要什么樣的解決方案，他只知道木橋這么一個方案，所以他只會提這樣的需求，如果我們簡單地按用戶所說的去做，依然會偏離很多，一定要問用戶需求背后的背后，要找到用戶需求背后的這個商業價值why。

華為的DevCloud平臺，為了更好的支持敏捷，也設定了很多工作模式，其中關于需求這一塊，有專門預置的用戶故事模板，進入這個模板里面就可以看到，每次添加一個需求的時候用戶故事的三個要素，已經缺省展示在那里，提示大家按照這三個要素來寫需求。

Ron Jeffries的3C準則

用戶故事最早的提出人是Ron Jeffries，是非常著名的敏捷大師，關于用戶故事提出一個3C的概念，雖然現在已經把3C擴充到了5C，3C最早的是第一個C叫Card卡片，用戶故事通常是寫在一張張小卡片上的，內容很簡潔，只用三個要素就好，我們需要激發大家的溝通，對需求的一致理解靠的是相互協作和溝通，第二個C就是Conversation，溝通故事背后的細節和原因，一旦我們對于需求達成一致理解之后，需要達成一個確認，就是第三個C，confirmation確認我們這個故事，未來將會做成什么樣子，如何去驗收。

DevCloud還支持樹狀視圖，其中我們可以由epic、feature到yourstory的一個列表可能更容易能看到，多個需求之間是一種什么組合關系，而且還可以通過這種收縮關系，看到更多的需求。

用戶故事的另一種形式

用戶故事5c里面那個最后的C稱之為Consequence結果，就是幫用戶實現預期的目標，在用戶故事構建出來的那個程序或者是可運行的軟件，只能稱之為outcome結果，產出稱之為output，output不一定產生outcome，如果說構建出來的東西不能跟客戶需求去做積極有效的驗證，我們就不知道是做對了還是做錯了，所以為了更有效的把用戶故事落地，我們會把用戶故事做一層延伸，用戶故事轉化成另外一種形式，也就是一種假設，為了驗證它，我們將提出一個假設檢驗，要有目的地去收集相應的數據來證明，這個用戶故事代表的需求，真正讓用戶用它解決問題，而且用戶喜歡用，我們把這稱之為outcome。

INVEST準則

INVEST準則這個圖中，畫了很多硬幣，寫好用戶故事，做好的需求就像投資一樣，在前端做好了整個項目就有了起點，所以需求是我們的起點，INVEST的I代表的是Independent獨立，需求經常需要調整優先級，不會一成不變，如果需求之間依賴太多的話，那就不容易調整優先級，第二個N，跟3C里面的第二個C，Conversation是相關聯的，稱之為Negotiable可協商的，協商用戶需求的一些細節和背后的商業價值why，細節就是Confirmation驗收標準的東西，V是valuable有價值的，就是要找到用戶需求背后的商業價值why，E叫Estimable可估算的，S稱為Side appropriate大小適當的，在冰山模型里大家會理解大小適當是什么概念，最后一個T是Testable可測試的。

敏捷需求管理的冰山模型及DEEP準則

產品需求列表/Product Backlog

要管理好用戶故事，就離不開冰山模型，在敏捷中會把所有的需求列成一個大表，這個列表從上到下是優先級的，這個列表的名字叫產品需求列表，英文叫Product Backlog，在這個冰山分為浮出水面的部分和沉在水面之下的部分，水面之上的部分，意味著這個需求馬上進入迭代開發，它的力度要非常細，這里有一個特殊的定義，DOR，defination of ready和ready for development，要細化到讓開發人員拿到一個需求，就知道如何進行開發，所以DOR通常會幫我們涉及到前面提到的驗收標準，還有外部依賴，如果做一些web、app項目的話，對應的界面原型也應該準備好了。再往下，中間部分，這個力度稍微粗一點，這個是針對一個大的版本，一個發布release應該準備工作內容。再往下面一部分，我們稱之為Future未來，可做可不做的還沒想好，只是放在這里邊，就是Backlog的含義。

整個冰山圖符合這個DEEP準則，第一個D稱之為Detailed Appropriately詳略得當，跟前邊講的INVEST的S是一個道理，第二個E是Estimated，就是估算的，第三個叫Emergent涌現，所有的需求它是動態調整的，可能今天在水面之下，明天就把他調整到水面之上，因為他的優先級提升了，馬上要進入開發，需求不是一成不變的，未來會根據客戶的反饋不斷有新的需求加入進來，所以這個冰山的也會不斷的變大，但有可能某一天我會發現某個需求，真的已經過時了，沒有什么用途，并還沒有做，那就可能直接把他拋棄了，那么最后一個P是Prioritized，劃分優先級，這個一直都在強調，在敏捷里頭所有的需求一定不是一視同仁的，應該是按照用戶價值來劃分優先級。

用戶故事地圖

為了更好地組織用戶故事以及進行拆解，還有另外一種工作形式叫用戶故事地圖，故事地圖的出現也是跟前面講的產品需求列表有關系，如果列表內容特別多，而且內容很繁雜的時候，你會發現我們只見樹木不見森林，我有很多需求，但是具體要做什么樣子，這個需求之間的脈絡關系到底是什么，就不一定很清晰了。用戶故事地圖也是應運而生，按照用戶或者多個用戶角色，相互交互的業務邏輯按照時間序列進行依次組合的用戶故事，地圖的制作也體現了共創，專門有一本書就叫《用戶故事地圖》，右下角是用戶故事地圖的發明人叫Jeff Patton，也是在業界內非常有名的一個敏捷教練。

如何做發布規劃和迭代計劃

關于如何做發布規劃，我們有很多需求，需要作出不同版本，決定什么版本包含什么內容，每個版本大概在什么時間去發布，如果能把用戶故事地圖跟發布規劃結合起來，會得到非常好的一個效果。

從想法到落地計劃

假設我們已經有一個用戶故事地圖，按照時間順序從左到右，把多個用戶使用產品的交互順序，以業務邏輯的形式展示出來之后，進行分層細化，比如說先做廣度優先，再做深度有限的細化之后，形成一個大的地圖，在這個大的地圖里邊，理論上來講，缺省的應該是從上到下有優先級的，高一級的在上面，我們畫幾道折線，就可以把最高優先級的挑出來，組成第一個版本，再畫幾個折線挑一部分，組成第二個版本，最后，其他的再畫幾道折線會組成多個版本。

第一個版本稱之為MVP，這個MVP是指最小可行產品，也稱之為minimal variable product，它首先是非常小的，同樣的又是可行，既為客戶帶來價值同時是一個完整的功能，能夠把它做出來代表Product。很多時候大家對于MVP的劃分不得要領，如果你的第一個版本，不能讓你覺得不好意思，那就不夠MVP。如果說發布一個版本，這個版本太好了，其實有可能就做多了。MVP一定要做最必要的精簡內容，因為第一個，我們希望能夠更快速地交付一個產品給用戶，另外一方面，很多時候我們也不知道，用戶想要的需求和真正關心的是什么，用戶很多時候他也說不清楚自己想要什么，只有他看到一個原形的時候，他會才豁然開朗，知道自己想要的跟這個差不多，再在某個方向上，去做一些修正優化，就差不多了。MVP有兩層含義，快速地驗證需求同時避免過度的開發。

這是在實際過程中的用戶故事地圖和真實發布計劃相結合的實例，在一面墻上，做地圖同時做一些規劃，形成了一些發布計劃。

發布計劃與迭代計劃的關系

發布計劃包含內容如果比較多，可能會拆分成若干個迭代來實現，現在的迭代周期通常是一到三周，典型的玩法是兩周，我一個發布可能兩周做不完，大概需要三到四周，一到兩個迭代才能夠把事情做完，一個迭代可能會包含若干故事，故事又會包含若干個任務，只有把這兩個迭代的工作內容全部做完之后，才有可能做一次發布。

前面規劃MVP，內容很簡，正好能夠在一個迭代完成，一個迭代內完成可能又分兩種場景，一種是正好在迭代的邊界也是迭代結束的時候完成了，這種你做一次性發布沒有問題，但還有可能是很多云的產品，比如DevCloud，已經提前幫你開發了很多套件，部署在云上，有很多基礎的服務已經具備了，可能很快就把一個基礎版本MVP搭建出來，可能根本用不了兩周，這時候就可以根據自己的需要直接做發布，有一句話是說按節奏開發，按需要發布，我們做軟件開發做項目本身是一場馬拉松，在這場馬拉松的過程中的形成一個節奏感，這樣才能真正跑完全程，而且效率會更高，所以迭代就是為節奏而產生的。

當然，發布不要跟迭代進行深度綁定，不能只在迭代的結束才做發布，我們希望大家能夠把需求拆解，盡量獨立，這樣兩三個需求做完之后，就可以滿足發布，這樣叫按需發布，持續交付DevCloud很多理念也是在強調這一點。

DevCloud做計劃

在DevCloud中，做計劃是非常容易的，假設我們把所有的需求都以用戶故事、樹狀圖或腦圖的形式，進行不斷的拆解細化之后，接下來做計劃的時候就會進入另外一個計劃視圖，這有項是列出所有未計劃的工作項，未計劃的工作項就像冰山里面那個大的概念，叫Product Backlog產品需求列表，所有沒做的事情列在這里，接下來就可以從高優先級里面挑一部分來，先進行開發。

在挑選的過程中非常簡單，只需要先建一個迭代，迭代里面比如說約定，從7月1號到7月14號，是兩周的時間，是一個迭代，建好迭代之后，直接把對應需求拖過去，就把一個排好序的內容拖到迭代的計劃中去，這樣一個迭代計劃就做出來。

做完迭代計劃之后，用戶故事需求要拆成任務，在做計劃里，DevCloud也非常靈活，可以快速創建小的工作項，這些小的工作項實際上就是一些任務，任務分為前端任務和后端任務，很多時候產品是前后端分離的，后端按模塊的劃分，還可能涉及到一些架構設計文檔的編寫任務，這都可以列出來，跟這個需求相關，自動地就會關聯起來。

在整個迭代計劃做完之后，DevCloud還會有另外一個視圖叫成員模式視圖，其中可以看到每一個成員的工作任務安排情況，可以在整體執行一個小計劃的時候來判斷一下，計劃是否合理，大家的工作是不是有沖突，任務的依賴有沒有問題，可以提前做一些傳統項目管理的風險依賴分析，同時也能從每個人的角度知道每個人到底應該做什么，或者在什么時間內，要完成什么，這樣大家也會有更好的自己的管理職能。

在傳統的項目管理，有個角色叫項目經理，他會統控全局，會做任務的拆解分配，制定計劃去跟蹤。在敏捷中，管理人員會稍微不太一樣，現在流行scrum團隊會有新的三個角色，三個角色分別承擔了不同的管理任務，Product owner主要負責需求，優先級設定，價值的驗證和驗收。Scrum Master? 主要是為大家消除障礙，帶領大家去執行項目的流程，還有就是team，更多的是完成產品功能的交互，三個角色把傳統管理職能進行了承擔，在實際過程中有些組織依然保留了傳統的項目管理角色，這是跟當前的業務和業務特性直接掛鉤的，在敏捷里，只是希望不要依賴一個人去做管理職責，而是一個所有人自我管理和自我組織的形態。

什么是相對估算？如何做相對估算

估算單位：故事點

既然用用戶故事來寫需求，在敏捷里，指需求這個估算單位，我們稱之為故事點，它是一個虛擬的單位，它不能映射成理想日或工時，它是基于你要完成工作的一個復雜度，大家做出了一個相對估算，沒有任何直接映射成經常用的理想日、理想工時的映射關系。他只是代表相對的大小，一個故事是三點，另外一個故事是一點，我們只是認為，三點的故事是一點故事的三倍大就夠了，采用這種方式更容易讓我們達成一致。

比如說，一個寫Java程序的，對java程序很熟，但今天進入了新的項目要用Scala，雖然他不懂，但是組內另外的成員對Scala還熟悉，同樣的Scala語言，一個需求，另一個成員可能只需要8小時，而他可能要12小時，這倆工作效率不一樣，可以先假設一個基準點，都認為這個任務只需要一個故事點，那么對于另外一個故事，可能會要復雜一點，對于另一個成員來講，可能需要20小時，這個故事是前面那個故事的三倍大，而不熟Scala的可能就要花40小時左右，本身因為語言不熟，所以效率比較低，但是不妨礙這個故事是前一個故事的三倍大，這樣的話大家通過相對估算，都容易達成一致，如果用絕對估算，絕對會吵起來，這個就不合理。

使用用戶故事呢，會更容易讓我們達成一致，用戶故事估算中故事點不是理想工時，所以不能夠映射成工期（Duration），用戶故事很有效，就是因為人類特別善于估大小比大小，做估算是一個特殊的數列，這個數列是斐波那契數列，所以用戶故事估值那個點，通常取值是一、二、三、五、八、十三、二十一、三十四，用戶故事會經常進行拆解，斐波那契數列正好符合這種形態，之前一個大故事我們做過估算，重新進行拆解之后，用戶整體需求的規模不會有太大的變化，對于需求，也就是用戶故事，用的是相對估算，取值取一、二、三、五、八、十三、二十一這些值，不能做平均。

計劃紙牌（Planning Poker）

有一種道具叫Planning Poker估算紙牌，大家通過打牌的形式，實現用戶故事的一個估算，用戶的需求的理解是通過團隊協作的一致理解來達成的，我們通過打牌，可視化每個人對需求的理解，我理解認為這個需求是三點，另外一個人可能認為這個需求是八點，我們因為不同，所以可以快速的溝通一下，為什么你理解成八點，我理解成三點，沒準你考慮的場景更復雜，而我忽略了什么，我認為是三點有可能是我找到了更容易的實現方式，通過打牌可視化，把不一致的理解可視出來，然后通過溝通來解決，所以估算得到這個值，既重要也不重要，其實最重要的是溝通。

另一種估算方法T-Shirt Size

除了估算紙牌，用戶故事，故事點，這種估算形式之外，有時候還會用更簡單的估算方式，T-Shirt SizeT恤的大小，只有三個值，大中小分別代表了321，如果太大可以拆一下，基本都符合這個規律就可以了，具體采用什么形式，每個團隊都有自己的傾向，關鍵是在需求理解，一定是通過共享的一致溝通協作來達成的。

推薦書籍

希望通過今天分享的內容，幫大家打開一個新窗口，在傳統的項目管理里，經常會遇到很多問題，在敏捷里把三角形進行顛覆，更多地去樹立，用戶價值、排優先級、不斷迭代交付的思路，幫助我們快速實現用戶需求的確認和驗證。我們希望這些總結和反思，能給正在實施敏捷或將要實施敏捷的朋友們，提供有價值的參考和指導，讓大家少走一點彎路，早日實現敏捷項目開發。

視頻鏈接：https://huaweicloud.bugu.mudu.tv/watch/b7kdpeml

以上文字內容由【內容眾創興趣小組-SUNSKY】整理。

項目管理 ProjectMan 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。