The organizational structure and collaboration model of multi-team agile development (continued)
In the blog http://yuan-bin01.iteye.com/blog/1756125 , I introduced the organizational structure and collaboration mode of multi-team agile development in practice. Here is a supplementary introduction to some special practices of the "technical expert" team.
The technical expert team here can be composed of internal engineers, but in some cases, external technical resources can also be considered.
We have such a scenario in practice: the system is in trial operation, and the performance problem is relatively prominent, but new requirements are constantly put forward after customers use it. Everyone's energy is on the realization of the new requirements, and the performance optimization is not enough. The enthusiasm, or "tired", all the brainstorming has been unable to get valuable feedback.
For this, we tried outsourcing. Our goal is to make our customers feel the improved performance this Sprint, and here's what we're doing:
1. Find out the three most complained pages of customers (login, statistics, detailed list) and the home page of the website as the needs of this optimization
2. Among the contractors we have cooperated with before, choose the best technology (objectively speaking, it is not the best cooperation)
3. Communicate a cooperation model with the contractor: the contractor is responsible for identifying bottlenecks, proposing a plan, testing and submitting a test report to prove the feasibility of the plan. The communication and assessment with the contractor is done by the architect team. In other words, the architect team is the contractor's PO and is responsible for the proposal and acceptance of technical requirements.
4. According to the plan proposed by the contractor, combined with the Sprint cycle, select the final plan. Our principle is: the least amount of change, the most obvious effect.
5. Code modification by Team and technical support by contractor. Contractors need someone to work with us.
We found that: In fact, the contractor may not necessarily come up with a particularly "eye-catching" plan, but they have found some obvious common-sense problems. These problems are probably written in a hurry when the schedule is tight, but there is no People refactor, or rather nobody has the passion to refactor.