UK Essays Services:

Free Help:

Project Management Software

AGILE SOFTWARE METHODOLOGY

Introduction and Adoption:

Expert project manager has been experiencing a lot of continuous changes in project management. The new model of project management to manage software is taking over from the old model that the project manager has been using. The old model of a software company delivering the vision of an organization is a giant, monolithic project is slowly being replaced with a new model where the organization, technology, product management, and vendors work together to build exactly what users want. For years, it's been well known that software's that deliver exactly what users want tend to be more successful, that needs a great deal of time, effort, techniques, analytics, as well as testing those methodologies to fulfil users needs with business requirements.

Using an agile approach to its greatest benefit requires discipline in a variety of ways. And none is more critical than the discipline of Software Configuration Management. Agile methods are creating a buzz in the software development community and have recently achieved extensive popularity. Experts have invested significant time and effort in Agile as there is an understanding demands from the emerging technology trends and the limitations of some of the traditional methodologies of developing software.

Agile vs. Waterfall Model:

The end of the first iteration results in a little bit of software that actually works. This has a staggering advantage that the customer can take that little bit of usable software and use it. Even if the client waits for the little iteration before the software has enough functionality, and only then uses it, the advantage is still huge. In any process where all the requirements are gathered up front, regardless of how or what is done with them afterwards, there is a large delay in getting the first bit of usable working in the clients hands. Regardless of how stable or unstable the requirements are, agile methods deliver a return on investment much sooner than other approach to building software.

Waterfall development attempts to divide the work of software development into phases, often with heavy paper deliverables, difficult integration efforts, and a desire to lock down or freeze requirements early in a schedule. It is not uncommon to see cycles of a year or more before ideas can be turned working software. In contrast, agile development practices attempts to dramatically increase the throughput of business value, maximizing client ROI through the rapid release of unstable functionality while providing the ability to adapt to changing requirements.

Brain research on rats suggests that voluntary pressure in the form of audacious goals taken on by high performance teams makes them produce more neuron stem cells, rewire the brain, and become smarter. Involuntary pressure, often seen on waterfall teams, may reduce stem cell production and make employees stupider. People should abandon teams on death marches as it is not healthy for them and will decrease brain function. (jeffsutherland.com May, 2008)

Main Agile Development Methods:

3.1 Crystal family of methodologies

The Crystal family of methodologies includes a number of different methodologies for selecting the most suitable methodology for each individual project. Besides the methodologies, the crystal approach also includes principles for tailoring the methodologies to fit the varying circumstances of different projects.

Each member of the Crystal family is marked with a colour indicating the heaviness of the methodologies, i.e. the darker the colour the heavier the methodology. Crystal suggests choosing the appropriate colour of methodology for a project based on its size and criticality. Larger projects are likely to ask for more coordination and heavier methodologies than smaller ones. The more critical the system being developed the more rigor is needed.

There are certain rules, features and values that are common to all the methods in the Crystal family. First of all, the projects always use incremental development cycles with a maximum increment length of four months, but preferably between one and three months (Cockburn 2002). The emphasize is on communication and cooperation of people. Crystal methodologies do not limit any development practices, tools or work products, while also allowing the adoption of, for example, XP and Scrum practices (Cockburn 2002). Furthermore, the crystal approach embodies objectives for reducing intermediate work products and shaping conventions within a methodology for individual projects and developing them as the project evolves. There are currently three main Crystal methodologies constructed: Crystal Clear, Crystal Orange and Crystal Orange Web (Cockburn 2002).

3.2 Dynamic Systems Development Method

Dynamic Systems Development (DSDM) is an organised, common-sense process focused on delivering business solutions quickly and efficiently. It is similar in many ways to SCRUM and XP, but it has its best uses where the time requirement is fixed.

DSDM focuses on delivery of the business solutions, rather than just team activity. It makes steps to ensure feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.

Many systems fall short of meeting the needs of the users and purpose they were designed for, causing the system to either be abandoned or overhauled. There are number of ways this may happen:

