【有些事你不熱愛它，還是可以收穫滿滿 - Scrum到底講什麼？】
今天考過了Scrum Master的證照！坦白說，我一直都沒有想過要去考證照，因為我是一個熱愛挑戰、有時喜歡破壞規則的人，總覺得這種規則很多的東西不適合我。但剛好 HowAgile 請我給他們的課程一些反饋、天下文化 請我做 #SCRUM敏捷實戰手冊 書評，大人學、MasterTalks 請我開產品管理、專案管理的課程，「是時候好好研究一下我沒有特別熱愛的事！」我想。
雖然面試過上百Scrum Master(敏捷導師)、陸續有十多個敏捷導師在我團隊上，也用敏捷開發十多年，但我其實沒有考過證照，也不知道竟然還有手冊！
抱著踢館的心態，開始了證照課程，發現自己用敏捷開發就像是騎腳踏車，會騎（用敏捷十年）、也在國家隊裡（臉書），但其實不知道原理，了解原理以後，感覺事情都串連起來的感覺！
幾個簡單的摘要給大家，不過切記，重點是團隊自動自發、有自主權的精神和背後的道理，倒不是這些規則喔！
【團隊】
📌 Product Owner管Product Backlog，負責讓Development Team做的事發揮最大的價值
📌 Scrum Master提倡、觀察、指導、協助團隊用Scrum
📌 Development Team決定Sprint Backlog，負責達成Sprint Goal、每個Sprint產出可以使用、上線的產品「Done Increment」，所有需要完成Backlog都在Development Team上，可能不只有工程師
【Sprint】不超過四週，矽谷軟體公司通常是兩週
【會議】
📌 Sprint Planning：決定Sprint要做什麼、Sprint Goal，一月不超過8小時。在業界通常分為「Backlog Grooming」讓團隊了解要做什麼、「Sprint Planning」決定Sprint 要做什麼。
📌 Daily Scrum：在業界常被叫做「Daily Standup每日站會」，固定15分鐘，只有Development Team參加。
Sprint Review：在業界常被叫做「Demo」，每月不超過4小時。不只是「看喔！我做好了！」還有評估調整剩下的東西。
📌 Sprint Retro：檢討會，每月不超過3小時。不只是檢討，還有選出一樣改進下個Sprint執行。
雖然我覺得Scrum Guild有些過於理想化，業界通常Product Owner也不是那個最了解產品時程的人（是Scrum Master），但整體來說，還是一個非常棒、矽谷每家公司都用（類似）的framework。
還有很多心得啦！下次再細講。
👉 聽 矽谷資深女工程師 、 NATEA北美台灣工程師協會 工程師怎麼用敏捷，今天台灣時間11am、美西晚上8點 https://www.facebook.com/events/3495823580475824
👉 Scrum書 https://www.books.com.tw/products/0010856655
👉 考scrum證照 HowAgile
👉 免費Scrum 線上測驗 https://www.scrum.org/open-assessments/scrum-open
👉 免費Scrum Guide https://www.scrumguides.org/
👉 上非Scrum專案管理實戰課 https://shop.darencademy.com/product/view/id/1
scrum master心得 在 [心得] SCRUM：用一半的時間，做兩倍的事- 看板book 的推薦與評價
書名： SCRUM：用一半的時間，做兩倍的事
推薦指數：★★★★☆
網誌： https://bit.ly/3fUJ7DI
購買連結： https://bit.ly/3vun2Tp
今天介紹的這本書是要介紹一個近年很流行的工作方法
過去我們會把一個專案拆成好幾個所需完成的工作
並詳細的說明每個工作會需要花費多少時間
但是大家或許會注意到
以往的方法所預估的時間差異往往過大
你可能預估這件事情完成只需兩小時
但實際完成卻花了二十小時或是二十分鐘
而過去的方法之所以失敗的原因就是
事情發展往往超乎想像
而書中的這套方法：Scrum
則把不確定性和創造性都納入考量
並不斷地滾動式修正
讓專案執行的速度越來越快且達成需求
那怎麼做呢？
首先，必須規劃出「衝刺」的期間
在書中一開始的例子
是以兩個禮拜作為一個循環
每個循環就是一次衝刺
在循環一開始的時候
團隊要開會決定在未來兩個星期中
他們能完成多少事情
每次衝刺結束後
團隊還要再開一次會
展現出大家在這一次循環當中完成甚麼工作
檢視有多少個項目已經被完成？
是否有列出太多工作沒有完成或是相反的狀況？
在這部分最重要的事情是「對自己的速度有基本的認知」
同時也需要提出問題給成員
「昨天你做了甚麼事情協助團隊完成本階段衝刺」
「今天你準備做甚麼事情來協助團隊完成本階段衝刺」
「有甚麼阻礙團隊前進的因素」
在專案管理中，有三個因素會造成時間的浪費
第一個是多工環境的切換
常常大家可能手上不只一件案子
然而本書建議大家一次只做一件事情
千萬不要A做一點就做B
B做一點就做C
人腦在切換環境的過程中需要一點時間適應
在過去的研究當中
假設你有五個專案在同時執行
那實際上會有75%的時間被浪費掉
第二個是事情做一半等於沒有完成
如果沒辦法做出一個已完成的產品
讓使用者可以使用的產品
那這件事情等於沒有價值
也相當於花費了時間與心力卻沒有任何成果
那這輪衝刺就浪費掉了
第三個是第一次就把事情做對
有間軟體公司曾經做過一個紀錄
紀錄軟體開發人員發現錯誤的當下就把程式更正和事後再回來修改程式
兩者所花費的時間的差異
後來發現如果在當下就花一秒把錯誤修正
可以預防事後花24秒修改程式
這樣的浪費是非常巨大的
而這也是由於人體的生理結構所限制
當你在做某一個專案的時候
腦中會有該專案的詳細架構與流程
但是當你轉換了幾個專案
事後再來回想
大腦需要花費更長的時間來重新組織進入狀況
最後本書有個概念我認為很值得一提
百分之八十的價值其實是來自於百分之二十的產品
但作者建議最好在有一點小功能就趕快拿給使用者試用得到回饋
這個概念稱為「最小可行產品」
如果是一台相機，可以設計一個能照相但還不能對焦的相機
你可能會聽到
「相機的機身很難拿」「快門鍵設計在詭異的地方」
這些評論都可以讓你在繼續設計以前先修改方向
得到更多的使用者滿意度
這本書在工作上也啟發了我很多
其實也如同先前介紹過的許多書一般
提醒你專注在適合的任務，提升工作效率
以免白白浪費了許多時間，卻十分低生產力
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.136.172.91 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/book/M.1622196427.A.BFA.html
... <看更多>