Transparent software development process
Among young software development companies, one of the most important problems that stand in the way of development lies in the low level of loyalty (trust) of [potential] customers. In general, over time, provided quality work, it is gradually eliminated naturally. However, how can you speed up the solution of this issue? One option is to organize a transparent development process.
Recently, a client came to our company who refused to continue cooperation with another contractor. The reasons are standard. The developers created the product according to the black box principle: the task list was determined, they left to do all this, and then they rolled out to the client all that happened. Hence a lot of problems, constant customer distrust, because he does not understand what the team was doing, whether they really needed so much time, and if so, why the client was still not satisfied as a result. Hence the result: the product turned out not to be what the client expected him to see, tainted relations and reputation. Losing situation for both.
We managed to rectify the situation by organizing a transparent development process. When working with a previous contractor, the customer had to spend a lot of time on the technical component of the project, to engage in constant checks of developers, instead of focusing on the business. Now the client at any time understands at what stage the project is located, has the ability to adjust the course of work, gives us quick feedback.
')
We have long ago developed for ourselves the most successful version of a combination of several flexible software development methodologies, which we successfully use (sometimes it changes in details and adapts to a specific project). Next will be described the main components of our process, which, in my opinion, more than others affect the speed of establishing trustworthy relations of developers with clients.
Flexible development methodologies come to the rescue. In my experience, teams never strictly adhere to one methodology, for example, Scrum or Kanban, most often each team simply adapts combinations of practices from different methodologies for themselves. For example, we use almost all techniques from extreme programming, except, say, Planning Poker. As a result of such experiments with adaptations of methodologies, a process that best suits the team is built.
We understood the weak points of the development process of the previous team and eliminated them by introducing several important components into the process that are directly related to the interaction with the client. Here are the most important ones.
The process was structured approximately as follows. We are planning a specific set of functionality that needs to be performed at the current stage. The scope of work, for example, corresponds to the month of development, but this does not prevent us from releasing product releases weekly (in fact - daily), adding new features gradually, not once. Thus, in a month we release 4 updates, instead of one. This gives us the opportunity to receive feedback and respond to it as quickly as possible.
Continuous integration is an integral part of quality development. Any changes should automatically fall on the test bench in a fully assembled, where they must check QA-engineer. In this case, there are two main reasons: feedback and customer. As quickly as possible to understand that something went wrong, as expected, it is very important. In addition, when a client can at any time have access to the latest version of the product (albeit not always 100% working), it has a positive effect on his loyalty in general.
First of all, the board on which the development process is reflected should be at all :) But the wrong separation of the board according to status can have a negative impact on the project. When a task “goes” on the board there should be no doubt what exactly is happening with the task and in what status it is. We have defined the following columns for this project: Backlog - Todo - In work - Done - Testing - Resolved - Deploy. In another case, there will most likely be a different set. It is important that these columns correspond to the natural course of the task and are not ambiguous.
A QA engineer who is responsible for the quality of the product as a whole must be connected to the team. This is not just a tester who “pokes” the system by the task description. This is a person who leads all the system usage scenarios, tests new tasks, and performs regression testing. His work largely determines the quality of the product, so such a person must necessarily be involved in the work.
Stand-up rallies - everyone knows about them, but not everyone really uses them. These mini-planning meetings lasting no more than 15 minutes are of great benefit to the team and the project as a whole. Every morning (or before dinner) we call up on Skype with a client and each team member tells about what was done yesterday, what problems arose, how they were solved or decided, and also subscribes to what will be done today. This practice, among other things, gradually increases the level of trust between the client and the team. [In Kanban, by the way, stand-ups are different]
After the end of each iteration, you need to show the client the work done. You need to show everything that has been done or corrected. Show, and not just give a link to the dev-server, where the client can see everything himself. He and so will look himself, but after your demo. It is important to get feedback immediately, perhaps to have some kind of discussion. Demonstration is a very important component. Pleasantly exciting. The whole team takes part, but one person directly demonstrates: a team leader or a QA engineer.
In this article, I listed several key components of the software development process, which allowed us to build a loyal relationship with a client who has unsuccessful experience working with another team. Of course, flexible methodologies offer much more different methods, many of which we use, but here I have cited those that, in my opinion, are more important than others for building a transparent process and trusting relationships between clients and performers.
It is worth noting that in order to carry out such techniques and maintain a high pace, the development team must be of a sufficiently high level. This is especially true of the practice of extreme programming, the main theses of which are directed specifically to the engineering component.
Thanks for attention. I hope, novice teams with not yet fully delivered processes, the article will be useful.
Scrum and Kanban: squeeze the maximum, H. Kniberg and M. Skarin .
Extreme programming, K. Beck .
Lean software production, M. Popendyk and T. Podendik .
Recently, a client came to our company who refused to continue cooperation with another contractor. The reasons are standard. The developers created the product according to the black box principle: the task list was determined, they left to do all this, and then they rolled out to the client all that happened. Hence a lot of problems, constant customer distrust, because he does not understand what the team was doing, whether they really needed so much time, and if so, why the client was still not satisfied as a result. Hence the result: the product turned out not to be what the client expected him to see, tainted relations and reputation. Losing situation for both.
We managed to rectify the situation by organizing a transparent development process. When working with a previous contractor, the customer had to spend a lot of time on the technical component of the project, to engage in constant checks of developers, instead of focusing on the business. Now the client at any time understands at what stage the project is located, has the ability to adjust the course of work, gives us quick feedback.
')
We have long ago developed for ourselves the most successful version of a combination of several flexible software development methodologies, which we successfully use (sometimes it changes in details and adapts to a specific project). Next will be described the main components of our process, which, in my opinion, more than others affect the speed of establishing trustworthy relations of developers with clients.
How to add transparency?
Flexible development methodologies come to the rescue. In my experience, teams never strictly adhere to one methodology, for example, Scrum or Kanban, most often each team simply adapts combinations of practices from different methodologies for themselves. For example, we use almost all techniques from extreme programming, except, say, Planning Poker. As a result of such experiments with adaptations of methodologies, a process that best suits the team is built.
We understood the weak points of the development process of the previous team and eliminated them by introducing several important components into the process that are directly related to the interaction with the client. Here are the most important ones.
Frequent releases
The process was structured approximately as follows. We are planning a specific set of functionality that needs to be performed at the current stage. The scope of work, for example, corresponds to the month of development, but this does not prevent us from releasing product releases weekly (in fact - daily), adding new features gradually, not once. Thus, in a month we release 4 updates, instead of one. This gives us the opportunity to receive feedback and respond to it as quickly as possible.
Continuous integration
Continuous integration is an integral part of quality development. Any changes should automatically fall on the test bench in a fully assembled, where they must check QA-engineer. In this case, there are two main reasons: feedback and customer. As quickly as possible to understand that something went wrong, as expected, it is very important. In addition, when a client can at any time have access to the latest version of the product (albeit not always 100% working), it has a positive effect on his loyalty in general.
The right board
First of all, the board on which the development process is reflected should be at all :) But the wrong separation of the board according to status can have a negative impact on the project. When a task “goes” on the board there should be no doubt what exactly is happening with the task and in what status it is. We have defined the following columns for this project: Backlog - Todo - In work - Done - Testing - Resolved - Deploy. In another case, there will most likely be a different set. It is important that these columns correspond to the natural course of the task and are not ambiguous.
QA engineer
A QA engineer who is responsible for the quality of the product as a whole must be connected to the team. This is not just a tester who “pokes” the system by the task description. This is a person who leads all the system usage scenarios, tests new tasks, and performs regression testing. His work largely determines the quality of the product, so such a person must necessarily be involved in the work.
Standup meeting
Stand-up rallies - everyone knows about them, but not everyone really uses them. These mini-planning meetings lasting no more than 15 minutes are of great benefit to the team and the project as a whole. Every morning (or before dinner) we call up on Skype with a client and each team member tells about what was done yesterday, what problems arose, how they were solved or decided, and also subscribes to what will be done today. This practice, among other things, gradually increases the level of trust between the client and the team. [In Kanban, by the way, stand-ups are different]
Demo
After the end of each iteration, you need to show the client the work done. You need to show everything that has been done or corrected. Show, and not just give a link to the dev-server, where the client can see everything himself. He and so will look himself, but after your demo. It is important to get feedback immediately, perhaps to have some kind of discussion. Demonstration is a very important component. Pleasantly exciting. The whole team takes part, but one person directly demonstrates: a team leader or a QA engineer.
Conclusion
In this article, I listed several key components of the software development process, which allowed us to build a loyal relationship with a client who has unsuccessful experience working with another team. Of course, flexible methodologies offer much more different methods, many of which we use, but here I have cited those that, in my opinion, are more important than others for building a transparent process and trusting relationships between clients and performers.
It is worth noting that in order to carry out such techniques and maintain a high pace, the development team must be of a sufficiently high level. This is especially true of the practice of extreme programming, the main theses of which are directed specifically to the engineering component.
Thanks for attention. I hope, novice teams with not yet fully delivered processes, the article will be useful.
Links
Scrum and Kanban: squeeze the maximum, H. Kniberg and M. Skarin .
Extreme programming, K. Beck .
Lean software production, M. Popendyk and T. Podendik .
Source: https://habr.com/ru/post/295074/
All Articles