Agile Software Development-methodology elements and principles

The methodology is methodology in English. The programming methodology should refer to a complete set of methods, processes, rules, practices, and technologies for software development. However, the methodology we generally mention focuses on projects, processes, and personnel. The methodology proposed by Alistair Cockburn, author of agile software development, has the following elements: roles, personalities, skills, teams, technologies, activities, processes, products, milestones, standards, quality, tools, and team values. Their relationships can be expressed in a diagram:

For the differences between methods and methodologies, we should note that the methods are more specific to the handling methods and steps of specific things. The methodology explores the combination and collaboration of methods that a team should adopt when dealing with a large process and facing a specific scenario.

 

Methodology can be enlightening, participatory, and standardized. For a growing knowledge system, part of the methodology is transformed from inspiration to standardization and becomes a standard solution to typical problems. This is similar to our knowledge management. When our invisible knowledge is converted to explicit, We can standardize it into a specific process, methodology and process are good carriers of experience.

 

The Design of methodology is closely related to the characteristics of the project, including the Personnel, project scale, features of R & D products, quality requirements, and working models of R & D teams. Methodology is a complete set. When faced with a specific project, we need to define a software development lifecycle model and software process that matches the project features. Therefore, this process involves a series of issues such as the weight, size, scale, accuracy, visibility, and stability of the methodology.

 

In the methodology design process, we must take into account the changes of people, cross-Project changes, changes in the project cycle and the impact of technological changes on the methodology. During the initial design methodology, the common mistake we make is that all projects adopt the same size methodology, regardless of the weight and flexibility of the methodology. They are designed based on their own opinions, or use the best performance practices that have not been proven. Therefore, here we focus on analyzing and learning the seven principles that can be used to design and evaluate methodologies:

 

1. Face-to-face interaction is the lowest cost, the most efficient and fast way of information exchange

 

Here, we should note that the number of communication channels increases exponentially as the team grows. Therefore, after the scale-up, we should emphasize the division of development teams, or avoid unnecessary scale-up by improving personal skills. The process of communication is best to combine whiteboard communication, and graphics are often easier for others to understand. The communication results must be recorded, either recorded or documented.

 

2. The consequence of overweight in methodology is a high price

 

Overweight methodology can be seen as a kind of satisfaction for the manager's vanity, or it can make the team look more beautiful, or reflect the decline in the manager's trust in the team and personnel, they want to see more intermediate output. The focus of a project's operation is not to satisfy the process, but to achieve the goal. It is useless in the gorgeous process to achieve the goal of the project.

 

The focus of team members should always be on product development and product quality. The weight of methodology must be reflected in the contribution to specific project objectives. The heavier the methodology, the harder it is for us to solve complicated problems. A small team is often able to solve larger problems in a lighter way.

 

3. a larger team needs more methods.

 

For a small team of 4-6 people, it is feasible for them to sit in the office with a whiteboard, so that when they create and communicate collaborative games, there will be information flow in the conversation. However, as the team size increases, communication, coordination, interference, overlap, and repetition all need to be considered. We must develop other forms of coordination and communication to address these issues.

 

4. The higher the project risk level, the higher the formal requirements for methodology

 

For the development of large-scale software systems such as aerospace aircraft, we must have a strict and highly formal methodology definition. This kind of project should not have a slight error. For the development of small and medium-sized information systems, the goal of the project is not only quality, but also progress and cost. We must weigh these elements.

 

Therefore, if we simply copy the development methodology of large-scale software engineering to a small agile team, it is obviously not worth the candle. We have more lightweight methods such as communication and collaboration to ensure quality and avoid mistakes.

 

5. Increase feedback and communication to reduce the need for intermediate artifacts

 

The final product quality and user satisfaction with the product are a key factor to determine whether the project is successful. any intermediate component is more to meet the internal management and supervision needs of the project team. The less trust we trust each other, the more intermediate outputs we need.

 

It is meaningless to measure the progress of the project by using the completion progress of intermediate artifacts. Therefore, the development mode of large waterfall in the rapid development team must be replaced by the iterative incremental mode. This fast iterative delivery can reduce risks and make the progress meaningful.

 

6. Discipline, skills and understanding vs processes, Forms and Documents

 

First, the process is not a discipline, but a process that allows people to observe norms and instructions, and discipline requires people to choose a consistent approach to work. In this process, discipline is more effective. Second, do not confuse documents and understanding. There is still a lot of tacit knowledge in the software development process. documents can only express a small part of this knowledge, but more need to be understood after communication. Finally, the form is always superficial. Developing a UML specification and learning UML does not mean that you have enough skills for object-oriented design.

 

Lightweight methodologies focus more on understanding, discipline, and skills, rather than documents, processes, and forms. Therefore, they apply to exploratory situations. Heavyweight methodologies focus on documents, processes, and forms. They are designed to allow people to work in environments that do not need to adapt to changes, but to optimize costs.

 

7. Non-bottleneck activities require efficiency

 

Constraint theory is often used in key chain project management. The key point of key chain project management is to explain that the progress of the project depends on the constraints of the project's core and bottleneck resources. In order to ensure the project progress, we need to consider how to make the bottleneck resources operate more efficiently. To do this, we need to make non-bottleneck resources do all kinds of work as early as possible, to ensure that the input to the bottleneck resources have a higher quality, reduce the rework of the bottleneck resources.

 

From non-bottleneck activities, we need to consider how to use our idle non-bottleneck resources when project progress is constrained by bottleneck resources. What we fear most about the progress of a project is that the bottleneck makes more people in the team seem idle.

Article Referenced from: