Java Reference
In-Depth Information
subject, let's start by establishing a base of what
agile
and the development process will mean for this
book.
The agile process has 12 tenets that virtually all of its variants prescribe. They are as follows:
•
Customer satisfaction comes from quick delivery of working software.
•
Change is welcome regardless of the stage of development.
•
Deliver working software frequently.
•
Business and development must work hand in hand daily.
•
Build projects with motivated teams. Give them the tools and trust them to get the
job done.
•
Face-to-face communication is the most effective form.
•
Working software is the number-one measure of success.
•
Strive for sustainable development. All members of the team should be able to
maintain the pace of development indefinitely.
•
Continue to strive for technical excellence and good design.
•
Minimizing waste by eliminating unnecessary work.
•
Self-organizing teams generate the best requirements, architectures, and designs.
•
At regular intervals, have the team reflect to determine how to improve.
It doesn't matter if you're using Extreme Programming (XP), Scrum, or any other currently hip
variant. The point is that these dozen tenets still apply.
Notice that not all of them will necessarily apply in your case. It's pretty hard to work face to face
with a book. You'll probably be working by yourself through the examples, so the aspects of team
motivation don't exactly apply either. However, there are pieces that do apply. An example is quick
delivery of working software. This will drive you through out the topic. You'll accomplish it by building
small pieces of the application, validating that they work with unit tests, and then adding onto them.
Even with the exceptions, the tenets of agile provide a solid framework for any development project,
and this topic applies as many of them as possible. Let's get started looking at how they're applied by
examining the way you document the requirements for the sample job: user stories.
Capturing Requirements with User Stories
User stories
are the agile method for documenting requirements. Written as a customer's take on what
the application should do, a story's goal is to communicate the how a user will interact with the system
and document testable results of that interaction. A user story has three main parts:
•
The title:
The title should be a simple and concise statement of what the story is
about.
Load transaction file.
Calculate fee tier.
Generate print file.
All of these are
good examples of story titles. You notice that these titles aren't GUI specific. Just
because you don't have a GUI doesn't mean you can't have interactions between
users. In this case, the user is the batch process you're documenting or any
external system you interface with.
