Perhaps I have been an engineer too many years to have a lot of faith in the agile process. I'm use to engineers providing a very definite path, in the form of drawings and specification, to a construction crew who completes the project. Careful upfront planning can reduce the cost of a project significantly, whereas poor planning is just asking for a disaster. I also recognize that software development is quite a bit different than constructing a building, so maybe other techniques might work better.
In reviewing different software development techniques I ran across an article by Martin Fowler on the general concepts of agile programming. I took a few quotes I found interesting and included them in my blog with my comments below:
"Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify."
I had posted a blog on this issue previous to this post. I find the idea of estimating program development a constant mystery. I've talked with may estimators in other fields and have been a project estimator on hundreds of projects. It seems there is no other technique in other fields of estimating that crosses well into software estimating. Moreover software estimating seems to always come down to guessing the size (time and cost) of black boxes. Maybe because software is almost always a "new creation" unlike construction where a door is a door and a wall is a wall. I guess I'm still looking for that magic software estimating algorithm.
"This doesn't mean that you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner."
Sorry, I just can't buy it, "controlled manner" or not. I have never been on a project where a change in scope did not result in a change in ether time or price. Granted, software is kind of "soft" so it might give a bit on this issue. I'd really have to see this in action to believe it works.
"A consequence of self-adaptivity is that you should never expect to find a single corporate methodology. Instead each team should not just choose their own process, but should also actively tune their process as they proceed with the project."
I can actually see some relevance to this statement. I have rarely found that the "cut and dry" engineering procedures that have been placed on me over the years worked very well. I have always found that I need to modify them, either to suit my needs or the specific needs of the project. I have also found that engineering process are seldom ever self correcting and rarely support the idea of "active tuning". I actually like this concept of the agile process.
"With common guidelines that state that the role of testing is to ensure conformance of software to up-front written specifications, the role of testers in an agile world is far from clear."
The world I live in....So much of the current philosophy of "Quality Assurance" is captured in this quote. Write a specification, develop the product, test to the specification....wait that sounds like Waterfall technique. A major compliant I have had with the current stare of quality assurance is that it prevents (or at least stifles) creative solutions to issues that appear mid-stream. It seems that the agile process actually embraces this concept. The idea that test development flows in parallel with an iterating design seems to make this possible.As will all new ideas, there is almost always a bit of truth in there somewhere (of course that is true of cults also).
No comments:
Post a Comment