Ch7 21 bi: Difference between revisions
(→Scrum) |
(→Scrum) |
||
Line 69: | Line 69: | ||
* Adaptation : If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being | * Adaptation : If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being | ||
processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. | processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. | ||
Scrum prescribes four formal opportunities for inspection and adaptation | Scrum prescribes four formal opportunities for inspection and adaptation: | ||
* Sprint Planning Meeting | * Sprint Planning Meeting | ||
* Daily Scrum | * Daily Scrum |
Revision as of 16:48, 3 December 2011
Introduction
Agile methodologies are software development techniques based on software and management principles that have been distilled over the past few decades. The primary differentiating factor between Agile methodology and traditional software development methods is the fluidity that the Agile methodologies inject in all stages of software development.
Agile software development is an umbrella term that encompasses various development techniques and philosophies, however, there are certain core characteristics that all of these share. The key features of Agile development are that it is based on iterative and incremental development encouraging an evolution of the requirements and solutions. Agile software development teams also tend to be more fluid, self-organizing and are often cross-functional. Agile software development at the core of it, strives to break the rigid boundaries that traditional software development techniques introduce.
History and the Agile manifesto
Historically, software development has followed the waterfall model [reference] with clear delineation of the various phases such as gathering requirements, design, implementation, verification and maintenance, with very little cross communication between these phases. This rigidity built into this model doesn't always reflect the real world requirements of software development, for e.g., the requirements could change after the design has been completed and a failure to accomodate the new set of requirements is often considered a failure of the project. This has resulted in a significant percentage of software development projects being delayed and in some cases being completely stopped.
As a reaction to the failure of the traditional software development models, quite a few new techniques started to develop in the late 1990's. They all emphasized close collaboration between the programmer team and business experts and a built in ability to be able to deal with and manage change. The core ideas behind these loosely defined methods, referred to as light-weight software development or Agile methods, were finally crystallized into a set of principles, i.e., the Agile manifesto.
The Agile Manifesto reads, in its entirety, as follows:<ref name="Agile Manifesto"/>
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
- Customer collaboration over 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.
Characteristics and Principles
While there are many specific agile development methods a common thread runs through all of them. The primary focus is on process adaptability throughout the software development life-cycle. This is achieved by constraining the development to short, time-contained increments. During each of these incremental development periods, there is a focus on a teamwork and collaboration with routine and formal daily face-to-face communication among team members.
Another key aspect of any agile methodology is the team composition, which is often cross-functional and self-organizing with traditional corporate hierarchy not allowed to get in the way of team formation. A cross-functional team is more reflective of the real-world in that all the stake holders in the project are allowed to influence the development process in a continuous manner throughout the life cycle of the project. This allows for adjustment in the goals of the project on a more `real-time' basis. Most agile teams include atleast one customer representative
Agile development emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods.
Some of the key guiding principles of Agile development are:
- Active involvement of the end-user : This results in the requirements being clearly communicated and understood (at a high level) at the outset. Requirements are prioritized appropriately based on the needs of the user and market and can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren’t read or are misunderstood. Emerging requirements can be factored into the development schedule as appropriate with the impact and trade-off decisions clearly understood. As the product goes through increments, it is easy to track if it continues to meet the user requirements and timely decisions can be made, about features, priorities, issues, and when the product is ready.
- Requirements evolve but the timescale is fixed : Agile methodologies embrace change as part of the development process, however it is also key to make sure that as the requirements morph the timelines don't slip. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.
- A collaborative & cooperative approach between all stakeholders is essential : Agile development relies on close cooperation and collaboration between all team members and stakeholders. Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development. This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members on the same page throughout the development.
- Capture requirements at a high level; lightweight & visual : Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product.
- Develop small, incremental releases and iterate : This reduces risk since we one has a clear visibility of what’s completed to date throughout a project. It also allows one to deliver value sooner, being able to release the product whenever it’s deemed good enough, rather than having to wait for all intended features to be ready. Developing iteratively allows more flexibility since we can choose to change direction or adapt the next iterations based on actually seeing and using the software.
- Complete each feature before moving on to the next : Features developed within an iteration, should be 100% complete by the end of the iteration. In agile development, make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as finished.
- Testing is integrated throughout the project lifecycle : Agile development does not have a separate test phase as such. Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code. Apart from being geared towards better quality software, this is also important to support the principle of small, iterative, incremental releases
There are quite a few agile software development methods :
- Agile Modeling
- Scrum
- Agile Unified Process (AUP)
- Dynamic Systems Development Method (DSDM)
- Essential Unified Process (EssUP)
- Extreme Programming (XP)
- Feature Driven Development (FDD)
Some of these such as DSDM are stand alone, i.e., they encapsulate all the agile principles while others such as extreme programming and Scrum focus on parts of the Agile process and needed to be complemented with other methodologies to be complete. We will focus on a couple of these methodologies and look at some of the available Agile tools.
Scrum
Scrum is a framework for developing and sustaining complex products. Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. Three pillars uphold every implementation of Scrum: transparency, inspection, and adaptation.
- Transparency : Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a
common understanding of what is being seen.
- Inspection : Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way
of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
- Adaptation : If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being
processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal opportunities for inspection and adaptation:
- Sprint Planning Meeting
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Extreme Programming
Implementing Agile Methodology
Agile Tools
References
http://www.extremeprogramming.org/ http://agilemanifesto.org/ http://en.wikipedia.org/wiki/Agile_software_development http://www.extremeprogramming.org/ http://www.industrialxp.org/ http://agilescout.com/best-agile-scrum-tools/ http://www.21scrum.com/ http://agilebuddy.com/ http://www.dsdm.org/ http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf