Intro to Agile
•Télécharger en tant que PPT, PDF•
1 j'aime•3,136 vues
Agile development is an iterative approach to software development that values individuals and interactions, working software, customer collaboration, and responding to change over following a strict plan. It utilizes short development cycles called sprints that are typically 2-4 weeks to deliver working, tested software increments. Key roles in Scrum, a common Agile framework, include the self-organizing development team, Scrum Master who facilitates the process, and Product Owner who represents customers and priorities features. The team works from a backlog of features, breaks them into tasks, tracks progress on a board, and demos working software daily to integrate customer feedback into future sprints.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Intro to Agile
Similaire à Intro to Agile (20)
Dernier
Dernier (20)
Intro to Agile
- 1. Introduction to Agile Development
- 3. 3 What is Agile Development? • Self Organizing* • Empowering • Collaborative • Active Customer Involvement • Frequent Delivery • Incremental • Time-Based* • Disciplined • Continuous Integration* • Feature Driven • Adaptive • Goal Driven • Iterative • Lean • Emergent Approach
- 4. 4 Traditional “Waterfall” Approach Months to working deliverable software
- 5. 5 How Agile Differs from Traditional Development Approach Traditional – Sequential Method Agile – Iterative Method
- 6. 6 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 Customercollaborationover 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. http://agilemanifesto.org/
- 7. 7 Agile Principles • Customer satisfaction by rapid, continuous delivery of useful software • Working software is the principle measure of success • Changes in requirements are anticipated and welcomed • Close, daily cooperation between business and developers • Face-to-face conversation is the best form of communication • Self-organizing teams • Regular adaptation to changing circumstances
- 8. 8 Agile Development Includes… • Continuous Innovation and Integration Deliver current customer requirements • Decreased communication latency Stakeholders actively involved in development • Testing integrated into the development process Doesn’t need or include a separate QA cycle Continuous integration, multiple builds • Product adaptability Doesn’t preclude future requirements Adapts to changing requirements
- 10. 10 What is Scrum? • An Agile process for software development • Projects progress via a series of iterations called “sprints” • Each sprint is typically 2-4 weeks in duration • Scrum Team typically includes 5-9 people with cross-functional skills • Scrum Master facilitates the process
- 11. 11 Scrum Team • Responsible for product delivery • Cross-functional Skills • Self-organizing • Daily face-to-face communication • Small size helps foster collaboration
- 12. 12 Scrum Master • No t the Team Leader • Acts as a buffer between the team and any distracting influences • Facilitates the process • Helps remove obstacles to team’s sprint delivery goals • Ensures team focus • Not responsible for the teams delivery
- 13. 13 Product Owner • Key stakeholder • Represents the voice of the customer • Identifies customer-centric requirements • Ensures Scrum Team work is aligned with needs of the business • Creates “User Stories” • Prioritises the “Product Backlog”
- 16. 16 Story Creation Story A User Story is a simple statement about what a user wants to do with a feature of the software, written from a user's perspective. All stories should be Independent, Negotiable, Valuable, Estimable, Small, Testable Story Points Relative size of stories vs. each other Sized by the team and used to understand capacity and estimate schedules
- 19. 19 Product Backlog • Master list of desired product functionality • Initiates the development process • High priority items are used to create the Sprint Backlog • Product Backlog grows and changes as more information is acquired
- 20. 20 Product Backlog - Example
- 21. 21 Sprint Planning Meeting • Assess team availability and capacity for next iteration • Review prioritized backlog – commit to deliver stories • Turn stories into a series of tasks for iteration • Ownership of tasks along with risks
- 22. 22 Sprint Backlog Example of Sprint Backlog in Excel • Lists tasks that will be completed during current sprint • Items drawn from Product Backlog
- 23. 23 Burndown Chart • Used to approximate conclusion of estimated backlog of work • Each point in the chart represents a sprint
- 24. 24 Daily Meetings • Brief (10-15 min) daily meeting • Assures continual team communication • Drives accountability (peer-pressure, visibility) • Demonstrates day-to-day progress to all team members and stakeholders
- 25. 25 Identifying Potential Obstacles • My ____ broke and I need a new one today. • I still haven't got the software I ordered a month ago. • I need help debugging a problem with ______. • I'm struggling to learn ______ and would like to pair with someone on it. • I can't get the vendor's tech support group to call me back. • Our new contractor can't start because no one is here to sign her contract. • I can't get the ____ group to give me any time and I need to meet with them. • The department VP has asked me to work on something else "for a day or two."
- 26. 26 Scrum Board
- 27. 27 Scrum Board - Example
- 28. 28 Sprint Review Meeting • Review the work that was completed and not completed • Present the completed work to the stakeholders (a.k.a. "the demo") • Incomplete work cannot be demonstrated • Feedback is reviewed and put back into backlog • Use to continually stay on course – deliver higher business value • Two hour time limit
- 29. 29 Retrospective meeting • Team reviews iteration successes and short falls • What could be done different in subsequent iteration? • Build in continuous improvement to agile process • Vital to success of agile development
- 30. 30 Summary of Agile Advantages • Get to see working Software every 2 weeks • Implement by feature not by task (design, code, test) • Feedback to development team sooner • Collaboration with customer – deliver only what’s needed • Quality as part of process – testing is continuous • Continuous improvement built into cycle Agile Projects are 37% Fasterto Market than Industry Average* *QSM Associates
- 31. 31 Further reading… http://www.mountaingoatsoftware.com/blog/ - Mike Cohn (Agile, Scrum, TDD) http://www.carlbruiners.com - Carl Bruiners (Agile, Scrum, Kanban, BDD) http://dannorth.net - Dan North (Agile, BDD) http://www.threeriversinstitute.org - Kent Beck (Agile, XP) http://scrum.jeffsutherland.com - Jeff Sutherland (Agile, Scrum) http://www.clarkeching.com - Clarke Ching (Agile, TOC, Scrum) http://theagilepirate.net - Simon Cromarty (Agile, Scrum, Kanban, BDD) http://cognitive-edge.com/blog/author/19/ - Dave Snowden (Future of software development)
Notes de l'éditeur
- Self organising teams – Teams that organise their backlog, manage themselves, etc… Time-based – Not always depends on the Agile methodology – Kanban is not time boxed, but the cycle times of stories is a time based measurement Continuous Integration – Whilst an XP practice, you can do Agile without Continuous Integration Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("sprints") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly.
- Hard dates at each phase – 1 slip and project is late did not meet the real needs (although they met the specifications) and many required extensive rework" to be usable When issue is found could be weeks to months after implementation. Waste of relearning/task switching Each phase dependent on the previous. Each phase needs information from the following phases to be fully complete. For example, requirements phase needs information from design phase as to what is feasible; design phase needs feedback from coding phase as to which design has the best chances of succeeding No feedback between phases. It is a hard task to get people specialized for each phase, as well as make sure that they are connecting with each other for proper information transfer
- One of the biggest problems with waterfall is that it assumes that all project requirements can be accurately gathered at the beginning of the project. The waterfall methodology assumes that up-front planning is enough to take into account all variables that could impact the development process. Waterfall therefore equates software development to an assembly line; defined processes can be established that, when used sequentially, result in a successful project each time. The first step is X, the second is Y, and the result is always Z. Agile development works on a completely different premise. Agile development works on the premise that requirements change and evolve. Almost no software system is so simple that the development can be entirely scripted from beginning to end. The inherent uncertainty and complexity in all software projects requires an adaptive development plan to cope with uncertainty and a high number of unknown variables. The simple ability to revisit the “phases” of development dramatically improves project efficiency. The idea of revisiting phases over and over is called “incremental and iterative development” (IID). The development lifecycle is cut up into increments or “iterations” and each iteration touches on each of the traditional “phases” of development.
- The Agile Manifesto is a statement of the principles that underpin agile software development. It was drafted in 2001 when representatives of various new methodologies (such as Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature Driven Development, and Pragmatic programming) met to discuss the need for lighter alternatives to the traditional heavyweight methodologies.
- The manifesto spawned a movement in the software industry known as agile software development. Some of the principles behind the Agile Manifesto are: Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances
- Scrum is an agile process for software development. With Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements. A scrum team is typically made up of between five and nine people, but Scrum projects can easily scale into the hundreds. The team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. The ScrumMaster role is typically, but not always, filled by a project manager or a technical team leader. The ScrumMaster is responsible for making sure the team is as productive as possible. The ScrumMaster does this by facilitating the Scrum process, by removing impediments to progress, etc.
- The scrum team has the responsibility of delivering the product. A team is typically made up of 5–9 people who do the actual work (design, develop, test, technical communication, etc.). Team composition is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements. Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single location which facilitates such communication. Typically small team size, help make team communication and team collaboration easier.
- Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster's role is to protect the team and keep them focused on the tasks in hand. The ScrumMaster also protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint.
- The product owner is often someone from product management or marketing, and is the project ’s key stakeholder. The Product Owner represents the voice of the customer, as they provide the perspective of users, customers and other stakeholders in the process. He/she ensures that the Scrum Team works on the "right things" from a business perspective. The Product Owner writes customer-centric items (typically referred to as “user stories”), prioritizes them and then places them in the product backlog. The product backlog is a collection of User Stories that the product owner prioritizes by business value.
- This graphic provides an overview of the essential elements of Scrum agile software development. On the left, we see the product backlog, which has been prioritized by the product owner and contains everything wanted in the product that ’s known at the time. The 2-4 week sprints are shown by the larger blue circle. At the start of each sprint, a sprint planning meeting is held during which the product owner prioritizes the product backlog, and the scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to the sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint. Each day during the sprint, team members meet to discuss their progress and any impediments to completing the work for that sprint. This is known as the daily scrum, and is shown as the smaller blue circle. This meeting helps set the context for each day ’s work and helps the team stay on track. All team members are required to attend the daily scrum. At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of an informal demonstration of the new features.
- Invest is important as it helps ensure the story backlog is in the best shape to be worked on by the team
- Moral of the slide – Don’t play larger sized stories in a sprint, as there are too many unknown, unkowns
- The Product Backlog is the master list of all functionality desired in the product , and is used as an input to begin the development process. The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog. In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains focused on the goal of that sprint. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requirements. Typically, a Product Owner documents everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
- Product backlog items can be technical tasks ("Refactor the Login class to throw an exception") or more user-centric ("Allow undo on the setup screen"). A very interesting prospect is expressing Scrum backlog items in the form of Extreme Programming's User Stories. Here is an example of a Product Backlog. This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates have been developed by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints.
- At the beginning of the sprint cycle, a "Sprint Planning Meeting" is held. The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives. During the sprint planning meeting the product owner describes the highest priority features to the team. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog. The product owner doesn't have to describe every item being tracked on the product backlog. Depending on the size of the backlog and the speed of the team it may be sufficient to describe only the high priority items, saving the discussion of lower priority items for the next sprint planning meeting. Typically, the Scrum team will provide guidance when they start to get further into the backlog list than they know could be done in the next sprint. Collectively, the Scrum team and the product owner define a sprint goal, which is a short description of what the sprint will attempt to achieve. The success of the sprint will later be assessed during the Sprint Review Meeting against the sprint goal, rather than against each specific item selected from the product backlog. After the sprint planning meeting, the Scrum team meets separately to discuss what they heard and decide how much they can commit to during the coming sprint. In some cases there will be negotiation with the product owner but it will always be up to the team to determine how much they can commit to completing.
- The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features. It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to. The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. An example of the Sprint Backlog in Excel looks like this.
- During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done. The estimated work remaining in the sprint is calculated daily and graphed, resulting in a burndown chart like this one. A Project Burndown Chart can be utilized to estimate the eventual conclusion of an estimated backlog of work. Each point of the chart represents an iteration - or Sprint - and the Y-axis represents the total estimated effort remaining for the backlog. As iterations progress, a trendline can be established through the points to create a velocity (work the team can complete per iteration). The trendline can then be extrapolated to determine the X-intercept, which represents the empirical estimate of the completion date.
- On each day of a sprint, the team holds daily meetings This is called a "daily scrum", or "the daily standup". Meetings are typically held in the same location and at the same time each day. Ideally the daily scrums are held in the morning as they help set the context for the coming day's work. All team members are required to attend the daily scrum. Anyone else (for example, a departmental VP, a salesperson, or a developer from another project) is allowed to attend but is there only to listen. This makes the daily scrums an excellent way for a Scrum team to disseminate status information--if you're interested in hearing where things are at, attend that day's meeting. The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions: What did you do yesterday? What will you do today? Are there any impediments in your way? The daily scrum is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. If a programmer stands up and says "Today I will finish the data storage module" everyone knows that in tomorrow's meeting he will say whether or not he did finish. This has the wonderful effect of helping a team realize the significance of these commitments and that their commitments are to each other, not to some far-off customer or salesman.
- Any impediments that are raised become the ScrumMaster 's responsibility to resolve as quickly as possible. Some typical impediments are listed here. In cases where the ScrumMaster cannot remove these impediments directly (e.g., usually the more technical issues) he or she still takes responsibility for making sure someone on the team does quickly resolve the issue.
- The scrum board shows all the work we ’re doing during a sprint. We update it continuously throughout the sprint. If someone thinks of a new task (“Test the snark code on Solaris 8”) they write a new card and post it on the board. Either during or before the daily scrum, estimates are changed (up or down) and cards are moved around the board. Each row on the scrum board is a user story, which is the unit of work. During the sprint planning meeting the team selects the product backlog items they can complete during the coming sprint. Each product backlog item is turned into multiple sprint backlog items. Each of these is represented by one task card that is placed on the scrum board. Each task card starts on the scrum board in the “To Do” column. Typical columns used on a scrum board are: Story –The story description ( “As a user I want to…”) shown on that row. To Do –This holds all the cards that are not done or in process. Work In Process –Any card being worked on goes here. The programmer who chooses to work on it moves it over when she ’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work on the boojum today.” To Verify –A lot of tasks have corresponding test task cards. So, if there ’s a “Code the boojum class” card there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column. Done –Cards pile up over here when they ’re done. They’re removed at the end of the sprint. Sometimes I remove some or all during a sprint if there are a lot of cards.
- Here is an example of an actual scrum board in use.
- At the end of each sprint a sprint review meeting is held. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features. The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint. Participants in the sprint review typically include the Product Owner, the Scrum team, the ScrumMaster, management, customers, and engineers from other projects. During the sprint review the project is assessed against the sprint goal determined during the Sprint planning meeting. Ideally the team has completed each product backlog item brought into the sprint, but it is more important that they achieve the overall goal of the sprint.
- During the Demo and Retrospective, all team members reflect on the past sprint, in an effort to make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
- Integration is not one "big bang" at the end of a project Early iterations expose risks You can find and correct defects over several iterations. – Early detection Team members learn along the way You can refine the development process along the way