程式扎記: [ HF Software Dev ] Chap4 : User stories and tasks - Getting to the real work

標籤

2011年5月9日 星期一

[ HF Software Dev ] Chap4 : User stories and tasks - Getting to the real work


Preface :
It’s time to go to work. User stories capture what you need to develop, but now it’s time to knuckle down and dish out the work that needs to be done so that you can bring those user stories to life. In this chapter you’ll learn how to break your user stories into tasks, and how task estimates help you track your project from inception to completion. You’ll learn how to update your board, moving tasks from in progress to complete, to finally completing an entire user story. Along the way, you’ll handle and prioritize the inevitable unexpected work your customer will add to your plate.

Break user stories into tasks :
In the beginning, we have a project iSwoon and all the user stories are collected as well. According to those user stories, we use a 20-work-day iteration to break down into below big board (we will mentioned latter). And now our jobs is to break user stories into tasks.
- Your work is more granular than your user stories
Your user stories were for your user; they helped describe exactly what you software needed to do, from the customer’s perspective. But now that it’s time to start coding, you’ll probably need to look at these stories differently. Each story is really a collection of specific tasks, small bits of functionality that can combine to make up one single user story. A task specifies a piece of development work that needs to be carried out by one developer in order to construct part of a user story. Each task has a title so you can easily refer to it, a rough description that contains details about how the development of that task should be done, and an estimate.
Each task has its own estimate and—guess what—the best way to come up with those estimates is by playing planning poker again with your team.


- Do your tasks add up?
Did you notice a possible problem with your estimates? We’ve got a user story with an estimate, but now we’re adding new estimates to our tasks. What happens when the two sets of estimates don’t agree?


- Task estimates add confidence to user story estimates
Your user story estimates kept you in the right ballpark when you were planning your iterations, but tasks really add another level of detail specific to the actual coding you’ll do for a user story. In fact, it’s often best to break out tasks from your user stories right at the beginning of the estimation process, if you have time. This way you’ll add even more confidence to the plan that you give your customer. It’s always best to rely on the task estimates. Tasks describe the actual software development work that needs to be done and are far less of a guesstimate than a coarse-grained user story estimate.

- Plot just the work you have left
Remember that burn-down rate chart from Chapter 3? Here’s where it starts to help us track what’s going on in our project. Every time we do any work or review an estimate, we update our new estimates, and the time we have left, on our burn-down chart :


- Add your tasks to your board
You and your team are now almost ready to start working on your tasks, but first you need to update the big board on your wall. Add your task sticky notes to your user stories. and also add an In Progress and Complete section for tracking tasks and user stories :


Start working on your tasks :
It’s time to bring that burn-down rate back under control by getting started developing on your first user story. And, with small tasks, you can assign your team work in a sensible, trackable way :


- A task is only in progress when it’s IN PROGRESS
Now that everyone’s got some work to do, it’s time to move those task stickies off of user story cards, and onto the In Progress
area of your big board. But you only put tasks that are actually being worked on in the In Progress column—even if you already know who’ll be working on tasks yet to be tackled. Your board’s only as VALUABLE as it is ACCURATE

- What if I’m working on two things at once?
Not all tasks are best executed in isolation. Sometimes two tasks are related, and, because there is so much overlap, it’s actually more work to tackle one, and then the other separately. In these cases the most productive thing to do is work on those tasks at the same time...
Rules of Thumb :
* Try to double-up tasks that are related to each other, or at least focus on roughly the same area of your software. The less thought involved in moving from one task to another, the faster that switch will be.
* Try not to double-up on tasks that have large estimates. It’s not only difficult to stay focused on a long task, but you will be more confident estimating the work involved the shorter the task is.



