JIRA中的史詩、故事、版本與衝刺

史詩, 故事, 版本與衝刺

這四輛馬車能夠優雅地管理敏捷過程的範圍和時間表。並構建您的工作。

一旦軟體團隊熟悉瀑布或其他傳統項目管理風格，他們常常感到「如何構建我的工作」的痛苦。 幸運的是，敏捷開發使用四個明確的交付工具，將結構帶入任何敏捷項目：史詩，用戶故事，版本和衝刺：

· Epic 史詩 大量的工作，包含故事

· Story 故事 最小的工作單位，也被稱為任務

· Version 版本 向客戶發布的軟體

· Sprint 衝刺 團隊事務處理的迭代

通過使用這四大工具，軟體團隊能夠組織工作並將其分解成可以實現的部件，因此可以優先考慮客戶的反饋意見，並從項目的原始計劃中進行改變，而不會覺得像被各種牆圍繞一樣而感到奔潰。

根據當前見解改變和適應未來計劃的能力是敏捷性的標誌。在這篇文章中，我們將定義這四種交付工具，並展示它們如何組合在一起構建您的工作。 但首先，我們來討論每個工具之間的區別。

史詩 v.s. 故事

史詩是更大的工作，涉及到很多的故事。 史詩可以跨越多個衝刺和版本。 版本與史詩不同，因為它們是軟體發布給客戶的時間點。 版本可能包含多個史詩。 史詩幫助團隊創建層次結構和架構。 故事幫助團隊跟蹤手頭任務的具體細節，並將其細分為子任務。

上圖中顯示的工作可以選擇為，在一個或多個衝刺期間完成的版本。

舉措(Initiative)發生在組合層。 重要的是將問題在該層面指出，以便發現史詩通常是更具戰略性的目標或舉措。 當進行長期規劃時，可以制定這些舉措，並通過JIRA工具來捕獲這些工作。

什麼是史詩？

史詩是一大堆的工作，可以分解成許多較小的故事。例如，版本發布中與性能有關的工作。如果史詩所屬的面板中包含多個項目，史詩可以跨越多個項目。

與衝刺不同，史詩經常隨著時間的推移變化，作為敏捷開發的一個自然方面。史詩幾乎總是通過一系列衝刺傳遞。隨著團隊通過開發和客戶反饋了解有關史詩的更多信息，將添加和刪除用戶故事，以優化團隊的發布時間。

史詩的例子

根據使用的敏捷框架（Scrum、看板或自己獨特的風格），敏捷史詩可以不同方式使用。

對於看板(kanban)，史詩可以用作泳道來分割不同的工作流。如果您正在使用scrum，史詩可以幫助您標記衝刺中的工作，如下面的示例。火星任務(Mission to Mars)在這個衝刺中是史詩。 TIS 1，TIS 2等都是衝刺中的用戶故事（TIS Sprint 1）。你可以看到，衝刺中有多個用戶故事和史詩。

衡量史詩

燃盡圖(Burndown)也可用於可視化史詩，從而保持團隊的積極性與執行利益相關者的關注。 好的史詩燃燒圖顯示了敏捷的發展性質。 清楚展示團隊的進度以及產品所有者添加和刪除用戶故事的地方。將這些數據清楚地顯示出來，每個人都可以對項目狀態保持一致認識，並促進關於產品演進和完成預測的開放交流。更不用說公開透明能夠建立的信任了！

什麼是用戶故事？

故事或用戶故事是敏捷框架中最小的工作單元。這是個軟體系統要求，用幾句短語表達，理想地使用非技術語言。

用戶故事的目標是將特定價值提供給客戶。請注意，「客戶」不必是傳統意義上的外部最終用戶，也可以是依賴您團隊的組織內部客戶或同事。

用戶故事是簡單語言中的幾句話，概述了所需的結果。他們沒有詳細的要求。

用戶故事示例

