Scrum

專案管理 Kanban (2)

基本介紹

教學目標

初步了解看板方法的回顧會議之概念。

重點概念

(註: 以下內容主要純屬銀行資訊人員工作經驗分享,並非標準流程。)

在組織內運行看板方法時每個月最好有至少一次回顧會議,類似於 Scrum 中的短衝回顧檢討會議,請參考 Scrum 指南,主要目的為:

  • 檢驗這個月內有關於人員,工作關係,流程,和工具的情況如何。
  • 找出並加以排列做的很好的主要任務們和具有潛力改善的任務們。
  • 制定一個計劃讓團隊的最佳工作方式得以改善。

一開始我們會在看板挑一張準備分享的便利貼 (最有意義的任務) ,並且自己給予評價分數 ( A+、A、B+、B、C ),並且填下以下相關事項。

  • 基本簡介
    • 任務摘要
    • 負責人
    • 評價分數
    • 花費時間
    • 提升效益
    • 感謝何人
  • 執行情況
  • 面臨問題
  • 檢討建議

接著在開始回顧會議之前,我們團隊組長會邀請部門科長、部門協理和敏捷顧問一同參與,並且在現場白板上將每個人的便利貼按照評價分數進行分類,等待會議開始,再來就由團隊組長說明此次開會目的,以及逐一請團隊成員上台分享這個月最有意義的任務,內容包括任務摘要、負責人、評價分數、提升效益、執行情況、面臨問題、檢討建議、感謝何人。此時過程中會由團隊組長將改善建議填寫至便利貼中,每個任務可以有多個改善建議。

當每個團隊成員包括團隊組長都分享完之後,團隊組長就會將改善建議貼至白板中,接著大致說明之後,再請團隊成員個別進行投票,選出得票數最高的改善建議保留下來貼回至看板中時刻提醒團隊們注意該改善建議,例如:SQL 效能優化、SOP 文件準備、簡化工作、…… 等。

此外團隊成員會再依據 Scrum 五大價值觀,分別為承諾、專注、開放、尊重和勇氣,填寫至少兩張好或不好的事項,貼至白板中,接著再由團隊組長將所有事項進行分類,並且大致說明之後,再請團隊成員個別進行投票。再來我們會針對不好的事項,找到最能解決與控管的利害關係人,並且將此次回顧會議的記錄文件複本給提供參考。

最後由敏捷顧問進行評論,指導我們該如何進行改善,以及協助後續與利害關係人的溝通。總結來說,看板方法除了每日的站立會議之外,每月的回顧會議更能夠讓我們更專注於維護和開發的任務中,過程中尊重每個人的意思、開放心胸進行學習、勇氣挑戰優化任務、並且在承諾的時間內完成任務的交付。

相關資源

專案管理 Kanban (1)

基本介紹

教學目標

初步了解看板方法的基本概念。

重點概念

當組織發生變革時我們要如何適應呢?然而不論正向思考或負向思考皆會面臨組織的危機點,此時藉由精實開發之看板方法有效且短時間內修正渡過危機持續成長。從專案開始我們做的第一件事情主要是看見整體,接著定義範圍,可是有挑戰的複雜專案需求會一直改變,此時藉由敏捷開發之 SCRUM 方法有效由上而下處理複雜專案;然而當敏捷開發之 SCRUM 方法與組織文化抵觸時,會先以組織文化為主,也因此敏捷開發之 SCRUM 方法的成功關鍵在於老闆的觀念是否正確。此外若當發現組織文化與看板方法抵觸時則會修正組織文化,同時符合精實開發的原則縮短開發時間,所以當組織發生變革或要導入敏捷開發時最好先從落實精實開發之看板方法開始。

精實開發的原則主要是組織文化的基礎規範,分別為:

  1. 消除浪費
  2. 增強學習
  3. 盡量延持決策
  4. 盡快交付
  5. 授權團隊
  6. 嵌入完整性
  7. 看見整體

第一原則消除浪費主要先繪製出開發流程或價值流程圖,找出浪費時間的原因,像是等待就是一種不能控制的事情,減少等待的時間,以及資源充份應用,就能夠讓時間變的更快。開始的第一步就是使用看板,目前敏捷開發之 SCRUM 方法皆採用看板,因為看板能夠充份表達出昨日主要進行哪些對組織有意義的事情、今日將會進行哪些對組織有意義的事情,以及目前遇到什麼阻礙需要團隊協助解決,同時藉由昨日事情進行自我檢討和今日事情進行自我學習,看板方法的約束相較 SCRUM 方法約束較少,主要有六大核心實務,分別為:

  1. 視覺化
  2. 限制半成品數
  3. 管理工作流程
  4. 制定明確規則
  5. 落實回饋機制
  6. 在協作中持續改善

