Daring bird structures: development flow
If you cannot describe the structure of your organization, department, or work in general on your fingers, it means that you are doing it inefficiently.
Efficiency and transparency are never the same thing. You can transparently do ineffective things, and effectively do things opaque.
Building a work structure is a complex, individual process, with a touch of audacity. Because we need not only courage and reflection (âwe work inefficiently, why?â), But also the ability to make graceful conglomerations.
')
Graceful piles - a pledge of the creation of structures. It seems âwe donât need it, we work and itâs okay, why do we need extra layersâ, but in fact - one thoughtful layer will take your work to a new level. It is a jumble, but it is elegant. Something like dependency injection or using Photoshop instead of painting with colors.
If now you thought âno, we are all efficientâ - do not even hope. Ineffective. Even if you absolutely, absolutely, never create any blockages in your work at all, then you just live in illusions. It's impossible. Efficiency is a fucking process, not a given. And a specific person should provide this process. And others - to support. Not because âthey said soâ, but because everyone will be fine - everyone will work the way they feel comfortable and be effective.
In short, we call our brainchild of exquisite piles of âarrogant bird structuresâ or âdevelopment flowâ. Now we describe it, and still eat a couple of your dogs in disputes.
Development Flow is designed to fulfill 4 commitments:
Development Flow is a tool that creates a system .
The system consists of elements, the elements are different, and the âcurrentâ flows through them - the workflow. In IT, âcurrentâ is the code, design, documents, and other things with which we work.
Systems are missing
If you do not know at what stage of your Private Flow are now (for example, âdeveloping the featuresâ), and do not know what stage you are in the General Flow (for example, the fourth, after the Product Owner, Scrum Wizard and Designer), and which the stage should follow you, what are his criteria for returning, and many other trivialities ...
Or if you know, but for your work with you, the Project Manager should sit next to you and remind you exactly at this very second you should be engaged (do not look away from the monitor, immediately follow up programs) ...
Or if you just feel that you are ineffective ...
... then most likely you do not have a System.
System fails to work properly
All is not gold that glitters. Not all the V12 that is under the hood. And most importantly - not every engine works correctly, even if it goes (hello, beloved by the auto industry).
It is important to have a properly working system, because this is our confidence. In their work, in the work of the whole system. You will immediately find problems, most of which can be solved.
Engine running has sound. He is rhythmic, pleasant. If there is a problem there, it is audible to the sensitive ear of the master. Squeak, sneezing, rhythm disturbance, knock. It slowly or quickly destroys the engine, and the âbusiness carâ breaks down precisely when you took a dollar mortgage on the top three inside the ring.
In the system of people's work, these noises - violation of deadlines, discontent, personnel leakage, reduced tone of employees, transfer of problems to the neighboring department - and much more. A good manager walks around the office with splayed supersensitive locators instead of ears. He is aware of the impending storm, he feels that the pressure has dropped. He hears all the short sighs, and notices the abstracted eyes. He is the System.
The DF system includes two sections - General Flow (the functioning of the system as a whole), and Private Flow (the functioning of its individual parts).
The system consists of elements combined into a structure to achieve the intended goal.
The goal in IT is to release a product at the right time of the right quality. The elements of the system are the participants of the process: the Product Owner, the Project Manager, the Scrum Master, the Developer, the Designer, the Tester, the Technical Writer ... All these are elements, and not all of them are ever present. Sometimes the roles are combined. It is necessary to highlight its elements.
It is necessary to highlight its elements. Write them down and draw your first flow with the arrow. This is called Total Flow.
Owner â SM â Designer, Developer â Tester â Tech Recorder
The task is to combine the elements into a structure and show what professional interactions are possible. Non-professional - that the designer and the owner of the product live together, is not necessary. You only need to role. The owner should not interact with the Designer or the Developer. Only Scrum Master. Only. Scrum master.
When we select interactions, these arrows, we must show what the First gives, and that the Second returns as feedback. So the system begins to live.
Owner â gives a description of the task â SM
SM will reformulate it both for the Owner and for the rest. Assessment of the task - approximate - will line up by itself. But the task of SM - from a simple description, applying an elegant jumble, to make a SUFFICIENT_DESCRIPTION. Parts of this TO he will discuss and distribute with the team.
SM â gives parts of DO â Designer and Developer
TO includes the scheme, all its possible states, and much more (I donât want to pile on for now). Everyone gets their part. Not always at the same time. Usually the Designer is ahead of the Developer by one sprint.
The designer and the Developer at the daily rally, in return for communicating with the SM, returns to him his vision of the task. Make sure that we understand everything the same way. It takes 25-28 seconds. And saves hours and weeks.
Developer â after his private flow (more on this later), sends the code â to Tester
The developer gives the code, the tester looks to his part of the TO, and fulfills his flow. Tester's feedback is for SM â âpositiveâ, that is, how he understands the task, and for Developer â ânegativeâ - only if it is broken.
The developer has no idea that his code is being tested, until problems arise.
I think that the general flow is correctly formulated as follows. The first gives to the Second, the Second processes, returns "positive" or "negative" Feedback, moves further into the General flow. Positive feedback - the conviction that everything works as intended; negative feedback shows where and what went wrong.
In this article, I will sort out the private flow of the Owner, CM and Developer, as an example. If you are interested, then lay out the rest of the developments.
the main objective
Task statement (backlog â description), read feedback
What's next
When tasks are formulated by the Owner, the SM describes them â leads to Sufficient_Description.
Feedback from
SM redescribes the task and discusses key milestones with the Owner quickly, including the deadlines.
Interacts with
CM
CM
the main objective
Accept the task, bring it into the form of Sufficient_Description, evaluate the task, distribute, read the feedback
What's next
Distributes tasks to employees
Feedback from
Designer, Developer, Tester, Tech Writer
Interacts with
Owner, Designer, Developer, Tester, Tech Writer
the main objective
Development of features and fix bugs. In the General Flow, tasks from CM come to him, and with the help of his professional activity, he implements them (git flow, rebase flow, feature flow, etc.).
What's next
He can make suggestions for modifications, discussing them with the CM and the Designer.
Feedback from
CM, Designer, Tester
Interacts with
CM, Designer, (important - it cannot generate interaction with Tester)
(I donât really like the scheme in this description, this is my presentation with a different description, and itâs more pleasant for me to work with it. But Iâm exploring options, trying, honing, and it turned out that way.)
Development Flow solves the following tasks:
The main advantages are that everyone knows what is happening, what they should do, and are not overloaded with unnecessary work.
A lot of work at the Scrum Master (Timlid, CTO). But it should be so, he is the main tractor in this approach.
very brief and dry presentation
Stay in the dark or create bold structures. We offer our bird, but it is large and this is only a part, as a first approximation. We need more cases. Because I ask you - hang all the dogs on me, I want to crack a better topic.
(Much had to be cut out to even a little shrink the size of the article. Because of this, I could have missed something, but I would promptly correct it, write.)
Efficiency and transparency are never the same thing. You can transparently do ineffective things, and effectively do things opaque.
Building a work structure is a complex, individual process, with a touch of audacity. Because we need not only courage and reflection (âwe work inefficiently, why?â), But also the ability to make graceful conglomerations.
')
Graceful piles - a pledge of the creation of structures. It seems âwe donât need it, we work and itâs okay, why do we need extra layersâ, but in fact - one thoughtful layer will take your work to a new level. It is a jumble, but it is elegant. Something like dependency injection or using Photoshop instead of painting with colors.
If now you thought âno, we are all efficientâ - do not even hope. Ineffective. Even if you absolutely, absolutely, never create any blockages in your work at all, then you just live in illusions. It's impossible. Efficiency is a fucking process, not a given. And a specific person should provide this process. And others - to support. Not because âthey said soâ, but because everyone will be fine - everyone will work the way they feel comfortable and be effective.
In short, we call our brainchild of exquisite piles of âarrogant bird structuresâ or âdevelopment flowâ. Now we describe it, and still eat a couple of your dogs in disputes.
Why is it needed
Development Flow is designed to fulfill 4 commitments:
- Structuring process
- Problem Solving
- Gives Feedback
- Provides a universal language of interaction
Development Flow is a tool that creates a system .
System
The system consists of elements, the elements are different, and the âcurrentâ flows through them - the workflow. In IT, âcurrentâ is the code, design, documents, and other things with which we work.
Systems are missing
If you do not know at what stage of your Private Flow are now (for example, âdeveloping the featuresâ), and do not know what stage you are in the General Flow (for example, the fourth, after the Product Owner, Scrum Wizard and Designer), and which the stage should follow you, what are his criteria for returning, and many other trivialities ...
Or if you know, but for your work with you, the Project Manager should sit next to you and remind you exactly at this very second you should be engaged (do not look away from the monitor, immediately follow up programs) ...
Or if you just feel that you are ineffective ...
... then most likely you do not have a System.
System fails to work properly
All is not gold that glitters. Not all the V12 that is under the hood. And most importantly - not every engine works correctly, even if it goes (hello, beloved by the auto industry).
It is important to have a properly working system, because this is our confidence. In their work, in the work of the whole system. You will immediately find problems, most of which can be solved.
Engine running has sound. He is rhythmic, pleasant. If there is a problem there, it is audible to the sensitive ear of the master. Squeak, sneezing, rhythm disturbance, knock. It slowly or quickly destroys the engine, and the âbusiness carâ breaks down precisely when you took a dollar mortgage on the top three inside the ring.
In the system of people's work, these noises - violation of deadlines, discontent, personnel leakage, reduced tone of employees, transfer of problems to the neighboring department - and much more. A good manager walks around the office with splayed supersensitive locators instead of ears. He is aware of the impending storm, he feels that the pressure has dropped. He hears all the short sighs, and notices the abstracted eyes. He is the System.
Development flow: system
The DF system includes two sections - General Flow (the functioning of the system as a whole), and Private Flow (the functioning of its individual parts).
Total flow
The system consists of elements combined into a structure to achieve the intended goal.
The goal in IT is to release a product at the right time of the right quality. The elements of the system are the participants of the process: the Product Owner, the Project Manager, the Scrum Master, the Developer, the Designer, the Tester, the Technical Writer ... All these are elements, and not all of them are ever present. Sometimes the roles are combined. It is necessary to highlight its elements.
It is necessary to highlight its elements. Write them down and draw your first flow with the arrow. This is called Total Flow.
Owner â SM â Designer, Developer â Tester â Tech Recorder
The task is to combine the elements into a structure and show what professional interactions are possible. Non-professional - that the designer and the owner of the product live together, is not necessary. You only need to role. The owner should not interact with the Designer or the Developer. Only Scrum Master. Only. Scrum master.
When we select interactions, these arrows, we must show what the First gives, and that the Second returns as feedback. So the system begins to live.
Owner â gives a description of the task â SM
SM will reformulate it both for the Owner and for the rest. Assessment of the task - approximate - will line up by itself. But the task of SM - from a simple description, applying an elegant jumble, to make a SUFFICIENT_DESCRIPTION. Parts of this TO he will discuss and distribute with the team.
SM â gives parts of DO â Designer and Developer
TO includes the scheme, all its possible states, and much more (I donât want to pile on for now). Everyone gets their part. Not always at the same time. Usually the Designer is ahead of the Developer by one sprint.
The designer and the Developer at the daily rally, in return for communicating with the SM, returns to him his vision of the task. Make sure that we understand everything the same way. It takes 25-28 seconds. And saves hours and weeks.
Developer â after his private flow (more on this later), sends the code â to Tester
The developer gives the code, the tester looks to his part of the TO, and fulfills his flow. Tester's feedback is for SM â âpositiveâ, that is, how he understands the task, and for Developer â ânegativeâ - only if it is broken.
The developer has no idea that his code is being tested, until problems arise.
I think that the general flow is correctly formulated as follows. The first gives to the Second, the Second processes, returns "positive" or "negative" Feedback, moves further into the General flow. Positive feedback - the conviction that everything works as intended; negative feedback shows where and what went wrong.
Private flow
In this article, I will sort out the private flow of the Owner, CM and Developer, as an example. If you are interested, then lay out the rest of the developments.
Owner
the main objective
Task statement (backlog â description), read feedback
What's next
When tasks are formulated by the Owner, the SM describes them â leads to Sufficient_Description.
Feedback from
SM redescribes the task and discusses key milestones with the Owner quickly, including the deadlines.
Interacts with
CM
CM
the main objective
Accept the task, bring it into the form of Sufficient_Description, evaluate the task, distribute, read the feedback
What's next
Distributes tasks to employees
Feedback from
Designer, Developer, Tester, Tech Writer
Interacts with
Owner, Designer, Developer, Tester, Tech Writer
Developer
the main objective
Development of features and fix bugs. In the General Flow, tasks from CM come to him, and with the help of his professional activity, he implements them (git flow, rebase flow, feature flow, etc.).
What's next
He can make suggestions for modifications, discussing them with the CM and the Designer.
Feedback from
CM, Designer, Tester
Interacts with
CM, Designer, (important - it cannot generate interaction with Tester)
(I donât really like the scheme in this description, this is my presentation with a different description, and itâs more pleasant for me to work with it. But Iâm exploring options, trying, honing, and it turned out that way.)
In the dry residue
Development Flow solves the following tasks:
- Structuring process
- Problem solving
- Gives feedback
- Provides a universal language that we havenât said yet
The main advantages are that everyone knows what is happening, what they should do, and are not overloaded with unnecessary work.
A lot of work at the Scrum Master (Timlid, CTO). But it should be so, he is the main tractor in this approach.
very brief and dry presentation
Stay in the dark or create bold structures. We offer our bird, but it is large and this is only a part, as a first approximation. We need more cases. Because I ask you - hang all the dogs on me, I want to crack a better topic.
(Much had to be cut out to even a little shrink the size of the article. Because of this, I could have missed something, but I would promptly correct it, write.)
Source: https://habr.com/ru/post/423797/
All Articles