Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Agree on user profiles
  2. Define scenarios for cognitive walkthroughs
  3. Define priority settings for reporting out (evaluators will go away do their evaluation and come back together to synthesize the results)

A Framework for the Inspection Process

The process we're putting together has a lot of autonomy in it, and great potential for imaginative discovery.  But we also want to achieve as much cross-pollination as we can between the teams, both in setting up the inspection plans and publishing the results.  The intention is that each of teams makes its own plan, but with lots of open discussion so that everyone can see what everyone else is doing and borrow each other's best ideas. This should be easy if we all use the wiki as our common forum for planning and discussing.
Let's consider what is common to all the teams. We can start with a description of what a "protocol" means in this context. Roughly, a protocol is is a specification of the tests, processes, scenarios, and goals that determine the procedure for an inspection or walkthrough; and a description of what information is to be captured.

From a team's point of view, the inspection process rests on three elements:

  1. A protocol that clearly specifies what we are going to do, and what information we are going to capture along the way.
  2. A predetermined clearly specified target that we are going to inspect: (product, version, instance, set of chunks) – the thing we're going to do it to.
  3. A report template specifying the format, style and content of the report of the information we capture.

Equipped with the right three elements, the teams will be able to:

  • Establish a baseline for each product, enabling us to measure the value of future enhancements
  • Identify pain points which can be addressed with near-term solutions
  • Merge their results in such a way as to be able to identify common issues susceptible to common solutions through common components.

The discovery of common issues with common solutions will be a big win for Fluid and should be kept in mind by everyone at all times as something to strive for.  General and reusable solutions have a value that goes far beyond addressing a pain point in a particular product.

Ideally, we can set things up so that each team can work with the three elements (protocol, target, report template) that work best for their product, but with as much sharing as possible and a minimum of re-invention. 

  • Teams assemble their protocols from the lists outlined by Clayton. If they plan to adopt or use others, these should be added to the common set.
  • Each team picks the best target for their investigation and defines it as precisely as possible
  • All teams start with the same reporting template.  If it is found to be constraining during the "team plan building" phase, enhancements can be made to thecommon version.

It's worth mentioning here that the inspections are bound to produce interesting information about each product that may not fit the report template and it will be up to the teams to find a way to communicate it to the rest of us – probably by recording their observations in the wiki..

Anchor
WorkingGroupCoordination
WorkingGroupCoordination
Working Group Coordination

...