June 8, 2010 at 22:14Abstract of Kent Beck's lectures
About a year ago I attended two lectures by Kent Beck: “Habits for agility” and “Four strategies for responsive design”. Today I came across a squeeze made of them then and decided to share it.
The first lecture is relevant for all people working in a team, the second relates more to programming.
Flexibility in this situation is understood not as the gymnast's flexibility, which is limited by the space of the arena 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 thought.
The following are habits whose development in themselves helps to improve teamwork.
Positive attitude. It is extremely important to think positively, if you say: “Everything is bad, a disaster, we can’t do anything” - you won’t do anything. If you really want to cry about how bad everything is, you need to go out, do it alone, come back and say: “So what will we do with this?”
It is extremely important to speak openly about achievements and especially problems.
The game of the “coward of the schedule” - everyone knows that the schedule breaks down, at the meeting with the bosses everyone is silent about the timing, and when the first one says “it seems we are not in time on the schedule” - everyone turns to him and asks “How not have time?!?! ”, although everyone knows this very well. As a result, everything falls on the one who first said, and being late on 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 it not going to? But not because of the name? And I’ll go and check it out, ”as a result of which much more time is spent than to be honest,“ I made a mistake somewhere and the project is not going to ”and hear equally honest, albeit negative, reviews.
Lies 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 makefiles that no one is at risk of doing), it is important to remember that if you don't teach anyone else, you'll be doing it for more than one year in splendid isolation.
In extreme programming, the term “done-done” is often introduced, because when they say “done” people often mean that they are personally ready, but there may be problems, but they are definitely not to blame. Finish-ready means that everything is really in order and this section of the project will not cause any problems.
It is important to act first, then reflect. If at first you are going to collect theoretical material, read books, study the experience of other people in forums, most likely you will not directly go to action. You must first try to do it. If it doesn’t work out on the first try, think and try again. Moreover, since the approach is largely iterative, it is not so important where to start, in the next attempt you will find the desired starting point. To the question “How to do this?” The correct answer is “Let's try this way, if it doesn’t work out, we’ll come up with something else.”
An equally important question is “What is so complicated about this?” You will most likely find that you simply thought up most of the difficulties for yourself, but even if the task is really difficult, a clear idea of the existing obstacles will appear.
It is important not to forget about measuring the results obtained for reflection (see below).
The only resource that is definitely available and will end just as surely.
Two weeks of work cannot be done in one week.
A good result is 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), start it for 25 minutes, these 25 minutes we work without being distracted by calls, SMS, mail, etc. For colleagues who come with questions, we silently point to the timer and continue to work. After these 25 minutes, we start the timer for 5 minutes and these 5 minutes we do small things. To begin with, such a deep dive is done once a day, then twice, etc.
The steady rhythm of work is more important than iron self-discipline.
Simple things need to 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 specialists, etc.
Communication on 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 some of his work.
The most important is communication with the customer, and the customer here means the direct user of the program, since it is he who is primarily affected by the decisions made by programmers. A dissatisfied user is much better than a satisfied one - if he was able to satisfy a dissatisfied one, he will make the program and you as a developer an advertisement that no initially satisfied user will do.
If you do not know how to communicate with users - try it, let it turn out bad at first, but if you act - it will turn out better over time. When discussing changes to the system between the programmer and the end user, there must be a minimum of intermediaries.
It is important to remember the global direction in 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 solve the general problem?”. 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 the bad options, but also to note the good ones and use them again and again.
The final design of the project! = The original design.
Responsive in this situation means changing depending on the surrounding realities.
A design is a collection of useful related elements or useful related elements.
Studying 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).
Safe steps must be taken - making one change should not lead to breakdowns in ten places.
Before you change anything, you need to isolate this piece and embed it back if everything is successful.
The development goal is a continuous stream of functionality.
Adding new functionality should be direct, not twisted.
If the solution to the problem is completely known, then 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:
It is applied if:
Then:
+: higher efficiency
-: higher risk
It is applied if:
Then:
+: Security
-: A lot of additional side work
It is applied if:
Then:
+: Obtaining components that can then be used in other projects
-: A large amount of unnecessary work
-: Lack of feedback at this stage.
It is applied if:
Then:
+: can be applied almost always
+: Develops initiative
-: Non-linear cost depending on the procedure for restoring requirements.
If you can’t add functionality directly:
In any case, the global design change is paid by customers, it is most advantageous to stretch it for a while, so as 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
Flexibility in this situation is understood not as the gymnast's flexibility, which is limited by the space of the arena 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 thought.
The following are habits whose development in themselves helps to improve teamwork.
An approach
Positive attitude. It is extremely important to think positively, if you say: “Everything is bad, a disaster, we can’t do anything” - you won’t do anything. If you really want to cry about how bad everything is, you need to go out, do it alone, come back and say: “So what will we do with this?”
Transparency
It is extremely important to speak openly about achievements and especially problems.
The game of the “coward of the schedule” - everyone knows that the schedule breaks down, at the meeting with the bosses everyone is silent about the timing, and when the first one says “it seems we are not in time on the schedule” - everyone turns to him and asks “How not have time?!?! ”, although everyone knows this very well. As a result, everything falls on the one who first said, and being late on 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 it not going to? But not because of the name? And I’ll go and check it out, ”as a result of which much more time is spent than to be honest,“ I made a mistake somewhere and the project is not going to ”and hear equally honest, albeit negative, reviews.
Lies can work well for short periods of time (for example, in sales), but for the long term, the truth is always better.
Responsibility
When doing work that quickly brings respect (for example, when structuring makefiles that no one is at risk of doing), it is important to remember that if you don't teach anyone else, you'll be doing it for more than one year in splendid isolation.
In extreme programming, the term “done-done” is often introduced, because when they say “done” people often mean that they are personally ready, but there may be problems, but they are definitely not to blame. Finish-ready means that everything is really in order and this section of the project will not cause any problems.
Act
It is important to act first, then reflect. If at first you are going to collect theoretical material, read books, study the experience of other people in forums, most likely you will not directly go to action. You must first try to do it. If it doesn’t work out on the first try, think and try again. Moreover, since the approach is largely iterative, it is not so important where to start, in the next attempt you will find the desired starting point. To the question “How to do this?” The correct answer is “Let's try this way, if it doesn’t work out, we’ll come up with something else.”
An equally important question is “What is so complicated about this?” You will most likely find that you simply thought up most of the difficulties for yourself, but even if the task is really difficult, a clear idea of the existing obstacles will appear.
It is important not to forget about measuring the results obtained for reflection (see below).
Time
The only resource that is definitely available and will end just as surely.
Two weeks of work cannot be done in one week.
A good result is 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), start it for 25 minutes, these 25 minutes we work without being distracted by calls, SMS, mail, etc. For colleagues who come with questions, we silently point to the timer and continue to work. After these 25 minutes, we start the timer for 5 minutes and these 5 minutes we do small things. To begin with, such a deep dive is done once a day, then twice, etc.
The steady rhythm of work is more important than iron self-discipline.
Simple things need to 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.
Communications
Each team member has his own connections, which are important to use - connections with specialists, etc.
Communication on 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 some of his work.
The most important is communication with the customer, and the customer here means the direct user of the program, since it is he who is primarily affected by the decisions made by programmers. A dissatisfied user is much better than a satisfied one - if he was able to satisfy a dissatisfied one, he will make the program and you as a developer an advertisement that no initially satisfied user will do.
If you do not know how to communicate with users - try it, let it turn out bad at first, but if you act - it will turn out better over time. When discussing changes to the system between the programmer and the end user, there must be a minimum of intermediaries.
Perspective
It is important to remember the global direction in 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 solve the general problem?”. 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 the bad options, but also to note the good ones and use them again and again.
Four Responsive Design Strategies
The final design of the project! = The original design.
Responsive in this situation means changing depending on the surrounding realities.
Initial premises
A design is a collection of useful related elements or useful related elements.
Studying 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).
Safe steps must be taken - making one change should not lead to breakdowns in ten places.
Before you change anything, you need to isolate this piece and embed it back if everything is successful.
The development goal is a continuous stream of functionality.
Adding new functionality should be direct, not twisted.
If the solution to the problem is completely known, then 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 as 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
It is applied if:
- We know how to do it
- We are confident that we can safely make and embed this option
Then:
- -We perform several actions in one step.
+: higher efficiency
-: higher risk
Parallelism
It is applied if:
- We know how to do it
- Not sure we can safely build and build
Then:
- We temporarily support both design options, gradually transferring functionality from the old to the new
+: Security
-: A lot of additional side work
Reference stone
It is applied if:
- We don’t 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 with which it will be easier to achieve the goal
+: Obtaining components that can then be used in other projects
-: A large amount of unnecessary work
-: Lack of feedback at this stage.
Simplification
It is applied if:
- We don’t know how to do it.
- No resources to complete the entire task
Then:
- Throw out the requirements until the task is solved in one safe step
- Gradually restore project requirements.
+: can be applied almost always
+: Develops initiative
-: Non-linear cost depending on the procedure for restoring requirements.
Additional remark
If you can’t add functionality directly:
- Do it how it goes
- Be prepared to pay the price of this decision later
In any case, the global design change is paid by customers, it is most advantageous to stretch it for a while, so as not to slow down the addition of new functionality and not to make each addition insanely expensive.