Bold bird structures: development flow
If you cannot describe on your fingers the structure of your organization, department, or work in general, then 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 heaps - a pledge of the creation of structures. It seems “we don’t need, we work and all right, 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 offspring of graceful heaps the “impudent bird of 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, “talk” 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 features”), and you do not know what stage you are in the General flow (for example, the fourth, after the Product Owner, Scrum Wizard and Designer) and what stage should go after you, what are his criteria for returning, and many other small things ...
Or if you know, but for your work with you, the Project Manager should sit next to you and remind you of exactly this very second (do not look away from the monitor, immediately follow no programs) ...
Or if you just feel that you are ineffective ...
... then most likely you do not have a System.
The system is not working properly
Not all gold that glitters. Not all the V12 that is under the hood. And most importantly - not every engine works correctly, even if it is traveling (hello, beloved by the auto industry).
It is important to have a properly working system, because it is our confidence. In their work, in the work of the whole system. You will immediately find problems, most of which can be solved.
A running engine 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, dissatisfaction, personnel leakage, reduced tone of employees, transfer of problems to the next 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.
The owner → gives a description of the problem → The SM
SM will reformulate it for both the Owner and the rest. Assessment of the task - approximate - will line up by itself. But the task of the SM - from a simple description, applying an elegant jumble, to make a SUFFICIENT_WRITING. Parts of this TO he will discuss and distribute with the team.
SM → gives parts of TO → Designer and Developer
TO includes a scheme, all its possible states, and much more (I don’t want to load up yet). 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 him his vision of the task. Make sure that we understand everything the same way. It takes 25-28 seconds. And it saves hours and weeks.
Developer → after his private flow (more on this later), sends the code → to the Tester
The developer gives the code, the Tester looks to his part before, and works out his flow. Tester's feedback is for SM → “positive”, that is, how it understands the task, and for the 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 of the
task formulation (backlog ← description), to read the feedback.
What's next
When the tasks are formulated by the Owner, the CM describes them → leads to Sufficient_Description.
Feedback from the
SM redescribes the task and discusses key milestones with the Owner quickly, in time.
Interacts with the
CM
CM
The main purpose of
take problem, bring it into view Dostatochnogo_Opisaniya, to evaluate tasks, distribute, read feedback
What's next
allocate tasks to employees
Feedback from the
designers, developers, testers, Tehpisatel
interacts with the
Owner, designer, developer, tester, Tehpisatel
The main goal
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)
(In this description, I don’t really like the scheme, 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.
(I had to cut a lot to shrink the size of the article at least a little. I could have missed something because of this, 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 heaps - a pledge of the creation of structures. It seems “we don’t need, we work and all right, 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 offspring of graceful heaps the “impudent bird of 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, “talk” 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 features”), and you do not know what stage you are in the General flow (for example, the fourth, after the Product Owner, Scrum Wizard and Designer) and what stage should go after you, what are his criteria for returning, and many other small things ...
Or if you know, but for your work with you, the Project Manager should sit next to you and remind you of exactly this very second (do not look away from the monitor, immediately follow no programs) ...
Or if you just feel that you are ineffective ...
... then most likely you do not have a System.
The system is not working properly
Not all gold that glitters. Not all the V12 that is under the hood. And most importantly - not every engine works correctly, even if it is traveling (hello, beloved by the auto industry).
It is important to have a properly working system, because it is our confidence. In their work, in the work of the whole system. You will immediately find problems, most of which can be solved.
A running engine 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, dissatisfaction, personnel leakage, reduced tone of employees, transfer of problems to the next 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.
The owner → gives a description of the problem → The SM
SM will reformulate it for both the Owner and the rest. Assessment of the task - approximate - will line up by itself. But the task of the SM - from a simple description, applying an elegant jumble, to make a SUFFICIENT_WRITING. Parts of this TO he will discuss and distribute with the team.
SM → gives parts of TO → Designer and Developer
TO includes a scheme, all its possible states, and much more (I don’t want to load up yet). 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 him his vision of the task. Make sure that we understand everything the same way. It takes 25-28 seconds. And it saves hours and weeks.
Developer → after his private flow (more on this later), sends the code → to the Tester
The developer gives the code, the Tester looks to his part before, and works out his flow. Tester's feedback is for SM → “positive”, that is, how it understands the task, and for the 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 of the
task formulation (backlog ← description), to read the feedback.
What's next
When the tasks are formulated by the Owner, the CM describes them → leads to Sufficient_Description.
Feedback from the
SM redescribes the task and discusses key milestones with the Owner quickly, in time.
Interacts with the
CM
CM
The main purpose of
take problem, bring it into view Dostatochnogo_Opisaniya, to evaluate tasks, distribute, read feedback
What's next
allocate tasks to employees
Feedback from the
designers, developers, testers, Tehpisatel
interacts with the
Owner, designer, developer, tester, Tehpisatel
Developer
The main goal
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)
(In this description, I don’t really like the scheme, 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.)
The bottom line
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.
(I had to cut a lot to shrink the size of the article at least a little. I could have missed something because of this, but I would promptly correct it, write.)
Only registered users can participate in the survey. Sign in , please.