10分鐘讀懂 Scrum Agile 敏捷軟體開發專案入門（含中文英文名詞對照）
江湖上軟體開發有兩個大門派，第一個門派歷史跟軟體一樣久，心法是以流程為主軸，正式名稱瀑布式開發（Waterfall），最具代表的武功就是CMMI，幾年前台灣政府大力推動支持。另一個門派在1990年代異軍突起，心法是以人為主軸，正式名稱為敏捷式開發（Agile），最知名的武功是Scrum。
江湖上軟體開發（或專案管理）有兩個大門派，第一個門派歷史跟軟體一樣久，心法是以流程為主軸，正式名稱瀑布式開發（Waterfall），最具代表的武功就是 CMMI，幾年前台灣政府大力推動支持。另一個門派在1990年代異軍突起，心法是以人為主軸，正式名稱為敏捷式開發（Agile），最知名的武功是 Scrum，但在台灣則是這一兩年才開始熱門起來。（註：Scrum 的原始意思是橄欖球的爭球動作，在軟體界沒有翻譯成中文，都是直接叫 Scrum）
兩個門派最大的不同在中心思想，用中國的哲學流派來比喻，瀑布式開發是法家，法為主，人為輔，強調「不別親疏，不殊貴賤，一斷於法」。只要規則定下去，照著做就會有好產品，鐵打的營盤流水的官，人的因素要盡可能排除以利產出的一致性。
而敏捷式開發是道家，人為主，法為輔，主張「道法自然」。道是沒有一定的形式，要觀察目前的情境，考量人的天性，因勢利導，以求功成事遂，百姓皆謂我自然。
總之敏捷式的專案管理門派更注重在人的層面，講求的是從快速從經驗中學習反應和團隊的自我管理。
而 Scrum 這套武功之所以比起其他的武功如看板、極限開發（XP）更有名，是因為一般認為比較容易導入或入門。因為 Scrum 裡角色和活動定義明確，又不提技術細節，讓不懂技術的老闆也可以聽懂（技術活也是很重要滴，請參考XP）。 很多堂口導 Scrum 就落入了做敏捷，而不是變敏捷的陷阱，如果組織已經在跑敏捷，可以看看這清單確認一下是真敏捷，還是拜飛機式的敏捷 XD。
如果還沒導入，恭喜你，可以先考慮 Scrum 會帶你上天堂還是地獄，並可參考 Scrum 不包生導入指南，還有破除敏捷=快的迷信。
Scrum 角色
Scrum 只有三種角色，至於其他角色如部門主管在 Scrum 框架外裝作看不到不討論。所有成員都要抱持敏捷的精神和態度。
Development Team（Dev Team，開發團隊）：可以獨立完成任務的特種部隊，人數5-9人（7+/-2）。大絕是我決定該怎麼做（How），武器是自我管理和持續改善的能力。每個人都有自己的特長，但依任務需求自行安排工作內容。類似射雕英雄傳裡全真七子所部的天罡北斗陣，如任一人受敵時，左右會來相救。
Product Owner（PO，產品負責人）：：產品的守護者。大絕是要做什麼我說了算（What），武器是敏銳的市場嗅覺的和擺平利害關係人。如同射雕英雄傳裡北極星位對天罡北斗陣的影響，當郭靖站到了北極星位就可以驅動全真七子。PO 要決定產品的規劃和為產品的成敗負責，可以參考一些PO 常常絆倒的地方。
Scrum Master（SM，無中文名稱）：Scrum 功夫的傳道者，唯一的大絕是影響力，武器是異於常人的信心與耐心。有人覺的他是 Team Lead 或是 PM 的角色。但其實他沒人事權不能管人，沒財務權不能編預算，更可憐的是不能決定產品的走向，是個令人摧心的角色。最常見的安排是PM 直接轉 Scrum Master，或是主管自己跳下來兼 Scrum Master，會把 Scrum Master絆倒的地方也不少。
以上三者又統稱Scrum Team 或 Team。
Scrum 物件: Scrum 中常會提到的物件與中文名稱。
Item（物件）：又稱 Story，是 PO 定義的產品產出。Item 大小要講究，要可以讓團隊在一般的速率下，可以完成3-5個。太多太繁雜，太少萬一沒做完就感覺整個 Sprint 一事無成，對團隊信心是個打擊。
Task（工作）：是 Dev Team 針對 Item（不是 PO 也不是 SM 哦），列出完成 Item 所需的工作。工作分配是開發團隊自己安排。
Product Backlog（產品待辦清單）：由 PO 負責整理的產品願景圖，以 Item 為單位，施工順序由上而下。
Sprint Backlog（衝刺待辦清單）：Dev Team 向 PO 承諾這個 Sprint 會盡力完成的 Item List。以 Task 為單位。
Potentially Shippable Product Increment（潛在可交付產品增量）：開發團隊的產出，簡單的說就是 PO 說要上線就可以馬上上線的東西才算數。
Burndown Chart（燃盡圖）：有點類似怪物的血條，看看還剩多少血怪（Sprint Backlog）才死。以 Task 大小為單位。
Scrum活動: Scrum 活動每一個都是有他的目的和時間限制（Time Boxed）。
Sprint（衝刺）：顧名思義，當團隊決定要哪些 Item 後，就著手去衝。Sprint 長度定義上是1-4個禮拜，但實務上不要多過2個禮拜。而且 Sprint 長度應該要保持穩定盡可能不變。這樣才容易讓團隊掌握節奏，也容易預估和比較 Sprint 內的工作量。大原則是 Sprint 內的 Sprint Backlog 不改變（有原則就有例外）。
Daily Scrum（每日站立會議）：每天10-15分鐘不能超時，目的是讓團隊資訊同步。一定要站著罰站為了讓大家長話短說。
Sprint Planning（衝刺規劃會議）：Sprint 開始時，討論一下這個 Sprint 團隊可以交付哪些Item。Item 優先順序 PO 決定，要選多少 Item 由 Dev Team 決定。
Product Backlog Refinement / PBR（產品待辦清單精煉會議）：PO 跟 Team 一起討論近期內會開始施工的 Item，主要是從商業和使用者角度切入，盡可能不觸及技術細節。
Sprint Review（衝刺檢視會議）：Sprint 結束時針對產品的會議，PO邀請利害關係人對產出給意見，是要可用的軟體才算產出。不準備Powerpoint或其他簡報，單純就軟體操作取得回饋。
Sprint Retrospective / Sprint Retro（衝刺回顧會議，我偏好稱為『自省』會議）：Sprint Review 後，Scrum Team 成員（Dev Team 或包含 PO），針對這個 Sprint 團隊的工作模式討論改善，并定出下個 Sprint 改善事項。為了創造一個安全的環境，原則上只有團隊成員才能參加。
Scrum 是個易學難精的架構，導入一個月就似模似樣入門了，但背後的精神如團隊自我組織、持續改善要數個月到數年才能見效。持續學習是必要的。
Scrum 的架構適合一個產品配合1-3個開發團隊。如果一個產品需要更多人打群架，有兩套基礎於Scrum 的終極陣法，一套是同樣以人為本的LeSS（Large Scale Scrum），另一套是加入流程控制的SAFe（Scaled Agile Framework），可以參考 LeSS 和 SAFe 的比較，和兩者運用組織權力的差異。
作者簡介：
敏捷黑手阿伊（Yves Lin），宅男工程師出身，生命中超過一半的時間在海外漂泊，靈魂中理性水瓶和感性雙魚反復爭鬥，相信敏捷 Agile 是這亂世中的生存之道。
原本以為軟體開發的宿命就是爆肝、底累、修罷、賣雞排。接觸敏捷後，才發現其實還有不同的可能性。好讀書不求甚解，特別喜歡歷史、地理、心理學，近期著重在於組織行為（Organizational Behavior）與團體動力（Group Dynamics）。
2005年加入致力於成為敏捷企業的新加坡商鈦坦科技（Titansoft），產品為線上娛樂平台開發商。現職為戰略顧問，期許自己是團隊的漿糊把團隊凝聚在一起，夢想是可以跟團隊一起成長到老。
圖片來源：http://www.infoq.com/news/2013/03/anime-scrum-primer
网友评论