Day 2 - Agile Process¶
by Mike Robinson
Introduction¶
Agile is a conceptual framework
Agile does have documentation
Agile methods have been around since the 1990s and were united by the agile manifesto.
Agile empowers the workers
Agile knows their finished when they are finished
Agile is:
- Like driving a race car, you know the course but can’t account for all the variables
Agile Values¶
- Individuals and interactions > process and tools
- Working software > comprehensive documentation
- Customer collaboration > contract negotiation
- Responding to change > following a plan
- Planning is more important than plans
Agile Principles¶
- Highest priority is to satisfy the customer
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
- Deliver working software frequently. 90% completion is a lie. Its either not started, working, or finished. If you do not deliver working software you are of no value.
- Business people and developers must work together daily
- Build projects over motivated people
- Give developers the support they need and trust them to get the job done
- Working software is the primary measure of growth.
- Information is best done in face-to-face conversation
- Agile processes promote sustainable development by not overworking people to meet deadlines.
- The sponsors, developers, and users should be able to maintain constant speed.
- Simplicity is really awesome. Code is a liability to any organization. The less code you can deliver the better.
- The best architecture, requirement, and designs emerge from self-organizing teams.
- At regular intervals the team reflects on how to become more effective, then adjusts its behavior accordingly.
Why use agile?¶
- Agile lets you meet what the marketing folks want to give to customers
- Agile means good for business so you can plan out hours better
- Operations likes it because your updates are simpler
- Development likes it because it empowers developers
Developers need to be respected¶
- Don’t agree on schedules without developer input
- Don’t agree on tasks without developer input
- Developers need to be honest in describing what needs to be done
- Get developers to demo their work to the customer!
Charging for the assessment phase¶
- Bill for it
- Tell customers that you’ll bill for planning as long as the customer is willing to pay
Roles on a team¶
- Product owner: Drives the project
- Project Manager: Handles the resources
- Team: Developers
- Stakeholders: Customers
- Users: obvious
Artifacts¶
- Impediment list (use stickies on the wall to be obvious)
- Project iteration
- Working code
Agile requirements analysis, estimating and planning¶
Identify the users
Gather requirements from the users via
- Interviews
- Questionnaires
- Observation
- workshops
Ways of documenting
Use cases fixed the ATM returning cards after cash
- too big to plan for and measure with
- prone to include UI details
User stories
- a tiny bit of information.
- You can attach these to use cases
Estimating development
Prediction is difficult!
You will never be 100% accurate
Short efforts on estimates are accurate
Long efforts on estimates are always off
Breakdown tasks into manageable chunks
Estimation performed by development team
Deriving an estimate
- Expert opinion
- Analogy
- Planning poker
Story points are a relative measure of size of a story. 10 points is more than 5.
Ideal time it would take to complete a task without interruptions. A football game is 60 ideal minutes and 120 minutes with interruptions
Planning poker
- Each member gets six cards
- People put the value they think it will take down on the table. The most common value is how long it will take in story points.
- If one person has things way off, then talk out why there is a discrepancy
- After each task has point assigned, figure out how long a point is worth. Use previous effort to determine the length of a story point.
Prioritizing user stories
- Priority assignment is the primary responsibility of the Product Owner
Velocity
Measure the rate of progress of a team
Amount of story points completed in the last iteration
Next iteration = same as last iteration (“yesterday weather”)
velocity corrects estimation error
Accommodate developer optimism
Burndown chart
- Plots the amount of committed effort left against the time left to complete the iteration
Agile planning game