Lecture of Kent Beck
About a year ago, he attended two lectures by Kent Beck: “The habit of flexibility” (Habits for agility) and “Four strategies for responsive design” (Four strategies for responsive design). Today I stumbled upon the squeeze made from them and decided to share it.
The first lecture is relevant for all people working in a team, the second relates more to programming.
Under this situation, flexibility is not the gymnast's flexibility, which is limited by the arena space and is not related to moving forward, but the ability to change the direction of movement when an obstacle appears.
Habit is what we come to in stressful situations, action without thinking.
')
The following are habits, the development of which in itself contributes to the improvement of teamwork.
Positive attitude. It is extremely important to think positively if you say: “Everything is bad, a catastrophe, we can’t do anything” - you can’t do anything. If you really want to cry about how bad everything is - you have to go out, do it alone, go back and say: “So what are we going to do about it?”.
It is extremely important to speak openly about achievements and especially about problems.
The game of the “coward of the schedule” - everyone knows that the schedule breaks down, when meeting with the authorities, everyone is silent when asked about the deadlines, and when someone first says “it seems we don’t have time for the schedule”, everyone turns to him and asks: have time?!?! ”, although everyone knows about it perfectly. As a result, everything falls on the one who first said, and the delay in the schedule is growing like an avalanche.
Transparency saves time - when you say “We are not going to have a project,” everyone starts to think, “And because of whom is he not going? And not because of the name? And I will go check it out, as a result of which much more time is spent than to honestly say, “I made a mistake somewhere and the project is not going to” and hear equally honest, even if negative reviews.
A lie can work well for short periods of time (for example, in sales), but for the long term, the truth is always better.
When doing work that quickly brings respect (for example, when structuring make-files that no one risks doing), it is important to remember that if you don’t train someone else, you will be doing this for more than one year in proud solitude.
In extreme programming, the term “done-done” is often introduced, since saying “done” (done) people often mean that they personally are done, but there may be problems, but they are definitely not to blame. Ready-ready means that everything is really in order and this part of the project will not cause any problems.
It is important to act first, then to reflect. If at first you will be collecting theoretical material, reading books, studying the experience of other people on the forums, you will most likely not be taken directly to action. We must first try to do. If you fail the first attempt - think and try again. Moreover, since the approach is largely iterative - it’s not so important where to start, in the next attempt you will find the right starting point. To the question “How to do it?” The correct answer is “Let's try this way, if it doesn't work out, let's think of something else.”
Just as important is “What is so complicated about it?”. Most likely, you will find that you simply made up most of the difficulties for yourself, but even if the task is really difficult, a clear idea of the existing obstacles will appear.
At the same time, it is important not to forget about the measurement of the results obtained for reflection (see below).
The only resource that is exactly available and will end just as accurately.
Work two weeks can not be done in one week.
A good result gives a short focus on different tasks, cutting time into small areas.
Tomato principle:
We buy a kitchen timer (preferably in the form of a tomato), we start for 25 minutes, these 25 minutes we work without being distracted by calls, sms, mail, etc. Colleagues coming with questions silently point to the timer and continue to work. After these 25 minutes, we start the timer for 5 minutes and these 5 minutes are engaged in minor matters. To begin with, such a deep immersion is done once a day, then twice, and so on.
The established rhythm of work is more important than iron self-discipline.
Simple things should be automated. In 90% of installers, you need to click next many times, while there is almost no need to change the parameters - poor automation.
Each team member has his own connections, which are important to use - connections with experts, etc.
Communication skills between team members - everyone knows at least a little in all areas, so if for example a css specialist is on vacation, the rest can at least do his part.
The most important is communication with the customer, and the customer here means the direct user of the program, since it is him who is primarily affected by the decisions made by programmers. A dissatisfied user is much better than a satisfied one - if he could satisfy a dissatisfied one, he will make the program and you as a developer such an advertisement, which no initially satisfied user will do.
If you do not know how to communicate with users - try, even if it comes out poorly at first, but if you act, it will get better in time. When discussing changes made to the system between the programmer and the end user, there should be a minimum of intermediaries.
It is important to remember the global direction when solving local problems. If an idea came to mind - crystallize it into a few simple clear phrases and ask yourself the question “Will this help to solve a common task?”. It is also important that the team has an open set of working principles.
The key question in this case is “How did it go?”, While it is important not only to discard bad options, but also to mark good ones and use them again and again.
Final design of the project! = Initial design.
Responsive in this situation means changing depending on the surrounding realities.
A design is a collection of useful related items or useful related items.
The study of design is introspective, empirical and quantitative.
The software design is fractal (the design of the connection of two objects is not much different from the design of the connection of two systems).
It is necessary to move in safe steps - making one change should not lead to breakdowns in ten places.
Before you change anything you need to isolate this piece and re-embed it, if everything is successful.
The goal of development is a continuous stream of functionality.
Adding new functionality should be straightforward, not twisted.
If the solution to the problem is completely known, then the responsiveness of the design is not so necessary. It is required in the following cases:
Making safe steps, you need to balance the following parameters:
Used if:
Then:
+: higher efficiency
-: higher risk
Used if:
Then:
+: Security
-: A lot of extra side work
Used if:
Then:
+: Getting components that can then be used in other projects
-: A lot of extra work
-: No feedback at this stage.
Used if:
Then:
+: almost always possible
+: Develops initiative
-: Non-linear cost depending on the order of restoration of claims.
If you can’t add functionality directly:
In any case, the global change of design is paid by customers, it is most beneficial to stretch it for some time in order not to slow down the addition of new functionality and not to make each addition insanely expensive.
The first lecture is relevant for all people working in a team, the second relates more to programming.
Habit of flexibility
Under this situation, flexibility is not the gymnast's flexibility, which is limited by the arena space and is not related to moving forward, but the ability to change the direction of movement when an obstacle appears.
Habit is what we come to in stressful situations, action without thinking.
')
The following are habits, the development of which in itself contributes to the improvement of teamwork.
An approach
Positive attitude. It is extremely important to think positively if you say: “Everything is bad, a catastrophe, we can’t do anything” - you can’t do anything. If you really want to cry about how bad everything is - you have to go out, do it alone, go back and say: “So what are we going to do about it?”.
Transparency
It is extremely important to speak openly about achievements and especially about problems.
The game of the “coward of the schedule” - everyone knows that the schedule breaks down, when meeting with the authorities, everyone is silent when asked about the deadlines, and when someone first says “it seems we don’t have time for the schedule”, everyone turns to him and asks: have time?!?! ”, although everyone knows about it perfectly. As a result, everything falls on the one who first said, and the delay in the schedule is growing like an avalanche.
Transparency saves time - when you say “We are not going to have a project,” everyone starts to think, “And because of whom is he not going? And not because of the name? And I will go check it out, as a result of which much more time is spent than to honestly say, “I made a mistake somewhere and the project is not going to” and hear equally honest, even if negative reviews.
A lie can work well for short periods of time (for example, in sales), but for the long term, the truth is always better.
A responsibility
When doing work that quickly brings respect (for example, when structuring make-files that no one risks doing), it is important to remember that if you don’t train someone else, you will be doing this for more than one year in proud solitude.
In extreme programming, the term “done-done” is often introduced, since saying “done” (done) people often mean that they personally are done, but there may be problems, but they are definitely not to blame. Ready-ready means that everything is really in order and this part of the project will not cause any problems.
Act
It is important to act first, then to reflect. If at first you will be collecting theoretical material, reading books, studying the experience of other people on the forums, you will most likely not be taken directly to action. We must first try to do. If you fail the first attempt - think and try again. Moreover, since the approach is largely iterative - it’s not so important where to start, in the next attempt you will find the right starting point. To the question “How to do it?” The correct answer is “Let's try this way, if it doesn't work out, let's think of something else.”
Just as important is “What is so complicated about it?”. Most likely, you will find that you simply made up most of the difficulties for yourself, but even if the task is really difficult, a clear idea of the existing obstacles will appear.
At the same time, it is important not to forget about the measurement of the results obtained for reflection (see below).
Time
The only resource that is exactly available and will end just as accurately.
Work two weeks can not be done in one week.
A good result gives a short focus on different tasks, cutting time into small areas.
Tomato principle:
We buy a kitchen timer (preferably in the form of a tomato), we start for 25 minutes, these 25 minutes we work without being distracted by calls, sms, mail, etc. Colleagues coming with questions silently point to the timer and continue to work. After these 25 minutes, we start the timer for 5 minutes and these 5 minutes are engaged in minor matters. To begin with, such a deep immersion is done once a day, then twice, and so on.
The established rhythm of work is more important than iron self-discipline.
Simple things should be automated. In 90% of installers, you need to click next many times, while there is almost no need to change the parameters - poor automation.
Connections
Each team member has his own connections, which are important to use - connections with experts, etc.
Communication skills between team members - everyone knows at least a little in all areas, so if for example a css specialist is on vacation, the rest can at least do his part.
The most important is communication with the customer, and the customer here means the direct user of the program, since it is him who is primarily affected by the decisions made by programmers. A dissatisfied user is much better than a satisfied one - if he could satisfy a dissatisfied one, he will make the program and you as a developer such an advertisement, which no initially satisfied user will do.
If you do not know how to communicate with users - try, even if it comes out poorly at first, but if you act, it will get better in time. When discussing changes made to the system between the programmer and the end user, there should be a minimum of intermediaries.
Perspective
It is important to remember the global direction when solving local problems. If an idea came to mind - crystallize it into a few simple clear phrases and ask yourself the question “Will this help to solve a common task?”. It is also important that the team has an open set of working principles.
Reflection
The key question in this case is “How did it go?”, While it is important not only to discard bad options, but also to mark good ones and use them again and again.
Four responsive design strategies
Final design of the project! = Initial design.
Responsive in this situation means changing depending on the surrounding realities.
Background
A design is a collection of useful related items or useful related items.
The study of design is introspective, empirical and quantitative.
The software design is fractal (the design of the connection of two objects is not much different from the design of the connection of two systems).
It is necessary to move in safe steps - making one change should not lead to breakdowns in ten places.
Before you change anything you need to isolate this piece and re-embed it, if everything is successful.
The goal of development is a continuous stream of functionality.
Adding new functionality should be straightforward, not twisted.
If the solution to the problem is completely known, then the responsiveness of the design is not so necessary. It is required in the following cases:
- It is not known how to do something;
- Known as, but not enough resources;
- It is known that there are resources, but the rest of the team does not understand this option.
Making safe steps, you need to balance the following parameters:
- Efficiency;
- Risk;
- Reviews;
- Teamwork.
Strategies
Bounce
Used if:
- We know how to do it.
- Sure that we can safely make and embed this option
Then:
- -We perform several actions in one step.
+: higher efficiency
-: higher risk
Parallelism
Used if:
- We know how to do it.
- Not sure if we can safely make and embed
Then:
- Temporarily support both versions of the design, gradually transferring the functionality from the old to the new
+: Security
-: A lot of extra side work
Support stone
Used if:
- We do not know how to do it.
- We know what can be done to simplify the solution of the problem.
Then:
- We are building an additional project that will make it easier to achieve the goal.
+: Getting components that can then be used in other projects
-: A lot of extra work
-: No feedback at this stage.
Simplify
Used if:
- We do not know how to do it.
- No resources to complete the task.
Then:
- We throw away the requirements until the problem is solved in one safe step.
- Gradually restore the requirements for the project.
+: almost always possible
+: Develops initiative
-: Non-linear cost depending on the order of restoration of claims.
Additional note
If you can’t add functionality directly:
- Do as you please
- Get ready to pay the price of this decision later.
In any case, the global change of design is paid by customers, it is most beneficial to stretch it for some time in order not to slow down the addition of new functionality and not to make each addition insanely expensive.
Source: https://habr.com/ru/post/95906/
All Articles