Patton Jeff. Custom stories. The art of agile software development

annotation

The book is a narrated algorithm for conducting the development process from idea to implementation using agile techniques. The process is laid out in steps and at each step the methods for the process step are indicated. The author points out that most of the methods are not original, without claiming to be original. But a good presentation style and some integrity of the process make the book very useful.

The key technique of the user story map is the structuring of ideas and statements as the user goes through the process.

At the same time, the process can be described in different ways. You can build steps as you achieve key value, or you can just take and imagine the users working day, how it works using the system. The author focuses on the fact that the processes need to be stated, pronounced in the form of user history on the process map, which was the name of the user story map.

Who needs it

For IT analysts and project managers. Required reading. It reads easily and pleasantly, the book is medium in size.

Feedback

In its simplest form, how it works.

A visitor comes to a cafe, chooses dishes, makes an order, receives food, eats, pays.

You can write the requirements that we want from the system at each stage.

The system should show a list of dishes, each dish composition, weight and price and be able to add to the basket. Why are we confident in these requirements? This is not described in the “standard” description of requirements and this creates risks.

Artists who do not understand why this is necessary usually do not what is needed. Performers who are not involved in the process of creating an idea are not involved in the result. Agile says, so let's focus primarily not on the system, but on people, on consumers, their tasks and goals.

We make people, for empathy we give them details and on the part of people we begin to set out stories.

Office employee Zahar has gone for lunch and wants a quick bite to eat. What does he need? The idea is that he probably wants a business lunch. Another idea he wants the system to remember is his preference, because he is on a diet. Another idea. He wants to get coffee right away, because he's used to drinking coffee before dinner.

And there is still business (organizational character is a character representing the interests of some organization). The business wants to increase the average bill, increase the frequency of purchases, increase profits. The idea is, let's offer unusual dishes of some kind of cuisine. Another idea - let’s introduce breakfast.

Ideas can and should be concretized, transformed and designed as a user story. As an employee of the Zakhar business center, I want the system to recognize me, so that I receive a menu based on my preferences. As a waiter, I want the system to notify me when to approach the table so that the client is satisfied with the quick service. Etc.

Dozens of stories. Further prioritization and backlog? Jeff points out the problems that arise: the linking in small details and the loss of conceptual understanding plus prioritization of the functional creates a torn picture due to inconsistency with goals.

Author’s path: We prioritize not the functional, but the result = what the user gets as a result.

An obvious non-obvious point: the priority session is not held by the whole team, because it is ineffective, but by three people. The first is responsible for business, the second for user experience and the third for implementation.

We select a minimum for solving one user problem (the minimum viable solution).

We detail the ideas of the first priority with the help of a user story, outline designs, restrictions and business rules on the map of user stories by telling and discussing with the team what people and stakeholders need at each step of the process. The remaining ideas are left unassembled, in the backlog of opportunities.

The process is written in the form of cards from left to right, and ideas on the cards under the steps of the process. Necessarily the path of the entire history must be spoken out together with the team for the appearance of mutual understanding.

Exposure in this way creates integrity for process matching.

The ideas you need to check. Not a member of the team puts on a person’s hat and lives in the head of the person’s day, solving his problem. A variant is possible when he does not see the developments, creating cards anew, and the team discovers alternatives.

Then drill down for evaluation. Three people are enough for this. Responsible for user experience, developer, tester with a favorite question: “What if ...”.

At each stage, the discussion goes on a map of the user's history processes, which allows keeping the user's task in mind to create an integrity of understanding.

Do I need documentation according to the author? Yes, I need it. But as notes, allowing us to remember what we agreed on. The involvement of a person from the outside again requires discussion.

The author does not delve into the topic of sufficiency of documentation, focusing on the need for discussion. (Yes, documentation is needed, no matter how people who are not deep in understanding agile). Also, the study of only part of the capabilities may lead to the need for a complete alteration of the entire system. The author points out the risk of excessive elaboration in the case when they have not guessed with the idea.

