在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.
全站熱搜
留言列表
