Lean development practice-use dashboards to manage Reading Notes for large-scale projects

1. Project Background

2. organize teams

3. Attend cocktail parties every day

The above meeting usually lasts for 10-15 minutes and is chaired by the team lead (scrummaster). Generally, the following three questions are raised.

• What did I do yesterday?
• What are you going to do today?
• What troubles have you encountered?

All testers gather before the test status board to discuss how best to take advantage of the day's time. Testers belonging to the specific functional development team just held a meeting with their respective teams, so they can share the latest progress of each team.

At the same time, the demand analysis team is holding their own synchronization conference. Analysts who have just finished the meeting with the function development team also attended the meeting. They have the latest information to report to the entire demand analysis team.

The people who participate in the Project synchronization presentation are called cross-team members. In this project, each major sends a representative, each function development team sends a representative, and several others, such as the project manager, Configuration Manager, and myself.

We will review the status of the entire project at the project synchronization Conference, focusing on the normal operation of each process from Requirement Analysis to production:

• What is each team doing today?
• Is there any problem blocking our process?
• What are the bottlenecks?
• How can we eliminate bottlenecks?
• What will happen to the next bottleneck?
• Is our release plan going smoothly?
• Do anyone know what to do today?

4. Project Progress Board

This system looks like a waterfall development model. In fact, in the panel system, these different stages are parallel.

You cannot fill up all task boards.

Use a police car to mark emergencies that require rapid handling.

Use a Pink sticker to indicate obstacles.

5. Expand the task board

As the number of project members increases, each team member has its own task dashboard, showing the progress of the team. However, the overall project status is unclear.

• What is the overall progress of the project?
• What are the bottlenecks? What new functions will be available next?
• Which functions can be completed on time when this version is released?

6. Tracking the overall goal

If everyone knows what the overall goal is, they will pay more attention to the overall goal.

7. Define "available" and "complete"

The two most important definitions are "available for development" and "available for system testing", because these two are the most problematic areas in the past. When a feature is available for development, it must have the following features:

• There must be an ID.
• You must have a contact.
• Must be valuable to customers.
• It must be estimated by the team.
• The acceptance test scenario must be written on the back of the function card to describe the specific steps of a typical test scenario.

Available for system testing:

• Automated acceptance testing. End-to-end functional level acceptance testing or inheritance testing has been automated.
• Regression testing: All automated tests that run existing functions must pass.
• Already demonstrated.
• Enter the check-in notes clearly.
• Tested in the development environment.
• Merged with the code trunk.
  

8. Handle technical accidents

9. Handle bugs

10. Continuous Improvement Process

• Transparency: Set a dashboard in a conspicuous place to show everyone the progress of the project. Deliverables are clearly defined and can be understood by everyone.
• Communication: periodic process improvement workshops (weekly or every two weeks) are held within and across teams ).
• Data: track some simple metrics to see if the process has been improved. We measure the speed and cycle time.

Example of Process Improvement Proposal

11. Manage Products

There are only four columns of work in process.

12. capture and use Process metrics

Process measurement is very useful. We can find out where improvements are needed and see whether our changes have brought positive results. It is also useful for planning the version release outline from a macro perspective. We track the following two process measurements:

• Rate (number of features per week)
• Cycle Time (the development time of each function)

1. It can be used as a realistic check tool to check whether the version release plan is feasible.

2. Based on this data, we can predict the approximate number of functions that can be completed by a certain time point.

• Stable rate: the weekly rate should be the same, rather than unevenly distributed.
• Increase Rate: our current average rate is 3 with the goal of 5.
• Shorter cycle time: Our average cycle time is 6 weeks, and the target is 2 weeks.

13. Sprint version release plan

• Requirement List sorting
• Select top 10 features
  • Business Value
  • Knowledge
  • Resource Utilization
  • Dependency
  • Testability
• Why sort the demand list out of the sprint planning meeting?
• Planned version release

14. How do we implement version control?

No spam for Trunk

Team Branch

System Test Branch

16. Lessons learned

• Understanding goals
• Continuous lab
• Failed to hug
• Solve real problems
• Has a full-time promoter of change
• Engage people
  

Typical day of panel management

Lean development practice-use dashboards to manage Reading Notes for large-scale projects