Part of AtsGoesExtreme and the AtsDiary.

------

As part of UserStory estimation, we identified SpikeSolution''''''s for every story that we had questions about.  Since we're doing additional work on an existing project, many of our so-called SpikeSolution''''''s were actually just code diving or design explorations.  Only a few actually involve creating a working solution.

This definition of SpikeSolution doesn't seem to be quite the same as the ExtremeProgramming definition that it's based on.  But we're finding it to be very useful, as we often don't need to go all the way to code; we just need discuss the various ramifications of an issue or remind ourselves how the application works.

For ATS, I'm defining a SpikeSolution as "any research (not development) activity that reduces risk."  As I said, that may not be the 'pure' definition, but that's the definition that works for us.  But by shortcutting the definition in this way, we may be glossing over problems that will bite us later.

We listed our SpikeSolution''''''s on a card.  Here's some examples:

	* Explore security architecture in ATS (particularly for user story #26).  How will user info be passed around and enforced?  (Also, user proxying.)
	* Explore security DB arch.
	* Can a search window selection pop up another search window?
	* Prototype audit history window.
	* Review audit DB arch.
	* Check DB to see if it supports action item templates.
	* Find out the circumstances in which the save changes dialog appears.
	* Code action item tree for default action items.
	* Walk through session timeout design, DB arch.
	* Automatically clean up invalid session id's.