Onlookers-casual projects (3)

One element of rapid software development is daily build and smoke testing. The premise of its introduction is that the granularity of functional points should be as detailed as possible, and everyone in the team should strictly abide by the discipline to form the habit of daily completion. A functional point can be basically completed only when it passes the smoke test. One reason for the project delay is that the task we promise is not reliable or we think it is done, and put a lot of missed work in the later stage of the project.


The shorter or more tight the project schedule, the more deviations we can tolerate, and the more detailed the task granularity. It is best to have visible project output every day. That is, even if you receive a task of one week, you need to divide the task into one day. Most of the time, our status is that when we receive a task for a week, there is no concept about how many tasks should be completed today.


When a task with a large granularity is received, it is a process of project and time management by individual to complete the task by target. This task is a project, the resource is yourself, the progress plan is what to do every day, the amount to complete, and the verification is self-testing. Task Management at a large granularity is poor because of insufficient understanding of Self-skills and productivity, and lack of awareness of time management.


Software Quality Assurance does not rely on tests in the later stages, but on the early stages of training, standardized formulation and learning, and the need and architecture. Perfect developer skills.


All outputs in the software development process must be managed, including process documents and Source code . In addition, after the management, the configuration items are controlled, and the changes must be recorded and analyzed and confirmed by certain procedures, even if the entire change process is simple.


Demand priority-the most valuable thing for users with limited time and resources.


When directly estimating based on business functions or user needs, we need to note that estimation is based on the development framework and architecture that is basically stable and mature. If the entire development model and framework have not been confirmed or passed the historical project verification during the estimation, there is a high degree of uncertainty and risk in the estimation. In this case, we must consider estimation of non-functional requirements and estimation of reusable functional components.