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

145147Re: [XP] Software Risk - books help request

Expand Messages
  • Ken Boucher
    Sep 3, 2008
      --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
      <sgordonphd@...> wrote:

      > XP itself mitigates many major risks:
      >
      > Here are some examples:
      > * Sustainable Pace reduces the chance of somebody leaving during the
      project.
      > * Pair programming and Collective Code Ownership reduces the impact if
      > somebody does leave during the project.
      > * Test Driven Development, Automated Acceptance Tests and Continuous
      > Integration sharply reduces the half-life of bugs.
      > * Frequent Delivery of working software and On-site Customer reduces
      > the chance of developing the wrong software.
      > * Frequent Delivery of working software reduces the chance of being
      > surprised at what will be delivered on the due date.
      > * Frequent Delivery of working software guarantees that working
      > software will be available on the due date.
      >
      > Come to think of it, frequent feedback based on the frequent
      > delivery of working software is the best possible risk management
      > tool, because if we pay attention, we will see risks coming and be
      > able to plan for the ones that are coming using the current
      > information at the time.
      >
      > Compare this to the alternate approach of trying to anticipate all
      > possible risks and preparing a plan for each risk at the beginning
      > of the project when we have the least accurate information we will
      > ever have during the project. Planning for risks that will never
      > happen is a big waste of time and effort. Making plans for those
      > risks based on information that will be inaccurate when the risks
      > actually happen is a big waste of time and effort.

      I would like to add to this list the following additions.

      An XP project has more points in time for the customer to halt
      investment. Having the information to make a decision to suspend or
      stop a project at two months instead of six months may result in
      substantial savings.

      In addition, when that investment is halted, the customer does have a
      working something. It may not be enough of a something to be
      profitable and useful or it may be. And even if it's not completed
      enough when a project is halted, it's often in a state where it can be
      restarted with minimal waste (for some definitions of waste).

      The ability to save by stopping a failed project sooner, having a
      product to show for the money that was invested, and being able to
      restart from a product with shippable tested functionality, all serve
      to manage risk from a mitigation standpoint.
    • Show all 18 messages in this topic