True XP / TDD in Pivotal from the inside: how does it look and is it possible?
Earlier, an article was published on Habré about how Xp / Tdd in theory looks like in Pivotal Labs, and there were questions about whether / is it really necessary. I will try to explain how this looks in practice and why it may be (suddenly) good.
In the past six months, I had to work in one of the big banks on a project with Pivotal Labs, in their New York office. This is very different from all the enterprise development I’ve seen before.
The first thing that catches your eye is a pair of workplaces, identical Apple machines with a pre-installed software, two keyboards and two monitors. Everyone works in pairs, couples are rotated inside the team every day. You never know where you will sit tomorrow, with whom to work and on what story. You can be transferred from team to team at any time.
')
Working time is strictly limited, we work from nine to half past, then lunch for an hour, then continue until six. At six zero one you are free.
(Yes, it actually looks as monstrous as it seems. You can’t secretly install your favorite text editor, you can’t rock for half a day reading news or technical reviews, you can’t arrange a corner and chat with a neighbor, you can’t try cram a new framework or library. The first three months you get used to new personal boundaries, to what someone looks when you type or think, to half or more time you look how the other works, but to fall asleep or turn off completely can s because he expects that you know what's going on. If you're, then you explain each step aloud).
Therefore, all you have to do is ask him what story we have in priority today and start doing it. All requirements are written in a format when-it-should, under which it is easy to make test specifications. All the specs are written ahead of the implementation, if someone urgently wants the opposite, then the partner will correct it. In the process, usually one writes a test, a second implementation, then vice versa.
(In spirit, this is reminiscent of TV shows, where two policemen drive in a circle along the street in one car, eat hamburgers and comment on what is happening).
By the end of the day, the completed or unfinished story goes to the Wip commit and tomorrow someone else can start it. Usually, they manage to finish one story in a day and start a second one, sometimes more - the story never extends over several days and the story cannot be saved. Both are signed in a commit, but no one is punished, because the two rarely make risky changes: they will simply be rewritten tomorrow.
On jenkins, tests are always included. It’s unthinkable to put something on the maidens on maidens, the partners will not understand. Zakommitit without tests - too, no one just does not understand what it is, and most likely just rolled back. To write something incomprehensible to the specs - too. Therefore, the specs always reflect what is in the ticket tracker, and the code works as the specs are written. Just tests - it is possible, someone else will write tomorrow.
All specs are necessarily written in an abstract form and include the mock implementation to eliminate dependencies on external services. There is no such thing as “the tests broke because the data on the external service was updated”.
A specific technological stack is unimportant and varies from project to project, our current cycle looks like this:
Ui always uses consumer-driven contracts, that is, we are dancing not from what is in the database, but from what we want to see on the form.
The story, which in its usual form would look like “draw a form with ten fields, validate and send to the database”, begins to look like ten to twenty stories with a covering of five hundred thousand tests. To put a field on a form is one story. Formatting an input is another. Display data from the backend - the third. Link the backend data to the database - the fourth. If somewhere a block is due to lack of information, then the backlog state will accurately display the block, and not “we have a hundred points on the backlog, which roams from sprint to sprint”. All stories are written by users and they understand, there are no stories from the “database refactoring” series that are not accompanied by user value.
Actually, bugs are not evaluated, they do not clog up backlog, you see a bug - fix it, commit it, mark what story it refers to. So healthier.
Personally, I am pleased that such a system practically pushes any discussion about implementation to a stage when it is not interesting to anyone. If we do not know now what database we want, we will read data from a file or a mo-service. If we don’t like today's base, we’ll write a new adapter tomorrow, because we have specials.
The entire code, by definition, was reviewed. It does not happen that someone writes a tab with two spaces, and someone with four, and someone else has an eclipse and tabs. It does not happen that one uses lombok, and the second writes properties with handles.
Given that the level of programmers is not God knows what, they are often rotated and do not know very well the underlying languages and frameworks (which excludes supercompact hacks and beautiful), they all need to know test libraries well, distinguish moki, stubs and fakes, and can write intelligible specifications and, if necessary, can write a test library on their own.
Any minimal improvements are instantly distributed through the rotation of pairs, starting from a convenient hot key and ending with the parameters of the git commands or features of the framework.
Rotation strongly contributes to the preservation of social skills and allows you to quickly involve new people, in fact, in one rotation cycle, a person usually already understands what is happening. At the same time, as a rule, he does not need a vision of the project as a whole, which excludes hot wars. In addition, there is no embarrassment at the fact that “this code was written by our old friend Uncle Vasya and he will be offended if we remove it”.
In teams, peace and complacency are usually raised, because by rotating couples it is rather inconvenient to fight with each other. Therefore, everything is generally friendly.
When you see a working system, you understand how difficult it is to implement it and how much resistance from the outside. What is needed is mainly a critical mass of maniacs who are ready to work in this way and uncompromising to proposals like: “Guys, let's play one-day siku, and one day unwind the cable”, “let's get a quick production”, etc. . And you need to be ready to take it entirely. If one person from the team is late, refuses to explain solutions, or write tests, or break stories - the system loses its meaning and demotivates the others. Therefore, there must be a will and a resource for the Enforcement. The system is now rapidly developing on Wall Street, although its limits are unclear. Maybe soon it will absorb the traditional ways of development, at least in the usual banking enterprise.
In the past six months, I had to work in one of the big banks on a project with Pivotal Labs, in their New York office. This is very different from all the enterprise development I’ve seen before.
The first thing that catches your eye is a pair of workplaces, identical Apple machines with a pre-installed software, two keyboards and two monitors. Everyone works in pairs, couples are rotated inside the team every day. You never know where you will sit tomorrow, with whom to work and on what story. You can be transferred from team to team at any time.
')
Working time is strictly limited, we work from nine to half past, then lunch for an hour, then continue until six. At six zero one you are free.
(Yes, it actually looks as monstrous as it seems. You can’t secretly install your favorite text editor, you can’t rock for half a day reading news or technical reviews, you can’t arrange a corner and chat with a neighbor, you can’t try cram a new framework or library. The first three months you get used to new personal boundaries, to what someone looks when you type or think, to half or more time you look how the other works, but to fall asleep or turn off completely can s because he expects that you know what's going on. If you're, then you explain each step aloud).
Therefore, all you have to do is ask him what story we have in priority today and start doing it. All requirements are written in a format when-it-should, under which it is easy to make test specifications. All the specs are written ahead of the implementation, if someone urgently wants the opposite, then the partner will correct it. In the process, usually one writes a test, a second implementation, then vice versa.
(In spirit, this is reminiscent of TV shows, where two policemen drive in a circle along the street in one car, eat hamburgers and comment on what is happening).
By the end of the day, the completed or unfinished story goes to the Wip commit and tomorrow someone else can start it. Usually, they manage to finish one story in a day and start a second one, sometimes more - the story never extends over several days and the story cannot be saved. Both are signed in a commit, but no one is punished, because the two rarely make risky changes: they will simply be rewritten tomorrow.
On jenkins, tests are always included. It’s unthinkable to put something on the maidens on maidens, the partners will not understand. Zakommitit without tests - too, no one just does not understand what it is, and most likely just rolled back. To write something incomprehensible to the specs - too. Therefore, the specs always reflect what is in the ticket tracker, and the code works as the specs are written. Just tests - it is possible, someone else will write tomorrow.
All specs are necessarily written in an abstract form and include the mock implementation to eliminate dependencies on external services. There is no such thing as “the tests broke because the data on the external service was updated”.
A specific technological stack is unimportant and varies from project to project, our current cycle looks like this:
jira-ticket >> selenium feature spec >> enzyme\jest spec >> react\redux mock implementation >> react/redux real implementation >> spring boot backend service spec >> backend mock implementation >> spring boot backend real test with oracle \ mq \ whatever .Ui always uses consumer-driven contracts, that is, we are dancing not from what is in the database, but from what we want to see on the form.
The story, which in its usual form would look like “draw a form with ten fields, validate and send to the database”, begins to look like ten to twenty stories with a covering of five hundred thousand tests. To put a field on a form is one story. Formatting an input is another. Display data from the backend - the third. Link the backend data to the database - the fourth. If somewhere a block is due to lack of information, then the backlog state will accurately display the block, and not “we have a hundred points on the backlog, which roams from sprint to sprint”. All stories are written by users and they understand, there are no stories from the “database refactoring” series that are not accompanied by user value.
Actually, bugs are not evaluated, they do not clog up backlog, you see a bug - fix it, commit it, mark what story it refers to. So healthier.
Personally, I am pleased that such a system practically pushes any discussion about implementation to a stage when it is not interesting to anyone. If we do not know now what database we want, we will read data from a file or a mo-service. If we don’t like today's base, we’ll write a new adapter tomorrow, because we have specials.
The entire code, by definition, was reviewed. It does not happen that someone writes a tab with two spaces, and someone with four, and someone else has an eclipse and tabs. It does not happen that one uses lombok, and the second writes properties with handles.
Given that the level of programmers is not God knows what, they are often rotated and do not know very well the underlying languages and frameworks (which excludes supercompact hacks and beautiful), they all need to know test libraries well, distinguish moki, stubs and fakes, and can write intelligible specifications and, if necessary, can write a test library on their own.
Any minimal improvements are instantly distributed through the rotation of pairs, starting from a convenient hot key and ending with the parameters of the git commands or features of the framework.
Rotation strongly contributes to the preservation of social skills and allows you to quickly involve new people, in fact, in one rotation cycle, a person usually already understands what is happening. At the same time, as a rule, he does not need a vision of the project as a whole, which excludes hot wars. In addition, there is no embarrassment at the fact that “this code was written by our old friend Uncle Vasya and he will be offended if we remove it”.
In teams, peace and complacency are usually raised, because by rotating couples it is rather inconvenient to fight with each other. Therefore, everything is generally friendly.
When you see a working system, you understand how difficult it is to implement it and how much resistance from the outside. What is needed is mainly a critical mass of maniacs who are ready to work in this way and uncompromising to proposals like: “Guys, let's play one-day siku, and one day unwind the cable”, “let's get a quick production”, etc. . And you need to be ready to take it entirely. If one person from the team is late, refuses to explain solutions, or write tests, or break stories - the system loses its meaning and demotivates the others. Therefore, there must be a will and a resource for the Enforcement. The system is now rapidly developing on Wall Street, although its limits are unclear. Maybe soon it will absorb the traditional ways of development, at least in the usual banking enterprise.
Source: https://habr.com/ru/post/354118/
All Articles