The Agile Transformation Practice of a group product in zhongxing communication

This product from 2014 began the formal implementation of agile transformation, to 2016 to achieve product-level agility, about two years of time. This article is based on my experience in ZTE these two years to do the summary, insight is relatively superficial, and most of it is written down by memory, inevitably there are some inconsistencies in the place. first, the Agile Transformation Program 1 Project Overview

• Product use: China Mobile IPTN bearer network transmission equipment

• Project team: Develop 120 + Test 30 people

• Number of products required (Feature): approx. 500 items

• Number of user stories (Userstory): approx. 3,000 articles

• New development veneer: 10 pieces

• New Modification code: approx. 300W

• Number of test cases: Automated 7000+ manual 3000

• Research and development cycle (project to design): approx. 1 years 2 transition Ideas

• Research and development process follow the company HPPD development process framework, combined with CMMI process domain, promote agile practice

• Agile propulsion is guided by the evolution from team-level agility to project-level agility and product-level agility

– Team-level agility

• Located within the Software development team with 7-15 people, involving software development and system testing Department

• The scope of agile practice is limited to team scope, the level of practice content and ability of the team is different, the team work ability is weak.

– Project-level agility

• Located in the PDT Research and Development group work, with research and development projects as the carrier, involving planning Department, Software Development department, System testing department, pilot department and many other roles and teams

• The scope of agile practices extends to the entire research and development project level, which is applicable to the Agile development team of the strong project organization, weakening or canceling the department

• The pursuit of multi-role, teamwork ability to improve the quality of project development and efficiency for the purpose

– Product-level agility

• Positioned throughout the PDT team and the HPPD product development process

• Agile Practice covers all areas of the PDT team

• Product development process with market demand driven, efficient internal cost and risk control as the main line, customer value realization as the Center 3 organizational structure Adjustment

• Change the previous matrix, each team is composed of Sm+po+team, forming a feature team

SM: From the development manager, Test Manager, SE, or other business backbone

PO: Is generally familiar with the business of the technical backbone, such as SE

team: Includes development (software, logic, microcode), Test 4 SM and PO responsibilities

SM Responsibilities:

– Guide the scrum activities

– Work with the team to promise an iterative output to the PO

– Track the progress of tasks within an iteration and lead the team to complete the iteration task objectives on time

– Management of dependencies with other teams, external coordination of the team, and external interface

– Help teams remove obstacles from work

– Work with the team to assess performance, listen to team voices, and respect team views

– Focus on team capabilities, including team members ' business skills and soft skills

PO Responsibilities:

– Maintain the backlog and adjust the list to competitors, market changes and customer feedback in a timely manner

– Communicate with product-grade PO when demand is unclear

– Uncover the most valuable features from your customer's usage scenarios and communicate them to your team in a timely manner

– Answer team questions about test scenarios to make test scenarios as consistent as possible with customer usage scenarios

–po attends daily meeting to answer business questions, but does not interfere with management work

– Participate in the needs grooming meeting to answer the team's questions on clarifying requirements and determine userstory acceptance criteria

– Participate in the program, and team together determine the content of each team's iteration output

– Participate in the review, acceptance of work products within the team, preferably to the real user to check

– Participate in the review to gather ideas on product improvements 5 Agile Framework

• Team Level: System solution completed to system test end, mainly feature team

• Project level: Product requirements Package determination to end of validation phase, feature team + Test team

• Product Level: Entire product development cycle (before operation and maintenance phase), feature team + Test team + Hardware Group + Pilot Group + production Group + Power + process structure 6 Agile Solutions

• Application projects: All software, hardware and system projects

• Project criteria:

– Identify key requirements

– Explicitly release iteration cycles or release milestones

• Project composition: The Agile development team of the strong project organization, weakening or canceling the department

• Delivery conditions: Team-level Agility meets system test conditions (Results identification), project-level agile meets validation test conditions (design stereotypes), product-level agility meets low-volume production validation (production stereotypes) 7 Agile Models

• Integrate three tiers of products: product-level, project-level, and team-level activities. second, the Agile transformation Practice

1 daily Station meeting

• Start every day 8:45 on time, organized by iteration

• The team takes turns speaking, standing in front of the Kanban board, holding a story card

SM collect issues that need to be communicated at the Project SOS Station

2 SOS

• character

– each feature team SM, QA, agile instructor must attend, PM as appropriate to audit and supplement

• Communication Content

– The end of the last meeting and now, what our group has done.

– What is the main task of our group after this meeting?

– What difficulties we have encountered and what kind of assistance is expected.

– What are the issues we need to solve across groups.

• Output

– List of issues to be resolved and current status updates

– Good advice and methods to record

• Do not do anything

– No specific problem solving at the meeting

• Unable to quickly locate issues, identify follow-up people and participants, post-discussion sessions, project add a story card tracker

• Complex technical and business related issues to be submitted to the project team for a unified approach to structuring the group discussion

• Other

– 1 minutes per person, total time control in 20-30 minutes

– Encourage inter-group collaboration and encourage cross-group communication 3 requirements clarification/grooming

• Requirements can be layered, as plans can be layered

Epic/feature/user Story is a label used to differentiate the granularity of demand

• Project-level PO with team-level PO analysis feature

• Work together to determine feature priorities, workloads, responsibility teams, acceptance criteria

• Project-level PO determines the backlog for the next iteration

• Team PO splits feature into US 4 iteration plans

PO before the feature split us, determine acceptance criteria

Po explains us, team estimates US workload

• Team claim US and split task

PO Determine the spring Backlog that is completed within the iteration

5 Iteration Review

Principles

– Everyone has gone all out on their work, taking full account of the current situation, displaying their skills and invoking callable resources.

Focus	Loose focus
Explore	Rather than a defense.
Dialogue	Rather than arguing.
Communication	Rather than arguing.
Understand	Rather than guard against it.

Agenda

–po Acceptance Team Tasks

PO with the team to accept the Sprintbacklog in the US, acceptance through the close US

• Incomplete emigration of this iteration, and determine which iteration is complete and the blocking problem is moved to the blocking area

– Team Review Summary

• Team members list The good and need-to-be-improved questions of this iteration on the sticky note paper

SM to classify problems

• Team members vote for three needs to be maintained, three needs to be improved

• The team discussed three improvement measures to improve the problem 6 Continuous integration

• Pre-warehousing walk-check

– Before warehousing, complete the static tool inspection, through the pair after the walk to check the code, walk through the code after the pass.

– Code-in logs are filled in strictly according to the template: feature number, impact analysis, suggested test methods, modification, and follow-up information.

• Daily Architecture Group Review

– Schema Group development Code walk-through unified templates

– Daily 17:00-17:30, the architect randomly checks the code submitted by the business group on the day, discovers corrective comments against the rules, and enters into the sprint backlog of the relevant business group

– The architecture group analyzes and summarizes the issues identified by the architect Code review at the end of each month, and publishes monthly reports on the project.

ci Continuous Integration:

– Every night 12 o'clock trigger Pclint, klockwork, line coverage, complexity and other detection tools, full-scale construction, automated smoke testing, 7 points in the morning automatic push results, free time to run full-scale automated testing

7 Tiered Testing

• Test layering

–story layer, development self-test

–feature layer, the business group is responsible for self-test, the joint adjustment, the professional Test team is responsible for system testing

–epic layer, the professional testing team is responsible for (program testing)

• Test strategy development

– Version of the overall test strategy is developed by the version manager and the Test manager, including version planning, test time, test planning, SM testing tasks

• New functional Test Cases

–