Let’s Play Agile ! 12-09-15-testers_hub
•Download as PPT, PDF•
4 likes•465 views
The document discusses Agile software development methods. It defines Agile as iterative development methods that promote adaptive planning, evolutionary development, rapid response to change, and value interactions and collaboration over processes and tools. It describes common Agile frameworks like Scrum, which uses sprints, daily stand-ups, and artifacts like product backlogs to help teams self-organize and deliver working software frequently. The document contrasts traditional waterfall methods with Agile's emphasis on adaptability, collaboration, and rapid delivery of working software.
Report
Share
Let’s Play Agile ! 12-09-15-testers_hub
- 1. LET’S PLAY AGILE ! Atulya Krishna Mishra
- 2. ESSENCE OF AGILE ? In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment. —Charles Darwin
- 3. WHAT IS AGILE ? Agile software development is 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. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle Source : Wikipedia
- 4. WHAT IS AGILE ? “Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability” (Highsmith 2002).
- 6. AGILE MANIFESTO In 2001, a group of 17 “lightweight" methodologists met. The meeting also included the representatives of eXtreme Programming (XP) Scrum DSDM Adaptive Software Development ThE AGILE MAnIfESTo wAS wrITTEn
- 7. AGILE MANIFESTO Facilitating change is more effective than attempting to prevent it. Learn to trust in you ability to respond to unpredictable events; its more important than trusting in your ability to plan for disaster – Martin Fowler & Jim Highsmith As a result of the formation of the Agile Alliance in Feb 2001, 17 individuals came up with this manifesto • Individuals and Interactions over processes and tools • Working Software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan While we value the items on the right, we value the items on the left more
- 8. AGILE PRINCIPLES Satisfying customer is top priority Welcome changing requirements, even late in development Deliver working software frequently, from a couple of weeks to a couple of months Development teams and business work together Build projects around motivated people The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- 9. AGILE PRINCIPLES The primary measure of success is working software Agile processes promote sustainable development – The sponsors, developers and users should be able to maintain a constant pace in definitively. Continuous attention to technical excellence and good design Simplicity – the art of maximizing the amount of work not done—is essential The best architectures, requirements and designs emerge from self-organizing teams The Team regularly reflects on work
- 10. DOES AGILE REALLY WORKS ?
- 11. MYTHS ABOUT AGILE Myth#1 – Agile Development is undisciplined Myth#2 – Agile Teams do not plan Myth#3 – No Documentation, No Metrics Myth#4 – Compromise in Quality Myth#5 – Senior most people will lose their jobs Myth#6 – Self Organized Teams can do anything they want Myth#7 – Design and Architecture can be ignored
- 13. SCRUM OVERVIEW A play in Rugby in which the two sets of forwards mass together around the ball and, with their heads down, struggle to gain possession of the ball.
- 14. EMPIRICAL PROCESS The empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs
- 15. DEFINED PROCESS Laying out a process that repeatable will produce acceptable quality output is called defined process control.
- 16. EMPIRICAL PROCESS CONTROL 3 Legs of Empirical Process Control: Transparency - outcome must be visible to those controlling Inspection - various aspects must be inspected frequently Adaptation - must be adjusted if one or more aspects of the process are outside acceptable limits
- 17. •Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. •It allows us to rapidly and repeatedly inspect actual working software. •The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. •Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint. Scrum in 100 words
- 18. CHARACTERISTICS Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed One of the “agile processes”
- 19. SCRUM OVERVIEW
- 20. SPRINTS Scrum projects make progress in a series of “sprints” o Analogous to Extreme Programming iterations Typical duration is a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint
- 21. SCRUM FRAMEWORK 3 Roles o Product Owner (PO) o Scrum Master (SM) o Team 4 Ceremonies o Daily Scrum Meeting o Sprint Review o Sprint Planning o Sprint Retrospective 3 Artifacts o Product Backlog o Sprint Backlog o Increment
- 22. SCRUM ROLES
- 23. PRODUCT OWNER Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results.
- 24. SCRUM MASTER Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences
- 25. SCRUM TEAM Typically 5-9 people Cross-functional QA, Programmers , UI Designers, etc. Members should be full-time May be exceptions (e.g., System Admin, etc.) Teams are self-organizing What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility Membership can change only between sprints
- 26. SCRUM CEREMONIES
- 27. SPRINT PLANNING The Team and the Product Owner collaborate to help the Team determine how much Product Backlog it can turn into functionality during the upcoming Sprint. The Team create plans (Sprint Backlog) by identifying tasks for converting selected Product Backlog into functionality
- 28. SPRINT PLANNING Team selects items from the product backlog they can commit to completing Sprint backlog is created o Tasks are identified and each is estimated (1-16 hours) o Collaboratively, not done alone by the Scrum Master High-level design is considered
- 29. DAILY SCRUM MEETING Goal • Enable to team to share progress with each other • Make visible blocks (impediments) daily for whole team to see Everyone stands in a circle and reports 3 things • What did I do since the last Daily Scrum Meeting? • What will I try to do by the next Daily Scrum meeting? • What are my blockades? 15 minutes maximum No discussion or debate: listening only • After meeting ends, discuss and problem-solving can start Team and ScrumMaster only • Team can invite PO or others if they wish, but it‘s up to the team After the meeting, ScrumMaster leads the removal of blocks
- 30. SPRINT REVIEW Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal • 2-hour prep time rule • No slides Whole team participates Invite the world
- 31. SPRINT RETROSPECTIVE Periodically take a look at what is and is not working Done after every sprint Participants •Scrum Master •Team •Product owner (Optional)
- 32. SCRUM ARTIFACTS
- 33. PRODUCT BACKLOG The requirements A list of all desired work (Product Backlog Item) on the project Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner Reprioritized at the start of each sprint
- 34. SPRINT BACKLOG The Sprint Backlog defines the work the Team will perform to turn Selected Product Backlog items into a “Done” Increment. The list emerges during the Sprint. Each on going task identifies those responsible for doing the work Each Tasks has information about estimated amount of work remaining on the task on any given day during the Sprint.
- 35. INCREMENT The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” It must be in useable condition (Potentially shippable product)
- 37. More Rigid and Directions coming Top to Down Team may conduct dozens of experiments to see which works best More Commanding and Controlling style of Leadership Communication flowing freely between all the team members Spoon Feeding; Management tell everyone “What to Do” Self-Organizing; work is distributed with consensus by the Team itself Planning Centric and Plan Driven Plan could be very fluid in Agile world as Agile projects are more fluid then waterfall projects Document Oriented and Document Driven Cross functional, Self-Contained and Agile is ultimately pragmatic Resistant to Change Agile Projects are welcoming to change; true even changes are introduced late in the project Traditional Framework Agile Framework
- 38. Customer get involved early in the processes but tended to keep at arm’s length once the project begins Customer involvement is the key here as more closely involved at the time of work being performed Escalation to managers when problem arise When problems occur, team works together resolve them internally Heavy upfront analysis and design Daily stand-up meetings are held to discuss work done yesterday, plan of today and impediments if any More serious about processes than the product Agile methods less focus on formal and directive processes Product is planned extensively and then executed and tested Work is delivered to client in small and frequent releases to get rapid feedback loops Traditional models favors “Anticipation” Agile model favors “Adaption” Traditional Framework Agile Framework
- 39. Team Commits so early in the project before they can put their hands on Daily Stand-Up meetings are held to discuss work done yesterday, plan of today and impediments if any Heavy documentation before executing the work packages Agile Projects are highly democratic and implement a series of short and repeatable practices Slow and structured development process usually focus on one time release Agile is built on the concept of frequent and small releases known as “Incremental Delivery” in small chunks More focus on How than Why Agile more focus on Why and retrospective is held at the end of each Iteration or Release Ownership belongs only to the Project Manager Shared ownership Traditional Framework Agile Framework