Q: Q & A about Agile Software Development

Q: Q & A about Agile Software Development

Q: How can agile development be integrated into the cmme currently being implemented?
A: First of all, I would like to explain why CMMS is proposed based on CMM. Barry Boehm elaborated on this in his new book balancing agility and discipline: A Guide for the perplexed. In general, there are two main reasons: 1. Significant changes have been made to the components in CMM that may easily lead to bureaucracy; 2. include risk-driven as a core content into the cmme framework, so that the cmme framework can smoothly develop some agile processes. However, the agility of CMMs is hard to portray, because as a reference model for process improvement, it is closer to a set of requirements rather than a set of practices. That is to say, we can only portray the processes developed to meet these needs. Generally, the requirement constraints of CMMs are less than those of SW-CMM. More agility can be achieved if you want to explain the demand from a broader perspective. However, if a fully conservative approach is adopted during implementation and the heavyweight maturity evaluation method provided by the SW-CMM is used, the resulting cmme compatibility process will be heavy and very planned-driven. Therefore, I think agility can be smoothly integrated into the cmme model. If there is a problem, I think it is more about the agile exclusion of implementers than others.

Q: How does the agile development process cope with various predictable and unpredictable risks? For example, personnel flow and change, project cycle change, customer representative change, and other risks.
A: risks such as personnel flow and changes, project cycle changes, and changes of customer representatives are inevitable for any software development project. A good process should minimize the losses caused by these risks. Agile Methods try to create a very comfortable development environment, which is a typical craftsmanship culture. In this culture, people are proud of their own skills. They are proud to develop high-quality software and constantly strive to improve their skills. In such an environment, the flow of personnel and the frequency of changes are greatly reduced. In addition, the emphasis on face-to-face communication, Pair programming, and high-quality code and documentation in Agile Methods also greatly reduces the risks caused by personnel changes.
I think there is no more effective way to deal with changes in the project cycle than rapid and short iterations. It is these fast Short iterations that bring us a lot of feedback information, so that we have a comprehensive, in-depth and real understanding of the project situation. With this foundation, we are in a very favorable position in minimizing the risk of project cycle changes. Fast short iteration is an important feature of agility. What is agility? Agility is: "short cycles that are test-driven and feedback-driven, yielding constant improvements." I don't want to talk about the changes made by customer representatives. Because the risks brought by changes on customer representatives are the same for Agile Methods and plan-driven methods. If there is no good customer representative, it must be a failed project.

Q: Is the agile development process applicable to large-scale and complex application systems? Some systems with simple architecture and small code size can be improved through continuous code refactoring. However, for systems with complicated architecture, as the customer's business expands, the data capacity increases or the network access volume increases, the original core architecture design cannot meet users' needs, these important architectures play an important role in the system's core services and are difficult to be changed. In this case, the cost for changes is high, so it is necessary to focus on the early expectations of such changes. In addition, the complexity and scale of such software will lead to high cost and error-prone strict code refactoring.
A: First, we need to reach a consensus on what is a large and complex application system. One of the largest projects used by the scrum method is a medical image information system, with a total of 800 people. The largest project of the XP method application is an enterprise resource comprehensive management system, with a total of 50 people. Of course, when the number of people increases, some flexible practices must be adopted (otherwise, they will not be agile ). I think this should be the case for architecture issues. If it is a relatively mature field, you can learn from many existing experiences in the industry, especially some related models. This is very important. Otherwise, we will take a lot of detours and pay a lot of costs. For example, in the field of concurrency and distributed communication, a qualified system engineer must understand and understand all the modes in pattern-oriented software architecture and Volume 2. However, this only provides you with a direction to prevent you from making major mistakes. These patterns provide guidance for code refactoring and system evolution. If you do not understand these models, it is basically impossible to make an excellent architecture. After learning about these models, can we pile them up in the first place to form an architecture that can adapt to the future? Of course not. There are two ways to build an architecture that can adapt to the future: one is a System Architect that requires genius, and the other is guided by the domain model, the TDD and refactoring methods are constantly and gradually modified. Obviously, the 2nd method is a practical method.

Q: Does the agile development process support the creation of reusable products? For an engineering type, reusable products are extremely important for cost saving and efficiency improvement!
A: reusability has always been a hot topic in the software field. Generally, there is mechanism-Level Reuse, such as common function libraries or class libraries, and application domain logic reuse, such as application frameworks related to various fields. The first method of reuse is relatively easy, but the benefits are relatively low. The second method of reuse can bring us the greatest benefit, but it is very difficult. This is precisely because of this, there was a saying in the industry that "reuse myth. Countless practices have shown that to get a relatively available domain framework, you must be tempered by at least three practices in homogeneous domains. In addition, the number of failures is far greater than that of success. However, a project that tries to set reusability as the target at the beginning has basically not been successful (such a framework generally has the following characteristics: a simple task, but it becomes very complicated after the framework is used .). Therefore, the industry agrees that a project-specific and simple framework should be set up for your development. In the beginning, do not consider reusability, but focus on the clarity and simplicity of the system. In another homogeneous project, this framework is modified through reconstruction and evolution to make it more universal. After going through multiple projects, you may have a reusable framework. That is to say, we should focus on creating things that are easy to evolve into reusable frameworks. This stuff should have two features: 1. For specific problems; 2. Very simple and clear. The agile method pays great attention to the formation of such a framework, but does not deliberately do so. Its idea is to evolve it in constant loops and iterations. In this loop iteration, the agile method uses the dry (don't repeat yourself) Principle to gradually build the foundation for large-scale reuse.

