Difference between revisions of "Cruise missile"

From Pearl Language
Jump to navigation Jump to search
(Zeroth version.)
 
(Forces += educes designers, developers and testers to closely work together or {{p|swarm}} during implementation)
 
(6 intermediate revisions by the same user not shown)
Line 6: Line 6:
|wish=Hitting a moving target is both more effective and efficient.
|wish=Hitting a moving target is both more effective and efficient.
|so=Stabilize the specification above a certain threshold, minimize the items lead time, and follow any and all changes in the spec while the item is in progress.
|so=Stabilize the specification above a certain threshold, minimize the items lead time, and follow any and all changes in the spec while the item is in progress.
|wish full=Getting the item done as quickly and efficiently as possible, ensuring that it passes all tests (done done) even when the requirements and specifications change while the item is in progress. That is, how can you hit a moving target.
|image=Cruise-missile-path.png
|wish full=Getting the item done as quickly and efficiently as possible, ensuring that it passes all tests and is {{p|ready to ship}}, even when the requirements and specifications change while the item is in progress. That is, how can you hit a moving target?
|background===Forces==
|background===Forces==
*If the moving target outpaces the implementation effort, you will never hit it—it outpaces and ‘outcompetes’ you.
*If the moving target outpaces the implementation effort, you will never hit it—it outpaces and ‘outcompetes’ you.
*A more stable target is easier to hit.
*A more stable target is easier to hit.
*Incorporating any changes in the spec while the item is in progress—like a cruise missile—often is a shorter path than nudging it after it hits the original target.
*Incorporating any changes in the specification while the item is in progress—like a cruise missile:
**often is a shorter path than nudging it after it hits the original target; and
**educes designers, developers and testers to closely work together or {{p|swarm}} during implementation.
*Responding to change is a core value of the {{p|agile manifesto}}.
*Responding to change is a core value of the {{p|agile manifesto}}.
*Shorter lead times make following and hitting the moving target easier (more effective and efficient)
*Shorter lead times make following and hitting the moving target easier (more effective and efficient).
*Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item:
*Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item:
**refer to a specific revision of the spec;
**refer to a specific revision of the spec;
**include a copy the relevant parts of the spec (‘copy on write’).
**include a copy the relevant parts of the spec (‘copy on write’).
|therefore full=Only start working on an item if the specification is stable beyond a minimum level. Include the item’s stability measure in the {{p|ready to build}}. Follow any and all changes in the spec while the item is in progress.
|therefore full=Only start working on an item when the specification is stable beyond a minimum level and when the effort to implement it is expected to be below a couple of days—{{p|small is beautiful}} and {{p|ka-ching a day makes product owner hurray}}. Include the item’s stability measure in the {{p|ready to build}}. Follow any and all changes in the specification while the item is in progress.
|new=Consider to track the number of spec changes while the item is in progress. Trigger a {{p|retrospective gathering}} if it exceeds a predetermined threshold (for example, 3). Tighten up your {{p|ready to build}} to get the {{p|user story}} more stable, hence a lesser moving and volatile target.
}}
}}

Latest revision as of 09:56, 16 May 2014

Cruise-missile-path.png

…working on getting items ready to ship, that is, tested and accepted according to functional and technical design.

✣  ✣  ✣

Getting the item done as quickly and efficiently as possible, ensuring that it passes all tests and is ready to ship, even when the requirements and specifications change while the item is in progress. That is, how can you hit a moving target?

Forces

  • If the moving target outpaces the implementation effort, you will never hit it—it outpaces and ‘outcompetes’ you.
  • A more stable target is easier to hit.
  • Incorporating any changes in the specification while the item is in progress—like a cruise missile:
    • often is a shorter path than nudging it after it hits the original target; and
    • educes designers, developers and testers to closely work together or swarm during implementation.
  • Responding to change is a core value of the agile manifesto.
  • Shorter lead times make following and hitting the moving target easier (more effective and efficient).
  • Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item:
    • refer to a specific revision of the spec;
    • include a copy the relevant parts of the spec (‘copy on write’).

Therefore:

Only start working on an item when the specification is stable beyond a minimum level and when the effort to implement it is expected to be below a couple of days—small is beautiful and ka-ching a day makes product owner hurray. Include the item’s stability measure in the ready to build. Follow any and all changes in the specification while the item is in progress.

✣  ✣  ✣

Consider to track the number of spec changes while the item is in progress. Trigger a retrospective gathering if it exceeds a predetermined threshold (for example, 3). Tighten up your ready to build to get the user story more stable, hence a lesser moving and volatile target.


✣  ✣  ✣