- Your first standup meeting...
You’ve now got some tasks in progress, and so to keep everyone in the loop, while not taking up too much of their time, you conduct a quick standup meeting every day. Your daily standup meetings should :
* Track your progress. Get everyone’s input about how things are going.
* Update your burn-down rate. It’s a new day so you need to update your burndown rate to see how things are going.
* Update tasks. If a task is completed then it’s time to move it over into the Completed area and check those days off of your burn-down rate.
* Talk about what happened yesterday and what’s going to happen today. Bring up any successes that happened since yesterday’s standup meeting and make sure everyone knows what they’re doing today.
* Bring up any issues. The standup meeting is not a place to be shy, so encourage everyone to bring up any problems they’ve encountered so that you all as a team can start to fix those problems.
* Last between 5 and 15 minutes. Keep things brief and focused on the short-term tasks at hand.

- You have to track unplanned tasks
So far, your board has kept track of everything going on in your project. But what happens when somthing unplanned comes up? You have to track it, just like anything else. It affects your burn-down rate, the work you’re doing on user stories, and more...
Note :
An unplanned task is STILL a task. It has to be tracked, put in progress, completed, and included in the burn-down rate just like EVERY OTHER TASKyou have.

You’ve been hit by the unexpected, but that’s part of software development. You can’t do everything, but you also can’t make the
choice about what takes priority. Remember, the customer sets priorities, not you. You need to deal with new tasks like customer demos, and the best way to do this is to ask the customer what takes priority. Give the customer a chance to make a considered decision by estimating the amount of work that the new task requires and explaining how that will affect the current schedule. Ultimately, the customer rules, so as long as they have all the information needed to make a choice, then you need to be prepared to go with their decision by reshuffling your
existing tasks and user stories to make room for the surprise work. Ultimately you need to keep your customer in the picture as to what is in and what is out. Adding new unplanned work is not the end of the world, but your customer needs to understand that the work has an impact, and then they can choose what that impact is.

- Unexpected tasks raise your burn-down rate
Unexpected task mean extra work. If the unexpected tasks can’t be pushed into another iteration, then they need to be factored into your board. All of this means that your burn-down rate is affected, and not in a good way...


- Velocity helps, but...
You’ve got more work thanks to some unexpected requirements from your customer, but didn’t you factor this in when you calculated your team’s
velocity? Unfortunately, velocity is there to help you gauge how fast your team performs, but it’s not there to handle unplanned tasks :


- Float—the “extra” days in your schedule—disappear quickly.
An employee’s car breaks down, someone has to go to the dentist, your daily standup meetings...those “extra” days disappear quickly. And remember, float is in work time, not actual time. So if your company gives an extra Friday off for great work, that’s three days of float lost because you are losing three developers for the whole day. So when unplanned tasks come up, you may be able to absorb some of the extra time, but velocity won’t take care of all of it.
Note :
Velocity is NOT a substitute for good estimation; it’s a way of factoring in the real-world performance of you and your team.

- We have a lot to do...
You’re in a tough spot. Doing some refactoring work is going to cost you time now, but the hope is that it will save you time in the long run. In addition you have the new demo that you need to prepare for the iSwoon CEO...but we know EXACTLY where we stand :
* The customer knows where you are
At every step you’ve kept the customer involved so they know exactly what work they’ve added, and you can show them exactly what the changes will impact.
* YOU know where you are
You and your development team are also on exactly the same page thanks to your board and the burn-down rate. This means that although things look a bit bleak, at least no one is burying their heads in the sand. The challenges are right there on your wall.

Because you’re monitoring your project using your board you know right now that there are challenges ahead if you’re going to keep things on track. Compare this with the Big Bang “See you later, I’ll deliver something in 3 months” approach from Chapter 1.
With the Big Bang approach, you didn’t know you were in trouble until day 30, or even day 90! With your board and your burn-down rate you know immediately what you’re facing, and that gives you the edge to make the calls to keep your development heading towards success.
Note :
Successful software development is about knowing where you are. With an understanding of your progress and challenges, you can keep your customer in the loop, and deliver software when it’s needed.
This message was edited 21 times. Last update was at 28/04/2011 16:40:07

沒有留言:

張貼留言

網誌存檔

關於我自己

我的相片
Where there is a will, there is a way!