Thursday, August 14, 2014

Agile Software Development - Agile Modeling

INTRODUCTION
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems.   Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.
Agile software development was a significant departure from the heavyweight document-driven software development methodologies such as waterfall. While the publication of the “Manifesto for Agile Software Development” didn’t start the move to agile methods, which had been going on for some time, it did signal industry acceptance of agile philosophy. A recent survey conducted by Dr. Dobb’s Journal shows 41 percent of development projects have now adopted agile methodology, and agile techniques are being used on 65 percent of such projects.

Manifesto for Agile Software Development

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.

Figure 1The agile software development manifesto

TWO AGILE SOFTWARE DEVELOPMENT METHODOLOGIES
The most widely used methodologies based on the agile philosophy are XP and Scrum. These differ in particulars but share the iterative approach described above.

1. XP (Extreme Programming)
XP stands for extreme programming. It concentrates on the development rather than managerial aspects of software projects. XP was designed so that organizations would be free to adopt all or part of the methodology.
XP development
XP projects start with a release planning phase, followed by several iterations, each of which concludes with user acceptance testing. When the product has enough features to satisfy users, the team terminates iteration and releases the software.
Users write “user stories” to describe the need the software should fulfill. User stories help the team to estimate the time and resources necessary to build the release and to define user acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to requirements as the software is being built. This allows requirements to evolve as both users and developers define what the product will look like.
To create a release plan, the team breaks up the development tasks into iterations. The release plan defines each iteration plan, which drives the development for that iteration. At the end of iteration, users perform acceptance tests against the user stories. If they find bugs, fixing the bugs becomes a step in the next iteration.
Iterative user acceptance testing, in theory, can result in release of the software. If users decide that enough user stories have been delivered, the team can choose to terminate the project before all of the originally planned user stories have been implemented.

 
Figure 2: A simplified XP process









XP Rules And Concepts

Here are the most important concepts:

1. Integrate Often - Development teams must integrate changes into the development baseline at least once a day. This concept is also called continuous integration.

2. Project Velocity - Velocity is a measure of how much work is getting done on the project. This important metric drives release planning and schedule updates.

3. Pair Programming - All code for a production release is created by two people working together at a single computer. XP proposes that two coders working together will satisfy user stories at the same rate as two coders working alone, but with much higher quality.

4. User Story - A user story describes problems to be solved by the system being built. These stories must be written by the user and should be about three sentences long. User stories do not describe a solution, use technical language, or contain traditional requirements- peak, such as “shall” statements. Instead, a sample user story might go like this: Search for customers. The user tells the application to search for customers. The application asks the user to specify which customers. After the user specifies the search criteria, the application returns a list of customers meeting those criteria.

Because user stories are short and somewhat vague, XP will only work if the customer representative is on hand to review and approve user story implementations. This is one of the main objections to the XP methodology, but also one of its greatest strengths.


2. Scrum
In rugby, ‘scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. Scrum for software development came out of the rapid prototyping community because prototypers wanted a methodology that would support an environment in which the requirements were not only incomplete at the start, but also could change rapidly during development.
Scrum management methodology actually originated earlier in the manufacturing community and was adopted and adapted by software developers. Unlike XP, Scrum methodology includes both managerial and development processes. Some development organizations have combined Scrum managerial processes with XP development processes. The adoption rate is still rather low but growing.

Scrum Management
At the center of each Scrum project is a backlog of work to be done. This backlog is populated during the planning phase of a release and defines the scope of the release.
After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints. Each sprint aims to implement a fixed number of backlog items. Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress.
During a sprint, the team has a daily meeting called a scrum. Each team member describes the work to be done that day, progress from the day before, and any blocks that must be cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone in the same room standing up for the whole meeting.
When enough of the backlog has been implemented so that the end users believe the release is worth putting into production, management closes development. The team then performs integration testing, training and documentation as necessary for product release.
Scrum Development
The Scrum development process concentrates on managing sprints. Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review, and adjust each of the backlog items. During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary.
 
Figure 2: A simplified SCRUM process
ADVANTAGES OF AGILE
1. Revenue - The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realized early as the product continues to develop.

2. Speed-to-market - Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and 'perpetual beta'.

3. Quality - A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.

4. Visibility - Agile development principles encourage active 'user' involvement throughout the product's development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.

5. Risk Management - Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there's still time to make a material difference to the outcome.

6. Flexibility / Agility - In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it's imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.
7. Cost Control - The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.

8. Business Engagement/Customer Satisfaction - The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.

9. Right Product - Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It's all too common in more traditional projects to deliver a "successful" project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.

10. More Enjoyable - The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what's right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.

DISADVANTAGES OF AGILE
1. Active user involvement and close collaboration are required throughout the development cycle. This is very engaging, rewarding and ensures delivery of the right product. It's the fundamental principle in agile that ensures expectations are well managed. And since the definition of failure is not meeting expectations, these are critical success factors for any project. However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.

2. Requirements emerge and evolve throughout the development. This creates the very meaning of agile - flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are two big flip sides to this principle though. One is the potential for scope creep, which we all know can create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver. This can make it harder to define a business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.

3. Agile requirements are barely sufficient. This eliminates wasted effort on deliverables that don't last (i.e. aren't part of the finished product), which saves time and therefore money. Requirements are clarified just in time for development and can be documented in much less detail due to the timeliness of conversations. However this can mean less information available to new starters in the team about features and how they should work. It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front. The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible. And this risk is managed closely through the incremental approach to development and frequent delivery of product.


4. Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end of the project. However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project. This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail. The cost of a long and unpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to the project to adopt continuous testing throughout.

5. Frequent delivery of product and the need to sign off each feature as done before moving on to the next makes UAT (user acceptance testing) continuous and therefore potentially quite onerous. The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project. This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.

6. Common feedback is that agile development is rather intense for developers. The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.

THE FUTURE OF AGILE DEVELOPMENT
Agile methodology is becoming very popular for software projects. Its supporters boast that it speeds up software development and delivers precisely what the customer wants, when the customer want it, while fostering teamwork and empowering employees. Before implementing agile development, the purposed system and development methods should be examined carefully. As experienced IT professional know, a one-size-fits-all solution does not exist.





No comments:

Post a Comment