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

RE: [XP] Re: RUP and Test First

Expand Messages
  • Dinwiddie, George
    Rob, Have you looked at http://www.objectmentor.com/publications/RUPvsXP.pdf ? - George ... From: Rob Lally [mailto:RobL@zonal.co.uk] Sent: Monday, May 28,
    Message 1 of 13 , Jun 1, 2001
    • 0 Attachment
      Rob,

      Have you looked at http://www.objectmentor.com/publications/RUPvsXP.pdf ?

      - George

      -----Original Message-----
      From: Rob Lally [mailto:RobL@...]
      Sent: Monday, May 28, 2001 12:37 PM
      To: extremeprogramming@yahoogroups.com
      Subject: [XP] Re: RUP and Test First


      Whilst you are, of course, correct that Test First(TM) is a technique for
      driving design and coding I don't consider that to be the be all and end all
      of the technique. It's also about testing. If that weren't true then you
      could safely delete the tests at the completion of each story.

      I want to try to tailor our RUP instance to be as XP-like as I can within
      the boundaries I have to work in. [snip]
    • Ivan Tomek
      Hi Peter, Nice hearing from you once in a while! Unfortunately, I have the bad habit of throwing my papers out too soon and so I don t have a copy. I suggest
      Message 2 of 13 , Jun 1, 2001
      • 0 Attachment
        Hi Peter,

        Nice hearing from you once in a while! Unfortunately, I have the bad habit
        of throwing my papers out too soon and so I don't have a copy. I suggest
        asking Hermann, he has a much bigger office and is better organized. In the
        worst case, I can try and find whether our library still has that issue.

        Are you going to do something along the lines of the article?

        Ivan

        -----Original Message-----
        From: Dinwiddie, George [mailto:George.Dinwiddie@...]
        Sent: Friday, June 01, 2001 12:12 PM
        To: 'extremeprogramming@yahoogroups.com'
        Subject: RE: [XP] Re: RUP and Test First


        Rob,

        Have you looked at http://www.objectmentor.com/publications/RUPvsXP.pdf ?

        - George

        -----Original Message-----
        From: Rob Lally [mailto:RobL@...]
        Sent: Monday, May 28, 2001 12:37 PM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] Re: RUP and Test First


        Whilst you are, of course, correct that Test First(TM) is a technique for
        driving design and coding I don't consider that to be the be all and end all
        of the technique. It's also about testing. If that weren't true then you
        could safely delete the tests at the completion of each story.

        I want to try to tailor our RUP instance to be as XP-like as I can within
        the boundaries I have to work in. [snip]

        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
        see www.xpuniverse.com for details and registration.

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



        [Non-text portions of this message have been removed]
      • Ivan Tomek
        Oops, sorry about that. Pushed the wrong button. Ivan ... From: Ivan Tomek [mailto:ivan.tomek@acadiau.ca] Sent: Friday, June 01, 2001 1:02 PM To:
        Message 3 of 13 , Jun 1, 2001
        • 0 Attachment
          Oops, sorry about that. Pushed the wrong button.

          Ivan

          -----Original Message-----
          From: Ivan Tomek [mailto:ivan.tomek@...]
          Sent: Friday, June 01, 2001 1:02 PM
          To: 'extremeprogramming@yahoogroups.com'
          Subject: RE: [XP] Re: RUP and Test First


          Hi Peter,

          Nice hearing from you once in a while! Unfortunately, I have the bad habit
          of throwing my papers out too soon and so I don't have a copy. I suggest
          asking Hermann, he has a much bigger office and is better organized. In the
          worst case, I can try and find whether our library still has that issue.

          Are you going to do something along the lines of the article?

          Ivan

          -----Original Message-----
          From: Dinwiddie, George [mailto:George.Dinwiddie@...]
          Sent: Friday, June 01, 2001 12:12 PM
          To: 'extremeprogramming@yahoogroups.com'
          Subject: RE: [XP] Re: RUP and Test First


          Rob,

          Have you looked at http://www.objectmentor.com/publications/RUPvsXP.pdf ?

          - George

          -----Original Message-----
          From: Rob Lally [mailto:RobL@...]
          Sent: Monday, May 28, 2001 12:37 PM
          To: extremeprogramming@yahoogroups.com
          Subject: [XP] Re: RUP and Test First


          Whilst you are, of course, correct that Test First(TM) is a technique for
          driving design and coding I don't consider that to be the be all and end all
          of the technique. It's also about testing. If that weren't true then you
          could safely delete the tests at the completion of each story.

          I want to try to tailor our RUP instance to be as XP-like as I can within
          the boundaries I have to work in. [snip]

          To Post a message, send it to: extremeprogramming@...

          To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...

          Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
          see www.xpuniverse.com for details and registration.

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



          [Non-text portions of this message have been removed]


          To Post a message, send it to: extremeprogramming@...

          To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...

          Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
          see www.xpuniverse.com for details and registration.

          Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



          [Non-text portions of this message have been removed]
        • Rob Lally
          Hi George, I have seen this document and I agree heartily with it. I have had our Process Engineer read it. But to no avail. He is simply not interested in
          Message 4 of 13 , Jun 4, 2001
          • 0 Attachment
            Hi George,

            I have seen this document and I agree heartily with it. I have had our
            "Process Engineer" read it. But to no avail. He is simply not interested in
            trying to make our process more agile, or even more efficient. I have found
            that I get no resistance when trying to add practices to our process but
            trimming anything is a no-no.

            As a result of our process we are producing terrible code very, very slowly.
            I've been trying to add practices that will at least solve the first of
            those problems. Making unit testing easier seems to be one of the best
            things I can do.

            I'm trying to hold with the "find the worst problem you have and fix it the
            XP way" idea. At least partly so that when the over-bosses get sick of
            missed schedules we will be able to trim the process and hopefully lose the
            BDUF practices that are hurting us the most. I don't see XP as an attainable
            goal but I am hopeful that some sort of agility is do-able long term. I
            suppose the other side of the coin to "change your organisation" is "change
            your oranisation" and I am getting mighty sick of BDUF.

            There has been some criticism here in the past of the idea of "sneaking in
            XP". It has been suggested that if you're scared to tell people the true
            name of the process you are moving towards then the principle of Courage is
            certainly not being adhered to and Communication os sorely lacking.

            I feel that every practice I try to add to our process is there to solve a
            problem, but I try to avoid the term XP these days as it just antagonises
            the Process Engineer. Do people feel that I'm being dishonest? I'd like to
            make clear that although I expect things to come crashing down around our
            ears at some point I've been consciously avoiding "the straw that broke that
            camels back" behaviour - however much I might be tempted. That being true -
            our process isn't working, would provoking a major confrontation/catastrophe
            be responsible behaviour. I think not, but is letting the project stagger on
            for another six months before the big bang a reasonable alternative.
            Opinions? Suggestions?

            Rob.



            >Rob,
            >
            >Have you looked at http://www.objectmentor.com/publications/RUPvsXP.pdf ?
            >
            > - George
            >
            >-----Original Message-----
            >From: Rob Lally [mailto:RobL@...]
            >Sent: Monday, May 28, 2001 12:37 PM
            >To: extremeprogramming@yahoogroups.com
            >Subject: [XP] Re: RUP and Test First
            >
            >
            >Whilst you are, of course, correct that Test First(TM) is a technique for
            >driving design and coding I don't consider that to be the be all and end
            all
            >of the technique. It's also about testing. If that weren't true then you
            >could safely delete the tests at the completion of each story.
            >
            >I want to try to tailor our RUP instance to be as XP-like as I can within
            >the boundaries I have to work in. [snip]
          • Dale Emery
            Hi Rob, ... If you re going to produce terrible code, perhaps it s best to do it very, very slowly. ... I don t think the name is important. What is important
            Message 5 of 13 , Jun 4, 2001
            • 0 Attachment
              Hi Rob,

              > As a result of our process we are producing terrible code very,
              > very slowly.

              If you're going to produce terrible code, perhaps it's best to do it
              very, very slowly.

              > I feel that every practice I try to add to our process is there
              > to solve a problem, but I try to avoid the term XP these days as
              > it just antagonises the Process Engineer. Do people feel that I'm
              > being dishonest?

              I don't think the name is important. What is important is all the
              stuff the name implies. The practices produce the same results
              regardless of what you call the set of them.

              Names carry baggage. In fact, that's the whole point of names. The
              problem is, when you say XP, you are trying to convey one set of
              ideas, and when people hear you say XP, they hear a different set of
              ideas. You don't have control of what baggage people are going to
              attach to any name, including XP.

              I've seen any number of processes go through something like a teenage
              romance cycle, starting with infatuation, and ending with
              disillusionment and bitterness. One thing that contributes to this
              cycle is that the process has a name. I made up the If You Name It,
              They'll Blame It principle. It works like this:

              - A small group of people have great success with some set
              of practices.

              - In their enthusiasm to share their success and learnings,
              they name their process, and tell others about the successes.
              They tell everything they can think of, but almost always
              leave out many of the tiny details that spell the difference
              between success and failure.

              - Other people, wanting successes themselves, become enthusiastic
              about the process. They use the name in every sentence they
              utter (perhaps trying to invoke "name magic"). The name
              invokes lots of inspiration and hope.

              - People try the process -- at least, the process as they
              understand it (which doesn't include all of the tiny,
              critical details). Some succeed wildly, which the process's
              enthusiasts usually attribute to the process. Some fail
              miserably, which the process's enthusiasts *always* attribute
              to "doing the process wrong".

              - People begin to notice the process's "failures". Even when
              the process succeeds, it may not live up to the magical
              expectations people had. The name loses its shine.

              - Disillusioned folks start to blame the process for the bad
              things -- the "failures" and unfulfilled expectations. They
              don't notice that their expectations were unwarranted. They
              now have the scapegoat they need, and their unwarranted
              expectations can remain intact. The name now carries more
              negative than positive baggage.

              - Throughout all of this, the practices remain the same. The
              name remains the same. Only the baggage changes.

              In many cases, you'll have much better results if you don't worry
              about the name. Focus on the practices, and whether they are helping
              you.

              > our process isn't working, would provoking a major
              > confrontation/catastrophe be responsible behaviour. I think not,
              > but is letting the project stagger on for another six months
              > before the big bang a reasonable alternative.
              > Opinions? Suggestions?

              Responsible to whom? Responsible for what result? How did you become
              responsible for that? My guess: Nobody asked you to take
              responsibility for the entire success of the project. Focus on (1)
              the responsibility that you have negotiated (perhaps implicitly) with
              others, and (2) your responsibility to yourself.

              As for (1), if you and the other stakeholders have agreed that you are
              responsible for continuing or ending the project, you don't need a
              catastrophe. Just end it. If you don't have that responsibility,
              either renegotiate so that you do have it, or let it go. Focus
              instead on the responsibilities you do have, which (probably) include
              speaking up when you see a problem.

              As for (2), I can see at least two possibilities. First, you always
              have the possibility of walking away. Second, if you choose to stay
              on the project, clarify (with yourself and others) what is within your
              responsibility and what is not.

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