基于GitHub的項目管理方案ZenHub最近創(chuàng)造了“Epics”。這個新工具提供了一個完整的GitHub 問題和問題管理的返工方案，旨在在GitHub中完全管理產品開發(fā)過程。

ZenHub Epics使敏捷epics集成到開發(fā)工作流中成為可能，ZenHub說，在敏捷術語中，epics是更大的用戶故事，這些用戶故事的實現(xiàn)跨越了幾個迭代過程，因此需要被逐步分解為可行的任務，即更小的用戶故事。使用GitHub的開發(fā)者們之前沒有更簡單的方式來在GitHub中創(chuàng)造epics，ZenHub說道，或者他們需要轉而使用GitHub以外的第三方工具，例如JIRA。Epics使完全在GitHub內計劃產品backlog成為可能，ZenHub說道。

ZenHub Epics幫助開發(fā)者們將較大的用戶故事分解，允許開發(fā)者們將其分成幾個子任務并在將來的開發(fā)中追蹤這些任務在整體目標中的完成度?，F(xiàn)存的GitHub問題可以被加入epic中，或者可以直接在epic中創(chuàng)建新的問題。此外，一個問題可以被在任何時間轉化成epic以適應開發(fā)過程中問題變得更復雜的情況。

在擁有自己的詳細信息頁面基礎上，ZenHub Epics還在ZenHub “Boards”中進行了集成，這允許使用GitHub的開發(fā)者們在看板管理中管理問題?？窗逯懈鶕?jù)用戶定義的標準組成的問題群在不同的區(qū)域給用戶提供了一個項目狀態(tài)的快速總覽。Epics在用戶的其他GitHub 問題旁邊展示并且用戶可以使用過濾工具來篩選所有屬于一個特定epic的問題。

　　為了更加了解Epics，InfoQ采訪了ZenHub的締造者者Matt Butler。

使用ZenHub Epics對開發(fā)者們有什么好處？

Epics給GitHub問題提供了一個關鍵的、額外的層次結構。開發(fā)者們可以將他們的任務板與ZenHub Epics匹配起來用，這樣就可以更容易地看到他們離下一次發(fā)布目標的距離。通過使用epics規(guī)劃開發(fā)任務，軟件工程師可以更精確地滿足發(fā)布期限，并從根本上杜絕技術負債。最重要的是，由于Epics使用了GitHub的原生界面（并使用了GitHub已存在的數(shù)據(jù)），開發(fā)者們可以留在他們熟知并喜愛的環(huán)境中。

使用ZenHub Epics對管理者們有什么好處？

開發(fā)團隊的日常工作和生活中已經離不開GitHub了，ZenHub Epics能讓管理者們在GitHub內計劃并共享項目backlog，這是他們的。這可能是第一次真正地在GitHub中管理所有的sprint計劃，而不是使用第三方的平臺。眾所周知，第三方平臺開銷較高，并且功能過于繁雜，權限結構過于分明。由于ZenHub利用了已存在的GitHub數(shù)據(jù)，他們可以確定信息總是精確和最新的。ZenHub和ZenHub Epics為團隊每個人，從管理者到開發(fā)者再到執(zhí)行者，創(chuàng)造了一個“唯一真實的數(shù)據(jù)來源”。

ZenHub Epics和JIRA哪個對敏捷epics的支持更好？

JIRA已被證明是在非技術項目經理中極受歡迎，而ZenHub是特別為敏捷開發(fā)團隊和技術管理搭建的。

首先，ZenHub Epics開銷低，擁有更簡單的權限結構，靈活性更高，并且配置時間幾乎為零。它們是特別為敏捷開發(fā)團隊搭建的，他們需要一個能做他們所需要的事情、然后“解決事情”的工具。

它們最重要的不同之處在于ZenHub所有的功能都以GitHub的原生界面呈現(xiàn)，并且它是唯一的一個提供這樣功能的工具。為什么這很重要呢？

集中一個單獨的工具，消除“信息煙囪”，使團隊把他們的工具集固定下來。

“上下文切換”開銷很高，特別是對于開發(fā)者們來說。ZenHub消除了在工具之間的這種“上下文切換”浪費的時間。因此項目經理可以花更少的時間提醒開發(fā)人員來更新任務，并且開發(fā)人員也自發(fā)地參與到更多的項目管理過程了，因為它就寄生于他們的環(huán)境中——而不是一個沉重的管理平臺。

ZenHub是一個類似Trello的、拖放式的項目管理方案，它搭建在GitHub的基礎上，并與其進行了全集成。它可以在開源項目中免費試用，否則需要付費。在幾個月前就已發(fā)布了ZenHub 2.0，它引進了更多有價值的功能，例如使項目可以跨越多個庫的多庫支持，還引入了燃盡圖、時間估計針對GitHub企業(yè)自運營服務的支持。

查看英文原文：Agile Epics in GitHub with ZenHub Epics