https://pastebin.com/9Ua5giHB


--------CHAPTER 1----------
Product Backlog
	Prioritized list of desired features
	Change be changed with feedback

Sprint
	Timeframe with development goals
	Anything left imcomplete is prioritized in the following sprint
	At the end of each sprint the team should have a potentially shipable product
		If the product needed to be shipped at anytime, the previously completed sprint should be usable.

	Sprint Backlog
		A mini-Product backlog just for the sprint

	Sprint Planning
		Product Owner talks about sprint goals

	Sprint Review
		1 hour per week
		Product is demoed to Team Owner and Stockholders for feedback

	Sprint Restrospective
		At the end of the sprint the team gathers to ask
			What went well?
			What didn't and how do we fix it?

Daily Scrum
	Questions
		What have you done since last Daily standup?
		Wht are you going to do until the next daily standup?
		What impediments are standing in your way?
	15 mins max

Roles
	Product Owner
		Create and Groom product backlog

	Scrummaster
		Advocate for team,
			Responsible for removing ipediments

	Development Team
		Responsible for implementing user stories

Benefits
	Delighted Customers
	Improved Return on Investment
	Reduced Costs
	Fast Results
	Scrum can best be applied to complex work
	Stakeholder's immediate Feedback

Waterfall
	Disadvantages
		No immediate Feedback
		Costly
		No way to pivot
		Lack customer interaction
--------CHAPTER 2----------
Plan Drive Sequential Development (PDSD)
	Good for well-defined, predictable projects unlikely to undergo signifigant changed
	All planning is done upfront (waterfall)

Agile Manifesto Values
	Individuals and Interactions OVER process and tools
	Working Software 			 OVER Comprehensive Document
	Customer Collaboration		 OVER Contract Negotiation
	Responding to Change		 OVER Following a planning

	Principle 1: Variablility and Uncertainty
		"Variability is good" Principle
		Create a single instance of a product rather than multiple
		Employ Iterative and Incremental Development
			Iterative: 		Things will get worse before they get better
			Incremental:	Build some before you build all
		Uncertainties - To be reduced
			End Uncertainty: Uncertanty around final product
			Means Uncertainty: Uncertainty around the process to making the final product
			Customer Uncertainty: Uncertainty about what customer wants.
	Principle 2: Prediction and Adaption
		"Change is good" principle
		The later changes are made to the product the more expensive it is.
			Work harder earlier in development so change is cheaper
	Principle 3: Validated Learning
		->Inspect->Adapt->Assume->Build->Feedback->REPEAT
	Principle 4: Work in Process
		Small Batches > Big Batches
			>>>>ASK PROFESSOR WHAT IS A BATCH<<<<
			>>>ALSO ASK WHAT IS REDUCED FLOW VARIABILITY<<<
			>>>CHAPTER 2 SLIDE 15<<<
			Why Smaller Batches are Better:
				Less time waiting for work to be done
				Faster Feedback
				Less Overhead
				Easier for teammembers to stay focused/see impact of their work
				Easier to schedule
		100% worker utilization is bad (makes team inflexible)
	Principle 5: Progress
		"Measure progress" principle
		Focus on Value (money) of product in terms of progress
	Principle 6: Performance
		"Fast is good, quality is better" principle
Cost of Delay
	Delays cost money, can you believe it.
	"Focus on Idle Work not Idle Workers."

--------CHAPTER 3----------
Sprint (revisited)
	Duration should be consistent

	Time Boxing
		"Good enough" is often enough
		Improves predictability of work being done

		Reasons to change duration of sprint
			Product releasing before sprint ends
			Holidays
			Check if maybe the feedback from even shorter sprints is worth it

		Unacceptable reason to change duration of sprint
			Team needs more time to fulfill sprint goals.

		Cadence
			Rhythm of work

		Velocity
			The amount of work that can be completed in a sprint

			Allocation
				Each work day (10 for 2 weeks) is a story point
				Enough work to fill 80% of your story points should be allocated.
					ie: 1 month sprint should allocate 16 story points

		Short Period of Time
		Easier to plan/Get Feedback
		Short Term success/gratification
		Bounded Error
			If something goes wrong, it goes wrong in a small way.

	Checkpoints (sprint reviews)

