迭代甘特圖

本文目錄一覽：

• 1、項目管理常用的工具推薦——WBS、甘特圖、燃盡圖
• 2、甘特圖提高效率的方法已經OUT了，快來試試Scrum法
• 3、用peoject畫甘特圖？
• 4、Atlassian In Action-Jira之核心插件（三）

項目管理常用的工具推薦——WBS、甘特圖、燃盡圖

01

工作分解結構（WBS）

WBS是一種常用的項目管理工具，是把一個項目，按一定的原則分解，總任務在上方，往下分解為分項目，然后進一步分解為獨立的任務。再把任務分配到每個人的日常活動中，通過把項目分解成能有效安排的組成部分，有助于把工作可視化。

WBS以可交付成果為導向對項目要素進行的分組，它歸納和定義了項目的整個工作范圍，每下降一層代表對項目工作的更詳細定義。

WBS結構定義和組織項目，也可用來分解任務以外的東西。預算可根據分解計劃進行計算，在分支定義不明確的情況下，甚至可以計算風險。

02

甘特圖

甘特圖可用于進度計劃編制和進度控制，表達直觀，甘特圖可以體現項目完成比例、責任人和具體日期等。

使用進度貓甘特圖甘特圖把大型項目劃分為幾個小部分，從一個甘特圖中，你可以清晰地看出子任務是什么，以及每個任務何時開始何時結束，每個任務都可以分配給單獨的團隊成員。

可視化地呈現一個項目還可以輕松地了解每個階段會發生的事情，從而跟蹤項目進程。

使用甘特圖，可以確保項目遵守時限，項目經理可以查看所有正在進行的任務以及相對于某些項目里程碑的進展情況。單獨使用此功能有助于使甘特圖對于任何項目都是必不可少的。

03

責任矩陣圖

責任矩陣就是將所分解的工作任務落實到職能部門或個人，表示出他們的關系、責任和地位的方法，它可以清楚地反映工作責任和相互關系，尤其在職能式項目組織模式中，通過責任矩陣強化分工，減少后續分工爭議的風險。

04

燃盡圖

燃盡圖顯示在一次迭代或發布中的剩余工作量。這些圖可以用來追蹤實際速度和預期速度的對比，評估項目績效。燃盡圖用來預測團隊最可能的速度，團隊按照這個速度去開發即將到來的沖刺或迭代交付物，從而促進有效計劃。

發布燃盡圖：項目組在迭代末期通過更新發布燃盡圖來對比計劃進展。當曲線達到零，項目中沒有更多的故事點時，它已經準備好發布。

05

看板

看板幫助監控和管理項目，有助于項目團隊更有效地協同工作，幫助團隊成員將他們必須完成的工作可視化，也這方便項目經理限制正在進行的工作量，平衡工作流，避免給團隊帶來過重的負擔。

實際中的板上卡片可以按優先級排序，因此工作流得到了改進。一旦任務完成，卡片會被移到下一欄，團隊成員就會開始處理他們待辦事項欄最上面的卡片。

進度貓的看板功能，顯示了我們的待辦任務清單、負責的任務、參與的項目及進度，通過看板我們可以知道有哪些任務沒完成，每個項目的進度等

甘特圖提高效率的方法已經OUT了，快來試試Scrum法

商業的本質就是效率，包括創新的效率、生產的效率、迭代的效率、資金的效率等等。長久以來，提高效率的方法大多以命令和控制為主，科學管理、過程控制等管理技術就是其中的代表。 傳統的“甘特圖” 比較直觀地展現了這種模式，首先定義并解釋了每一件必須做的事情，然后以環環相扣的方式展示整個項目的各個部分，每一個步驟、每一個里程碑式的事件以及每一個交付日期都詳細地列了出來，整個示意圖就像一道瀑布一樣傾瀉而下。從表面上看，一切盡在掌握，只要按圖索驥、逐項推進就能夠按期完成任務。事實上，這 往往是錯誤的，甚至是一廂情愿的設想，根本無法真正得到落實。 一方面，詳細而嚴格的計劃進度緩慢，進展往往滯后于計劃，造成預算超支；另一方面，突發事件的發生、需求的改變、政策的調整等內外部因素共同發力，便會導致“甘特圖”成為一張廢紙，原有的意圖要么被延后，要么被更改。

