As IT professionals, we have all
at one time or another, either at school, or work, have found themselves troubleshooting adjusting a script, or writing a line of code so a printer will work, or maybe, as a
software programmer reviewed, troubleshoot, and written software code. The point being, we are all quite familiar
with the development process. We started
with the goal, get the requirements, then we break up the functions in little
battalions and then… storm the beaches of Normandy suffering unbelievable
casualties of time, money, and quality. As the old project adage goes, you want
it Fast, Cheap, and Good, pick two.
However, there is one nemesis that can thwart all three, Scope.
So if you find
that your software projects seemed to be long on the tooth, or are just not
quite meeting your expectations, perhaps, your team needs to be open to new
techniques, flexible in their methods, quicker to adapt new ideas, in a word,
Agile.
Source(s):
About Rick Ricker
To contain the beast known as Scope Creep, many have tried to refine
this process to a ubiquitous regiment that manages scope through the
requirements, e.g., Yourdon Demarco, Structured Analysis, Rapid, Structured English, the list is
endless. However, many have faded away
in the halls of also-rans. Conversely, there
are a few that seem to have persevered, one is even experiencing a resurgence,
Agile.
Agile Software Development (ASD) is a concept, a philosophy and a
methodology which evolved in the 90's as an answer to the long-growing
frustrations of the waterfall SDLC concepts. The term promotes an iterative
approach to software development using shorter and lightweight development
cycles and some different deliverables.
Agile software development focuses on keeping code simple,
testing often, and delivering functional bits of the application as soon as
they're ready. The goal of ASD is to build upon small client-approved parts as
the project progresses, as opposed to delivering one large application at the
end of the project.
Enter User Stories
At the center of Agile is User
Stories. User Stories are not
memorialized meanderings of their experiences, but rather a specific way to
describe pieces of functionality from your intended user’s point of view.
"User Stories are a boundary
object. A boundary object is a concept in sociology to describe information
used in different ways by different communities. They are plastic, interpreted
differently across communities but with enough immutable content to maintain
integrity”
--Wikipedia
The components of a user story
are:
- Type of User (As a),
- Goal (I want to),
- Reason (so that).
For example,
USER STORY
- As a: Visitor of the website
- I want to: Submit my email address
- So that: I can receive the newsletter
Card, conversion, confirmation, the
card holds the User Story, it can be placed on a card and affixed on a wall,
placed on a table, or board or your folder. The point being is that your goal
is clearly defined. However, the real
value of the card is not the card itself, but the conversation it fuels.
User Stories force you to talk about what is
relevant and what might just be esoteric.
Once hammered out, then confirmation comes to validate the User Story. Once accepted as ready, then how the piece of
functionality is tested and finished is driven toward the User Story.
This seems a little rudimentary,
but it’s better than getting all mixed up in gigantic dissertations of
requirements, that frankly, will never be read by anyone other than the
author. Just because it is in writing
doesn’t ensure clarity. In short, stop
typing, start talking.
Another key to
User Stories is that is puts an end to the idea that process is key (as
Structured Analysis would leave you to believe). Typically, developers today focus too much on
the technology and process, i.e., how it will happen, when they really should
be asking what will happen. By focusing on the user and putting their actions
front and center, it keep us from being distracted with what could be done, and
grounds us back to what should be done.
By using this
user centric scope definition, you aren’t chasing windmills of functionality
the user will never use. Don’t believe
us? Have you used Microsoft Word lately? When was the last time you used the
“Solstice” option in the Effects menu?
When restricting your scope to the user’s goal, you can code faster and
will have more time for quality and testing.
So if you find
that your software projects seemed to be long on the tooth, or are just not
quite meeting your expectations, perhaps, your team needs to be open to new
techniques, flexible in their methods, quicker to adapt new ideas, in a word,
Agile.Source(s):
- http://www.slideshare.net/bartvermijlen/user-stories-develop-better-products-faster-and-cheaper
- http://searchsoftwarequality.techtarget.com/definition/agile-software-development
- http://www.agileproductdesign.com/presentations/user_story_mapping/index.html
So “Once more unto the breach, dear friends, once more;”
____________________________________________________________
About Rick Ricker
An IT professional with over 21 years experience in Information Security, wireless broadband, network and Infrastructure design, development, and support.
For more information, contact Rick at (800) 399-6085





No comments:
Post a Comment
Thanks for your input, your ideas, critiques, suggestions are always welcome...
- Wasabi Roll Staff