Product Design Experience (November 6)-Understanding "agility"

 

 

 

Recently, I was a little interested in agility. I spent two nights browsing agile iterative development-manager's guide, a conceptual book. It seems easy to extract some of my own experiences.

 

Some requirements cannot be raised at the beginning, or can't be refined. Forced transitional demand analysis is a waste of time. Later, most of them will need to be changed.

Waterfall (in fact, the original intention of the waterfall model proposed by Royal is also iterative, but it has been misunderstood by future generations) is the problem of exposing contradictions in the end, of course, it is good for projects with fixed requirements.

Agile iterative development is extremely dangerous if it is out of context. For example, if there is no iterative test to keep up with, it will be too late to discover the problem at last.

 

Four agile modes are introduced: scrum, XP (eXtreme Programming), up (Unified Process), and evo (evolutionary project management). Their common points are as follows:

 

Embrace changes and resolve major problems separately. First, resolve the core and most risky aspects.

Consolidate the work in the meeting room, hold regular meetings every day (<20 min), stand-up meetings, and make full use of whiteboards and walls.

A short iteration cycle is usually one week to one month. The number of teams should not be too large (less than a dozen). Too many teams can be divided into multiple teams.

Ø tasks are never added to an iteration cycle, and there are many requirements placed in future iterations. If tasks cannot be completed within the iteration cycle, they can be required by time points, remove a part of the task to the next iteration.

Lists the tasks in the iteration cycle and traces the tasks at a very small time granularity (in days.

Ø continuous release/delivery, allowing the demand side to see the results and get feedback.

Ø the demand side should be fully invested, Including the need personnel working together, and the acceptance test iteration.

The demand-side representatives should have the right to speak, otherwise it would be extremely depressing to take a half-way lead to a boss.

Streamline the document and refine and correct it through development and testing.

The programmer selects the task point and schedules the time point.

It is difficult to combat overtime, especially in China.

Many oral communications are required by team members, especially Chinese technicians.

Emphasize testing, early testing (TC written earlier than coding), heavy testing, and test drive projects.