只有改掉舊習慣和老的工作方法，采用更先進、更靈活的工作方法，才能真正地提高效率。這種方法就是薩瑟蘭博士的 “Scrum”方法 。Scrum原本是一套新的軟件開發方法，與傳統的那種規范性、自上而下逐步實施的瀑布式軟件開發辦法相比，是一種徹底的變革。它 先進靈活，具有自我修正能力，自問世以來，這種開發框架已經成為科技行業開發新軟件和新產品的主要方式。 隨著方法的有效性一再被驗證，在全球掀起了一場敏捷革命，成為微信、京東、華為、通用電氣、Twitter、FBI一致采用的管理方法， 在某些案例中，一些紀律性非常強的團隊的工作效率能夠改善8倍。 因此，Scrum方法被譽為“管理學的諾貝爾獎”。薩瑟蘭博士的 《敏捷革命》 一書，便深入淺出地講解了敏捷管理的精髓，精彩地闡述這套管理體系。

Scrum原本是橄欖球運動的一個專業術語，愿意為團隊通力合作，在場地內傳球。這個過程需要認真配合、信念一致和目標明確。這與Scrum工作方法是基本一致的。于是，薩瑟蘭博士將這種敏捷開發流程命名為Scrum。這種方法能夠幫助公司改變固有的工作方式、創新方式，規劃方式以及思考方式，從而達到提高效率、降低成本的目的。

Scrum方法充分考慮了可能出現的不確定性因素，同時具有鮮明的創造性。結構上是圍繞著學習過程建立的。能夠做到在項目執行過程中及時加以調整和改進，而不是刻板地遵循計劃。這樣一來，團隊既可以評估已經取得的成果，也可以評估取得這些成果的方法。這種架構能夠為團隊提供更加高效的工作方式，幫助他們更好地自我組織，提高工作速度，改進工作質量。薩瑟蘭博士指出，每個人都是制度的產物，而Scrum方法會承認和接受這個現實，進而審視導致失敗的制度，最后著力改良制度，從根本上去除影響項目進展問題的根本原因，而不是非要找出一個人來承擔責任，進而從根本上消除影響、拖累項目的不利因素。為了直觀地展現團隊人員的進度，增加項目推進的透明度，薩瑟蘭博士提出了 “Scrum板”的方法。這只是一面張貼許多便箋紙的白板而已，上面會有三種不同的任務狀態：待辦、在辦、完成。 可以很清晰地看出誰負責哪些任務以及進展情況。任何人只要走進辦公室看一眼白板，就能夠精確制導團隊運作的情況。如果任何成員、任何環節出現了問題，團隊能夠及時調整策略，集中時間、集中精力加以解決，從而確保項目進展“航向正確”。

OODA循環是指Observe-Orient-Decide-Act，意為觀察-導向-決定-行動。 在戰爭或商業中，這個循環能產生生死攸關的影響。了解對方的決策回路可以導致他們陷入困惑和疑惑，從而反應過度或反應不足。正如博伊德所講解的那樣：誰的應變速度最快，誰就能幸存下來。“觀察”就是要擺脫自身的局限性，看到周圍所有情況的變化，而不僅僅從自己的視角去觀察。“導向”與你能夠為自己創造多少行動選項有關。這一環節不僅反映出你如何看待這個世界，以及你處于什么位置，也反映出你能看到什么樣的世界。“觀察”與“導向”結合在一起，產生了“決定”，從而催生了“行動”。然后，新的循環從“觀察”開始。這次觀察的則是你與對手的行動產生的后果。在商業方面，觀察對象就是市場的反應。在博伊德OODA的持續循環下，效率將得到不斷提升，與競爭對手的博弈則更加游刃有余。這就是所謂的“戰略上著眼全局，策略上迅速行動。”

與其他方法不同，Scrum強調以下兩點： 一是一次只做一件事情。 專家指出：人們之所以同時執行多項任務，并不是因為他們擅長這樣做，而是因為他們容易分心，難以克制自己去做另一件事的沖動。換句話說，那些最喜歡同時執行多項任務的人自制能力相對較弱，沒有辦法讓自己長時間集中精力。而且，在任務的轉換中，將造成更多的時間和精力的浪費，造成極大損失損失。同時進行多任務處理，勢必導致部分項目止步不前，甚至半半途而廢。半途而廢等于絲毫沒做，一輛半成品的汽車只是消耗了原本可以用來創造價值或節約資金的資源而已。任何在制品都是一樣，只會消耗資金和能源，而不會產生任何有價值的成果。

二是“二八法則”。 在產品開發中，有一條反復得到證明的鐵律： 即一個產品80%的價值來自20%的功能。 在你購買的任何東西中，大部分價值，也就是說人們需要的大部分功能，只是所有功能的1/5。 Scrum的魔力就在于能幫你找出如何先著手創建那20%的功能。 在傳統的產品開發過程中，開發團隊直到最后交付產品也不清楚客戶真正需要的20%的功能究竟是什么。這就意味著他們80%的努力浪費掉了。重要的事情要優先做，Scrum則圍繞20%的核心目標，優先突破，逐級迭代，最終完成項目。但是，優先順序處在不停地變動之中，這一周的順序是正確的，但未必適用于下一周，因為你面臨的環境可能已經改變。所以，薩瑟蘭博士提出，要認識到不確定性因素的存在，充分接受自己目前確定的優先順序和創造的價值僅僅在當前是相對正確的，它將會持續不斷地改變。

在Scrum中，共有三類角色：開發團隊成員，負責開展具體的開發工作；Scrum主管，協助開發團隊把事情做得更好；產品負責人，決定應該做什么工作，擬定待辦事項清單的內容，最終有要的是，確定各個事項的優先順序。Scrum主管與團隊成員的職責是確保工作快速完成，看看是否能進一步加快速度、提高效率，而產品負責人的職責是把團隊的效率轉換成實實在在的價值。這種組織結構的溝通飽和度曾經達到90%，而大多數公司的溝通飽和度大約在20%。溝通飽和度高則直接決定了溝通的效率以及執行的效率，對于項目整體大有裨益。

首先是擬定待辦事項清單和組建團隊。 將產品或服務必須做的事情分解成小的待辦事項，并確定優先順序。待辦事項清單只有一份，產品負責人從頭到尾必須不斷地對優先順序加以調整，改進和評估待辦事項清單。

其次，召開沖刺規劃會，規劃沖刺的內容，確定為期1-2周的的沖刺周期 ，并做好每個沖刺完成事項的記錄，并努力在每一個沖刺階段中提高完成記錄。

第三，要采取“Scrum白板”+“每日立會”的方式，讓整個團隊清楚地知道每個沖刺周期內各項任務的進展，以及相互之間需要克服的障礙。

第四，做好每次沖刺。 既要展示之前沖刺中創造的成果，還要提出下一沖刺階段要做出的改善和成果，集思廣益，共同尋求解決問題的方法。其中的精髓在于，團隊的任務不是自上而下分派的，而是自主決定、自助完成的，也不需要向上司做詳細的匯報。換句話說，就是要激發團隊成員的自主能動性，實現個人創造力和企業效率的有效結合。

通過薩瑟蘭博士在書中的大量操作實例，我們不難看出，Scrum是一種務實的、可以付諸實施的方法，開創了提升個人創造力與企業效率的全新協作模式，不但對于商業組織、政府機關具有借鑒意義，對于個人而言也能夠幫助解決前進路上的各種障礙，最大限度地發揮出自己的能力。正如維爾福軟件公司創辦者格雷格·庫默所說的： “如同工業領域的很多創新一樣，這種管理架構的創新也產生了強大的影響力，改變了我們工作的性質。這非常有用，非常成功，所以，它堪稱一種變革世界的力量。”

用peoject畫甘特圖？

專業的甘特圖，不應該是?photoshop、?illustrator、coreldraw?等做到，除非是ps?高手。因為里面的信息量，圖片素材太多太雜了。

