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

Re: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Mike Beedle
    Baker: Interesting post. I guess it is somewhat contradictory that he supports and sells an agile method i.e. his own version of XP; but on the other hand he
    Message 1 of 37 , Jun 5, 2003

      Interesting post. I guess it is somewhat
      that he supports and sells an agile method i.e.
      his own version of XP; but on the other hand he
      has not been supportive or convincing enough to
      highlight XP or agile in SWEBOK.

      Perhaps, he does feel it is a conflict of interest
      to promote in SWEBOK the agile things he sells,

      - Mike

      --- bakersox1 <StockingB@...> wrote:
      His prominence there coupled with the cited absence
      of support in the SWEBOK material might suggest that
      he is, at best, a luke-warm friend of the movement.

      A brief review of his site (www.construx.com) suggests

      that, while he seems to honor XP practices and the
      word "Agile" (the latter only from a distance), he
      makes little effort to further either movement
      except for an attempt to market his own flavor of XP
      via a proprietary framework called CxOne.

      See his white paper
      comparing his proprietary "CxOne" process to
      XP "along with a look at how CxOne can assist XP
      projects". His company will be happy to sell you
      their "CxOne Extreme Programming toolkit" which "gives
      you all the materials you need to run a successful XP

      His company's decription of the CxOne software
      engineering framework
      (http://www.construx.com/cxone/) seems almost to go
      out of its way to avoid use of the word "agile",
      substituting it with a whole string of adjectives
      that retain its essence: "lightweight, tailorable,
      modular, and scalable".

      The only reference I could find there to the agile
      _movement_ is in a
      copy of his editorial entitled "Common Sense" from the
      2001 issue of IEEE/Software in which he says:
      "One contribution of the agile programming movement is
      to cast a
      critical eye toward prevention and ensure that
      projects do not spend
      more on prevention than they would need to spend on
      cure. On balance,
      I think this common sense maxim does apply to
      software, but we need
      to be careful not to overextend it, i.e., "Moderation
      in all things."

      Could we perhaps conclude that Mr McConnell might fear
      charges of
      1.) a conflict of interest if he were to promote XP
      for SWEBOK?
      2.) trying to promote "common sense" as an engineering
      discipline if he were to promote agile methodolgies
      by name?

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