Scrum完整項目實例

1、背景

在談 JIRA 以前，就不得不說說敏捷開發了。正式因爲項目是基於敏捷開發進行的，所以才引入了 JIRA 這款適合於敏捷開發的項目管理工具。固然，這裏不會大篇章的介紹敏捷開發，以前的文章有詳細講過《敏捷開發系列終極之旅》。這裏簡單的再回憶一下敏捷開發的流程。

2、流程

Scrum 是一個用於開發和維護複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱爲一個Sprint，每一個Sprint的建議長度是2到4周(互聯網產品研發可使用1周的Sprint)。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式一般爲用戶故事。Scrum團隊老是先開發對客戶具備較高價值的需求。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上通過討論、分析和估算獲得相應的任務列表，咱們稱它爲Sprint backlog。在每一個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。 Scrum起源於軟件開發項目，但它適用於任何複雜的或是創新性的項目。

Scrum流程以下圖：

2.1 SCRUM框架包括3個角色、3個工件、5個事件、5個價值

2.1.1 3個角色

1. 產品負責人（Product Owner）
2. Scrum Master
3. 開發團隊

2.1.2 3個工件

1. 產品Backlog（Product Backlog）
2. SprintBacklog
3. 產品增量（Increment）

2.1.3 5個事件

         

1. Sprint（Sprint自己是一個事件，包括了以下4個事件）
2. Sprint計劃會議（Sprint Planning Meeting）
3. 每日站會（Daily Scrum Meeting）
4. Sprint評審會議（Sprint Review Meeting）
5. Sprint回顧會議（Sprint Retrospective Meeting）

2.1.4 5個價值

1. 承諾 – 願意對目標作出承諾
2. 專一– 把你的心思和能力都用到你承諾的工做上去
3. 開放– Scrum 把項目中的一切開放給每一個人看
4. 尊重– 每一個人都有他獨特的背景和經驗
5. 勇氣– 有勇氣作出承諾，履行承諾，接受別人的尊重

2.2 SCRUM理論基礎

Scrum以經驗性過程控制理論（經驗主義）作爲理論基礎的過程。經驗主義主張知識源於經驗, 以及基於已知的東西作決定。Scrum 採用迭代、增量的方法來優化可預見性並控制風險。

Scrum 的三大支柱支撐起每一個經驗性過程控制的實現:透明性、檢驗和適應。Scrum的三大支柱以下：

2.2.1 第一：透明性（Transparency）

透明度是指，在軟件開發過程的各個環節保持高度的可見性，影響交付成果的各個方面對於參與交付的全部人、管理生產結果的人保持透明。管理生產成果的人不只要可以看到過程的這些方面，並且必須理解他們看到的內容。也就是說，當某我的在檢驗一個過程，並確信某一個任務已經完成時，這個完成必須等同於他們對完成的定義。

2.2.2 第二：檢驗（Inspection）

開發過程當中的各方面必須作到足夠頻繁地檢驗，確保可以及時發現過程當中的重大誤差。在肯定檢驗頻率時，須要考慮到檢驗會引發全部過程發生變化。當規定的檢驗頻率超出了過程檢驗所能允許的程度，那麼就會出現問題。幸運的是，軟件開發並不會出現這種狀況。另外一個因素就是檢驗工做成果人員的技能水平和積極性。

2.2.3 第三：適應（Adaptation）

若是檢驗人員檢驗的時候發現過程當中的一個或多個方面不知足驗收標準，而且最終產品是不合格的，那麼便須要對過程或是材料進行調整。調整工做必須儘快實施，以減小進一步的誤差。

Scrum中經過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，作出調整，從而優化第二天的工做價值；Sprint評審和計劃會議檢驗發佈目標的進展，作出調整，從而優化下一個Sprint的工做價值；Sprint回顧會議是用來回顧已經完成的Sprint，而且肯定作出什麼樣的改善可使接下來的Sprint更加高效、更加使人滿意，而且工做更快樂。

2.2.4 更多敏捷開發資料

因本文重點內容爲jria的完整項目用例，對SCRUM敏捷開發的相關內容，咱們就不作具體討論了。有興趣，請點擊scrum中文網。

3、開始咱們實例製做

3.1 建立項目

• 訪問http://10.10.25.252:8080
  
• 新建項目
  
  選擇下一步
  
  填寫項目名--提交
  
  以上就是咱們的項目，能夠正常使用了

3.2 簡單使用

