Scrum 敏捷軟體開發 一日體驗營@新竹 - Part 4

講師: David Ko

Outline

  1. 敏捷觀念簡介
  2. Scrum 基礎觀念介紹
  3. 如何組織需求
  4. Scrum 會議
  5. Scrum 開發方法總結

Part 4. Scrum 會議

1. 敏捷評估

小小迷之聲1:
就是評估這個專案可以多久完成啦!以人/天為單位。 是說,比起經驗法則,這個有個依據,雖然很多還是自己定義的 XDD。但忘了問問題的部分是,那個人/天的人的能力標準是以哪個為單位基準? junior 感覺不是,但非常 senior 的工程師感覺會做很快,中間感覺合適。但又感覺應該要依據即將參與這專案的工程師能力素質的比例,來做衡量。比方 junior 與 senior 比例約 3:2 ,如果原先是以介在 senior 和 junior 中間的能力來做估算就還要程以相對的比例,會比較好吧? 不過只是估算啦! 拍腦袋 與 敏捷評估 之間是個誤差值多和少的概念。
小小迷之聲2:
評估這件事真的不能一個人決定呀!經過這活動下來,整個就覺得傳統方式,如果是非工程師估算時間,會因為對方不了解我,然後就壓時程,根本就是惡性循環。然後做得半死的是勞累的員工。整個超不 OK 的!而經過討論評估的時間真的比較 OK,但如果討論時,遇到那種 甚麼,你這竟然覺得要花5天! 的那種人,感覺討論氣氛就不會太好~ 下面回到正題~

1-0. 評估原則

  • 筆大容易
  • 相對比絕對容易
  • 基準(中間值),排相對大小,算時間

1-1. 發布會議解析

  • Why: 想對發佈的時程和內容有個概略的估算
  • Who: PO, Scrum Master, Team
  • When: 產品開發初期
  • I/O: input - 目標、產品需求清單;output - 發布時間、發布內容
  • Step 1. 決定滿足的條件:

    1. 固定時程導向:
    2. 固定功能導向
      評估方向:

因為在敏捷裡,它覺得時程和金錢都是固定的,所以能談的只有範圍

  • Step 2. 評估使用者故事的複雜度與時間

  • Step 3. 決定循環時間

  • Step 4. 評估速度
    團隊最近資料、業界資料

  • Step 5. 排出故事的優先順序 (依商業價值、技術可行性)

  • Step 6. 選擇要做那些故事和決定發布的時間

    1. 固定需求導向(所需循環個數 = 評估的總時數 / 預估的速度)
    2. 固定日期導向(可交付的需求 = 所需循環個數 X 預估的速度)

1-2. Playing Poker?

  • 採費氏數列代表不同的 point (複雜度)
  • 目的:讓大家更了解 Spec ,與共識

小小迷之聲: 阿對~ 這其實不是敏捷的概念,但是因為老闆最重視這個了,所以這方法蠻受用的。

2. Sprint 規劃會議

  • Why: 決定 Sprint 範圍和如何做
  • Who: PO, Scrum Master, Team
  • When: Sprint 第一天
  • I/O: input - 產品需求清單;output - Sprint 需求清單、更新任務版
    Task:
  • 定義: 要完成故事時,其中要做的事情。(最好 1~2 天完成)

3. 每日站立會議 (Daily Scrum)

  • Why: 團隊每日交換資訊
  • Who: Scrum Master, Dev Team (可選: PO, 利害關係人)
  • When: 每天
  • I/O: input - Sync 資訊;output - 調整 Sprint 需求清單
  • 進行模式(站著講、圍半圓看著看板): 1) 完成甚麼? 2) 打算做甚麼? 3) 遇到的困難?

Tip:
有做事的人講話就好。
要互助合作。
15分鐘以內開完。

4. Scrum 檢查會議

  • Why: PO 要驗收團隊的成果,並調整方向
  • Who: PO, Scrum Master, Team
  • When: Sprint 結束前
  • I/O: input - Sprint 目標、產品需求清單;output - 潛在的可交付產品增量、調整後的產品需求清單
  • Demo 技巧:
    • 展示UI雛形,系統架構,測試案例
    • 做完就可以展示
    • 講故事
    • 時間不要太長
    • 開放回饋
    • 找對利害關係人
    • 要真實數據
    • performance test 可以產 report
    • 有做的人都要一起 Demo
    • Demo 前 請先 Windows update
    • 移除個人資料

小小迷之聲: 這看起來好像對研究所報 Paper 也很有用 XD

5. Sprint 回顧會議

  • Why: 希望開發流程或是做事方法能夠更有效率
  • Who: PO, Scrum Master, Team
  • When: Sprint 結束前 (通常在 Scrum 檢視會議結束後)
  • I/O: input - 客觀數據;output - 改善計畫
  • 方法:
    1. 好 or 不好
    2. SKS = Stop, Keep, Start
    3. 帆船法
    4. Fishbone
    5. 4 Ls: Liked, Learned, Lacked, Longed For
    6. Lean Coffee
    7. 焦點討論法(ORID): Objective, Reflective, Interpretive, Decisional

Without a good facilitator, a retrospective most likely will be a disaster. - Luis Gonçalves

小小迷之聲: 覺得就是檢討會的概念,但這檢討後,能夠帶動團隊往好的方向和凝聚軍心,其實我覺得這蠻重要的。即便開檢討會,也是要有效率的。而不是只有形式上的召開。那一點用的沒有。如果開完,Scrum Master 、 PO 把人罵翻,那就準備翻船吧!ㄎㄎ

Related Articles

comments powered by Disqus