CS 458 - Week 4 Lecture 1 - 2016-09-13

*   there are a number of approaches
    in the "Agile" category;

    ...we will mostly be focusing
    on the Extreme Programming
    approach from this category;

*   some key principles:
    *   developing software in small iterations
    *   use a working system as the measure of
        progress
    *   "embracing change"

    *   getting to Extreme Programming in particular:
        *   must have rapid system development
        *   must have customer involvement
	    *   early and frequent communication
	        with the customer
        *   must be extreme in avoiding defects
        *   all the programmers in the team
	    "own" all the code
        *   must be extremely respectful of people
	    and of their personal, social,
	    and psychological needs

    *   and how does this work?
        *   there are a collection of practices
	    which are intended to work in synergy
            towards the above goals;

        *   use of user stories for requirements
	    specifications
        *   pair programming for producing code
        *   test-first or test-driven or test-infected
	    development
	    (those are SLIGHTLY different...)
            *   in all, writing unit tests of code
	        BEFORE writing the code
	    *   writing acceptance tests to
	        determine if software meets
      		or satisfies user stories
        *   frequent integration of code
        *   having SIMPLE designs that are
	    REFACTORED when needed;

	    "do the simplest thing that could
	    possibly work"

*   here's a list of SOME of the practices
    often grouped under Extreme Programming:
    *   short iterations
    *   common, shared vocabulary - in older references,
        called metaphor, but requiring an overall
	simple image of the system didn't work
	well in practice; so, shared vocabulary
	is more accepted now
    *   coding standards
    *   something on the continuum of
        test-driven to test-first (or test-infected) development
        *   in either, writing tests THEN writing code
        *   unit test of each "chunk" of code
        *   acceptance tests to determine if
	    user stories for an iteration are
	    satsified
    *   pair-programming
        *   potential benefits:
	    *   all design decisions involve at least
	        2 minds
	    *   at least 2 people familiar with every
	        part of the system
	    *   less chance of both in a pair neglecting
	        tests or other tasks
            *   changing pairs spreads knowledge through
	        the team
	    *   code is always being reviewed by
	        at least one person

    *   refactoring - making changes/improvements
        to *working* code
    *   collective code ownership
    *   continuous integration - rather than going
        a "long" time between changing code and
	integrating it into the latest version...?
	*   more on this later;

    *   YAGNI - "You Aren't Going to Need It"
        *   simple design
	*   "do the simplest thing that could
	    possibly work"
	*   but many are not comfortable with
	    emergent design

    *   40-hr-work-week - people cannot program
        well and creatively and robustly
	long term at 60, 80 hrs/week

	...they need lives outside of work;
	...increases productivity at
	   work, then
    
    *   user stories 
    *   the planning game/ release planning
        *   based on the latest release,
	    and the user stories still to be
	    implemented,
	    negotiate which will be implemented
	    in the next release

    *   acceptance testing 
    *   frequent, small releases
  
    *   something on the continuum from
        an on-site customer to at least an
	involved customer      
  
    *   CRC cards - if object-oriented programming
        *   class, responsibilities, and collaboration
        *   determining each class's responsibilities
	    (in an object-oriented design),
	    and which other classes each uses/collaborates	
            with
    *   stand-up meetings/daily, informal meetings

*   planning game/release planning
    *   imagine you have this concept of user stories
        *   they COULD be written by the customer --
	    describing, in 1-3 sentences, something
	    a user of the system can do,
	    in terms they can understand
        *   often accompanied by a ROUGH estimate
	    of how long the programming team
	    THINKS each will take to implement

   *   the programmers and the users negotiate
       which user stories are reasonable
       to implement in the next release,
       and when it would be feasible to complete
       that release by;

*   why test early?
    why write tests BEFORE writing the code?
    *   yes, unit tests ARE written before
        writing the code being tested;
    *   you have to test sooner or later --
        testing sooner focuses/clarifies your
	thinking
    *   if you can't write a specific test --
        do you really understand what you are
	trying to do?
    *   (more likely to write better, more
        thorough tests when do so early --
	less likely when FINALLY got the
	code to compile...!)