目前分類:Scrum (117)
- Jan 16 Sat 2021 09:38
2021/01 新竹敏捷: 車用 A-SPICE認證到Scrum
- Nov 20 Fri 2020 08:15
Scrum Guide 2020 - Goal
- Nov 19 Thu 2020 11:12
Scrum Guide 2020 - Scrum 的定義
Scrum Guide 2020 昨天(11/18) 剛出爐, 讓我眼睛一亮的部分, 是他對於 Scrum 的定義. 讓我們來看看 2017 和 2020 版本有什麼不同:

Scrum Guide 2017 版本
- Nov 19 Thu 2020 09:09
Scrum Guide 2020 - Scrum Team 的轉變
- Oct 10 Sat 2020 21:55
[敏捷小品] 利用 Google Doc 進行回顧的感想
- Aug 19 Wed 2020 21:28
[敏捷小品] 如何加速 sprint planning 中的估算
Sprint planning 會議會拖很久, 其中一個原因, 是決定這個 sprint 可以完成多少個 story.
這件事情之所以會慢, 是因為要工程師估時程. 他需要了解需求是什麼, 可能要拆解工作, 要想想可能會有多少插單進來, 或者他有多少把握做完等等, 要考慮的東西可能非常多, 因此, 他不能不慎重, 不能不多想想.
但是每次都這樣搞, 時間能不拖久嗎?
- Aug 04 Tue 2020 20:58
[敏捷小品] Scrum 其實沒有 XP 不行
當年 Jeff Sutherland 那一開始 Scrum 是有實施 XP 的實務。但是 Ken Schwaber 說服了他,把工程實踐從 Scrum 中移除,以保持整個模型的單純,讓團隊自己去負責技術實務的部分。或許,這可以幫助 Scrum 傳播的很快。但是,缺點是許多團隊因此而受難。因為缺乏技術實務,而導致無法建立可持續的敏捷開發。

所以, 請記得上完 Scrum 課程之後, 記得找 91 來補上 工程實踐. XD
- Aug 03 Mon 2020 21:53
[敏捷小品] Sprint 規劃會議太久怎麼辦?
很多人會抱怨 Scrum 的 sprint planning 太久, 一個不小心都要花上半天時間. 主要他們在釐清需求, 以及安排任務(task) 上花了很多時間. 尤其在釐清需求上, 真的可以討論很長. 個人有些建議可以幫助大家, 讓 sprint planning meeting 可以有效率點

(1) Sprint refinement meeting
在召開 sprint planning 之前, 先有些 refinement meeting, 了解一下之後 sprint 要做的功能是什麼. 這樣 sprint planning 就可專心規劃
- Jun 26 Fri 2020 22:32
[敏捷小品] Scrum 是種整合測試
Stacia Viscardi 提出一個概念: Scrum 是種整合測試. 用來檢驗團隊是否能在 sprint 結束後交付價值給客戶.

就如同大家所知的過程, 測試是會找到 bug 的. 這個測試的結果, 往往會發現很多問題, 例如: 需求不清楚, RD 開發品質不好, 測試和開發合作不順暢等等.
- Jun 24 Wed 2020 08:18
[敏捷小品] Scrum 無法解決問題?
很多人想要用 Scrum, 是他認為 run 了 Scrum 以後, Scrum 就能幫他解決問題. 是這樣子嗎?
Scrum 的發明人 Kschwaber 曾說過一句話:
Scrum is like your mother-in-law, it points out ALL your faults.

- Oct 02 Tue 2018 20:26
站立會議可診斷團隊病的重不重
- Oct 01 Mon 2018 18:15
Scrum 的師父在聊些什麼: 新新產品開發遊戲
我想很多人都知道, Scrum 想法的來源之一, 是受到了 The New New Product Development Game 這篇文章的影響. 難得有機會可以看一次這個文章, 因此想把一些重點給整理下來
一開始文章內提到, 在現今多變的世界中, 產品想要像瀑布式循序開發, 想要維持需求不變, 這已經是件苛求的事情. 為了因應這樣的變化, 應該學習橄欖球比賽一樣, 藉由不斷移位傳球, 來取得團隊的前進. 也就是說需要速度和靈活性.
- 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
如何讓回顧會議有效率
工程師們對於技術的學習, 總是能很快地接受, 並且能夠舉一反三. 但是對於人之間的相處, 反應總是慢半拍, 並且感到怕怕. 所以回顧會議要能執行的好, 還真的不是件容易的事.

以下是一些個人小小心得, 跟大家一起分享一下: