We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
The main group that I've worked on for the last 10 years tries to follow that manifesto. We may not be truly an "agile" team, and we may not be 100% "XP" (or even 50%)... but we are moving there, and we believe in the above. Lately I've been working with some other people. Mostly doing architecture, participating in some design thoughts, did some prototyping, etc. Helping out and trying to guide... but its their team and they are all forced to follow the standard waterfall process. Which is an extermely rigid. Nothing agile about it.
AND ITS DRIVING ME NUTS.
It is so against the manifesto.
- Process over interactions - no we can't do any coding until the design is 100% complete. And when it is all done, we'll have to manually verify that all interfaces are in sync.
- Or you could just take the Agile approach and hook some code into the framework and insure that all the tests still work. Not worrying about whether the interfaces work or not, cuz they obviously do since everything compiled and is still working.
- Comprehensive documentation over working software. Don't make changes as better ways are discovered - instead lets just document it, review it, and then make it later.
- Or you could just updating the code that currently works, make sure it still pasts the tests, and move on. Thus having one less thing to do later, and being able to see how it actually effects the system, and letting people code against the change.
- Following a plan over responding to change - Don't modify the system based upon user requests, but follow what was originally scoped, no matter what - for fear of scope creep. We can always change it in a later release
- Or you could make the update right now, be responsive, and see how it effects things, rather than designing and building upon things that you know will eventually change
The manifesto is a great thing, a great way to think, and is trying to move us in the right direction.
I was talking to someone about all of this - and how from a "true" Agile/XP group - they may look at what we do and think "you aren't even close". But as this person said "You don't know how far you've come, until you are forced to look back at where you've been."
How true. I didn't realize how far we've come, until I was forced to work in the old way.
Now, not only working the new way (agile), but having the oppurtunity to compare it to the old way (waterfall) in a real environement, man... I can't ever imagine going back. Its just way too painful.
And a cool thing about process improvement, and new techniques, is that people (at least some people) are starting to realize that there is no "correct" answer. There is only a "better" answer. I believe, as do many others, that Agile/XP is the better answer... right here, right now. (To quote VanHalen). But that doesn't mean 10 years from now it will be. And that is something some people find so hard to understand and work with. "Tell me the correct process, and the one we will use forever. Tell me what it is and then never change it." We (the architects on my projects) keep trying to tell people - things will always change... if we are working towards making them better. Its not that they are bad now, just that they could be better.
Well... guess I should climb down off my soap-box now...
No comments:
Post a Comment