Team lead’s monologue on the use of the Agile Manifesto in industrial software development

I draw thoughts from books I have forgotten
Trying to be justified before God,
But what if I can confess
Co-written by twisted intrigues.

Leonid Samoilovich

When you are just starting to develop a software product, there is a temptation not to write the TOR and quickly sketch out the product mockup, which was discussed “last Monday.”
The development team is still small and everything can be discussed without leaving the table.

If luck smiled and the product turned out to be in demand, then it should already be tested to be rejected from the developers.

We invite a tester to the project, and if fortune is our face again, the question is inevitable: on what basis to test?

Tomorrow there is a similar question from a technical writer: How does a product have to work in order to describe it correctly?

And now, ATTENTION, the main question!

How to fix the requirements for a product in conditions when there is no technical specification for the final product, because no one yet knows what will eventually be included in it?

The problem is compounded by the fact that now most of the new features are being prepared taking into account the wishes of real or potential buyers of the product, who are even less patient than children.

So, at the beginning of a long journey, we have a product mockup with no requirements for it. It is not tested and not described.

This is what simplified agile looks like in most startups.

Industrial software development technology is very different. And that’s why.

In such projects, several teams appear, each of which develops its own part based on the functional requirements developed by analysts.

There is a need for their coordination. It is necessary to ensure that all teams understand the system requirements in the same way. There is a need to conduct cross-team debugging. Teams should write implementation requirements, or at least document how functional requirements are implemented. For future generations of developers, it will also be useful to know why it was implemented this way and not otherwise. Testers should be assigned to a separate team. most errors occur at the interfaces between development teams.

Development by the method of sequential build-up of functionality is fraught with a time bomb. At some point, it turns out that the initially adopted architecture cannot accommodate a new feature or cannot cope with the increased load. This problem does not arise when all functionality and load are known in advance. It happens that the system software on which you are based also changes the API, and even worse … the architecture. And then there is a need for refactoring. He kills everything that brings joy in life, and …. delays the sprints at times. It is almost impossible to foresee it. There is a need for regression testing of a significant part of the product. At such times, technical debt starts to rise.

From the planned features, everything disappears except the most necessary, without which the feature is no longer a feature. Only positive scenarios are tested. A method of dealing with an increase in the cost of autotests for an established functionality.

When a product starts selling, there is a need for support. There are requests for bug fixes from the support team. There is a desire to fix it only in the next version, without diverting resources from the development of new features. If you go to meet customers and fix bugs in the old release, then already agreed sprints of the next release begin to pour in. Since each fixed bug requires testing in the old release and, in the future, checking the correct porting to the current one. Developers have to switch from developing new features to fixing bugs and vice versa. You can make a customer wait for a new release, promising that bugs will be fixed in it. But customers are not ready to wait. Therefore, in order not to lose the customer and money for technical support, you have to correct errors in the old release.

The product acquires the properties of an industrial one and … there are releases consisting only of bug fixes.

Nobody likes this except the customers. Because you need to be distracted by the old code. And this is context switching. And this is a waste of time and a disruption of the current sprint. True, this pushes developers to develop autotests, document code, which everyone does not like so much and that, until the appearance of bugfix releases, everyone seems to be a whim of managers and a waste of time.

Therefore, testing can contain several releases at the same time: bug fix release, release being released, current sprint of the next release …

A little more about autotests… The question before teams is whether they need to be developed and, if necessary, to what extent. Everyone probably knows about TDD (Test Driven Development). But in a product where the already debugged functionality can change several times, this leads to costs for developing a test with each change. In this case, all tests, except the last one, go to the basket. Not writing autotests at all is the other extreme. Then everything is shifted to manual testing, which leads to non-testing and delivery of semi-finished products to customers. This is even worse. Each team chooses a compromise solution. Usually tests are written for stable functionality, for checking formats, for load. Unit tests are used for functions with complex logic and / or a large number of execution branches. All tests are run automatically with each assembly of product components in the CI (continuous integration) system. Ideal if you can use beta testers. For example, … from a number of loyal customers.

– Why you call this version “beta”?
– Because it’s betta than nothing

Folk wisdom

Similar Posts

Leave a Reply