Extreme Programming - Lightweight Crystal Method
March-Bird Lucian Yjf Taopin WL Jazz Han Wei Nullgate Simon [Aka] (Reprinted from Cutter.com) September 15, 2003
Crystal Light Methods: Comments by Alistair Cockburn lightweight Crystal Method Editor's note:. In the early 1990s, Alistair Cockburn was hired by the IBM Consulting Group to construct and document a methodology for OO development IBM had no preferences as to what the answer might look like, just that it work. Cockburn's approach to the assignment was to interview as many project team members as possible, writing down whatever the teams said was important to their success (or failure). The results were surprising. The remainder of this Section Was Written By Cockburn and is based on his "in-process" Book on minimal methodology Note: In the early 1990s, the AliStair Cockburn IBM consultant group was working, and a set of work was developed for OO (object-oriented) development. method. IBM believes that the white cat black cat, it is a good cat to the mouse. Cockburn has been in depth in depth in many development groups and wrote the key to the success or failure of the project. As a result, it was shocked. The following is written by cockburn, based on his "actual work" book containing very little methodological book. In the IBM study, team after successful team "apologized" for not following a formal process, for not using a high-tech CASE tool, for "merely" sitting close to each other and discussing as they went. Meanwhile, a number of failing teams puzzled over why they failed despite using a formal process -? maybe they had not followed it well enough I finally started encountering teams who asserted that they succeeded exactly because they did not get caught up in fancy processes and deliverables, but instead sat close Talk Easily So The Could Talk Easily and Delivered Tested Software Frequently. In the IBM research group, the development team wants to "apologize" to the previously successful group, because they don't abide by a formal process because they do not use a high-tech CASE tool. Or or "Just" because they sit together, discuss how they will do it.
At the same time, some failed groups feel very confused, although they use formal processes, they still fail - it is not good enough to comply with these processes. Later I started to meet some successful groups, they claimed that it was because they were not trapped in the flowers and publishing, but everyone sat together, thus making them more easily discussed and often exchanged the test software, and finally It was successful. These results have been consistent, from 1991 to 1999, from Hong Kong to the Americas, Norway, and South Africa, in COBOL, Smalltalk, Java, Visual Basic, Sapiens, and Synon The shortest statement of the results are:. These conclusions from From 1991 to 1999, from Hong Kong to the United States, Norway, South Africa, in Cobol, Smalltalk, Java, Visual Basic, Sapiens, and Synon are consistent, these shortest descriptions are: to the extent you can replace Written Documentation with Face -to-face interacts, you can reduce Reliance ON WRITTEN WORK PREDUCE RELIANCE THE LIKELIHOD OF Delivering The system. To use the face-to-face communication, you can reduce Work products written in your scope. dependence, and increase the possibility of publishing system the more frequently you can deliver running, tested slices of the system, the more you can reduce reliance on written "promissory" notes and improve the likelihood of delivering the system. the more often published The system is running and tested, the more you can reduce the dependence of the "agreement" tag, the more you can increase the possibility of the final release system, the PEOPLE ARE COMMUNICATINGS. Even Introverted Programmers Do Better with Informal, Face-to-Face Communication Than With Paper Documents. from a cost and time persft Ive, Writing Takes Longer and is Less Communicative Than Discussing At The Whiteboard. It should be communicated in humanity. Even for the internal contact, the face-to-face communication is used, which is better than the communication effect of the document written on paper. From a cost and time, writing articles will always discuss more time than in the whiteboard, and the effect of communication is worse.
Written, reviewed requirements and design documents are "promises" for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running tested code. It is more accurate because IT is not a timed promise, IT is a timed accomplishment. Those who are written and reviewed needs and design documents are just "promise" what to do, we can use it as a sign of project progress. There are a lot of progress marks to be in the original setup. However, more accurate progress marks should be the code after running the test. Because this is not a pre-promised flag, but the true completion of the symbol. Recently, a bank's IT group decided to take the above results at face value. They began a small project by simply putting three people into the same room and more or less leaving them alone. Surprisingly (to them), the team delivered the system in A Fine, Timely Manner. The Bank Management Team WAS A bit belay? SURELY IT CAN't Be this Simple? Recently, a bank's IT department decides the following results. They launched a small project, using simple ways to put three people in a room, so that they will die. Surprisingly, this group promptly, excellent release system. Bank's management feels a bit confusing. Will it be as simple as it? It is not quite so simple Another result of all those project interviews was that:... Different projects have different needs Terribly obvious, except (somehow) to methodologists Sure, if your project only needs 3 to 6 people, just put them into A room to points, one........................................................................................................................................ A Rocket, I'll Ask you not to try it. we must remember factors such as team size and demans on the project, such as: Of course not so simple. Another conclusion obtained after interviewing all other projects is: Different projects have different needs. This is very obvious, not dependent on methodology (don't know what). Of course, if your project only needs 3 to 6 people, just let them be in a room. But if you have 45 or 100 people, this is useless.
If you want to test through the process of the food and drug management department, you can't start this way. If you want to launch me with a rocket to Mars, I recommend don't try it. We must remember the needs of the team's size and project: as the number of people involved grows, so does the need to coordinate Communications. With the growth of participants, coordinated communication needs more as The Potential for Damage Increases, And The Tolerance for Personal Stylistic Variations Decreases. With the potential destructive growth, the requirements for public inspections are also increasing, while simultaneous differences in the difference due to different personal styles. The degree also reduces Some Projects Depend On Time-to-Market and Can Tolerate DEFECTS (Web Browsers Being An Example); Other Projects AIM for Traceability Or Legal Liability Protection. Some projects demonstrate the release time determined by the market, and for some defects Can be tolerated (web browser is such an example); other projects are committed to provision and legal responsibility. The result of collecting those factors is shown in Figure 6. The figure shows three factors that influence the selection of methodology:. Communications load (as given by staff size), system criticality, and project priorities summarized according to the collected relevant factors Conclusion As shown in Figure 6. It shows the three factors that choose different methodologies: communication difficulty (decided by the number of members), system key programs, and priority of the project. Figure 6 - The Family of Crystal Methods.
Locate the segment of the X axis for the staff size (typically just the development team). For a distributed development project, move right one box to account for the loss of face-to-face communications. Determined according to the number of members in the X-axis Part (usually just developing groups). If it is a distributed development project, because the opportunity to communicate in the face is reduced, move to the right. On the Y Axis, Identify The Damage Effect of The System: Loss of Comfort, Loss of "Discretion" Monies, Loss of "Essential" Monies (EG, Going Bankrupt), or Loss of Life. On the Y-axis, confirm that the system is corrupted Impact: The degree of comfort is lowered, obvious economic losses, fundamental economic losses (such as bankrupt), or death. The different planes behind the top layer reflect the different possible project priorities, whether it is time to market at all costs (such as in the first layer), productivity and tolerance (the hidden second layer), or legal liability (the hidden third layer ). The Box in the Grid Idicates The Class of Projects (for Example, C6) with Similar Communications Load and Safety Needs and can be used to select a methodology. Different aircraft (Plate Panel?) Reflects various items Different key points, whether it cost is a listing time (like the first layer), efficiency and compatibility (hidden second layer), or legal responsibility (hidden third floor). The grid in the grid is determined. In similar communication difficulty and the type of item (for example, C6), you can use methodology. The grid characterizes projects fairly objectively, useful for choosing a methodology. I have used it myself to change methodologies on a project as it shifted in size and complexity. There are, of course, many other factors, but these three determine methodology selection quite well This grid shows the characteristics of the project and is useful for choosing a methodology. I used to change my methodology when I changed the size and complexity of the project. Of course there are other factors, but these three are used to decide what methodology is good.
Suppose it is time to choose a methodology for the project. To benefit from the project interviews mentioned earlier, create the lightest methodology you can even imagine working for the cell in the grid, one in which person-to-person communication is enhanced as much as possible, and running tested code is the basic timing marker. the result is a light, habitable (meaning rather pleasant, as opposed to oppressive), effective methodology. Assign this methodology to C6 on the grid. Suppose now that you want to select an item methodology . Thanks to the interviews mentioned above, you can build a maximum amount of methodology, imagine into the grid in the grid, here, try to improve the communication between people and people, run The code after the test is the most basic progress mark. The result is a simple, conforming to human habits (meaning more pleasant, opposing capping). Specify this method to C6 on the grid. Repeating this for all the boxes produces a family of lightweight methods, related by their reliance on people, communication, and frequent delivery of running code. I call this family the Crystal Light family of methodologies. The family is segmented into vertical stripes by color ( not shown in figure): the methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc. All these repeat The lattice, generate a lightweight method, based on their confidence, communication, and release of people's confidence, communication, and the frequency of running code. My name is this family for the Crystal Light method. This family is divided into different vertical stripes: 2-6 people's project methodology: 2-6 people's project method is called Crystal Yellow, 20-40 people Method is called Crystal Orange, then Red, Magenta, Blue, and so on.
Shifts in the vertical axis can be thought of as "hardening" of the methodology. A life-critical 2-6-person project would use "hardened" Crystal Clear, and so on. What surprises me is that the project interviews are showing rather Little Difference In The Hardness Requirement, Up to Life-Critical Projects. Switch between vertical directions is known as enhancement. A 2 to 6 people in a short life period should be managed using a strengthened Crystal Clear or its derived approach. What made me surprises is that in such a project, I can't see the contradiction between the additional demand and completing the project on time. Crystal Clear is documented in a forthcoming book, currently in draft form on the Web. Crystal Orange is outlined in the methodology chapter of Surviving Object-Oriented Projects (see Editor's note below). Crystal Clear from a book to be published now online There is already a draft. The contour of the Crystal Orange is described in the Method of "Surviving Object-Oriented Projects". Having Worked with The Crystal Light Methods for Several Years Now, i Found A Few More Surprises. After many years, I found more surprises. The first surprise is just how little process and control a team actually needs to thrive (this is thrive, not merely survive). It seems that most people are interested in being good citizens and in producing a quality product, and they use their native cognitive and communications abilities to accomplish this. This matches Jim's conclusions about adaptive software development (see Resources and References, page 15). you need one notch less control than you expect, and less is better when it comes to delivering quickly. The first surprise Yes, a development team success (not only survive) does not require too much management and control. Most developers are happy to work and write good software, they will use their own understanding and communication skills to complete all. This is exactly the same as the conclusions made by Jim on adaptive software development (see "Resources and References", page 15). You need to have much more control over you expect, especially when you want to release the software as soon as possible, the less you.
More specifically, when Jim and I traded notes on project management, we found we had both observed a critical success element of project management: that team members understand and communicate their work dependencies They can do this in lots of simple, low-tech,. Low-Overhead Ways. It is often not Necessary to Introducture Tool-Intensive Work Products to Manage It. More particularly, when I exchange project management, we realized that we all observed successful project management. A key element: developers can understand the work of relevant personnel and communicate. They can complete all this through many simple, low-tech and cheap methods. Usually this does not need to introduce what special tools are managed. OH, But it is necessary to in Introduce Two More Things Into The Project: Trust and Communication. However, two key elements are required: trust and communication. A project that is short on trust is in trouble in more substantial ways than just the weight of the methodology. To the extent that you can enhance trust and communication, you can reap the benefits of Crystal Clear, XP, and the other lightweight methods. In a project, lack of trust is more destined to learn a wrong method. From a certain extent, as long as you can strengthen trust and communication, you will be able to benefit from Crystal Clear, XP (Extreme Programming?) Or other lightweight development methods. The second surprise with defining the Crystal Light methods was XP. I had designed Crystal Clear to be the least bureaucratic methodology I could imagine. Then XP showed up in the same place on the grid and made Clear look heavy! What was going on? First Two surprises are that it is consistent with XP when we define the cystal light method. I designed Crystal Clear as the least bureaucratic method I can imagine.
Subsequently, XP appeared and showed a summation in the same field, and the Clear in front of it became a heavyweight development method! This is how the same thing? It turns out that Beck had found another knob to twist on the methodology control panel:.. Discipline To the extent that a team can increase its internal discipline and consistency of action, it can lighten its methodology even more The Crystal Light family is predicated on Allowing Developers The Maximum Individual Preference. XP is Predicated on Having Everyone Follow Tight, Disciplined Practices: This is probably because Beck discovers another switch on the control panel of the method: discipline. To some extent, if a development team enhances internal discipline and ensuring the consistency of action, the methodology can become more lightweight. Crystal Light derived methodology gives the developer's maximum personalization. XP requires everyone to abide by strict disciplined practices: Everyone Follows A Tight Coding Standard. Everyone must abide by a strict coding standard. The Team Forms a Consens On What Is "Better" Code, So That Changes Convert. About what is good code, the development team should reach a consensus, so all changes are set together. Avoid repetition. Unit tests exist for all functions, and the always pass at 100%. Each function must pass the unit test and must be 100%. All production code is written by two people's code is completed by two developers Tested Function is Delivered Frequently, in The Two- To Four-Week Range. It is one cycle every two weeks. Frequently publish those functions that have been tested. In other words, Crystal Clear illustrates and XP magnifies the core principle of light methods: In other words, Crystal Clear lightweight way to show the core of the law, and XP enlarge it: Intermediate work products can be reduced and project delivery enhanced, To the Extent That Team Communications AreaSed. To a certain extent, if the development team's communication has improved, the released frequency is improved, then the workload of the intermediate product can be reduced, which can be completed faster project.
