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

Trying to implement XP

Expand Messages
  • Gabriel Castellanos
    Hi Everybody: In my last posting I wrote that I will be working in a big project involving several hundreds users in different locations and that I want to
    Message 1 of 3 , Sep 17, 2002
    • 0 Attachment
      Hi Everybody:

      In my last posting I wrote that I will be working in a big project involving several hundreds users in different locations and that I want to implement XP (at least some practices), I'd love to implement it completely but management is not very convinced, so what I gain is the ability to implement some practices, if we deliver results we can move on an implement some more, obviously I hope this group can help me in my endevour ;) , btw my idea is to give you some kind of "status report" so we all learn from this experience. After saying this, let's start:

      It's being very difficult for me so decide which practices to use, since all the practices are interelated, so it's not only decide which practices I can use, but how can I "patch" the process at least while I get more decision power and I can implement the others practices. So far this is my first list of practices:


      1. Testing (unit testing and customer acceptance testing).
      2. Planning game.
      3. Refactoring.
      4. Coding standards.
      5. 40 Hour week.
      6. Metaphor.
      7. Simple design.
      8. On site customer(at least partially, since we will have a "representative" for a couple of hours a week)


      Now I'd like to discussed how I am planning to implement these (this will be the topic for another posting), but first I want to discuss two practices that I have doubts in how to implement even if I could convince management:


      Short Releases and Continuous integration: The application has 1,200 users and even the smallest chunk is for 100 users, how can I handle training and deployment? I believe I can implement continuous integration, but is it worth it without short releases?


      Before you ask the following two are out of the question since management doesn't like them at all, I hope that when I start delivering results they will allow me to implement them, I know they are basic and very important but for now there is no way I can convinced them, I have some ideas on how to strength the others practices so the impact is not so terrible, but again that's another posting, I need to do more research ;) .


      1. Pair programming.
      2. Collective ownership.


      Thanks for your help.

      Gabriel


      _______________________________________________________________________________________________________
      Obt�n gratis tu cuenta de correo en StarMedia Email. �Reg�strate hoy mismo!. http://www.starmedia.com/email
    • William Pietri
      ... You d have to tell us more about your environment before I could give you a useful answer to that question. Are we talking about a desktop app? A website?
      Message 2 of 3 , Sep 17, 2002
      • 0 Attachment
        On Tue, 2002-09-17 at 07:57, Gabriel Castellanos wrote:
        > [...]Now I'd like to discussed how I am planning to implement these
        > (this will be the topic for another posting), but first I want to
        > discuss two practices that I have doubts in how to implement even if
        > I could convince management:
        >
        > Short Releases and Continuous integration: The application has 1,200
        > users and even the smallest chunk is for 100 users, how can I handle
        > training and deployment?

        You'd have to tell us more about your environment before I could give
        you a useful answer to that question. Are we talking about a desktop
        app? A website? A video game? A warehouse management system?

        The general theory with deployments is that if you do them frequently,
        then you will find ways to make them easy. And with training, my notion
        is that users won't have much trouble adapting to a steady stream of
        small improvements if you a) have a good information architecture, b)
        design good UIs, c) have good contextual help, and d) provide them with
        explicit notice every time you change things that aren't obvious.

        But I think there is a lot of territory where those are tricky, so that
        "frequent" is a term that requires careful local interpretation.

        > I believe I can implement continuous integration, but is it worth it
        > without short releases?

        I feel continuous integration is always worth it. The longer you wait
        between integrations, the harder it is to find and fix integration
        problems. (I think the curve is exponential, but I couldn't prove it.)
        Ergo, if you want all your integration problems to be tiny, you should
        integrate continuously.

        > Before you ask the following two are out of the question [...]
        >
        > 1. Pair programming.
        > 2. Collective ownership.

        If you are getting rid of pair programming, you must add some other
        measure to compensate. I'd suggest stringent design and code reviews;
        that's enough of an industry standard that your managers couldn't
        object. If they do, you should probably find another place to work.

        As to collective ownership, why do they want it? Just for the sake of
        'accountability', so that they can zap people for particular bugs?

        If so, then I would set things up so that every part of the system is
        nominally owned by somebody, and make sure that they are involved in all
        code reviews for their parts. And when a programmer is working out of
        their area of 'ownership', they should probably ask the code 'owner' for
        help. Which starts to look a lot like pairing, doesn't it?

        William

        --
        brains for sale: http://scissor.com/
      • Robert Martin UncleBob
        ... If you can t start with it all, then the minimum set to start with is: 1. Short cycles. 2. Test Driven Development. By short cycles I mean 2-3 week
        Message 3 of 3 , Sep 19, 2002
        • 0 Attachment
          > -----Original Message-----
          > From: Gabriel Castellanos [mailto:juangabriel@...]
          > Sent: Tuesday, September 17, 2002 9:57 AM
          > To: extremeprogramming@yahoogroups.com
          > Subject: [XP] Trying to implement XP
          >
          >
          > Hi Everybody:
          >
          > In my last posting I wrote that I will be working in a big
          > project involving several hundreds users in different
          > locations and that I want to implement XP (at least some
          > practices), I'd love to implement it completely but
          > management is not very convinced, so what I gain is the
          > ability to implement some practices, if we deliver results we
          > can move on an implement some more, obviously I hope this
          > group can help me in my endevour ;) , btw my idea is to give
          > you some kind of "status report" so we all learn from this
          > experience. After saying this, let's start:

          If you can't start with it all, then the minimum set to start with is:
          1. Short cycles.
          2. Test Driven Development.

          By short cycles I mean 2-3 week iterations and 2-3 month releases. This is,
          *by far* the most important of all the practices. If you do this, and
          nothing but this, you will get a sizeable fraction of the benefit of XP.

          Test Driven Development includes unit tests and acceptance tests.
          Implementing these is critical, with acceptance tests being slightly more
          important than unit tests. After all, how can you know you are done with a
          feature, unless there is some kind of repeatable acceptance criteria?

          > It's being very difficult for me so decide which practices to
          > use, since all the practices are interelated, so it's not
          > only decide which practices I can use, but how can I "patch"
          > the process at least while I get more decision power and I
          > can implement the others practices. So far this is my first
          > list of practices:
          >
          >
          > 1. Testing (unit testing and customer acceptance testing).
          > 2. Planning game.
          > 3. Refactoring.
          > 4. Coding standards.
          > 5. 40 Hour week.
          > 6. Metaphor.
          > 7. Simple design.
          > 8. On site customer(at least partially, since we will have a
          > "representative" for a couple of hours a week)
          >
          >
          > Now I'd like to discussed how I am planning to implement
          > these (this will be the topic for another posting), but first
          > I want to discuss two practices that I have doubts in how to
          > implement even if I could convince management:
          >
          >
          > Short Releases and Continuous integration: The application
          > has 1,200 users and even the smallest chunk is for 100 users,
          > how can I handle training and deployment? I believe I can
          > implement continuous integration, but is it worth it without
          > short releases?

          You don't have to release to the entire user community every iteration. I
          once delivered a very large system *weekly*, but only to my customer. He
          would review it, and comment on it. Sometimes he'd send it on to another
          group for further testing. Even less frequently he'd hire a bunch of
          independent testers to beat it up. It was launched only once -- at the end
          -- but the customers had had a *lot* of experience with it prior to that
          launch and were quite happy with it.

          The user documentation and training thing is often much less difficult than
          you might thing. For one thing, you can have the documentation folks
          participate in each interation. The deliverables for each interation can
          include the user manuals and training materials for the stories implemented
          in that iteration.

          > Before you ask the following two are out of the question
          > since management doesn't like them at all, I hope that when I
          > start delivering results they will allow me to implement
          > them, I know they are basic and very important but for now
          > there is no way I can convinced them, I have some ideas on
          > how to strength the others practices so the impact is not so
          > terrible, but again that's another posting, I need to do more
          > research ;) .
          >
          >
          > 1. Pair programming.
          > 2. Collective ownership.

          I don't think this is a big impediment. Clearly doing them would be good,
          but you can live without them for a few releases. The benefit you will get
          from short cycles, test driven development, and the planning game will
          likely be spectacular.

          Have you seen the article in "The New Architect":
          http://www.newarchitectmag.com/documents/s=2412/na1002e/index.html

          -----------------------------------------------
          Robert C. Martin |
          President & Founder |
          Object Mentor Inc. | unclebob @ objectmentor dot com
          PO Box 5757 | Tel: (800) 338-6716 x15
          565 Lakeview Pkwy | Fax: (847) 573-1658
          Suite 135 |
          Vernon Hills, IL, | www.objectmentor.com
          60061 |
          -----------------------------------------------
        Your message has been successfully submitted and would be delivered to recipients shortly.