• 問題處理實例

  • 在項目中新建故事問題

    • 選擇項目→ 新建 →建立問題→  項目名→ 問題類型（爲故事，其餘類型詳見自定義）→ 概要（實現什麼功能）→ 問題描述→ 優先級(緊急程度)→ 附件（問題的截圖或需求文檔）
      → 連接問題(關聯已建立問題類型)  → 問題（關聯問題名）→ 經辦人（問題處理人）→ 史詩鏈接
      
      
    • 如今咱們已經用admin帳號委託給本身
      點擊問題可查看到此問題
      
      
      
    • 如被分配人在處理其餘請求，須要再次手動分配給其餘人
      

• 創建面板

  • 新項目須要創建的面板(本次看板類型爲scrum)

    • 建立面板
      
    • 面板依賴來於一個已有項目
      
      
    • 填寫面板名稱，項目，並建立面板
      
      
    • 配置面板（）
      
      詳情後續介紹
      
      

  • 將問題添加到面板

    • 被委派人登錄帳號，點擊項目選擇，剛剛被委派的項目，查看到一個新的故事問題TEST-4
      
    • 點選建立問題（此時爲把需求問題轉化爲功能點，細化，也能夠稱之爲任務）（任務下還能夠建立子任務，因子任務與問題任務的建立方式相似，這裏就再也不重複了。）
      
      相似於問題的建立過程，也能夠委派人員完成任務
      
      
      

  • 根據任務評估時間，後評估整個故事的時間

    • 選中任務，彈出側邊欄
      
      選擇登錄工做→ 填寫時間→ 點擊日誌完成
      
      
      
    • 選中問題， 同任務
      
      
      

  • 活動泳道的使用(項目衝刺階段使用)

    • 進入項目→ 選擇活動的Sprint →代辦事項
      
    • 點擊建立sprint
      
    • 把任務推拽的上方→ 點擊開始Sprint
      
    • 預估時間
      
    • 查看並更改狀態
      
    • 拖拽圖
      
    • 所有完成後→ 點選完成Sprint
      
    • 回顧總結吧，小夥伴們。
      
    • 神奇的跳到confluence，竟然還有模塊，厲害了
      
      

      到知識庫中去一塊開會總結經驗成果吧

      
      
    • 結構圖
      

• 版本的發佈（使用史詩問題）

  • 創建版本計劃

    項目→ 管理版本
    

  • 發佈
    

  • 歸檔
    

• 創建報告

  • 生成報告

    1. 導航到所需的主板，而後單擊報告。將顯示上次查看的報告。
    2. 點擊切換報告查看不一樣的報告。這個列表中的報告是特定於敏捷開發的。
       有關更多詳細信息，請參閱下面的「Scrum項目報告」或「Kanban項目報告」部分。
    3. 若是您想要查看不是特定於敏捷開發的報告，請從「 交換機報告」下拉列表中選擇全部報告，並查看不在「敏捷」部分中的報告。
       有關更多詳細信息，請參閱下面的「常規分析問題報告」部分。 

  • Scrum項目報告

    圖表	適用於	目的
    燃耗圖	衝刺	跟蹤所有剩餘工做而且計劃完成sprint目標的可能性。這有助於您的團隊管理方面取得的進展和做出相應的反應
    Sprint報告	衝刺	瞭解每一個sprint中完成的工做或者退回後備的工做。這有助於您肯定您的團隊是過量使用或若是有過多的範圍擴大。
    速度圖	項目，版本或衝刺	跟蹤各個Sprint已完成的工時量。這有助於您肯定您的團隊的速度並預估團隊在將來Sprint中實際完成的工做。
    累積流程圖	任何一段時間	顯示隨着時間的推移問題的狀態。 這有助於識別須要調查的潛在瓶頸。
    EPIC報告	史詩	顯示隨着時間的推移完成史詩的進展。 這有助於您經過跟蹤剩餘的不完整和不肯定的工做來管理團隊的進度。
    EPIC燃燒圖	史詩	與Epic Report相似，但針對Sprint中的Scrum團隊進行了優化。跟蹤完成史詩所需的衝刺數量。 這能夠幫助你監視史詩是否會按時釋放，因此若是工做落後，你能夠採起行動。
    發佈燃燒圖	版本	相似於版本報告，但針對在sprint中工做的Scrum團隊進行了優化。 跟蹤版本的預計發佈日期。這有助於您監控版本是否能及時發佈，以便在工做落後的狀況下采起措施。
    速度圖	衝刺	跟蹤從衝刺到衝刺完成的工做量。 這有助於您肯定團隊的速度，並估計您的團隊在將來的衝刺中能夠切實實現的工做。
    版本報告	版本	跟蹤版本的預計發佈日期。