To remove risks, it is necessary to quickly receive feedback on the created product to minimize the damage to the creation of the “wrong” product. They made a sketch of the idea - validated by the user, a sketch of the interface prototypes - validated by the user, etc. (Separately, a little is indicated how to validate prototypes of programs). The goals of creating software, especially at the initial stage, are training through quick feedback; accordingly, the first product created is an outline that can prove or disprove a hypothesis. (The author relies on the work of Eric Rice, “Startup by Lean Methodology”).

A story map helps to establish communication if the implementation is provided by several teams. What should be on the map? What you need to support the conversation. Not only user story (who, what, why), but ideas, facts, outline interfaces, etc. ...

Dividing the cards on the history map into several horizontal lines, you can divide the work into releases - select the very minimum, the layer of building functionality and bows.

We tell stories on the process map.

The employee came for lunch.

What does he want? Service speeds. So that his dinner is already waiting for him on the table or at least on a tray. Opa - a missed step: the employee wanted to eat. He logged into the system and chose the business lunch option. He saw calorie content and nutritional value in order to maintain a diet and not get fat. He saw pictures of the dish to decide whether he would eat in this place or not.

Next, he will go to get lunch and lunch? Or maybe he will get lunch at the office? Then the step of the process is the choice of the place of food. He wants to see the time when he will be delivered and how much it will cost to choose where to spend time and effort - to go down or to work. He wants to see the cafe busy so as not to jostle in lines.

Next, the employee came to the cafe. He wants to see his tray, to take it and immediately go to dinner. The cafe wants to accept money in order to earn money on maintenance. An employee wants to lose a minimum of time in settlements with a cafe, so as not to waste precious time without benefit. How to do it? Pay in advance or vice versa after servicing remotely. Or pay at the moment using a kiosk. Which of these is the most basic? How many people are willing to pay by credit card for lunch? How many people trust the storage of the card number for repeated payments of this dining room? Without field research, it is unclear whether testing is needed.

At each step of the process, you need to at least somehow provide functionality, for this you need to take as a basis some kind of person and choose what is more important to him (the same three electors). Passed the story to the end = made a viable decision.

Next is the detail. The client wants to see the cafe’s workload so as not to jostle in the queues. What exactly does he want?

Watch the forecast how many people will be in 15 minutes, when he gets there.

Watch the average service time in the cafe and its dynamics for half an hour ahead.

Watch the situation and the dynamics of the tables

. What if the forecasting system gives an incomprehensible result or stops working?

Watch through the video lines in the cafe, as well as the employment of tables. Hmm, why not do it first?

The author points out a small exercise for practicing practice: try to imagine what you are doing in the morning after waking up. One card = one action. Enlarge the cards (instead of grinding coffee - drink a refreshing drink) to remove individual details, focusing not on the way of implementation, but on the goal.

For whom this book is for IT analysts and project managers. Required reading.

Applications

Discussion and decision making are effective in groups of 3 to 5 people.

Write on the first card what needs to be developed, on the second - to fix what was done in the first, in the third - to fix what was done in the first and second.

Prepare stories like cakes - not writing out a recipe for making, but finding out to whom, for what reason, how many people have a cake. If you break down the implementation, then not on the manufacture of cakes, cream, etc., but on the manufacture of small finished cakes.

Software development is similar to making a film when you need to carefully develop and lick a script, organize a scene, actors, etc., before filming begins.

Resources will always be scarce.

20% of the efforts give a tangible result, 60% give it is unclear that, 20% of the efforts are detrimental - that is why it is important to focus on learning and not to despair in case of a negative result.

Communicate with the user directly, feel in his shoes. Focus on some issues.

Detailing and working out the history for evaluation is the most dreary part of scrum, make the discussions stand-up in an aquarium mode (3-4 people discuss at the board, if someone wants to participate, he replaces someone).