![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerI moved to a new team at Christmas, leaving the mainframe (largely) behind me, and heading into the worlds of Java and C#. This was nice - a decent IDE makes a huge difference to me, and compiles that take 3 seconds rather than 5 minutes are a godsend. However, in many ways this wasn't the biggest change from my old team to the new one.
The standard way of working on software development is for a business analyst to talk to users, look at processes and work out what is needed, setting it out in some kind of large document. An IT analyst then takes this document and produces a design and specifications for how the computers will produce the effect the business person described. A bunch of programmers then follow the specification to produce a working system that fulfills the IT analyst's specification. At the end the working system is handed over to the users, who cry with joy at the sheer wonderfullness of what's been created.
Or Not.
What tends to _actually_ happen is that the Business Analyst has a pretty good idea of what they want, knows that anything they miss out will cause people to whine at them incessantly, and that IT projects come along once every five years. They therefore throw vast amounts of 'nice to have' items into the spec, leaving out lots of things that they believe are obvious, and put in a variety of things they can't have, as they don't actually understand the current system.
The IT analyst then mostly understands this document, works out a good way of implementing bits of it, hides the bits that look impossible, writes up a design based on their (limited) understanding of the current system and hands it to a bunch of developers who all work independently to produce something which then doesn't really hang together when they come to integrate it. It doesn't quite do what the IT analyst wanted (because the spec wasn't 100% perfect), it doesn't really do what the business analyst wanted (because the IT analyst didn't understand the business spec 100% before writing the IT spec), and it really doesn't do what the actual business user wants (because they've been pretty much left out of the whole process).
The business users then complain loudly about the programmers, who are terribly upset, because _they followed the spec_. At this point everyone goes down (separate) pubs and cries into their beer.
The problem here is not the quality of specs, the quality of the understanding of the various people involved or the laziness of the various workers. The problems is that the whole methodology is a big pile of poo.
The _current_ methodology we're trialling (to rapturous response) is this:
The business people come to us with a problem. We then spend 1-4 weeks going over their processes with them and seeing where we can help, before agreeing a general, over-arching goal/direction for the project. We then agree what we are going to do _in the first month_. We do this using a very simple method - they organise their priorities into a list (with our help) and then we tell them how far down the list we can get in a month.
We then beaver away for a month, producing the stuff we said we would. We do this _with a business representative sitting with the team_. This business rep may well bring work with him to do while they're sitting there, but they're constantly available when we ask awkward questions like "When you said you wanted X, did you want X1 or X2?", the answer frequently being "Y, of course." This keeps us on general track during that month, in general.
At the end of the month, we then have a system that _does something_. This is important. It may not be finished. It may not be ready to show the world. But it _is_ in a state where we can show it off to a bunch of business people and ask for their feedback. They can then look at what we've done and decide (a) what changes they want, because of miscommunication and misunderstanding and (b) what ideas they've now had as to what it could do. We now go back to the priority list, they add, remove and move things around and we then agree what will happen in the second month.
By doing this, it is impossible to produce a system they don't want. We may go off on the wrong track for a month (although this is unlikely with a business person sitting there), but we can't go wrong for longer than that. We can't focus on functionality they don't care about, rather than the things they do, because they set the priority.
And so far, in general, it seems to work extremely well. I never have a feeling of working in a vacuum, or that I'm not doing the right thing, or that what I'm making makes no sense - because there's always someone around to give me a sense-check, and at the end of each month we get feedback about how well we're doing.
If they try to make me go back to the old way of working, I'm going to cry. A lot.
The standard way of working on software development is for a business analyst to talk to users, look at processes and work out what is needed, setting it out in some kind of large document. An IT analyst then takes this document and produces a design and specifications for how the computers will produce the effect the business person described. A bunch of programmers then follow the specification to produce a working system that fulfills the IT analyst's specification. At the end the working system is handed over to the users, who cry with joy at the sheer wonderfullness of what's been created.
Or Not.
What tends to _actually_ happen is that the Business Analyst has a pretty good idea of what they want, knows that anything they miss out will cause people to whine at them incessantly, and that IT projects come along once every five years. They therefore throw vast amounts of 'nice to have' items into the spec, leaving out lots of things that they believe are obvious, and put in a variety of things they can't have, as they don't actually understand the current system.
The IT analyst then mostly understands this document, works out a good way of implementing bits of it, hides the bits that look impossible, writes up a design based on their (limited) understanding of the current system and hands it to a bunch of developers who all work independently to produce something which then doesn't really hang together when they come to integrate it. It doesn't quite do what the IT analyst wanted (because the spec wasn't 100% perfect), it doesn't really do what the business analyst wanted (because the IT analyst didn't understand the business spec 100% before writing the IT spec), and it really doesn't do what the actual business user wants (because they've been pretty much left out of the whole process).
The business users then complain loudly about the programmers, who are terribly upset, because _they followed the spec_. At this point everyone goes down (separate) pubs and cries into their beer.
The problem here is not the quality of specs, the quality of the understanding of the various people involved or the laziness of the various workers. The problems is that the whole methodology is a big pile of poo.
The _current_ methodology we're trialling (to rapturous response) is this:
The business people come to us with a problem. We then spend 1-4 weeks going over their processes with them and seeing where we can help, before agreeing a general, over-arching goal/direction for the project. We then agree what we are going to do _in the first month_. We do this using a very simple method - they organise their priorities into a list (with our help) and then we tell them how far down the list we can get in a month.
We then beaver away for a month, producing the stuff we said we would. We do this _with a business representative sitting with the team_. This business rep may well bring work with him to do while they're sitting there, but they're constantly available when we ask awkward questions like "When you said you wanted X, did you want X1 or X2?", the answer frequently being "Y, of course." This keeps us on general track during that month, in general.
At the end of the month, we then have a system that _does something_. This is important. It may not be finished. It may not be ready to show the world. But it _is_ in a state where we can show it off to a bunch of business people and ask for their feedback. They can then look at what we've done and decide (a) what changes they want, because of miscommunication and misunderstanding and (b) what ideas they've now had as to what it could do. We now go back to the priority list, they add, remove and move things around and we then agree what will happen in the second month.
By doing this, it is impossible to produce a system they don't want. We may go off on the wrong track for a month (although this is unlikely with a business person sitting there), but we can't go wrong for longer than that. We can't focus on functionality they don't care about, rather than the things they do, because they set the priority.
And so far, in general, it seems to work extremely well. I never have a feeling of working in a vacuum, or that I'm not doing the right thing, or that what I'm making makes no sense - because there's always someone around to give me a sense-check, and at the end of each month we get feedback about how well we're doing.
If they try to make me go back to the old way of working, I'm going to cry. A lot.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-04-14 06:27 pm (UTC)no subject
Date: 2005-04-14 07:36 pm (UTC)I just wish my customers *wanted* to be involved in the process, sometimes. I'm Evil Analyst and make them, but I can understand why that gets left out sometimes....
no subject
Date: 2005-04-14 07:46 pm (UTC)no subject
Date: 2005-04-14 08:05 pm (UTC)no subject
Date: 2005-04-14 09:20 pm (UTC)We're currently trying to change our testing strategy to one that isn't one size fits all and involves actually working out where the risks are and testing to them. Great in theory, but how likely is it that a contractor just in the door will be able to do it well?
no subject
Date: 2005-04-14 09:24 pm (UTC)We actually have almost no documentation for this project. We have a few discussion documents (that get edited to fit current discussions - old ones are deleted) an excel spreadsheet with all the validation for the GUI in it and a whiteboard with the project schedule on it (again, changed on a as-and-when basis).
We know we're doing the right thing because the users tell us we are, and check it on a regular basis. We don't need documentation too :->
(We will, of course, be providing training documentation for the end users).
no subject
Date: 2005-04-15 09:52 pm (UTC)no subject
Date: 2005-04-15 10:04 pm (UTC)no subject
Date: 2005-04-15 02:45 am (UTC)I'm in the process of doing the same thing. Spent a week building objects and a general framework for what the users would probably need. That part kind of sucked because they didn't see anything. But then it's time to wire up the interfaces with the objects, and C# makes it so easy to do this, things go up in a hurry, and it's a snap to move items around, because everything's encapsulated.
Guidance
Date: 2005-04-15 07:23 am (UTC)I mean it identifies duplicate entries by name rather than NI Number, it will not accept that an address can be two lines plus a postcode, to print something you need to open it in a preview window and then print (why do you need to see it to print it, I dont know)
So yay for you, build things people actually want
no subject
Date: 2005-04-15 08:43 am (UTC)The one bad point about my work here is that everything is filtered via at least one person and I don't get to talk to the users really. (this isn't really deliberate, more a function of tryign to keep some osrt of control on work requests). It doesn't matter so much for the kind of behind-the-scenes stuff that I mainly do, but still, I keep subtly pushing for more - sometime I dont' even know WHO a piece of work is to be used by - which is daft.
no subject
Date: 2005-04-15 09:43 am (UTC)Somehow, though, I think we mostly ignore them or just use them for finding bugs rather than giving feedback on the game. Personally I think our design methods are rubbish, random and convoluted and drag out project lengths. This seems to be changing but I'm not sure by how much or whether that will work :S
no subject
Date: 2005-04-16 05:01 am (UTC)I'm absolutely amazed that your bosses have actually made the decision to embrace agile methods... seems too good to be true! There seems little danger they'd go back to the bad old days, given the results are presumably speaking for themselves.
Now, if only the Australian government could be convinced that this kind of way of doing things—time and materials, iterative/incremental development—actually works, rather than vast fixed price monstrosities with multi-year delivery time frames, I'd be more optimistic about future defence projects...