Sprint Goal
	"Do this and that" <- What the goal should be
	Should be a "Business prupose"
	Should be refined during Sprint Planning

	Change vs Clarification
		Change: "You idiot I wanted it this way" - Customer
		Clarification: "Hey are did you want this a specific way?" -Devs

	Change causes dev team motivation and trust to deteriorate

	No Goal Altering Changes
		This is a rule and certain situations can negate this rule

Sprint Termination

	Abnormal Termination
		Sprint has been made invalid
		Termination is immediate
		Restrospective is performed immediately
		New Sprint Planning is performed immediately
		Next Sprint maybe variable length

	Definition of "Done"
		Potentiall Shipable (I know you've heard it a dozen times)
		Product has a "State of Confidence"
			I guess this means you believe in the product
		Completes a "checklist"
			checklist here is the series of tasks that actually dictate when the code is done
				things like testing, debugging and acceptance tests.
		The definition can evolve over time

--------CHAPTER 4----------
Sequential Product Development
	Provide specific details in what software needs to do.

Sequential Development
	ie: Waterfall
	Each development stage is rigid/static

Bidirectional Communication
	People who are not on the scrum team communicate with people who are on the scrum team.
	Conversations get more specific as progressive refinement kicks in

User Stories

	Artifacts
		Alternative Documents used to support or replace user stories
		EX1: Artifact
			Bug report instead of user story
		EX2: Supporting Artifact
			UI Sketch to acompany the user story.

	Level of Detail
		Epic
			Think Lord of the Rings, an Epic story happens over months
		Feature
			Think multiply, feature that takes several sprints
		User Story
			"Sprintable"
		Tasks
			Can make up a User story, done in hours.
		Neumonic
			EF U R N
			"F" you right now

	Characteristics of User Story
		Independent
			No dependencies
		Negotiable
		Valuable
			To user
		Estimatable
			Should be competeably in a sprint

			!!!!!!Ask professor what he means by this
			http://i.imgur.com/OtbmrOX.png
		Small
		Testable

		Neumonic
			INVEST

	Nonfunctional Requirements
		The "-itities"
		Such as reliability, availability, portability, scalability, usability, maintainability
		Does not have to fit the user story template (I <ROLE> WANT TO <FEATURE> SO I CAN <BENEFIT>)

	Knowledge Acquisition
		Tasks or stories that are new to the team's methodology.
			ie: Learning to create a new feature, Proof of concepts, prototype construction
		Owner must be able to estimate the cost of knowledge aquisitions to weight whether it is worth doing.

	Gathering User Stories
		Writing workshops (with customers)
			Brainstorming with Team+Owner+Stakeholders

			Personas
				Role Playin customers

			Top-Down approach
				Start at Epic and widdle down to User Story

			Bottom-Up approach
				Collect User stories and synthesize them into Epics

		Story Mapping
			One for each Epic
				Goes like this:
				Epic->Theme->Story
				http://i.imgur.com/8O1UsyK.png
				aka: Activity->Task->Subtask (Some guy named Patton)

		Other methods
			Focus Groups
			Surveys
			Customer Voting

--------CHAPTER 5----------
***************************
PBI - Product Backlog Items
	Desired business values to be implemented

	Progressive Refinement
		Go from vague to specific as PBI's "approach a sprint"

		!!!!!!!!
		Ask professor what "approach a sprint" means
		http://i.imgur.com/wfDqiaI.png

	Item Types
		User Story Template:
			Feature
			Change
		User Story Template Without Role:
			Defect
		Do not user User Story Template:
			Technical Work
			Knowledge Aquision

	DEEP - Product backlog Item Characteristics
		Detailed (See refinement)
			Epics should decompose in advance into sprint-ready items (ie: Usable at a moment's notice)
		Emergant (Changing)
		Estimated
			Bigger Items should sink near the bottom or be refined into smaller items
			Smaller the item, more accurate the estimate
		Prioritized
			Should be done for the next new sprints, less important for items near bottom of PB

***************************
Backlog Grooming
	Updating items in the PB
	Ensures items are ready to be put into a sprint
	***Done by Product Owner
	***10% of team's time spent grooming
	***Can occur once a sprint, once a week or even daily
	Little to No Grooming in Waterfall

	Ready Checklist
		List of things defined by team before an item can be moved into a sprint
		ie: Appropriately staffed

Must Have's and Nice to Have's
	Labels for PB items
	Higher items should be Must Have's

Wont have's
	Items that are below the release cut-off time.

Piplining
	Team should have 2 or 3 weeks work of User stories ready to go.

Hierarchical Backlogs
	The team's backlog is a subsection of items from a larger back log
	http://i.imgur.com/VHHgeoX.png
	Any team would ideally only work on a single backlog


--------CHAPTER 6----------

Velocity
	Rate of tasks team can get done
		Work not value
	Assign a point value to items in the backlog
	Observe how many points a week your team completes
	http://i.imgur.com/EzOapya.png

Duration
	Given a number of item points and a velocity
	You can derive the amount of time an item should take

Estimations
	Value: Are not commitments

	Use Relative Size

	Ideal Days:
		Not the same as calendar days,
			work days can be interrupted
			number of staff members per day changes
Initial Velocity
	Start with what the team thinks it can do and go from there

Plateauing
	Most velocities increase and eventually plateau

Do not use as a performance metric
	Causes "gaming the system"

Sprint Burndown
	History of Velocity
	Measured by
		Y=Remaining Effort
		X=Days
	http://i.imgur.com/k4mfGH0.png
--------CHAPTER 7----------

Technical Debt
	Bad code that while not rewritten taxes the team's productivity and owner's money

	Examples:
		Unfit design
			No longer a viable, not adapted to change in system
		Defect
			Problems known about but not removed
		Insufficient Test Coverage
			Testing that wasn't done
		Excessive Manual Testing
			Forcing the team to test manually instead of automatically
		Poor Inegration and Release Management
			Code poorly integrated
		Lack of platform experience
			limited techincal skills on part of team

	Types
		Naive
			Immaturity of team members

			!!!!!!!!!
			Ask professor what the context is for "Immaturity"

			Cure
				Training

		Unavoidalbe
			Unpredicted and unpreventable

		Strategic
			Taking a shortcut to achieve a short term goal

	Failing to Pay Technical Debt
		Difficult to code new features
		Difficult to innovate (become more efficent)

	***************************
	When should you pay technical debt?
		When you can test Refractor Code
		When you can test integration of code
		When you can perform regression testing
			Regression testing
				Testing to make sure software that interacts with other changed software still performs as well as it used to.

	Consequences: NOT ON MIDTERM REVIEW
		Tipping Point
			Point where product is unmanagable
		Increase Time to delivery
		Signifigant Number of Defects
		Rising development and support costs
		Atrophy
			Not adding new features becomes the norm
		Decreased predicatablilty
		Underperformance (reduced expectation)
		Frustratition
			Trust in dev team errodes
		Decreased Customer Satisfaction



Managing Debt
	Stronger Definition of Done
		Helps reduce technical debt

	Test Driven Development
		Dev writes testing software before writing the software

	Code Reviews between developers

	Make technical deb visible to developers

Approaches for Servicing Debt
	Discard
		Not all debt needs to be repaid, a product nearing the end of its lifetime.
	Boy Scout Rule - You see it, you fix it.
	High Interest Debt First
	Incremental
		Little by little every sprint
	Do it while doing customer valuable work
		work payment into new work.

--------CHAPTER 7----------

Product Owner:
	Participate in Planned Activities
	Groom PB
	Define Acceptance Criteria and Verifying they are met

	Skills
		Domain Skills

		!!!!!!!!
		What is this?

		People Skills
		Decision Making Skills
		Accountability

	Hierarchical PO
		levels of Product Owners for
			Feature
			Product Line
			Chief (overseer of all other product owners)

Scrum Master
	Coaching
	Process Authority

	!!!!!!!!
	What is this?

	Impediment Remover

	http://i.imgur.com/nJKe8jN.png

	Scrum Master can work for multiple teams in lieu of working as a dev

Dev Team

	Role Specific Teams
		Instead of having team members split into departements which hand off work to one another
		Scrum Dev Team members should attempt to work independantly during a sprint

	Responsibilities
		Planning Sprint
		Executing
		Inspection and Adapting
		Grooming Product Backlog

		!!!!!!!!!
		Wasn't this this PO's Job??

	T-Shaped Skills
		Work Outside Core Area
		Speciality

----------Chapter 8----------
Scrum Team is made up of Scrum Master, Dev Team and Product Owner

Product Owner Roles
	Defining Acceptance Critieria
	Grooming Product Backlog
	Participating in Planned activities

Scrum Master
	Helps organization design scrum approach
	Process Authority
	Impediment remover
	Should not be also be part of dev team or PO.
	Can server for multiple teams.

Vertical Slices of work
	Dont create departments that hand off work to the next departments

Dev Team
	Plans the Sprint
	Grooms the product backlog

T-Shaped Skills
	Broad - Ability to work outside of core area
	Deep - Specializing

----------Chapter 9----------

Portfolio Backlog Items
	Composed of products, programs, projects or high level epics.
	A backlog of high level items.

Portfolio Planning
	Determins which Portfolio backlog items to work on
	Never Ends
	Determines whether to fund the product

People who take part in planning
	Stakeholders
	PO
	Senior architects
	Techinal Leads

Questions
	For new products
		Cost?
		How long to finish?
		Value?
		Risks?

	For existing products
		***Customer feedback?
		***Technical Debt levels
		costs?
		Schedule?
		Marked data?

Inflow Strategies
	Knowing when to add items into portfolio backlog

Outflow Strategies
	Knowing when to pull products out of profolio backlog
	Establish a WIP limited
	Wait for a complete team.
		Unless it requires multiple teams then start when a whole team is available.

In-Process Strategy
	Knowing when to pivot or terminate existing product.
	Avoid bottlenecks by using smaller frequent releases
	Embrace Emergent Opportunity
		ie: being first to market

Scheduling Strategy
	Calculate costs of delay
	Estimate for accuracy not prcision due to limited data.

	Types:
		Linear - Costs increase at fixed rate.
		Large Fixed Costs - A product that accrues a large single costs
		Must do now - Cost of delay is massive
		Fixed Date - Product must be deliverable by a fixed date.
						Costs of delay must occur only after the date.
		Logarithmic - cost of delay accrus very early with increasingly less delay thereafter.
		Intangible - A product has no cost of delay for a long time but suddenly accrues a very high delay cost.



Weighted Shorted Job First

WSJF = COST OF DELAY / DURATION

----------Chapter 10----------
Principles of Kanban
	Visualize your work
		use state diagrams
	Limit your WIP
	Measure Flow

Cards
	Cards represent a piece of work to be done and is placed on a kanban board.
	Contains info:
		Unique ID
		Task Name/Description
		Person task is assigned to
		Estimate
		!!!!!!
		Deadline

Kanban board
	Board which cards are posted which represent states
		Ranging from backlog to done.
		http://i.imgur.com/mOiNZ7z.jpg
	WIP limits on board
		http://i.imgur.com/tLcmZei.jpg
	Swim Lanes
		A card may not go through the exact same states as other cards.

Lead Time and Cycle Time
	Lead time is the time from when a bug was reported to when it was fixed.
	Cycle time is the time from when the dev started working on the bug and when it was fixed.

Cumulative Flow Diagram
	Measures how much work falls within lead time, cycle time.
	States include done, started and queued.
	http://i.imgur.com/NlbDUGT.jpg

Throughput
	Measure of the number of items that were delivered in a time period.
		Delivered means in the "Done" column of Kanban board.

----------Chapter 11----------
UML - Unified Modeling Lanague
	Notation that resulted from unification of Object modeling Lanague

	OMT - Object Modeling technique
	OOSE - Object Oriented Software Engineering

	You can solve 80% of modeling problems using 20% UML

Modeling
	System can be decomposed into subsystems and subsystems of subsystems.

	A model people can understand should contain 5 to 9 parts.

	Falsification
		proving relavent details have not been represented properly


Diagrams
	http://i.imgur.com/43MF72Z.jpg
	Use-Case
		Functional behavior as seen by user.

		Actors
			An entity (user, external system, physical environment)

		Text Fields
			Name
			Participating Actor: (Role)
			Entry Condition: (What the actor does to start the interaction)
			Exit Condition: (What the actor's condition is like after the interaction is over)

		Extends Relations
			Uncommonly invoked Use Cases
			Not included in the work flow
				Example: User cancels transaction.
				http://i.imgur.com/XFRiY50.jpg

		Includes Relationship
			Relationships where a functionality is needed in more than one use-case
			http://i.imgur.com/IljOGWH.jpg

	Class Diagrams
		http://i.imgur.com/XfHRNrV.jpg
		http://i.imgur.com/zw391KP.jpg
		Describe the static structure of the system
			Objects, attr, operations and associations.

		Associations
			Relationships between classes

		http://i.imgur.com/FBceN9E.jpg

		Aggregation
			Shows parent and children classes

			Composition
				An aggregate which lives as long as both the parent and child lives
				removing one destroys the whole aggregate
			Qualifier
				http://i.imgur.com/zpyd13H.jpg


	Sequence Diagrams
		Behavior of objects in the system
		http://i.imgur.com/K29nhEg.jpg
		Focus on Control Flows
		http://i.imgur.com/uLjFaVf.jpg
		http://i.imgur.com/98fhe4P.jpg


	State Chart Diagrams
		Behavior of an individual objects
		FSM (theory of alg) where functions or actions are on each edge
	Activity Diagrams
		Workflow of a system
		FSM http://i.imgur.com/smqRpYe.jpg
		Splitting http://i.imgur.com/oKgW0Cy.jpg

----------CHAPTER 12----------
System Design
	is the process of defining architectures, subsystems and interfaces to satisfy specific requirements

Software Architecture
	Describing system in terms of subsystems

Boundary Use cases
	Describing system configuration, starup, shutdown, and exception handling

Coupling
	Measures dependency among two subsystems

Cohesion
	Measures dependecies among classes within a subsystems

Relating Subsystems
	Layer
		Hiearchy of subsystems
	Partitioning
		Subsystem peers

*****A GOOD DESIGN HAS HIGH CHESION AND LOW Coupling
	ND: HIGH CHESION LIKE MR TRUMP LOL


----------CHAPTER 13----------
Questions when testing
	Does it work as:
		Intended?
		Correct input?
		Incorrect input?
		Scaling data?
		Scaling userbase?
		With other systems?

States:
	Failure
		Any deviation in behavior from the specified behavior
	Erroneous State
		System is in a state that can lead to Failure
	Fault
		Mechanical or Algorithmic cause of error.
	Validation
		Checking for deviations between observed behavior and specified behavior.

Test Driver:
	Simulates part of the system

Test Stub:
	Sumulate a component that is called by tested compenent.
	Must return a value complient with the return signature.

Fault avoidance
	Reduce complexity

Fault detection
	Testing
	Debugging
	Monitoring

Fault Toleratnce
	Exception handling
	modular redundancy
	!!!!!!!

Testing should be done by independent testers
	Programmers are biased

Unit Testing
	Done by developer
	Goal: Confirm subsystem is correctly coded and carries out the intended functionality

Integration Testing
	Done by developers
	Testing interfacing between subsystems.

System Testing
	Done by developers
	Testing the entire system to make sure it meets requirements.

	Functional Testing
		Test functionality of system
	Performance Testing
		Test non-functional requirements
			like purposely doing things wrong to see how the system reacts
			Call receive() before send()

Acceptance Testing
	Carried out by client.
	Demonstrate that system meets requirements of client.

Regression Testing
	Carried out by test engineers
	Determine if modifications to particular component have introduced faults in other components

Automation Testing
	Testing carried out by automatically testing framework.

Black Box Testing
	Focuses on I/O behavior
	If we can can predict the output the component passes the test.
	Testing in done in three equivalence classes:
		Below the range
		Above the range
		Within the range

Bottom-Up testing Strategy
	Subsystems in the lowest layer of the call hierarchy are tested individually
		Next subsystems are tested that call the previously tested subsystems.
	http://i.imgur.com/NK5iMQB.jpg

	Pros:
		Useful for object oriented systems
		Useful for real-time systems

	Cons:
		Drivers needed
		***Uses interface last

Top-Down testing Strategy
	Test the top layer first
		Then test all systems without the top layer
		http://i.imgur.com/MrcjtOd.jpg

	Pros:
		No driver needed
		Test cases definedi n terms of functionality of system

	Cons:
		Writing stubs is difficult

Sandwich Testing Strategy
	Combines top-down and bottom-up
	Has 3 layers
		Target Layer -> Middle Layer
		Layer above target
		Layer below target

	http://i.imgur.com/bGEOQDs.jpg
	I guess middle layer here is the target