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

Agility and CMBoK? (was Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.)

Expand Messages
  • Brad Appleton
    ... Hmmn - an AgileBoK? On an (only somewhat) related note, a configuration-management WIki-web was started about a year ago and some folks voluntarily took it
    Message 1 of 37 , Jun 3, 2003
      On Tue, Jun 03, 2003 at 09:06:08AM -0600, Mike Cohn wrote:
      > There's a difference, however, between mentioning agile methods and writing
      > a body of knowledge that has some implicit assumptions about Big Design
      > Upfront. I would think our body of knowledge should include mention that Big
      > Design Upfront doesn't work--even if there is no explicit mention of
      > anything agile.
      > Perhaps we mean a guide to the Agile Body of Knowledge? :)

      Hmmn - an AgileBoK?

      On an (only somewhat) related note, a configuration-management WIki-web was started about a year ago and some folks voluntarily took it upon themselves to attempt to document a CM Body of Knowledge (or CMBoK). I don't think they intent certification (at least not yet - tho they did model it after the organization of the PMI's PMBOK).

      There is a section of it that talks about contribution to CM from other areas and methods, and which speaks specifically about contributions from Agile development, XP, SCRUM, and RAD. These are all still "in progress" of course and some parts or obviously incomplete. (one of the sections was taken from an email posting of mine to a related mailing list wondering what the heck this agile-stuff was and how does it relate to CM, and is it anything new or just old wine in new skins).

      Those wanting to look at it and make clarification/corrections/additions or comments can do so at their leisure (it's a wiki after all) at:

      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep." -- Robert Frost
    • Mike Beedle
      ... From: Fabian Ritzmann [mailto:usefri@gmx.net] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests or
      Message 37 of 37 , Jun 6, 2003
        -----Original Message-----
        From: Fabian Ritzmann [mailto:usefri@...]
        > Need to bring this back on topic for this list. :-)

        Oh, I don't know -- we are still sort of on topic.

        > --- Fabian Ritzmann <usefri@...> wrote:
        > XP as I understand it uses unit tests and system
        > tests, unit tests for unit testing and system tests for
        > whatever the users want to test, including quality
        > aspects like performance, reliability, etc.

        We call tests by the user "acceptance tests" or ATs.

        I think this is a valid definition across XP and
        Scrum but I don't know if other agile methods call
        them the same way.

        self wrote:
        > The combination is very powerful:
        > * test as _specification_ from Test-First, and
        > * program as executable _specification_ from
        > functional programming
        > Both strategies drive development more into the
        > quantifiable _what_ space, much more than worthless
        > "exhaustive requirements documents" or "models".
        > Perhaps, this is what we need to concentrate in
        > software architecture -- in patterns that tell us
        > _what_ to program and that are executable,

        Fabian wrote:
        >The principle problem is that provable (and executable)
        >specifications don't help if the specification is wrong.
        >And we all know that specifications always change,
        >that's why we do Scrum or another Agile development
        >method. Of course that shouldn't keep anybody from
        >improving the way we are programming these days.

        True. In our view, the need for acceptance tests
        conducted through people-2-people interaction
        never goes away for the exact reasons you list
        (and regardless the programming styles used):

        - making sure that the specification is not wrong
        - making sure that we keep up with changes
        for the specification
        - making sure that the user experience is
        comfortable i.e. timely, convenient, beautiful, etc.

        It is just easier, faster and even more economical
        in some paradigms of programming to do the above
        3 things,

        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.