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

Agile Modeling 110

Posted by timothy from the cat-with-superglue dept.
RickHigh writes: "I've been waiting for a book like this. If you are doing software development of any kind, you should read this book. Especially if you are doing Extreme Programming and you errantly believe modeling has no place in XP. Or, your doing the Unified Process and you feel that your models and documents are more important than a working system, or you feel you are bogged down in documentation and required artifacts (more likely). Agile Modeling (AM) is a modeling methodology that enhances your modeling endeavors, whatever your process methodology inclination. Agile modeling will help you effectively incorporate modeling into your organization." Read the rest of Rick's review below.
Agile Modeling: Effective Practices for Extreme Programming and the Unified Process
author Scott Ambler
pages 400
publisher Wiley, John & Sons, Incorporated
rating 7.5
reviewer RickHigh
ISBN 0471202827
summary A worthwhile melding of XP techniques with modeling of general interest to programmers of all stripes.

The title is only partially accurate as the book covers a lot more than modeling. I know from experience that picking titles is tricky (you can't please everyone). You don't need to be a UML expert to get value of this book. Any software developer should be able to appreciate it. Modelers, software developers and Yes, managers will find this material useful. In fact you may want to buy a copy and put it on your manager's desk. This book is original and well thought out. It is also well written and very readable. I wish there were more examples of applying the different artifacts in different phases of the XP life-cycle, but there has to be room for the next edition. The depth is appropriate.

Many UP developers (and those working with other prescriptive processes) get bogged down in the tonnage of documents and artifacts that are required. They wonder if they are ever going to have time to actually write the code.

XP offers a methodology for building high quality software fast. However, many XP developers, and I've spoken to them about this very subject on many occasions, find that XP does include time to do models. This books shows how to integrate XP and modeling.

This book sets the record straight about design and Extreme Programming. Actually, Kent Beck set the record straight with the first book on XP when he said 'In the time it would take you to code one design, you can compare and contrast three designs with pictures.' Kent Beck's views were corrupted over the years for various reasons that Agile Modeling explains, as it clarifies once and for all the relationship between XP and modeling.

The book emphasizes that you should model to understand the problems and only apply the right artifacts, i.e., that not all modeling must lead to writing code.

Despite the title, he AM book transcends just being a book on modeling; the book covers many aspects of developing software. Agile Modeling endeavors to be real. By real I mean it talks about real issues and how things are handled in the real world, not the perfect world covered by most books. For example, the chapter on documentation is an excellent coverage of the subject, but not idealized beyond all usefulness.

Like the original XP book, the AM book lists values, core principles and practices. It also adds supplementary principles like 'Content Is More Important Than Representation.' A key lesson from the book is that models are important if they help you understand and solve problems. And, models do not have to be perfect -- in fact they can be thrown away when you are done with them. After all is said and done, 'Software is your Primary Goal.'

The author, Scott Ambler is the author of numerous books (and by numerous I mean a lot) for the Unified Process, and UML. He also contributed to the Mastering EJB Book, and the Java Elements of Style book. All his work in UP seems strange since AM seems to have closer ties to XP than UP, but that is probably my own warped misconceptions of the world. Bottom line, Scott has mastered the craft of writing and I really enjoyed his writing style. The first few chapters seemed a little slow, probably because their content has been covered before in other books. The chapters on AM and XP, though, were informative and useful (as was the chapter on agile documentation mentioned earlier).

If you are doing software development of any kind, you should read this book. It is an informative and enjoyable read.

What's covered? Here are the chapter headings:

  • Table of Contents:
  • PART I: INTRODUCTION TO AGILE MODELING.
    • Introduction.
    • Agile Modeling Values.
    • Core Principles.
    • Supplementary Principles.
    • Core Practices.
    • Supplementary Practices.
    • Order from Chaos: How the AM Practices Fit Together.
  • PART II: AGILE MODELING IN PRACTICE.
    • Communication.
    • Nurturing an Agile Culture.
    • Using the Simplest Tools Possible?
    • Agile Work Areas.
    • Agile Modeling Teams.
    • Agile Modeling Sessions.
    • Agile Documentation.
    • The UML and Beyond.
  • PART III: AGILE MODELING AND eXTREME PROGRAMMING (XP)
    • Setting the Record Straight.
    • Agile Modeling and eXtreme Programming.
    • Agile Modeling Throughout the XP Lifecycle.
    • Modeling During the XP Exploration Phase.
    • Modeling During an XP Iteration: Searching for Items.
    • Modeling During an XP Iteration: Totaling an Order.
  • PART IV: AGILE MODELING AND THE UNIFIED PROCESS.
    • Agile Modeling and the Unified Process.
    • Agile Modeling Throughout the Unified Process Lifecycle.
    • Agile Business Modeling.
    • Agile Requirements.
    • Agile Analysis and Design.
    • Agile Infrastructure Management.
    • Adopting AM on an UP Project.
  • PART V: LOOKING AHEAD.
    • Adopting Agile Modeling or Overcoming Adversity.
    • Conclusion: Choose to Succeed.
    • Glossary of Definitions and Abbreviations.
    • References and Suggested Reading.
  • Appendix A: Modeling Techniques.

Sites of interest

You can purchase Agile Modeling from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
This discussion has been archived. No new comments can be posted.

Agile Modeling More

Agile Modeling

Comments Filter:

  • I was just reading this at the bookstore... (Score:4, Insightful)

    by swagr ( 244747 ) on Tuesday May 07, 2002 @12:50PM (#3478007) Homepage
    My problem is that I'm working as an independant contractor. And many other people work on solo projects. Most of these systems (SCRUM, Extreme, etc.) are geared towards a group of developers. It's much harder when there's only one of you.

    What about techniques/systems for the 1 man show?

    • Re:I was just reading this at the bookstore... (Score:5, Interesting)

      by phallen ( 145919 ) on Tuesday May 07, 2002 @01:08PM (#3478121) Homepage
      While it is true that lightweight/Agile methodologies such as XP are based on the idea that communication is key, but there is another core value: discipline! There are many principles that any programer can use to improve their productivity, if your are disciplined enought to do them without a team of people keeping you honost. Here's a list of techniques I use as an XP guy when I'm working by myself:

      Test-First Programming: write some unit tests before your write the code they test. Then write the actual code and work on it until the tests pass; go back and write more tests. BTW: if you are saying "test-first programming doesn't work!" then you've never tried it, right? Tell me if I'm wrong.

      Itterative Development/Refactoring: always re-evaluate your code and look to make it better, easier to read and understand, and more modular. Develope in small steps that produce a working system quickly and often, even if the system doesn't do much at first. Big-bang development = Big-bomb development.

      Implement the simplest solution that will work: don't overengineer the system when you don't need to, even if you have some cool, but complicated, ideas. If you need a more elaberate solutions later, refactor it in.

      Deliver the most value-producing code first: give the users the thing they need the most first. Don't work on the coolest part of the system first unless it's the most valuable.

      Like I said, anyone can do these things if they are disciplined enough to do them, and you don't need a pair/team to do them, though it's easier.

      • I use IntelliJ IDEA which has insane refactoring. (I'm using the Early access preview which is even better that 2.5.2).
        As some book I read put it, "refactor ruthlessly". I do. I think that's my one saving grace.

        My biggest problem is that I over-engineer. Quite often I end up with a bunch of interfaces, abstract classes and implementations, where, in hindsight, something really simple would have worked just as well.

        Or I end up "bending over backwards" to create more re-usable objects that are never re-used.

        Object Oriented Overkill is my problem.
        • Overkill is fine as long as you do refactor. It's probably better to design too much and prune than to underdesign and bandage. In fact, I would go as far as to say that overkill + refactoring is a very strong programming practice!
          • what the hell are you talking about?

            Refactoring does not have to do with "pruning" your design (which I'm interpreting as making complicated designs simpler). It's actually the exact opposite -- It has to do with making a simple design more complicated, as needed.

            The whole idea is that you start off with simple designs (i.e. underkill) and then rely on refactoring to add in additional features later instead of trying to predict the future and making a too-complicated design at the start.
            • Man, I think you need to go back and read the book again.

              Refactoring has everything to do with making complicated designs simpler. And it doesn't have anything to do with adding in additional features (or taking them out, for that matter). I think you must be confusing refactoring with something else.
        • Maybe test-driven development may help keep you more focused on what you really need to code? If what you're writing doesn't help make your tests work, don't write it.
        • My biggest problem is that I over-engineer. Quite often I end up with a bunch of interfaces, abstract classes and implementations, where, in hindsight, something really simple would have worked just as well.

          Or I end up "bending over backwards" to create more re-usable objects that are never re-used.

          Object Oriented Overkill is my problem.

          Murphy's Law dictates that the project you stop doing this on will be the one that would really have benefitted from it. It ends up becoming superstition, a form of learned behaviour... I think you can tell that I'm afflicted with a similar mania. :/

          (However, I've been working under extreme time pressures recently, and for stuff that has to be done quickly rather than well -- this has forced me to loosen up a bit. Good, fast and cheap -- pick any two, and we had to opt for fast and cheap :)

          (BTW, I don't work for the organisation advertised in my .sig -- just a disclaimer in case people get the wrong ideas. :)

      • Test-First Programming: write some unit tests before your write the code they test. Then write the actual code and work on it until the tests pass; go back and write more tests.

        For me, what works so well about Test First Programming is that it strongly drives me. I have concrete goals, objective measurement, and even a built in reward system of sorts. When all else fails and I'm feeling particularly unmotivated, I write more test code, giving me more things to test.

        C//
      • I wish I could work with Mr. Phallen! He speaks the gospel truth.

        Unfortunately, for myself and others in similar predicaments, I work with managers who could really care less about the Zen of effective programming.

        Yes, I work for Corporate America.

        Where innovation is another word for "troublemaker".

        Where its not the quality of your work that matters but the size of your manager's budget and feifdom.

        Where great ideas are met with yawns and patronizing paltry interest.

        Where its not the technology that drives the boat, but the political connections and process.

        Where you have serious questions whether or not you work for Damien himself.

        Etc..

        • I have a fantastic manager, who equates "minimal change" with "minimal risk".

          So we never refactor anything, and if we're working in an area of code to add some new feature, it's forbidden to fix any old and long-standing bugs while we're there, even if doing so requires negligible effort and all of the relevant code is going to be completely retested as a result of the other work anyway. Never rework a sound design into another sound design when a smaller hack to the original will do.

          Sadly, I kid you not.

          • I agree a little bit with the manager. But I can also see how in certain situations he could be wrong.

            If you truly are completely restesting ALL the functionality, then by all means, bugs should be fixed. On the other hand, some piece of code in another module could be expecting buggy results from the piece of code that you think is simplistic to fix. So unless it's a bug in a self-contained routine, then fixing it may require more planning then "I have the source file open, so...".

            • The problem is, while I see the point of the "minimal change" doctrine, it can be taken to extremes. We are currently shipping what I deem to be crap, and needlessly so, because management is too anal about procedures and not enough about actually producing a quality product. (I'm not talking about bugs in core library routines used all over the place here, I'm talking about naff UI routines because someone was lazy, or a divide-by-zero that always goes off in the same place because it's not checked.)

              By the way, since they shifted my old boss onto another assignment, I am now the only person even remotely qualified to assess how risky any such change would be. The manager concerned wouldn't know his way around the code -- or even the overall design -- if I gave him a detailed map. I wrote much of it, and have in the past extended or fixed much of the rest. Draw your own conclusions about whose assessment of risk is most likely to be correct...

      • you've got some good ideas, but let me point out that refactoring time is often lost to time pressure. Many times, code that is "okay" or "not so great" is sufficient (depends on environment, mind you - an Internet startup looking to get a product out versus a contract software house doing MilSpec stuff) and it is more important to get on to other things than it is to optimize and clean up. Of course, in the end, it bites you on the ass and then you have to do more painful refactoring.... but if you did it up front, you might not get to the later as your company runs out of VC....

        I've also worked on complex enough systems that in order to get working even _basically_ you had to do a lot of work. Sometimes (and with some problems) there IS no convenient way to parcel it into smaller pieces and so you just have to bite the bullet, spend the time, and write the code that needs written to give you the smallest useful chunk. That can still be a fair size.

        Examples I've run across that come to mind are some network related things that just don't do _anything_ till you get them right and that requires a certain minimum infrastructure.

        Also, in some situations, the required effort to test jig a piece of code or to subdivide the task effectively doubles the amount of work required (or more) and thus isn't economically viable. For certain applications, the key tests are integration test results, NOT unit tests. Yes, you do leave yourself open to getting bit in the ass later... but it work a fair percentage of the time.

        But, having raised those "real world" comments, I think the discipline proposed is an awesome idea!
        • you've got some good ideas, but let me point out that refactoring time is often lost to time pressure. [...] Of course, in the end, it bites you on the ass and then you have to do more painful refactoring.... but if you did it up front, you might not get to the later as your company runs out of VC....

          Sorry, gotta disagree with that. In my experience, maintaining a good design always pays for itself and more, whenever you do it. I've spent months refactoring/rewriting a whole spaghetti design to clear it up. I've also walked in to help a junior colleague who'd spent a week having trouble working with someone else's serial comms code and getting nowhere tweaking it. The first thing I did was spend a couple of hours completely refactoring it into sensible layers. In the process we fixed a couple of serious bugs, and the whole development was complete two hours after that. Are you really telling me it would have paid off to leave him tweaking for another week instead, if you had limited VC funding? :-/

          • No. But a lot of times refactoring is slightly more complex than something that can be done in a couple of hours. Especially if you enjoy the "joy" of having inherited part of a large multi-platform project with multiple applications that have to interop. Assuming the whole thing has been assembled, many times perhaps to satisfy requirements for rapid demonstrations, etc. in order to acquire sales leads, etc, then refactoring becomes a large task in and of itself.

            Of course, in a perfect world, this would never happen. If you happen to live in one, let me know where and I'll emmigrate.

            The definition of bite you in the ass later is: Costs you more to fix later than it would have to do right in the first place.

            This hinges on several factors:
            1) That, by the time you later refactor, your own knowledge of the situation/requirements/code/etc hasn't improved drastically
            2) or that by the time you refactor, some change hasn't altered your requirements radically thus making your refactor actually a redesign (so if you'd refactored before, perhaps you wasted your time and money)
            3) or that a dollar today and a dollar six months down the road are equal - which isn't true in many cases... a dollar now may be something scarce and so refactoring time is VERY expensive, and later that same dollar (or even two given it will be harder to refactor) may be less problematic and more affordable

            I distinctly recall drawing the distinction that it depends on situation. In some cases, it makes sense to refactor always. In some cases (especially where you inherit a large, convoluted code base but have to start working on features without uptake time), refactoring immediately is a dumb idea. In an emerging market, refactoring immediately may well be wasting your time as that entire feature set or product direction may be entirely abandoned.

            So, although I support refactoring, I think the real world shows us places where it takes on a semblance of creeping elegance. I myself do it fairly regularly (mostly to make things easier for me and those following to understand), but I've seen the time hit this can incur trying to unravel a messy class heirarchy and I've seen the severing of whole feature sets as marketing/sales scramble for market position. That's why the real world isn't like the inside of any textbook.

            • Most people forget that a schedule can be changed. It is not carved in stone. The end date may be carved in stone. But what the project does... You also need to know when to chuck things overboard to get things done. It may be cool to have the splash screen popup. But do you HAVE to have one? Could you use that 3-4 days somewhere else? These sort of things should be hashed and rehashed all the way through ANY project. Refactoring can be a tool to _HELP_ you get things done on time. But sometimes we get rather miopic on what we are doing.

              Also when you are redesigning/rewriting/refactoring something how can you not at least LOOK at what the other person did? That will take some time. Just to say OH I know what it should do may not be true. Maybe they ran into some problems you didnt even THINK of and they alread solved them? Also more than likely other parts of the system are dependent on the behavior of that 'broken' piece of code. How do you take that into acount? These are the sorts of things you do when you are redesigning things.

              But you have it right about knowing WHEN to refactor. Just because someone does not work with you anymore. Is almost always the wrong reason. Sometimes if it works dont touch it is a good thing. You can work on OTHER things that will help you. Other times it finaly just comes down to 'NO ONE' knows how that damn thing works and we need someone here that knows it 'IN and OUT'. More than likely if no one else can even figure out what it does, and how it does it. It probably is a good candidate for getting refactored. But more than likely in order to tear something like that appart correctly you will have to understand the old code.

              You just need to know when to pick your battles.
      • I agree with almost all of your points here. Especially iterative development: it is simply _impossible_ for the programmer, designer, architect or client to know all of the requirements perfectly in advance for any reasonable size project. Also, some requirements change - it's a fact of life. Instead of getting angry about this, simply accept it and enable a mechanism in you development process to deal with it - that's what iterative development is all about.

        Where I disagree somewhat is with "deliver the most value-producing code first". I would prefer to emphasise:

        Deliver the highest risk code first.

        For example, if there is a new tool, technology, system, or whatever that you haven't used before and is critical for the project, this is probably the highest risk part. If the project, has strict performance requirements, this may be the highest risk part that requires a load testing framework to be established early and used rigorously thoughout the project. While it is nice politically to give users useful code ASAP, this may or may not be a high risk - if it is, of course, do it first. I really believe that having prioritys being "risk-driven" rather than "user-driven" is a more correct approach.
    • I have the same problem (single developer), but I just switch to skitzo-mode and work with my other personalities.
    • What kind of system are you looking for?

      Most of the prominent SD methodologies/philosophies are "geared toward teams" because it's axiomatic that the great problem of the successful organization of software projects is related to the challenge of effecively communicating compex requirements and designs between individuals.

      Now, if you're the only programmer, presumably you don't need to communicate design at all -- aside from the spectre of the future mainetance programmer.

      However, there are still other project stakeholders with whom you need to communicate; managers, users, etc. So, you can pick the bits of the other methodologies that deal with effective communication between developers and the other project stakeholders. For instance, use cases and working prototypes, or XP's "planning game" may be very useful tools to help you nail down the requirements or schedule deliverables.

      The most important thing though (and as an adherent of the Agile philosophy, I'd say this goes for groups of developers of all sizes as well) is to pick the bits that work best for you. What works best w/ one customer may not work at all with another. Your best bet is to develop a toolset of techniques that have been successful for you before, and to keep an open mind about what the "best way" to do things is.

    • Caffeine
      Quake
      Code
      Caffeine
      Quake
      Code
      Slee p
    • My God, you asked this question and got answers, and not one reference to masturbation. Is our little Slashdot growing up?

    • I highly recommend the Personal Software Process [cmu.edu] from the Software Engineering Institute at CMU. PSP focuses on how you can improve your own process, which is fundamental no matter how many people you work with. I've been reading the two PSP intro books (one aimed at introductory programming students, one aimed at professionals) this year and have gotten a lot out of it. I'm looking forward to getting a lot of this implemented a little later this year. I don't work alone, but it's very close as we have very few people and projects rarely require more than one person.

      Don't confuse PSP with the TSP also described on the site. TSP is aimed at teams. (And in some people's minds, PSP appears to exist only to support TSP.)

      • PSP is SO lame (Score:2, Interesting)

        by epictetus ( 5123 )
        I started reading PSP a few years ago and found it just completely ridiculous. You're supposed to track how long it takes yourself to write common programming structures, like for() loops, and then eventually you will have a cookbook of all the common programming structures. You use this cookbook to estimate how long a project will take you (Ah, to implement this, I will have to write 3 for() loops and a switch() statement! That's a total of four hours!). After several months of gathering and analysing the data, you'll be able to estimate project time to the minute and also track your improvement.

        If you are designing your code down to this level of detail, then you are finished before you start typing it. The process seems to think that programmer time is taken up by mechanical, predictable tasks. This may have been true in the days of punch cards. In modern times, all the time-consuming work is mental, and you won't know how long that takes until you've done it. Sure you can still roughly estimate how long things will take, but tracking how long it takes to write a for() loop is no help at all.
    • What about techniques/systems for the 1 man show?

      I presented a paper on this topic at last year's Conference on XP and Agile Methods. You can find a copy at ftp.ancar.org [ancar.org].

  • slashdot have special interest in good reviews (Score:1, Insightful)

    by Anonymous Coward
    Look at the fucking BN link, including a sourceid.. someone is getting commission.. what is the point in reading a review when the reviewer (or Slashdot) is getting paid for each book that is sold after reading the review? Grrrr.

    • It doesn't personally offend me as much as it does you (some could argue that slashdot has the right to get some credit for referring interested readers to the book) but I realize a lot of people feel a little red flag go up inside their heads when they see something like this. Personally, I don't see why the BN link couldn't be replaced to a search-engine query at pricescan.com or AskJeeves or something like that. With a click on a single link, slashdotters can compare prices at numerous bookstores. Hell, why not just a google search box with some choice keywords already filled in. Click on the search button and it automatically does a google search on "price Agile Modeling Effective Practices Extreme Programming Unified Process"? That way slashdot wouldn't face any criticism for getting referral points.

      GMD

    • They did bring it to your attention, after all. That's generally the role of sales, and in this case, an affiliate payment is certainly fair enough.

      Not like it costs you any more, anyway.

  • News for Nerds: An Holistic Approach (Score:4, Funny)

    by tps12 ( 105590 ) on Tuesday May 07, 2002 @12:57PM (#3478051) Homepage Journal
    What is up with the headlines today? First it's "Affective Computing," followed by "Agile Modeling." Can we expect "Attentive Debugging" next?
  • I find that plastic models are easier, quicker and look more realistic, but wood and paper models are more satisfying to work on and give you a better sense of accomplishment.
    • Yeah, but expressing deep inheritance hierarchies with wood and paper gets a bit tricky, and objects with large relational cardinalities require extreme care to hook up - doesn't really qualify as "agile"!

      Emailing these models can also be a bit of challenge...

  • OK, I guess I'm mostly speaking for myself and those programmers I work with, but I think many programmers have, over the years, evolved a personal set of design and modeling techniques that closely resemble what's described here. Using the unified process from the start just doesn't work for me, because it's not the way I think. I do a combination of "loose" modeling with UML, rapid prototyping to work out thorny problems, and then a complete design review to fix up the problem areas. Then repeat. Eventually, what emerges is reasonable for the time spent.

    For me, XP techniques come in handy for rapid prototyping, especially the flow of ideas that come with working closely with another programmer. And the UP is good for bringing elegance to the overall design.

    Finally, let's not forget the ultimate design tool for every programmer: the whiteboard. Ah, the smell of erasable marker in the morning...
    • UML modeling seems like a good idea, but often I've found that the tools for it are lacking. My experience with Rational Rose has left a lot to be desired. Many of the useful features like code generation aren't nearly as useful when the generated code doesn't work well with your compiler. In addition, the lack of a good way to represent many common data structures like structs and unions often cause developers to insert things in the UML model that don't make much sense just for the sake of generating the code they want. UML has a lot of potential, but in my experience, the tools for it still have a long way to go.
      • Yeah, I agree. For me, the UML is more an effective way to visualise object relationships and to provide good documentation for future code maintainers. To be honest, I've never used the code generation bit in Rose. The UML diagramming in Dia works just as well for me. I find that UML helps to make complex inheritance hierarchies a lot more elegant, and it becomes a lot easier to see just what object is using what.

        That said, I once worked with a total UML/UP freak who produced sequence diagrams for every public method in our whole project. They were really nice, but it took a reeeeallly long time for him to get anything done. So I guess if you have the time, and that's the way your brain works, it's worth it.
    • I'm only halfway through the book, but to me the book is about learning how to recoginize what modeling techniques would be most appropriate to the situation you are in - by evalutating the people and environment around you and doing what works.

      Sure most of us have a set of design and modeling techiques we rely on, but this book can help judge which ones really will work with the project you're on. Even in the same company, there can be dramatic difference in what will work best on a project.

      Also, I think people tie this book too closely to XP - though it does advocate some XP techniques it does not mandate all XP techniques be used on all projects. I was at a JavaOne talk on Agile Modeling, and I really wish I had read the book before I attended the session as much of the session was wasted on XP questions instead of asking more interesting question at the higher level this book covers.

  • bn.com? wtf? (Score:4, Informative)

    by titonutz ( 558355 ) on Tuesday May 07, 2002 @01:04PM (#3478096) Homepage
    Everyone knows Amazon is better. Compare:

    Price at bn.com: $27.99 (%20 off)
    Price at amazon.com: $24.49 (%30 off)

    Buy from amazon.com [amazon.com]
  • Its very fascinating that this review should come out now. The entire technical competency at my new job has invested alot into Agile as one of many methodologies practiced. Yesterday some of us were having a discussion about usecases, and how they fit into the agile world, both as a consumable from the developer's view of the world, as well as from the view of User Experience and Project Management. In practice here, it seems that usecases are a very large part of the agile management style, in some cases, depending on the completeness, making it all the way to the client as a deliverable.

    I shall give this a read to see what insights Scott Ambler provides.

  • CLH model (Score:2, Funny)

    by avandesande ( 143899 )
    we use the CLH model ... (code like hell!)
  • My modeling endevor is to be on the cover of vouge. I'll even take my shirt off to do it.

  • Ok (Score:2)

    by Mr_Perl ( 142164 )
    I read this, and am still wondering what is modeling. Anybody?

    • Design of software using models, that is, drawing class diagrams, use case diagrams etc... This class contains that and inherits from this and so on.

    • Re:Ok (Score:3, Informative)

      by jamesmartinluther ( 267743 )
      Modeling, as in other fields, is forming a simplified representation of reality which assists in the understanding of reality (and often modeling even distorts this understanding). In the world of software development, I would say that modeling is a conceptual architecture that can help developers organize the work.

      When I'm modeling a new project, people will notice diagrams and other scribblings on my desk as I attempt to work out how all of the basic utilities, resources, and user interfaces of an application will work together.

    • Re:Ok (Score:5, Funny)

      by Anonymous Crowhead ( 577505 ) on Tuesday May 07, 2002 @01:42PM (#3478323)
      I read this, and am still wondering what is modeling. Anybody?

      [posted] by Mr_Perl

      No wonder.
  • when there an Agile SuperModel book. Perferable with a fold out.
  • I've visited the links on Agile Modeling, and they use the term "Modeling" over and over and over. But no place do they say what Modelling means.

  • Another methodology with a catchy name that is supposed to fix all the problems with software development but never quite does. Just what the world needs.

  • Good, finally a book that will cover how to make the transition from the runway, to the porn industry. Or did I miss something?

  • Misconception (Score:2, Insightful)

    by rovingeyes ( 575063 )
    "XP offers a methodology for building high quality software FAST"

    Well I don't understand why people confuse the term "Agile" with speed. Agile development is not about speed but about change (look in any dictonary). Agile development was a kind of revolt against the heavier methodologies since they were too picky and wouldn't let you change down the road, as easily as some of the Agile methods like XP.

    Now the practices proposed in Agile methods like XP might lead to a faster development but will never ever guarantee on time developement and never says snything about speed. It is all about adapting to change in requirements, situation etc.

    • Re:Misconception (Score:2, Insightful)

      by byrd ( 26881 )
      Agile development is not about speed but about change

      That's true. But being agile means that sometimes, you can dodge the speed-bumps.

      the practices proposed in [...] XP might lead to a faster development but will never ever guarantee on time developement

      It depends what you mean by "on-time". XP can certainly guarantee that something will be delivered on the appointed release-date, and that it will contain the most important functionality. You relax the scope in order to hit the target. In some non-XP projects I've been involved with, we've been unable to alter scope, and therefore had to relax quality to hit the target. And that's never a good feeling.

  • Modeling (Score:2, Interesting)

    by PinglePongle ( 8734 )
    Some people have asked what this modeling thing is all about; as a public service, here's the PinglePongle version.

    Some academics regard the process of building software as a descent from the abstract to the concrete. Typically, it starts of with "hey, we need a thingumajig - it must streamline our widget creation process". This is usually followed up by a requirements spec which says what the thingumajig should do, but doesn't go into how should be constructed.
    The next phase typically involves the developers working out how to build a thingumajig which meets the requirements spec.
    Once the developers have worked out how to build the thingumajig, they start to code it; if you're lucky it gets tested and eventually it's released.

    All these phases do occur, but the way in which they're executed varies enormously. Frequently, they overlap; frequently people move back and forth between the phases several times; frequently it's hard to tell which phase you're in.

    Modelling general concerns mainly the "how do we build a thingumajig" design stage. A model can be anything that helps to convey the intention of the design without being actual code - a crayon drawing, a piece of prose, an email, a memo, a flowchart, a wall-sized database diagram, a haiku. There are a bunch of methodologies which adress the modeling phase, most famously the Unified Modeling Language (UML) which defines a standard vocabulary for object oriented design using around a dozen different diagram styles.

    The problem with models is that they can become very cumbersome and end up leading a life of their own (here's a previous /. thread... [slashdot.org]), and it's not uncommon to have projects with many times more paper than code.

    As it goes, I believe that anyone who takes programming seriously should be at least passingly familiar with the most common modelling practices - UML use cases and class diagrams, database E/R diagrams, flowcharts; in my projects I ask the developers to model the tricky parts of the project, but only with the explicit purpose of understanding the problem better before starting to write code. You can change a model around easily and quickly - changing a class diagram to put a method in a different class takes seconds - but if you realize halfway through coding there's a better way to do it, you almost never have time to fix it.

    I've ordered the book (no, I'm not going to tell you where from) - and if it's as good as Cockburn's other work, it'll be money well spent, even from bn.com !

Slashdot Top Deals

The optimum committee has no members. -- Norman Augustine

Close