Agile Methodologies

Editor's Notes

• #4: 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
• #6: 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
• #7: 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
• #8: 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.
• #10: 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.
• #11: 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.
• #13: 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