我想很多人都知道, Scrum 想法的來源之一, 是受到了 The New New Product Development Game 這篇文章的影響. 難得有機會可以看一次這個文章, 因此想把一些重點給整理下來
一開始文章內提到, 在現今多變的世界中, 產品想要像瀑布式循序開發, 想要維持需求不變, 這已經是件苛求的事情. 為了因應這樣的變化, 應該學習橄欖球比賽一樣, 藉由不斷移位傳球, 來取得團隊的前進. 也就是說需要速度和靈活性.
目前分類：Scrum (126)
- Oct 01 Mon 2018 18:15
Scrum 的師父在聊些什麼: 新新產品開發遊戲
- May 22 Tue 2018 22:22
信任是團隊組成時常見的問題
5/21 參加了台灣敏捷協會的活動, 由 Odd-e 王晶分享有關自組織的主題, 他提到了不少團隊的模型, 也帶領大家討論和思考不少自組織的問題, 是個不錯的收穫.
在其中讓我想到最多的是一開始的遊戲, 在這個遊戲中, 有人提到了要能玩得好, 信任是一個很關鍵的因素. 因為主管的信任, 沒有再在那邊斤斤計較你做的到底是否剛好一致, 是否沒有說謊, 這樣的相信, 讓團隊樂意自己去做更多, 把它做得更好.
- May 13 Sun 2018 17:26
在 Scrum 中如何發展團隊
在實施 Scrum 時, 很多人都發現到, 難的地方不在於 process, 而是在於團隊. 如何打造自組織的團隊, 是實施 Scrum 很關鍵的要素.
那我們可以怎樣打造一個團隊? 我想這應該是很多人關心的一個議題.
Bruce Tuckman 在 1965 發表了一篇文章: Developmental Sequence in Small Groups. 描述了團隊發展會經過了哪 4 個階段: Forming, Storming, Norming, Performing. 然後在 1977 時又補了一個階段: Adjourning.
- Mar 27 Tue 2018 10:26
Scrum 團隊可以自己決定做什麼嗎?
Scrum 很強調團隊要能夠自組織, 那如何達到呢? Scrum Master 便是這件事情的主要推手, 他需要透過一些軟技能, 來幫助團隊凝聚在一起, 並且有效發揮戰力,
那何謂自組織團隊呢? 大多數人說就是團隊自己會決定要做什麼, 是一個自走砲的單位. 但是這句話並不完全正確, 如果團隊想要走的方向, 和 Product Owner 不同, 和公司方向不一樣, 那這樣也是不行的.
Scrum 團隊應該是自己組織自己, 讓自己可以達到 sprint 目標, 完成 sprint backlog 內的任務, 交付出對客戶有價值的功能. 為了完成這樣的目標, 團隊自己討論誰要做什麼, 如何互相幫忙, 要學哪些新東西, 哪個要先去做等等.
- Oct 30 Mon 2017 15:20
站立會議是深度工作力的表現, 不是來報流水帳
在深度工作力一書中, 提到深度工作才能讓你的產出有價值. 但是一個人每天認知能力是固定的, 因此如何消減淺薄工作變得很重要. 而 Scrum 的每日站立會議, 正是幫助你專注深度工作的好幫手.
深度工作力的作者在Rule 4 排除淺薄事務這個章節中, 提到一個策略: 安排工作日的每一分鐘. 他認為在每天一開始時, 需要處理以下事情:
- Oct 25 Wed 2017 17:14
亂亂彈: 產品代辦清單梳理會議篇
產品代辦清單梳理會議 (Product Backlog Refinement Meeting) 這是一個很饒舌的名稱, 用來釐清團隊處理的事項內容. 最近社群中不少人提到這個東西, 因此也湊熱鬧來整理一下.
- Oct 23 Mon 2017 22:26
站立會議經驗亂亂彈
很多人談到 Scrum 的站立會議時, 會覺得它是無聊, 浪費時間, 沒有幫助的一個作法.
有的人會說, 為什麼要大家每天花 15 分鐘站在那裡, 講一堆沒有意義的話. 對我來說沒有任何意義啊. 我平時就跟團隊緊密溝通, 大家的事情我早就知道. 為什麼還要做這白癡的事情呢?
- Jul 10 Mon 2017 20:01
Scrum 團隊中是否一定要有 Scrum Master?
有位網友在 Facebook 問到, Scrum 團隊中是否一定要有 Scrum Master? 他在 FB 的 po 文如下
一開始因為上班很忙, 並沒有太多時間想這個問題, 只是很衝忙地找了 Mike Cohn 的文章 po 了上去. 那篇文章的留言其實還蠻精彩的, 很多人給了不少意見.
- Nov 02 Mon 2015 22:14
如何讓回顧會議有效率
工程師們對於技術的學習, 總是能很快地接受, 並且能夠舉一反三. 但是對於人之間的相處, 反應總是慢半拍, 並且感到怕怕. 所以回顧會議要能執行的好, 還真的不是件容易的事.
以下是一些個人小小心得, 跟大家一起分享一下:
- Sep 20 Sun 2015 20:50
Scrum 對產品負責人還不夠
在 Scrum 的開發流程中, 提到了三個角色: 產品負責人(Product Owner), Scrum Master 和團隊. 在很多文章中, 大多會描述後面兩者要做什麼, 但是對於產品負責人的部分, 卻是介紹的不是很多, 因此很多人不是很清楚他要做什麼.
一般來說, 大家比較熟悉的部分, 就是產品負責人需要撰寫產品需求, 並且對之排出優先順序. 可是就這麼簡單嗎? 事實上, 這樣是不夠的.
- Jun 26 Fri 2015 08:29
好故事更有說服力 - 從故事中學習 Scrum
網路上有人提到, 知名導演和編劇 Andrew Stanton 認為, 我們喜歡聽故事, 是因為我們想肯定自己生命的意義, 而故事讓我們重新確認自己是個什麼樣的人.
我們可以藉由聽別人的故事, 肯定別人生命的意義. 再藉由肯定別人的意義, 來肯定自己的意義. 所以故事就會變成了一座橋梁, 將人與人之間連結起來, 讓所有人成為一個由故事和理念組成的共同體.
- Jun 10 Wed 2015 23:02
Scrum Master 該做些什麼
Scrum Master 強調要僕人式領導. 也就是說, 他不一定具備正式領導職權, 但具有激勵合作, 信任, 傾聽, 授權和倫理等特徵.
Scrum Master 不該強迫團隊去做一些事情. 即使 Scrum 要求該那樣做.
- May 10 Sun 2015 21:50
如何進行 sprint 規劃會議
Scrum 開發流程中, 第一道關卡就是要進行 sprint planning meeting. 在這個會議中, 你需要找出要做哪些故事, 並且將這個故事拆解成 task.
那要怎麼進行呢? 這裡有篇文章介紹了他們如何進行 sprint planning meeting, 大家可以參考一下.
- May 05 Tue 2015 20:45
Scrum 就是一副晚娘臉
Scrum 藉由頻繁交付, 可以讓你的缺點即早曝露, 因此你可以及早修正.
因此, 有人說, Scrum 是一面鏡子, 他會把你的行為, 一舉一動, 呈現出來給大家看, 所以你才知道你哪裡有問題.
- May 04 Mon 2015 21:59
產品負責人在敏捷開發的該注意的事情
之前看了Henrik Kniberg 的Agile Product Ownership in a Nutshell 的 video (https://www.youtube.com/watch?v=502ILHjX9EE ), 外加 Daniel Teng 的教誨, 對於 Agile/Scrum 有更深一層的感觸. 以下是整理出來產品負責人 (Product owner) 應該注意的事情:
1. 知道為什麼比知道要做什麼重要
知道客戶為什麼要, 或者他遭遇到什麼問題, 會比只是知道要做什麼功能還重要. 所以你需要花時間去瞭解客戶, 通常你會利用 design thinking, empathy, user journey map 等技巧, 瞭解客戶背後的問題.
- Apr 29 Wed 2015 23:41
Scrum 能幫你什麼忙?
在 Amazon 中, 針對 Scrum: The Art of doing Twice the work in half the time 一書, Bas Vodde 對它寫了一些評論:
在裡面有幾句話寫得非常好, 深深地打動我:
- Apr 13 Mon 2015 14:53
產品負責人的檢查清單
這裏有一份產品負責人 (Product Owner) 的檢查清單. 可以讓大家參考需要會什麼東西:
1. 啟動一個新的產品或是史詩級的故事
a. 和團隊, 利害關係人, 和顧客一起建立願景
- Mar 30 Mon 2015 20:52
[Agile 新知介紹] Niko Niko 日曆
在敏捷團隊中, 我們會想用視覺化的方式, 來將一些資訊呈現出來, 好讓大家可以很清楚知道專案目前的狀態.
常見的道具, 像是 burn down chart 或者 task board, 就是用來顯示目前專案的進度, 以及工作處理的狀況.
可是除了專案的狀態可以視覺化外, 還有人想出了想把成員的心情也給視覺化. 它叫做 Niko Niko calendar.
- Mar 29 Sun 2015 21:19
產品需求清單的特色
Scrum 中有一個東西叫做產品需求清單 (product backlog), 大家可能不太清楚, 怎樣的 product backlog 內容才是合宜.
Roman Pichler 和 Mike Cohn 認為一個好的產品需求清單 (product backlog), 應該具備以下特性:
- Mar 25 Wed 2015 22:23
何謂需求準備就緒?
在實施 Scrum 時, 我們會利用 definition of done, 來定義什麼叫做一個功能做完. 這可以避免大家對於做完的標準有不同解釋, 並且也讓大家在評估時, 會把該做的事情都考慮進去.
可是, 有時候問題不是只有出在功能做完沒有共識, 有時候問題是出在這個功能是否已經準備就緒. 如果這個功能沒有被適當的規劃, 而工程師卻開始去實作它, 那將會是一場災難. 因為你可能會做到沒有價值的功能, 或者是花很多時間來釐清需求內容.
為了避免這樣的問題發生, scrum 裏就提出了 defintion of ready 這個觀念, 希望在開發這個功能前, 就能確保這個功能是已經準備就緒的.
