Setting tasks for beginners timlidov
When people talk about setting tasks, they love to remember about SMART.
Well, they say, the goal should be Specific, Measurable, Attainable, Relevant, Time-bound.
And there are even amazing people who are trying to push it to programmers.
But there are tasks, but there are tasks. And between them a big difference!
Developer - being streaming, driving. Unlike project managers, timlids and other great people who inevitably have to switch focus every 10 minutes. And it's great if the processes allow the developer to be in this thread and create code without distraction to the coordination points and communication errors. For this there is a model TOTE. And there is an opinion that it is from her that you need to make a start when formulating a task to the developer. I will explain first what the model is, and then how to apply it.
T1 - Test - the desired state to which we aspire, what is it?
O - Operation - what actions should we do to achieve the result?
T2 - Test2 - by what signs will we understand that we have moved towards the result?
E - Exit - by what criteria will we understand that the result is finally achieved?
')
This model is very algorithmic and well suited for tasks up to 20 hours (I hope you don’t need to explain why line developers don’t need to set tasks for more than 4..8 hours? :)).
I will give an example of how it falls on the formulation of tasks in planned development. Of course, the above recipe is not suitable in the case of work in the style of Research and Development, the organization of work on the operation or work on the urgent plugging of holes.
First ( T1 ) there is a brief description of what we are doing (do not confuse it with the title of the task!). One sentence summarizing what we do and why.
Generally speaking, there is no point in taking on a task if you cannot formulate it. It might look like this: “Make a standard REST API user profile so that the application frontend works with it”, “We teach the method of creating armor to accept the gender parameter and save it”, “You need to write migrations that will arrange the keys according to the schemes from merge request (uml table charts) ".
As Operation and a little bit of T2 , the chapter “what actions should be done to achieve the result” is in favor.
This is a numbered list of those specific actions that a linear developer needs to do. Perhaps with an estimate of time. For example:
It is important that it is numbered and you understand how much time each step should take to complete. This is especially important - if you work with juniors and middles. For as soon as your developer “digs in”, this list is a good way to quickly understand where he is stalled and what further steps he should have.
Well, in the end, the chapter “Expected result” acts as Exit rules and a little bit T2 . “Expected result” is an unnumbered checklist of the task check. In fact, we formulate scenarios for testing the task in the QA language. That is, they should ideally contain both positive and negative scenarios and should not contain references to the code in the “written such and such class” style. Only functional checks.
For example:
By the way, a high percentage of bugs in the tasks done is just an excuse to pay more attention to the “expected result” when formulating what you want from the developers.
Of course, in practice it may not be cost-effective to prescribe all tasks in this way. We need to find a balance, and this also wants to say a little.
Task setting through TOTE is useful as a temporary measure when connecting newbies, juniors and middles until they get comfortable with the new system and approaches adopted in the team.
You can safely simplify the formulation of tasks for qualified, proactive and advanced employees. You can safely cut the wording, if you have one person takes one block of work and solves it without a break, without holidays and illnesses with a guaranteed result. If you have to “play checkers” with people, transfer them from task to task and shuffle them between teams, if blocks of jobs are “put on hold” - TOTE is necessary.
You may have mistakes in how large blocks of work are cut into tasks. There may be an error with the goal-setting of the work unit as a whole, with the requirements for the work units, with the processes in the company and trite, with competencies. TOTE approach does not solve these problems. And that's another story.
Well, they say, the goal should be Specific, Measurable, Attainable, Relevant, Time-bound.
And there are even amazing people who are trying to push it to programmers.
But there are tasks, but there are tasks. And between them a big difference!
Developer - being streaming, driving. Unlike project managers, timlids and other great people who inevitably have to switch focus every 10 minutes. And it's great if the processes allow the developer to be in this thread and create code without distraction to the coordination points and communication errors. For this there is a model TOTE. And there is an opinion that it is from her that you need to make a start when formulating a task to the developer. I will explain first what the model is, and then how to apply it.
TOTE
T1 - Test - the desired state to which we aspire, what is it?
O - Operation - what actions should we do to achieve the result?
T2 - Test2 - by what signs will we understand that we have moved towards the result?
E - Exit - by what criteria will we understand that the result is finally achieved?
')
This model is very algorithmic and well suited for tasks up to 20 hours (I hope you don’t need to explain why line developers don’t need to set tasks for more than 4..8 hours? :)).
I will give an example of how it falls on the formulation of tasks in planned development. Of course, the above recipe is not suitable in the case of work in the style of Research and Development, the organization of work on the operation or work on the urgent plugging of holes.
First ( T1 ) there is a brief description of what we are doing (do not confuse it with the title of the task!). One sentence summarizing what we do and why.
Generally speaking, there is no point in taking on a task if you cannot formulate it. It might look like this: “Make a standard REST API user profile so that the application frontend works with it”, “We teach the method of creating armor to accept the gender parameter and save it”, “You need to write migrations that will arrange the keys according to the schemes from merge request (uml table charts) ".
As Operation and a little bit of T2 , the chapter “what actions should be done to achieve the result” is in favor.
This is a numbered list of those specific actions that a linear developer needs to do. Perhaps with an estimate of time. For example:
1. Create a migration (30 minutes)
2. Register model with validation (2 hours)
3. Register the controller (2 hours)
It is important that it is numbered and you understand how much time each step should take to complete. This is especially important - if you work with juniors and middles. For as soon as your developer “digs in”, this list is a good way to quickly understand where he is stalled and what further steps he should have.
Well, in the end, the chapter “Expected result” acts as Exit rules and a little bit T2 . “Expected result” is an unnumbered checklist of the task check. In fact, we formulate scenarios for testing the task in the QA language. That is, they should ideally contain both positive and negative scenarios and should not contain references to the code in the “written such and such class” style. Only functional checks.
For example:
- When creating a user through the API, it appears in the database
- API responses when creating a user correspond to the documentation
- User can be created only by administrator
- Non-administrator gets 403 error when trying to create a user
By the way, a high percentage of bugs in the tasks done is just an excuse to pay more attention to the “expected result” when formulating what you want from the developers.
Are there too many beeches?
Of course, in practice it may not be cost-effective to prescribe all tasks in this way. We need to find a balance, and this also wants to say a little.
Task setting through TOTE is useful as a temporary measure when connecting newbies, juniors and middles until they get comfortable with the new system and approaches adopted in the team.
You can safely simplify the formulation of tasks for qualified, proactive and advanced employees. You can safely cut the wording, if you have one person takes one block of work and solves it without a break, without holidays and illnesses with a guaranteed result. If you have to “play checkers” with people, transfer them from task to task and shuffle them between teams, if blocks of jobs are “put on hold” - TOTE is necessary.
What else to pay attention
You may have mistakes in how large blocks of work are cut into tasks. There may be an error with the goal-setting of the work unit as a whole, with the requirements for the work units, with the processes in the company and trite, with competencies. TOTE approach does not solve these problems. And that's another story.
Source: https://habr.com/ru/post/339556/
All Articles