How not to drain 10 million budget of your customer, playing with Agile
In this post I will talk about the problems that our Scrum Front End team faced during the year when working on a decent project. We started to develop a project from scratch using the React + Typescript technology stack. Looking back, I see many millions being wasted simply because the development process wasn’t right from the start. But there are reasons for this.
First you had to win the tender. To do this, it was necessary to quickly wash down the Minimal Valuable Product. And here lies the first error costing a decent amount for our customer. It sounds like this: quick gash MVP. The customer wants to see the result quickly, but this means that we are sacrificing good infrastructure, reliable architecture, and a year later we came to the conclusion that our Front End architecture requires serious refactoring. Order of several months. So we leaked 500,000 rubles.
Looking back, I can say with confidence that the first step was to take into account all the functionality that the customer wanted to see in the end in a few years. So we could avoid architectural errors in the style of "this architecture does not provide for this." As a result, each large chip required serious refactoring.
In order to win the tender, our company sent developers who did not have experience in designing large applications and reliable extensible systems. Understandably, the tender is not an order, and nobody wants to be scattered with good personnel. But the absence of a technical architect at the (class level) led to the fact that our application turned into a spaghetti code and stopped meeting the requirements of SOLID. And here lies the mistake of every customer. It is impossible to maintain a constant development pace without increasing team resources. Agile principle “Investors, developers and users should be able to maintain a constant rhythm indefinitely” only works if the requirements were known and worked out from the very beginning, the whole set of functionality, a reliable and extensible architecture was designed (in a word, if each class was thought out taking into account the final system functionality) and clearly defined processes. And this had to be done in MPV before cutting the product. Otherwise, over linear time, the complexity of the application grows exponentially. This means gash feature in a year will cost O (e (N)) more expensive than at the beginning.
')
In our team, the only designer was a remote employee. It was a serious mistake. A remote employee always lives his life. He draws himself a design, nice and fine, the customer is happy. But all these charms ultimately boil down to the fact that we have N different styles and layouts for the same logical forms. From the very beginning, it was worthwhile to put a demand: stylize a specific framework (we had Ant Design). If there is something not there, do what is there. The customer thought that React is a cubes designer. And he still doesn’t understand why we are sawing primitive forms for 4 days. React is a constructor, but only if we have a set of similar reusable components at the very beginning of development (UI framework). A designer without layout experience will never do this himself. The developer will never tell the customer about it. The leader must follow this. So the Front End team leader should be the Front End developer in the past, not the Back End as it always happens. Consequently, we come to the fact that the full-featured Agile team must contain a competent leader in each of its areas of work (FE, BE). These leaders must have strong Soft skills to convey to the customer what I am trying to describe in this article. And this is very, very not easy.
When we came out in the first release, we realized that we constantly had something breaking on the very last day before the demo. Throughout the year of development, each release branch turns into a hell of crutches (turn it off, put it away), which then magically turn out to develop the thread. And there is a series of commits (turn it on, turn it on). A year later, we came to the conclusion that we need to have a clear branch policy. But most importantly, a responsible person who would eliminate the existing chaos. This meant: either to moderate the chaotic desires of the customer, or to moderate the chaotic bugs, or at each stand to have its own configuration, disabling some kind of graphic features or buttons. Wrapping every button in the if statement is crazy. We came to the conclusion that we need a fiche-modular Front End architecture based on plug-ins (disable - enable). I have long thought how to achieve such an architecture. But one thing I understood for sure. We needed a full context. This is how the js-beans library was born (https://www.npmjs.com/package/js-beans). Each booth had its own json context. The plugins were chained (chased) through the Proxy pattern. For example, we had a data source as a separate bin, and various transformations were done as optional Proxy beans replacing this bin, but injecting it into itself. For example, if you need to scale the data model to test FPS performance, I simply add a line to enable the scaling plugin in the json file. Something broke on the production, but locally not played, I turn on the logger with one line without rebuilding the stand (the stand is about 20 minutes, and a dozen of the stands are not always enough for everyone). Or if you need to quickly turn off a module due to the fact that it can be broken (disable the optional bin in context).
As time went on, we turned off the stands for a week. It was impossible to locally develop the front. We have not provided autonomous architecture for mocks. I had to pain through it with a creak. Now, looking back, I would do it at the very beginning. But we had MVP, and we were forced to write code without deep design. But the customer considered us professionals, and thought that we should immediately write the code without errors. Here is the next error. The name of the company does not speak about the professionalism of the team. The professionalism of the team is determined by the professionalism of the team leader. If there is no technical leader in the team, after a year your project will come to a standstill. So you will merge a couple more millions.
We had a remote architect. But only one thing was known about him: he is. The last stage of development of the leader in the opinion of Vladimir Tarasov. In this, our architect has reached perfection. Error number N: you do not have a technical architect who designs the system at the grade level. You do not have a person who can ask for help if you come to a dead end. Ask for help to other more experienced teams - the customer told us. But for some reason in other teams never had time to help us. Our PR is hanging for the second month. I sincerely hope that there will be a brave man who appruvnet him. As a result, life rewarded our code with a rich abundance of paranormal phenomena in the form of magic and sets of crutches for all occasions. Only one was missing. Magic and @Kostyle special annotations. Good idea for the next ES.
We decided that more midles and less signers are more profitable for the project. Now we think differently. If you have a small budget, you need to hire the most expensive professionals. If you, like us, have no problems with the budget, you can safely save on specialists and turn the Code Review into a battle of psychics.
We thought we would meet quarterly deadlines. Now we think differently. In short, for good we need to rewrite the project. And preferably from scratch. I hope our customer will never know about it. After all, we just recently had a great team building)
We decided to play with new technologies, in which we had little expertise. They were recommended to us. Of course we wanted to gain experience. Now I think that it would be better to use only those technologies in which I have experience.
We gave estimates based on the 8 hour day. In reality, estimates should be given on the basis of a 4-hour working day. Why no one includes tea, the story of interesting stories, search for a toilet on the navigator, talking on the phone, correspondence, the study of new technologies and most importantly, enthusiastic disputes within the team. The latter is probably the most inevitable, and the most expensive. Although, to be honest, for Open Space you need to throw a couple of hours. Constant conversations terribly reduce concentration. Blessed is the customer who understands all this!
Our assessments were exhausting and turned into tedious technical controversy anyway. The effectiveness of the rallies was minimal. But we found a solution: delicious pizza. When the appetizing smell irritates the nose, the person begins to express his thoughts more clearly.
In the beginning we had one small team, then one big team. Planing took 2-3 hours. Stand up 30 minutes. What I respect our PO for is that he decided to divide it into many smaller ones and to highlight his own mini PO in each of them. Probably, this was the best decision in the entire history of our project.
From the very beginning we didn’t have time to write tests. After half a year we came to the conclusion that they still needed to be written. But we still don’t find time for this. Too much higher priority technical debt has accumulated. Not to save technical debt is a utopia. He will always be.
My personal subjective conclusions:
You are unlikely to avoid all these problems even after reading this article. My goal is to show you that it is inevitable. And no matter how hard you try, you will never have perfect conditions. So just be ready for this. And before leaving, you can safely show this article to your customer. Let him be morally ready for this.
PS: Maxim, if you ever read this article, know that everything I described is completely fictional and has no resemblance to our project) But all this is not important, because today I am going on vacation. The first vacation for the year of painstaking unsized work! (as FE lead).
First you had to win the tender. To do this, it was necessary to quickly wash down the Minimal Valuable Product. And here lies the first error costing a decent amount for our customer. It sounds like this: quick gash MVP. The customer wants to see the result quickly, but this means that we are sacrificing good infrastructure, reliable architecture, and a year later we came to the conclusion that our Front End architecture requires serious refactoring. Order of several months. So we leaked 500,000 rubles.
Looking back, I can say with confidence that the first step was to take into account all the functionality that the customer wanted to see in the end in a few years. So we could avoid architectural errors in the style of "this architecture does not provide for this." As a result, each large chip required serious refactoring.
In order to win the tender, our company sent developers who did not have experience in designing large applications and reliable extensible systems. Understandably, the tender is not an order, and nobody wants to be scattered with good personnel. But the absence of a technical architect at the (class level) led to the fact that our application turned into a spaghetti code and stopped meeting the requirements of SOLID. And here lies the mistake of every customer. It is impossible to maintain a constant development pace without increasing team resources. Agile principle “Investors, developers and users should be able to maintain a constant rhythm indefinitely” only works if the requirements were known and worked out from the very beginning, the whole set of functionality, a reliable and extensible architecture was designed (in a word, if each class was thought out taking into account the final system functionality) and clearly defined processes. And this had to be done in MPV before cutting the product. Otherwise, over linear time, the complexity of the application grows exponentially. This means gash feature in a year will cost O (e (N)) more expensive than at the beginning.
')
In our team, the only designer was a remote employee. It was a serious mistake. A remote employee always lives his life. He draws himself a design, nice and fine, the customer is happy. But all these charms ultimately boil down to the fact that we have N different styles and layouts for the same logical forms. From the very beginning, it was worthwhile to put a demand: stylize a specific framework (we had Ant Design). If there is something not there, do what is there. The customer thought that React is a cubes designer. And he still doesn’t understand why we are sawing primitive forms for 4 days. React is a constructor, but only if we have a set of similar reusable components at the very beginning of development (UI framework). A designer without layout experience will never do this himself. The developer will never tell the customer about it. The leader must follow this. So the Front End team leader should be the Front End developer in the past, not the Back End as it always happens. Consequently, we come to the fact that the full-featured Agile team must contain a competent leader in each of its areas of work (FE, BE). These leaders must have strong Soft skills to convey to the customer what I am trying to describe in this article. And this is very, very not easy.
When we came out in the first release, we realized that we constantly had something breaking on the very last day before the demo. Throughout the year of development, each release branch turns into a hell of crutches (turn it off, put it away), which then magically turn out to develop the thread. And there is a series of commits (turn it on, turn it on). A year later, we came to the conclusion that we need to have a clear branch policy. But most importantly, a responsible person who would eliminate the existing chaos. This meant: either to moderate the chaotic desires of the customer, or to moderate the chaotic bugs, or at each stand to have its own configuration, disabling some kind of graphic features or buttons. Wrapping every button in the if statement is crazy. We came to the conclusion that we need a fiche-modular Front End architecture based on plug-ins (disable - enable). I have long thought how to achieve such an architecture. But one thing I understood for sure. We needed a full context. This is how the js-beans library was born (https://www.npmjs.com/package/js-beans). Each booth had its own json context. The plugins were chained (chased) through the Proxy pattern. For example, we had a data source as a separate bin, and various transformations were done as optional Proxy beans replacing this bin, but injecting it into itself. For example, if you need to scale the data model to test FPS performance, I simply add a line to enable the scaling plugin in the json file. Something broke on the production, but locally not played, I turn on the logger with one line without rebuilding the stand (the stand is about 20 minutes, and a dozen of the stands are not always enough for everyone). Or if you need to quickly turn off a module due to the fact that it can be broken (disable the optional bin in context).
As time went on, we turned off the stands for a week. It was impossible to locally develop the front. We have not provided autonomous architecture for mocks. I had to pain through it with a creak. Now, looking back, I would do it at the very beginning. But we had MVP, and we were forced to write code without deep design. But the customer considered us professionals, and thought that we should immediately write the code without errors. Here is the next error. The name of the company does not speak about the professionalism of the team. The professionalism of the team is determined by the professionalism of the team leader. If there is no technical leader in the team, after a year your project will come to a standstill. So you will merge a couple more millions.
We had a remote architect. But only one thing was known about him: he is. The last stage of development of the leader in the opinion of Vladimir Tarasov. In this, our architect has reached perfection. Error number N: you do not have a technical architect who designs the system at the grade level. You do not have a person who can ask for help if you come to a dead end. Ask for help to other more experienced teams - the customer told us. But for some reason in other teams never had time to help us. Our PR is hanging for the second month. I sincerely hope that there will be a brave man who appruvnet him. As a result, life rewarded our code with a rich abundance of paranormal phenomena in the form of magic and sets of crutches for all occasions. Only one was missing. Magic and @Kostyle special annotations. Good idea for the next ES.
We decided that more midles and less signers are more profitable for the project. Now we think differently. If you have a small budget, you need to hire the most expensive professionals. If you, like us, have no problems with the budget, you can safely save on specialists and turn the Code Review into a battle of psychics.
We thought we would meet quarterly deadlines. Now we think differently. In short, for good we need to rewrite the project. And preferably from scratch. I hope our customer will never know about it. After all, we just recently had a great team building)
We decided to play with new technologies, in which we had little expertise. They were recommended to us. Of course we wanted to gain experience. Now I think that it would be better to use only those technologies in which I have experience.
We gave estimates based on the 8 hour day. In reality, estimates should be given on the basis of a 4-hour working day. Why no one includes tea, the story of interesting stories, search for a toilet on the navigator, talking on the phone, correspondence, the study of new technologies and most importantly, enthusiastic disputes within the team. The latter is probably the most inevitable, and the most expensive. Although, to be honest, for Open Space you need to throw a couple of hours. Constant conversations terribly reduce concentration. Blessed is the customer who understands all this!
Our assessments were exhausting and turned into tedious technical controversy anyway. The effectiveness of the rallies was minimal. But we found a solution: delicious pizza. When the appetizing smell irritates the nose, the person begins to express his thoughts more clearly.
In the beginning we had one small team, then one big team. Planing took 2-3 hours. Stand up 30 minutes. What I respect our PO for is that he decided to divide it into many smaller ones and to highlight his own mini PO in each of them. Probably, this was the best decision in the entire history of our project.
From the very beginning we didn’t have time to write tests. After half a year we came to the conclusion that they still needed to be written. But we still don’t find time for this. Too much higher priority technical debt has accumulated. Not to save technical debt is a utopia. He will always be.
My personal subjective conclusions:
- If your developers do not understand why IoC is needed on FrontEnd, then most likely when they understand it will be too late.
- If your developers don't understand why FrontEnd needs knowledge of OOP, then your code can hardly be maintained.
- Less expensive specialists better than more more profitable.
- If you have an architect, most likely you need another one.
- If you saw MVP, finish it and change the project.
- If you have already filed MVP, do not go to this project.
- If you write down MVP and do not want to leave, most likely you will change your mind.
- If you have written down MVP and want your project to survive, rewrite it from scratch.
- If you show this article to the customer, most likely you will be fired.
- If you work on Agile, most likely you understand me.
You are unlikely to avoid all these problems even after reading this article. My goal is to show you that it is inevitable. And no matter how hard you try, you will never have perfect conditions. So just be ready for this. And before leaving, you can safely show this article to your customer. Let him be morally ready for this.
PS: Maxim, if you ever read this article, know that everything I described is completely fictional and has no resemblance to our project) But all this is not important, because today I am going on vacation. The first vacation for the year of painstaking unsized work! (as FE lead).
Source: https://habr.com/ru/post/448878/
All Articles