CS 458 - Week 5 Lecture 1 - 2016-09-20

*   MMM Ch. 3 - Surgical Team
    *   "cruel dilemma"
        *   conceptual itegrity -> a FEW good minds doing DESIGN
        *   timely completion -> need a way to bring considerable
	                         programming effort to bear

*   a little more focus:
    USER STORIES!

    *   written from the customer's point of view,
        in the customer's language
    *   things the system needs to do from their
        point of view
    *   in the format of about 1-3 sentences
        of text
    *   ALSO include an estimate (it can be rough!)
        of how long the programmers think it will
	take to accomplish

    *  ideally, these are written on index cards (!)

    *   the user story is the "unit" of functionality
        in an Extreme Programming projects

    *   you are NEVER DONE writing (and/or modifying) user stories
        during the course of a project;
        *   some WILL be thrown out (client discovers they
	    don't want them after all)
	*   some WILL be modified
	*   some may be added!

    *   and when a user story is determined to be too
        big, it should be "broken up" into smaller
	user stories...

*   according to Beck and Fowler -- "Planning Extreme Programming"
    a user story should be:
    *   UNDERSTANDABLE to customers *and* developers
    *   TESTABLE  <- acceptance testing!
    *   VALUABLE to the customer
    *   SMALL ENOUGH so that the developers can build
        HALF a DOZEN in an iteration
	*   (ok, for CS 458, I'll settle for less than
	    half a dozen -- but at least 3...!)

        *   note what this implies about the 
	    granularity of user stories! NOT too "big",
	    not too "high level", and not "nebulous"

    *   do you see that a user story is a CHUNK of functionality
        that is of value to the customer?

	*   provide a more-practical way for developers
	    and customers to CHOP UP what a desired system
	    needs to do, so it CAN be develivered
	    in useful, functional, deliverable pieces

    *   ideally, in Extreme Programming, it sounds like the
        customer actually writes these --
	the CS 458 team will be writing these,
	based on the client's perspective
	(probably with instructor's approval...!)

    *   emphasis on SIMPLE is ESSENTIAL!

    *   "So, as we look at stories,
         remember that the point is to make them TOO simple
	 to work in the hope that we MIGHT just get away
	 with it" <-- verbatim, BUT I added the emphasis;

    *   "pretend" as much as possible that user stories
        are independent of each other (yes, we they aren't
	always...)

*   in an ideal world, 
    *   customers propose a story, [thus, it should be valuable
        to them, else why would they propose it?]
    *   developers ask themselves if the story can
        be tested and estimated,
	and if it is of appropriate size,
	...can't be estimated? ask the customer to clarify the story
	...too big? developers ask the customer to split the story
    
*   when are you DONE writing stories?
    ...never, or at least until the project is cancelled (!!)
    *   may be MOST PROLIFIC early on, but does not end!

    *   when do you have enough stories to start developing?
        *   when the customer is reasonably sure that the
	    MOST important stories have been developed
	    (keeping in mind they may be wrong... 8-) )

	*   you have enough for several months worth of
	    development (for CS 458, I want at least a 
	    few more than you can complete during the
	    semester...)

        *   there should be enough so that the customer
	    can make meaningful choices

    *   and remember: FLUX in the user stories is NORMAL
        and expected in agile approaches!