Extreme Programming - Practice
March-Bird Lucian Yjf Taopin WL Jazz Han Wei Nullgate Simon [Aka] (Reprinted from Cutter.com) September 15, 2003
Practices Practice One thing to keep in mind is that XP practices are intended for use with small, co-located teams. They therefore tend toward minimalism, at least as far as artifacts other than code and test cases are concerned. The presentation of XP's practices have both positive and negative aspects At one level, they sound like rules -.. do this, do not do that Beck explains that the practices are more like guidelines than rules, guidelines that are pliable depending on the situation However, some. , like the "40-hour week," can come off as a little preachy. Jeffries makes the point that the practices also interact, counterbalance, and reinforce each other, such that picking and choosing which to use and which to discard can be tricky One thing that should be remembered is that we should tend to use XP in a small, partial team. In addition to the exception of code and test, minimize some impact. XP practices have both positive performance and negative. In some respects, they sound like a bunch of rules, do this, don't do that. This beck is explained, and XP is more like a guideline, a flexible development policy that relies on the specific environment. However, it is 40 hours a week. "Working every week" It may feel that it may feel inseparable. Jeffries make practical practice, balanced, and strengthen each other. So that the same discarding is a tricky thing. THE planning game. XP's planning approach mirrors that of most iterative RAD approaches to projects. Short, three-week cycles, frequent updates, splitting business and technical priorities, and assigning "stories" (a story defines a particular feature requirement and is displayed in a SIMPLE CARD FORMAT ALL DEFINE XP's Approach to Planning. The plan is planned: XP can reflect the characteristics of most iterative RAD projects in the implementation method of the development plan. In the short term, every three weeks is a loop, frequently updated, Assign Stories by priority division task and technology, a Stories defines a special functional requirement and records on cards in a simple manner), all of which constitutes a plan in XP.
Small releases "Every release should be as small as possible, containing the most valuable business requirements," states Beck This mirrors two of Tom Gilb's principles of evolutionary delivery from his book Principles of Software Engineering Management:.. "All large projects are capable of Being Divided Into Many Useful Partial Result Steps, "AND" Evolutionary Steps Should Be Delivered on The Principle of The Juiciest One Next. "Summary:" Each version should be as small as possible, and contain the most commercial value, Beck is said. This also reflects Tom Gilb's two points mentioned in his
Metaphor. XP's use of the terms "metaphor" and "story" take a little wearing in to become comfortable. However, both terms help make the technology more understandable in human terms, especially to clients. At one level, metaphor and architecture are synonyms - they are both intended to provide a broad view of the project's goal But architectures often get bogged down in symbols and connections XP uses "metaphor" in an attempt to define an overall coherent theme to which both developers and business clients can relate.. The Metaphor Describes The Broad Sweep of The Project, While Stories Are Used to Describe Individual Features. Metaphor: The use of "metaphor" and "story" in XP may make people feel uncomfortable. However, the use of these terms can help us understand in a more humane manner, especially for our customers. To a certain extent, metaphor is the same as the architecture - they are all focused on a project from globally. But architectures often trapped in symbols and connecting patches. XP uses "metaphor" to define a comprehensive consistent topic from developers to business customers. Metaphor is used to describe the comprehensive appearance of the project, and Story is used to describe individual specific features. .... Simple design Simple design has two parts One, design for the functionality that has been defined, not for potential future functionality Two, create the best design that can deliver that functionality In other words, do not guess about the future: create the best (simple) design you can today. "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy," writes Beck. "Put in what you NEED WHEN You NEED IT. "Simple design: Simple design contains two parts. First, design for a defined function, not designed to potentially future possible functions. Second, create the best designs that can implement functionality. In other words, it will be the best design that is currently achievable without the future. "If you believe in the future, it is uncertain, and you believe that you can change your ideas, then the consideration of future features is dangerous." Beck wrote.
"Only when you really need it" In the Early 1980s, I Published An Article in DataMation Magazine Titled "Synchronizing Data with Reality." The gist of the articles "" The gist of the articles "That, NOT CAPTURE and NOTLITY storage. Furthermore, I said that data that was not systematically used would rapidly go bad. Data quality is a function of systematic usage, not anticipatory design. Trying to anticipate what data we will need in the future only leads us to design for data that we will probably never use;.. even the data we did guess correctly on will not be correct anyway XP's simple design approach mirrors the same concepts As described later in this article, this does not mean that no anticipatory design ever happens; it In the 1980s, I published an article "Actual Synchronization Data" article in the art of automated information management, the quality of data is the function, not capture. With storage. In addition, I said that if the data is not very systematic, it will become. Data quality is the function of the system, not a pre-designed design. Regardless of whether it is wrong or wrong, try to design a data we have never used, the end result is likely to use them once again. The simple design method of XP reflects the same point of view. As described later in this article, this does not mean that it does not require prediction, but the design made by the predicted content has changed, the cost of it is very huge. . Refactoring If I had to pick one thing that sets XP apart from other approaches, it would be refactoring - the ongoing redesign of software to improve its responsiveness to change RAD approaches have often been associated with little or no design; XP should be. THOUGHT OF AS Continuous Design. in Times of Rapid, Constant Change, Much More Attention Needs to Be Focused On Refactoring. See The Sections "Refactoring" and "Data Refactoring," Below. Reconstruction: If I have to find out one can The things that are distinguished from XP and other methods are the reconstruction - the continuous software re-designed to improve its reaction. The RAD method often rarely does not even correspond to design; XP should be seen as a continuous design. When the change is fast and frequent, there should be more energy on the reconstruction.
See "Reconstruction" and "Data Reconstruction" section below. . Testing XP is full of interesting twists that encourage one to think - for example, how about "Test and then code" I've worked with software companies and a few IT organizations in which programmer performance was measured on lines of code delivered? and testing was measured on defects found - neither side was motivated to reduce the number of defects prior to testing XP uses two types of testing: unit and functional However, the practice for unit testing involves developing the test for the feature prior to.. Writing the code and further stat. Once the code is written, it is immediely subjected to the test suite instant feedback. Test: XP full of thoughtful puzzles. For example: What is "encoding first test"? I have worked with software companies and some IT agencies, where is the number of lines through code to assess the performance of programmers, and the performance of the test is taken by the number of defects found. Both methods cannot encourage the number of defects generated before testing. XP uses two tests: unit testing and function testing. The unit test requires the test method of the corresponding function before writing code, and tests should be automated. When the code is completed, it is immediately tested with the test set, so it can get feedback immediately. The most active discussion group on XP remains the Wiki exchange (XP is a piece of the overall discussion about patterns). One of the discussions centers around a lifecycle of Listen (requirements) Test Code Design. Listen closely to customers while gathering their requirements. Develop test cases. Code the objects (using pair programming). Design (or refactor) as more objects are added to the system. This seemingly convoluted lifecycle begins to make sense only in an environment in which change dominates. XP most active discussion group It is still Wiki Exchange (XP is part of the Pattern's overall discussion), one of which discusses the life cycle of listening to (demand) -> test -> code -> design. Close to customers listen and collect their needs. Development Test Cases. Complete object coding (using paired programming).
Design (or reconstruction) when more objects are added to the system. This seemingly chaotic life cycle is only meaningful in the environment that is often changed. Pair programming. One of the few software engineering practices that enjoys near-universal acceptance (at least in theory) and has been well measured is software inspections (also referred to as reviews or walkthroughs). At their best, inspections are collaborative interactions that speed learning as much as they uncover defects. One of the lesser-known statistics about inspections is that although they are very cost effective in uncovering defects, they are even more effective at preventing defects in the first place through the team's ongoing learning and incorporation of better PROGRAMMING PRACTICES. Pairing programming: Software (or use inspection directly is one of the few software engineering practices that are widely accepted (at least in theory) and effective metrics. In the best case, the inspection of Inspection can accelerate learning while discovering defects. A less known statistics about InsPection is although it is very effective in discovering defects, but through the team's continued learning and collaboration for good development practices, it can prevent defects in the first time. One software company client I worked with cited an internal study that showed that the amount of time to isolate defects was 15 hours per defect with testing, 2-3 hours per defect using inspections, and 15 minutes per defect by finding the defect before it got . to the inspection the latter figure arises from the ongoing team learning engendered by regular inspections pair programming takes this to the next step -.? rather than the incremental learning using inspections, why not continuous learning using pair programming one I worked on software Company Customers cited an internal research result, indicating that a defect is found for 15 hours during the test phase. It takes 2-3 hours in the Inspection phase, and it takes only 15 minutes before Inspection before INSPECTION. The subsequent data comes from the continued team of conventional review.
Pairing programming will bring this next step - with its incremental learning with inspection, why don't you use the programming to learn? "Pair programming is a dialog between two people trying to simultaneously program and understand how to program better," writes Beck. Having two people sitting in front of the same terminal (one entering code or test cases, one reviewing and thinking) creates a continuous , dynamic interchange. Research conducted by Laurie Williams for her doctoral dissertation at the University of Utah confirm that pair programming's benefits are not just wishful thinking (see Resources and References). "pairing two people at the same time trying to understand how to better programming and A pair of programs. Quot;, Beck wrote. Let two people sit in front of a terminal (a person knocking code or test case, a person's review and thinking) produces a continuous, dynamic exchange .Williams The Ph.D. Research in Utah is proved that pairing programming is more than just a beautiful idea and is not effective. (See Resources and Reference) Collective Ownership. XP Defines Collective Ownership As The Practice That Anyone on The Project Team Change Any Of the code at any time. for many programmers, and certainly for many managers, the prospect of communal code raises concerns, ranging from "I do not want those bozos changing my code" to "Who do I blame when problems arise?" Collective OWN ERSHIP Provides Another Level To The Collaboration Begun By Pair Programming. Code Sharing: Everyone in the project group can modify the code of other project members at any time, which is the code sharing defined in XP. . For many programmers and manager, the idea of total code will cause some doubts, such as "I don't want those idiots to change my code", "Who should I blame?" And so on. The shared code provides support from another level of collaboration in pairing programming.
Pair programming encourages two people to work closely together: each drives the other a little harder to excel Collective ownership encourages the entire team to work more closely together:. Each individual and each pair strives a little harder to produce high-quality designs, code, And Test Cases. Grand, All this Forced "TOGETHERNESS" May Not Work for Every Project Team. Pairing programming encourages two people to work closely: everyone motivates another effort to surpass. Common all encourage the entire team more closely collaboration: Each individual and each double strive to produce high quality design, code and test sets. Of course, all of these forced "common" do not necessarily apply all items groups. Continuous integration Daily builds have become the norm in many software companies -.. Mimicking the published material on the "Microsoft" process (see, for example, Michael A. Cusumano and Richard Selby's Microsoft Secrets) Whereas many companies set daily builds as a minimum, XP practitioners set the daily integration as the maximum - opting for frequent builds every couple of hours XP's feedback cycles are quick:.. develop the test case, code, integrate (build), and test often integration: daily build (build ) In many companies have become specifications, things on publications on the "Microsoft" process are imitated. (See, for example, Michael A. Cusumano and Richard Selby's Microsoft Secrets) Many companies share the daily chain as the minimum requirement, XP practitioners use daily integration as the maximum requirement, and choose to completely chain each two hours. XP feedback cycle rapid: development test set, encoding, integration (chain chain) and test. The perils of integration defects have been understood for many years, but we have not always had the tools and practices to put that knowledge to good use. XP not only reminds us of the potential for serious integration errors, but provides a revised perspective on Practices and Tools. It has been many years of understanding of integrated defects, but we don't always have the corresponding tools and time to use these knowledge. XP not only reminds us that there may be serious integration errors, but also provide a new understanding from the perspective of practical and tools.
40-hour week Some of XP's 12 practices are principles, while others, such as the 40-hour practice, sound more like rules I agree with XP's sentiments here;... I just do not think work hours define the issue I would Prefer A Statement Like, "Don't Burn Out The Troops", "Rather Than A 40-Hour Rule. There Are Situations in Which Working 40 Hours Pure Drudgery And Others In Which The Team Has To Be Pried Away from A 60-Hour Work Week. Just 40 hours per week: XP has 12 basic principles of practice, but sometimes, like only 40 hours of principles per week, it sounds more like rules. I agree with the views in XP. Just don't think there is a need for hard standard for working hours. Compared to it, I prefer a word similar to "not burning the arm". In some cases, work 40 hours is too tired, and in other groups, even 60 hours of work will be taken. Jeffries provided additional thoughts on overtime. "What we say is that overtime is defined as time in the office when you do not want to be there. And that you should work no more than one week of overtime. If you go beyond that, there's something wrong - and you're tiring out and probably doing worse than if you were on a normal schedule I agree with you on the sentiment about the 60- hour work week When we were young and eager, they were probably okay.. It's the Dragging Weeks to Watch for. "Jeffries provide more thinking about overtime:" We said that overtime is defined for us to stay in the office when we don't want to stay in the office. And you should not overtake more than one week. If you exceed you If you have anything, you have a problem - you are too tired, it is possible to do it off when you get on time. I agree with your stay in 60 working. When we are young and full, this may not Question. It is worth noting that it is a week and week.
