Saturday, October 13, 2012

Projects Exploding Scope? Try To Be More Agile...

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. 

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

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

The Three C’s

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):



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