Agile software development is becoming quite popular these days, which is funny, because in the subject we had about software development, the lecturer kinda poo-pooed the whole thing as rubbish, but having used it in practice, I can see how handy it is. If you can't be bothered reading the Wikipedia article, here's the gist of it.
The old method was to define the software, then move on to building the software, then testing it, to make sure it works, then shipping it. Usually, there is quite a long gap between the definition stage, and the shipping stage, and often things have moved on, and what eventually gets built was not what they wanted. To find that out when shipping means a huge amount of money is wasted. Instead, agile tries to smaller define, build, test, ship cycles, where you start building the essential features, and expand from there, checking at each shipping stage whether you're still on the right track. Because you've built something tangible, even if it's small, the end users can offer feedback because they can actually see/use it. This also means if the end user thinks what you've built so far is completely wrong halfway through your process, they tell you earlier and you can make changes faster.
One of the tools used in agile development is a story wall. Each task is broken down into "stories" that define a particular thing that needs to be done, and what criteria that activity has before being considered completed. You estimate roughly how large each story is, so you have a rough idea of how long it'll take, and then each person picks one or more stories and runs with them, with the idea being they pick up more stories than they can realistically complete in a pre-defined cycle (e.g. 3 weeks). Stories are arranged in order of priority, so you know what the important things are. It's really important to remember that not every story needs to be completed, which is why there is a prioritisation step. Cards were sorted into 4 columns:
- Backlog: Cards that hadn't been picked up yet
- In Progress: Cards that were currently assigned to one of us
- In Testing: Cards that were just waiting to hear back from someone (e.g. waiting for confirmation from a vendor)
- Done: Cards that had been completed
So MrMan5.5 and I sat down and worked out all the tasks we needed to complete for the wedding. We sorted out dependencies (stories that rely on other stories to be complete) and estimated them. Then we sorted them by priority. The idea was that every Sunday, we would get together (in a "stand up") and report the status of our current story/stories, and re-prioritise if necessary. That way we could keep track of who was doing what (to avoid doubling up on things), and get an idea of how close we were to having the entire wedding planned.
Well, as Sun Tsu says, no battle plan ever survived first contact with the enemy, and things did not quite go as smoothly as we thought. The fact that the wedding was so far away, and that we had more pressing issues to deal with at work made it really easy to slack off. The Sunday "stand ups" happened once, and it was on a Tuesday. However, I think the card system worked well. It was good knowing that we both had tasks assigned to each other, and when we finally did complete tasks, it was nice to move the cards over to the "Done" column.
We took a look last week, and we really only have seven cards left in the backlog, which means we're nearly done with the wedding! I've been stressing a lot about it lately, and wondering if we were going to get things done in time, but I feel a lot better about it now. There were a few cards that we ended up tossing, as we realised they're not all that important in the grand scheme of things. Having the story wall helped us decide that as well.
Even now, the last few tasks are mostly nice-to-haves. We have all the essential things in order to have a wedding: someone to officiate it, somewhere to get married, clothes to wear at the wedding, guests to see us be married. All the rest is icing on the cake, really.
No comments:
Post a Comment