Big kitchen big data. Part 1
It is time to share our experience of organizing the development process in the fashionable theme of “Big Data”. In the telecommunications industry, Big Data has high hopes for new niches, products, and, accordingly, revenues. True, many telecommunications companies prefer to buy ready-made solutions in the field of Big Data, rather than develop their own expertise. Since 2013, MegaFon has gone the other way, making a bet on a team of strong Big Data specialists who are able to effectively solve very difficult tasks.
Before diving into Big Data, you should be familiar with the legal framework that governs their processing. The federal laws “On Communication” and “On Personal Data” set forth in detail the data processing procedures that the cellular operator accumulates. This information, in accordance with the law, must be protected - therefore, information about real customers and their transactions cannot be used to debug and test newly written code.
When “internal customers” and work performers sit at adjacent tables, this provides instant and natural feedback. Add here not always a clear statement of tasks, the desire of the customer to make adjustments “on the go”, and we will see that SCRUM becomes the best method of work. He faithfully served us for almost 12 months until the end of 2013. The development went quickly, while we had the opportunity to experiment and produce an effective product. A single team of customers and developers in full force participated in the discussion of tasks, in the decomposition of requirements into technical components. As a result, customers saw how their ideas were implemented in code, and developers solved interesting problems, combining and performing the functions of analysts, architects and designers.
In the meantime, tasks from the customer multiplied, the requirements became tougher, backlog was accumulating, technical debt grew. In addition, the requirements for reliability and performance of already implemented solutions were tightened. It was here that SCRUM began to fail: sprint planning became so long and complicated that it upset the team’s rhythm. Nobody wanted to take big and difficult tasks in the sprint, I didn’t want to cut tasks either. For a large number of tasks, the team stopped seeing the big picture; immediate tasks began to distract people and reduce productivity. It is time for the kanban method.
')
We restructured the workflow, again involving the “internal customers” themselves, and established a constructive dialogue: the assessment of tasks began to be carried out all the time, and not just during the planning of the sprint. At the same time, there was a shortage of analytics that would filter the flow of customer requirements, and the size of the team did not correspond to the volume of the tasks. As a result, we invited trainers, we needed advice from people who made learning lean technology their profession. After talking with them, we came to the scheme of the process that we use now.
Perhaps the main problem was a large number of tasks (regardless of the amount of work to solve them), which stretched the deadlines. The customer was unhappy, the transparency of the process left much to be desired. Another problem appeared: the feedback with the customer worked poorly. He was not interested in how his tasks are decomposed, in what order they are taken into work, and when he will receive output. From here and misunderstanding of real terms of work. The third problem was that the developers themselves began to lose understanding of how a particular task affects the overall goals of the team.
While maintaining a commitment to a flexible approach (which ensured speed, flexibility and responsiveness), we changed our process so much:
We have agreed on general rules for keeping and filling backlog when all requirements are collected, and the analyst puts emphasis.
For customers, this gives them confidence that their tasks will not be lost, and for developers, the ability to receive correctly described tasks with a predetermined priority (in the future this will help to avoid unnecessary iterations of reworking the functional).
We began to actively use User Story Mapping, this tool was a good help to involve customers in the discussion of tasks and their decomposition. For all participants in the workflow, it became clearer what is being done to accomplish a specific task and how this decision will affect the final product.
After successfully applying Story Mapping, we approach the Impact Mapping tool. It will allow you to globally assess the impact of each refinement on common goals and to place emphasis.
We have identified several areas within the development process and divided into classes all the services developed by different teams. This made it possible to isolate the development teams, due to which programmers stopped distracting with the immediate tasks of other projects, and customers and analysts understood the capabilities of each development direction and built their goals more efficiently.
For all employees (customers and R & D), trainings were held where they were told about the methodology, basic principles of work and tools that allow using Kanban with maximum efficiency.
This key Kanban practice has allowed us to increase the transparency of our development processes for our customers. We calculated the average time to complete the tasks and calculated the maximum number of tasks for each direction, which is necessary to meet the requirements of customers. Therefore, in order to guarantee the quality and timing of the work, we consider only tasks that we will precisely cope with.
We could not completely abandon the weekly planning, so we left the weekly meetings with customers to discuss the status of the development stages, determine which tasks are transferred from backlog to ToDo, and completed and tested works are accepted.
Key meetings :
• Planning
Participants: Customers, Managers
The purpose of the meeting: filling TODO Backlog
Weekly
• Acceptance
Participants: Customers, Managers, Team
Meeting purpose: Acceptance of team work results
Weekly
We began to arrange weekly meetings for the whole team. They were arranged before that the whole team was aware of common processes. Now the emphasis is on technical tasks, it is determined which of the developers will carry out specific tasks, which works completed earlier are closed, and plans for development are formed. It has become a truly effective tool.
Continued here .
There is a law
Before diving into Big Data, you should be familiar with the legal framework that governs their processing. The federal laws “On Communication” and “On Personal Data” set forth in detail the data processing procedures that the cellular operator accumulates. This information, in accordance with the law, must be protected - therefore, information about real customers and their transactions cannot be used to debug and test newly written code.
From particulars to general
When “internal customers” and work performers sit at adjacent tables, this provides instant and natural feedback. Add here not always a clear statement of tasks, the desire of the customer to make adjustments “on the go”, and we will see that SCRUM becomes the best method of work. He faithfully served us for almost 12 months until the end of 2013. The development went quickly, while we had the opportunity to experiment and produce an effective product. A single team of customers and developers in full force participated in the discussion of tasks, in the decomposition of requirements into technical components. As a result, customers saw how their ideas were implemented in code, and developers solved interesting problems, combining and performing the functions of analysts, architects and designers.
In the meantime, tasks from the customer multiplied, the requirements became tougher, backlog was accumulating, technical debt grew. In addition, the requirements for reliability and performance of already implemented solutions were tightened. It was here that SCRUM began to fail: sprint planning became so long and complicated that it upset the team’s rhythm. Nobody wanted to take big and difficult tasks in the sprint, I didn’t want to cut tasks either. For a large number of tasks, the team stopped seeing the big picture; immediate tasks began to distract people and reduce productivity. It is time for the kanban method.
')
We restructured the workflow, again involving the “internal customers” themselves, and established a constructive dialogue: the assessment of tasks began to be carried out all the time, and not just during the planning of the sprint. At the same time, there was a shortage of analytics that would filter the flow of customer requirements, and the size of the team did not correspond to the volume of the tasks. As a result, we invited trainers, we needed advice from people who made learning lean technology their profession. After talking with them, we came to the scheme of the process that we use now.
Bug work
Perhaps the main problem was a large number of tasks (regardless of the amount of work to solve them), which stretched the deadlines. The customer was unhappy, the transparency of the process left much to be desired. Another problem appeared: the feedback with the customer worked poorly. He was not interested in how his tasks are decomposed, in what order they are taken into work, and when he will receive output. From here and misunderstanding of real terms of work. The third problem was that the developers themselves began to lose understanding of how a particular task affects the overall goals of the team.
While maintaining a commitment to a flexible approach (which ensured speed, flexibility and responsiveness), we changed our process so much:
- 1. Formalization of the requirements collection process, backlog management
We have agreed on general rules for keeping and filling backlog when all requirements are collected, and the analyst puts emphasis.
For customers, this gives them confidence that their tasks will not be lost, and for developers, the ability to receive correctly described tasks with a predetermined priority (in the future this will help to avoid unnecessary iterations of reworking the functional).
- 2. Story Mapping
We began to actively use User Story Mapping, this tool was a good help to involve customers in the discussion of tasks and their decomposition. For all participants in the workflow, it became clearer what is being done to accomplish a specific task and how this decision will affect the final product.
After successfully applying Story Mapping, we approach the Impact Mapping tool. It will allow you to globally assess the impact of each refinement on common goals and to place emphasis.
- 3. Introducing Service Classes
We have identified several areas within the development process and divided into classes all the services developed by different teams. This made it possible to isolate the development teams, due to which programmers stopped distracting with the immediate tasks of other projects, and customers and analysts understood the capabilities of each development direction and built their goals more efficiently.
- 4. Exact Kanban
For all employees (customers and R & D), trainings were held where they were told about the methodology, basic principles of work and tools that allow using Kanban with maximum efficiency.
- 5. Limiting the number of tasks that are simultaneously in the work, including service classes
This key Kanban practice has allowed us to increase the transparency of our development processes for our customers. We calculated the average time to complete the tasks and calculated the maximum number of tasks for each direction, which is necessary to meet the requirements of customers. Therefore, in order to guarantee the quality and timing of the work, we consider only tasks that we will precisely cope with.
- 6. Weekly meetings with customers
We could not completely abandon the weekly planning, so we left the weekly meetings with customers to discuss the status of the development stages, determine which tasks are transferred from backlog to ToDo, and completed and tested works are accepted.
Key meetings :
• Planning
Participants: Customers, Managers
The purpose of the meeting: filling TODO Backlog
Weekly
• Acceptance
Participants: Customers, Managers, Team
Meeting purpose: Acceptance of team work results
Weekly
- 7. Daily meetings (stand-up rallies) for development teams
We began to arrange weekly meetings for the whole team. They were arranged before that the whole team was aware of common processes. Now the emphasis is on technical tasks, it is determined which of the developers will carry out specific tasks, which works completed earlier are closed, and plans for development are formed. It has become a truly effective tool.
Continued here .
Source: https://habr.com/ru/post/269557/
All Articles