When cooperating with the customer, it is important that he participates in the testing process and makes corrections (if there are any) in the development process. This will allow the customer to trust the executor more, because if such testing is carried out, say, at the end of the sprint, then the customer will see the changes that occur in the development of the program. It will also help the customer to more realistic assess the timing for which one or another functionality can be made. We are trying to hold such meetings at the end of each sprint. Sprint is the time period for which the team creates a part of the functionality ready to be displayed to the client. Each Sprint is a mini-project that consists of a goal, a plan for its achievement, work and the final product.
Here’s a recent version of the program, at the end of the sprint, for Dimol, a customer of the Dimol Smart application. The process took place on the customer side with the connection of panels to the application and passed all stages of verification from the Dimol company. The results were good enough Dimol Smart perfectly synchronized with the heaters. That is, when you change any parameters on the heater (for example, the heater doesn’t heat up or the temperature in the room has changed), it is immediately displayed in the application. If there is a mistake in the panel, you will be notified. During testing, we found where the delay in transmitting data from the heater in addition (when changing the temperature in the room), and the customer made adjustments to add colors in the interface. Such testing enables the customer to better understand how the logic of the program is implemented, and we can again see the functionality that is the priority for him (customer). The development of this kind of functional is largely a creative work that has practically no analogues in the market, and the division of development into sprints helps to realize exactly what is needed. That’s how we can focus just on the required functionality.