So we've been, you know, we started off giving the big picture about Agile and Waterfall
and where that all came from and then we've been on this detour
where we kind of learned about the software as a service, Agile, all the architecture of the views,
and now learning about Ruby and Rails we're [inaudible]. So now we're coming
back to the agile development. In particular we'll talk about
behavior-driven design and user stories and things like that. That's - this is the outline of
what we'll get through, get through a, a few of these bullets today but this maps
on to the, the chapter as the sessions show. Let's start off with behavior-driven design,
BDD, also known as behavior-driven development and we'll talk about user stories.
So why did this get created? Because projects were failing. [laugh].
It was a sad commentary. I heard this line about software that if - let's see,
if we built all the buildings like we built software, the first woodpecker would
destroy civilization. [laugh] So, so there have been a lot of disappointments
about software, so, why? Well, one reason is, it just doesn't do what the customers
want. As we'll see, that has to do sometimes because, once the customers see what
you've built, they realize "That's not what I want, even though it sounded like it."
Or, they're late. You know, this is, we're gonna talk about that. How you estimate
time to get things done. You run out of time and money and it's, the, so that's
another reason to fail. Or, yeah, you go over budget, run out of money. Or it's - you
get it working, the first one's okay, but it's really hard to maintain and evolve
and people expect software today to be maintainable. Or you do - you get them
all wrong, right? So that's what inspired this kind of manifesto for - the Agile Manifesto.
And let's just remind you what that is. Since there'd be this gap between
what cust-- they thought customers wanted and what they really wanted, the solution
was to work continuously with the customer, not like sign a contract, come
back in two years and show them your result. Let's engage customers
continuously. Not only the customer, but all the stakeholders. And so the word
stakeholder, the users, the end users of the system, the customers who were
requiring it. The people developing the code maintainer maintenance, if there's
several people operating it, the management, everybody involved: let's be
involved continuously so we're all on the same page. And the way to make sure you
understand what's being done is that you're going to maintain a working prototype.
So the Rails and Ruby environment lets you have something that's partially
operational but it works. And then you limit your new features to every iteration
which is typically a week or two. In this class we'll do it every week so you can
get lots of iterations in. Now this is in contrast to that waterfall model, where
there're these major phases. Right? You would do the design and that would last
for four months. And, and you'd start or you'd do the specs and then. The design
and then the development, and later it'd be testing. And so that basically, it was a - the
Agile Manifesto is a rebellion against the conventional wisdom of these major phases,
each takes months long, hundreds of programmers, and extensive documentation.
Let's instead work with the customer continuously. And we check it and make sure what you do
next. A lot of the problem the programmers have is they anticipate what the customers
would want or what the other stakeholders would want rather than just asking them.
So let's every week or so, let's just make sure we're still on the same page. And
let's make sure we're going to build the right thing, not just build what they told
us to. So, BDD, as it's called, is asking questions before and during development.
And the phrase BDD came around after - I sort of talked about Test-Driven Development
is that there's, there was some confusion in Test-Driven Development,
about what you're supposed to be talking to the customer. And it became useful to
use the word Behavior-Driven Design to try and separate it from the implementation.
So that's what the, we'll talk about. Test-Driven Design, Armand will talk
about that next week. We're gonna finish talking about Behavior-Driven Design
but the idea - you're trying to capture the behavior you want as opposed to how you're
implementing it and that's why it didn't - the name's kind of long. The mechanism is written down
as user stories and we'll talk about where that came from which is supposed to be
kind of an easy, understandable way to talk to regular people, non-technical
people so that you can communicate with them to reduce the chances of
misunderstanding. And again it's the B part is behavior versus the
implementation. TDD really is about implementation, and this - the unit testing
versus the higher level acceptance testing. All right. What are these user
stories we've been talking about? It's typically one to three stories, one to
three, sorry, sentences, that fit into everyday language. The idea was to put
them on the three by five card. We've had practice in this class with three by five
cards. So, you know what they look like [laugh]. And, it's written with the
customer, or by the customer. So, here's an example of a user story. This format
of - this stylized format which has 'as a', and then a kind of stakeholder, 'so that I can'
achieve some goal I want to, came from a start-up company called Connextra, and
they gave this stylized version which is useful for people to follow. So the format
here is that there's a feature name that's right there at the top of the card, which
lets us add a movie. And then here is the story, the "as a movie fan, so that I can
share a movie with other fans, I want to add a movie to Rotten Potatoes' database."
This is what, just what we've been doing. Now these three phrases, to follow Connextra
format, they have to be there but they can be in any order, they don't have
to be in this order. And the idea here is that these user stories, because they're
written before you've built any code, they can be used as acceptance tests. So why
the 3x5 cards? This actually came from our colleagues in the human computer interface
community. They were dealing with trying to get people to have good user interface
designs and so rather than doing it in code, they came up with these 3x5 cards.
The idea is that they can, it's non-threatening if you're working on these
cards, it's kind of you're playing with it. And everybody kind of participates.
And rather than just the programmers explaining what they thought the user
interface should be, it's everybody can participate and decide what they like. So
the cards, you can throw them away. You can shuffle them. You can prioritize them
so that it would seem to be a - an inviting way for non-technical people to get
involved. In contrast, we'd either do some kind of wire frame programming or actually have
kind of a user interface working. And people would find the collection of -
customers would be afraid to make suggestions because it was already
felt to be working. So it was the easier to use technology made it more
attractive for people to participate in it. And - and since these things are short,
it's really pretty easy to change during the development process.
Now, it's important that there, it said, as a stakeholder. Why do you do that?
Because different stakeholders will have different perspectives about what they
want from a particular feature. So I'd like to see which of my friends are going
to the show as a theatergoer so that I can have more fun with my friends. And, I want
to see which of my Facebook friends are actually going to the show. Now, that's a
perspective of somebody, a user, going to it. From the, from the box office manager,
your perspective of why this is a great feature is so that - get patrons to come,
and get her to bring more of her friends to the show. So the perspective will
give different priorities. So, maybe - and there needs to be people advocating
each of the stakeholders in these descriptions of the user stories. Real
systems don't have just a couple of stories, they have hundreds of stories.
It's easy to come up with features for a new application, can come up with the whole time, and
so what they call is - a 'backlog' is this collection of user stories that haven't
been implemented yet. And when we talk about - later in the course when we talk
about some of the tools that track user stories we'll see the word backward again.
And so you get these three by five cards and simply what you do is you prioritize
them, depending - the stake holders agree so the most valuable ones are charged the
front of the backhoe - ah, front of the backlog, and the less are behind them. And then
if you're going to do specific software releases and coordination with the
customer, they want to have something by certain dates, then you use three by five
cards and associate the release dates with collections of them.