Thursday, February 23, 2006

Agile Modeling

I just received the best newsletter ever, about Agile Modeling. I've been receiving this newsletter for a long time now, but reading this issue reminded me that, though I use the technique myself, I haven't said an awful lot about it. If you don't know what agile modeling is, you should rush right over to agilemodeling.com and learn something useful. The website starts with the following definition:
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.
Boiling it way down, it's developing in iterations; keeping your requirements for each iteration light; engaging your stakeholders throughout the development cycle; keeping each iteration short; and delivering often. If you've worked with me before you know that this is what I mean when I talk about taking care of your "major pain" first.

Another way of looking at this is that you should deliver the minimum amount of software that can reasonably be expected to work well... then flesh out the major shortcomings, then flesh out what's left, until there's nothing left worth fixing. A lot of IT managers would balk at a policy like this ("What do you mean, deliver the least we can get away with!?"), but think about it. Custom software is not commercial code. It's development should be driven by your needs, not by some imagined market pressures. Your major pain (or need, or "itch") really is dragging down your business... why would you suggest putting up with it for a day longer than necessary? Instead, you fix it quickly, efficiently, and cheaply. You engineer the cure to be flexible and extendible, but you focus your attention on the pain. Once you've fixed it, it's no longer painful, and you focus your attention on the next major pain. The end result is that at a point in development where "top down" designers would still be talking about the problems, agile stakeholders are using the solutions.

My sons' high school has a motto that describes this best:
Do your best; then do it better.
I couldn't agree more. That said, the reason that this particular newsletter was so interesting to me was that it thoroughly answers two questions I'm often asked: what is it I am... what's my title? Relax, I know the answer, it's just that I now have someplace to point people for a better explanation. Here it is. And while you're poking around, read this article for a nice continuation of getting your requirements right.

Stop the Presses

It was pointed out to me as I was drafting this that this "agile modeling" thing is flatly at odds with both the systems development methodology on my website and the concepts of Function Class Decomposition (FCD). The short answer is, NO IT ISN'T. Agile programming affects two things more than anything else: scope and documentation.

It affects scope because you're accepting that you'll solve a more limited problem two weeks from now rather than try to solve everything a year from now. Rather than a project in itself, an IT system becomes a product that is subject to versioning. But each version (iteration) is a small project, subject to the same principles of good project management as bigger ones. The big difference is that these successive smaller projects are more manageable and cheaper to produce, with more immediate impact. Whereas with larger projects "scope creep" or "feature creep" can become devastating, this iterative approach of focusing on your pain can greatly reduce creep. By the time the really significant issues have been dealt with, your stakeholders may decide that the remaining issues are just too inconsequential to deserve additional funding.

It affects documentation in that you really need to find new and more flexible ways of documentation. Heavily commented source code is good; and a good way to start with that is to pseudocode first (100% comment lines) and then flesh in the pseudocode with actual code; that way your intent and your execution are documented in the same source file. Keep meetings informal. Document issues in a shared database or discussion group. Document them in email, but cc: a Notes mail-in database. Document no more or less than is necessary. But there's one piece of documentation you cannot skimp on... your initial scope document, signed by the stakeholders. Your requirements may be refined in the face of reality, and you may have to adjust your design as you go, but you should always keep your eye on the prize: that core set of functionality you're contracted to deliver.

As for FCD, it's not affected at all. As you go through new iterations, you take the same old functional model you had at the outset, Add new functionality (it's nice to diagram these in new colors), and analyze how it fits into the existing design. You still look at your opportunities for re-use, except you now have the benefit of having actual classes to deal with. Describe any new classes that will deliver the functionality. Then you implement the functionality from the bottom up, only having to deliver those components that don't pre-exist and limited modifications to those that do.

0 Comments:

Post a Comment

<< Home