介紹

瞭解了敏捷開發 Scrum 的流程之後，我們再來談談 JIRA 。正如前邊所說，JIRA 是一款優秀的問題跟蹤及管理工具。JIRA 採用 J2EE 技術，能夠跨平臺部署。當然，對我們來說，他還有最重要的一個功能，就是協助管理敏捷開發，在經過 Sprint 計劃會議之後，產品經理把討論好的 Sprint 任務列表新增到 JIRA 的 Story 中。而且都包含著開發的具體業務，開發用時，技術難度等。組員們可以去 JIRA 上隨意選擇自己喜歡的任務領取。於是，就開始了一次開發迭代。

功能

考慮到 JIRA 的安裝和配置都比較簡單，而且網上也有很多這方面的教程，這裡就不再贅述了。這裡推薦一篇文章，就是講 JIRA 的安裝和配置《 

jira5.0+greenhopper6.1.6的安裝》。當然我這裡也有一份比較詳細的教程，是專案開發時用於培訓的，由於篇幅比較多，就不再部落格上貼了，有需要的聯絡我就行。這裡，我打算選幾個重要的功能跟大家說一下。

• 專案

安裝好 JIRA 之後，需要首先建立一個專案，這裡我們以許可權系統為例。簡單的介紹一下新專案的新增以及設定。

• 問題型別

專案新增好之後，JIRA 預設的是 Bug 型別，而我們要進行的是管理敏捷開發流程，因此需要對應于敏捷開發中的 Task，這就需要手動的修改一下預設的 Issue 及 Issue 的順序。

• 工作流

JIRA 是基於工作流進行的，而且他也提供了很強大的工作流管理。JIRA 提供的預設工作流為五個狀態：Open，Close，Resolve，In Progress，ReOpen。而我們真正使用的時候，這幾個狀態往往滿足不了需求，例如，一個正在進行的任務，突然發現不符合條件進行，需要掛起，那麼應該放到哪個裡面呢？
GreenHopper看板上面會把Story，Task，Sub-Task等都列上來，而對於Story和Task在我們的思路里，是不希望它們是一樣的處理流程，例如，對於Story我們只希望它從Open到Resolve或Close即可，不需要進入In Progress。基於這些問題，我們需要自己建立一個適合我們專案開發的工作流。 而 JIRA 正是提供了自定義的工作流，讓你自己去設定工作流，以滿足工作的需要。下面來看一下具體的配置。 首先，把預設工作流中用不到的狀態去掉，然後儲存。




到此處為止，我們就把不需要的狀態已經刪除了。當然，為了完成我們自己的工作流，還需要新增一個狀態。






到這裡，自定義工作流就完成了。接下來還需要在配置一下工作流方案，這裡就不再一 一介紹了，有需要的找我就好。

感受

由於之前的專案中，也用過一款國內的專案管理工具 —— 禪道，不過對於敏捷開發來說，基於 Scrum 的理念、開發流程等，總覺得禪道有些不合適（個人感覺），不可否認，禪道已經做的很好了，只是感覺不適合我們這個敏捷開發的專案罷了，各位勿噴。而熟悉了 JIRA 之後，發現 JIRA 更適合敏捷開發。 在 JIRA 的設計理念中，就存在對 Scrum 的一系列支援。當你開始一次迭代時，JIRA 會幫你記錄任何一個時間點，由 待辦 → 處理中 → 掛起 → 完成 。這幾個狀態可以相互轉換，根據具體的條件、具體的任務、具體的環境相互轉換。沒完成一個狀態時，都會有詳細的記錄。而且，JIRA 還會記錄每個人的工作量，統計每個組員完成的任務量。這在績效考核中也是很重要的一部分。

結束語

通過 JIRA，使得我們能夠快速的實施敏捷開發，自動化的管理敏捷開發中的各個環節，使我們能夠把精力集中到業務的實現、技術點的攻克上。而且，有了 JIRA，在敏捷開發中，組員之間的相互協作也更加高效，不會再出現“有人忙得要死，有人閒的要死”的局面了。任務進行的條件無法滿足時，可以先把任務掛起，重新開一個新的任務，當前一個任務滿足條件時，再重新啟用。 在我看來，敏捷開發就是把任務簡化，把任務細化。然後把開發時間精細到每個任務，在最短的時間內集中精力完成任務。這也是為什麼敏捷開發不提倡加班的原因。重要的不是敏捷開發的過程，而是敏捷開發的思想。 JIRA，不僅僅是一款專案管理工具，同時也代表了一種敏捷開發的思想。