Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Integrating Agile Development 121

Posted by timothy from the smoothly-smooshing dept.
James Edward Gray II writes "If you've ever wanted to know more about the agile programming methodologies, Integrating Agile Development in the Real World is a fine place to look for the answers to your questions. Various agile methodologies are explained, compared, and contrasted within. A good look is taken at how they work, their strengths and weaknesses, and how they compare to the more traditional approaches of software development. This proves to be a strong introduction and overview to agile programming practices." Read on for the rest of Gray's review.
Integrating Agile Development in the Real World
author Peter Schuh
pages 346
publisher Charles River Media
rating 8
reviewer James Edward Gray II
ISBN 1584503645
summary An encyclopedia of agile software development practices.

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.
This discussion has been archived. No new comments can be posted.

Integrating Agile Development More

Integrating Agile Development

Comments Filter:

  • Hardly ...its a really terrible book!! (Score:4, Informative)

    by moofdaddy ( 570503 ) on Wednesday March 02, 2005 @03:12PM (#11826600) Homepage
    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.

  • Somewhat offtopic but... (Score:5, Funny)

    by GillBates0 ( 664202 ) on Wednesday March 02, 2005 @03:12PM (#11826603) Homepage Journal
    As long as we're talking about XP...

    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.

  • better book (Score:5, Informative)

    by carnivore302 ( 708545 ) on Wednesday March 02, 2005 @03:17PM (#11826639) Journal
    I have read both this book and Agile Software Development, Principles, Patterns, and Practices [amazon.com] 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.

  • the plan (Score:4, Insightful)

    by achacha ( 139424 ) on Wednesday March 02, 2005 @03:18PM (#11826645)
    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.

    • Re:the plan (Score:5, Funny)

      by 0racle ( 667029 ) on Wednesday March 02, 2005 @03:31PM (#11826762)
      "What exactly do you do here?"
      "I deal with the god damn customers so the engineers don't have to! I HAVE PEOPLE SKILLS! Can't you understand that, I AM GOOD AT DEALING WITH PEOPLE! WHAT THE HELL IS WRONG WITH YOU!"

    • Re:the plan (Score:1, Insightful)

      by Anonymous Coward
      It's a lot easier when you're doing internal business applications, which seem to be overlooked most of the time...

      The majority of the applications I work on are for my business partners who want to cut the red tape as much as me and my managers.

      Finding a happy medium for producing fast/complete applications while making them supportable for the next 20 years without spending months trying to document and work through processes would be a God-send.

    • Re:the plan (Score:1, Funny)

      by Anonymous Coward
      "So you physically take the requirments from the customer and give it to the developers? Couldn't the customers give the requirements to the developers directly?"

      "Damn it! I HAVE PEOPLE SKILLS!"
    • The most convincing argument you can make is that you are losing customers in droves to a competitor who delivers more effective software. Of course, by then you are well on your way to out of business.

      Your case to make then, is that it would be better for your marketing people not to have to find work at a new company when yours goes out of business, and that they can do that by allowing the development team to deliver quality software.
    • you make the marketting guys the SCRUM Master.

    • 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.

      Quick tip: what to make isn't a technical decision; it's a business decision. HOW to make it is the domain of us techies.
      • Knowing what the requirements are is important. We techies are usually quite intelligent and can understand what the customer wants. The big problem is that 'what customer wants' gets translated by the sales/marketing to 'what I think we can deliver that customer wants' and sales/marketing people are not techies and do not know what is possible and what is not. We techies can work as sales/marketing, but not vice versa.

        I remember working for a company where we had a full suite of products and I would of
        • Sorry, I guess my quick tip was too quick.

          I agree completely that we techies should collaborate vigorously. I also agree that letting salespeople control the product plan, especially when they arbitrary schedules based on their own fantasies, is a mistake.

          But I disagree that techies are qualified, simply on the basis of raw intelligence, to make business decisions. A good product manager is just as smart as the programmers. There's no reason to think they could step in and dictate development, just like t

  • A big stumbling block... (Score:5, Insightful)

    by Zangief ( 461457 ) on Wednesday March 02, 2005 @03:28PM (#11826731) Homepage Journal
    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.
    • You just define your process to exclude the documentation.

      CMM and ISO software standards have little to say about quality in the conventional sense (i.e. a particular product does what its supposed to and does so for a reasonable time). They're all about an organization's processes consistently applied. No useful output is required.
    • This was the first thing I said to a good friend of mine who is an Agile Progject Manager. Her reply which is utterly graceful in its simplicity: test cases are your documentation. When the code you write gives you the results you expect in testing, you're done. Anybody who later wants to enhance the code (assumably the same group who wrote it the first time but theoretically any Agile dev(s)) should be able to take the test cases, determine what's going on, build NEW test cases based on the expected res
      • To say that Agile development doesnt' include documentation, or that you can't do documentation in an agile development process is simply incorrect.

        While Agile programmers certain like to avoid documentation (http://www.martinfowler.com/distributedComputing / thud.html), if such documentation is a user requirement, than deliver it.

        The key is helping the user understand what they are paying for. When the user begins to understand the cost of documentation, and 'documentation maintenance' when the code bas
      • I think the idea that tests are the documentation is flawed because prose documentation is helpful and reading code causes people to make assumptions. Not one Java developer I know gets his or her daily work done by looking at the JDK source code. They all read the Javadocs. Rarely do test cases cover the entire breadth of functionality; when people refer to the implementation code for how something works, they will make assumptions that leak out into the code they write. While I do find it unncessary to wr
        • I think you're missing the point. There is no test code. Gathered requirements become test cases and the (production) code is built to pass the tests. Peer review within the team working the project prevents crappy code from making the release b/c an Interation Manager enforces coding standards.

          Coming out of a "traditional" waterfall style of iterative development it can be a bit dificult to wrap your brain around it, but it does work.
          • What you're describing is even more flawed. Enforcement of code quality solely through person management is doomed to failure. Automated builds with integrated unit tests are mandatory. Use cases are high-level; they do not document how an API works.
      • I personally don't buy into the whole XP/Agile methodology, but I do think that they're on to something with their test-driven approach. Of course, what they're on to is getting back to actually writing real requirements, instead of the fluff that passes for requirements documents these days, but that's beside the point.

        Ultimately, requirements are supposed to define what the customer will consider an acceptable product. Too often what they end up being is a bunch random features which may or may not actual

        • You've hit the nail on the head here re: testing having the capability of making documentation come alive.

          For eg, a typical requirement specification document is a bunch of unchanging bytes that says stuff like: "the system must do blah". There is no sync-ing of this dead document with the oft-shifting ground reality of the codebase it purports to document. The situation gets a bit better with API documentation, but it is still a problem.

          Instead, if after saying "the system must do blah" , imagine a litt
      • This may seem like pie in the sky and "hardened" devs are sure to line up telling me it never really happens that way. However, I know for a fact that it does.

        Having tried Extreme Programming, I can testify. On a recent project, we had pretty much 100% test coverage. After 36 developer-months of happy construction and no formal QA, we released to the public and have had a total of 2 bugs in production and zero downtime in the five months since launch. The CEO, a Silicon Valley veteran, said he's never see
    • Remember that the documentation can just be a task that the customer schedules, knowing that it has a cost just like any of the other development.

    • In these days of forums and /. do we really need documentation?

      Well, maybe a browser or a modem may need some... a bit hard to get onto the forums without those!

    • There is no agile way of producing this documentation.

      XP teams have been blessed up to CMM level 3 with only minor additions. See the papers from Agile conference proceedings (and also from CMM people like Mark Paulk) for details.

      There are indeed plenty of relatively agile ways to produce necessary documentation. It's the unnecessary documentation, the stuff that nobody ever reads, that agile methods tend to leave out. But I'd say that leaving out pointless work is a process feature, not a process bug.

  • Extreme Programming Installed (Score:4, Insightful)

    by mindpixel ( 154865 ) on Wednesday March 02, 2005 @03:55PM (#11827036) Homepage Journal
    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.

  • Agile programming is great (Score:2, Insightful)

    by Anonymous Coward
    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

  • My experience with eXtreme Programming != good (Score:4, Insightful)

    by Morpeth ( 577066 ) on Wednesday March 02, 2005 @04:07PM (#11827285)
    I don't know if it's the people managing the projects (I'm a developer, most of my experience is in the financial & mutual fund industry) -- but in the two places I've worked that were into XP, things always went late, over budget and the apps tended to have a lot of bugs or needed reworking.

    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 ?

    • 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.

      It always is. If you're using XP and it doesn't work out, it's because you did it wrong. Just ask any XP zeal^H^H^H^Henthusiast.
    • 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
    • perhaps their way of doing XP was flawed

      That's a reasonable theory. It sure doesn't sound like my XP experiences. Perhaps you can tell me more about how they did XP.

      felt like I was often having to interpret and 'guess-timate' a lot.

      Extreme Programming requires an on-site product manager. Why would you have to guess if the guy who can decide is ten feet away? And if the product manager was, as XP recommends, defining the acceptance tests, where was the room for mystery?

      the apps tended to have a lot
    • One of the tenets of XP is to have a customer representative available all the time. To avoid "having to interpret and 'guess-timate' a lot".

  • Greetings from TSP Hell (Score:5, Interesting)

    by serutan ( 259622 ) <snoopdougNO@SPAMgeekazon.com> on Wednesday March 02, 2005 @04:17PM (#11827480) Homepage
    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.
  • ...when you are the one to support and maintain the system developed using Agile Programming.
    Here are a few "features" of AP...
    • bad or no documentation
    • unstructured code
    • varying methods (of doing anything...I do not mean methods in the OO sense)
    • bugs bugs and more bugs to fix
    • did I mention documentation? Oh, just read the code to find out what it is "supposed" to do.

    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 t

  • 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, co
    • 95% of software development problems would be solved by having good, descriptive, well thought out specs.

      If you ever see one of these let me know.
      • And that's exactly the problem. You wouldn't even begin building a house or making a car without full and complete specifications. In software development you're expected to make shit up on the fly, and then they expect quality out of whatever you produce. Not just that, but the schedule usually allocates 30% less time for development than needed, so you either have to bust your ass, or release a subpar product.

        How does agile development address these issues? That's right it doesn't address them.
        • 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 t
          • 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 s
        • Perhaps I misunderstood your point, but here is my answer:

          In XP (I realize that there are other agile methods), the client is supposed to be on-site. Thus, the client can answer these questions whenever they come up. I realize that not all clients will want to spend their days sitting around a bunch of developers, but believe me when I say it actually helps quite a bit. Have you found otherwise?
        • You wouldn't even begin building a house or making a car without full and complete specifications.

          We don't build software. Compilers build software. The specifications are written using code. Compilers can't build software without a strict specification. We, the developers, develop that specification. We take requirements and we develop software based on those requirements much like a house or skyscraper developer does. A house developer may draw you a picture or create a model and ask the customer, "do
    • The problem is that rarely (if every) there is time to develop proper specs, plan out the development, and get it done on time and budget, and these methods at least attempt to apply some manner of structure to the development process. I'm not saying that I necesarily agree with using these models, but the fact of the matter they're a necesary evil. Personally, I prefer a modified version of the prototyping model, as that applies best to the kind of work that I do.

    • Re:Agile development is a bunch of horseshit (Score:1, Informative)

      by Anonymous Coward
      The guys at Software Reality already went over this

      http://www.softwarereality.com/lifecycle/xp/case_a gainst_xp.jsp [softwarereality.com]

      They even have a book on it now

      http://www.amazon.com/exec/obidos/tg/detail/-/1590 590961/ref=ase_softwarereali-20/104-8363309-843276 6?v=glance&s=books [amazon.com]
    • > I'm afraid. 95% of software development problems would be solved by having good, descriptive, well thought out specs.

      yeah, that's the problem: requirements gathering is the most failure-prone activity in software development.

      Waterfall methods approach this problem by generating pallet-loads of documentation, and having everyone and their brother (theoretically) review the paperwork. This of course almost never happens. When it does happen it's almost impossible for the users to visualize the syst
    • There's less HS in there than you think.

      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 th

      • "Specs are not a substitute for the customer."

        Yes, and the customer is not a subsitute for a spec. Ideas are written down for a very good reason: people are not capable of remembering a large amount of detailed information in their heads.

        If you have an infinite amount of money to burn, you can rewrite the application every time the customer's recollection of the requirements changes, otherwise you'd better have a spec.
  • 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
    • I agree that good people are critical Unfortunately, 1)good people leave, move on to other projects, or get bored 2)The best people are not always easily available, reality is you will have a mixture of A's, B's and C's 3)Many systems are too complex to not model at least somewhat. You don't have to fully adopt Model Driven Development, but some code visualization is important In the early part of development software is more art and engineering. After you have an architecture, it becomes more science. So

  • Does anyone else think... (Score:3, Insightful)

    by gidds ( 56397 ) <slashdot@NospaM.gidds.me.uk> on Wednesday March 02, 2005 @08:42PM (#11830169) Homepage
    ...that the problems start the moment you start calling something a 'methodology'?

    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.

    • Generally that's what "agile" says. Instead of jumping through a rigid set of hoops to prove that you can jump through hoops, the body of agile talks about how to take various proven practices and apply them to your situation.

      For example, Beck's second edition of Extreme Programming Explained talks more about the underlying principles and values than specific methodology implementation details. Most agile proponents recognize that no single approach works for all shops, or even two shops.

      -J-
  • Those who can't, teach! Good for him.

Slashdot Top Deals

"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud

Close