Agile Methodologies
•
0 recomendaciones•647 vistas
Choosing the best Agile methodology for your project: extreme programming XP,scrum,UP?
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Agile Methodologies
Similar a Agile Methodologies (20)
Más de Kenny Nguyen
Más de Kenny Nguyen (20)
Último
Último (20)
Agile Methodologies
- 2. CONTENTS 1 Brief introduction to Agile methodologies 2 SCRUM Agile methodology 3 XP, UP Agile methodology 4 XP, UP or Scrum? 5 Conclusion Tuesday, September 25, 2012 Page: 2
- 3. AGILE METHODOLOGIES Agile is an iterative and incremental (evolutionary) approach to software development Helps teams respond to the unpredictability of building software Maximize the return on your software investment. Promotes adaptive planning, evolutionary development and delivery; It's a conceptual framework that promotes foreseen interactions throughout development cycle. XP SCRUM AUP or UP DSDM Adaptive Software Development Crystal LSD FDD Tuesday, September 25, 2012 Page: 3
- 4. AGILE METHODOLOGIES Traditional methodology Agile methodology Try to restrict changes Try to embrace changes Try to create predictive Try to be adaptive plans Structured in phases Structured in features (requirement, design, (such as Sprints) coding, test, deploy….) Hard to measure progress Easier to measure progress Doing testing at the end of Embrace continuous the project (It’s too late) testing, integration and reviews Tuesday, September 25, 2012 Page: 4
- 5. Real projects The Google AdWords development group applied Agile techniques piecemeal, successfully over a period of 6 months… BT Group (2005): Change Unix-based phone-traffic monitoring system to Web-centric architecture Shift from traditional waterfall development techniques (three to nine months for a third-party developer to gather specifications) to agile methodology The company's shift to 30-day software iteration cycles Outcome: At least four times as fast, meaning they could deliver the end product that much faster. Tuesday, September 25, 2012 Page: 5
- 6. AGILE METHODOLOGIES Agile methods tend to fall into two categories: Engineering (how to do it): eXtreme Programming Project Management (how to manage it): Scrum Operate in an incremental, iterative, adaptive manner Tuesday, September 25, 2012 Page: 6
- 7. SCRUM Agile Methodology An iterative, incremental framework for software development Focus on project management values and practices rather than requirement, implementation Work is structured in small units of work called sprint Iterations of work that are typically 30-calendar days. End of each sprint, Team delivers a potentially shippable product increment to the customer. Each iteration, team works on highest priority requirement to develop feature which is highest in value to customer (client-driven adaptive planning) Tuesday, September 25, 2012 Page: 7
- 8. XP Agile Methodology Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible It’s an “engineering” method in that it prescribes “HOW” to create the code unlike SCRUM that talks about “how to manage an agile project” Tuesday, September 25, 2012 Page: 8
- 9. XP Agile Methodology XP is extreme in the sense that it takes 12 well-known software development "best practices" to an extreme 1. Planning Game (short iterations,1-3 weeks in duration, each iteration features are broken down into very small stories) 2. Small Releases (min: once per iteration, max: 2-3 months ) 3. Metaphors (Names are chosen to be evocative of the system being created) 4. Simple Design (The simplest design that suffices for the task at hand) 5. Continuous Testing (Test-driven development: test case test data) 6. Refactoring (Codes are continuously reviewed and kept as clean as possible, get feedback from client and redesign) 7. Pair Programming 8. Team code ownership 9. Continuous Integration (The system is built and tested end-to-end several times each day Developers must continuously keep the system in a deployable state) 10. Sustainable pace (Building software is a marathon, not a sprint.) 11. Whole team together (team consists of developers, business analysts, QA, PM..) 12. Coding standards Tuesday, September 25, 2012 Page: 9
- 10. XP Agile Methodology Cycle: XP teams work in a series of fixed iteration cycles (1-3 weeks). Tuesday, September 25, 2012 Page: 10
- 11. UP Agile Methodology Agile UP is an adaption of UP Phases = inception, elaboration, construction, and transition Phases divided into iterations Focus on prioritized high risk tasks for development Tuesday, September 25, 2012 Page: 11
- 12. XP or SCRUM? SCRUM XP management methodology (driven by engineering methodology (driven by management) developers) Self organizing teams Collaboration, communication 30-calendar day iterations 1-3 weeks iterations Used for large projects, flexible in Small or medium projects, low on ceremony scale, multiple teams (7+-2) ceremony scale (<=7 pp), delivery dates <=1 year Life cycle consists of 4 phases: Life cycle consists of 5 phase: Planning, staging, development, release Exploration, Planning, iteration to first release, productionizing, maintenance Nothing must be added during an XP promotes no overtime, Not allow to iteration sign up for more work in the coming iteration than the previous iteration. Daily integration and regression test Unit tests and Acceptance tests Increase the productivity of the project improvement in the quality of the code team and test suites. Tuesday, September 25, 2012 Page: 12
- 13. CONCLUSION Scrum: more visibility, better business engagement, team collaboration, a clear process for prioritization, etc. Scrum suitable for projects where customer has priority of work to be completed and requirements keeps changing from time to time. Scrum + XP and UP is a good combination. Tuesday, September 25, 2012 Page: 13
Notas del editor
- Agile methodology is an approach to project management, used in software development. Agile methods maximize the return on your software investment. It helps teams respond to the unpredictability of building software through incremental, iterative work known as sprints. Agile methodology is iterative and incremental. In waterfall methodology, software development team only has one chance to get it right, where as in Agile methodology, every aspects of software development such as requirement, design, development etc is continually revisited throughout the life cycle of the project. FDD: Feature driven development LSD: Lean software development
- Having said that, none of the other Agile methods are as well defined, or as broad in scope as XP . Scrum, for example, is roughly equivalent to XP’s Planning game practice, with elements of Whole Team . While there are differences in the details, it is fair to say that Scrum is a subset of XP . Indeed, many Scrum teams augment their process by adding in many of the XP practices such as Acceptance Testing, Pair Programming, Continuous Integration, and especially Test Driven Development. Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work. Of those disciplines, Test Driven Development is the most revolutionary and impactful. http://www.infoworld.com/d/developer-world/bt-case-study-in-agile-programming-112
- Incremental - Build a system gradually - See the system grow - Demonstrating progress • Iterative - Multiple releases or check points during a project, each closer to the target - Iterations include requirements development and testing - Typical iterations are two weeks long - Plan as you go • Adaptive: Goals change based on lessons from prior iterations, feedback and business opportunities
- The Scrum start when the Product Backlog contains sufficient prioritized features for the first sprint In each sprint, team works on highest priority requirement to develop feature which is highest in value to customer. At the end of each sprint, team delivers a potentially shippable product increment to the customer. Product Backlog is broken down in to Sprint Backlogs Sprint Backlog: task breakout, is a list of tasks in 4-16 hours (based on business value and risk ) Tasks are broken down into pieces that require less than 2 days or 16 hours of work Items are chosen for Sprint Backlog that can be completed within 30days based on team size, level of productivity… Each sprint begin with Sprint planning meeting Reviews and confirms estimate features to refine the Product backlog and Release backlog (next operational or product release) No other discussion is allowed outside the 3 questions Scrum framework is suitable for projects where customer has priority of work to be completed and requirements keeps changing from time to time.
- The Planning Game Development proceeds in very short iterations, typically 1-2 weeks in duration. Prior to each iteration features are broken down into very small stories. Stories are estimated by developers and then chosen by stakeholders based on their estimated cost and business value. The sum of story estimates planned for the current iteration cannot exceed the sum of estimates completed in the previous iteration. Whole Team The team consists of developers, business analysts, QA, project managers, etc. The team works together in a lab space or open area where collaboration and communication are maximized. Acceptance Tests Stories and features are defined by automated tests written by the business analysts, and QA. No story or feature can be said to be done until the suite of acceptance tests that define it are passing. Small Releases Systems are released to production, or pre-production very frequently. An interval of 2-3 months is the maximum. The minimum can be once per iteration. Continuous Integration The whole system is built and tested end-to-end several times each day. While new tests are made to pass, no previously passing tests are allowed to break. Developers must continuously keep the system in a deployable state. Collective Ownership Code, and other work artifacts, are not owned by individuals. Any member of the team may work on any artifact at any time. Coding Standard Code, and other work artifacts, look as if they were written by the team. Each team member follows the team standard for format and appearance of the artifacts. Metaphor Names within code and other work artifacts are chosen to be evocative of the system being created. Sustainable Pace Building software is a marathon, not a sprint. Team members must run at a rate they can sustain for the long haul. Overtime must be carefully controlled and limited. Tired people do not win. Pair Programming Code and other work artifacts are produced by pairs of individuals working together. One member of the pair is responsible for the task at hand, and the other helps out. Pairs change frequently (every two hours or so) but responsibility stays with the owner. Test Driven Development Developers are not allowed to write production code until they have written a failing unit test. They may not write more of a unit test than is sufficient to fail. They may not write more production code than is sufficient to pass the failing test. The unit tests are maintained and executed as part of the build process. No previously passing unit test is allowed to fail. Refactoring Code, and other work artifacts, are continuously reviewed and kept as clean as possible. It is not sufficient that code works; it must also be clean. Simple Design The simplest design that suffices for the task at hand, is the right design. More complex and general designs may become useful later, but not now. We do not wish to carry the weight of that complexity while it is not needed. Sufficient for the day are the complexities therein.
- User requirements come to the development team in what we call “ Stories ” A project velocity is used to determine if the iteration is over booked or not . • Total up the time estimates in ideal programming days of the tasks, this must not exceed the project velocity from the previous iteration. If the iteration has too much then the customer must choose user stories to be put off until a later iteration Beginning of iteration: the team gets together with the customer for a planning meeting. In that meeting, they go over the features the customer wants done in that iteration, breaking each feature down into individual engineering tasks. Individual developers then sign up for specific tasks, and estimate those tasks. No developer is allowed to sign up for more work in the coming iteration than he completed in the previous iteration. During the rest of the iteration, the team will implement the features they signed up for, pair programming on all production code At the end of the iteration (usually on a Friday), the programmers deliver a working system to the customer. The system may not be complete, but all functionality that is implemented works completely, without bugs. The customer accepts delivery, and the team goes home early. The next Monday everyone meets again to plan the next iteration, and the cycle repeats itself.
- In my experience, Scrum is the more likely starting point when the adoption of agile is driven by management. XP is the more likely starting point when the adoption of agile is driven by developers. In my view? Ideally you would do both. Or at least elements of both. And you would start with the one that addresses the issues causing you to adopt agile in the first place. regression test: test against test case data Unit test: developer write test functions Acceptance test: Perform to make sure if the work fulfill the requirements