How to develop new functionality with maximum benefit for a product?
Prepare your team before active development is started
The main stakeholders for any functionality being developed are the business side (or product owner), UX designer, developer, and QA engineer. These 4 sides represent the point of view of what the system should do, how it should look, what can and can not be implemented, and what may go wrong or be missed. Having different people for each point of view will help reduce missing important points.
And yet, do not limit discussion with only these sides. Depending on the functionality you are developing, you may find that other interested parties are needed to provide other points of view (marketing team, seo-specialist, support team, etc). But do not think that the bigger is the better. Include only people who are interested and will be involved in the implementation process. Do not include the whole team in discussion as this reduce team members’ sense of responsibility. As a result of passive participation - important points may be missed. Placing the right people in discussion is must done to achieve the best results. How get things done?
These nominal four parties must work together to determine what needs to be done, how to understand that it is done and done as expected. Once the functionality is implemented, each party should check the final result to make sure that it is still correct from the point of each view.
The first discussion should be immediately before user story implementation. Do not wait too late to add details and ask questions because the delay will slow development down. Do not start discussion too early - the details may become outdated, the context may change so that knowledge can no longer be applied.
Between the beginning and the end all key participants should communicate closely, so that any misunderstandings be discovered and corrected at an early stage and therefore any new ideas can be included. By continuous sharing the different perspectives on the functionality everyone can raise their concerns and resolve as soon as possible.
Why is it important?
This approach helps to avoid:
- missing any details
- confusion in user story understanding
- rework
What can be difficult?
- incorrect or incomplete workgroup composition. Members should be carefully considered.
- too frequent discussions - instead of implementation. Discussion should be qualitative and detailed to resolve most of the questions before implementation is started.
In general these user stories discussions are short workshop with the team to understand the details and ensure everyone has all the information they need. But in the end it gives great value to the product.
Using GoLang and MQTT
Surprisingly, on GoLang we don't have a lot of different solutions around MQTT protocol. My goal is to build a reliable solution based on paho client and highlight different cases. While trying different approaches I finally come out with a scalable and robust solution.
How You Can Make It Easy To Write Unit-Tests In Golang
When I started to write unit-tests in golang at first it wasn't easy and it was taking much time. I didn't know specific tools, technique and libraries to make easy writing of tests.
Google maps as background for SVG map
Imagine that we want to show USA with a beautiful background of the oceans and neighboring continents. All we need are just find a picture, set as background, and done. It seems that everything is beautiful and we do not need Google maps, but there is a big BUT, there is a responsive layout