-
Notifications
You must be signed in to change notification settings - Fork 0
/
10.3.txt
69 lines (35 loc) · 7.55 KB
/
10.3.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
10.3 Redefining the Problem
It’s not all doom and gloom, though. There are many teams out there delivering projects on time and within budget and delighting their stakeholders, and they manage to do it again and again. It’s not easy. It takes discipline and dedication and relies on a high degree of communication and collaboration, but it is possible. People who work like this tend to agree it is also a lot of fun!
Behaviour -Driven Development is one of a number of Agile methodologies. Specifically, it is a second-generation Agile methodology, building on the work of the really smart guys. Let’s look at how these Agile methods came about and how they address traditional project risks, and then we can see how BDD allows us to concentrate on writing software that matters.
A Brief History of Agile
Since we first started delivering software as projects, there have been software professionals asking themselves the same questions. Why do so many software projects fail? Why are we so consistently bad at delivering software? Why does it seem to happen more on larger projects with bigger teams? And can anything be done about it?
Independently they developed a series of lightweight methodologies whose focus was on delivering working software to users, rather than producing reams of documents or staging ceremonial reviews to show how robust their processes were. They found they could cut through a lot of organizational red tape just by putting everyone in the same room.
Then in early 2001 a few of these practitioners got together and pro- duced a short manifesto describing their common position. You might well have seen it before, but it is worth reproducing here because it describes the common ground so perfectly. (1)
The 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 things on the right, we value the things on the left more.
The Agile Manifesto is empirical—it’s based on real experience: “We are uncovering better ways...by doing it.” Also notice that it doesn’t dismiss traditional ideas like documentation and contracts—a criticism often leveled at Agile methods—but rather it expresses a preference for something different: something lighter weight and more directly relevant to the customer or stakeholder.
How Agile Methods Address Project Risks
The authors of the manifesto go further than just the few lines quoted previously. They also documented the principles underpinning their thinking. Central to these is a desire to “deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Imagine for a moment you could do this, namely, delivering production- quality software every two weeks to your stakeholders, on your current project, in your current organization, with your current team, start- ing tomorrow. How would this address the traditional delivery risks we outlined at the start of the chapter?
1. You can find the Agile Manifesto online at http://agilemanifesto.org.
No Longer Delivering Late or Over Budget
Since we are delivering the system in tiny, one- or two-week iterations or mini-projects, using a small, fixed-size team, it is easy to calculate our project budget: it is simply the burn rate of the team times the number of weeks, plus some hardware and licenses.
Provided we start with a reasonable guess at the overall size of the project (that is, how much we are prepared to invest in solving the busi- ness problem in the first place) and we prioritize the features appropri- ately, then the team can deliver the really important stuff in the early iterations. (Remember, we are delivering by feature, not by module.) So, as we get toward the point when the money runs out, we should by definition be working on lower-priority features. Also, we can measure how much we actually produce in each iteration, known as our velocity or throughput, and use this to predict when we are really likely to finish.
If, as we approach the deadline, the stakeholders are still having new ideas for features and seeing great things happening, they may choose to fund the project for a further few iterations. Conversely, they may decide before the deadline that enough of the functionality has been delivered that they want to finish up early and get a release out. This is another option they have.
No Longer Delivering the Wrong Thing
We are delivering working software to the stakeholders every two weeks (say), which means we are delivering demonstrable features. We don’t have a two-week “database schema iteration” or “middleware iteration.”
After each iteration, we can demonstrate the new features to the stake-holders, and they can make any tweaks or correct any misunderstandings while the work is still fresh in the development team’s mind. These regular, small-scale micro-corrections ensure that we don’t end up several months down the line with software that simply doesn’t do what the stakeholders wanted.
To kick off the next iteration, we can get together with the stakeholders to reassess the priorities of the features in case anything has changed since last time.(2) This means any new ideas or suggestions can get scheduled, and the corresponding amount of work can be descoped (or extra time added).
2. In practice, the planning session often follows directly after the showcase for the previous iteration.
No Longer Unstable in Production
We are delivering every iteration, which means we have to get good at building and deploying the application. In fact, we rely heavily on process automation to manage this for us. It is not uncommon for an experienced Agile team to produce more than 100 good software builds every week.
In this context, releasing to production or testing hardware can be considered just another build to just another environment. Application servers are automatically configured and initialized; database schemas are automatically updated; code is automatically built, assembled, and deployed over the wire; and all manner of tests are automatically executed to ensure the system is behaving as expected.
In fact, in an Agile environment, the relationship between the devel- opment team and the downstream operations and DBA folks is often much healthier and more supportive.
No Longer Costly to Maintain
This last one is one of the biggest tangible benefits of an Agile process. After their first iteration, the team is effectively in maintenance mode. They are adding features to a system that “works,” so they have to be very careful.
Assuming they can solve the issues of safely changing existing code so as not to introduce regression defects, their working practices should be exactly the same as downstream support developers. It is not uncommon for an Agile development team to be working on several versions of an application simultaneously, adding features to the new ver - sion, providing early live support to a recently released version, and providing bug fixing support to an older production version (because we still make mistakes, and the world still moves on!).