Agile實務(Practices)的調查
The Big Agile Practices Survey
http://www.noop.nl/2009/04/the-big-agile-practices-survey.html
這裡有一份Agile practices的調查報告. 作者認為他主要關心以下事情
1. 什麼實務對agile專案是最重要的
目前分類：Agile Concept (204)
- Jun 24 Wed 2009 09:19
Agile實務(Practices)的調查
- May 29 Fri 2009 06:21
Agile好書大集合
Agile好書大集合
Overview of Agile Project Management, Scrum etc.
1. Agile Software Development with Scrum
- Let this be the first 'Scrum' book you read!
2. Agile Project Management with Scrum
- May 09 Sat 2009 08:46
理想的iteration長度
理想的iteration長度
Ideal Iteration Length
http://www.infoq.com/news/2009/03/ideal-iteration-length
Mar 31, 2009
Posted by Vikas Hazrati
Published in InfoQ.com
- May 02 Sat 2009 21:34
在XP中經理人與程式設計師的權利
在XP中經理人與程式設計師的權利
Extreme Progamming - Installed
Author: Ron Jefries, Ann Anderson, Chet Hendrickson
Translator: 范綱志
Chapter 1 極致軟體製程
- Apr 25 Sat 2009 10:06
Agile 相關好書
Agile 相關好書
我想大家應該都知道, 前一陣子有出一本有關agile testing的好書:
Agile Testing: A Practical Guide for Testers and Agile Teams
雖然我知道它是signature series, 但是Kent Back和Martin Fowler都沒有廣告他們. 後來才發現它其實是Mike Cohn所出的signature series.
他一共有四本書, 除了agile testing外, 其他三本即將快要出版. 分別列出如下:
1. Agile Game Development with Scrum
- Apr 03 Fri 2009 09:33
目前我們仍然跟的上進度嗎?
目前我們仍然跟的上進度嗎?
Agile development - is our iteration on track?
http://blog.huddle.net/agile-development-is-our-iteration-on-track
29, Jan, 2009
Posted by Colin
Published in huddle
- Mar 28 Sat 2009 16:11
十件你所不知道有關Agile Development的事
十件你所不知道有關Agile Development的事
March 2009
Posted by Jeffery Oayne
Published in Better Software
1. 敏捷才是目標
- The debate about what development practices practices are or are not agile is moot
- Mar 20 Fri 2009 09:17
Agile軟體開發程序的缺點
Agile軟體開發程序的缺點
Disadvantages of Agile Software Development
http://www.agile-software-development.com/2007/09/disadvantages-of-agile-software.html
Posted by Kelly Water
Published in All About Agile
作者說不要懷疑他, 他是道道地地Agile的fan.
雖然Agile有很多好處, 但是他也是一定有不少缺點
所以當你在採用Agile時, 你一定要知道他當初要解決的問題是什麼, 或是為了達到什麼目的. 這樣你才可檢查這樣的東西是否適合你, 你也才知道一些trade-off.
這裡是作者列出一些, 在agile中不錯的practices, 但是它卻帶來一些問題:
1. 在開發過程要求顧客積極加入及緊密合作
- However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.
2. 在開發過程, 需求會逐漸浮現及演進
- There are two big flip sides to this principle though.
* One is the potential for scope creep, which we all know can create the risk of ever-lasting projects.
* The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver.
- This can make it harder to define a business case for the project, and harder to negotiate fixed price projects.
- Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.
3. 簡潔的需求就已經足夠了
- However this can mean less information available to new starters in the team about features and how they should work.
- It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front.
- The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible.
- And this risk is managed closely through the incremental approach to development and frequent delivery of product.
4. 測試是被整合到整個開發過程
- However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project.
- This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail.
- The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs.
- However there is an additional cost to the project to adopt continuous testing throughout.
5. 經常交付產品給客戶
- The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project.
- This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.
6. 綿密的iterations/sprints
- Finally, common feedback is that agile development is rather intense for developers.
- The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.
不知各位看倌, 你覺得這些是否也是你的問題?
Disadvantages of Agile Software Development
http://www.agile-software-development.com/2007/09/disadvantages-of-agile-software.html
Posted by Kelly Water
Published in All About Agile
作者說不要懷疑他, 他是道道地地Agile的fan.
雖然Agile有很多好處, 但是他也是一定有不少缺點
所以當你在採用Agile時, 你一定要知道他當初要解決的問題是什麼, 或是為了達到什麼目的. 這樣你才可檢查這樣的東西是否適合你, 你也才知道一些trade-off.
這裡是作者列出一些, 在agile中不錯的practices, 但是它卻帶來一些問題:
1. 在開發過程要求顧客積極加入及緊密合作
- However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.
2. 在開發過程, 需求會逐漸浮現及演進
- There are two big flip sides to this principle though.
* One is the potential for scope creep, which we all know can create the risk of ever-lasting projects.
* The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver.
- This can make it harder to define a business case for the project, and harder to negotiate fixed price projects.
- Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.
3. 簡潔的需求就已經足夠了
- However this can mean less information available to new starters in the team about features and how they should work.
- It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front.
- The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible.
- And this risk is managed closely through the incremental approach to development and frequent delivery of product.
4. 測試是被整合到整個開發過程
- However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project.
- This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail.
- The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs.
- However there is an additional cost to the project to adopt continuous testing throughout.
5. 經常交付產品給客戶
- The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project.
- This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.
6. 綿密的iterations/sprints
- Finally, common feedback is that agile development is rather intense for developers.
- The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.
不知各位看倌, 你覺得這些是否也是你的問題?
- Mar 17 Tue 2009 09:31
理想的Agile工作環境
理想的Agile工作環境
The Ideal Agile Workspace
http://blog.mountaingoatsoftware.com/the-ideal-agile-workspace
March 5th, 2009
Posted by Mike Cohn
Published in Mike Cohn's BLog
作者認為一個理想的Agile 工作環境, 需要具備以下狀況
1. 引人注目的大型圖表 (Big Visible Charts)
- Agile teams like to hang the charts on their walls.
- Charts like these provide a strong visual reminder of the current state of the project.
- What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint.
- There are some items could on the charts
* sprint burndown chart, showing the number of hours remaining as of each day of the current sprint.
* the number of passing customer acceptance tests
* the pass/fail status of tests by day
* print and release burndown charts
* number of new stories introduced to the product backlog per sprint, and more.
2. 額外回饋的機制 (Additional feedback devices)
- For example:
* A lava lamp that is turned on whenever the automated build is broken.
* Use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server.
* Ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires.
- Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.
3. 每個人都在同一工作場所 (Everyone on your team)
- Each person on the team should ideally be able to see each other person on the team.
- This absolutely includes the ScrumMaster and ideally includes the product owner.
- I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead.
- Still, in an ideal world the product owner would be visible to everyone in the team workspace.
4. 在這Spint中的工作清單 (The sprint backlog)
- One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible.
- The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board.
- A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story.
- Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.”
- In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.
5. 整個專案的工作清單 (The product backlog)
- One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities.
- A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible.
- This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space.
- Even better, tack the index cards with those upcoming user stories on a wall where all can see them.
- This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.
6. 至少要有一個大白板 (At least one big white board)
- Every team needs at least one big whiteboard.
- Locating this in the team’s common workspace encourages spontaneous meetings.
- One developer may start using the board to think through a problem; others may notice and offer to help.
7. 要有私人和寧靜的空間 (Someplace quiet and private)
- As important as open communication is, there are times when someone needs some peace and quiet.
- Sometimes this is for something as simple as a private phone call.
- Other times it can be to think through a particularly challenging problem without being interrupted.
8. 食物和飲料 (Food and drink)
- It’s always a good idea to have food and drink available.
- These don’t need to be fancy, and they don’t even need to be provided by the organization.
- It could buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it.
- Other teams buy a coffee machine, depending on team preferences.
- Some teams rotate bringing in snacks, both healthful and not.
9. 對外的窗戶 (A window)
- One of the nice things about an open workspace is that windows are shared.
- Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.
The Ideal Agile Workspace
http://blog.mountaingoatsoftware.com/the-ideal-agile-workspace
March 5th, 2009
Posted by Mike Cohn
Published in Mike Cohn's BLog
作者認為一個理想的Agile 工作環境, 需要具備以下狀況
1. 引人注目的大型圖表 (Big Visible Charts)
- Agile teams like to hang the charts on their walls.
- Charts like these provide a strong visual reminder of the current state of the project.
- What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint.
- There are some items could on the charts
* sprint burndown chart, showing the number of hours remaining as of each day of the current sprint.
* the number of passing customer acceptance tests
* the pass/fail status of tests by day
* print and release burndown charts
* number of new stories introduced to the product backlog per sprint, and more.
2. 額外回饋的機制 (Additional feedback devices)
- For example:
* A lava lamp that is turned on whenever the automated build is broken.
* Use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server.
* Ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires.
- Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.
3. 每個人都在同一工作場所 (Everyone on your team)
- Each person on the team should ideally be able to see each other person on the team.
- This absolutely includes the ScrumMaster and ideally includes the product owner.
- I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead.
- Still, in an ideal world the product owner would be visible to everyone in the team workspace.
4. 在這Spint中的工作清單 (The sprint backlog)
- One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible.
- The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board.
- A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story.
- Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.”
- In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.
5. 整個專案的工作清單 (The product backlog)
- One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities.
- A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible.
- This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space.
- Even better, tack the index cards with those upcoming user stories on a wall where all can see them.
- This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.
6. 至少要有一個大白板 (At least one big white board)
- Every team needs at least one big whiteboard.
- Locating this in the team’s common workspace encourages spontaneous meetings.
- One developer may start using the board to think through a problem; others may notice and offer to help.
7. 要有私人和寧靜的空間 (Someplace quiet and private)
- As important as open communication is, there are times when someone needs some peace and quiet.
- Sometimes this is for something as simple as a private phone call.
- Other times it can be to think through a particularly challenging problem without being interrupted.
8. 食物和飲料 (Food and drink)
- It’s always a good idea to have food and drink available.
- These don’t need to be fancy, and they don’t even need to be provided by the organization.
- It could buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it.
- Other teams buy a coffee machine, depending on team preferences.
- Some teams rotate bringing in snacks, both healthful and not.
9. 對外的窗戶 (A window)
- One of the nice things about an open workspace is that windows are shared.
- Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.
- Mar 11 Wed 2009 09:14
如何利用Daily Burndown Chart來追蹤進度
如何利用Daily Burndown Chart來追蹤進度
How To Implement Scrum In 10 Easy Steps - Step #8: Track Progress With A Daily Burndown Chart
http://www.agile-software-development.com/2007/11/how-to-implement-scrum-in-10-easy-steps.html
Posted by Kelly Water
Published in All About Agile
通常傳統的的開發專案, 在一開始的時候, 開啟來一切都很順利, 幾乎有80%的完成率. 可是隨著時間的演進, 事情越來越糟, 越來越多事情無法on schedule.直到最後的關頭, 你終於承認你無法達到原先的目標, 可是那時候已經為時已晚, 已經無法做什麼事情可以幫助它來改善.
在Agile的開發專案中, 有些好的principle可以早點指出這樣的問題. 雖然一開始令人看起來很不安, 但是仍然有時間可以做些事情來改善它.
像是testing, 在傳統開發流程中, 他總是在最後關頭才做, 因此在面對龐大的系統要做測試, 其品質即時程程很難控制的. 可是在Agile開發流程中, 測試的活動是伴隨著整個流程, 因此一旦某個feature完成, 通常也代表他已經經過適當的測試. 不會到最後才來確認他的品質.
因為Product Owner或是customer加入, 在整個流程的當中, 隨時可以review 產品, 以確認產品有照著需求來做.
除了這些principles外, 每天的stand-up meeting, 可以幫助你清楚知道整個專案的進度如何, 每個人會提供他自己的的處理狀況給所有team members知道
但是, 除了這樣之外, 作者認為Daily Burndown Char也是一個好的工具, 它很簡單, 但是很有用. 要怎樣來使用這個工具呢? 以下是作者覺得要注意的地方:
1. 'Estimate To Complete'
- Take all the tasks to be delivered in a particular Sprint in Scrum, i.e. your Sprint Backlog you created in step 4.
- On your Sprint Backlog, enter the estimated time to complete, which of course at the beginning of the Sprint is the same as the original estimate.
- Update the estimated time to complete (ETC) each task on a daily basis.
2. Team members需要對自己負責
- Each team member can be responsible for updating their own ETC's on a daily basis before the Scrum.
- Updating it daily - and sharing the effort amongst the team - means typically there should only be 2 or 3 items to update for each person each day.
- Therefore it should not be onerous and means team members take responsibility for their own tasks
- Be honest about what effort you believe is required to complete each task (and that's the effort needed to really complete each task), regardless of how long has been spent to date and regardless of what was estimated in the first place.
3. 清楚標示出團隊的目標
- The team's goal, quite simply, is for the team to reach zero hours to go, by the end of the Sprint duration.
4. 以視覺化圖形方式來呈現你的進度
- The beauty of this approach is that it's a numeric view of progress and can therefore be plotted visually on a graph.
- Plot the original estimates for the Sprint on one line, and the current estimates to complete on another line.
- When the actual line tracks below the original estimate line, you're on track.
- When it tracks higher, you're running behind. It really is as simple as that.
- Highly visual, instant feedback for the whole team.
5. 紀錄關鍵事件
- I've also found it useful to annotate the graph with 'speech bubbles' describing key events along the way.
- This is a useful way to record significant events so they're not forgotten by the time of the Sprint review.
- It's also useful to communicate important things to management and stakeholders instead of producing a separate status report.
6. Scrum 會指出你的問題, 但是不會解決它
- Using a burndown chart, when you spend one day on a task and discover
* a whole load of problems or
* effort you hadn't anticipated or
* estimated for, the estimate to complete jumps up,
* creating an all-too-visual indicator of the problem for all to see.
- When this happens early in a project, and/or on a large scale, believe me it's pretty scary!
- Suddenly you're not so sure about all this new-found visibility!
- It seemed like such a good idea at the time, but can you really stick *that* burndown chart on the wall?!
7. 呈現真實的狀態反應
- But you do gain one big advantage. One enormous advantage.
- You get to see where the project really is, every day, in all its techni-colour glory!
- And when you hit problems in a project, you actually see them.
- And see them when you might just have time to do something about it.
How To Implement Scrum In 10 Easy Steps - Step #8: Track Progress With A Daily Burndown Chart
http://www.agile-software-development.com/2007/11/how-to-implement-scrum-in-10-easy-steps.html
Posted by Kelly Water
Published in All About Agile
通常傳統的的開發專案, 在一開始的時候, 開啟來一切都很順利, 幾乎有80%的完成率. 可是隨著時間的演進, 事情越來越糟, 越來越多事情無法on schedule.直到最後的關頭, 你終於承認你無法達到原先的目標, 可是那時候已經為時已晚, 已經無法做什麼事情可以幫助它來改善.
在Agile的開發專案中, 有些好的principle可以早點指出這樣的問題. 雖然一開始令人看起來很不安, 但是仍然有時間可以做些事情來改善它.
像是testing, 在傳統開發流程中, 他總是在最後關頭才做, 因此在面對龐大的系統要做測試, 其品質即時程程很難控制的. 可是在Agile開發流程中, 測試的活動是伴隨著整個流程, 因此一旦某個feature完成, 通常也代表他已經經過適當的測試. 不會到最後才來確認他的品質.
因為Product Owner或是customer加入, 在整個流程的當中, 隨時可以review 產品, 以確認產品有照著需求來做.
除了這些principles外, 每天的stand-up meeting, 可以幫助你清楚知道整個專案的進度如何, 每個人會提供他自己的的處理狀況給所有team members知道
但是, 除了這樣之外, 作者認為Daily Burndown Char也是一個好的工具, 它很簡單, 但是很有用. 要怎樣來使用這個工具呢? 以下是作者覺得要注意的地方:
1. 'Estimate To Complete'
- Take all the tasks to be delivered in a particular Sprint in Scrum, i.e. your Sprint Backlog you created in step 4.
- On your Sprint Backlog, enter the estimated time to complete, which of course at the beginning of the Sprint is the same as the original estimate.
- Update the estimated time to complete (ETC) each task on a daily basis.
2. Team members需要對自己負責
- Each team member can be responsible for updating their own ETC's on a daily basis before the Scrum.
- Updating it daily - and sharing the effort amongst the team - means typically there should only be 2 or 3 items to update for each person each day.
- Therefore it should not be onerous and means team members take responsibility for their own tasks
- Be honest about what effort you believe is required to complete each task (and that's the effort needed to really complete each task), regardless of how long has been spent to date and regardless of what was estimated in the first place.
3. 清楚標示出團隊的目標
- The team's goal, quite simply, is for the team to reach zero hours to go, by the end of the Sprint duration.
4. 以視覺化圖形方式來呈現你的進度
- The beauty of this approach is that it's a numeric view of progress and can therefore be plotted visually on a graph.
- Plot the original estimates for the Sprint on one line, and the current estimates to complete on another line.
- When the actual line tracks below the original estimate line, you're on track.
- When it tracks higher, you're running behind. It really is as simple as that.
- Highly visual, instant feedback for the whole team.
5. 紀錄關鍵事件
- I've also found it useful to annotate the graph with 'speech bubbles' describing key events along the way.
- This is a useful way to record significant events so they're not forgotten by the time of the Sprint review.
- It's also useful to communicate important things to management and stakeholders instead of producing a separate status report.
6. Scrum 會指出你的問題, 但是不會解決它
- Using a burndown chart, when you spend one day on a task and discover
* a whole load of problems or
* effort you hadn't anticipated or
* estimated for, the estimate to complete jumps up,
* creating an all-too-visual indicator of the problem for all to see.
- When this happens early in a project, and/or on a large scale, believe me it's pretty scary!
- Suddenly you're not so sure about all this new-found visibility!
- It seemed like such a good idea at the time, but can you really stick *that* burndown chart on the wall?!
7. 呈現真實的狀態反應
- But you do gain one big advantage. One enormous advantage.
- You get to see where the project really is, every day, in all its techni-colour glory!
- And when you hit problems in a project, you actually see them.
- And see them when you might just have time to do something about it.
- Mar 09 Mon 2009 09:36
十大Agile Development網站
十大Agile Development網站
Top 10 Agile Development Websites
http://www.agile-software-development.com/2007/05/top-10-agile-development-websites.html
根據 Alexa的資料顯示(Web Information Company, http://www.alexa.com/), 目前大家最常去十個Agile Development 網站是:
1. Martin Fowler
Papers and articles from one of the giants in the field.
www.martinfowler.com
2. ThoughtWorks, Inc.
A commercial site for Martin Fowler's company.
www.thoughtworks.com
3. Agile Modeling
Practice-based methodology for effectively modeling and documenting software-based systems.
www.agilemodeling.com
4. Extreme Programming
A gentle introduction to eXtreme Programming (XP).
www.extremeprogramming.org
5. XProgramming
Articles, FAQs and other information on the XP methodology.
www.xprogramming.com
6. Rally Software Development
Agile development tools and consulting.
www.rallydev.com
7. JUnit
A unit testing framework for Java.
www.junit.org
8. Agile Software Development [Wikipedia]
Wikipedia's definition of agile software development.
http://en.wikipedia.org/wiki/Agile_software_development
9. Alistair Cockburn
One of the parents of the agile movement, and creator of Crystal family of lightweight methodologies.
www.alistair.cockburn.us
10. Advanced Development Methods, Inc.
Home of Scrum agile development methodology.
www.controlchaos.com
Top 10 Agile Development Websites
http://www.agile-software-development.com/2007/05/top-10-agile-development-websites.html
根據 Alexa的資料顯示(Web Information Company, http://www.alexa.com/), 目前大家最常去十個Agile Development 網站是:
1. Martin Fowler
Papers and articles from one of the giants in the field.
www.martinfowler.com
2. ThoughtWorks, Inc.
A commercial site for Martin Fowler's company.
www.thoughtworks.com
3. Agile Modeling
Practice-based methodology for effectively modeling and documenting software-based systems.
www.agilemodeling.com
4. Extreme Programming
A gentle introduction to eXtreme Programming (XP).
www.extremeprogramming.org
5. XProgramming
Articles, FAQs and other information on the XP methodology.
www.xprogramming.com
6. Rally Software Development
Agile development tools and consulting.
www.rallydev.com
7. JUnit
A unit testing framework for Java.
www.junit.org
8. Agile Software Development [Wikipedia]
Wikipedia's definition of agile software development.
http://en.wikipedia.org/wiki/Agile_software_development
9. Alistair Cockburn
One of the parents of the agile movement, and creator of Crystal family of lightweight methodologies.
www.alistair.cockburn.us
10. Advanced Development Methods, Inc.
Home of Scrum agile development methodology.
www.controlchaos.com
- Feb 28 Sat 2009 11:32
Agile Requirements Collaboration (1)
Agile Requirements Collaboration (1)
Beyond Story Cards: Agile Requirements Collaboration
http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html
James Shore是"The Art of Agile Development"一書的作者, 在agile是赫赫有名的作者. 他在2005年受邀到Software Process Improvement Network (SPIN)演講. 主題是Agile Requirements Collaboration.
在這演講中, James主要討論的是以下的主題
- what happens before you create the story cards and
- what happens after you create them
但是他並不提story本身的細節
1. 為什麼要 Collaborate?
(1) 這裡他引用"Project Management: The Criteria for Success"的內容, 讓我們知道正確需求的重要性:
Lack of user involvement traditionally has been the No. 1 reason for project failure.
Conversely, it has been the leading contributor to project success.
Even when delivered on time and on budget, a project can fail it it doesn't meet user needs or expectations.
(2) 所以他認為:
user involvement is a key success factor in software projects... in all software projects, agile or not.
(3) Agile development values collaboration because it increases your chance of success.
- 所以作者要調強的是要如何ehance collaboration,來進一步釐清需求. 而不是只有把它寫出來, 貼在牆壁上而已
2. 那stories從哪裡來呢?
(1) On an XP project, that person is usually called the "on-site customer."
- You'll also hear terms like "lead customer" and "product manager."
- I'm going to call him (or her) a "product manager" in this presentation, because it's more in line with common industry terms.
(2) The product manager needs to have a strong, clear vision of the product
- but that doesn't mean he or she is solely responsible for it.
- work with interaction designers, business analysts, real customers, marketers, users...
- has to have a strong sense of vision, to tie all the diverse threads together into a strong, usable product.
- has to know the market well and understand what it needs.
- has to have the political savvy to juggle all of the project stakeholders' demands, and he has to have the authority to make his decisions about priorities stick.
(3) 所以作者覺得XP其中一個最難的地方, 是找到好的product manager
=========================================================
觀眾所提的問題
1. Audience question: What if you don't have anyone with a vision of the product?
Ans:
(1) I haven't encountered that. What I have seen is that people sometimes aren't sure what they want.
(2) They think they know, but when they actually see it running, they realize that they wanted something else.
(3) I think the frequent iteration-by-iteration deployment of agile methods are an important way to help people understand on what they really want, because they get to see the software actually running.
(4) 這裡有作者以前的工作經驗:
- I was on a team where we were working with a customer and we were showing him the product every two weeks.
- We weren't sure that we were really delivering what he wanted.
- Every time we said, "this is really what we're going to deploy!" And he said, "sure, sure."
- And then, about four weeks from release, we said that again and he said, "wait! That's what we're going to deliver? No, no, it's all wrong."
- But it only took us one two-week iteration to change the software to what he wanted. Most of the changes were just user interface changes.
2. Audience question: I think something that's more common is to have too many people with product vision. How do you balance this?
Ans:
(1) That's the product manager's role, to balance the competing visions of all the different stakeholders. You need someone with political savvy to do that.
(2) I've tried a number of different options, such as allocating each group a portion of the iteration budget, having people justify the value of their stories, and they didn't work well.
(3) We spent too much time doing bits and pieces of too many things and never got anything completely done. Ultimately what worked best was just having a product manager make the call.
=========================================================
The "latest responsible moment"
(1) Story card hell
- Story card hell is when you have 300 story cards and you have to keep track of them all. This doesn't work.
- Story cards aren't meant to capture all of the details of your product requirements. They're only supposed to be a sentence or two. At most, a paragraph.
- 作者舉了一個例子
* You have one story card that says "make toast" and another that says "cook bread."
* Is that the same story? Or are they different requirements for completely different parts of the system?
* You can't tell, and you lose track of the overall vision because you're surrounded by trees.
(2) 發生"Story card hell"的徵兆
- A good sign that you're in story card hell is when you start hearing the question, "can we put these in a database?"
- Every customer I've ever worked with wanted to put story cards in a database. That misses the point of story cards.
- If you're worried about losing story cards, you're doing too much with them.
(3) Latest Responsible Moment
- "Latest responsible moment" is a core agile idea.
- The term comes from Lean Software Development.
- The idea is that you want to put off decisions as long as you can: to the latest responsible moment.
- But it's the latest responsible moment, not the "last possible" moment. That wouldn't be responsible.
(4) 為何要用"Latest Responsible Moment"
- The reason we do this is because putting off decisions is cheaper and results in better decisions.
- Money we spend tomorrow is cheaper than money we spend today, and between now and tomorrow, we'll learn more things about our environment and the decisions we need to make.
- Plus, things could change so much that the decision isn't relevant any more.
- If we've spent the time and effort to make the decision, that money is wasted.
- So we wait as long as we responsibly can.
Beyond Story Cards: Agile Requirements Collaboration
http://jamesshore.com/Presentations/Beyond%20Story%20Cards.html
James Shore是"The Art of Agile Development"一書的作者, 在agile是赫赫有名的作者. 他在2005年受邀到Software Process Improvement Network (SPIN)演講. 主題是Agile Requirements Collaboration.
在這演講中, James主要討論的是以下的主題
- what happens before you create the story cards and
- what happens after you create them
但是他並不提story本身的細節
1. 為什麼要 Collaborate?
(1) 這裡他引用"Project Management: The Criteria for Success"的內容, 讓我們知道正確需求的重要性:
Lack of user involvement traditionally has been the No. 1 reason for project failure.
Conversely, it has been the leading contributor to project success.
Even when delivered on time and on budget, a project can fail it it doesn't meet user needs or expectations.
(2) 所以他認為:
user involvement is a key success factor in software projects... in all software projects, agile or not.
(3) Agile development values collaboration because it increases your chance of success.
- 所以作者要調強的是要如何ehance collaboration,來進一步釐清需求. 而不是只有把它寫出來, 貼在牆壁上而已
2. 那stories從哪裡來呢?
(1) On an XP project, that person is usually called the "on-site customer."
- You'll also hear terms like "lead customer" and "product manager."
- I'm going to call him (or her) a "product manager" in this presentation, because it's more in line with common industry terms.
(2) The product manager needs to have a strong, clear vision of the product
- but that doesn't mean he or she is solely responsible for it.
- work with interaction designers, business analysts, real customers, marketers, users...
- has to have a strong sense of vision, to tie all the diverse threads together into a strong, usable product.
- has to know the market well and understand what it needs.
- has to have the political savvy to juggle all of the project stakeholders' demands, and he has to have the authority to make his decisions about priorities stick.
(3) 所以作者覺得XP其中一個最難的地方, 是找到好的product manager
=========================================================
觀眾所提的問題
1. Audience question: What if you don't have anyone with a vision of the product?
Ans:
(1) I haven't encountered that. What I have seen is that people sometimes aren't sure what they want.
(2) They think they know, but when they actually see it running, they realize that they wanted something else.
(3) I think the frequent iteration-by-iteration deployment of agile methods are an important way to help people understand on what they really want, because they get to see the software actually running.
(4) 這裡有作者以前的工作經驗:
- I was on a team where we were working with a customer and we were showing him the product every two weeks.
- We weren't sure that we were really delivering what he wanted.
- Every time we said, "this is really what we're going to deploy!" And he said, "sure, sure."
- And then, about four weeks from release, we said that again and he said, "wait! That's what we're going to deliver? No, no, it's all wrong."
- But it only took us one two-week iteration to change the software to what he wanted. Most of the changes were just user interface changes.
2. Audience question: I think something that's more common is to have too many people with product vision. How do you balance this?
Ans:
(1) That's the product manager's role, to balance the competing visions of all the different stakeholders. You need someone with political savvy to do that.
(2) I've tried a number of different options, such as allocating each group a portion of the iteration budget, having people justify the value of their stories, and they didn't work well.
(3) We spent too much time doing bits and pieces of too many things and never got anything completely done. Ultimately what worked best was just having a product manager make the call.
=========================================================
The "latest responsible moment"
(1) Story card hell
- Story card hell is when you have 300 story cards and you have to keep track of them all. This doesn't work.
- Story cards aren't meant to capture all of the details of your product requirements. They're only supposed to be a sentence or two. At most, a paragraph.
- 作者舉了一個例子
* You have one story card that says "make toast" and another that says "cook bread."
* Is that the same story? Or are they different requirements for completely different parts of the system?
* You can't tell, and you lose track of the overall vision because you're surrounded by trees.
(2) 發生"Story card hell"的徵兆
- A good sign that you're in story card hell is when you start hearing the question, "can we put these in a database?"
- Every customer I've ever worked with wanted to put story cards in a database. That misses the point of story cards.
- If you're worried about losing story cards, you're doing too much with them.
(3) Latest Responsible Moment
- "Latest responsible moment" is a core agile idea.
- The term comes from Lean Software Development.
- The idea is that you want to put off decisions as long as you can: to the latest responsible moment.
- But it's the latest responsible moment, not the "last possible" moment. That wouldn't be responsible.
(4) 為何要用"Latest Responsible Moment"
- The reason we do this is because putting off decisions is cheaper and results in better decisions.
- Money we spend tomorrow is cheaper than money we spend today, and between now and tomorrow, we'll learn more things about our environment and the decisions we need to make.
- Plus, things could change so much that the decision isn't relevant any more.
- If we've spent the time and effort to make the decision, that money is wasted.
- So we wait as long as we responsibly can.
- Feb 22 Sun 2009 10:43
Technical Debt
Technical Debt
http://www.scrumlabs.com/tag/technical-debt/
Technical Debt 是由Ward Cunningham 在1992中的一份experience report所提到的:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
之後在agile的領域中常常出現這個term, 為什麼呢? 因為在agile中有iteration, sprint等東西, 因此你就會常常聽到engineer說, 這些東西下個iteration再做, 現在已經擠不進去. 以前不是agile的時候, 這個藉口也是常用, 只是因為周期較長, 以前在中後期比較會聽到這樣的事情. 但是現在會每次的iteration都會聽到一次:
* ‘We’ll do it in the next release’ – that never comes.
* The project got delivered – along with a maintenance team.
* We did it for good business reasons.
* “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
* “To get anything released to production is a nightmare - we have to regression test the whole system”.
以下有兩篇好的文章, 在探討Technical Debt, 作者推薦大家可以參考一下:
An excellent article on Technical Debt by Kane Mar :
http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/
And another excellent article by Steve McConnell:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
作者也提到, 有一個方法可以mitigate這個問題, 那就是在幾個business focused 的sprints後, 加一個technical debt, 這樣可以幫助你之後的velocity, 還可以維持一定的水準, 不會被日積月累的負債給拖垮. 需知道當你有巨大的債務時, 即使光付利息也是會讓你喘不過氣來.
當然啦, 如果可以在每個release中減少technical debt, 那還是比排一個做refacoring 的TD sprint. 因為每天運動, 一定比假日或是有空運動, 效果要好的多, 代價也不會太多. 很多道理就是相通的.
http://www.scrumlabs.com/tag/technical-debt/
Technical Debt 是由Ward Cunningham 在1992中的一份experience report所提到的:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
之後在agile的領域中常常出現這個term, 為什麼呢? 因為在agile中有iteration, sprint等東西, 因此你就會常常聽到engineer說, 這些東西下個iteration再做, 現在已經擠不進去. 以前不是agile的時候, 這個藉口也是常用, 只是因為周期較長, 以前在中後期比較會聽到這樣的事情. 但是現在會每次的iteration都會聽到一次:
* ‘We’ll do it in the next release’ – that never comes.
* The project got delivered – along with a maintenance team.
* We did it for good business reasons.
* “The architecture - let me see - I have a single power-point somewhere with a picture on it”.
* “To get anything released to production is a nightmare - we have to regression test the whole system”.
以下有兩篇好的文章, 在探討Technical Debt, 作者推薦大家可以參考一下:
An excellent article on Technical Debt by Kane Mar :
http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/
And another excellent article by Steve McConnell:
http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
作者也提到, 有一個方法可以mitigate這個問題, 那就是在幾個business focused 的sprints後, 加一個technical debt, 這樣可以幫助你之後的velocity, 還可以維持一定的水準, 不會被日積月累的負債給拖垮. 需知道當你有巨大的債務時, 即使光付利息也是會讓你喘不過氣來.
當然啦, 如果可以在每個release中減少technical debt, 那還是比排一個做refacoring 的TD sprint. 因為每天運動, 一定比假日或是有空運動, 效果要好的多, 代價也不會太多. 很多道理就是相通的.
- Feb 12 Thu 2009 09:28
一個立見分曉的測驗來檢驗Agile化的程度
一個立見分曉的測驗來檢驗Agile化的程度
Quick Poll: A Litmus Test for Agile Development
http://www.scrum-breakfast.com/2008/10/quick-poll-litmus-test-for-agile.html
作者想要知道一個team, adopt agile的程度如何, 到底做的好不好. 因此他整理了一些簡單的Yes/No question, 希望能很快得知到底狀況如何. 他也希望大家能幫他看看是否有遺漏哪些部份. 現在就讓我們來看看
1. Source Code: Do you use source control?
2. Build: Can you build in a single step?
3. Daily Build: Do you make daily builds?
4. Bug DB: Do you have a bug database?
5. Fixing: Do you fix bugs before writing new code?
6. Sched: Do you have an up-to-date schedule?
7. Spec: Do you have a spec?
8. Quiet: Do programmers have quiet working conditions?
9. Tools: Do you use the best tools money can buy?
10. Testers: Do you have testers?
11. Intervew: Do new candidates write code during their interview?
12. Hallway: Do you do hallway usability testing?
13. Wiki: Do you use a Wiki?
14. Continuous: Do you do continuous build / test / deploy?
15. TDDev: Do your tests drive your development?
16. Pair: Do your developers pair and support each other?
17. Talk: Does everyone talk to each other, constantly?
18. Hiring: Does the team select its new members?
19. Colocated: Is the team colocated?
20. Testing: Can you test in a single step?
21. Releases: Have you delivered running, tested, usable functionality to users at least twice in the last six months?
22. Deploy: Can you deploy in a single step?
23. Integration: Do you integrate the system at least twice per week`
24. News: Can you give your boss bad news?
25. Access: Does it take less than three days from when you have a question to when an expert answers it?
26. Improvement: Did you get together within the last three months to discuss and improve your group’s working habits?
27. Retrospective: Does you team conduct a retrospective after every iteration?
28. User Stories: Do you define the product in terms of user stories?
29. Acceptence: Do you define acceptence tests before you write code?
如果我有找到作者最後用這些問題的survey結果, 再和大家分享.
Quick Poll: A Litmus Test for Agile Development
http://www.scrum-breakfast.com/2008/10/quick-poll-litmus-test-for-agile.html
作者想要知道一個team, adopt agile的程度如何, 到底做的好不好. 因此他整理了一些簡單的Yes/No question, 希望能很快得知到底狀況如何. 他也希望大家能幫他看看是否有遺漏哪些部份. 現在就讓我們來看看
1. Source Code: Do you use source control?
2. Build: Can you build in a single step?
3. Daily Build: Do you make daily builds?
4. Bug DB: Do you have a bug database?
5. Fixing: Do you fix bugs before writing new code?
6. Sched: Do you have an up-to-date schedule?
7. Spec: Do you have a spec?
8. Quiet: Do programmers have quiet working conditions?
9. Tools: Do you use the best tools money can buy?
10. Testers: Do you have testers?
11. Intervew: Do new candidates write code during their interview?
12. Hallway: Do you do hallway usability testing?
13. Wiki: Do you use a Wiki?
14. Continuous: Do you do continuous build / test / deploy?
15. TDDev: Do your tests drive your development?
16. Pair: Do your developers pair and support each other?
17. Talk: Does everyone talk to each other, constantly?
18. Hiring: Does the team select its new members?
19. Colocated: Is the team colocated?
20. Testing: Can you test in a single step?
21. Releases: Have you delivered running, tested, usable functionality to users at least twice in the last six months?
22. Deploy: Can you deploy in a single step?
23. Integration: Do you integrate the system at least twice per week`
24. News: Can you give your boss bad news?
25. Access: Does it take less than three days from when you have a question to when an expert answers it?
26. Improvement: Did you get together within the last three months to discuss and improve your group’s working habits?
27. Retrospective: Does you team conduct a retrospective after every iteration?
28. User Stories: Do you define the product in terms of user stories?
29. Acceptence: Do you define acceptence tests before you write code?
如果我有找到作者最後用這些問題的survey結果, 再和大家分享.
- Feb 11 Wed 2009 09:25
在Run Agile時, 如何知道我們一切都上軌道?
在Run Agile時, 如何知道我們一切都上軌道?
Agile development - is our iteration on track?
http://blog.huddle.net/agile-development-is-our-iteration-on-track
作者認為如果只由story point, 其實很難知道team是否一切事情都on track.
過去或許有人列出了一系列的建議的解決方案, 來讓我們知道是否進度是否上軌道, 但是作者一一解釋, 那些方法並不能完全解決我們的需求
方案 1: “使用 iteration / sprint burndown chart.”
- Our signature story point burndown chart tends to look a bit like this
- So we often don’t know if we are going to make it until the last couple of days of the iteration.
方案 2: 所以, 那你們為什麼不以小時(hour)的方式, 來記錄和追蹤task的進度; 以及用小時計的burndown chart來顯示進度?
- We did this for a while.
- It was moderately useful when the team was very new to the process and struggling to deliver.
- But as the team became more experienced and more efficient, the overhead seemed less and less worthwhile.
- As the value decreased, the team’s motivation to supply the data also decreased, so the quality of the data dropped. So, we stopped.
方案 3: “這是Agile的基本常識, 你的daily stand-up meeting會告訴你是否你的team是on track"
- In traditional format stand-ups will not necessarily tell you if you are on schedule to meet your iteration commitment.
- It’s perfectly possible to describe what you did yesterday, list your commitment for the day and report on any blocks, day after day, accurately and honestly, yet still not provide enough information to ascertain whether iteration delivery is on track.
- This is because, typically, developers work on one story at a time, whereas the overall iteration scope consists of a series of stories with resource dependencies, and occasionally, technical dependencies.
- For example, if Bob gets less done than he’d planned in the first couple of days of the iteration, Anto gets ahead and Jenna is bang on track, but Jenna and Bob have a joint story further down the priority list that is dependent on Anto’s story, are we on track to get it done? Who knows!
方案 4: 把你的iteration計畫的更好, 指出每個story何時開始, 何時結束, 誰負責, 有沒有對它建立mini 的project plan
- Please! Remind me, which do we value more – a) following a plan, or b) responding to change?
方案 5: “Well then, if you work on your stories in priority order, and if you work efficiently and sensibly removing blocks as they arise, what does it matter anyway? If unforeseen issues materialise, the lowest priority stories won’t be delivered, and so be it!”
(1) Working on stories in strict priority order is not always practical.
- We do have some skill specialisms within the teams.
- For example, if the top priority stories are all backend development heavy, our UI developers will pick up some lower priority items.
(2) This is a bit of a guilty confession, I just like to know what we are going to deliver before we get to the end of the iteration!
作者知道大家都很期待, 是否他會提出什麼解決方案. 他說很可惜地, 他自己只解決一小部份, 以下是他的作法:
1. We keep an eye on the points delivered day to day and try to spot trends that indicate the iteration is deviating from the normal pattern.
2. If an individual developer wants to log hours against his tasks to help determine if he is on track to meet his personal commitment, he can.
3. We’ve amended our stand-up format a little. As well as emphasising “tasks I committed to but did not deliver yesterday” we also quickly review the overall status of each story at the end, and review priorities as needed.
4. The developers themselves decided to log a simple “target end date” for each story within the iteration, to help retain focus.
5. We do try to work on stories in priority order as far as possible, and use the stand-ups to divert effort from lower to higher priority stories where possible.
Agile development - is our iteration on track?
http://blog.huddle.net/agile-development-is-our-iteration-on-track
作者認為如果只由story point, 其實很難知道team是否一切事情都on track.
過去或許有人列出了一系列的建議的解決方案, 來讓我們知道是否進度是否上軌道, 但是作者一一解釋, 那些方法並不能完全解決我們的需求
方案 1: “使用 iteration / sprint burndown chart.”
- Our signature story point burndown chart tends to look a bit like this
- So we often don’t know if we are going to make it until the last couple of days of the iteration.
方案 2: 所以, 那你們為什麼不以小時(hour)的方式, 來記錄和追蹤task的進度; 以及用小時計的burndown chart來顯示進度?
- We did this for a while.
- It was moderately useful when the team was very new to the process and struggling to deliver.
- But as the team became more experienced and more efficient, the overhead seemed less and less worthwhile.
- As the value decreased, the team’s motivation to supply the data also decreased, so the quality of the data dropped. So, we stopped.
方案 3: “這是Agile的基本常識, 你的daily stand-up meeting會告訴你是否你的team是on track"
- In traditional format stand-ups will not necessarily tell you if you are on schedule to meet your iteration commitment.
- It’s perfectly possible to describe what you did yesterday, list your commitment for the day and report on any blocks, day after day, accurately and honestly, yet still not provide enough information to ascertain whether iteration delivery is on track.
- This is because, typically, developers work on one story at a time, whereas the overall iteration scope consists of a series of stories with resource dependencies, and occasionally, technical dependencies.
- For example, if Bob gets less done than he’d planned in the first couple of days of the iteration, Anto gets ahead and Jenna is bang on track, but Jenna and Bob have a joint story further down the priority list that is dependent on Anto’s story, are we on track to get it done? Who knows!
方案 4: 把你的iteration計畫的更好, 指出每個story何時開始, 何時結束, 誰負責, 有沒有對它建立mini 的project plan
- Please! Remind me, which do we value more – a) following a plan, or b) responding to change?
方案 5: “Well then, if you work on your stories in priority order, and if you work efficiently and sensibly removing blocks as they arise, what does it matter anyway? If unforeseen issues materialise, the lowest priority stories won’t be delivered, and so be it!”
(1) Working on stories in strict priority order is not always practical.
- We do have some skill specialisms within the teams.
- For example, if the top priority stories are all backend development heavy, our UI developers will pick up some lower priority items.
(2) This is a bit of a guilty confession, I just like to know what we are going to deliver before we get to the end of the iteration!
作者知道大家都很期待, 是否他會提出什麼解決方案. 他說很可惜地, 他自己只解決一小部份, 以下是他的作法:
1. We keep an eye on the points delivered day to day and try to spot trends that indicate the iteration is deviating from the normal pattern.
2. If an individual developer wants to log hours against his tasks to help determine if he is on track to meet his personal commitment, he can.
3. We’ve amended our stand-up format a little. As well as emphasising “tasks I committed to but did not deliver yesterday” we also quickly review the overall status of each story at the end, and review priorities as needed.
4. The developers themselves decided to log a simple “target end date” for each story within the iteration, to help retain focus.
5. We do try to work on stories in priority order as far as possible, and use the stand-ups to divert effort from lower to higher priority stories where possible.
- Feb 10 Tue 2009 09:39
一個sprint 或是iteration 應該要有多長?
一個sprint 或是iteration 應該要有多長?
How Long should be a Sprint or Iteration ?
http://shishirtech.wordpress.com/2009/01/15/how-long-should-be-a-sprint-or-iteration/
一個iteration要有多長了, 通常是一開始要run agile的人, 所要痛苦掙扎的問題之一. 太短怕做不完, 太長又覺得feedback太慢. 以下是作者認為要考慮的因素:
1. 管理上的overhead
- Each iteration needs a planning meeting/ game to kick start the iteration, closing/ review meeting, and a retrospective at the end of iteration.
- Although one can say that the size of these meetings would depend on the length of sprint, so as long as these meetings comprise say just 10% of overall time available for a sprint/ iteration, it should be fine.
- If meetings are taking longer, then there are generally Process Smells - Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
2. 回饋和彈性
- Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction - more chances of canceling the sprint and more chances of things being obsolete.
3. 多好的銷售團隊
- If the marketing team is good, then the product owner will break the stories or tasks small enough to keep sprint/ iteration length small.
- Product Owner would know the worth and priority for each story or task and help the team pick up most important stuff - minimizing stuff thats not needed - helping the team become Agile.
4.團隊能移動多快
- This is generally the most important factor in deciding a sprint length.
- Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves.
通常來說, agile都會要求較短的iteration. 那較短的iteration有什麼好處呢? 以下是作者認為的原因:
1. Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
2. Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
3. Shorter sprints or iterations force continuous evaluation regularly and quickly.
4. Shorter sprints or iterations also allows the team to establish an empirical velocity very quickly.
目前我們team是採用2 weeks當做一個iteration, 因為剛開始run, 現在還困難重重, 之後有結果再跟大家報告
How Long should be a Sprint or Iteration ?
http://shishirtech.wordpress.com/2009/01/15/how-long-should-be-a-sprint-or-iteration/
一個iteration要有多長了, 通常是一開始要run agile的人, 所要痛苦掙扎的問題之一. 太短怕做不完, 太長又覺得feedback太慢. 以下是作者認為要考慮的因素:
1. 管理上的overhead
- Each iteration needs a planning meeting/ game to kick start the iteration, closing/ review meeting, and a retrospective at the end of iteration.
- Although one can say that the size of these meetings would depend on the length of sprint, so as long as these meetings comprise say just 10% of overall time available for a sprint/ iteration, it should be fine.
- If meetings are taking longer, then there are generally Process Smells - Product Owners who have not done their homework correctly or have not had the chance to review the deliverables properly.
2. 回饋和彈性
- Shorter the duration of the sprint/ iteration, earlier the feedback and correction and more flexibility, longer the duration of the sprint/ iteration, longer the correction - more chances of canceling the sprint and more chances of things being obsolete.
3. 多好的銷售團隊
- If the marketing team is good, then the product owner will break the stories or tasks small enough to keep sprint/ iteration length small.
- Product Owner would know the worth and priority for each story or task and help the team pick up most important stuff - minimizing stuff thats not needed - helping the team become Agile.
4.團隊能移動多快
- This is generally the most important factor in deciding a sprint length.
- Assuming the team has a good marketing leadership, one reason the team does not commit to a smaller iteration is lack of confidence in themselves.
通常來說, agile都會要求較短的iteration. 那較短的iteration有什麼好處呢? 以下是作者認為的原因:
1. Short sprints make certain bad habits impossible to get away with and certain good habits more attractive to learn.
2. Shorter sprints or iterations are difficult for product management team but also most desirable as they can make changes quickly.
3. Shorter sprints or iterations force continuous evaluation regularly and quickly.
4. Shorter sprints or iterations also allows the team to establish an empirical velocity very quickly.
目前我們team是採用2 weeks當做一個iteration, 因為剛開始run, 現在還困難重重, 之後有結果再跟大家報告
- Feb 02 Mon 2009 09:34
Iteration Demo失敗的原因
Iteration Demo失敗的原因
It's a Trap!
http://jamesshore.com/Blog/Its-a-Trap.html
在Adopt Agile時, 作者認為最常見的一個問題, 就是要達到iteration commiment會有問題. 換言之, team通常在iteration在結束時, stories大部分只完工一半. 因此在iteration demo時通常都是很令人失望.
你可能會覺得, 造成這個結果的原因, 可能很複雜並且不大相同. 等等!! 事實上... 這是一派胡言, 我必須老實承認, 而不是很鄉愿地欺騙你. 當你選擇了只挑容易做的practices, 這件事都註定要發生了. 也就是說 這條道路看起來容易和簡單，但是它充滿了陷阱.
Trap #1: 日益增加的QA負擔 (The Ever-Increasing QA Burden)
就作者所知, 許多agile team大多是adopt iteration, dailystand-up meeting和planning game, 但是他們並沒採用其他agile 的 engineering (像是refacotring, TDD, pair programming等等), 所以他們的iteration看起來只像是mini版的waterfalls. 也就是RD做design 和coding, 之後的結果由QA去做測試.
在日益增加的測試負擔中, QA最終只會走向死亡. 即使QA有建立automated的測試, 但是這些測試往往是整合式的測試，執行的過程很緩慢的, 很容易break的, 並且會有很大的maintenance的cost. 除此之外, 這些事情都是手動維護, 這是另一個更大的負擔。
更糟的是, 這個負擔是和軟體的size成比例的, 並且在每次的iteration中, 這些負擔會一直重複發生.
不久之後, QA及使用完所有時間去測試, Bug還是會蔓延到下一個iteration, 並且影響到team規劃的可靠度, 使得整個team逐漸掉到無底深淵去
最後結果: buggy iteration demos.
改善方法: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.
Trap #2: 一廂情願的想法 (Wishful Thinking)
另外一個對iteratiom demo失望的原因, 就是team答應超過他們能力所能做的事情. 他們通常歸咎於estimation不夠準確, 但是這不是真正的原因. 真正的原因是team不知為何緣故, 可能是想要取悅RD, customer或manager, 因此膨脹自己能處理的速度
你不管stories是否真正的被做完(有可能只是code complete, 或是來沒被測完, 或是還沒被customer所接受), 但是你都視為他已經完成, 把它算到你的volocity. 你要知道所謂的做完, 是指這個story已經可以被出貨了才叫做完.
所以做完的定義是很嚴苛的, 會使你的velocity數字會很難看的, 所以人們才會捏造它. 常見的手法是自己在自己的capcity數字上乘一個莫名的比例, 讓你的結果看起來比較好看, 比較"積極", "正面".
但是不管你怎樣假造你的數字, 你有能力作多快這件事還是維持不變.
最後結果:
當iteration的demo開始時, team還沒完成任何事. 事實上, 他們甚至做不完他們有能力完成的部份, 因為大部分的工作都是做到一半, 而不是有一半的工作已經做完. 當然, 這將會導致鱉腳的速度, 因而會讓人增加想要去假造較樂觀數字的念頭.
改善方法:
它是最簡單也是最難的方法, 那就是停止去假造你的速度. 根據已經做完的事情來計算, 並秉持謹慎的態度去增加它. 它可會無法產生你喜歡的數字, 但是您會花更少的時間滅火. 您終於可以開始處理您潛在的生產力問題，而不是玩數字的遊戲; 並且在iteration demo, 不會不安的一直低著頭.
It's a Trap!
http://jamesshore.com/Blog/Its-a-Trap.html
在Adopt Agile時, 作者認為最常見的一個問題, 就是要達到iteration commiment會有問題. 換言之, team通常在iteration在結束時, stories大部分只完工一半. 因此在iteration demo時通常都是很令人失望.
你可能會覺得, 造成這個結果的原因, 可能很複雜並且不大相同. 等等!! 事實上... 這是一派胡言, 我必須老實承認, 而不是很鄉愿地欺騙你. 當你選擇了只挑容易做的practices, 這件事都註定要發生了. 也就是說 這條道路看起來容易和簡單，但是它充滿了陷阱.
Trap #1: 日益增加的QA負擔 (The Ever-Increasing QA Burden)
就作者所知, 許多agile team大多是adopt iteration, dailystand-up meeting和planning game, 但是他們並沒採用其他agile 的 engineering (像是refacotring, TDD, pair programming等等), 所以他們的iteration看起來只像是mini版的waterfalls. 也就是RD做design 和coding, 之後的結果由QA去做測試.
在日益增加的測試負擔中, QA最終只會走向死亡. 即使QA有建立automated的測試, 但是這些測試往往是整合式的測試，執行的過程很緩慢的, 很容易break的, 並且會有很大的maintenance的cost. 除此之外, 這些事情都是手動維護, 這是另一個更大的負擔。
更糟的是, 這個負擔是和軟體的size成比例的, 並且在每次的iteration中, 這些負擔會一直重複發生.
不久之後, QA及使用完所有時間去測試, Bug還是會蔓延到下一個iteration, 並且影響到team規劃的可靠度, 使得整個team逐漸掉到無底深淵去
最後結果: buggy iteration demos.
改善方法: prevent bugs using agile engineering techniques and involving customers rather than trying to test the bugs out.
Trap #2: 一廂情願的想法 (Wishful Thinking)
另外一個對iteratiom demo失望的原因, 就是team答應超過他們能力所能做的事情. 他們通常歸咎於estimation不夠準確, 但是這不是真正的原因. 真正的原因是team不知為何緣故, 可能是想要取悅RD, customer或manager, 因此膨脹自己能處理的速度
你不管stories是否真正的被做完(有可能只是code complete, 或是來沒被測完, 或是還沒被customer所接受), 但是你都視為他已經完成, 把它算到你的volocity. 你要知道所謂的做完, 是指這個story已經可以被出貨了才叫做完.
所以做完的定義是很嚴苛的, 會使你的velocity數字會很難看的, 所以人們才會捏造它. 常見的手法是自己在自己的capcity數字上乘一個莫名的比例, 讓你的結果看起來比較好看, 比較"積極", "正面".
但是不管你怎樣假造你的數字, 你有能力作多快這件事還是維持不變.
最後結果:
當iteration的demo開始時, team還沒完成任何事. 事實上, 他們甚至做不完他們有能力完成的部份, 因為大部分的工作都是做到一半, 而不是有一半的工作已經做完. 當然, 這將會導致鱉腳的速度, 因而會讓人增加想要去假造較樂觀數字的念頭.
改善方法:
它是最簡單也是最難的方法, 那就是停止去假造你的速度. 根據已經做完的事情來計算, 並秉持謹慎的態度去增加它. 它可會無法產生你喜歡的數字, 但是您會花更少的時間滅火. 您終於可以開始處理您潛在的生產力問題，而不是玩數字的遊戲; 並且在iteration demo, 不會不安的一直低著頭.
- Jan 31 Sat 2009 10:59
The Documentation Myth
The Documentation Myth
The Documentation Myth
http://jamesshore.com/Blog/The-Documentation-Myth.html
很多人, 包括我自己, 都認為文件是必要的. 即使抱怨要寫文件的人,在他們需要文件的時候, 也是希望別人也要寫文件給他們. 所以就很容易會有這樣的迷思出現:
Myth: Documentation is good.
但是作者提醒我們一件事, 那就是要文件背後真正的問題是什麼? 他到底認為有什麼問題? 是程式碼寫的不夠清楚? 還是整個程式架構不夠organized? 還是到底是什麼?
因為有時麼你拿到一堆文件, 你也不見得會看, 有時候還會因為文件寫的不夠系統化, 導致你不易了解. 或者是你要找尋一些東西時, 無法很快從這些眾多的文件中找到答案.
所以大家可能真正要的是什麼? 作者認為大家要的應該是解答. 你之所以需要文件, 通常是你有地方不清楚, 想要知道答案是什麼. 有些人想要知道系統架構是如何運作; 有些人想要知道return code有哪些, 各代表什麼意思. 因此最終大家想要的是解答. 所以作者認為換個角度想, 真正的狀況是什麼:
Reality: Answers are good.
如果我們能越快得到答案, 那將會更好更滿足.
但是大家應該也知道可以回答問題的方式有很多種, 文件只是其中一種. 如果有別的方式也可以知道答案, 那是否每個東西都要文件化, 或是立即要文件化, 那就不一定了.
作者這裡提出四種方法, 可以幫助你盡快找到答案. 越前面越是Agile team所想追求的. 但如果做不到, 那就是回歸到原先要寫文件的地步.
1. Best of all is not having to ask the question
- Code that is so well-named and structured that it needs no comments; software whose use is intuitively obvious; libraries that scream their purpose and method of use from every API call.
- XP advocates this as an ideal to strive for.
- It's hard to achieve, sure. We don't always get there, no. But try, and when you think you need documentation, try again.
2. Next best is being able to ask someone the question and get an answer right away.
- Phone calls and email are okay at this, if the other person responds quickly, but the absolute best in speed and communication quality is having the person right next to you, ready to answer the question.
- It's not a pipe dream(白日夢): that kind of instant response is why agile methods emphasize cross-functional and colocated teams. The productivity gains are amazing.
3. Not as good, but still pretty good, is being able to Google the answer easily.
4. And way, way down at the bottom of the list is "reading through documentation to find the answer."
- Sure, sometimes documentation is beautifully organized, wonderfully written, and a pleasure to read.
- Yeah. The rest of the time, it's, um, not. And the more documentation you have to read before you get the answer, the worse off you are.
- More documentation isn't good; just the opposite.
- The only thing great about sheer weight of information--The Almighty Thud--is the sound it makes.
The Documentation Myth
http://jamesshore.com/Blog/The-Documentation-Myth.html
很多人, 包括我自己, 都認為文件是必要的. 即使抱怨要寫文件的人,在他們需要文件的時候, 也是希望別人也要寫文件給他們. 所以就很容易會有這樣的迷思出現:
Myth: Documentation is good.
但是作者提醒我們一件事, 那就是要文件背後真正的問題是什麼? 他到底認為有什麼問題? 是程式碼寫的不夠清楚? 還是整個程式架構不夠organized? 還是到底是什麼?
因為有時麼你拿到一堆文件, 你也不見得會看, 有時候還會因為文件寫的不夠系統化, 導致你不易了解. 或者是你要找尋一些東西時, 無法很快從這些眾多的文件中找到答案.
所以大家可能真正要的是什麼? 作者認為大家要的應該是解答. 你之所以需要文件, 通常是你有地方不清楚, 想要知道答案是什麼. 有些人想要知道系統架構是如何運作; 有些人想要知道return code有哪些, 各代表什麼意思. 因此最終大家想要的是解答. 所以作者認為換個角度想, 真正的狀況是什麼:
Reality: Answers are good.
如果我們能越快得到答案, 那將會更好更滿足.
但是大家應該也知道可以回答問題的方式有很多種, 文件只是其中一種. 如果有別的方式也可以知道答案, 那是否每個東西都要文件化, 或是立即要文件化, 那就不一定了.
作者這裡提出四種方法, 可以幫助你盡快找到答案. 越前面越是Agile team所想追求的. 但如果做不到, 那就是回歸到原先要寫文件的地步.
1. Best of all is not having to ask the question
- Code that is so well-named and structured that it needs no comments; software whose use is intuitively obvious; libraries that scream their purpose and method of use from every API call.
- XP advocates this as an ideal to strive for.
- It's hard to achieve, sure. We don't always get there, no. But try, and when you think you need documentation, try again.
2. Next best is being able to ask someone the question and get an answer right away.
- Phone calls and email are okay at this, if the other person responds quickly, but the absolute best in speed and communication quality is having the person right next to you, ready to answer the question.
- It's not a pipe dream(白日夢): that kind of instant response is why agile methods emphasize cross-functional and colocated teams. The productivity gains are amazing.
3. Not as good, but still pretty good, is being able to Google the answer easily.
4. And way, way down at the bottom of the list is "reading through documentation to find the answer."
- Sure, sometimes documentation is beautifully organized, wonderfully written, and a pleasure to read.
- Yeah. The rest of the time, it's, um, not. And the more documentation you have to read before you get the answer, the worse off you are.
- More documentation isn't good; just the opposite.
- The only thing great about sheer weight of information--The Almighty Thud--is the sound it makes.
- Jan 29 Thu 2009 14:43
Agile 的衰敗緣由
Agile 的衰敗緣由
The Decline and Fall of Agile
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
我想很多人一定讀過"The Art of Agile Development", 它是一本很紅agile 書籍, 在Amazon上有四顆半的評價. 可是作者在2008年11月時, 寫了一篇文章談Agile的誤用與衰亡.
雖然Agile現在似乎是當紅, 可是作者卻唱衰地說, Agile可能在幾年後走向敗亡的道路.
因為剛開始時, 別人都是要做這去教他們怎麼用agile, 可是現在卻是叫作者去救急. 因為他們apply agile後遭遇到很多問題. 像是無法meeting iteration commitments, a lot of technical debt, 和測試要花很長的時間等等.
甚至有同行還笑稱 "Rescuing Scrum teams keeps me in business". 聽起來很糟, 但卻是事實.
所以作者覺得 agile這行應該快有問題了, 尤其Scrum讓這種情況更加惡化
以下是作者認為Agile失敗的原因如下
(1) Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design.
- Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement.
- Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt.
(2) People just adopt rapid cycles(Sprints and Scrums), but none of the good stuff that makes rapid cycles sustainable.
(3) People aren't working in shared workspaces or emphasizing high-bandwidth communication.
- They're don't have on-site customers or work in cross-functional teams.
- They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.
(4) People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.
我認為是這就像王安石變法一樣, 立意雖佳, 但是若是執行的人不佳, 結果還是不好的. 這也樣當初在推OO一樣, 都是表面上像OO, 但是內部精神上並沒有把原汁原味給做到位.
作者寫完後, 目前已有133人給他feedback, 我想這是很驚人的回應. 很值得大家去看看, 尤其是你現在run agile, 特別是Scrum的人, 好好小心是否自己也有相同的問題.
The Decline and Fall of Agile
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
我想很多人一定讀過"The Art of Agile Development", 它是一本很紅agile 書籍, 在Amazon上有四顆半的評價. 可是作者在2008年11月時, 寫了一篇文章談Agile的誤用與衰亡.
雖然Agile現在似乎是當紅, 可是作者卻唱衰地說, Agile可能在幾年後走向敗亡的道路.
因為剛開始時, 別人都是要做這去教他們怎麼用agile, 可是現在卻是叫作者去救急. 因為他們apply agile後遭遇到很多問題. 像是無法meeting iteration commitments, a lot of technical debt, 和測試要花很長的時間等等.
甚至有同行還笑稱 "Rescuing Scrum teams keeps me in business". 聽起來很糟, 但卻是事實.
所以作者覺得 agile這行應該快有問題了, 尤其Scrum讓這種情況更加惡化
以下是作者認為Agile失敗的原因如下
(1) Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design.
- Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement.
- Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt.
(2) People just adopt rapid cycles(Sprints and Scrums), but none of the good stuff that makes rapid cycles sustainable.
(3) People aren't working in shared workspaces or emphasizing high-bandwidth communication.
- They're don't have on-site customers or work in cross-functional teams.
- They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.
(4) People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.
我認為是這就像王安石變法一樣, 立意雖佳, 但是若是執行的人不佳, 結果還是不好的. 這也樣當初在推OO一樣, 都是表面上像OO, 但是內部精神上並沒有把原汁原味給做到位.
作者寫完後, 目前已有133人給他feedback, 我想這是很驚人的回應. 很值得大家去看看, 尤其是你現在run agile, 特別是Scrum的人, 好好小心是否自己也有相同的問題.
- Jan 28 Wed 2009 10:02
什麼是Definition of Done (DoD)?
什麼是Definition of Done (DoD)?
What is Definition of Done (DoD)?
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
Definition of done (DoD) 對一個Scrum的team來說非常的關鍵, 因此你必須要和team找出你們共同的DoD出來. 以下是DoD所擁有的特性, 和你的team檢查看看, 是否你們都有注意這些重點
1. DoD是檢查它們完成程度的checklist
- A simple list of activities that add verifiable/demonstrable value to the product.
- Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.
- For example: writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
2. DoD 對team members來說, 它是主要的reporting mechanism
- Reporting in its simplest form is the ability to say, “This feature is done.”
- DoD is a simple artifact that adds clarity to the “Feature’s done” statement.
- Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.
3. DoD 是根據現實狀況來回報的
(1) Scrum asks that teams deliver “potentially shippable software” at the end of every sprint.
- Potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion.
- Ideally, potentially shippable is equivalent to the Definition of Done.
(2) In reality, many teams are still working towards a potentially shippable state. Such teams may have a different DoD at various levels:
- Definition of Done for a feature (story or product backlog item)
- Definition of Done for a sprint (collection of features developed within a sprint)
- Definition of Done for a release (potentially shippable state)
(3) There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release.
- Ultimately, the decision rests on the answer to the following three questions:
Can we do this activity for each feature? If not, then
Can we do this activity for each sprint? If not, then
We have to do this activity for our release!
(4) Teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”. Common root causes for impediments include:
- Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
- Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
- Team members are executing their sprint in mini-waterfalls.
- Aha! Here’s an opportunity to be more cross-functional and share responsibilities across functional silos.
4. DoD 不是一成不變的
- The DoD changes over time.
- Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.
5. DoD 是一份auditable checklist.
- Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining).
- Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist.
- The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis.
What is Definition of Done (DoD)?
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod
Definition of done (DoD) 對一個Scrum的team來說非常的關鍵, 因此你必須要和team找出你們共同的DoD出來. 以下是DoD所擁有的特性, 和你的team檢查看看, 是否你們都有注意這些重點
1. DoD是檢查它們完成程度的checklist
- A simple list of activities that add verifiable/demonstrable value to the product.
- Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.
- For example: writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.
2. DoD 對team members來說, 它是主要的reporting mechanism
- Reporting in its simplest form is the ability to say, “This feature is done.”
- DoD is a simple artifact that adds clarity to the “Feature’s done” statement.
- Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.
3. DoD 是根據現實狀況來回報的
(1) Scrum asks that teams deliver “potentially shippable software” at the end of every sprint.
- Potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion.
- Ideally, potentially shippable is equivalent to the Definition of Done.
(2) In reality, many teams are still working towards a potentially shippable state. Such teams may have a different DoD at various levels:
- Definition of Done for a feature (story or product backlog item)
- Definition of Done for a sprint (collection of features developed within a sprint)
- Definition of Done for a release (potentially shippable state)
(3) There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release.
- Ultimately, the decision rests on the answer to the following three questions:
Can we do this activity for each feature? If not, then
Can we do this activity for each sprint? If not, then
We have to do this activity for our release!
(4) Teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”. Common root causes for impediments include:
- Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
- Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
- Team members are executing their sprint in mini-waterfalls.
- Aha! Here’s an opportunity to be more cross-functional and share responsibilities across functional silos.
4. DoD 不是一成不變的
- The DoD changes over time.
- Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.
5. DoD 是一份auditable checklist.
- Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining).
- Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist.
- The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis.