其中前三項核心實務的約束為主,後三項核心實務的約束則為策略,看板其實源自於豐田主要有兩個原則為零庫存系統和拉式系統,直到 2007 年才正式正名為『看板方法』,主要僅是改變管理方針的途徑。藉由看板能夠讓專案透明化,並且透過給予學習的機會讓團隊成員成長更快速,以及藉由回饋所帶來的價值持續改善。

最後我們都知道專案失敗最主要的原因為需求不明確,此時要如何讓需求更明確呢?主要可以藉由使用者故事以卡片說明、對話問題和測試案例的方式拆解出滿足需求的任務,卡片資訊主要包括標題、工時預估、說明、負責人、重要性、…等資訊。因此主要會由團隊的一起評估開發時間,以及進行討論與回饋,切記卡片主要僅代表團隊對任務的認知,以及最終目標,內容足夠就好,當然除了卡片之外,落實看板方法最好了解看板背後隱藏的規則,並且針對『完成』進行定義,再藉由增刪欄位改善組織文化。總而言之若要導入敏捷開發之 SCRUM 方法之前,最好先導入精實開發之看板方法改善組織文化。

相關資源

專案管理 Scrum (3)

基本介紹

教學目標

初步了解 Scrum 產物的概念。

重點概念

敏捷不是快而是處理複雜的專案,在面對每項任務時估算時間足夠就好。Scrum 主要會由三種面向進行規劃,分別為角色、活動和產物。為了要達到團隊共同溝通所以會採用站立會議,同時使得專案更透明,並且鼓勵學習成員之間共同估算時程和學習做超過能力的事情。其中 Scrum 產物主要分為產品待辦事項、衝剌待辦事項、遞增產品、燃盡圖。

首先產品待辦事項是指一份已經排好順序的事項表,包括了產品所需要的所有東西,並且唯一記錄針對產品有任何改變的必備條件表,其中產品負責人對於產品待辦的內容,可用性和重要順序必須負責任。此外產品待辦事項是動態的,主要會隨著產品的適用性,競爭力和用途來不斷地改變,因此只要產品存在,產品待辦事項就會存在。

接著衝剌待辦事項主要是從產品待辦事項中選出這次衝剌項目主要做的事項,只屬於開發團隊擁有和改變,同時加上發表遞增產品所需要的功能,以及將這功能轉換成完成品所需工作的預測。其中包括足夠細節的計劃,任何進度改變皆可在每日 Scrum 匯報中清楚看到,並且持續修正衝剌待辦事項,一步一步了解哪些是達成衝剌目標必須的工作。此外當有新工作需求時,開發團隊會將相關事項加入至衝剌待辦事項中,並且當工作有進展或完成時,預估剩餘工作量才會被更新。

再來遞增產品主要是指在衝剌期間內所有已完成的產品待辦事項,以及之前衝剌遞增產品價值的總合,同時在衝剌的最後,新的遞增產品必須是完成的。其中所謂完成的意思是代表其使用狀態達到 Scrum 團隊對於完成的定義,必須是可以使用的狀態。

最後燃盡圖主要會在專案完成之前,針對需求完成的相關工作進度以視覺化的方式呈現。其中有 Y 軸代表工作和 X 軸代表時間,在理想情況下,該圖表是向下的曲線,將會隨著剩餘工作的完成進度,燒盡至零為主。

相關資源

專案管理 Scrum (2)

基本介紹

教學目標

初步了解 Scrum 會議的概念。

重點概念

敏捷不是快而是處理複雜的專案,在面對每項任務時估算時間足夠就好。Scrum 主要會由三種面向進行規劃,分別為角色、活動和產物。為了要達到團隊共同溝通所以會採用站立會議,同時使得專案更透明,並且鼓勵學習成員之間共同估算時程和學習做超過能力的事情。其中 Scrum 會議主要分為計劃會議、站立會議、展示會議和回顧與檢討會議。

首先計畫會議主要會訂定衝剌 (Sprint) 內主要做的工作項目,這個會議是限時的,基本一個月以八小時為上限,同時由 Scrum Master 確認會議加開和參與人員了解會議的目的,主要分成上、下半段的會議,上半段主要是講述需求,下半段是團隊將 Sprint 相關的 backlog 拆解成工作項目,接著針對需求的重要性進行重新排序,會先從重要的部份做起,再由團隊共同預估完成工作項目所需要的時間,並且透過此會議能夠回答以下問題:

  1. 本次衝剌的目標是什麼?
  2. 這次衝刺可以發表什麼樣的遞增成品?
  3. 為了要達成遞增成品的發表什麼工作是必須的?