Q: Is the quality assurance mechanism of the agile development process sufficient for developing software with strict security and reliability requirements? The quality control mechanisms supported by agile software development processes with strict security requirements in the power and telecommunications systems do not seem to prove that the user's software is safe. Are other measures required?
A: First of all, security and reliability belong to the scope of user requirements. In Agile Methods, customer satisfaction is very important, from the ideological basis of process methods alone, there is no way to focus more on customer satisfaction than agile methods. Secondly, security and reliability are not described in some rules and regulations. practices that empty list some terms of security and reliability in the system solution, it is of no use to ensure the reliability and security of the system. The only way to ensure security and reliability is to test and continuously test the system as it evolves. Write the user's security and reliability requirements through test cases to frequently verify whether the system can pass these tests. If the test fails, the integration fails. I wonder how everyone is doing to ensure system reliability and security?

Q: The current project and department organizational structure, internal customers and external customers are far away from developers. How can they reach zero distance? Although a single customer and developer working together can effectively track demand changes and respond to demand changes in a timely manner, if the system faces different customers, how can we avoid the singularity and uniqueness of some demand changes during development?
A: No matter whether the project uses any method, it has the same requirement for the customer, that is, this customer must be a crack (collaborative, representative, authorized, committed, knowledgeable) customer. Given the various environments we are currently in, it is unlikely that a full range of crack and on-site customers will be possible. However, a person who can take the role of a qualified customer and frequently participate in project development is required for project success. In addition, changes in response to requirements are the strengths of agile methods. If these changes are really needed by the customer, why should they be avoided? At this point, we should take advantage of these changes.

Q: How to Avoid developers from using the document-based excuse to write less documents?
A: People in the agile culture are proud to complete their tasks with high quality. If writing a document is part of the completion of tasks with high quality, they will certainly write this document with high quality. Otherwise, what is the purpose of writing a document that only meets the format? Agile practices are practices that can truly provide developer skills. agile methods are strongly opposed to those procedures that are only designed to prevent developers from being "lazy.

Q: How can I grasp this issue when developers frequently communicate with each other face to face, resulting in frequent conferences?
A: face-to-face communication is not a meeting. Communicate as long as you feel you need it.

Q: How can we grasp the granularity of the simple design? If we emphasize the simple design of the preliminary architecture, how can we deal with the short time after the software is put into operation, as the customer's business expands, the data capacity increases or the network access volume increases, the original design cannot meet the user's needs?
A: see the previous architecture answer. First, you need to have a wealth of experience and knowledge. These things can provide you with an architectural evolution direction. Without these things, it is basically impossible to find the right direction for the first time. With this in mind, TDD + refactoring continues to evolve.

Q: How can a simple design ensure the implementation of test-driven development? If the design is not detailed enough, how do I write test cases and test code for interfaces?
A: First of all, it is not a simple design that ensures the implementation of test-driven development, but a test-driven development that can help you get a simple design. Second, there are first test cases before there are design and interfaces.

Q: The agile document describes how to create an acceptance test as an important means to design the system architecture and a function demonstration for end users, however, in essence, it is still a simulated integration test of system features, which does not fully represent the actual system. Is this acceptance test reliable from the traditional acceptance test?
A: What does the traditional acceptance test mean? Is a test conducted by a tester? Generally, the acceptance test referred to in Agile Methods (especially XP) is written by QA and customer representatives. If it passes, it indicates that the customer needs are met. I don't think any other method is more reliable than this method.

Q: In the test-driven development example, a simple design is also started, and then a test case is written to form another design. Do I need to design it at the beginning? To what extent should we reach? Is it possible to drive the design simply by testing without design? In my understanding, test-driven development is more suitable for the detailed design stage. Is test-driven development suitable for architecture design? In the test-driven development example in this article, the software requirements seem to come from the imagination of individuals as they wish. Is the generation method of such test cases lacking systematic and complete? Or is it necessary to strictly design the production of test cases for test-driven development?
A: What is design? This is an issue that requires consensus first. The core of TDD is continuous design and constant attention to design quality, which is based on frequent and real feedback, rather than hypothetical ideas. It is "tuned to today and got Ed to strike at tomorrow. it is not a design that draws Several UML diagrams through some ideas. The design should be verifiable and should be continuously corrected through feedback. Design verification is carried out through test cases. The test case can be a customer requirement, which is an acceptance test. It can also be the internal implementation requirements of the Development Team, which is the internal test of the development team (usually also a unit test ). The test case should come from the customer, which is beyond doubt. A test activity is a risk-driven activity. After the test investment reaches a certain level, its effect will quickly decrease. For "SYSTEMIC", "completeness", and "strict", I don't know what it means? Can you give us a detailed description of the system, completeness, and rigor of your needs ".

