Slashdot Mirror
Integrating Agile Development
The book opens with a couple of chapters exploring exactly what it means to be an agile development team. The author doesn't spoon feed you a definition. Instead, he takes a look at the Manifesto for Agile Software Development and pulls from that a collection of values important to agile software development. A list of agile principles is presented, and each of these aspects is examined from the angle of what it's trying to accomplish and where it can help when building software.
At this point, the book introduces seven methodologies including The Crystal Methodologies, eXtreme Programming, and Scrum. Each approach is defined by their practices and focus. The author does a nice job of telling you where these methodologies excel and even where they don't. The approaches are contrasted, but not with an eye towards finding out who is right and who is wrong. Instead, the author digs for the strengths in each practice.
The next few chapters offer suggestions about what agile practices can do for your development team, and outline how to adopt a few agile practices. This is one of the many places where the book really shines, thanks to its realistic approach. The author knows that not everyone can run out, soak up some eXtreme Programming training, and convert their entire division overnight. If you can, great, but this book is more focused on people who don't meet certain agile requirements and others who just want to test the waters a little. For these groups, there is sensible advice like, "Start by doing X, Y, and Z, because they're great ideas, easy to implement, and will help you a lot." If you like those changes, the author suggests what to try next. Even better, you're told to back away from the changes you don't like, sprinkle in some ideas from other methodologies, and even customize the practices to your needs. That may not be as extreme as some agile developers would prefer you to be, but it is agile programming distilled down to what it can do for you personally. I found that to be a great touch.
With the introduction to this new world of software development covered, the book moves into detailing actual agile practices. Early chapters in this section focus on the programmer, testing, and even the database side of the operation. Later chapters get into management, the project, and an agile development cycle. When a practice is defined, you're warned of prerequisites you should have in place before considering it, offered advice for how to get started with it, and even given a few variations that might work better for your group. I wouldn't say that the detail here is sufficient to teach you all you need to know, instead this section arms you with the knowledge to decide what you should be looking into. To kick-start your research efforts, a practice always ends with a list of further resources, available both online and in print.
The final chapters of the book get more abstract, dealing with customers, communication, and even just people. There's a lot of sound advice hidden away in these pages for some difficult challenges. I personally learned a lot about how agile development deals with customers and I have a few new ideas I'm anxious to try on my clients.
As an added bonus, the book has a very nice layout, filled with intelligent, witty prose and good looking charts. These effects are always subtle but can make a text a lot more approachable. I believe my only complaint was that the author tends to throw around acronyms assuming you know what they stand for. I think he even eventually got around to defining all but a couple, but not always when you first encounter them. A glossary probably could have helped in this case.
In summary, this book is agile programming for everyone. As a one-man operation, common practices like pair programming aren't even an option for me. The author knows that the methodologies aren't one-size-fits-all, and really focus on exactly what they can do for you, whatever your own needs may be. If you don't follow any development strategy (hope that's not true), would like to know more about the agile practices without joining a cult, or even just want to stay sane in your traditional software development company, Integrating Agile Development in the Real World will give you plenty of fresh ideas.
You can purchase Integrating Agile Development in the Real World from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Sounds great but how do you convince the sales/marketing/business/management types that it is better to deliver a working product than to syphon money from a customer, deliver something barely resembling what they requested and then charge them more to improve the product to meet their "new" needs.
Most developers can make software that the cutomer wants if they actually talked to the customer, but sales and marketing people somehow think that developers don't have perople skills to deal with customers... it is a sad world when someone with a business degree tries to make a technical decision.
Documentation.
Most big enterprise require loads of (normally useless) documentation. If your client is into CMM or any ISO standarization this is even worse.
There is no agile way of producing this documentation.
If you are interested in doing agile development, another interesting book is Ron Jeffries, "Extreme programming installed"...Here's my May 2001 amazon review of it:
People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968.
This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.
Once I understood the basic concepts, it was a real eye-opener. Wow, just write what you need, and use lots of tests so that it's easy to add new stuff later without breaking everything. Write your code simply so it's easy to read, refactor all the time so your code stays nice and beautiful and tight.
But that's it really. You don't need more of a paragraph to explain it. Any smart programmer, once explained the basics, should understand in an instant how it can help them. Then the thinking spreads into the rest of your project, into your project management, into what tools you use, etc.
I bought Chromatic's little Extreme Programming pocket guide (O'Reilly) and that told me everything I needed to know (yeah XP is just one way to be Agile but the basics are there).
Just the idea of "not programming ahead of the requirements" clicked in my head right away.. "you mean.. I don't have to flex my uberprogramming skills on every project? I can just do what they asked for and then add more when it's needed?"
So I guess what I"m saying is, "Agile" is fast becoming a buzzword. Once it reaches buzzword status, people who could benefit from it start getting turned off.. "Teach Yourself Agile Extreme Programming in 10 Minutes By Example For Dummies" REAL programmers don't buy books with those kinds of buzzwords in the title, right?
So just pick up the O'reilly XP pocket guide, poke around on the interweb, and remember that "Agile" is just "software best practices".. the ones you're not doing now but inside you know you should.
My biggest issue was not having well-defined user specs and documentation to work from. As much as I consider myself a generally bright person, and a decent listener - I felt like I was often having to interpret and 'guess-timate' a lot. And it's frustrating for a team to be in the hotseat when there's no document saying 'it says right here, you promised X by date Y.' It seems too loosey-goosey imo.
Now granted, I'm not 'up' on XP, I'm only commenting on my experience with orgs that claimed to be implementing it -- perhaps their way of doing XP was flawed. But for all the talk about rapid development and the sort of hip mystique around it, I didn't find it be a time or money saver.
I think traditional 4 stage life cycle development tends to work in my exp. Perhaps it's because I've been involved in larger financial apps w/ lots of business rules/reqs, where you just can't afford f-ups, people get understandably upset if you screw with their money.
I'm curious is XP 'sold' as working on large apps, or is it really most suited to smaller projects, and/or minor enhancements to existing applications ?
'The unexamined life is not worth living' - Socrates
To my mind and experience, the greatest benefit of Agile methodologies is that all of them put a premium on communication. Many of the practices (pair programming, on-site customer, etc.) are aimed sqaurely at fostering communication between team members.
Test-driven development is a good tool and because it's one that's easy for programmers to understand, it's usually the first Agile practice to get adopted. However, I don't think that it's the only (or even the most) valuable one. I can do good work without formal unit tests, but I can't do good work without an on-site customer who can answer my questions as I write code.
A word about specs. Specs are not a substitute for the customer. Read that last sentance again. Print it out, frame it and hang it on the wall. You shouldn't be writing to satisfy the spec, you should be writing to satisfy the customer. My experience with detailed specs is that they only work for well-known problems with limited scope.
My experience here is limited; I've never done any proper XP or similar. But I've read quite a bit about those sorts of development practices, and used a few others (all the way back to Jackson Structured Programming), so I hope my intuition isn't completely out here.
My feeling is that just about all of these practices work much better as tools and tactics, to be chosen from and used where you feel they work and then dropped, rather than as part of a rigid methodology.
Management tends to want to treat development as a predictable, join-the-dots process -- and many methodologies seem to reduce it to that. But they don't! They just hide the creativity and unpredictability where it can't be seen. IME, a rigid methodology just gets in the way of good developers, and gives the bad ones something to blame...
So use some of these techniques and ideas, by all means: it looks like they can work very well. But don't treat them as the be-all and end-all of development. There's always a need for creativity and good judgement.
Ceterum censeo subscriptionem esse delendam.
Show me a house and garden that's ever "finished"...
If you regard something like Windows as a single project, then no, it's never finished - in the same way that a house is never finished bcos it gets redecorated/refitted every few years. It's more accurate to think in terms of multiple successive releases. And on those terms, a house and a piece of software are identical - you keep working on it until it's a good enough quality to sell.
A description of a house doesn't have to be complete, down to the size of screws used. But it does have to say what the house is going to look like and how it works (ie. structurally sound, and electrics and plumbing meet specs).
Same with software. If your requirements are "dude, we need a really *fast* tool to convert from this format to that format, and there might be a bunch of new fields you need to invent some values for", you're utterly screwed.
All the requirements do *not* necessarily have to be in place at the start. When building a house, the builders will likely walk the clients through when the floors are in, to fix the locations of pipes and electrical points. Similarly in software, you'll refine your requirements as you go along. The key thing in *both* is that you record what your requirements are, and check when you're done that your product is meeting those requirements. If you don't, chances are that your clients will be unhappy at the end, and you don't get paid (or don't get further contracts).
I also note that your examples all involve off-the-shelf desktop software. In this field you have to invent requirements beforehand, to try and predict what your customer's requirements are. This is not the case for most software projects - the majority of software developers are working on projects for customers who have some real requirement that needs filling. Even if they can't articulate it precisely, if what you give them doesn't do what they wanted, you don't get paid. And if it comes to court, you need to be able to show that you *did* produce what they asked for, otherwise it's your ass on the line.
Grab.