Author: Li Wenhua Note: This article is original, any use must have my consent.
Work as much as possible
1.1. Various characters can work together
Agility features are to make the work more efficient. Few companies carefully considered that the optimization of project members in workflows can improve how much work efficiency is increased. However, as long as we think about it, each member in the project is actually a CPU capable of independently calculating and completing the task, then we will continue to optimize these CPU workflows like IBM's grid computing experts. What about a new world record?
Don't think that you must start development after all the needs must be completed and you can start testing. Software managers should be very clear that all project members are available for useful CPU resources, whether in any stage of the project, you should not let these CPU resources are too idle. The project's work advances to want the CPU's pipeline, do not form a sequential process, and carry out as concurrent as possible, so that resources can be utilized to maximize resources.
Demand analysis is still in progress, what do developers do?
Designed is still in progress, what can demand people can do? What can the tester do?
The author is not good at exploiting the owner of the labor force. Asking these issues is to inspire "Human Resources" is very flexible, and many times feel that "there is not enough resources" is not really not enough, but ask yourself " The resources have been fully utilized. "
The following table is an agile work plan for everyone to refer to you. In this plan, the author should emphasize a few points:
1. There are many hidden work in software projects, and we must take into account when project projects, and discharge them. For example, training, formulation, organizational utility development, etc.
2. Clear role is divided, try to clarify the job responsibilities of everyone, will make the entire team more active and orderly.
3. Do not ignore the coordinated levels, within the project group, within the department, cross-sectors require good communication channels and coordination resources.
Stage role
Demando / human machine engineer
Architect / designer
Development Engineer
Test Engineer
requesting research
l Communicate with customers
l Writing cases and demand specifications (functional requirements, non-functional requirements)
l Training (business background)
l organization demand review
l architecture design
l Confirm the demand with the demander
l Constructing prototype
l Training (tool usage guide, coding specification, environmental construction, debug guide, performance problem processing)
l organization utility development
l Participating in demand review
l Install and become familiar with tools
l Learn about business background
l Training and learning
l Develop utility tools
l Participating in demand review
l-write test plan
l Writing test case
Analysis / design
l Continue to confirm the demand
l refine features list
l refine logic checklist
l interface requirements
l Participate in design review
l Architecture design refinement
l module summary and detailed design
l Writing an interface document
l Writing Performance Test Plan and Performance Program
l organization design review
l Participate in design review
l Write the unit test for the interface
l refine test case
l Preparing to test the environment
Realization / test
l Continue to confirm the demand
l Check function implementation
l Check Interface Specification
l code walking (code structure, interface, abnormal processing, performance bottleneck) L ~ PR
l microscopic performance test
l Code implementation
l Precursive logic checklist writing unit test
l Modify BUG
l Participating in skill training
l function test
l Macro performance test
l integrated test
1.2. Always do the most
Let the entire team work as parallel as much as possible, which seems to be very ideal. But it is not easy to do this in project management practices, and you need a unified value of the entire team, and follow a work principle, that is, "always do what is doing".
The principle of "always do what is the most doing" here includes:
Dependency priority
2. Interface is preferred
3. Key path priority
4. Guangsheng priority
1.1.1. Dependency priority
Everyone knows that the key to work is to let each task do not depend until, so that each task can be done separately. However, there is often a variety of dependencies between tasks, depending on the implementation of the task into serial lines.
In the project, everyone's daily tasks often often, some of which are independent, and it is done early or later, it has no effect on others. Some tasks are dependent, if they don't finish, others can't complete. The principle of relying on the priority is to ask the members of the entire team to establish a conscious: always give priority to others' dependencies. One does not seem to have an effect; but if the entire team can truly pursue this principle and fall into the implementation of the implementation, then the coordination work of the entire team will be greatly reduced, and the entire team will continue to be more High work efficiency.
Case: Tester A waiting for demander B to provide a functional checklist F tide for a module. So f is a dependency of A to B. If the other of the B hand only affects your work, it is time that the demand staff B should give priority to the test staff A unable to work.
There is also another problem here, that is, everyone should be clear, if their own work, in addition to the coordination of the other party to solve the external dependence, I should understand that I should never be so dry. Waiting. And to handover other work, once dependent is released, then switch back to the original work.
1.1.2. Interface priority
Although the term "interface" makes it easier to understand the object-oriented programmers, this concept is promoted. "Interface" is used to express two partial combined handover, which may be code, or a document.
The principle of interface priority is to emphasize that the dependence on both parties will be clear and stable as much as possible. With an interface, the two parties can work in parallel with the interface. The interface is preferred to depend on special forms.
Interface priority requirements:
A. Dedicated to the interface as soon as possible
B. Carefully set the interface, the provider, and the user jointly determine the interface, and required the interface review
C. Interface changes to be controlled
From the actual project, it is too late to develop around the interface, and the phenomenon of rework is very prominent. A typical scenario is to wait until the project is integrated to find that the interface does not meet the needs, and this time the modification of the interface is often hurting the bone, the cost of reconstruction is large.
In addition, it is necessary to develop an interface to experience a lot of experience, and it is necessary to fully consider the change in the future. However, one of the actual projects often see is that the user of the interface often does not care about the specific details of the interface. The interface is set by the provider, and the integration phase, the interface is used to propose the interface that cannot meet your needs. And require the interface provider to change. Everyone should be very clear. At this time, the interface change not only requires the interface provider to modify the internal logic code, but a greater hidden danger is a whole body, and the change in an interface will cause code adjustment of all interface users. The author compares the implementation of the "Interface Review" system, and the export must be required to participate in the participation, clarify the needs and form of the interface. This is often capable of forming a good atmosphere:
First, the user of the interface participated in the interface review, helping him carefully consider whether their needs can satisfy.
Second, the form of interface is reviewed by the user, and the user should be responsible for the change of the future interface. This can cause the user of the interface to fully clarify its own needs in advance.
Third, the communication between the two sides is communicated, which is clearly related to the coordination processing in the future work.
1.1.3. Key path priority
Readers who have learned the picture know the concept of key paths, and the project management theory also tells us that the delay of any activities on key paths will postpone the entire project.
Key path requirements:
1. The project management team needs to know what work is a key path.
2. The project management team must develop a feasible plan to ensure that these key paths are completed.
1.1.4. Guangsheng priority
The breadth is also a concept in the chart, indicating that it is prioritized from a broad scale when the tree search. Here is along the integration of the priority to decompose tasks, not processing tasks.
Considering the parallel processing efficiency of the entire team task, if the task A can be decomposed into sub tasks A1, A2, A3, and the subtask A1 may continue to decompose into subtranes A11, A12. Each member in the team should do this:
First, consider the decomposition of task A into several subtasities A1, A2, A3.
Second, consider how to deal with task A1, find that A1 can be decomposed into two subtasities A11, A12. OK, do not drill in the process A11 or A12, but processes A2. It is found that A2 only needs to handle sub tasks A21. Next, the A3 is processed, and the A3 is decomposed into A31 and A32.
Third, at this time, A11 can be processed, processing A11 to process A12, playing in processing A21, etc.
Why do you do this? I think this is what everyone wants to know. The reason is as follows:
1. Cultivate everyone's big concept, don't rush to drill into a detail problem
2. Always do it first, such as division
3. First divide the task from the intensity, which is conducive to switching to another task when a sub-task encounters a dependency.
Concern resources share. The task has been in the broad score. When there is a new resource, it is easy to assign its decomposition subtuto to ensure that the task is always in parallel.
