4. From Wikipedia:
Its a group of software development methods based on
iterative and incremental development, where
requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams........
5. Manifesto for Agile Software Development
`We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
Individuals and interactions - over processes and tools
Working software - over comprehensive documentation
Customer collaboration - over contract negotiation
Responding to change - over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
10. Being Agile – What's involved ?
Goal
Deliver high
value, high
quality
working s/w
quickly &
frequently
Ceremonies
Training
Release Planning
Iteration Planning
Daily Stan-up
Review / demo
Retrospective
Techniques
Iterations
User stories
Co-location
Task board
Burn chart
Planning Poker
Done-done-done
Pairing
Unit Test
Continous integration
Participate
Fundamentals
Short feedback
loops
Inspect &
adapt
Collaboration &
teamwork
11. Agile Myths
- No documentation
- No scope management
- No design
- 100% automation
- Only iterative development
- No architecture
- No strick deadline
(I can change my mind whenever I want to)
16. Roles
* Scrum Master
Not “command & control” project manager
Process coach and team facilitator
Remover of roadblocks
* Scrum Team
Individuals responsible for the Sprint results
Mix of skills representing multiple disciplines
Usually 6-8 individuals
* Product Owner
Individual responsible for product
Responsible for product profitability (ROI)
Adjusts feature list and priorities for each Sprint
Accepts or rejects work results
* Users & Stakeholders
Interested in results but not responsible for deliverables
17. The Sprint
* Time boxed effort
Usually 2 weeks to 1 month
Can be longer or shorter
* Defined workload
No changes once Sprint is begun
* Begins with Planning Meeting
* Ends with demonstrable Release
20. Product Backlog
* All features and functions for final product
* May be subdivided into releases
* Prioritized by Product Owner
* Initial backlog is established and releases are defined prior to start
of Sprints
* Product backlog is reviewed and updated throughout the project
* Time must be allotted during Sprints to allow for this activity
21. Sprint Backlog
* Features and functions targeted for a single Sprint
- Frequently broken down into User Stories;
Especially if function is complex
* May include technical requirements or objectives
- e.g.; database design, UI standards, architecture
documentation
23. Sprint Planning
* Product Owner and Team
* Review of Product Backlog
* Product Owner provides definition and details of features and functions
* Negotiation of what will be in Sprint
* May identify new Product Backlog needs
* Results in Sprint Goals
25. Daily Stand-up
* Standup 15 minute meeting
* Each team member answers 3 questions:
- What have you done since the last meeting?
- What will you do before the next meeting?
- What is preventing you from accomplishing your tasks?
* For benefit of other team members
* Not a “status report” to the ScrumMaster
26. Sprint Review
* Results of Sprint are demonstrated to Product Owner
* Owner accepts or rejects results
* Results are input to:
- Next Sprint Planning meeting
- Sprint Retrospective
27. Sprint Retrospective
* Meeting with Sprint Team
- May include Product Owner
* Process review and modification
* Lessons learned applied in following Sprints
* Techniques
– Mute Mapping
– Brainstorming
29. INDEX CARD 4”X6”
Three Parts (3 Cs)
Card
Conversation
Confirmation
User Story
I N V E S T
The acronym INVEST stands for,
I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T - Testable
30. User Story
Provides a simple medium for
– Gathering basic information about stories,
– Recording high-level requirements,
– Developing work estimates, and
– Defining acceptance tests
Acts as agreements between customers and team
members to discuss detail requirements during an
iteration
31. Example : User Story Card (Formal)
As a <role>,
I want <goal/desire>
so that <benefit>
As a
Who wants this piece of functionality
I want
What the user wants
So that
Why the user wants it
As an employee, I want to purchase a parking pass so that I can
park my car safely in the basement and save money.
Priority : 8
Estimate : 4
32. Theme and Epic
Theme is a set of related user
stories that may be combined
together and treated as a single
entity for either estimating or release
planning
Epics are large user stories with
lower priority. They are too big to
implement in a single iteration and
therefore they need to be
disaggregated into smaller user
stories at some point
33. Velocity
* Velocity is a measure of a team’s rate of
progress per iteration.
* It is calculated by summing the number
of story points assigned to each user
story that the team completed during
the iteration
Question :
The project team completes four stories in one iteration,
Story A – 5, Story B – 3, Story C – 7, Story D – 5. Calculate the Velocity?
Answer :
Summing up the story points assigned to each user story gives the velocity.
Hence velocity = 5+3+7+5 = 20
36. Estimating Size with Story Points
Story Points are the unit of
measurement for expressing the
overall size of a user story,
feature, or other piece of work.
37. Story Points
The “bigness” of a task is influenced by,
• How hard it is (complexity)
• How much of it there is (effort involved)
• How risky it is
Relative values are what is important:
• A login screen is a 2, A search feature is an 8.
Estimate using the relative values
• Select the smallest story and estimate as 1 story point
• Select a medium-sized story and estimate it as 5 story points
38. Planning Poker
An iterative approach to estimating
Steps
- Each estimator is given a deck of
cards, each card has a valid
estimate written on it
- Customer/product owner reads a
story and it’s discussed briefly
- Each estimator selects a card
that’s his or her estimate
- Cards are turned over so all can
see them
- Discuss differences (especially
outliers)
- Re-estimate until estimates
converge
40. Extreme programming has been described as following practices
Fine scale feedback
- Pair programming
- Test-driven development
Continuous process
- Continuous integration
- Refactoring or design improvement
- Small releases
Shared understanding
- Coding standards
- Collective code ownership
- Simple design
Testing
- All code must have Unit tests
- All code must pass all Unit tests before it can be released.
- When a Bug is found tests are created before the bug is addressed
XP
42. Unit Testing
* Unit Testing reduces the level of bugs in production code.
* Unit Testing saves you development time.
* Automated tests can be run as frequently as required.
* Unit Testing makes it easier to change and refactor code.
* Unit Testing can improve the design of code especially with
TDD.
* Unit Tests are a form of documentation.
* Unit Testing inspires confidence!
* Unit Tests are a measure of completion.
* Unit Testing is FUN!
43. Coding Standards
• Code Integration
• Team Member Integration
• Maintenance
• Uniform Problem Solving
• Minimizes Communication
• Minimizes Performance Pitfalls
• Saves Money Due to Less Man Hours
44. CI
* Say goodbye to long and tense integrations
* Increase visibility which enables greater communication
* Catch issues fast and nip them in the bud
* Spend less time debugging and more time adding features
* Proceed in the confidence you’re building on a solid foundation
* Stop waiting to find out if your code’s going to work
* Reduce integration problems allowing you to deliver software
more rapidly
45. CI – Reminder / Rules
* Check in frequently
* Don’t check in broken code
* Don’t check in untested code
* Don’t check in when the build is broken
* Don’t go home after checking in until the system builds
-----
* Maintain a Single Source Repository
* Make Your Build Self-Testable
* Every Commit Should Build the Mainline on an Integration Machine
* Keep the Build Fast
* Everyone can see what's happening
* Automate Deployment
-----
* Detect integration errors as quickly as possible
* Assumes a high degree of tests
* Always have a deployable build
* Generate metrics to guide project management
* Continuous Integration is Vital for Agile Development