New methodology
Hu Jian (reprinted from Ji Ji China) September 15, 2003
The software development method (Agile) (also known as "lightweight", lightweight) has been used in the process of correcting bureaucrats, and the license has aroused autonomous adjustment. Very big interest. In this article, I will explore the rationality of the agile method, and the heavy point is not in its "light weight", but their adaptability (adaptive) nature and people's priority I also briefly introduced some agile methods and give further reference materials. In addition, I also put forward some factors that you need to consider when you decide whether you want to leave this just walking. None, to the heavy, and then to agile majority software development is still a chaotic activity, that is, a typical "edge write change" (Code and fix). The design process is full of short-term, instant decisions, and no complete planning This model is actually used for small system development, but when the system becomes more complicated, it is more difficult to join new features. At the same time, there is more and more wrong failures, more and more difficult to exclude. A typical The sign is that there is a long test phase after the system function is complete, sometimes even distorted, thus causing a serious impact on the completion of the project.
We have been using this model for a long time, but we actually have another option, that is, "Methodology]. These methods have strict and detailed provisions of the development process, in order to make software development more There is a predetermined and efficiency, this idea is to draw on practices in other engineering fields - so I refer to Engineering Methodologies.
The engineering method has existed for a long time, but there is no remarkable success, and even how people have not attracted people. The criticism that is most common to these methods is the bureaucratic cumbersome, if it comes to it, it needs to do too much thing, and delay the entire development process.
As a rebellion to these methods, a new type of method has occurred in the past few years. They are called "lightweight) methods in a period of time, but now there is a widely accepted name, Agile Methodologies. For many people, this type of method is to attract the rebellion of bureaucratic processes for the buddy. They have reached a balance in the process and too cumbersome process, so that it can get more satisfactory results with many steps.
There are some significant differences between agile models and engineering type. One of the obvious differences is reflected in the document. Agile type is not very directed, for a task, they usually only require as few documents as possible. From many ways, they are more like "code-oriented]. In fact, they think that the most fundamental document should be source code.
However, I don't think that the document is characterized by the fundamental point of the agile method. Document reduction is just a representation, which actually reflects two deeper features:
Agile type method is "adaptive" rather than "foresee". Engineering methods try to make a detailed plan for a long time span, and then develop according to the plan. This type of method is not working well in general, but (demand, environment, etc.) is not too spiritual. Therefore, they are essentially refused to change. And the agile method is welcome. In fact, their purpose is to become the process of adapting changes, and even allow changing themselves to make changes. Agile method is "People-Oriented) rather than" process-oriented). The goal of engineering methods is to define a process, no matter who works. The agile method is considered that there is no process that can replace the skills of the development group, and the role of the process is to support the work of the development group. In the following sections, I will explore these differences in detail so that you can understand what adaptability and people-centered processes, their benefits and shortcomings, and whether you should use them as a software developer or user. Preset and adaptability The basic idea of designing and construction of separate open software development a formal way is generally from other engineering, such as civil engineering, reference. In this kind of engineering practice, the design plan is usually very emphasized before practical construction. Engineers first have to draw a series of drawings, which accurately illustrate what is to build and how to build (including partial and overall). Many design decisions, if how to deal with a bridge, will be made when drawing paper. Then These drawings are distributed to another group of people, usually another company, to build. This way is actually assumed that the construction process will come as drawing. Of course, there will be some problems in construction, but these are times need.
The drawings are actually a detailed construction plan that illustrates the various parts that must be completed in a project, and how to put these parts into whole. Such a plan can further set out various tasks that need to be completed, as well as the dependencies between these tasks. In this way, production schedules and project budgets can be made more reasonably. This model actually specifies how the builder is (construction), which implies builders who do not have to be high intelligent, although they may have a very superb hand.
Here, we have seen two very different activities. Design is difficult to foresee, and need expensive creative personnel, construction is easy to preset. After we have a design, we can plan to plan. After the construction plan, we can make a very predictable. In civil engineering, construction is much larger than the design and planning in terms of funding or in time.
Therefore, the way the software engineering method is like this: we want the foreseeable production schedule to use the low skills. To achieve this, we must separate the design and construction. Therefore, in software development, we have to make such a design, making the planning, and the construction will be straightforward.
So what form should I use? For many people, this is a design "logo symbol" (notation), if the UML needs to be borne. If we can use UML to make all major technical decisions, then use UML to do construction plan, then put It is scheduled to give programmers to encode, namely the construction activities.
But there is a key issue here. Can you make such a design make it possible to make the code become a construction activity? If it is, then do such a dry cost is sufficient to make this way worthwhile?
This puts a few questions. The first question is that there are many difficulties that enable a design that uses a similar UML to give the programmer to directly encode. The design that is used as the language like UML looks very beautiful on the paper, while the actual programming may find a serious defect. The model used by civil engineers is based on multi-year engineering practice and is crystallized in the engineering chapter. Furthermore, some key parts, such as stress, are based on solid mathematical analysis. In software design, we can only ask the experts to review the UML drawings. This is of course very helpful, but often some design errors can only find when coding and testing. Even skilled designers, I think I belong to this column, often feels unexpectedly in the event that occurs in the process of designing software. Another problem is the cost comparison. When building a bridge, the design costs generally account for 10% of the entire project, about 90% of the remaining 90% is the construction cost. In software development, the time occupied by the encoding is generally much less. McConnell pointed out that encoding and unit testing only 15% in large projects, this is almost in the proportion of bridge projects. Even if all test work is counted as part of the construction, the design is still 50%. This puts forward an important issue, that is, the software design is nature compared to the design of other process fields.
These problems have led to Jack Reeves to propose source code should also be a design document, and the construction should be compiled and link. Indeed, anything you think that belongs to build should be automated.
These discussions have led to some important conclusions:
In software development, the specific construction cost is very low, and several negligible. All jobs in software development are designed, so you need to have a creative talent. The creative process is not easy to plan, so predictability is an impossible goal. We should maintain a sufficient alert to the practice of software development using traditional engineering models because they are different types of activities that require different processes. The unpredictability of demand has such a situation in each of the problems I participated, and the developer runs complaining that "the problem of this project is always changing." What surprised me is that everyone is surprised. In fact, in the construction of commercial software systems, demand changes are normal, the problem is how we process it.
One way is to see demand changes as the result of the demand engineering (Requirements Engineering), which is not good. In general, demand projects (or analyzes the demand analysis] Before the construction of the software, it has been obtained. Fully understand the screen to be built, then obtain customer approval issuing, and establish a set of regulations to limit demand changes.
One problem with this method is to accurately obtain all the needs, especially when the developer does not provide some cost information. For example, when you buy a car, you want to install a sunroem on your car, but the salesman can't tell you that you have to add 10 yuan in the car, or 10,000 yuan. If you don't know this, how can you decide if you are willing to spend money on the car and add a sunroof.
It is not easy to estimate the cost of software development, which has a variety of reasons. Part of the reason is that software development is a design activity, so it is difficult to accurately plan. Part of the reason is that the system's "basic material" changes very fast. Part of the reason is that development activities have greatly dependent on project participants, and individuals are difficult to predict and quantify.
The software's "in touchless" is also a reason. Before the system is built, it is sometimes difficult to judge the specific value of a function. That is to say, only when you use the system in realively, you can know which features are useful, which is not used.
This result is quite ironic, that is, people expect demands should be variable. After all, the software should be "soft". Therefore, demand is not only variable, it is simply changed. To make customers fix the need to spend a lot of strength, especially when they "participate in" software development and "know" how easy is to modify. However, even if you can fix all the needs, you don't mean that your development is sunny, you may still be in dim. Under today's economic situation, business factors that determine and promote software system feature are quickly changing. Now a good function is better than six months. The business world will not stop due to the need for your system, and many changes in the business world are completely unpredictable. If someone does not admit this, or he is lying, or he has blended it into a millionaire.
Everything in software development depends on the system requirements. If the demand is not fixed, you cannot develop a predictable plan.
Is it impossible to predictability? Generally, it is impossible. Of course, there are some software development projects, predictivity is possible. Software development projects like NASA's space shuttle should be such an example. It requires a lot of meetings, sufficient time, huge team, as well as stable needs. After all, these are the project of the space shuttle. But I don't think that the general commercial software is developed such a system, so you need a different development process.
If you can't follow a predictability method, you can support, then this is very dangerous. Typically, the creator of a regular method is not very good at (or music) gives the boundary condition of its method. In other words, when these boundary conditions are not satisfied, the method is not applicable. Many methodologists hope that their methods can be The four seas are all accurate, so they don't understand, nor to announce the boundary conditions of their methods. This leads to people in the wrong situation, for example, using a foresee in unpredictable environments. Sex method.
The use of anticipation methods has a strong temptation, as the fores seeking is a very desirable feature. However, when you can't reach your prediege, you believe you, this will lead to such a situation: You can develop a plan very early, but you can't properly deal with the plaque. You see reality and plan slowly deviation, and you can hold the plan for a long time, it is still valid. But when you have accumulated enough to accumulate enough, your plan collapses, which is usually very painful.
Therefore, in an unpredictable environment is not a predictive method. Recognizing this is a big impact. It means that we have used many of the control projects of the project, and many modes of processing customer relationships will not be correct. The predictability is indeed a lot of benefits, and we are difficult to give up these benefits. Like a lot of problems, the most difficult point is to recognize the existence of these issues.
However, waive prediction does not mean back to uncontrollable chaos. What you need is another process, which allows you to control unssetbility, this is the "adaptability" role.
The control of the unfair process - iteration, how do we deal with an unpredictable world? The most important thing is to be the most difficult thing to know that we are in development in development, which requires an honest feedback mechanism to tell us accurately.
The key point of this mechanism is "Itemive] development method. This is not a new idea, iterative development methods have been there for a long time, but the name is different, such as" incremental], "progressive "(EVOLUTIONARY)," Staged], "Spiral], etc. The main point of iterative development is often the final system of the final system, which enables the system to realize the required system. Function. Although it is in full, the implementation must be faithful to the final system requirements, they must be a fully integrated and test product. The reason for this is: Nothing is more integrated, tested systems As a result of a project, it can hide all the defects, and all issues can be exposed when the user can use it when the user is actually sitting in the system. These issues may be source code defects (bugs), or it is possible to understand the needs.
Although iterative development can also be used in visibility environments, it is basically used as an "adaptive] process because the adaptive process can deal with demand changes in time. Demand changes make long-term plans are unstable, a stable The plan can only be short-term, which is usually an "iteration period" (Iteration). Iterative development allows each iterative cycle to provide a solid foundation for the following development plan.
An important issue for iterative development is how long it is required. Different people have different answers, XP (extreme programming) suggests one to three weeks, Scrum recommends a month, Crystal is longer. However, the general trend is to make every cycle as short as possible. So you You can get frequent feedback, which can constantly you know what you are.
Adaptive customers This type of adaptive process needs to establish a new type of relationship with customers, especially when the development is carried out by a signing company. Because when hiring a contract company is developing, most customers willing to order a fixed price contract. They told the developer that they need the features, tenders, and contract, and then the rest is the development partner to build the system.
The fixed price contract requires a stable demand, that is, a predictable process. Adaptive processes and unstable needs mean that you can't do this fixed price contract. Put a fixed price mode will result in a painful ending. The worst is that customers will be equally harmed with software developers, and the customers will not want a software. Even if they have not paid a developer, they still lose a lot. Indeed, they lose more than to pay for the developer (they pay this money, if the business value of this software is small?)
Therefore, in the case where the predictability process cannot be used, the fixed price contract is dangerous to both parties. This means that customers must change a way of working.
This is not to say, you can't fix a budget for your software. This actually means you can't fix time, price and scope. Usually a agile method is fixed time and price, and the range can be controlled.
During the adaptability, the customer can actually perform deeply and fine control of the software development process. In each iteration phase, they can check the development schedule and change the software development direction. This leads to a closer relationship with software developers, or true business partnerships. But not every customer, not every developer is ready to accept this degree of intervention, but if the adaptability process can work well, this level of cooperation is basic requirement.
This development method can bring a lot of benefits to customers. First, this development of "response" is good. A available, although it is a small system to be put into use as soon as possible. Customers can change some system functions in time according to actual usage, and changed demand. In this way, it is possible to more truly reflect the actual state of the project. The predictable process is that the quality of the project is measured according to the consistency of the plan. When actual conditions are out of schedule, it is difficult to mention. The general result is a large landslide on the post-expiration schedule. In an agile type project, the plan is reviewed every cycle. If there is anything bad thing, it will also be discovered earlier, so there will still be a time to solve. Indeed, this risk control is a key advantage of iterative development. Agile development is more step, because its cycle is very short, and it also regards these changes as an opportunity.
This is important for definition what is a successful project. The success of the predictive item is determined by it well in accordance with planned execution. A project is successful if it is completed within the prescribed time and budget. This measure is meaningless for the agile environment. For agile project practitioners, the most important thing is business value - whether the value of the customer's software is greater than their investment. A good foresight project is based on the plan, and a good agile project will build a better software as the original plan is not only the same.
It is not easy to put people in the first place to implement an adaptive process, especially it requires a set of high-efficiency developers. Efficient is embodied in high-quality individuals, and is also reflected in the way to work harmonize. Here is an interesting harmony: not just a team of adaptive processes, and most excellent developers are willing to adopt an adaptive process.
One of the targets of the compatible program plug-in traditional regular method is to develop such a process such that a project participating person is alternative. Such a process will be regarded as a resource that has different roles, such as an analyst, some programmers, testers and a management. Individuals are not important, only roles are important. In this way, when you plan a project, you don't care which analysis you can get, which testers, you just need to care how much you can get, know how the resource number will affect your plan.
But this has a key question: Does participating in software development is alternative? An important feature of the agile method is to reject this view.
Perhaps the most clearly opposed this point of view of the actair cockburn. In his paper "Software Development, people are non-linear, first-order components", and he pointed out that the predictable software development process requires "part" behavior is also foreseen. Sexual. However, people are not a predictable components. Further, his research on software projects has led to the following conclusions: people are the most important factors in software development.
In the title of this article, I call people as "components". (Traditional) Process / Method is to look at people this way. This view is that no "people" are very variable and nonlinear, different individuals have unique success or failure mode. Those factors are a first order It is not negligible. If a designer of a process or method cannot take into account these factors, then its consequence is the project's unplanned trajectory. It is like what we often see. - [cockburn non-linear] cockburn It is the most clearly advocated in software development, in fact, this concept is already a consensus in many software industries. The problem is that the method used is with this concept.
This causes a strong positive feedback mechanism. If you expect your developer to be mutually programming plugins, you will not try to see them as different individuals. This will reduce morale (and productivity), and make excellent talents to a place where they can play their own character, and finally you get what you need: can be interveiled programming plug-in. Make people's priority decision is a big event It requires a lot of determination to implement. It is a deep-rooted idea of people in the business community. The root causes to Taylor's "scientific management" method. When managing a plant, this Taylor's way is effective. But for the highly creative and professional work, I believe that software development is such that Taylorism is not applicable (in fact modern manufacturing is also out of Taylorism).
The programmer is a key idea of responsible professional Taylorism. It is not that people who don't know how to do this kind of people can do. This may be like this in the factory because the ordinary workers in many factories are not the most intelligent and most creative personnel. Another reason is that the relationship is tense due to the disassembly of the management and workers' salary.
History proves that this situation does not exist in software development. Continuously excellent talents are attracted to the software industry, attracting their existing lights and rich returns (it is the two induces me to leave the electronic engineering]. Other welfare, such as the company's shares, make programmers Interests are closely linked to the company.
[There may be a "generational" effect. Some of the people who met made me think that there are many outstanding talents in the past ten to transfer to the software industry. If this is the case, this may be the reason why today's young people advocate IT industry, just like other fashion, there are always some real reasons. ]
If you want to hire and keep an excellent talent, you have to realize that they are professionals. Therefore, they are the most qualified to do how their technology work. Taylorism allows the plan to decide how to do a good job is only effective when the planner can know how to make it more than the actual operator. If you have excellent, consciously self-motivated employees, this is not established.
The "people-oriented" concept can have different performances in the management of people's processes, which will result in different effects, not all results are exactly consistent.
One key to implementing the agile process is to let everyone accept a process rather than imparting a process. Usually the process developed by software is determined by the management, so such a process is often boycott, especially if the manager has been out of the actual development activity for a long time. It is necessary to "voluntarily", so that you can participate in active attitude towards it.
This leads to an interesting result, that is, only developers they can choose and follow a suitable process. This is particularly obvious in XP, as this requires strong self-discipline to run this process. As a complementary, Crystal (crystal series) process only requires minimal self-discipline.
Another point is that developers must have the right to do all decisions in technology. XP is very emphasizing this. In the previous plan, it explains the time required to do one work only if developers can estimate.
For many managers, such a technical leader is a very large transformation. This approach requires sharing responsibilities, namely developers and managers have the same status in the leadership of a software project. Note that I said the same. Managers still play their roles, but they need to know and respect developers' expertise.
The reason why the role of developers is emphasized, an important reason is that the technology change rate in the IT industry is very fast. Today's new technologies may be over time. This situation is completely different from other industries. Even those who have previously dried technologies in the management must recognize that the entering management means that their technical skills will disappear quickly. Therefore, it is necessary to trust and rely on the current developer.
The difficultiness of the measure If there is a process, the person who specifies how the work should do is not specific to the person, then you need some way to measure whether the person works is effective. In Science Management, there is a strong force drive to develop objective methods to measure people's work output. This is very difficult to measure software is particularly related to software. Although people have made great efforts, we still can't measure some simple aspects of software, such as productivity. If there is no effective measure method, any external control will be difficult (doomed).
There is no set of effective measurement methods to introduce measurements in management will result in management itself. In this regard, Robert Austin has a good discussion. He pointed out that when the measure is performed, you have to get all important factors affecting this measure. Any lack will inevitably change the specific work of people to change their way to get the best measurement scores, even which will significantly reduce their true work effectiveness. This measured "DYNSFunction" is a fatal place based on the measured management method (Achilles Heel, the ankle of Akariis).
Austin's conclusion is that you have to choose in these two methods: how to manage the measured management, or "delegatory" management (people who do work). The measured management is very suitable for simple, repetitive work, low knowledge requirements and easy to measure output - this is just the opposite of software development.
The key is that the premise of traditional methods assumptions is based on the measured management is the most effective way of management. Agile developers believe that the characteristics of software development make the measured management lead to very high measurement "DysFunction). In fact, the use of the entrustful management method is much more effective, which is the center of the agile argument.
The Role of Business Leadership (The Role of Business Leadership), but the technicians do not cover the world, they need to guide the needs of the application system. This leads to another important aspect of the adaptive process: they need to be very close to business experts in the application field. contact.
This tightness has a tightness exceeding the degree of intervention of businessmen in general projects. If developers and business people only communicate occasionally, the agile process is impossible. They need to constantly obtain expertise in business. In addition, this communication is not processed by management, but every developer needs to do. Because developers are professionals in their industries, they can work together with professionals in other industries.
This is determined by the characteristics of the adaptive process. Because agile development is in the entire development process, things have changed soon, and you need to communicate frequently to make everyone know these changes in time.
For developers, there is nothing better than seeing your hard work, it is more painful. Therefore, developers can be very important to obtain accurate high-quality application systems at any time.
The adaptive process has so far, and the adaptability I talked refers to how the software is frequently modified in a development project to be changed to a constant demand. However, there is another adaptability, that is, the process itself changes over time. A project is in the start of an adaptive process without reaching this process after a year. Over time, the development team will find what way to work on their work and then change the process to accommodate.
The first step in adaptive is to summarize the process. In general, after each iteration is over, you can ask yourself as follows [Norm Kerth]:
. What do you have to do. What lesson is there. What can be improved. What are you doing clearly?
These problems will help you consider how to fix the process in the next iteration. In the sample, if there is a problem when the process is started, the process will be gradually improved as the project is perfect to better suit the development team. If a project uses an adaptive method, this method can be further introduced within one organization. If you need to deepen the adaptive process, I recommend developers to do a more formal review in a period of time, as suggested by Norm Kerth, including leaving the work location, to another place, in an experienced Experts have a summary of 2-3 days. This is not only a learning opportunity for the development group, but also gives an opportunity to organize the entire organization.
The result of adaptability is that you must never look forward to only one process. Instead, each project group not only chooses their own procedures, but also adjusts the process used as the project. The process of disclosing and other projects can be used as a reference and sample. However, developers need to adjust it according to the specific circumstances of the project, which is also the professional responsibility of developers.
This adaptive is clearly referred to in ASD and Crystal (Crystal Series]. The strict rules of XP do not seem to be allowed, but this is just surface phenomena, because XP is encouraged to adjust the process. This top XP and other methods The main difference is that XP advocates suggested that when using XP, then according to the book, according to the book, it is adjusted, and then, the review summary this is not emphasized in XP, nor this The part of the process, although XP recommends reconsideration should be one of the practical guidelines for XP.
A number of methods for agile models can be classified into the agile model, and they have a lot of common features, but there are also some important points. In this short review, I can't list all the features of these processes, but at least I can tell you where you can find more detailed materials. Most of these methods I have no in-depth practical experience. I have a lot of work based on XP, and I have some experience in RUP. But for other methods, my knowledge is mainly from books (of course, this is not enough].
XP (Extreme Programming - Extreme Programming) In all agile methods, XP is the most distinctive. In part because XP's excellence, especially Kent Beck, he can attract this The method is coming, but it has been in a leader. But XP heat brings a problem, that is, it squeezes other methods and their very valuable thinking.
XP is rooted in the SmallTalk circle, especially Kent Beck and Ward Cunningham in close cooperation at the end of the 1980s. At the beginning of the 1990s, they deepen their practice on a series of projects to extend their software development and should be humanistic.
A key step in forming a systematic regular way from informal, exploratory practice to forming a systematic approach is in 1996. Kent was invited to review the development schedule of Chrysler's salary management project (C3]. The project was developed by SMALLTALK by a sign company. Because the source code quality is poor, the Kent suggests to move. The project is then His leadership began from head and became an early XP flagship and training base.
The first system of C3 is put into operation in early 1997. After the project continued for a while, it was incurred, led to the revocation of the development plan in 1999. (This also proves that XP is not a guarantee of success)
The four basic value principles of XP are: communication, feedback, concise, and courage. Based on this, more than 10 Practical guidelines should follow. In fact, many guidelines are previously existing and practical tests, but often ignored. The XP re-established these guidelines and woven them into a harmonious whole, making each criterion to strengthen in other guidelines. XP has a most impactful, which is the characteristics of initial attraction, it is its extreme attention to the test. It is true that all the processes mention test, but they are generally not very emphasized. However, XP will test the basis for development, requiring each programmer to write a corresponding test code when writing a source code. These test fragments are constantly accumulated and integrated into the system. Such a process will produce a highly reliable construction platform that provides a good foundation for further development.
On this basis, XP has established a progressive development process that rely on the reforming of the source code during each iteration. All design is around the current iteration, regardless of the future demand. This The result of the design process is "discipline" and "adaptability" highly unified, so that XP has become the best way to develop in adaptive methods.
XP has produced a group of leading characters, many of which came out from the C3 project. There are many documents for XP to read. Kent Beck writes Extreme Programming Explained, a declaration of XP, which expounds the idea hidden behind XP. This book provides adequate explanation and explanation for our hearts in XP and to make it in promoting them. A group of "colorful" XP books have been published in the past two years, but most of them are similar, mainly from the perspective of some XP early practices.
In addition to the book, there are still many online resources. If you want to find a more structural material, you'd better access two members of the C3 member: Ron Jefferies' Xprogramming.com and Don Wells ExtremeProgramming.org. Many XP early advocacy and development can be found in Ward Cunningham Wiki Web (Cooperative Writing). Wiki is a fascinating place, although its roaming nature often can't be caught in it, XP discussion group [XP Discussion Egroup It is also very interesting. There is also a very interesting article from the (XP circle) "outside" to examine XP, which is one of the leading people of CMM from the perspective of Mark Paulk.
Cockburn's crystal series Method Alistair Cockburn has been studied in the form of IBM in the early 1990s. From then, he is active in this field. But his research pathway is different from other methodologists. The general method scholar is the theory of the experience of their personal experience, and Cockburn has actively visited other projects, and the project team members have been actively visited, and how these projects are working. . It is difficult for that he never adheres to his own point of view, he will correct his theory according to new discovery. His characteristics make him be my favorite methodologist.
His book Surviving Object-Oriented Projects brings a lot of recommendations for how to run software development projects, this book is also the preferred book I recommend running iterative projects. Recently, Alistair wrote a review book on agile software development, and explored the basic principles of these methods.
Alistair further explores an agile method and proposes a series of crystals. The reason is a series because he believes that different types of projects require different methods. He believes that a method is related to two factors: The number of items participates in the number and error. If two coordinate axes are used to indicate these two variables, then on this picture, each method has its corresponding coordinate position. For example, there are two items, one is There are 40 people to participate, if the financial losses caused by failure can be accepted; another project is only 6 people, and its success or failure. Then the methods used in these two projects have different positions on the coordinate map. Crystal series is the same as XP There are people-centered philosophy, but they have different practices. Alistair considers that people are generally difficult to strictly follow a discipline process, and therefore, alistair explores the minimum discipline with the high discipline of XP. A method of constraints can still be successful, thereby reaching a balance in output efficiency and easy operation. That is, although the crystal series is not as output efficient as XP, more people can accept and follow it.
Alistair also costs a lot of written inks to emphasize the summary review of each iteration, and thus encourage the process itself. His reason is that iterative development is used to find problems as soon as possible and solve it. This will strengthen the developer to observe the procedures they used and adjusted as the project.
The open source code will see this title you may have some unexpected. After all, open source (open source) is a class of software, not a process. Here I refer to a way to operate in the open source, which is suitable for open source projects, in fact it's many practices It can also be used for the closed source project. The open source project has a special place, which is that the program developers are distributed widely in the region. Notes this is important, because the general adaptive process emphasizes the item group member at the same location. jobs.
Most open source projects have one or more source maintenance people (maintainer). Only maintenance can enter new or modified source segments into source code libraries. Other people can modify the source code, but they need to make changes they do For the maintainer, the maintainer reviews these changes and decides whether it is incorporated into the source code library. Generally speaking, these changes are in the form of "patch" files so that it is easy to handle. Maintainer is responsible for coordinating these changes And keep the design consistency.
The role of the maintainer has different generation and processing methods in different projects. Some projects have only one maintainer, some projects divide the entire system into several modules, each module has a maintor. Something is a maintenance person, some is a plurality of maintaines in the same source section, some of which are combinations of these squares. Many participants in open source projects are just part of time (or spare time), such as fruit project requirements are full-time, then this has a problem, how to effectively coordinate these developers effectively.
A highlight of the open source is the high parallability of the error of Debug. Because many people can participate in the wrong dislocation. If they find mistakes, they can send the "patch" file that corrects the source code to the maintenance This is a very good job for the non-maintainer, which is also a very good job for those who are not very strong.
There is still no systematic literature on the open source method. At present, the most famous article is written by Eric Raymond, which is short, but it is very exciting. In addition, there are also several chapters of the book of CVS in Karl Fogel. Source code method. Even if you don't want to use CVS, these chapters are worth seeing.
High Software Development Method (ASD - Adaptive Software Development) Jim Highsmith has been engaged in the research, establishment and teaching of a predictable method for many years, and finally concluded that these methods have fundamental defects, especially In the development of modern application systems. His recent book focused on the adaptation characteristics of the new method, focusing on the application of some ideas originated from complex adaptability systems (commonly referred to as chaos theory - Chaos THEORY). This book is not Detailed practical guidelines are as XP, but it fundamentally explains why adaptive development methods are important and further illustrates its impact on organizational structure and management.
The core of ASD is three nonlinear, overlapted development stages: guess, cooperation and learning.
In an adaptive environment, because the result is unpredictable, HIGHSMith regards the plan as a "counter" [paradox]. In the traditional plan, the deviation plan is wrong and should be corrected. In an adaptive environment, the deviation plan is taking us into the right goal.
In an unpredictable environment, you need everyone to work in a variety of ways to work with uncertainty. In management, its focus is not to tell everyone what, but encourage everyone to communicate, so that they can make creative solutions.
In a predictable environment, it is usually not encouraged. The designer has been designed, you will follow it.
In adaptive environments, learning to all parties, including developers and customers are a challenge. They need to learn to test their assumptions, need to learn to adapt to the next cycle with the results of each development cycle. - [HIGHSMITH]
Such learning is continuous, this has become an important feature of this method, so we must recognize that plans and design have changed in advance.
The most powerful, indivisible benefits of adaptive development cycles are the challenges of our own psychological model, which forces us to more actually estimate their ability. - [Highsmith] With such a starting point, HIGHSMith put his work in the difficulty of adaptive development, especially how to enhance cooperation and study in a project. Basically, his book is focused on the "soft" method, so this book will be a very useful complementary method for the methods extracted from development practices such as XP, FDD and crystal series.
Scrum Scrum has been very late in the OO ride, but I have to admit that I don't know much about its historical development. Like the methods arguable as before, this method emphasizes the fact that the defined defined replicate method is limited to a repetitive environment that is clearly defined. The repeated personnel use to solve the prolific issues that are clearly defined.
Scrum divided a project into several 30-day iterative stages, called a "rush" (sprint). Before you "rush", you have to clarify the function of this "rush" to achieve, then hand it over to the development group. Completed. However, during the "rush", the demand must be fixed.
The management personnel do not work if it is "rush". Every day, he needs to convene a short meeting (15 minutes or so), called a Scrum, will discuss what you have to do next day. In particular, you will propose factors that hinder the project for the management, and hope that management can Solved. Of course, they also need to report what is currently completed, so management can make progress every day.
Scrum literature multi-concentrated discussion discipline schedule plan and progress tracking. It is similar to other agile methods, especially it can be well combined with XP programming criteria. For a long time, there is no special book on Scrum for a long time until Ken Schwaber and Mike Beedle have written the monographs of Scrum. Ken Schwaber also hosted a website controlchaos.com, which may be the best review of Scrum. Jeff Suthurland has a very active website to discuss OO technology, some of which are specially discussed Scrum. In addition, there is also a good review of Scrum in the PLOPD 4 book. Scrum also has a Yahoo discussion group.
The function-driven development method (FDD - Feature Driven Development) is proposed by Jeff de Luca and Oo Master Peter COAD. Like other methods, it is committed to short-time iteration phases and visible functions. In FDD, An iterative cycle is generally two weeks.
FDD has the following five tasks:
. Establish an overall model. Propose a list of functions. Develop a plan for functions. Designed for function items. Implementation
The first three items were completed at the beginning of the project, and the latter two items were done every time iterative cycle. Each task can further decompose and develop corresponding inspection standards.
In FDD, programming developers are divided into two categories: Class Owner (Class Owner). Chief Programmer is the most experienced developer, they are responsible for developing various functions of the system. For each Function, Chief Programmer wants which classes need to be needed to implement this function, and convene "class" programmers form a development group for this function. Chief programmer as a coordinator, designer and instructor And "class" programmer is mainly written in source code.
About the documentation of FDD is relatively small. Until recently, there was a full discussion of FDD. The main proposal of FDD Jeff de LUCA has now established a FDD portal, including some articles, notes and discussions. The earliest discussion of FDD is seen in the UML in Color of Peter COAD. His company TOGETHERSOFT is also engaged in FDD consultation and training.
Dynamic System Development Method [DSDM - Dynamic System Development Methods] DSDM started in UK in 1994. Some companies that want to develop system development with RAD and iterative methods have formed a community [consortium]. At first, there were 17 members, and now members have more than 1,000 members, all over the UK. DSDM is developed by other agile methods due to the development of a community. It has special organization support, with manual, training course, certification procedure, etc. Because of its price tag, it limits the further investigation of this method. However, Jenifer Stapleton has written a book to introduce this method.
If you want to use this method, you have to first analyze it. Feasibility analysis should consider whether DSDM is suitable for this project. Business analysis is a series of seminars to fully understand the application domain, and also propose a general system structure and project plan.
The rest of the work consists of three mutually intertwined cycles: function model cycle generates documents and prototypes (experimental systems), designing construction cycles to generate operational systems, implement cycle processing system installation deployment (deployment) problem.
DSDM has some basic principles including communicating with users, frequent delivery (Delivery). Project group with full powers, complete system testing. Like other agile methods, one cycle of DSDM is 2-6 weeks. It emphasizes high quality systems and high adaptability to demand changes. I haven't seen the project using DSDM in the United Kingdom. The basic structure of DSDM has many mature traditional methods, and at the same time follows the accelerated pathway. But here is worth noting that this method is to encourage a process and cumbersome tendency.
Agile Software Development Declaration can be seen that these methods mentioned earlier have many similarities, then natural everyone will be interested in conducting some forms of cooperation. In February 2001, the representatives of these methods were invited to Snowbird for two days of Snowbird. I am also in their column, but I have not hugged too much hope. After all, when you put a bunch of method scholars into a house, they can treat them with a gift.
The result is unexpected. Each participant recognizes that these methods have many common points, which is much greater than their differences between them. This discussion will enable these first-class methods to increase contact. Everyone also has a joint statement - calling for promoting the development of light-type development process (we also agree with "agile" words to express our total Idea.
The results are a agile software development Declaration [Manifesto for agile software development], which expresses the value and principles of the agile process. Participants are also intended to work further in the future, and encourage methods of software development with business people using agile methods. Software Development Magazine [Software Development Magazine] There is an article about the declaration and explanation of the article.
Of course, the Declaration is just a published document, which is a gathering point for people with common ideas. Another result of this effort is to establish an agile alliance. Agile Alliance is a non-profit organization, its purpose is to promote the knowledge of agile methods and to promote this discussion. Many leaders in the agile methods I have mentioned are also members and leaders of this alliance.
Context Driven Testing Agile Development Movement is initially driven by software developers. However, some people who participate in software development are also affected by this movement. A obvious group is testers, they are usually living in a world defined by waterfall development. In general, the role of testing is to ensure that software is in line with the beginning of the design. In the agile world, the role of testers is still unclear.
In fact, several people in the test circle have been questioning this mainstream test thinking for a considerable period of time. This results in a group called "Context Driven Testing). The best discussion on this concept is "Lessons Learned In Software Testing this book. This circle is also very active on the web, you can take a look at these websites, Brian Marken (he is also one of the authors of the agile declaration) ), Brett Pettichord, James Bach, and Cem Kaner.
Is RUP a sensitivity method? When we start discussing the method of OO field, it is inevitable to encounter RUP (Rational Unified Process). The process is developed by Philippe Kruchten, Ivar Jacobson, and other people of Rational's company, mainly as a match and complement with UML The process. RUP is actually a process framework, which can contain many different types of processes, this is the main criticism of my for RUP. Because it can be anything, then you are not the same. I am willing to choose The process is that it can clearly tell you what, not give you an endless choice. Since RUP is a framework, you can use it in a different way, if you are very traditional "waterfall" development method, or agile You can use it to make it light, you can make it a bashite. This depends on how you cut it in your environment.
Craig Larman is extremely advocated to use RUP in an agile manner. In his outstanding book on OO development, he put forward a process, which is based on this "light" RUP idea. His view is that there are so many efforts to advance agile methods, but only the mainstream OO development method that can be regarded as RUP. When making a project, the Craig is going to do, in the first two or three days of the first two or three days of January and the entire development group, using UML outline the design of this iterative stage. This design is not an uncharged, it is just a sketch that makes everyone know how to dry this stage.
Another policy to treat RUP is the DX process of Robert Martin. The DX process is a process that is fully compliant with RUP, and it happens to be completely equivalent to XP (seeing DX to turn 180 degrees. XP is also RUP at the same time, which can be used as an excellent example of using RUP in agile.
For me, a key to using RUP is that the leaders of the industry RUP need to emphasize their software development pathways. Once more than once, I heard the use of RUP is using the "waterfall" development process. Based on the links in the industry, I know that Philippe Kruchten and his team are firm iterative development trustwors. Clarify these principles and encourage agile to use RUP, such as Craig Robert, will have an important impact and role for software development.
Recently, there are two good books, which are widely discussed by Alistair Cockburn and Jim Highsmith, and they are widely discussed in the book.
Regarding the acceleration method, there are many articles and discussion groups, which may not provide a complete method, but you can give you a window to observe how this is developing.
Patterns Language Of Programming (Patterns Language Of Programming) The General Assembly often has some material discussion, this may be because many of the model (Pattern) is also interested in adaptation and "humanity" methods. In this regard, there is an early first-class papers. JIM Coplein is collected in PLOP1. The Ward Cunningham Episodes mode language is collected in PLOP2. Jim Coplein is now a website, orgpatterns, the Wiki mode has collected a lot of organizational structural mode. Dirk Riehle submitted a papers at the XP2000 conference, comparing XP and adaptive software development (Adaptive Software Development, ASD) value system. The July of XP and FDD.IEE Software in July, the July of the July, and fdd.ieee Software. There are several articles to discuss "Process Diversity], which also mentioned these methods. Mary Poppendieck wrote a very exciting article comparative agile method and fine (Lean) manufacturing.
Should you go to agile? Not everyone can use an agile method. When you decide to take this way, you have to remember many guidelines. However, I do it exactly that these new methods can be widely used. Just consider using them far less enough, there should be more people to use them in practice.
In the current software development, most methods are still write-edge modifications (Code and fix), then introducing some discipline constraints will definitely be better than a chaotic. The main advantage of agile type means is that it is less than the grade method. There are more. If you are accustomed to no process, follow the simple process should be more likely to follow the cumbersome process.
One of these new methods is how to deal with larger project groups. Like many other new methods, these agile methods are also willing to be used on a small scale, and usually they are proposed to be placed on a small-scale project group. XP clearly explains that it is suitable for project groups up to 20 people. It is worth mentioning here that many software project groups can reduce the number of people without reducing overall productivity.
Other agile methods are trying to use the big team. FDD was originally designed for projects around 50. ThoughtWorks has used similar XPs in three mainland (continents), and the project team member is about 100 people. Scrum also used in a similar scale project.
This article is at least clearly delivered to this information, which is effective in the adaptive method to be uncertain or often changed. If you don't have a stable demand, then you can't make stable design and follow a planned process. In this case, the adaptive process may feel uncomfortable, but it will be more effective in practice. Typically, the use of adaptive methods is the largest barrier from customers. I believe that the important point is to let customers understand that in an environment where demand is constantly changing, it is risky to them in accordance with the predefined process. It is also risks to the developer.
If you want to adopt an adaptive method, you need to trust your developer and let them participate in (technical) decisions. The success of the adapter process relies on your trust in your developer. If you think your developer quality Not enough, then you should use a predetermined way.
Summary, the following factors recommend that you adopt an adaptive process:
. Uncertain or often changed demand. Responsible, conscious self-motivated developers. Understand and willing to participate in customers
And these factors are recommended that you use the predictability process:
. The project group above more than 100 people. Fixed prices, or more exactly, fixed task-wide contract
