UNIT-IV
AGILE DEVELOPMENT
What Is Agility?
Agility has become today’s buzzword when describing a modern software process. Everyone is agile. An agile team is a nimble team able to appropriately respond to changes. Change is what software development is very much about. Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates the product. Support for changes should be built-in everything we do in software, something we embrace because it is the heart and soul of software. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project.
Agility can be applied to any software process. However, to accomplish this, it is essential that the process be designed in a way that allows the project team to adapt tasks and to streamline them, conduct planning in a way that understands the fluidity of an agile development approach.
What Is an Agile Process?
Any agile software process is characterized in a manner that addresses a number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That is, both activities should be performed in tandem so that design models are proven as they are created. It is difficult to predict how much design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.
How do we create a process that can manage unpredictability? The answer is process adaptability (to rapidly changing project and technical conditions) can manage unpredictability?
But continual adaptation without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaptation, an agile team requires customer feedback (so that the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational prototype or a portion of an operational system.
Agility Principles:
The Agile Alliance (see [Agi03], [Fow01]) defines 12 agility principles for those who
want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential
The Politics of Agile Development:
There is considerable debate (sometimes strident) about the benefits and applicability of agile software development as opposed to more conventional software engineering processes. Jim Highsmith (facetiously) states the extremes when he characterizes the feeling of the pro-agility camp (“agilists”). “Traditional methodologists are a bunch of stick-in-the-muds who’d rather produce flawless documentation than a working system that meets business needs.” As a counterpoint, he states (again, facetiously) the position of the traditional software engineering camp: “Light- weight, er, ‘agile’ methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise-wide software.”
No one is against agility. The real question is: What is the best way to achieve it? As important, how do you build software that meets customers’ needs today and exhibits the quality characteristics that will enable it to be extended and scaled to meet customers’ needs over the long term?
Feature-Driven Development (FDD):
Feature-Driven Development (FDD) is an iterative and incremental software development methodology that focuses on delivering features iteratively while emphasizing collaboration, domain object modeling, and code ownership. It was first introduced by Jeff De Luca and Peter Coad in the mid-1990s. FDD is particularly suited for larger projects where teams need to manage complexity and maintain a clear focus on delivering tangible features to stakeholders.
FDD adopts a philosophy that
(1) emphasizes collaboration among people on an FDD team;
(2) manages problem and project complexity using feature-based decomposition followed by the integration of software increments, and
(3) communication of technical detail using verbal, graphical, and text-based means.
Features of FDD:
1) Because features are small blocks of deliverable functionality, users can describe them more easily; understand how they relate to one another more readily; and better review them for ambiguity, error, or omissions.
2) Features can be organized into a hierarchical business-related grouping.
3) Since a feature is the FDD deliverable software increment, the team develops operational features every two weeks.
4) Because features are small, their design and code representations are easier to inspect effectively.
5) Project planning, scheduling, and tracking are driven by the feature hierarchy, rather than an arbitrarily adopted software engineering task set.
Reference:
1)Software engineering : a practitioner’s approach / Roger S. Pressman. — 7th ed.