Software Development Methodology

They asked me at the company to make a report and talk about the methodology for which we work, we are developing our application. I immediately said - "We have Scrum", and sat down to make a presentation. But I stopped on the first slide, and here's why.

Agile contains many methodologies - XP, Scrum, Lean, Kanban, ScrumBut (Scrum). Having sat down to understand the techniques, I realized that I could not say that my team was working on one of them. In general, our workflow can be represented as:



')
As you can see, we use a lot of items from different methodologies, a lot - but not all. We adapted methodologies for our development process, for our team.
We use a lot of recommendations from XP practice, we found something similar in our development process in the Kanban methodology, some of the points were taken from the Scrum-methodology. I decided to select a separate axis and called it Conferences. Because a lot of useful ideas were taken from the conferences. I can say that the beginner Project Manager (y), Team Lead (y) should start with conferences, but not just come and listen, but go to the speaker after the performance and try to ask questions that interest you. That is how a release page, team and personal goal appeared in my team, my QA-specialists brought from the conference such a useful thing as impact analysis and the notion “tester-analyst”. But let's not digress from the main topic and return to the methodologies of software development.

At the core of the project is the concept of Sprint and Product backlog, who are familiar with Scrum (om), he immediately says that these are his main artifacts. But our team has no Product Owner (a), User Story has no priority and no Story Point (s). We do not have Scrum cards to play in Planning Poker and we don’t draw Burn down charts, but instead of Scrum boards we have a release page.
And we don’t use all this, not because we are too lazy or we don’t understand how to do it, just some of the artifacts have disappeared during the development of the application. The customer did not want to set priorities, because for him all the tasks are important, we did not “bother” with Story Point (s), because in the sprint could push new tasks. And we did not build a diagram, because it was not visual. When we are asked, in the development process, how things are going, we show a release page that looks something like this:




Once I was advised by Alexey Lupan to lead her, he spoke at a conference and showed something similar for his project. I implemented it in my project and it turned out to be convenient. On this page you can see how many features we included in the release, who is responsible for each feature, in what condition it is. The deadline for testing and production is also indicated. The most important thing here is a list of all critical and very important errors that you need to pay attention to before submitting a new version of the product. I like this page because if there is more than one tester in the project, then I tell everyone - “Test important errors, and it doesn’t matter that they are designed for someone else, it’s better to take a fresh look. So you can find something new. ” And it works. How many times have I had such situations when one tester found errors with another tester. It really saves. Of course, it is not always possible to do double testing, but whenever possible I try to practice it. Here the saying goes: one head is good and two is better.

And so, I told you what we do not use in Scrum. Oh yeah, I almost forgot, we are not holding daily standup rallies. We are sitting side by side, at arm's length, everything that is being discussed is being discussed next to the team, which means that everyone hears. Therefore, meetings are held as necessary. Mostly when required by the customer. Then we print the release page, and print the tasks broken into subtasks, with the status opposite to each subtask and with comments in the Problems column, if any.

In general, in the process of working, I learned two truths for myself:
1. the customer doesn’t care what methodology you use; in fact, he is interested in the final result;
2. If you give the customer more than he expects, he becomes happier.

This was also checked more than once, especially the first truth, because when errors appear at the end of a release, the customer forgets that you are working, for example, on Scrum. He has such questions in his head: “When will it be fixed?”, “Who is to blame?”, “Why did this happen?”. And note, in that order. It is unlikely that at this point the customer expects you to start playing Planning Poker, arrange a Story Point and plan a sprint. And he is not interested in velocity, even if it has doubled in comparison with the previous sprint. And he will not look at the graphics either. Therefore, if you are hampered by some artifacts in Scrum or you consider them not very useful in your project, do not be afraid to throw them out, there is nothing terrible in this. The main thing is that your team continues to move forward and be flexible in terms of changes. Scrum is a kind of framework consisting of separate parts. You can use all of its parts, you can connect gradually, but you can also change something to suit your needs. In this, it seems to me that there is a sense of agile methodology, when you do not bend under the methodology, but the methodology bends under you.

Another truth that I like and which bears fruit is to give testers as much time as possible to test the finished product, and also let testers test the intermediate results of your work. Probably the second part of the previous sentence is the main one. I always let my testers touch the raw version of the app. What for? In order for them to begin to criticize, to say that something is not convenient, to bring in ideas, to start writing tests to test what will be, they have begun to think through bottlenecks in logic and interface. It gets a little bit, but nonetheless brings its fruits. The main thing is not to make one mistake, which I heard in many projects. The error lies in the fact that testers and programmers are sitting separately, and most importantly do not communicate on the line. Those. two enemy camps are being formed. This is not correct, remember, you are a team, you are working on one product, your goals are the same. Help each other, sit together, ask questions, communicate.