用戶故事由產品所有者(product owner)勾畫出來，然後整個產品團隊共同決定更詳細的要求。這些細粒度工作，有助於定義故事和即將到來的衝刺的執行。

在一個故事中，需要一系列任務，這些任務在用戶故事的估計過程中應該被補充，並在團隊的問題跟蹤器中進行鏈接。

使用與上述相同的例子，這個衝刺中的故事顯示了預估、優先順序、處理人、史詩和描述，所以每個人都可以快速了解正在完成的工作。

什麼是版本?

版本是向客戶發布軟體的實際版本。請記住，在每個衝刺結束時，團隊應該能夠將軟體提交給客戶。版本是產品所有者實際提交的策劃變更。

版本經常貫穿於一系列衝刺中開發，就像史詩一樣。精明的產品所有者可能會選擇在幾個版本上提供史詩。一個史詩不必完全包含在一個版本中。通過幾個版本交付某個史詩，產品所有者可以了解市場如何響應史詩，並對其未來發展方向做出評估決策，而不是做一個巨大的發布。

版本的例子

產品所有者可以按如下方式構建發布策略：

· 版本1：登錄，註銷，密碼管理

· 版本2：購買歷史

· 版本3：保存偏好

· 等等

版本範圍變化也是敏捷開發的自然部分。 Burndown圖表讓整個團隊了解版本隨著時間的推移。應與整個團隊討論對版本的更改，以將每個人都放在同一頁面(整體認識)上。

什麼是衝刺？

衝刺是一個很短的周期，開發團隊實施並提供離散和潛在可交付的應用程序增量，例如工作的里程碑版本。如果您以前沒有運行衝刺，我們建議您為每個衝刺使用固定的兩周持續時間。時長已經足夠完成任務，但也不會長到團隊無法獲得任何正常反饋。

注意：Sprint只是Scrum框架的一部分。相比之下，看板團隊在吞吐量允許的情況下就可以著手積壓下一個項目上的工作。不需要預測。

在Scrum中，團隊承諾在固定時間段內完成一組用戶故事。一般來說，衝刺是一，二，四周。由隊伍決定衝刺的長度。一旦確定了衝刺節奏，團隊將永遠按照這種節奏運作。只要擁有幾個完成的衝刺的數據，固定長度的衝刺能增強評估技能，並且能夠預測團隊的未來速度。

衝刺的例子

與上述相同的例子，下圖中的衝刺TIS Sprint 1是用戶故事的集合。

關於衝刺你應該知道一些事:

一旦團隊承擔了一連串衝刺的用戶故事，並且Sprint已經開始，Scrum主管將負責防範用戶故事的更改。 這使得團隊集中精力，並且抗擊「範圍蠕變」（在衝刺開始之後，將工作量添加到衝刺中）。 加入中期衝刺可以幫助團隊準確預測和估計團隊的能力。

在每個衝刺結束時，團隊需要提供一個工作的軟體。 在scrum中，這稱為潛在的可交付增量（PSI）。 產品所有者最終決定PSI何時發布給客戶，但是工作應該足夠完整，以適應在衝刺結束時的發布。

衡量你的衝刺

任何Scrum團隊的好工具是燃盡圖表。 他們清楚地跟蹤Y軸上的「剩餘工作」和X軸上的「時間」在整個衝刺中的進度。 Burndown圖表是團隊的強大動力，他們在衝刺中保持每個人的注意力。 最重要的是，這些圖表提供了有關衝刺進度的討論中的支持數據。

擴大

較大的組織通常會有幾個敏捷團隊在一個共同的計划上工作，而組合計劃是規模運行敏捷的關鍵。 史詩和版本為團隊層面的敏捷投資組合管理奠定了基礎。 敏捷投資組合管理包括跨多個團隊的跟蹤計劃，同時在組織的較高層面保持同樣水平的敏捷性。 在敏捷組合部分，詳細了解敏捷規模。

如想學習更多IT技術，請前往51Testing軟體測試網-中國軟體測試人的精神家園哈~