CPSC 3720 - DAY 25
APRIL 21, 2017

================================================================================

				EXTREME PROGRAMMING
				-------------------

Common Agile Methodology
Often referred to as XP
Very flexible with the rules and practices, so there are many variations.

Values:

	Simplicity - Do what is needed, but no more.
	Communication - Work as a team on everything
	Feedback - Every iteration produces a deliverable system
	Respect - Everyone respects each other/ expertise
	Courage - Honesty about expectations

Rules based on 5 categories

	Planning
	Managing
	Designing
	Coding
	Testing

Planning

	User stories are focused on what the user can do in the system.
	Short, 2 or 3 sentences
	Not too detailed
	Drives creation of acceptance tests

	Release planning creates the release schedule
		Lays out the overall project
		Development team estimates the time to complete each user story
		Customer prioritizes the user stories
		Together they decide what stories are implemented in each
		release
		Project Velocity - how many story points per iteration

	Make frequent small releases
		At the end of each iteration
		Should be a functional system.
			Even if the functionality requires user to know SQL,etc

	Project is divided into iterations.
		One to three week iterations
		Iteration length should be the same for each iteration.
		Plan the details of the iteration at the beginning of that 
		iteration.
		Do not look ahead to add functionality from a later iteration.

	Iteration planning starts each iteration
		User stories for each iteration decided during release planning
		Stories broken down into tasks that support them
		Tasks are in the developers language
		Developers sign up to complete tasks
		Recheck estimate with project velocity and adjust if necessary

Managing
	
	Give the team a dedicated open work space
		Large space with no barriers
		Computers in the middle are unowned and used for pair
		programmming
		Computers along the walls for individual work (non-programming)

	Set a sustainable pace
		Pace should allow system to be fully developed and tested by
		end of iteration
		Rushed code will lead to future problems and wasted time
		No overtime
		Keep velocity realistic
		Adding more developers slows down progress

	A stand up meeting starts each day
		Most people do not contribute in a typical meeting
		Stand in a circle for face to face communication
		Stand to keep the meeting short.
		Developers report 3 things.
			What was accomplished yesterday?
			What will be attempted today?
			What problems are causing delays?
		Any other details can be handled in other meeting with only 
		people who need to be there

	Project Velocity is measured
		Add up the number of stoy points in last iterations
		Compare to estimates and planned stories
		This is the assumed velocity for the next iterations
		Don't divide by the size of the team or length of iteration.

	Move people around
		Avoid knowleghe loss and bottle necks
		Cross training is important.
		Cannot have "_______" guys, everyone must know the whole system
		Change the pairs in pair programming
		Each individual task may run longer, but scheduling is easier
		and you save time in the long run.

	Fix XP when it breaks
		Make XP work for your team
		When rules are set, they must be followed until the team agrees
		to change them
		At the end of each iteration, discuss if any changes are
		necessary.

Design

	Simplicity is the key.
		Subjective
		Don't add extra feature yet
		Four qualities to use to judge code:
				
			Testable - can easily make unit and acceptance
				tests.	
			Understandable - It is clear how the code works
				and what everything does.
			Browseable - be able to easily find a part of 
				the system.
			Explainable - Understandable to people outside
				of the team.

	Choose a system metaphor
		Simple metaphor to describe your design
		Keep functions and names consistent with the metaphor.
		System metaphor can be used to describe the system to a new
		developer withous huge amounts of documentation.