目前分類：Scrum (126)
- Sep 29 Tue 2009 09:43
敏捷開發(Agile Development)實戰經驗分享會
- Sep 28 Mon 2009 13:20
漸進式的Scrum of Scrums
漸進式的Scrum of Scrums
Monday, May 4, 2009
Three stages of the Daily Scrum
http://agiletips.blogspot.com/2009/05/three-stages-of-daily-scrum.html
作者在一個很大的agile 團隊, 大約有180人, 分成12個團隊. 他們會進行2週的iteration, daily scrums以及iteration的retrospective會議.
在這裡作者要介紹他如何做scrum of scrums會議. 首先, 他提到一開始團隊並沒有這麼大, 人數也是由少量變成多量, 因此它分成三個階段的演進
- Sep 27 Sun 2009 20:27
Release planning 和Sprint Planning的比較
Release planning 和Sprint Planning的比較
Iteration Planning
http://www.rallydev.com/learn_agile/agile_planning/iteration_planning
Pusblished by Scaling Software Agility
這兩個planning是大家容易搞混的, 這裡有份比較可以參考看看
- Sep 25 Fri 2009 13:39
一些進行scrum of scrums會議的建議 (2)
一些進行scrum of scrums會議的建議 (2)
Advice on Conducting the Scrum of Scrums Meeting
http://www.mountaingoatsoftware.com/articles/35-advice-on-conducting-the-scrum-of-scrums-meeting
May 2007
Posted by Mike Cohn
- Sep 24 Thu 2009 09:39
一些進行scrum of scrums會議的建議 (1)
一些進行scrum of scrums會議的建議 (1)
Advice on Conducting the Scrum of Scrums Meeting
http://www.mountaingoatsoftware.com/articles/35-advice-on-conducting-the-scrum-of-scrums-meeting
May 2007
Posted by Mike Cohn
Scrum of Scrums會議是一個非常重要的技巧, 讓大型的project teams用來進行scaling scrum. 這個會議允許切割團隊以用來討論他們的工作, 著重於integration和overlap的問題.
- Sep 21 Mon 2009 09:26
Scrum Tuning: Lessons Learned at Google
Scrum Tuning: Lessons Learned at Google
Scaling Scrum & Distributed Teams – Scrum Tuning: Lessons Learned at Google
http://ti-agile.blogspot.com/2009/09/scaling-scrum-distributed-teams-scrum.html
septembre 01, 2009
Scaling Scrum & Distributed Teams – Scrum Tuning: Lessons Learned at Google
http://ti-agile.blogspot.com/2009/09/scaling-scrum-distributed-teams-scrum.html
septembre 01, 2009
- Sep 11 Fri 2009 10:33
ScrumButs CD
ScrumButs CD
Scrum的創始人之ㄧKen Schwaber, 出了張CD來談ScrumButs所帶來的問題, 有興趣的人可以去參考
ScrumButs: The Dangers of Customizing Scrum (Audio CD)
by Ken Schwaber (Author), Kevin Aguanno (Author)
http://www.amazon.com/ScrumButs-Dangers-Customizing-Ken-Schwaber/dp/155489042X/ref=sr_1_1?ie=UTF8&s=books&qid=1252633798&sr=8-1
註:
- Sep 01 Tue 2009 09:28
評估你ScrumBut的程度
評估你ScrumBut的程度
We’re Doing Scrum But…
http://www.dennisstevens.com/2009/03/05/were-doing-scrum-but/
March 5th, 2009
Posted by Dennis Stevens
作者是一位在IBM工作, 並且相信PMBok的人. 他經由書上或是師徒的關係, 學到有關Scrum的知識. 並且根據他懂的部份, 來執行scrum. 他覺得Agile/Scrum是以比較不負責任的方式在工作.
- Aug 28 Fri 2009 08:25
要不要採用Scrum 或者ScrumBut也不錯
要不要採用Scrum 或者ScrumBut也不錯
To Scrum or not to Scrum, or ScrumBut?
http://agile.luminis.nl/?p=162
"我們現在正在run ScrumBut.... 這意味著並沒有完全在作Scrum. 沒有完全在作Scrum可能意味著, 你可能無法得到像全面在執行Scrum時的好處" Dennis Stevens在他的blog中描述著(http://www.dennisstevens.com/2009/03/05/were-doing-scrum-but/)
通常大家會這樣解釋 也就是非黑即白. 也就是你如果沒有套用Sceum所有key principles, 你就不是Scrum. 但是事實上你作ScrumBut, 並不意味著你都不能得到Scrum所帶來的好處.
有很多組織, 他們仍然用傳統的方法在執行專, 像這樣的組織可能很難全面地採用scrum, 因此在導入時要非常小心. 可能在一開始的時候, 並不是所有的key principles都要被執行.
- Aug 19 Wed 2009 10:29
常見的技術債務
常見的技術債務
Technical debt in Scrum projects
Wednesday, July 8, 2009
http://scrumftw.blogspot.com/2009/07/technical-debt-in-scrum-projects.html
- May 30 Sat 2009 05:41
Comparing Kanban To Scrum
Comparing Kanban To Scrum
Kanban v.s. Scrum, a practical Guide
Author: Henrik Kniberg
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
上次在"Scrum 和 Kanban 的比較"(http://www.wretch.cc/blog/kojenchieh/13367441)一文中, 有簡單提到Scrum和Kanban的差別.
- May 07 Thu 2009 09:45
Scrum 和 Kanban 的比較
Scrum 和 Kanban 的比較
Kanban v.s. Scrum, a practical Guide
Author: Henrik Kniberg
Kanban最近在agile community引起相當廣泛的討論, 以前都是在社群或是blog中才會看到他們, 現在已經開始有一些書籍介紹它們. 這裡有一本"Kanban v.s. Scrum, a practical Guide", 是由Henrik Kniberg所撰寫的. 他本身也是"Scrum and XP from the Trenches"一書的作者, 目前很多有關Scrum 的圖片或是插畫, 都是出自本書. 我記得在網路上很像可以找的到PDF版. 此外此書也已經被翻成很多語言的版本, 像是德文, 俄文, 西班牙文等等.若是你想對Scrum有些認識, 作者提供了一些網站來讓你快速上手
Scrum:
- Apr 20 Mon 2009 11:04
Scrum和XP應該合在一起
Scrum和XP應該合在一起
Scrum and XP fit together
http://blog.crisp.se/henrikkniberg/2007/10/13/1192249140000.html
October 13, 2007
Posted by Henrik Kniberg
- Apr 01 Wed 2009 10:59
如何利用白板來做檢查
如何利用白板來做檢查
Kanban checklists
http://blog.crisp.se/mattiasskarin/2009/02/04/1233754800000.html
04, Feb, 2009
Posted by Mattias Skarin
Publishd in Mattias Skarin's blog
- Mar 30 Mon 2009 12:50
Burndown Chart的好處和用途
Burndown Chart的好處和用途
Questions About Burndown Chart
http://digday.blogspot.com/2009/02/questions-about-burndown-chart.html
February 21, 2009
Posted by Jimmy Zhao
Published in Dig Knowledge Everyday
- Mar 29 Sun 2009 17:19
測試你有多Scrum?
測試你有多Scrum?
Comfortably Scrum: How Scrum Are You?
http://tommynorman.blogspot.com/2009/01/comfortably-scrum-how-scrum-are-you.html
January 26, 2009
Posted by
Published in Tommy Norman's blog
- Mar 19 Thu 2009 09:47
使用白板所帶來的好處
使用白板所帶來的好處
The Power of a Whiteboard
http://www.agile-software-development.com/2009/03/power-of-whiteboard.html
Posted by Kelly Water
Published in All About Agile
Agile的開發團隊通常使用一些low-tech, 手動的方式來追蹤他們的工作. 像是用便利貼來記載工作項目, 用手繪的burndown chart, 或是用手繪的architecture等等
你或許會很好奇, 像這樣高科技的產業, 應該有一堆現成的project management tools, 或是一些為特定目的所建造的工具可以使用, 會何會用這樣low-tech的方式呢?
作者認為白版提供很多好處, 是這些軟體工具所比不上的.
1. 白板讓大家都看得見
- When you see something in print, somehow it seems more real. I guess because it's physical.
- A large number of post-it notes on a whiteboard looks like a lot of work.
- You can show some information like: Sprint Status, Burndown Chart
2. 白板有著無限的彈性
- You can put literally anything you like on it.
- Unlike an electronic system, there are never any constraints.
3. 白板可以快速, 有效的被修改
- You could completely reoarganise a set of cards in just a few moments.
- Or sketch something important in seconds.
4. 讓你覺得有形的
- For people that like tactile, it feels good to move a card to done.
- You feel a sense of ownership when you pick up a card.
5. 它也讓你感到很新穎, 新奇的
- When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look.
- The whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.
6. 白板提供一個可以一起合作, 一起討論的地方
- It's a focal point.
- Like a campfire in days gone by. Or a fireplace in your lounge.
- Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design.
7. 在白板上, 不同團隊會呈現出不同的文化
- The team can express itself through the things it puts on its whiteboard.
- It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.
作者也提到他並不是反對使用工具, 只是他認為工具是用來輔助白板, 而不是取代它. 有些事情是白版無法做的, 像是keeping track of longer lasting information, doing calculations, searching等等.
The Power of a Whiteboard
http://www.agile-software-development.com/2009/03/power-of-whiteboard.html
Posted by Kelly Water
Published in All About Agile
Agile的開發團隊通常使用一些low-tech, 手動的方式來追蹤他們的工作. 像是用便利貼來記載工作項目, 用手繪的burndown chart, 或是用手繪的architecture等等
你或許會很好奇, 像這樣高科技的產業, 應該有一堆現成的project management tools, 或是一些為特定目的所建造的工具可以使用, 會何會用這樣low-tech的方式呢?
作者認為白版提供很多好處, 是這些軟體工具所比不上的.
1. 白板讓大家都看得見
- When you see something in print, somehow it seems more real. I guess because it's physical.
- A large number of post-it notes on a whiteboard looks like a lot of work.
- You can show some information like: Sprint Status, Burndown Chart
2. 白板有著無限的彈性
- You can put literally anything you like on it.
- Unlike an electronic system, there are never any constraints.
3. 白板可以快速, 有效的被修改
- You could completely reoarganise a set of cards in just a few moments.
- Or sketch something important in seconds.
4. 讓你覺得有形的
- For people that like tactile, it feels good to move a card to done.
- You feel a sense of ownership when you pick up a card.
5. 它也讓你感到很新穎, 新奇的
- When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look.
- The whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.
6. 白板提供一個可以一起合作, 一起討論的地方
- It's a focal point.
- Like a campfire in days gone by. Or a fireplace in your lounge.
- Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design.
7. 在白板上, 不同團隊會呈現出不同的文化
- The team can express itself through the things it puts on its whiteboard.
- It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.
作者也提到他並不是反對使用工具, 只是他認為工具是用來輔助白板, 而不是取代它. 有些事情是白版無法做的, 像是keeping track of longer lasting information, doing calculations, searching等等.
- Mar 14 Sat 2009 14:57
在開始Run Scrum時, 要注意的事情
在開始Run Scrum時, 要注意的事情
Scrum Hell!
http://www.agile-software-development.com/2008/05/scrum-hell.html
May, 2008
Posted by Kelly Water
Published in All About Agile
如果你剛開始成立一個team, 並且大多數的人沒有做過Scrum, 或是沒有接受過Scrum的training. 這時候, 你要team開始使用Scrum來開發, 你將會遇到很多問題, 並且會有大的挫折.
作者看過很多這樣的狀況, 並且每個team所遭遇的問題還不盡相同.
以下是常見的問題及狀況
- Much time is spent discussing the process and how things should be done as actually doing it
- The product backlog is confusing and disorganised
- Requirements are not clear.
- User Stories are not adequately prepared.
- Sprint Planning takes *days* instead of hours.
- No too many developers love sitting in meetings!
以下作者提供了一些小秘訣, 來幫助大家度過這樣的難關
1. 首先最重要的, 把你的backlog排出重要順序
- Here I say you should proceed no further until this step is completed, otherwise you'll regret it.
- Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm.
- Refine how you handle the process in each Sprint.
Scrum Hell!
http://www.agile-software-development.com/2008/05/scrum-hell.html
May, 2008
Posted by Kelly Water
Published in All About Agile
如果你剛開始成立一個team, 並且大多數的人沒有做過Scrum, 或是沒有接受過Scrum的training. 這時候, 你要team開始使用Scrum來開發, 你將會遇到很多問題, 並且會有大的挫折.
作者看過很多這樣的狀況, 並且每個team所遭遇的問題還不盡相同.
以下是常見的問題及狀況
- Much time is spent discussing the process and how things should be done as actually doing it
- The product backlog is confusing and disorganised
- Requirements are not clear.
- User Stories are not adequately prepared.
- Sprint Planning takes *days* instead of hours.
- No too many developers love sitting in meetings!
以下作者提供了一些小秘訣, 來幫助大家度過這樣的難關
1. 首先最重要的, 把你的backlog排出重要順序
- Here I say you should proceed no further until this step is completed, otherwise you'll regret it.
- Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm.
- Refine how you handle the process in each Sprint.
- Mar 12 Thu 2009 09:52
實施Scrum的經驗談
實施Scrum的經驗談
When is Scrum not Scrum?
http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/
February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts
作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.
1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.
2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
*Ease and accuracy of burndown
burndown on tasks rather than hours
making the whole process binary: a task is done or it is not done
*It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.
When is Scrum not Scrum?
http://agilethinking.net/blog/2007/02/21/when-is-scrum-not-scrum/
February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts
作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.
1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.
2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.
3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
*Ease and accuracy of burndown
burndown on tasks rather than hours
making the whole process binary: a task is done or it is not done
*It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.
4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.
6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.
7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.
8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.
- Mar 08 Sun 2009 08:28
XP 和Scrum的比較
XP 和Scrum的比較
eXtreme Programming Versus Scrum
http://www.agile-software-development.com/2008/04/extreme-programming-versus-scrum.html
XP 和Scrum到底那一個比較好呢? 作者聽到很多人問這樣的問題. 作者認為這兩者是很難比較的, 因為他們是不同樣的東西, 因此無法比較起.
基本上來說, 他們是根據agile manifesto和agiel principles所發展出來的, 有些地方他們是有重複(如user story, iteration/sprint, accpetance test 等等), 但是他們是不同面向的東西. 以下是作者的分析
XP
(1) XP is an agile engineering methodology.
(2) If your motivation for agile is simplification of requirements management and improved product quality, XP is for you.
(3) XP is the more likely starting point when the adoption of agile is driven by developers.
Scrum
(1) Scrum is an agile management methodology.
- Scrum and XP are entirely complementary.
(2) If your motivation for agile is wanting more visibility, better business engagement, team collaboration, a clear process for prioritisation, etc - Scrum is for you.
- If you use both(Scrum and XP), you will benefit from a more incremental, iterative approach to development.
(3) Scrum is the more likely starting point when the adoption of agile is driven by management.
所以根據作者的觀點來說, 他建議你應該兩者都採用. 但是你可以先用一個, 一個能幫你先解決目前你所遇到問題, 之後在adopt另外一個.
eXtreme Programming Versus Scrum
http://www.agile-software-development.com/2008/04/extreme-programming-versus-scrum.html
XP 和Scrum到底那一個比較好呢? 作者聽到很多人問這樣的問題. 作者認為這兩者是很難比較的, 因為他們是不同樣的東西, 因此無法比較起.
基本上來說, 他們是根據agile manifesto和agiel principles所發展出來的, 有些地方他們是有重複(如user story, iteration/sprint, accpetance test 等等), 但是他們是不同面向的東西. 以下是作者的分析
XP
(1) XP is an agile engineering methodology.
(2) If your motivation for agile is simplification of requirements management and improved product quality, XP is for you.
(3) XP is the more likely starting point when the adoption of agile is driven by developers.
Scrum
(1) Scrum is an agile management methodology.
- Scrum and XP are entirely complementary.
(2) If your motivation for agile is wanting more visibility, better business engagement, team collaboration, a clear process for prioritisation, etc - Scrum is for you.
- If you use both(Scrum and XP), you will benefit from a more incremental, iterative approach to development.
(3) Scrum is the more likely starting point when the adoption of agile is driven by management.
所以根據作者的觀點來說, 他建議你應該兩者都採用. 但是你可以先用一個, 一個能幫你先解決目前你所遇到問題, 之後在adopt另外一個.