用這些軟件太費事。應該有這樣一個軟件可以包含大量的，圖標素材和背景模板供調用。比如visio和億圖圖示edrawmax就不錯，都有大量的模板可以使用，visio有3000多個模板，億圖圖示更是有12000個模板可以使用。

擴展資料：

Microsoft Project 2013

在最新版本的Project中，微軟提供了更佳的用戶體驗。提供了以下新特性：

用于Project報表的藝術字

Project 2013在報表中支持藝術字。您可以在Project報表中包含圖片、表格、圖表、形狀和文本框。使用藝術字，您可以創建數據的動態視覺效果，甚至可以在動畫和超鏈接中包含這樣的效果。此功能幫助您創建專業報表，而無需Project數據導出到其他程序。

Project中的藝術字的工作方式與它在Microsoft Word、Excel、PowerPoint和Outlook中的工作方式相同。您甚至可以在這些程序之間共享藝術字內容。

更好的即用型報表

至于報表，我們已使用OfficeArt基礎結構創建全新的一組預安裝可視報表模板。這些報表模板替換之前Project版本中的預安裝報表。使用這些新模板，您可以創建鮮艷的動態報表，無需數據導出到其他程序。

豐富的項目報表（燃盡報表）

Project用戶早已能夠通過將Project數據導出Excel數據透視表創建燃盡報表。您可以在Project中快速創建亮麗的燃盡報表。燃盡報表將計劃工時、完成工時和剩余工時顯示為圖表上的線，使項目經理可以一眼看出項目是否能準時完成。

燃盡報表是靈活項目管理方法的關鍵要求。（敏捷項目管理:一種項目管理方法，該方法的迭代時間較短（最長四個星期），采用自適應策略及團隊成員協同工作方式。敏捷項目管理的類型包括齊心協力、關鍵鏈和極限編程。）

任務路徑

查看任務的整個“鏈接鏈”比較困難，尤其在任務的鏈接直接影響該任務或直接受該任務的影響時更是如此。Project 2013允許您突出顯示任何任務的鏈接鏈，即任務路徑。若要查看任務路徑，請轉到甘特圖。單擊“格式”“任務路徑”，然后選擇您要查看的鏈接類型。

擴展日期支持

Project 2013支持的任務和項目日期可達2149年12月31日。比以前長了整整一個世紀！

Backstage檢查

單擊“文件”即可轉到Backstage，它是用于管理Project文件的一站式目的地。我們已針對幾個目標檢查了Backstage：

使其更易于查找所需內容。

使Project與您已熟悉的其他Office程序一致。

為打開文件以及將文件保存到您的計算機、Web、Project Server或者與SharePoint網站保持同步提供統一位置。

更新的視覺效果

Project 2013的外觀有了改善，像MicrosoftOffice套件的其他程序一樣。它具有新穎的外觀，但不會妨礙您的工作簡潔而時尚。我們更關注如何幫助您完成工作，不想讓界面變得過于花哨。

甘特圖以圖示通過活動列表和時間刻度表示出特定項目的順序與持續時間。一條線條圖，橫軸表示時間，縱軸表示項目，線條表示期間計劃和實際完成情況。直觀表明計劃何時進行，進展與要求的對比。便于管理者弄清項目的剩余任務，評估工作進度。

甘特圖是以作業排序為目的，將活動與時間聯系起來的最早嘗試的工具之一，幫助企業描述工作中心、超時工作等資源的使用。

甘特圖包含以下三個含義：

1、以圖形或表格的形式顯示活動；

2、通用的顯示進度的方法；

3、構造時含日歷天和持續時間，不將周末節假算在進度內。

簡單、醒目、便于編制，在管理中廣泛應用。

甘特圖按內容不同，分為計劃圖表、負荷圖表、機器閑置圖表、人員閑置圖表和進度表五種形式。

參考資料來源：百度百科-project

參考資料來源：百度百科-甘特圖

Atlassian In Action-Jira之核心插件（三）

Jira的道在于構建了整個環境和思維模式，也贏得了市場的認可，成了一種勢。無數的廠家便成了Jira的海洋生態當中的重要組成部分。有些廠家的插件是提升了Jira的體驗，有些則是強化了特定功能。這里只推薦三個算得上 必須 使用的插件。

