Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Agile Modeling and XP -- Setting the record straight

Expand Messages
  • wecaputo@thoughtworks.com
    ... I found the article to be very on target, in an area that I think we will see more and more of -- how to do XP with Just want to go
    Message 1 of 1 , Nov 6, 2001
      Scott Ambler:
      >feedback would definitely be welcome.

      I found the article to be very on target, in an area that I think we will
      see more and more of -- how to do XP with <fillInTheBuzzWord>

      Just want to go into something a little bit:

      From the article:
      "Is using buzzword1 with buzzword2 the right question to be asking? and if
      not What is the right question? When you ask these questions about XP and
      UML you quickly realize that the right question to be asking is more along
      the lines of How do you model effectively on an XP project?"

      This question does a nice job of stepping back and looking at the issue
      from a broader perspective. In the spirit of agile however, I think an even
      more fundamental question we should ask ourselves (on any given project)

      "How can modelling add value to the project?"

      This is in turn an example of an even more fundamental question:
      "How can buzzwordX add value to the project?"

      As the "XP and buzzword" craze increases -- due to more and more IT shops
      looking at XP, but not wanting to upend their entire infrastructure -- this
      is one way we can reach an effective solution.

      XP precludes nothing. Instead it prescribes the mind set of only adding
      things as they add value to the particular project in response to a
      demonstrated deficiency in our existing process.

      This is the rationale behind those XP'rs recommendations that we do XP as
      close as we can to the way it is described before changing it -- both on a
      organizational, and project level. Personally, this is how I try to
      approach each new project I look at.

      This "don't add it until you really need it" idea seems to be common
      across all agile processes, and may be their common thread. It's also
      common across all software development concepts -- as true for Modelling
      and UML, as it is for DBMS, additional project roles, and architectural
      decisions.

      Anyway, a good thought-provoking article. Thanks Scott for bringing it to
      the attention of the list.

      Best,
      Bill
    Your message has been successfully submitted and would be delivered to recipients shortly.