Q: The procedure for starting agile design may also be the simplest and inflexible. The team will not seize the opportunity to apply agile design principles to improve the design until it needs to change. There are several prerequisites that the team should be sensitive to poor design to seize the opportunity to improve the design; the team should have enough time to improve the design. If these two prerequisites are not true, what if agile design is performed?
A: How can I be flexible? Make things simple and simple things have the most flexibility! Kent Beck defines what is simple in extreme programming. In a word, it is: "clean code that works." If these premises are not true, no design can be done. Many agile practices aim to help us cultivate this sensitivity through learning and practice.

Q: How can we grasp the "progress" in the test-driven development process, that is, how can we grasp the granularity of each test case? Large granularity can accelerate development, but some bugs may be missed. A small granularity may affect the development progress. What are the test cases in the test-driven development process? Is it a unit test? Or integration testing with a large granularity? If it is a unit test, at least it should not be a unit test in the traditional sense. In this case, is the unit test a black box test or a white box test, or is it neither a black box nor a white box? How can we understand that test-driven development can improve the design? What is the theoretical basis? Can I explain this question from the black box testing theory?
A: granularity is an independent and verifiable thing. Kent Beck gave a detailed description of the pace of TDD development in his book test-driven development. Writing and testing does not affect the development progress. The more time-consuming the development, the more. I think everyone has had this experience: "It takes 20 minutes to complete a function, and then it takes 2 hours or more to debug it ." In TDD, there are only two types of test cases: customer-oriented acceptance test cases and internal development team-oriented test cases (also known as unit testing ). Why should we be so clear about black boxes and white boxes? The idea that test-driven development can improve design is elaborated in test-driven development. This has nothing to do with the black box test. TDD is a design method, a real design method with feedback and verification.

Q: The beauty of software: for software designers, an internal structure that is simply and intuitively separated and with minimum internal coupling is beautiful. Beautiful systems are flexible and easy to understand. Building and maintaining them is a pleasure. In the software field, how should we be aesthetic? The concept of "flexible and easy-to-understand" involves many subjectivity. For a specific software aesthetic, the comments of different people are different. Of course, masters are more accurate, however, there are too few masters. Are there any objective and quantifiable indicators? So that people without much experience can also use this as a guide to improve the software to make it develop in the United States?
A: Agile Software Development: principles, practices, and patterns provides many principles and practices for reference.

Q: Is eXtreme Programming only applicable to lightweight teams and projects, or for heavyweight teams and projects? Is there any conflict with CMM? What are the feasibility of implementing eXtreme Programming (such as test-driven development) and what are not feasible (such as Pair Programming )? How to use it in heavyweight teams and projects?
A: Extreme Programming for small projects (10 ~ 20 people. For large projects, copying the practice in XP will certainly lead to problems. Therefore, it is necessary to make corrections based on actual conditions to a certain extent. There are many discussions and articles about whether there are any conflicts with CMM, which are basically benevolent and wise. However, the goal of improving the development quality is certainly not contradictory. In fact, there are also many different opinions on how to implement CMM. There are many cases in which different evaluators give different conclusions. In fact, there is no need to copy XP in an all-round way. I think we can introduce a small part of practices without changing the existing operation process of the team. TDD should be the first choice.

Q: although the five important principles "single responsibility principle, open-closed principle, liskov replacement principle, dependency inversion principle, and interface isolation principle" are expressed here as the principle of object-oriented design, but in fact they are only special examples of the principles that have always existed in software engineering. So what is the general principle that has always existed in software engineering? What are there? How to Use structured programming in embedded development where a large number of applications exist? The "use for use" design principle will lead to unnecessary complexity. The design principle is a summary of experience and must be a solution to a problem. So, in programming, what are the issues that need to be considered at all times?
A: First of all, the more general the principle is, the less practical it is. Only the principles specific to context and force have more practical significance, this is also an important reason why the model is widely recognized in disseminating excellent design experience. If you have to give a general principle, I think one sentence Grady booch once said can be used as a reference: "the entire history of SW enginerering is one of rising levels of dynamic action. "Whether you use structured programming or object-oriented programming, understanding a variety of programming specifications will certainly benefit your development. The design principles and patterns can only guide you. The most important thing is to keep the (Design) code simple. The question of thinking at all times is whether the Code clearly expresses my intention, that is to say, intentional programming is required, and "Keep it dry, shy, and tell the other guy.