Failure to meet the purpose / solve the problem it was designed for - DSDM allow for user testing all through the development process, this allowing developers to get prompt feedback on the usability and suitability of the product.
Cost outweighs benefits - In DSDM, a business study is done at the beginning of the project, greatly decreasing the likely hood of late surprises in the financial realm.

Core Concepts in DSDM:

The following list describes the core concepts of DSDM.

Active User Involvement:

The people who will be using the product must be actively involved in its development. This is important in order for the product to end up being useful to the people who will be using it.

The Team Must Be Empowered to Make Decisions:

The team should be able to make rapid and informal decisions, without having to cut through red tape to get those decisions approved.

Iterative Development, Driven by User Feedback

The development in the systems is done in iterations, which allows for frequent user feedback, and a partial but prompt solution to immediate needs and more functionality being added in later iterations.

Changes Must be Reversible:

All products should be in a fully known state all times. This allows for backtracking if a certain change does not work out well.

Requirements are Initially Defined at a High level:

High level requirements are worked out at the beginning of the project, before any coding, leaving the details to be worked out during the course of the development.

Fitness for Business Purpose is the Goal:

Meeting the business need is more important than technical perfection.

Integrated Testing:

Testing is done at every step of the way, to ensure that the product being developed is technically sound and does not develop any technical flaws, and that maximum use is made of user feedback.

(scour.com 2003)

3.3 Feature Driven Development

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. FDD was first introduced to the world in 1999 via the book Java Modelling in Color with UML. FDD was first implemented on a 15 month, 50 person project for a large Singapore bank in 1997, which was immediately followed by a second, 18 month long 250 person project. A more substantial description is published in the book A Practical Guide to Feature-Driven Development as well as the Feature Driven Development web site.

FDD is an agile and adaptive approach for developing systems. The FDD approach does not cover the entire software development process, but rather focuses on the design and building phases. However, it has been designed to work with the other activities of a software development project (Palmer and Felsing 2002) and does not require any specific process model to be used. The FDD approach embodies iterative development with the best practices found to be effective in industry. It emphases quality aspects throughout the process and includes frequent and tangible deliveries, along with accurate monitoring of the progress of the project. As name implies, features are an important aspects of FDD. A feature is a small, client-valued function expressed in the form like Calculate the total of a sale, Validate the password of a user, and Authorize the sales transaction of a customer.

FDD consists of five sequential processes and provides the methods, techniques and guidelines needed by the project stakeholders to deliver the system. Furthermore, FDD includes the roles, artefacts, goals, and timelines needed in a project (Palmer and Felsing 2002). Unlike some other agile methodologies, FDD claims to be suitable for the development of critical systems (Palmer and Felsing 2002).

3.4 Scrum:

Scrum is an agile process that can be used to manage and control complex software and product development using iterative, incremental practices. Scrum has been used from simple projects to changing the way enterprises do their business. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical system development.

Scrum Roles:

In Scrum, there are three primary roles: The Product Owner, Team Members, and The ScrumMaster.

The Product Owner is responsible for taking all the inputs into what the product should be, from the customer or end-user of the product, as well as from Team Members and stakeholders and translating them into a product vision.

Team Members build the product that the customer is going to consume: the software, the website, or whatever it may be. The team in Scrum is typically five to ten people, although teams as large as 15 and as small as 3 commonly report benefits.

The ScrumMaster is tasked with doing whatever is necessary to help the team be successful. The ScrumMaster is not the manager of the team; he or she serves the team, by healping remove blocks to the team's success, facilitating meetings, and supporting the practices of Scrum. (scrumalliance.org 2003)

3.5 Extreme Programming:

Extreme Programming (XP) is a deliberate and disciplined approach to software development. XP is around since last eight years, and it has already been proven at many companies of all different sizes and industrial world wide. (extremeprogramming.org 1999)

Extreme Programming is a discipline of software development based on values of simplicity, communication. The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply.

The Extreme Environment:

XP is designed to meet the Customer Bill Of Rights and Developer Bill Of Rights.

