Modeling is a keyword in agile methods. Agile modeling seizes on the opportunity to create models. These can be logical models such as drawings of systems, or mock-ups such as the prototypes described earlier in this chapter. A typical agile modeling process would go something like this:
- Listen for user stories from the customer.
- Draw a logical workflow model to gain an appreciation for the business decisions represented in the user story.
- Create new user stories based on the logical model.
- Develop some display prototypes. In doing so, show the customers what sort of interface they will have.
- Using feedback from the prototypes and the logical workflow diagrams, develop the system until you create a physical data model.
Agile is the other keyword in agile modeling. Agile implies maneuverability. Today’s systems, especially those that are Web-based, pose twin demands: getting software released as soon as possible and continually improving the software to add new features. The systems analyst needs to have the ability and methods to create dynamic, context-sensitive, scalable, and evolutionary applications. Agile modeling as such is a change-embracing method.
Writing User Stories
Even though the title of this section is “Writing User Stories,” the emphasis in the creation of user stories is on spoken interaction between developers and users, not the written communication. In user stories, the developer is seeking first and foremost to identify valuable business user requirements. Users will typically engage in conversations every day with the developers about the meaning of the user stories they have written. These frequent conversations are purposeful interactions that have as their goal the prevention of misunderstandings or misinterpretations of user requirements. Therefore, user stories serve as reminders to the developers that they must hold conversations devoted to those requirements.
The following is an example of a series of stories written for an ecommerce application for an online merchant of books, CDs, and other media products. The stories give a fairly complete picture of what is needed at each of the stages in the purchase process, but the stories are very short and easy to comprehend. The point here is to get all the needs and concerns of the online store out in the open. Although there is not enough of a story to begin programming, an agile developer might begin to see the overall picture clearly enough to begin estimating what it takes to complete the project. The stories are as follows:
|
As you can easily see, there is no shortage of stories. The agile analyst needs to choose a few stories, complete the programming, and release a product. Once this is done, more stories are selected and a new version is released until all the stories are included in the system (or the analyst and customer agree that a particular story lacks merit, or is not pressing, and so need not be included). An example of a user story as it might appear to an agile developer is shown in the figure below. On cards (or electronically), an analyst might first identify the need or opportunity, and then follow it with a brief story description. The analyst might take the opportunity to begin thinking broadly about the activities that need to be completed as well as the resources it will take to finish the project. In this example from the online merchant, the analyst indicates that the designing activity will take above-average effort, and the time and quality resources are required to rise above average. Notice that the analyst is not trying to be more precise than currently possible on this estimate, but it is still a useful exercise.
Scrum
Another agile approach is named Scrum. The word scrum is taken from a starting position in rugby in which the rugby teams form a huddle and fight for possession of the ball. Scrum is really about teamwork, similar to what is needed in playing a game of rugby.
Just as rugby teams will come to a game with an overall strategy, development teams begin the project with a high-level plan that can be changed on the fly as the “game” progresses. Systems development team members realize that the success of the project is most important, and their individual success is secondary. The project leader has some, but not much, influence on the detail. Rather, the tactical game is left up to the team members, just as if they were on the field. The systems team works within a strict time frame (30 days for development), just as a rugby team would play in a strict time constraint of a game.
We can describe the components of the scrum methodology as:
- Product backlog, in which a list is derived from product specifications.
- Sprint backlog, a dynamically changing list of tasks to be completed in the next sprint.
- Sprint, a 30-day period in which the development team transforms the backlog into software that can be demonstrated.
- Daily scrum, a brief meeting in which communication is the number-one rule. Team members need to explain what they did since the last meeting, whether they encountered any obstacles, and what they plan to do before the next daily scrum.
- Demo, working software that can be demonstrated to the customer.
Scrum is indeed a high-intensity methodology. It is just one of the approaches that adopts the philosophy of agile modeling.
Contents
- Prototyping: Kinds of Prototypes
- Developing a Prototype: Guidelines
- Users’ Role in Prototyping
- Rapid Application Development (RAD)
- Comparing RAD to the SDLC
- Agile Modeling : Values and Principles of Agile Modeling
- Activities, Resources, and Practices of Agile Modeling
- The Agile Development Process
- Lessons Learned from Agile Modeling
- Improving Efficiency in Knowledge Work: SDLC Vs Agile
- Risks Inherent in Organizational Innovation
