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

Re: [XP] Getting started with XP for personal development

Expand Messages
  • Dan Bunea
    Hi, When I first started with agile methodologies, as a developer, I had to think about what to do to be able to make the company become agile. Sell XP to
    Message 1 of 5 , Oct 12, 2005
      Hi,

      When I first started with agile methodologies, as a developer, I had to
      think about what to do to be able to make the company become agile.

      Sell XP to yourself

      In order to do that you have to sell XP to yourself in the first step. If
      you're both the vendor and the client, you must think what would you like
      as a developer to achieve by moving to another way of working. Since
      you're selling XP to a developer, you have to show yourself how you can go
      home being confident that the code runs, being able to work 40 hours every
      week, being able to apply your new ideas very easily, without fear, that
      you might break what you already did. TDD and automated tests can give you
      the confidence and from that you'll be able to move faster and add ideas
      to your project, motivation will start going high. Refactoring and simple
      design, can alow you to minimize rework (smaller and simpler code is
      easier to debug and enhances flexibility). Continuous integration is very
      important, as it lets you go home happy and find in the morning if you
      broke something in the worst case. Continuous integration maximizes the
      feedback from the code to you. It is a bell telling you that you broke
      something. It is by running the test, the break detector.

      After a few months, I was able to have reasonable enough confidence in
      myself to go to the practices skeptics. I could confront them, not always
      very well, but as in Alistair's - 'shu ha ri' the tree levels in aikido,
      things must go ahead , slowly but ahead.

      After you've convinced yourseld, you can convince other developers.

      In convincing other developers about agile/xp practices, I use the 'self
      training' technique, where we take a book/article etc and every morning we
      all stop work for an hour or so and read a chapter, the answer a few
      questions to see what each understood then talk until the things described
      there are understood by everyone. More at:
      http://danbunea.blogspot.com/2005/05/self-training.html. The others will
      see that you did not invent the things, but they will read them there and
      you'll be able to explain how they work and answer their questions.

      Slowly you're convincing the developers. It is time to move upper -
      management

      Sell XP to your management

      In convincing managers you have to remember that they are managers and
      they are running a business. They don't care about better code design,
      more automated tests. They care about money, and you need to show them how
      these practices can maximize profits. I wrote a simple sample about how
      TDD minimizes costs here:
      http://danbunea.blogspot.com/2005/09/how-tdd-improves-development-speed-and.html.

      Start small, but explain the advantages of iterations and cusomer on site.
      Expain that these two eliminate communication gaps and show examples how
      in the past commujication gaps costed money. A lot of money. Then go
      further to user stories. Another communication problem. Show that writing
      very detailed spec is very costly and has a high risk of being trown away
      when changes occur. When they'll see that you can reduce costs and improve
      profits (don't overpromise!) they'll start to be convinced.

      Selling to the customer

      The customer must be informed from the beginning about what you're
      planning to do and the iterative circle of life (see Ron's XP Installed).
      Convince them about the benefits, using the same methods as for managers.
      Less time, less money, better quality, running features after just a
      couple of months.

      I needed 18-24 so far and I am not ready. I am still becoming agile, just
      like everyone else. But the situation is changing. More and more people
      hear about the good results of XP and that might bring down the resistance
      wall faster. The most time, you will need to sell agile to you. When that
      is ready nothing can stop you.

      I tried to share a little about my experiences in becoming agile as a
      business. We are very small, and that's a huge advantage, but I have seen
      good results even in monster companies. Just determination is needed.

      Thanks,
      Dan Bunea
      http://danbunea.blogspot.com






      If you're from development and you want to make your organization go
      agile, I think


      On Wed, 12 Oct 2005 18:12:08 +0300, Robert Williams <robert0122@...>
      wrote:

      > I work in a small MIS department for a manufacturing plant. There are
      > only about 6 developers, and we usually each have our own project.
      > All our customers are internal.
      >
      > I want to start using some of the XP practices to help my personal
      > productivity. There is no support currently for XP among management,
      > so I'm limited in what I can do.
      >
      > Our current process involves a signed off requirements document,
      > although it does not have to be submitted until the code is submitted
      > for testing and deployment. There's not much of a detailed design
      > review. All code must be manually tested using a test plan written by
      > the developer. We're still very much in love with written documents
      > around here.
      >
      > I am thinking of documenting requirements as user stories and
      > estimating them in terms of hours, not points (as suggested in Extreme
      > Programming Explained, 2nd Edition). I thought I'd implement a weekly
      > development cycle, and update the requirements document and test plan
      > with the stories I implemented that week. I'll informally work with
      > my internal customers to prioritize stories, and give them access to
      > my development system as early as possible.
      >
      > I'll be able to do TDD, Refactoring, Simple Design, and maybe
      > Continuous Integration, although that last one is "iffy".
      >
      > I do not think I can my users to write automated acceptance tests, and
      > I will not be able to regularly do any pair programming since
      > management does not support this.
      >
      > Any advice on how to make this work or warnings of mistakes to avoid?
      >
      > Thanks,
      > Robert
      >
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >



      --
      Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
    • Robert Williams
      Dan, Thanks for your comments. I have a couple of questions. First, we have quite a few pieces of the system, and many (and the biggest) are not set up for
      Message 2 of 5 , Oct 12, 2005
        Dan,

        Thanks for your comments. I have a couple of questions.

        First, we have quite a few pieces of the system, and many (and the
        biggest) are not set up for any sort of automated testing. Even the
        version control tool we use for many applications does not support
        command-line interfaces. How can I go about implementing Continuous
        Integration? What's a good approach?

        Second, I am concerned that I'll build automated unit tests, but after
        I check the code in another developer will break the test (e.g., by
        changing an interface) and will just ignore the failed test (which
        I've seen happen) or delete it. Is there anything I can do?

        Thanks,
        Robert
      • Dan Bunea
        On Wed, 12 Oct 2005 22:22:11 +0300, Robert Williams wrote: I m no expert, however my recommendation would be: Try show why tests can be
        Message 3 of 5 , Oct 12, 2005
          On Wed, 12 Oct 2005 22:22:11 +0300, Robert Williams <robert0122@...>
          wrote:

          I'm no expert, however my recommendation would be:

          Try show why tests can be usefull to the other developers, show them how
          the tests can help them. If they can't be persuaded YET, go to plan B
          until they are, but my recommendation would be to try as much as possible
          to avoid it. Have your tests only for you, until you can convince the
          others how they are helping you. At some time, you will be more relaxed
          and this will show. If they ask why, you'll be able to prove it.

          My opinion is that if a system has more parts, the more recommended it is
          to have a CC tool. At least let it run every night. In the morning it will
          tell you if you broke something covered (or you're colleagues did). This
          feedback will allow you to see better your immidiate priorities. About
          support take a look at CC tools available. I don't know that language
          you're using to be able to tell you more. For us , we use .NET, and Cruise
          Control.NET. Where CC.NET couldn't keep up (compiling web apps) we used
          NAnt. So there are solutions.

          Another problem is from what I see working with legacy code (you seem to
          have a large project there). In some cases where I have to work with
          legacy code which have few or no automated tests, I discovered that a good
          approach is not to try to tests the untested code, but add tests as you go
          for the features that you're doing and for the bugs you're solving. This
          is the first step, in building the safety net of tests. It will grow and
          become more usefull as time passes.

          Thanks,
          Dan


          > Dan,
          >
          > Thanks for your comments. I have a couple of questions.
          >
          > First, we have quite a few pieces of the system, and many (and the
          > biggest) are not set up for any sort of automated testing. Even the
          > version control tool we use for many applications does not support
          > command-line interfaces. How can I go about implementing Continuous
          > Integration? What's a good approach?
          >
          > Second, I am concerned that I'll build automated unit tests, but after
          > I check the code in another developer will break the test (e.g., by
          > changing an interface) and will just ignore the failed test (which
          > I've seen happen) or delete it. Is there anything I can do?
          >
          > Thanks,
          > Robert
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          > Yahoo! Groups Links
          >
          >
          >
          >
          >
          >



          --
          Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
        • Kent Beck
          Robert, It sounds like you have a complete and workable plan for the changes you want to make. The only thing I can think to add to your list is to find
          Message 4 of 5 , Oct 12, 2005
            Robert,

            It sounds like you have a complete and workable plan for the changes you
            want to make. The only thing I can think to add to your list is to find
            someone to whom you can be accountable for the changes you are making. This
            might be a co-worker, a manager (these might not work from what you said), a
            technical friend, your spouse, someone on the net, or a trusted mailing
            list. Call your shots--tell this person or group what you are planning on
            doing and then tell them what you actually did, warts and all. I find being
            part of an accountability group keeps me on track even when I get scared and
            want to cut corners.

            Sincerely yours,

            Kent Beck
            Three Rivers Institute

            > -----Original Message-----
            > From: extremeprogramming@yahoogroups.com
            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
            > Robert Williams
            > Sent: Wednesday, October 12, 2005 8:12 AM
            > To: extremeprogramming@yahoogroups.com
            > Subject: [XP] Getting started with XP for personal development
            >
            > I work in a small MIS department for a manufacturing plant. There are
            > only about 6 developers, and we usually each have our own project.
            > All our customers are internal.
            >
            > I want to start using some of the XP practices to help my personal
            > productivity. There is no support currently for XP among management,
            > so I'm limited in what I can do.
            >
            > Our current process involves a signed off requirements document,
            > although it does not have to be submitted until the code is submitted
            > for testing and deployment. There's not much of a detailed design
            > review. All code must be manually tested using a test plan written by
            > the developer. We're still very much in love with written documents
            > around here.
            >
            > I am thinking of documenting requirements as user stories and
            > estimating them in terms of hours, not points (as suggested in Extreme
            > Programming Explained, 2nd Edition). I thought I'd implement a weekly
            > development cycle, and update the requirements document and test plan
            > with the stories I implemented that week. I'll informally work with
            > my internal customers to prioritize stories, and give them access to
            > my development system as early as possible.
            >
            > I'll be able to do TDD, Refactoring, Simple Design, and maybe
            > Continuous Integration, although that last one is "iffy".
            >
            > I do not think I can my users to write automated acceptance tests, and
            > I will not be able to regularly do any pair programming since
            > management does not support this.
            >
            > Any advice on how to make this work or warnings of mistakes to avoid?
            >
            > Thanks,
            > Robert
            >
            >
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.