Agile is Principle, not just a Methodology. Agile doesn't mean to take less Discipline, but More.
1. Principle 1: Keep it Simple by telling User Stories; Get in Detail by Making User Cases
Storytelling is how
cultures survive and progress; it is the simplest and most effective way to
pass knowledge from one person to another. It is the best way to communicate
what a system should do, and to get everybody working on the system to focus on
the same goals. Therefore, user stories can enforce agile-style iterative
communication and interaction.
The use cases capture the goals of the system. To understand a use case, you tell stories. The stories cover how to successfully achieve the goal, and how to handle any problems that may occur on the way. Use cases provide a way to identify and capture all the different but related stories in a simple but comprehensive way. This enables the system’s requirements to be easily captured, shared and understood.
2. Principle 2: Be Flexible in Communication
User Case is formal. Use Cases are meant to be a complete specification of all possible scenarios and outcomes related to a feature, exposed to an actor. It is meant to be detailed to a point where it considers the design / messaging / alternate flows etc. There is usually very little room for negotiation once a Use Case has been specified, developers and QA should use this as the source of truth all through the development process.
User Story is informal: User Stories on the other hand are meant to be much less formal. At the core is the idea that in a sentence, you should be able to specify the feature to be built using a template like "As an {type of actor} I want to be able to {do something using the system} so that {some actor goal} can be achieved". This format allows for a lot of flexibility in terms of the details of the implementation, while ensuring the agile team are always aware of the objective. Since the User Stories do not specify the most details, QA tests if the outcome is "Acceptable" and achieves the desired goal.
User Story is informal: User Stories on the other hand are meant to be much less formal. At the core is the idea that in a sentence, you should be able to specify the feature to be built using a template like "As an {type of actor} I want to be able to {do something using the system} so that {some actor goal} can be achieved". This format allows for a lot of flexibility in terms of the details of the implementation, while ensuring the agile team are always aware of the objective. Since the User Stories do not specify the most details, QA tests if the outcome is "Acceptable" and achieves the desired goal.
3. Be Adaptive to Different Project
For many dynamic projects, high-level user stories are the way to go and lend
themselves better to planning sessions and introducing detailed functionality
at the last possible minute, rather than attempting to decide all of it way too
early and too much in depth. When using storytelling as a technique to
communicate requirements, it is essential to make sure that the stories are
captured in a way that makes them actionable and testable.
if the project favors a "All Design and Analysis
upfront" style, Use Cases are the way to go, and it also depends on
project complexity, user stories tend to be more granular, focused on
individual features, as opposed to use cases that can be complex and include
all alternative routes.
Agile is about alternatives, selecting the proper communication style to fit the need is the first step for Agile success.
Agile is about alternatives, selecting the proper communication style to fit the need is the first step for Agile success.
0 comments:
Post a Comment