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

Re: [XP] Struggling with how to fit QA in

Expand Messages
  • Steven Gordon
    On the other hand, if you are in an organization where the real customer can only use a new feature in production after a long, tedious, bureaucratic
    Message 1 of 31 , Dec 5 10:59 AM
      On the other hand, if you are in an organization where the real customer can
      only use a new feature in production after a long, tedious, bureaucratic
      deployment process, then the QA delay probably has no affect on value flow
      except in the last iteration of a release.

      In such a case, Kent's argument needs to be applied to the deployment
      process before being applied to the QA process. The argument for
      leaning/integrating the QA process then comes down to shortening feedback
      loops instead of value flows.

      Steven Gordon

      On 12/5/05, Kent Beck <kentb@...> wrote:
      >
      > Denis,
      >
      > I wonder if the programmers' perspectives would change if you worked
      > backwards from "real customer successfully uses new feature" instead of
      > forwards from "programmer writes line of code". I use a process called
      > value
      > stream mapping borrowed from lean manufacturing to visualize such
      > situations. What are all the activities that take time before the real
      > customer successfully uses a new features, and what are the points in the
      > process where the code is simply waiting? You can draw the current picture
      > and then draw a desired future picture. From the example below, I would
      > have
      > a box labelled "programmer writes code" followed by a wait of up to an
      > iteration followed by "tester tries code, reports defect" followed by some
      > wait time followed by "programmer fixes code" followed by more waiting
      > followed by "tester verifies fix" followed by a bunch more waiting (the
      > rest
      > of the release) followed by "real customer successfully uses new feature".
      > From there you can figure out for yourselves if that is the picture you
      > want
      > or if it would be more efficient to somehow bring the tester into the
      > iteration (for example, by writing story tests in advance). Maybe testing
      > N-1 is so much better than waiting and testing a whole release at once
      > that
      > the current situation is fine for everyone but you.
      >
      > Sincerely yours,
      >
      > Kent Beck
      > Three Rivers Institute
      >


      [Non-text portions of this message have been removed]
    • Steven Gordon
      On the other hand, if you are in an organization where the real customer can only use a new feature in production after a long, tedious, bureaucratic
      Message 31 of 31 , Dec 5 10:59 AM
        On the other hand, if you are in an organization where the real customer can
        only use a new feature in production after a long, tedious, bureaucratic
        deployment process, then the QA delay probably has no affect on value flow
        except in the last iteration of a release.

        In such a case, Kent's argument needs to be applied to the deployment
        process before being applied to the QA process. The argument for
        leaning/integrating the QA process then comes down to shortening feedback
        loops instead of value flows.

        Steven Gordon

        On 12/5/05, Kent Beck <kentb@...> wrote:
        >
        > Denis,
        >
        > I wonder if the programmers' perspectives would change if you worked
        > backwards from "real customer successfully uses new feature" instead of
        > forwards from "programmer writes line of code". I use a process called
        > value
        > stream mapping borrowed from lean manufacturing to visualize such
        > situations. What are all the activities that take time before the real
        > customer successfully uses a new features, and what are the points in the
        > process where the code is simply waiting? You can draw the current picture
        > and then draw a desired future picture. From the example below, I would
        > have
        > a box labelled "programmer writes code" followed by a wait of up to an
        > iteration followed by "tester tries code, reports defect" followed by some
        > wait time followed by "programmer fixes code" followed by more waiting
        > followed by "tester verifies fix" followed by a bunch more waiting (the
        > rest
        > of the release) followed by "real customer successfully uses new feature".
        > From there you can figure out for yourselves if that is the picture you
        > want
        > or if it would be more efficient to somehow bring the tester into the
        > iteration (for example, by writing story tests in advance). Maybe testing
        > N-1 is so much better than waiting and testing a whole release at once
        > that
        > the current situation is fine for everyone but you.
        >
        > Sincerely yours,
        >
        > Kent Beck
        > Three Rivers Institute
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.