優化甘特圖

本文目錄一覽：

• 1、如何用project制作甘特圖
• 2、project軟件怎么制作甘特圖
• 3、甘特圖的做法及用途
• 4、甘特圖的做法及用途是什么？
• 5、Atlassian In Action-Jira之核心插件（三）

如何用project制作甘特圖

先編制計劃步驟：

設置工作間項目起始（或結束）期并新任務設置自任務（便自調整）；

資源工作表列項目所用資源詳細信息；

鍵入任務名稱、資源名稱、工期；并用摘要任務進行組織（詳見WBS代碼）；

設置任務間關系（主要前置任務）；必要部任務設置程限制；

項目計劃進行調整、優化

二

視圖切換甘特圖能看軟件自甘特

project軟件怎么制作甘特圖

一

先編制計劃，步驟：

設置工作時間和項目的起始（或結束）日期，并將新任務設置為“自動任務”（方便自動調整）；

在資源工作表中，列出項目所用資源的詳細信息；

鍵入任務名稱、資源名稱、工期；并用摘要任務進行組織（詳見WBS代碼）；

設置任務間關系（主要是前置任務）；有必要的話，為部分任務設置日程限制；

最后對項目計劃進行調整、優化。

二

將視圖切換到甘特圖，就能看到軟件自動生成的甘特圖。

甘特圖的做法及用途

在項目管理中，甘特圖是通過圖形的方式更直觀的表現出任務安排以及任務之間的關聯性，有了甘特圖，可以使項目經理從大量的密密麻麻的表格中解脫出來。

如果你使用的專門的項目管理軟件（推薦MS Project），其實不需要特別編制甘特圖，只需要你將任務填寫清楚，包括：任務名稱，工期，開始和完成時間，前置任務，資源名稱等基本內容，軟件會根據你錄入的內容自動生成甘特圖，在今后的閱讀中十分方便。

甘特圖（Gantt chart）又稱為橫道圖、條狀圖(Bar chart)。其通過條狀圖來顯示項目，進度，和其他時間相關的系統進展的內在關系隨著時間進展的情況。以提出者亨利·L·甘特（Henrry L. Ganntt）先生的名字命名。

甘特圖的做法及用途是什么？

1、計劃評審技術是用來安排大型、復雜計劃的項目管理方法。是一種規劃項目計劃

(project)的管理技術，它利用作業網(net-work)的方式，標示出整個計劃中每一作業

(activity)之間的相互關系，同時利用數學方法，精確估算出每一作業所需要耗用的時間、經費、人力水平及資源分配。

計劃者必須估算：在不影響最后工期(project

duration)的條件下，每一作業有多少寬容的時間，何種作業是工作的瓶頸

(bottle

neck)，并據此安排計劃中每一作業的起記時刻

(scheme)，以及人力與資源的有效運用。PERT的內容包含了「管理循環」中的三個步驟：計劃(planning)、執行(doing)、和考核(controlling)。

2、甘特圖，也稱為條狀圖(Bar

chart)。是在1917年由亨利·甘特開發的，其內在思想簡單，基本是一條線條圖，橫軸表示時間，縱軸表示活動(項目)，線條表示在整個期間上計劃和實際的活動完成情況。它直觀地表明任務計劃在什么時候進行，及實際進展與計劃要求的對比。

管理者由此極為便利地弄清一項任務(項目)還剩下哪些工作要做，并可評估工作是提前還是滯后，亦或正常進行。是一種理想的控制工具。

甘特圖的含義

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

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

2、現在是一種通用的顯示進度的方法；

3、構造時應包括實際日歷天和持續時間，并且不要將周末和節假日算在進度之內。

甘特圖具有簡單、醒目和便于編制等特點，在企業管理工作中被廣泛應用。甘特圖按反映的內容不同，可分為計劃圖表、負荷圖表、機器閑置圖表、人員閑置圖表和進度表等五種形式。

3、最早出現于20世紀50年代，它是通過分析項目過程中哪個活動序列進度安排的總時差最少來預測項目工期的網絡分析。其通常做法是：

1）

將項目中的各項活動視為有一個時間屬性的結點，從項目起點到終點進行排列；2）

用有方向的線段標出各結點的緊前活動和緊后活動的關系，使之成為一個有方向的網絡圖；3）

用正推法和逆推法計算出各個活動的最早開始時間，最晚開始時間，最早完工時間和最遲完工時間，并計算出各個活動的時差；4）

找出所有時差為零的活動所組成的路線，即為關鍵路徑；5）

識別出準關鍵路徑，為網絡優化提供約束條件；

特點：

關鍵路徑上的活動持續時間決定了項目的工期，關鍵路徑上所有活動的持續時間總和就是項目的工期。

關鍵路徑上的任何一個活動都是關鍵活動，其中任何一個活動的延遲都會導致整個項目完工時間的延遲

關鍵路徑上的耗時是可以完工的最短時間量，若縮短關鍵路徑的總耗時，會縮短項目工期；反之，則會延長整個項目的總工期。但是如果縮短非關鍵路徑上的各個活動所需要的時間，也不至于影響工程的完工時間。

關鍵路徑上活動是總時差最小的活動，改變其中某個活動的耗時，可能使關鍵路徑發生變化。可以存在多條關鍵路徑，它們各自的時間總量肯定相等，即可完工的總工期。

關鍵路徑是相對的，也可以是變化的。在采取一定的技術組織措施之后，關鍵路徑有可能變為非關鍵路徑，而非關鍵路徑也有可能變為關鍵路徑。

另外,站長團上有產品團購,便宜有保證

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