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
Notes de l'éditeur
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