接著站立會議主要是個十五分鐘時限的會議,讓開發團隊能夠同步他們開發的活動,以及針對接下來的二十四小時訂定一個計劃。此時若要達成的話就必須檢驗每日 Scrum 匯報之後的工作項目,以上次為主,並且預估下次每日 Scrum 匯報之前所能夠完成的工作項目。藉由此會議減傳其複雜性,以及每日 Scrum 匯報來檢驗達到衝剌目標進度和趨勢,並且在會議中,開發團隊成員們除了表達今天想學些什麼之外,主要會輪流說明以下問題:

  1. 我昨日做了哪些事情協助開發團隊達成衝刺目標?
  2. 我今日要做哪些事情協助開發團隊達成衝刺目標?
  3. 是否存在任何阻礙物在防止我或者開發團隊達到衝剌目標?

再來展示會議主要是在衝剌期間的最後舉行,檢驗遞增成品和必要調整的產品待辦事項。此時 Scrum 團隊會與利益相關者協同討論在這次衝次完成的工作,主要有以下三件事情:

  1. 產品負責人邀請 Scrum 團隊和主要利益相關者出席。
  2. 產品負責人解釋哪些產品的待辦事項已完成,以及哪些未完成。
  3. 產品負責人討論目前待辦事項,依據目前為止的進度規劃可能完成的日期。
  4. 開發團隊討論遭遇的問題,以及如何解決。
  5. 重新評估產品在市場上或潛在使用方式是否改變了,並且再重新評估產品的時間,預算,潛力和市場等資訊。

最後回顧與檢討會議主要是提供 Scrum 團隊自我檢驗的機會,以及制定可改進的計劃供下次參考。基本上一個月以三小時為上限,會由 Scrum Master 確認會議加開和參與人員了解會議的目的,並且指導所有人在時間內完成會議,在 Scrum 流程上負責任。其中最主要目的則在於檢驗上次衝剌內有關於人員,工作關係,處理流程和相關工具的使用情況如何,找出並加以排序做的更好的主要事項和具有潛力改善的事項,同時在不預設立場和不針對個人的前題下制定讓 Scrum 團隊的最佳工作方式得以改善的計劃。

相關資源

專案管理 Scrum (1)

基本介紹

教學目標

初步了解 Scrum 團隊角色的概念。

重點概念

敏捷不是快而是處理複雜的專案,在面對每項任務時估算時間足夠就好。Scrum 主要會由三種面向進行規劃,分別為角色、會議和產物。為了要達到團隊共同溝通所以會採用站立會議,同時使得專案更透明,並且鼓勵學習成員之間共同估算時程和學習做超過能力的事情。其中 Scrum 團隊角色主要可以分為 Scrum Master、產品負責人和開發團隊,開發工作可由一個或多個 Scrum 團隊進行,每個團隊會由三種角色所組成。

首先產品負責人主要是負責管理和維護產品 backlog,以及保證所有人都能看見,並且確保開發團隊交付工作價值的唯一負責人。簡單來說產品負責人對於開發團隊產品 backlog 有足夠深入的了解,並且能夠清晰達產品 backlog 項目 (Product Backlog Item,PBI),接著依重要性排序,按照最佳的順序達成任務,最後負責對開發團隊所做工作的價值最佳化。

接著開發團隊主要是依照指示完成產品的開發工作,他們屬於自主組織且跨功能的團隊。簡單來說開發團隊會選擇如何以最好的方式完成他們的工作,而不是由團隊以外的其他人來指使他們,此外跨功能團隊擁有完成工作所需要的全部技術,不會需要依賴團隊以外的其他人,目的是以最大限度地優化適應性、創造性和生產力。

最後 Scrum Master 定義為負責確保 Scrum 被理解並實施,並且確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則。簡單來說 Scrum Master 會確保符合流程,並且以各種方式引導成員,以解決問題實務為主,並不以符合規範為主,每次衝剌 (Sprint) 二至三週,藉由發表遞增產品取得客戶回饋資訊,再以回饋資訊針對需求進行優先權調整。其中需求主要使用 User Story 細分任務,並且當成機會或命運,配合燃燒圖確保團隊開發速率節奏和相關貢獻程度。

相關資源