Agile Software Development Essentials E-Book

Nick Robinson

• Herausgeber: BookRix
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2016

Beschreibung

This title is one of the "Essentials" IT Books published by TechNet Publications Limited.
This Book is a very helpful practical guide for beginners in the topic , which can be used as a learning material for students pursuing their studies in undergraduate and graduate levels in universities and colleges and those who want to learn the topic via a short and complete resource.
We hope you find this book useful in shaping your future career.

Leseprobe

Nick Robinson

Agile Software Development Essentials

This title is one of the "Essentials" IT Books published by TechNet Publications Limited. This Book is a very helpful practical guide for beginners in the topic , which can be used as a learning material for students pursuing their studies in undergraduate and graduate levels in universities and colleges and those who want to learn the topic via a short and complete resource. We hope you find this book useful in shaping your future career.BookRix GmbH & Co. KG81371 Munich

Table Of Contents

Table of Contents

Introduction

Chapter 1   Waterfall Development and its Problems

Chapter 2   What is Agile?

Chapter 3   Common Agile Misconceptions and Mistakes

Chapter 4   Advantages and Disadvantages

Chapter 5   Extreme Programming (XP)

Chapter 6   Scrum

Closing Summary

Detailed Table of Contents

Introduction

Introduction

Who Is This Book For?

Who Is This Book For?

This book will appeal to many different audiences. If you are a developer, then this book will give you a good understanding of why Agile is beneficial to you, your team, and your employer. This might be the first Agile project that you've worked on, and you want to understand why you're using Agile over Waterfall. This book will also be a good refresher on why you're using Agile if you're already on an Agile project. 

If you're a project manager, then this book will help you understand the difference between an Agile project and the more traditional Waterfall project. As teams become more self-directed when working on a project, a project manager is still crucial to help ensure the teams are run correctly and deliver on time and budget. 

If you're an IT or business leader and your company is considering adopting Agile, this book will help you understand how this will work and what the benefits are to your organization. This book covers six main areas:

Waterfall development and its problemsWhat is Agile all about?Common Agile misconceptionsAdvantages and disadvantagesExtreme Programming (XP)Scrum

Chapter 1 Waterfall Development and its Problems

Chapter 1  Waterfall Development and its Problems

History of the Waterfall Model

The Waterfall software development process was introduced computer scientist Winston Royce in 1970. Royce first wrote about Waterfall in an article called, Managing the Development of Large Software Systems. Although Royce didn't directly refer to his model as Waterfall, the article was actually about a process that was flawed for software development. Royce's model allowed for more repetition between stages of the model, which Waterfall doesn't allow you to do.

Royce's actual model was more iterative in how it worked and allowed more room to maneuver between stages. We will discuss a more iterative way of working when we discuss Agile later on in this book. Although Royce didn't refer to his model as the Waterfall model directly, he is credited with the first description of what we refer to as the Waterfall model.

Royce's original article consists of the following stages, which we'll go into more detail on in a moment. Those stages are:

Requirements SpecificationDetail DesignConstruction, where developers start crafting codeIntegration, where all the code is brought together and compiled into a run-able solutionTesting and Debugging, where your testing will try to find defects that the developers will fixInstallation, where you deploy your system so that it can be used by your end users. Maintenance, where you fix any issues that are raised by the users.

How Does Waterfall Work?

How Does Waterfall Work?

The Waterfall process is split into separate stages, where the outcome of one stage is the input for the next stage. In the first stage, Requirements Specification, all possible requirements for the system to be developed are captured and documented in a requirement specification document. This document normally requires sign-off by key project and business stakeholders. 

This part of the Waterfall model is typically organized by the business analysts, but depending on the size of your project, team, or organization, other members of your development team may be involved. This stage is about teasing out the requirements of the system from your stakeholders. This would include the required functionality, documentation of business rules and processes, and capturing any regulatory and compliance requirements that will affect the overall system. 

Figure 1 The Waterfall software development process

The next stage is System Design. The requirement specifications from the first stage are inspected, and the system design is put together. This design helps in specifying the system design requirements, and also helps with designing the overall system’s architecture. It is this stage where architects, solution designers, and developers will work together to decide how the overall system will be constructed. This is from a code perspective, and also a technology choice and infrastructure perspective. 

The next phase is Implementation. This is the phase where the developers take the design and start producing code to turn the design into a reality. The developers may also write automated unit and integration tests at this stage.

After the Implementation phase, we have the Integration and Testing phase. This is where all the deliverables from the implementation phase are brought together and tested as a whole. The testing team should be working to a defined test plan. Once the system has been tested and signed off by the test team, the next stage is deploying the solution to your end users. Your end users may be internal customers within your organization, or customers. 

Once the solution has been deployed, it goes into the Maintenance phase, where any issues that are reported will need fixing and re-deploying. This would generally be in the form of release patch fixes to your system. You may also perform small enhancements to the system at this phase. If an enhancement is quite large in scope, then you might start the Waterfall process again and start capturing further requirements.

All of these phases are cascaded, where progress is seen as flowing steadily downwards like a waterfall. The next phase is started only after a pre-defined set of goals are achieved from the previous phase. In this model, the phases do not overlap.

Where Is Waterfall Suitable?

Where Is Waterfall Suitable?

Every software development project is different and requires a suitable software development lifecycle approach that is employed based on your team and organization's internal and external factors. There are some project situations where the Waterfall model is appropriate, but as we look at these, you may feel from experience that this doesn't always work out. 

First, Waterfall is suitable if your requirements are well documented, clear, and fixed. How often is that the case though? From my own experience as a software developer, I can't remember any of the many projects I've delivered where the requirements have been clear from the start so that they can be captured in a document that doesn't change as the project rolls on. 

Next, the product definition must be stable. Again, I can't think of a single project where this has been the case, as external factors like a change in the marketplace or a shift in business priorities mean that your product will change over time. I have worked on many projects where the final delivered product was quite different from what was initially specified. Under Waterfall this shouldn't happen, but in reality, what you are building can change. 

There is nothing wrong with this, but it does fight against the software delivery process. Hold this thought in your mind, as this will form a big part of our core theme when we discuss Agile in detail later on.

Next, the technology should be well understood. This means that developers should understand the technologies that they're going to be using and how they work. Once you enter the implementation and construction phase of the project, developers normally have to work toward very rigid and set-time scales. In my experience, a lot of effort is expelled on the requirements and design phases, which normally eat into the time needed to actually develop the code. 

Next, Waterfall works best on projects that are short, and by short I mean projects that take around two-to-four months in total. The longer a project runs, the more chance there is of the requirements and product definition becoming out-of-date. 

Finally, Waterfall works best when all the members of your project team are available. It is quite normal for a development team to have a pool of resources that might be shared out between many different projects. If another project is overrun for any reason, you may not have all your people available at the time when they are required. This can greatly impact a project's time scale and put delivery dates at risk.