Visual specifications
Specs are death boredom. This is probably the most boring part of the job of managing a product. Perhaps that is why most of the specifications are terrible and are the main source of delays, rework and bugs.
Active communications and the availability of a product manager help to solve the problem of insufficiently good specifications, but not always.
Agile movement has its own look at the specifications. The most extreme wing expresses its views like this:
')
In the ass specs!
And a typical description of the requirement in such projects is as follows:
As a user
I want to add a new task quickly
To save time and not lose context
Surprisingly, this approach works. In certain cases. All conditions below must be met:
If at least one of the conditions is not met, the team has serious problems.
At the other end of the spectrum are a few individuals who are willing to spend a quarter of their lives creating exhaustive project documentation. They think through every little thing, describe each field in detail in form, go deeper into all negative scenarios and know exactly how the system should react to an inadvertent mouse click, an attempt to enter a name in SQL and a direct meteorite hit in the data center.
Many programmers do not like specifications. We introduce the definition, let it be “Class 1 Programmers”. They firmly know how the system should work, on which scenarios you can issue the messages “Unknown error” or “You can't do that” and where you need to cut corners in order to less mess with uninteresting things.
The presence of the specification is perceived as a restriction of the freedom of creativity and an expression of mistrust: “Ha, you would think, we do not know how best to make this feature”. Therefore, class 1 programmers do not like to read specifications. They can scan them, look at them and look at pictures, but they will not read them.
Class 2 programmers are completely different people. If the feature does not have a specification, they fall into a sad state and anticipate a lot of rework, belated disputes and bad decisions. They know that many direct contacts with testers are waiting for them in attempts to introduce a definition of a bug. They clearly see how much time they will have to spend in trying to catch the manager of the product and flattery or deception to extract answers to a dozen questions from him.
Distribution of programmers by type. Most normally refer to specifications.
Class 2 programmers read the specification from cover to cover, methodically digest it and ask deadly precise questions.
For programmers of class 2, you can create any specifications - they swallow everything. Class 1 programmers can only show pictures with short, clear captions without complex words. Better yet, they show a cartoon. I wanted to say - animation.
Between these two classes is a numerous one and a half class. These programmers read specifications and generally require their presence. But they do it without much zeal and thoughtfulness. Such programmers are most of all, and it is for them that specifications should be written by product managers. More precisely, it is necessary to lower the barrier to entry into the specification and convey ideas visually, briefly and vividly.
Testers have a hard life. Lack of specification turns the testing process into a slow torture of endurance and resistance to stress. Basically, a bug is a mismatch in the behavior of the specification system. When there is no specification, there are no bugs. What mercenary programmers use with pleasure.
For example, if the company has bonuses for the absence of bugs, then the best way to get a bonus is to stop writing specifications. No specifications - no problem. Product managers do not write specs (and in the free time they post seals on Facebook), programmers write code without bugs, and testers do not find bugs (well, unless sometimes the company suddenly decided that they are not needed at all). All good. Only customers who end up with the devil knows that with unpredictable behavior suffer.
Programmers for some reason can not afford to read the specifications, but testers - no. They will have to meticulously understand any garbage that the product manager has sketched from his head in the shortest possible time. They will have to systematically re-read everything, look for inconsistencies and ambiguities. And this can be used by lazy product managers. What, in fact, mess with the specification, if the tester reads everything and tries to correct all the errors.
Let's talk about the signs by which any fool can distinguish a bad specification from a good one.
According to Godel, there is no point in aiming for a complete specification. Any complete specification is inconsistent. So you have to accept the fact that any specification will be incomplete. The most that can be hoped for is consistency.
At this point, you can give up and say that once we can’t do a complete specification, why bother with it at all? However, reasonable attempts to get closer to fullness give a lot of advantages, and only two minuses: time and effort.
Finding a balance is not a simple task and there is no unambiguous answer; a lot depends on the context. However, it is clear that if, at the start of development, programmers come to a product manager with three or more questions, then you can safely deny the manager access to fresh fruit and coffee, so as not to be distracted, but get busy.
So how complete should the specifications be? The answer is pretty simple. First, the requirement specification should be limited to a few sentences. Before starting development, it should be as detailed as it is reasonable in terms of time.
Specification specification depending on the development phase of user story. At first, a couple of sentences are enough. At the beginning of the actual implementation, you need a complete specification.
It is desirable that, after studying the specification, there was no doubt whatsoever. In practice, during the development process, any restrictions are revealed or things that are unexpectedly difficult to implement. But with a good specification of them a little.
If the specification is too short, then the divergence effect lowers the morale of the team to the bottom of the glass. The feature expands, mutates, mutates, penetrates unexpected places of application and grows into it with a cancerous tumor. It seems that its development will never end. Heroic efforts are required for its folding, control and termination.
A typical development course features with missing (incomplete) specification. Identifying new problems increases the scope of work. Heroic efforts are required to complete the features.
There are people who like to appear extremely intelligent, although this is weakly correlated with their real abilities. They happily use words like “correlation”, “divergence” and “Godel”.
So, they terribly love to write complex texts, in which sentences occupy a paragraph, there are semicolons, and, scary to think, pictures are completely missing! Sometimes, such people, due to improbable fluctuations, become managers of the product, and make their destructive contribution to the success of the project.
Moreover, their specifications are simply boring to read, so precious calories of energy must be spent trying to understand what is actually meant by the phrase “the user performs the operation of switching to the next section of the client application by double-clicking the left mouse button.”
Specifications should be as simple as possible. The language should be clear even to a class 1 programmer, if he suddenly decides to distract himself from the pictures and read something. Programmers and so have to sweat to fulfill all your crazy demands, save them at least from the jungle of your intellect.
If the printed specification can cripple a fragile tester, then this specification clearly has serious problems. A good specification can kill a mosquito, a maximum fly, killing any creature of a larger size should raise questions. No unnecessary words, redundant paragraphs and repetitions. If it seems that there is nothing to throw out, and the specification is still big - break the feature into several smaller ones.
It may seem that size correlates (damn!) With fullness. However, filling the specification with water is clearly not a good idea. Fill it with meaning and life.
What are the general methods of explaining your thoughts? Let's go over them.
Too many spec developers like structurality. The most accessible structural elements: tables and lists. Often, there is nothing else in the specification: lists, lists, nested lists, nested lists nested in lists ... and tables.
On the one hand, tables really help to perceive well ... tabular data. But it is unlikely that any specification can be presented in the form of tabular data. Although some succeed:
An example of great use of tables.
Lists are also good in moderation. When the whole specification consists of them, by the fifth page I want to shoot the author, and by the seventh, I want to shoot myself.
An example of convincing use of lists.
Such use of the text spoils karma. Do not do this.
Usually, product managers do not like writing coherent text. Plates, lists, diagrams - it still all right. But to take and write a coherent story is beyond their strength. Therefore, narrative specifications in nature almost never occur. I took the liberty of writing one, for example.
It seems that reading this specification is much more interesting than the dry language of tables and lists. It reveals the motivation, gives you a feel and a solution. Vasya becomes just sorry and wants to help him somehow. Maybe give Vasya the opportunity to pinganut admin right now with one click on the link? Or to make a proactive error display even before Vasya released the cards?
Unfortunately, few people want to spend time on a normal coherent text. It is much easier to put a table in the document and fill its columns with dry verbs.
Perhaps the narrative specification is not formal enough. But if it is supplemented with the right pictures, then everything will be fine.
Behavior-Driven Development has a rather curious format for describing requirements. In fact, we describe the acceptance criteria for the feature. If all criteria pass, the feature is considered finished. Here is one example of a specification in BDD format:
What is good and bad about this approach? From the good, you can select a single format. You get used to it, and after a few weeks, somehow you immediately begin to write the specification in this format, not particularly including the brain. There is / made / received - a clear response format to any user action.
In addition, this specification can be automated. Of course, you will have to agree on a slightly more strict format, but in principle the product manager is able to issue scripts that will immediately turn into automated tests. Executable specifications - the dream of any developer.
Cons is also quite enough. First, everything that translates well into automated tests is usually poorly translated into the human brain. Specifications are primarily written for people, not for tests. To perceive the BDD format is quite difficult. Especially sad looks spec from a dozen scenarios. Well, no better than a list or a table, and often worse, because it contains so many repetitions of Given, When, Then. These repetitions introduce unnecessary noise, making it difficult to perceive useful signals.
BDD scripts are well suited for describing the interaction of a system with a user, but are completely inappropriate for non-functional requirements and interface elements.
When using BDD, it is almost impossible to cover the entire feature at once.
Many managers of products are afraid of pens, and their mood spoils from a set of colored pencils. They are embarrassed to draw and are sure that the sketches by hand look unprofessional and not cool enough. Instead of a pencil, they prefer Visio, OmniGraffle or any other expensive professional tool.
For sketches, it is not necessary to have a firm hand and the art of drawing straight lines with closed eyes. The advantage of sketches is that they can be made very quickly, take a picture on the phone and finally dilute the bleak spec with live pictures.
An outline of the reporting system in Targetprocess 3.
Usually draw the interface and, much less often, something deeper. Is it possible to make a spec from sketches? Quite, but not the fact that this is the best application of your artist abilities.
Outline the allowed assignments of tasks to people depending on the role, project and team in Targetprocess 3
Sketches have a serious drawback - the lack of detail. By definition, from the sketch you should not expect any trifles, it gives an overall picture, a general idea, but it raises many additional questions at the feature development stage.
Sketch timelines in Targetprocess 3.
I personally love sketches.
With design, everything is simple - it should be ready before the development stage. You should not hope that the designer will be able to rivet something for a couple of days, for which he himself will not be ashamed. Designers need time. Usually a lot. Design needs to start doing long before the feature gets into development.
There is a problem. It may happen that a feature with a ready-made design suddenly becomes unnecessary. There’s nothing you can do, you have to try to guess and design for features that are highly likely to be developed.
Ready timeline design in Targetprocess 3
So, the finished design should be an indispensable attribute of any specification. Can the design replace the entire specification? Unfortunately not. Usually, the design does not show all the system states, does not describe the interaction flows, all the scenarios are not worked out. The design is static. And we need a speaker. It is possible to show the dynamics in the design:
Three options for changing the requirements card over time
But it is long and difficult. Only a select few are able to scrutinize the options so scrupulously.
Storyboards love directors. In general, this is just a collection of individual key frames of a scene.
Typical storyboard to an incomprehensible film.
You don't have to be a great artist to draw storyboards. It is enough to be able to draw curves at arbitrary angles:
Typical fast storyboard.
In our industry, a storyboard is a collection of individual system states.
Storyboards are quite compact and make it possible to understand what kind of states there are. Excellent storyboards also show how to go into these states.
Storyboard quickly add tasks to Targetprocess 3 with an alternative scenario.
Unlike static sketches of the interface, storyboards show user interaction with the system. If the interaction is complex, then the storyboards are complex. This is a sign to think a little more, suddenly you can make it easier.
For a good understanding of the requirements, you need to know what actions the user can do and in what states the system can go. BDD scripts in general give such an understanding, but they need to be carefully read and translated into images that are understandable to programmers of class 1. And this is difficult. It is much easier to draw all actions and all states.
The flow diagram can simply show which state transitions are possible in response to user actions, or it can also contain UI elements (in this case, it approaches the storyboard).
I like drawing diagrams of flow no less than the sketches of the interface.
Context editing stream in Targetprocess 3.
All kids love cartoons. But when they find out that in order to create a one-minute cartoon, you need to make 1000 drawings, the majority forever discourages animated films.
Still, storyboards can be animated! Then it turns out a very visual thing that allows you to imagine how it all will work.
You can make the animation much faster than a live prototype. Of course, there will be no real interaction with the interface, but the main cases can be shown quite well.
In order to make animated gifs, perseverance, patience and professional deformation are needed. We began to get involved in animation Igor Trafimovich, and zabombil a few good examples:
Changes in the progress of the demand card over time in Targetprocess 3.
Animation can show the basic things, but to animate complex cases is quite problematic and time consuming.
Quickly edit data in Targetprocess 3 lists
Not all children love paper, scissors and glue. Some were beaten on the hands with a pointer for trying to cut off the neighbor's pigtail opposite, some of them never managed to cut an even circle, someone was glued to a chair in the middle of the lesson. Well, malicious glue lovers simply do not live to the desired professional level. Probably why paper prototypes are not very common.
It would seem that there is nothing easier to take the paper, draw the pieces of the interface, drag the video camera, record it all in a couple of hours and mount a small video. Come on, video, at least just to go through the interface and find out where there are controversial and incomprehensible places.
A paper set can be put in a backpack and go in search of intimidated users who will appreciate your prototype for the simple late in starbucks and will reveal to you the depths of their ... originality.
It is fun and interesting to work with paper. Interactions are visible perfectly. Time is required, of course, much more than for the sketch, but much less than for the real prototype. It seems to me that this type of prototyping is undervalued.
Paper prototyping iPad applications (which we started to do, but did not finish).
A good example of paper prototyping of a registration form.
Interactive specifications combine text and graphics, making them quite effective. To do them, you usually need to know how to program. Not all product managers have the necessary set of knowledge, they are somehow familiar tables and lists.
The only interactive specification I saw in my life was made by Oleg Seryag.
Interactive specification of customization of cards in Targetprocess 3. Clickable .
Here we can switch the size of the cards, the types of cards and quickly move to the desired item with a description of important properties.
Is it worth making interactive specs? Most likely no. For the prototype, they are not enough, and there are easier ways to convey all the information just as efficiently.
Most product managers cannot write code. They are not alien to some data structures, such as lists, queues and hash tables (although they do not know how they actually work). They generally have an idea of ​​cycles and conditional statements. But only a small number of product managers had experience writing real code. All this translates into the fact that they can not make a living prototype of the system on their own, which means they need to contact the programmers.
A good prototype gives answers to a huge number of questions. It allows you to go through many scenarios yourself and finally see the real interaction. On prototypes you can run usability tests. Prototypes can simply show customers and collect their wishes. A sales specialist can show a prototype to a potential client and lie that it is already in development and will soon (in 2 months) be released without fail.
It seems that nothing better can be desired. But not everything is so rosy, the prototype cannot completely replace the specification.
Unfortunately, almost always in prototypes implement only positive scenarios. The main goal of the prototype is to work on a breakthrough, proof of the performance of a particular solution. Negative scenarios do not affect the quality of the evidence, so they are left aside. However, for the developer, negative scenarios are extremely important. If developers do not want to think about them, then testers love it. As a result, you will have to patiently find out the nuances of the system behavior, painfully fix bugs and edit the messages “You can't do that!”.
The second problem is the lack of small details. The prototype is usually significantly different from the finished design. He can be generally quite scary in appearance, the main thing working.
The first prototype of Targetprocess 3, made to test the concept. Appeared to customers and caused general approval. Clickable , but not all that can be seen.
Through the prototype it is very tedious and will take a long time to figure out requirements like “and what is the maximum length of this field?”. Not only does the developer need to remember that the field has a length, so also poke the prototype with the mouse and watch the code in a vain attempt to find something good there.
So the prototype does not replace the specification. Excellent complements - this is please. But I would be careful not to go on reconnaissance with the product manager, who gives the developer a prototype with the words “everything is clear, start doing it”.
Another disadvantage is time. Prototypes for a long time. In general, there are two types of developers: fast and slow. Fast can be trusted to develop prototypes, slow - in no case. The quality of the code in the prototype, as you understand, can be arbitrarily bad. The main thing is to work the necessary scenarios. And it would seem that KO is now patting me from the back on the shoulder, but I myself have made such mistakes in the past.
The purpose of the specification is to convey ideas in the most clear and complete form. This works best when both text and graphics are used. Therefore, we need a healthy mix of various methods that we have already talked about. It is always hard, requires creativity and the desire to do good.
Below all methods are summarized in a single schedule. On the x-axis we have the difficulty of creating content. It is clear that it is difficult to make a living prototype, while sketching is pretty simple. Along the Y axis, we have utility, that is, how effectively this method conveys an idea. Again, the usefulness of pseudo-narrative specifications is not high, while the usefulness of the finished design or prototypes is high.
All methods of communicating ideas in one bottle.
It is advisable not to use low utility methods such as BDD and pseudo-narrative.Sketches, narratives, flowcharts, storyboards, paper prototypes and finished designs work well. It is worth spending time on animation and live prototypes only if there is really a lot of it.
Take the path of good friends! Create clear visual specifications that tell stories in plain language.
PS I still have 20 beautiful pictures in stock, but the article is so huge, so sorry.
Active communications and the availability of a product manager help to solve the problem of insufficiently good specifications, but not always.
Agile movement has its own look at the specifications. The most extreme wing expresses its views like this:
')
In the ass specs!
And a typical description of the requirement in such projects is as follows:
As a user
I want to add a new task quickly
To save time and not lose context
Surprisingly, this approach works. In certain cases. All conditions below must be met:
- the team sits in the same room
- have 24x5 access to the product manager
- there is no tester in the team
- designers are able to come up with solutions to any problem in 1 working day
If at least one of the conditions is not met, the team has serious problems.
At the other end of the spectrum are a few individuals who are willing to spend a quarter of their lives creating exhaustive project documentation. They think through every little thing, describe each field in detail in form, go deeper into all negative scenarios and know exactly how the system should react to an inadvertent mouse click, an attempt to enter a name in SQL and a direct meteorite hit in the data center.
Specifications and programmers
Many programmers do not like specifications. We introduce the definition, let it be “Class 1 Programmers”. They firmly know how the system should work, on which scenarios you can issue the messages “Unknown error” or “You can't do that” and where you need to cut corners in order to less mess with uninteresting things.
The presence of the specification is perceived as a restriction of the freedom of creativity and an expression of mistrust: “Ha, you would think, we do not know how best to make this feature”. Therefore, class 1 programmers do not like to read specifications. They can scan them, look at them and look at pictures, but they will not read them.
Class 2 programmers are completely different people. If the feature does not have a specification, they fall into a sad state and anticipate a lot of rework, belated disputes and bad decisions. They know that many direct contacts with testers are waiting for them in attempts to introduce a definition of a bug. They clearly see how much time they will have to spend in trying to catch the manager of the product and flattery or deception to extract answers to a dozen questions from him.
Distribution of programmers by type. Most normally refer to specifications.
Class 2 programmers read the specification from cover to cover, methodically digest it and ask deadly precise questions.
For programmers of class 2, you can create any specifications - they swallow everything. Class 1 programmers can only show pictures with short, clear captions without complex words. Better yet, they show a cartoon. I wanted to say - animation.
Between these two classes is a numerous one and a half class. These programmers read specifications and generally require their presence. But they do it without much zeal and thoughtfulness. Such programmers are most of all, and it is for them that specifications should be written by product managers. More precisely, it is necessary to lower the barrier to entry into the specification and convey ideas visually, briefly and vividly.
Specs and Testers
Testers have a hard life. Lack of specification turns the testing process into a slow torture of endurance and resistance to stress. Basically, a bug is a mismatch in the behavior of the specification system. When there is no specification, there are no bugs. What mercenary programmers use with pleasure.
For example, if the company has bonuses for the absence of bugs, then the best way to get a bonus is to stop writing specifications. No specifications - no problem. Product managers do not write specs (and in the free time they post seals on Facebook), programmers write code without bugs, and testers do not find bugs (well, unless sometimes the company suddenly decided that they are not needed at all). All good. Only customers who end up with the devil knows that with unpredictable behavior suffer.
Programmers for some reason can not afford to read the specifications, but testers - no. They will have to meticulously understand any garbage that the product manager has sketched from his head in the shortest possible time. They will have to systematically re-read everything, look for inconsistencies and ambiguities. And this can be used by lazy product managers. What, in fact, mess with the specification, if the tester reads everything and tries to correct all the errors.
Specification Properties
Let's talk about the signs by which any fool can distinguish a bad specification from a good one.
(Incomplete)
According to Godel, there is no point in aiming for a complete specification. Any complete specification is inconsistent. So you have to accept the fact that any specification will be incomplete. The most that can be hoped for is consistency.
At this point, you can give up and say that once we can’t do a complete specification, why bother with it at all? However, reasonable attempts to get closer to fullness give a lot of advantages, and only two minuses: time and effort.
Finding a balance is not a simple task and there is no unambiguous answer; a lot depends on the context. However, it is clear that if, at the start of development, programmers come to a product manager with three or more questions, then you can safely deny the manager access to fresh fruit and coffee, so as not to be distracted, but get busy.
So how complete should the specifications be? The answer is pretty simple. First, the requirement specification should be limited to a few sentences. Before starting development, it should be as detailed as it is reasonable in terms of time.
Specification specification depending on the development phase of user story. At first, a couple of sentences are enough. At the beginning of the actual implementation, you need a complete specification.
It is desirable that, after studying the specification, there was no doubt whatsoever. In practice, during the development process, any restrictions are revealed or things that are unexpectedly difficult to implement. But with a good specification of them a little.
If the specification is too short, then the divergence effect lowers the morale of the team to the bottom of the glass. The feature expands, mutates, mutates, penetrates unexpected places of application and grows into it with a cancerous tumor. It seems that its development will never end. Heroic efforts are required for its folding, control and termination.
A typical development course features with missing (incomplete) specification. Identifying new problems increases the scope of work. Heroic efforts are required to complete the features.
Mozgodrochka
There are people who like to appear extremely intelligent, although this is weakly correlated with their real abilities. They happily use words like “correlation”, “divergence” and “Godel”.
So, they terribly love to write complex texts, in which sentences occupy a paragraph, there are semicolons, and, scary to think, pictures are completely missing! Sometimes, such people, due to improbable fluctuations, become managers of the product, and make their destructive contribution to the success of the project.
Moreover, their specifications are simply boring to read, so precious calories of energy must be spent trying to understand what is actually meant by the phrase “the user performs the operation of switching to the next section of the client application by double-clicking the left mouse button.”
Specifications should be as simple as possible. The language should be clear even to a class 1 programmer, if he suddenly decides to distract himself from the pictures and read something. Programmers and so have to sweat to fulfill all your crazy demands, save them at least from the jungle of your intellect.
The size
If the printed specification can cripple a fragile tester, then this specification clearly has serious problems. A good specification can kill a mosquito, a maximum fly, killing any creature of a larger size should raise questions. No unnecessary words, redundant paragraphs and repetitions. If it seems that there is nothing to throw out, and the specification is still big - break the feature into several smaller ones.
It may seem that size correlates (damn!) With fullness. However, filling the specification with water is clearly not a good idea. Fill it with meaning and life.
Methods of communicating ideas
What are the general methods of explaining your thoughts? Let's go over them.
Pseudo-Narrative
Too many spec developers like structurality. The most accessible structural elements: tables and lists. Often, there is nothing else in the specification: lists, lists, nested lists, nested lists nested in lists ... and tables.
On the one hand, tables really help to perceive well ... tabular data. But it is unlikely that any specification can be presented in the form of tabular data. Although some succeed:
An example of great use of tables.
Lists are also good in moderation. When the whole specification consists of them, by the fifth page I want to shoot the author, and by the seventh, I want to shoot myself.
An example of convincing use of lists.
Such use of the text spoils karma. Do not do this.
Narrative
Usually, product managers do not like writing coherent text. Plates, lists, diagrams - it still all right. But to take and write a coherent story is beyond their strength. Therefore, narrative specifications in nature almost never occur. I took the liberty of writing one, for example.
The story about Vasya and Butch DnD
Vasya is planning the next iteration. He looks at the board, filled with cards. On the left, he notices the list of cards in the backlog. Vasya reads the names of user stories, and understands that the first three stories must be made in the next release. Vasya habitually presses Ctrl and clicks on each card, the cards invitingly turn yellow in response. Vasya grabs the first card and starts dragging it into the right column. Cards nicely fold into one, topped with a spectacular number 3 in the right corner. Vasya moves the cards to the correct column, but he still does not let them go, enjoying the way the column turns yellow to the cards in response.
A happy ending
Vasya lets go of the card, which splits into three. Once the job is done, the column returns to its usual gray color. Cards blink twice, assuring that they are already accustomed here, and also become normal. Vasya is happy.
Unhappy end
Vasya lets go of the card and suddenly he sees an alarming red message “You, my friend, do not have rights to change the iteration for the user of the story. Ask the admin, maybe he will. ” The cards jump back to the left column and remain yellow so that Vasya can fully feel his own insignificance compared to the system developers.
It seems that reading this specification is much more interesting than the dry language of tables and lists. It reveals the motivation, gives you a feel and a solution. Vasya becomes just sorry and wants to help him somehow. Maybe give Vasya the opportunity to pinganut admin right now with one click on the link? Or to make a proactive error display even before Vasya released the cards?
Unfortunately, few people want to spend time on a normal coherent text. It is much easier to put a table in the document and fill its columns with dry verbs.
Perhaps the narrative specification is not formal enough. But if it is supplemented with the right pictures, then everything will be fine.
BDD
Behavior-Driven Development has a rather curious format for describing requirements. In fact, we describe the acceptance criteria for the feature. If all criteria pass, the feature is considered finished. Here is one example of a specification in BDD format:
BD Chart drawn by weeks
As a scrum master
BD Chart drawn by weeks
When Iterations practice is disabled
So that I can benefit from BD chart
Given any development process
When I turn off Iterations practice in Admin -> Process -> Edit
BD chart
Then iteration velocity replaced by weekly velocity
End date
And BD
Chart Start Date
What is good and bad about this approach? From the good, you can select a single format. You get used to it, and after a few weeks, somehow you immediately begin to write the specification in this format, not particularly including the brain. There is / made / received - a clear response format to any user action.
In addition, this specification can be automated. Of course, you will have to agree on a slightly more strict format, but in principle the product manager is able to issue scripts that will immediately turn into automated tests. Executable specifications - the dream of any developer.
Cons is also quite enough. First, everything that translates well into automated tests is usually poorly translated into the human brain. Specifications are primarily written for people, not for tests. To perceive the BDD format is quite difficult. Especially sad looks spec from a dozen scenarios. Well, no better than a list or a table, and often worse, because it contains so many repetitions of Given, When, Then. These repetitions introduce unnecessary noise, making it difficult to perceive useful signals.
BDD scripts are well suited for describing the interaction of a system with a user, but are completely inappropriate for non-functional requirements and interface elements.
When using BDD, it is almost impossible to cover the entire feature at once.
Interface Sketches
Many managers of products are afraid of pens, and their mood spoils from a set of colored pencils. They are embarrassed to draw and are sure that the sketches by hand look unprofessional and not cool enough. Instead of a pencil, they prefer Visio, OmniGraffle or any other expensive professional tool.
For sketches, it is not necessary to have a firm hand and the art of drawing straight lines with closed eyes. The advantage of sketches is that they can be made very quickly, take a picture on the phone and finally dilute the bleak spec with live pictures.
An outline of the reporting system in Targetprocess 3.
Usually draw the interface and, much less often, something deeper. Is it possible to make a spec from sketches? Quite, but not the fact that this is the best application of your artist abilities.
Outline the allowed assignments of tasks to people depending on the role, project and team in Targetprocess 3
Sketches have a serious drawback - the lack of detail. By definition, from the sketch you should not expect any trifles, it gives an overall picture, a general idea, but it raises many additional questions at the feature development stage.
Sketch timelines in Targetprocess 3.
I personally love sketches.
Detailed design
With design, everything is simple - it should be ready before the development stage. You should not hope that the designer will be able to rivet something for a couple of days, for which he himself will not be ashamed. Designers need time. Usually a lot. Design needs to start doing long before the feature gets into development.
There is a problem. It may happen that a feature with a ready-made design suddenly becomes unnecessary. There’s nothing you can do, you have to try to guess and design for features that are highly likely to be developed.
Ready timeline design in Targetprocess 3
So, the finished design should be an indispensable attribute of any specification. Can the design replace the entire specification? Unfortunately not. Usually, the design does not show all the system states, does not describe the interaction flows, all the scenarios are not worked out. The design is static. And we need a speaker. It is possible to show the dynamics in the design:
Three options for changing the requirements card over time
But it is long and difficult. Only a select few are able to scrutinize the options so scrupulously.
Storyboards / Storyboards
Storyboards love directors. In general, this is just a collection of individual key frames of a scene.
Typical storyboard to an incomprehensible film.
You don't have to be a great artist to draw storyboards. It is enough to be able to draw curves at arbitrary angles:
Typical fast storyboard.
In our industry, a storyboard is a collection of individual system states.
Storyboards are quite compact and make it possible to understand what kind of states there are. Excellent storyboards also show how to go into these states.
Storyboard quickly add tasks to Targetprocess 3 with an alternative scenario.
Unlike static sketches of the interface, storyboards show user interaction with the system. If the interaction is complex, then the storyboards are complex. This is a sign to think a little more, suddenly you can make it easier.
Flows / Flows
For a good understanding of the requirements, you need to know what actions the user can do and in what states the system can go. BDD scripts in general give such an understanding, but they need to be carefully read and translated into images that are understandable to programmers of class 1. And this is difficult. It is much easier to draw all actions and all states.
The flow diagram can simply show which state transitions are possible in response to user actions, or it can also contain UI elements (in this case, it approaches the storyboard).
I like drawing diagrams of flow no less than the sketches of the interface.
Context editing stream in Targetprocess 3.
Animation / gifs
All kids love cartoons. But when they find out that in order to create a one-minute cartoon, you need to make 1000 drawings, the majority forever discourages animated films.
Still, storyboards can be animated! Then it turns out a very visual thing that allows you to imagine how it all will work.
You can make the animation much faster than a live prototype. Of course, there will be no real interaction with the interface, but the main cases can be shown quite well.
In order to make animated gifs, perseverance, patience and professional deformation are needed. We began to get involved in animation Igor Trafimovich, and zabombil a few good examples:
Changes in the progress of the demand card over time in Targetprocess 3.
Animation can show the basic things, but to animate complex cases is quite problematic and time consuming.
Quickly edit data in Targetprocess 3 lists
Paper prototypes
Not all children love paper, scissors and glue. Some were beaten on the hands with a pointer for trying to cut off the neighbor's pigtail opposite, some of them never managed to cut an even circle, someone was glued to a chair in the middle of the lesson. Well, malicious glue lovers simply do not live to the desired professional level. Probably why paper prototypes are not very common.
It would seem that there is nothing easier to take the paper, draw the pieces of the interface, drag the video camera, record it all in a couple of hours and mount a small video. Come on, video, at least just to go through the interface and find out where there are controversial and incomprehensible places.
A paper set can be put in a backpack and go in search of intimidated users who will appreciate your prototype for the simple late in starbucks and will reveal to you the depths of their ... originality.
It is fun and interesting to work with paper. Interactions are visible perfectly. Time is required, of course, much more than for the sketch, but much less than for the real prototype. It seems to me that this type of prototyping is undervalued.
Paper prototyping iPad applications (which we started to do, but did not finish).
A good example of paper prototyping of a registration form.
Interactive specs
Interactive specifications combine text and graphics, making them quite effective. To do them, you usually need to know how to program. Not all product managers have the necessary set of knowledge, they are somehow familiar tables and lists.
The only interactive specification I saw in my life was made by Oleg Seryag.
Interactive specification of customization of cards in Targetprocess 3. Clickable .
Here we can switch the size of the cards, the types of cards and quickly move to the desired item with a description of important properties.
Is it worth making interactive specs? Most likely no. For the prototype, they are not enough, and there are easier ways to convey all the information just as efficiently.
Living prototypes
Most product managers cannot write code. They are not alien to some data structures, such as lists, queues and hash tables (although they do not know how they actually work). They generally have an idea of ​​cycles and conditional statements. But only a small number of product managers had experience writing real code. All this translates into the fact that they can not make a living prototype of the system on their own, which means they need to contact the programmers.
A good prototype gives answers to a huge number of questions. It allows you to go through many scenarios yourself and finally see the real interaction. On prototypes you can run usability tests. Prototypes can simply show customers and collect their wishes. A sales specialist can show a prototype to a potential client and lie that it is already in development and will soon (in 2 months) be released without fail.
It seems that nothing better can be desired. But not everything is so rosy, the prototype cannot completely replace the specification.
Unfortunately, almost always in prototypes implement only positive scenarios. The main goal of the prototype is to work on a breakthrough, proof of the performance of a particular solution. Negative scenarios do not affect the quality of the evidence, so they are left aside. However, for the developer, negative scenarios are extremely important. If developers do not want to think about them, then testers love it. As a result, you will have to patiently find out the nuances of the system behavior, painfully fix bugs and edit the messages “You can't do that!”.
The second problem is the lack of small details. The prototype is usually significantly different from the finished design. He can be generally quite scary in appearance, the main thing working.
The first prototype of Targetprocess 3, made to test the concept. Appeared to customers and caused general approval. Clickable , but not all that can be seen.
Through the prototype it is very tedious and will take a long time to figure out requirements like “and what is the maximum length of this field?”. Not only does the developer need to remember that the field has a length, so also poke the prototype with the mouse and watch the code in a vain attempt to find something good there.
So the prototype does not replace the specification. Excellent complements - this is please. But I would be careful not to go on reconnaissance with the product manager, who gives the developer a prototype with the words “everything is clear, start doing it”.
Another disadvantage is time. Prototypes for a long time. In general, there are two types of developers: fast and slow. Fast can be trusted to develop prototypes, slow - in no case. The quality of the code in the prototype, as you understand, can be arbitrarily bad. The main thing is to work the necessary scenarios. And it would seem that KO is now patting me from the back on the shoulder, but I myself have made such mistakes in the past.
Specification = visual explanation
The purpose of the specification is to convey ideas in the most clear and complete form. This works best when both text and graphics are used. Therefore, we need a healthy mix of various methods that we have already talked about. It is always hard, requires creativity and the desire to do good.
Below all methods are summarized in a single schedule. On the x-axis we have the difficulty of creating content. It is clear that it is difficult to make a living prototype, while sketching is pretty simple. Along the Y axis, we have utility, that is, how effectively this method conveys an idea. Again, the usefulness of pseudo-narrative specifications is not high, while the usefulness of the finished design or prototypes is high.
All methods of communicating ideas in one bottle.
It is advisable not to use low utility methods such as BDD and pseudo-narrative.Sketches, narratives, flowcharts, storyboards, paper prototypes and finished designs work well. It is worth spending time on animation and live prototypes only if there is really a lot of it.
Take the path of good friends! Create clear visual specifications that tell stories in plain language.
PS I still have 20 beautiful pictures in stock, but the article is so huge, so sorry.
Source: https://habr.com/ru/post/197638/
All Articles