圍繞這三個插件，我們能夠搭建起研發管理的整體路線和迭代管控視圖，簡化流程，完善管理制度。接下來就介紹每個插件的場景和使用方式。

我們通過一張圖形成一個大概的印象

我們當時選擇這個插件期望滿足的場景有下面幾個：

我們項目管理常用的軟件就是微軟的Project，所以我們選項目標也是按照這樣的思路來挑選的。最簡化的概念就是 甘特圖 。

當中有設置的必要的應該是Working schedule了

設置放假和周末，這樣在計算任務起止的時候能夠在甘特圖中正確的顯示，其他我沒有做過多的設置。

從上圖可以看出甘特圖的組織形式分為4層。

1. 項目（Project）

2. 版本（fixVersion）：注意是根據父任務的修復版本確定的

3. 父任務（Story/Task）

4. 子任務（Sub-Task）

在甘特圖的界面可以進行任務的管理。

可以拖動任務的兩端進行開始和截止日期的調整，也可以直接拖動整個任務進行任務的調整。

任務的進度是通過下面的三角標識進度，這個計算是使用實際投入的工時與預計工時直接的比例。

藍色的線是在日期欄直接左擊，就可以設置一個時間線，默認是設置在選擇日期的開始。可以用于設置迭代里程碑。

顯示內容的設置界面如下：

可以看到有四種方式可以混合使用：

1. 面板

2. 過濾器

3. 項目

4. JQL查詢語句

任務列表界面上元素都是可以根據實際系統中設置的字段進行調整的，如下圖所示：

綠色的是自定義字段，灰色的是系統字段。自定義字段基本都是單純的顯示，系統字段會有一些其他的效果。

這個插件在前端沒有任何感知，知道Jira系統中存在這個插件的基本也只有管理員了。但是對于管理員來說，這是流程推進、串聯的最重要的工具了。

它的作用是在工作流的流轉過程中可以附加其他的操作，列表如下：

可以看到主要有賦值、分配人員、評論、觸發其他流轉環節、自定義腳本等等，而且可以針對問題本身、父問題、關聯問題。基本能夠涵蓋日常應用的場景了。

我講一下我實踐過程中，比較常用的幾種場景：

使用到 Assign to last role member 或者Assign to role member 。場景例如bug，當測試發現一個bug時，可能并不直接指定具體研發，而是 提交給研發管理小組 確認之后再分配給具體研發，具體研發人員修改完成后，點擊 修改完畢 按鈕，轉發給測試。測試若發現bug沒有完全修復，點擊 退回研發 按鈕，直接退回對應研發（而且可以累積退回次數）。

這里面的幾個步驟：

1. 修改完畢，會追溯到測試角色的最后一個經辦人，并且將問題分配給他

1. 退回研發，會追溯到研發角色的最后一個經辦人，并且將問題分配給他

為何要追溯某角色的最后一個經辦人？因為內部可能還存在多次指派，甚至對bug進行分析后發現不是后端bug要指定給前端研發。測試不用自己分析要退回給誰，讓流程來判斷。

使用到 Transition linked issues 和Transition parent issue 。我們最早就講過，整個系統是子任務驅動的，具體人員只用關心和管理自己的子任務（子任務只有開始和結束兩個簡單狀態），但是父任務涉及多人合作和角色含義，狀態和節點可能會有幾十個，無論讓誰來管理都是很困難的。場景，一個父任務需要UI、產品、前端、后端、測試共同完成。其中可能產品先行，完成之后交付給UI，完成就可以前后端介入，研發全部完成后才能交付給測試執行。

這里面思想其實很簡單，就是子任務工作流+角色。首先對于不同角色要區分出合理的用戶組，當每個人完成任務時，判斷他自身的角色從而觸發父任務的狀態流轉。比如產品完成任務時，轉至 方案設計完成 ，研發完成時可以判斷當前父任務下是否存在測試子任務，若存在轉至 研發完成待測 ，若不存在說明不需要測試轉至 研發完成無需測試 。

