CS 435 - Week 4 Lecture 2 - 2014-02-14

*   considering the practices of XP we discussed
    earlier (W3-2)

    IN TERMS of the CS 435 TEAM PROJECTS...

    *   frequent releases/small release <- WILL BE DOING
    *   system metaphor/common vocabulary
        *   we'll be going with common vocabulary;
        *   I'll likely be asking you to somehow
	    write this down;

        *   e.g., for GotWhich, an organizer
            is someone who makes a new list,
	    and an organizee signs up on the list

        *   notice -- this is BOTH for the team
	    AND the client(s)

    *   coding standards  <--- WILL BE DOING, within each
                               team

    *   testing/test-driven development/test-first
        development       <--- WILL BE TRYING, BUT KLUGILY
        *   unit testing
        *   acceptance testing

    *   pair programming  <-- SHOULD BE DOING

    *   refactoring <-- SHOULD BE DOING

    *   collective code ownership <-- WILL BE DOING

    *   simple design/YAGNI/"do the simplest thing
        that could possibly work" <-- SHOULD BE DOING

    *   40 hour work week/sustainable pace <-- NO GUARANTEES,
    	   	     		      	   BUT I HOPE SO
					   [ACADEMIC STYLE]

    *   user stories <-- DEFINITELY, more on that in a
                         moment

    *   planning game/release planning <-- DEFINITELY

    *   on site customer/customer involvement <-- AT LEAST
    	   			  	          SOMEWHAT

    *   continuous integrations <-- HOPEFULLY (and CAREFULLY)

    *   CRC cards <-- MAYBE
    *   stand-up meetings <-- RECOMMENDED, not sure if they'll	
    		 	      be officially documented...
    *   spike solutions <-- IF APPLICABLE

MORE about USER STORIES...
*   from Kent Beck and Martin Fowler, "Planning Extreme Programming",
    Addison-Wesley, 2001, Chapter 11, "Writing Stories"

*   the unit of functionality in an XP project
*   written in a language the client can understand!
    (user MIGHT write at least some of these,
    user DEFINITELY needs to DEFINITELY read them...!)

*   often 1 user story/index card
*   short -- 1-3 sentences
*   testable
*   valuable to the customer
*   small enough that the programmers can reasonably
    build a number of them in an iteration/release
*   in theory, independent (even though they really
    often aren't)

*   pp. 51-52: 
    *   "When have you done enough user stories to begin developing?

        When the customer is certain that the MOST important stories
        have been identified and you have enough stories for several
        months' worth of development." [!!]  

    *   "There should be enough stories so the customer can make
        meaningful choices."

*   they are a work in progress -- split, modified, added to,
    removed from, throughout the life of the project!

    *    "Not only is this normal; it is the WHOLE POINT of XP.

    *    The aim is to deliver software that matches the requirements at
         every release,
         
         NOT to match the requirements as they were MISUNDERSTOOD at
         the beginning of the project."