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........
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 toolsWorking software - over comprehensive documentation
Customer collaboration - over contract negotiationResponding to change - over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Traditional “Waterfall” Approach
DetailedDesign
DetailedDesign
Concept Concept
Build Build
Agile Process
Concept
DetailedDesign
DetailedDesign
Build Build
DetailedDesign
DetailedDesign
Build Build
SprintReview
SprintReview
SprintReview
SprintReview
Agile processes are based on a contionous process of Design it, Build it, Test it, Ship it.
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
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)
Scrum&
Extreme Programming
Scrum Principles✔ Time-boxes
✔ Cross-functional teams
✔ Open communications
– Within team– With stakeholders
✔ Priorities set by Product Owner
✔ Demonstrable results
✔ Responsive to change
ScrumRoles
- Scrum Master- Scrum Team- Product Owner- Stakeholders
Sprint
Artifacts- Product Backlog- Sprint Backlog- Burn down / up charts
Meetings- Sprint Planning- Daily Stand-up- Sprint Review- Sprint Retrospective
Roles* Scrum Master
Not “command & control” project managerProcess coach and team facilitatorRemover of roadblocks
* Scrum TeamIndividuals responsible for the Sprint resultsMix of skills representing multiple disciplinesUsually 6-8 individuals
* Product OwnerIndividual responsible for productResponsible for product profitability (ROI)Adjusts feature list and priorities for each SprintAccepts or rejects work results
* Users & StakeholdersInterested in results but not responsible for deliverables
The Sprint
* Time boxed effortUsually 2 weeks to 1 monthCan be longer or shorter
* Defined workloadNo changes once Sprint is begun
* Begins with Planning Meeting
* Ends with demonstrable Release
Product Backlog
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
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
Burnup Charts
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
Daily Stand-up
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
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
Sprint Retrospective
* Meeting with Sprint Team- May include Product Owner
* Process review and modification
* Lessons learned applied in following Sprints
* Techniques– Mute Mapping– Brainstorming
Mute – Mapping Technique
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
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
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
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
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
Prioritizing Requirements - MoSCoW
Agile Estimation
Agile Estimation
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.
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
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
Extreme programming
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
Pair Programming
* Better Code* Collective Code Ownership* Mentoring* Increased discipline* Improved morale* Team cohesion
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!
Coding Standards
• Code Integration
• Team Member Integration
• Maintenance
• Uniform Problem Solving
• Minimizes Communication
• Minimizes Performance Pitfalls
• Saves Money Due to Less Man Hours
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
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
Q & A