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.
The Lennon parody in the wikipedia link is a hoot. I give it a 10.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I have been a huge fan of Peter Schuh since his first book so when this came out I quicky snatched it up. After the first chapter I was already quite dismayed with it. First I have to say that the quality fo writing is sub standard, I had grown to expect a certain degree of quality fo Schuh but found this to be lacking. I even found a couple of spelling mistake (which is saying something considering i can spell horese) in the first 100 pages.
Style aside the substance is terrible. If I actually tried to implement the testing and development enviorments that he suggest my boss would first fire me and then run me out of town for ruining his company.
The most frusterating was chapter 4 where he actually does start to touch on something that could be useful and definetly had merit but he doesn't finish the idea and leaves the reader frusterated wnating more. That could have used a book all on its own.
Avoid this book at all costs.
Be better in bed. Wikiafterdark!
Some of the best days of my Software Engineering class were spent doing an Xtreme Programming assignment with a cute female chick as my partner. We earnestly spent days with her looking over my shoulder while I showed off my l3tt c0ding skills.
She even thanked me for the 95 we got in that assignment.
Aah, eXtreme programming....the best software engineering methodology for geeks.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
in soviet russia, government parodies you!
This caught my eye (additional emphasis mine):
Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand
Someone needs to update that article with a nice link to this article.
I have read both this book and Agile Software Development, Principles, Patterns, and Practices by Robert Martin, and must say I prefer the latter. Martins book is better written, does a better job of explaining the strengths and weaknesses using some well choosen case studies. Martin is also the author of the well known (well, in some circles :-) ) Designing Object-Oriented C++ Applications Using the Booch Method.
Please login to access my lawn
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.
working link
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.
Just to point out to , Parent Really is missleading , seems informative but is not.
Agile is a style
Bob Abooey? Is that you?!!!
It's been posting the same bloody troll since 1999!
Please help!
I've been using Agile for years, and I love its excellent debugger. Not to speak of the highly optimizing compiler.
I don't know about the book but this guy is obviously a troll. If you do a search you'll see that this is the author's first book. And the post doesn't actually reference any content in the book. Way to go mods, you got suckered by a troll who's slightly more creative than average.
The ones about bullshit?
Awesome.
Only one makes eggs.
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.
This is the author's 3rd book, check amazon. He is just trying to troll himself.
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
I WISH agile programming would catch on where I work. The big thing taking hold here now is TSP (Team Software Process), the most top-heavy methodology I've ever seen inflicted on developers, and I've been writing software for nearly 30 years.
Example: the process dictates doing a manual code review individually and in a group, BEFORE COMPILING, to look for things like missing semicolons and other routine errors that the compiler would catch all by itself. If you've done your reviews right, then the code should compile the first time without errors.
Seems like I've heard all this before. Like around 1978.
In OS X it's called alias. Look in the file menu while in the finder, drag the alias to the desktop. There are other faster ways such as holding down command+option while dragging it as well. Also in the mac world, most people don't put apps on their desktop. If they want something quickly accessible they use the dock, otherwise they just go to the applications folder. If you really have a lot of programs you might want to build your own folder tree to categorize things like I do. If you want a "start menu" then drag that folder into your dock and right-click/ctrl-click on it when you want to use it.
Here are a few "features" of AP...
In short, AP is fast and saves money in the short term, but costs much more (in maintenance costs) in the long term. It's great for the initial developers, but hell for anyone who comes in after.
AP is the same as development using CMM level 1 (or zero sometimes) methodologies. (and there is no level zero)
As a mac user I have found a lot of Windows users are snobs when they find out you use a mac, they come off just like you, assholes who don't know what they're talking about.
There's nothing wrong with someone being excited about their new machine, I see PC users bragging about how nicely certain games run.
Apple's ads pompous? Dude, they're just trying to target people who don't know much about computers. Think about it, what else does Apple have to advertise? Ghz? (which mean very little), Computability with games?
The only thing they can advertise to get users who are clueless about what all those specs mean is: "This machine works better than Windows, is easy to use (you don't have to be a computer geek to use it just because it's based off unix), and we try to make it fit well into a home environment (believe it or not, some people really value having a machine that runs quietly and doesn't look like an eyesore in your living room).
Stop being a snobbish anti-Apple AC and try to see the reasoning behind Apple's business model, SURPRISE! A corporation needs money to survive, you don't think Apple is going to let this chance to not 'die' (as they were doing for so long) slip by do you? Be happy that they at least have the innovation to make up for any 'snobby' business tactics they make.
Test-driven development is a good thing. Every self-respecting developer should write unit tests for his own code, and release it to test in a functional form.
Everything else in agile development methodologies is a bunch of horseshit, I'm afraid. 95% of software development problems would be solved by having good, descriptive, well thought out specs. So that developer wouldn't have to guess what the heck program manager meant by this and that.
My point is, development is usually good enough given clear, coherent specs as an input. You can't improve the product just by imposing an artificial work routine on developers. You need to get some good PMs first and foremost.
As part of a team which has quite successfully used XP:
It sounds to me like there was some misconception about the processes and principles surrounding XP here. XP claims that out of the four following variables of software development, only one is generally variable:
- Length of project
- Budget of project
- Code Quality
- Scope of project
The length and budget of a project are often fixed, and developers should not be required to sacrifice code quality. Therefore, the scope of the project is where one can gain the most flexibility.
Part of being able to change the requirements each and every day is that priorities will get shuffled around. This means that some "requirements" will fall off the end of the project in favor of other features, or changes to already implemented features. The customers I work with are greatly appreciative of this power.
I would say that if a project is going "over time" or "over budget," then the client and developers are not working together well enough to determine what will provide the client with the best business value.
As for estimates, we generally work under the assumption that estimates are not promises. That's even why a developer is supposed to give an estimate quality. So I could say... hey client, this looks like it will take a day, but my estimate is a shot in the dark. Thus, the client knows that it might take three days instead, and prioritize it accordingly.
In return, the client is supposed to leave the technical decisions to the developers (like, for example, when to refactor chunks of code). Some customers understand this, and some need help in order to do so.
Anyway. XP probably isn't for everyone. Some people like the process, some don't. I'm not going to claim it's the *best,* but of the approaches I've taken, I haven't found a better one. If you're curious, yes. My team does work on both large and small projects, and XP seems to work equally well.
Above all else, remember that XP preaches local adaptation, rather than the blind following of procedure. But if it stops being agile, then you're not really following XP.
If you have more information that you'd like to provide, it would be interesting to hear about the details (if you can give them) of your "failed" projects.
You wouldn't even begin building a house or making a car...
And this is where s/w specifically differs from other engineering processes. You are not making exactly the same thing over and over again. Or 'finishing' and walking away after a few months. The trouble with waterfall style development is that the description is never complete.
How many s/w projects out there ever finish? Linux? Windows? OpenOffice? Firefox? Have any of these finished? What complete spec. for all of those existed before the developers started on the project? (I bet next year's salary the answer is: None). And were all of these offerings utter failures? Even Sir Billy Gates KBE could modestly claim some degree of success... Now show me a completely specified project that is/was as successful as any of these.
Did he inhale?
Spelling should be
pensioned off... it terrorises human beings from birth." - Gabriel Garcia
Marquez.
ps
if you were shot in the head - you might be happt to be alive only complete twinks think spelling is important
Back when I started programming it was flow charts and "top down programming". I did neither, I visualized what the program was going to do. Then eventually it was UML and specing the hell out of everything as though you where a government contractor. I still visualized was the code and data structures where going to do. Then extreme programming, tomorrow who knows what they will try to shove down our throats. Stop worrying about the latest "way you have to do it". Go out and hire people who have a history of getting good software written, and let them do it the way it works for them. Hint, you will have alot easier time hiring good people if your not trying to cram some silly academics theory down there throats... Programming isn't a science its an art.
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.
The telephone game only applies when there's no redundancy, no verification of transmission, and mindless repetition of received transmissions. On an XP team, everybody's in the same room and talking, over time, to everybody else. If I hear one thing from one person and one from another, I'll grab 'em both and we'll work it out.
Often we do that by turning to the product manager, who sits in with the developers so that they can provide immediate answers to things that would indeed otherwise turn in to telephone-game nonsense.
Why have people started calling it eXtreme Programming? This seems about as lame as referring to Micro$oft. Have a look at the Extreme Programming website. Nowhere is the cheesy capitalization used, unless you count some graphic design on the book's cover.
-- Ed Avis ed@membled.com
Those who can't, teach! Good for him.
I guess I interpreted that particular phrase a little differently. I don't subscribe to a particular methodology (XP, Agile, etc.) but I've been a part of good and bad projects. Just in general, communication is one of the most important keys to a successful project. The idea that you can simply "pass words from man to man" is dangerous - if that is what they're saying.
Let's re-word this a la Imagine...
Imagine there's no client
No specification sheet
Just a manager's perception
From only one project meet
Chorus:
Imagine all the mistakes
Happening throughout...You-hoo-hoo...
You may say we don't need graphs
Or diagrams
I hope some day we can get this done
Without having to re-do half of it
The idea that you can simply "pass words from man to man" is dangerous - if that is what they're saying.
That idea alone is indeed dangerous. In the context of the other XP practices, it works very well.
Let's re-word this a la Imagine...
Yes, if people did as you imagine, it would suck. Fortunately, that's not what happens on a good XP project.