這里給大家一個小小的建議

當你添加自動化工作流時，這里時可以選擇名稱或者id的，id就是一串唯一數字，當你需要精確觸發工作流時可以指定。但是像上面描述的那種情況，其實并不能完全判定當前的狀態是什么。比如需要產品協助時，產品會先完成任務之后研發才開始，這時候研發介入的上一環節是 設計方案完成 ，但是也存在不需要產品研發直接開始比如研發內部優化，這種情況下研發介入的上一環節是 待辦 。如果這時候指定的具體的工作流，起始狀態不正確就無法執行。所以建議是使用名稱，而且建議規范是 轉至+下一環節名稱 ，比如到研發這個環節，無論從待辦或者方案涉及完成，甚至測試退回，都成為 轉至研發 ，這樣我們只要寫一次post function就可以滿足多種情況了。

注意 ：即使使用名稱流轉，也必須滿足該流轉的起始和中止狀態滿足當前情況。例如如果我 方案設計中 如果沒有指向 研發進行中 節點，即使我嘗試觸發該流轉也是無法執行的。

研發在質問我，已經9012年了我們還要使用工時這種low爆的形式來做績效管理么？每天湊滿8小時工作時間對于管理層就這么重要么？你們的能力僅僅就是看著這個人工時有沒有記錄好么？

如果你這么想，說明你沒有想過研發管理到底該做什么。研發管理控制三要素：時間、成本、質量。控制的目的是提升，如何提升？必然是發現問題，改進才能提升。最簡單發現問題的地方是 工時分配 ，而不是某個員工8小時工時本身。某個迭代中，那個story投入的工時超出成本，哪些人的bug工時投入超出正常比例、哪些人的線上問題投入工時較高、整體研發部門投入在非研發工作上的比例是多少，要不要優化。這些才是我們應當去關注并改進的。當所有人員只有3-5個人，可能這個數據受個人影響比較大，但是當人員超過30-50人時，個人少報或者沒有正確填寫的影響就已經比較小了，我們要觀察的是趨勢，大項的時間投入正常都是有記錄的，這樣基本就能夠反應真實情況了。

所以Tempo作為目前時間管理最好的工具，在研發管理中重要性相信各位管理人員都有認知了。

tempo當前最新是9.4.2版本，我使用的是8.15.3 。我嘗試升級過一次插件，結果大家都不習慣新的界面，我不得不退回老版本。

全局配置中有幾點說明，我們是子任務驅動所以工時不允許記錄在父任務。但是只有一個任務下有子任務的時候才是父任務，否則就可以記錄工時。

Work Attributes是設置工時填寫面板的自定義字段

注意 ：這里的字段只有通過記錄工時按鈕呼出的界面才有，比如完成任務時填報工時的界面是沒有自定義字段的。

v9去掉的就是這個工時表，這個基本上是我們最常用的功能了。所以去掉之后大家都不知道怎么用了。

用戶這個地方的下拉框可以選擇如下幾種選項。其中比較難理解的是賬戶這個概念，tempo里面實際上是有成本概念的，就是通過賬戶當中的金額來管理，不過我們沒有使用過。

常用的幾個是用戶（分析單個用戶的工時分布），團隊（每個小組整體任務工時分布），高級（指定過濾器查看任務工時分布），問題（查看單個問題的人員工時分布）

時間區間可以任意指定，查詢出的結果可以直接導出excel用于做透視圖之類的。

v9主推的就是Reports操作的內容和界面形式應該是更加優化，上面的時間區間、過濾器設置（可以多選），分組可以多選和排序。

這個我們用的比較少，主要會針對某個具體問題、或者較大的Epic相關的項目站會、總結會時，分析人員工作進度和使用。

上述三個插件加入到Jira之后，我們完成了迭代整體控制、工作流實施、研發管理規范與提升三方面配置，基本已經可以開始組織一個研發團隊為了同一個既定目標按照統一規范流程進行開發，而且盡量簡化過程降低研發非研發類工作的占比。但是我們還是可以使用一些其他的插件來提高研發管理整體效率。另外必須說一句，這些插件的儀表盤可用插件沒一個能用的。