ABC of Agile (Scrum & Extreme Programming)

2,621 views

Published on

What is Agile
Agile Principles
Agile Myths

Scrum
- Scrum Roles
- Sprint Planning
- Sprint
- Sprint Cycle
- Daily Standup
- Sprint Review
- Sprint Retrospective
- User Story
- Velocity
- Estimation
- Story Points
Extreme Programming
- Pair Prograaming
- Unit Testing
- Coding Standards
- Continous Integration

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,621
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
79
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

ABC of Agile (Scrum & Extreme Programming)

  1. 1. 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........
  2. 2. 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.
  3. 3. Traditional “Waterfall” Approach Detailed Design Detailed Design ConceptConcept BuildBuild
  4. 4. Agile Process Concept Detailed Design Detailed Design Build Build Detailed Design Detailed Design Build Build Sprint Review Sprint Review Sprint Review Sprint Review Agile processes are based on a contionous process of Design it, Build it, Test it, Ship it.
  5. 5. 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
  6. 6. 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)
  7. 7. Scrum & Extreme Programming
  8. 8. Scrum Principles ✔ Time-boxes ✔ Cross-functional teams ✔ Open communications – Within team – With stakeholders ✔ Priorities set by Product Owner ✔ Demonstrable results ✔ Responsive to change
  9. 9. Scrum Roles - 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
  10. 10. 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
  11. 11. 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
  12. 12. Product Backlog
  13. 13. 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
  14. 14. 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
  15. 15. Burnup Charts
  16. 16. 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
  17. 17. Daily Stand-up
  18. 18. 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
  19. 19. 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
  20. 20. Sprint Retrospective * Meeting with Sprint Team - May include Product Owner * Process review and modification * Lessons learned applied in following Sprints * Techniques – Mute Mapping – Brainstorming
  21. 21. Mute – Mapping Technique
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. Prioritizing Requirements - MoSCoW
  28. 28. Agile Estimation Agile Estimation
  29. 29. 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.
  30. 30. 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
  31. 31. 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
  32. 32. Extreme programming
  33. 33. 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
  34. 34. Pair Programming * Better Code * Collective Code Ownership * Mentoring * Increased discipline * Improved morale * Team cohesion
  35. 35. 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!
  36. 36. Coding Standards • Code Integration • Team Member Integration • Maintenance • Uniform Problem Solving • Minimizes Communication • Minimizes Performance Pitfalls • Saves Money Due to Less Man Hours
  37. 37. 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
  38. 38. 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
  39. 39. Q & A

×