Extreme Listening: The Onsite Customer participates in the Planning game. The development team interviews the customer to determine User Stories about how the system will work. User stories are combined or split to come up with a story. The customer prioritizes the tasks according to the business value, which puts stories into release schedule based on the development resources available. This lets the customers have an accurate Release Plan.
Extreme Design: XP relies on Test Driven Development for its inner loop. This pumps the outer loop, and makes the political end of XP possible. Promises are automatically kept. Programmer Test are written which the successful software will be able to pass. At first, the tests fail because the software hasn't been written yet. A simple design is developed by doing the simplest thing which might pass the tests.
Extreme Coding: XP involves pairs of programmers working together on code, so that the entire development team achieves code stewardship. They use Test Driven Development to Code Unit Test First. This Pair Programming leads to Collective Code Ownership. Programmers follow the Coding Convections whenever they write new code.
Extreme Testing: After code passes Programmer Tests, practices continuous integration of frequent releases and run acceptance tests to verify that the software meets the customer's requirements. (c2.com 2008)

Extreme Programming's Future:

Many of the XP practices are controversial when they are first introduced to an organization. But they needn't be controversial because they work. In these coming years it is expected almost all of the XP practises to become mainstream, especially those practices focused on planning, collaboration and testing.

It is important to note that Extreme Programming is not complete template for the entire delivery organization. Rather, XP is a set of best practices for managing the development team. Borrowing practices from other process including Interactive Design and The Unified Process is vital to complete the delivery team. These other disciplines have workflows and activities that we assign to separate teams outside of the XP development team.

Extreme Programming's future is bright. As a process it gives the ability to grow, change and adapt as they encounter different applications and business needs. And more than any other process Extreme Programming has the power to positively transform not just the development team but the entire delivery organization.

Success story of Agile methodologies:

BMC Bioformatics: has successfully used agile development approaches to create and maintain biomedical software, including software for bioformatics. According to their multi-site experience reports they found that agile methods are well suited to the exploratory and effective nature of scientific inquiry. They provide a robust framework for reproducing scientific results and for developing clinical support sytems.

They concluded that they found the agile development approach a good fit for their organizations, and that these practices should be applicable and valuable to other biomedical software development efforts. (BMC Bioinformatics 2006)

Failure story of Agile Development:

If there's one thing that all software development experts agree on, it's that the other experts are not always right. There are quite lot points of view to consider. Some experts see a fundamental divide between Agile and Lean development, while others think they are easily bridged.

Software Development is prone to fads, going back to the days of goto Considered Harmful. (CIO.com 2008) He has recently wrote an article on failure of agile methodology, which he tried to implement in a project that had been done with outsourcing to a CMM Level 5 organization, with great care in the methodology at their end and with careful detailed project management overall about two years ago. Further he mentions that the project consumed millions of dollars and years of overtime. Yet it failed utterly. They had done a thoroughly examined the failure cause and the last thing anyone would have said about their last project was that it was agile. (CIO.com 2008)

Considering the pros and cons of agile methodology, it is yet safe to say that despite being new term in software development Agile has proved many success stories than any other methodology. Of course there is risk in every methodology. But hey in every project we do take risks, but intelligent project manager will take a calculated risk, and there is where agile come into picture.

Conclusion:

Studies have shown that traditional plan-driven software development methodologies are not used in practice. It has been argued that the traditional methodologies are too mechanistic to be used in detail. As a result, industrial software developers have become sceptical about new solutions that are difficult to grasp and thus remain unused. Agile software development methods, officially started with the publication of the agile manifesto, make an attempt to bring a plagiarism shift in the field of software engineering. Agile methods claim to place a more emphasis on people, interaction, working software, customer collaboration, and change, rather than on processes, tools, contracts and plans. A number of promising new methodologies claiming conformance to these agile principles have been introduced. Yet, no systematic reviews of the agile methods have been attempted.

We provide a professional essay writing service that thousands of our customers use as an effective way of improving their grades, improving their research and saving them lots of time.