目前我們仍然跟的上進度嗎?
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
作者在run Scrum時, 有一個典型的問題困擾著他
How do we know if the team is on track to meet our iteration commitment (sprint goal)?
我想這應該是每個人都會遇到的問題, 作者列出一些他曾經使用的方法, 但是這些方法並沒有運作的很好
解法 1: 使用Sprint burndown chart
- Rightly or wrongly, our signature story point burndown chart tends to look a bit like this (and that is another topic for another day):
http://blog.huddle.net/wp-content/uploads/2009/02/3236267685_9002ee1159-300x195.jpg
- so we often don’t know if we are going to make it until the last couple of days of the iteration.
解法 2: 那為什麼不使用以小時為單位的方式, 來列出一個iteration中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, 這樣你就可以知道是否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規劃的更好, 產生出mini project plan
- Please! Remind me, which do we value more – a) following a plan, or b) responding to change?
解法 5: 如果你按照優先順序來做user stories, 並且能有效率的解決和做完, 那問題是什麼呢?
- If unforeseen issues materialise, the lowest priority stories won’t be delivered, and so be it!”
- Firstly, 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.
- Secondly, and 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.
目前個人是看不出作者這樣的作法有沒有用, 不過因為也遭遇類似的問題, 可能會加減來試看看
留言列表
