Filed under: Development
For long I’ve been interested in how a software projects, a business one, goes from its start to the end. There are plenty of books talking about methodologies but no one ever showed me the complete history of development of a real business software. May be it’s too boring at all. Or the folks writing those lengthy books have never put the theories into practice. Not sure if this is a good news to my company, I’ve got a chance to drive the development of a new application almost on my own behalf running with a entirely new team in China. I decided that the project contains no top business secret that my boss wouldn’t mind me writing down the story. After all, may be I can earn myself some penny by publishing the story to folks like me ever wondered about how a piece of successful software is given birth. So I start blogging about it.
The project is launched to build an application facilitating our customer relationship management process, with weighted focus on long term relationship management that happen after users have purchased our products/services. After a few weeks of study I decided to go XP for this project. The project is new, with lots of area not very well defined nor explored. Our development buddies, on the other hand, new on technology and product design. It could be best to take an iterative approach like XP to handle all these varying factors with a fizzy yet controllable manner. To be honest I was not having a very pleasant experience with my last XP project. Yet those big up-front methodologies make me more sick. Cockburn, the proposer of crystal clear methodology, said you should always review your process and shape it iteratively to make it work better especially your process is not giving what it’s supposed to give. Okay, I am sold. I don’t want to give up lessons learn from my last XP trial either. So I give it a second chance.
Projects always start with requirement gathering, no matter what methodology has been chosen to layout the project. I decided to talk to our users in terms of “User Story”. User story is plain, goal oriented and can be understand by everyone. It’s more valuable to know the goals that the buttons they want to have on their screen, or the number of fields they would like to have for describing a shipping address.
Today, 23th July 07, we have hold our first user story workshop, one of the best option to gather large number of user stories in a very short time. A few of the user representative from different teams and departments are invited. Our folks are busy. So I set the time limit to 2 hours. As the idea of working with user stories is still new to our folks, I spent around 10 minutes briefing them what’s user story and a user story workshop is about. We started with listing out roles. Then with the roles identified in mind we brainstormed the user stories the roles could have, writing each on a little note card.
Users were confused a bit at first what roles are to be identified. Say, role A wants to see something about B. Should B considered as a role as well? My answer is, no. Cos the application serves B in no way at all. The story should be written under the name of role A in fact. All right, then confusions gone and the list began to storm. They surprised me in numerous way I think the users want the application to be. Actually before I run the workshop I have made myself a list of roles and user stories given my understanding on the application’s problem domain. I can hardly think of variations of customer role but our users managed to give 10 customer roles just in minutes, though after a dicussion we managed to reduce the duplicates making the number down to 4. The user stores gathered thereafter surprised me as well in their variety. Most XP books would suggest you to get to your users. Sometimes if you are not able to get real users you have no choice but to get input from user proxy instead. Typical user proxy includes user’s manager, domain experts, development manager, marketing group, salespersons and former users. Yet these proxies, though all with their expertise related to the application’s usage, does give stories with bias. The bias could be so great that if you are unaware of it you could drap your application towards a very wrong direction. When I compared my own list with that gathered, I feel I’m lucky to have access to real users.
At the end of the day, I got a dozen of roles and user stories to start my next phase of work, to digest user stories and organize them into our upcoming project plan. No computer processing, only papers and hands. We done it all quickly with a whiteboard, a stack of note cards and pens. Things looks good. Our folks were enjoying it, at least it appeared to me as so when they were writing the stories with laugher on their faces. We have a clearer view on the goals and scope of the project. We have the atomsphere of conversation between development force and user force. And we are on the track.
Leave a Comment so far
Leave a comment
