Agile software development and extreme programming introduction

xiaoxiao2021-03-19 217

-------------------------------------------------- ----------------

Qiu Longbin

-------------------------------------------------- ----------------

This article is made by: This article is a summary of recording and experience in reading agility methods and extreme programming. Girking the company to learn from ISO9001 and CMMI3 custom quality control and process specifications, so organize the previous things

0. Software development

Let's take a look at the general product production:

Example 1, car production. Raw materials, accessories and other procurements (I said the purchase accessories, this is equivalent to transferring the production of some functions to other functions. Corresponding to software production (sub) project outsourcing. This topic is not expanded in this article), enter Production, assembly, test workshop, conduct a range of prescribed workflows. Under normal circumstances, if irresistible events do not have an irresistible event, the delivery specified in the contract can be completed on time. There will be no change and unpredictability in the middle.

Example II, then look at an example, such as someone wants to cover a house, he wants to use environmentally friendly materials, when the developer gives a sketch, price budget, he may change your idea. In the process of building a house, some of his ideas will gradually become clear. When the house is covered, the actual object is presented in his eyes, the original one of his decoration may also be adjusted according to the actual look of the house, such as the layout of the kitchen, the dresses of the master bedroom. In general, the prior plan encountered changes, stood in the "customer first" position, developing business to change the plan to meet the needs of customers. As for how to operate, it is a matter of contract negotiations. Customer change ideas have reason, because the original set is built in design (paper design, some development will provide 3D graphics or animation), customers will have further , More clear ideas.

Software development is also a productive industry, and his product is software delivered to customers. The above examples are closer to the construction industry, and the demand will change, and every production is not the same, even bigger. More exceptional, software development workload and time is estimated to have uncertainty than building production. This uncertainty comes from demand variations, fund support, technical risk, personnel flow, quality control, and functional range determination.

(In general, general customers can only specify three variables "cost, time, quality, range", and another is the development team to choose, such as customer preparing to spend $ xxx at the end of this month to implement all function points So under pressure, quality choice is to develop teams to determine; otherwise you have to adjust the other three variables selected by customers. - These four variables come from "hug changes", extreme programming.

Overall, the essence of software production is a new product development.

What are the characteristics of new product development?

It is not possible to create a constant, detailed specification in the previous period.

It is difficult to perform expected analysis during the start phase. along with

Experience data

The possibility of planning and estimation will increase accordingly.

It is unlikely to identify, definition, scheduling, and all detail activities in the start phase. Adaptive steps can be pushed by building a feedback cycle.

The general situation is that active adaptation is not defined changes, and the change is relatively high.

It corresponds to innovative new product development to have predictable manufacturing. It can have a bulky pre-specification, estimate, estimated plan, etc. New product development refuses these "reliable" pre-specification, the reason is:

Customers or users cannot know what they want. (You need to make it clear through step-by-step communication and guidance)

They are difficult to state all needs and knowledge.

Many of the details they want can only be gradually displayed during the development process.

Details may be too complicated to them.

When they see the development of the product, they will might change the original intention.

External pressure (such as competitors or services) lead to changes or increased demand.

1. Some statistical data and general conclusions in recent years

It is because software development is not a predictable production activity of the rules, but there is a new new product development activity, so many software projects that follow the predictable product production methods will eventually returned, whether it is a small company or Well-known enterprises. This is a case where new product development is definitely, and of course there is a problem.

Let us look at the research and statistics in the field of software development, which shows the basic situation of software project development in recent years:

Figure 1. A relationship with 23,000 projects "successfully implemented - duration", "successfully" defined "The project is completed during the fund budget and project work, and has all pre-specified features and features." (Standish98 Jim Johnson, et al. 1998. CHAOS: A Recipe for Success, 1998. Published Report. The Standish Group (You can use this definition to measure how your company's project success rate is.)

Figure 1. Relationship details of project success rate and project duration

(The abscissa is the project duration (how many months); the ordinate is the ratio of the success of the project)

From this figure, we can see that the success rate of short duration of the project is relatively high. It can be seen that small projects are easy to succeed. In addition, research shows that the team's projects are easier to succeed.

Figure 2. Situation showing the increasing change of changes in the software project development. The size of the project is measured by function point, corresponding to horizontal coordinates in the figure; the ordinate indicates the change in demand, still in units of function. (Jones97 Jones, C. 1997. Applied Software Measurement. Mcgraw hill)

Figure

Relationship between demand changes and project size

From this figure, we can see that demand changes cannot be circumvented, typically, a project must face the demand change, just as the front cover example. Demand changes also affect the success rate of the project. (The success here still complies with the previous definition.)

Figure 3. It is a function point in demand management to achieve the ratio of the actual usage after software product delivery, this ratio is very amazingly indicating that almost half of the function is even used, quite a number of features are also very small. use. In the competitive product market, these functional points may be selling points, thereby also increased the volume, complexity of the project, affecting the success rate of the project, delivery date. Non-competitive areas should be considered again to these needs :-) Press 20-80 principles, 20% of the function has 80% of the product) (Johnson02 Johnson, J. 2002. Keynote Speech, XP 2002, SARDINIA Italy.). In addition, based on risk and customer drive, you can maximize the most commonly used functions. Thus, an item can become a more useful phase-issued release when a project is completed with its 20% function.

Figure 3. Differential use of the product in the actual use

In addition, there is evidence that with the increase of function points, each developer's production efficiency decreases, and each developer's error rate rises. (Jones00 Jones, C. 2000. Software Assessments, Benchmarks, And Best Practices. Addison-Wesley). In addition, there is a large part of the failure item in the failure project is a waterfall model. 2. Waterfall model vs. iterative model

What kind of worldview is there, what kind of methodology will be. The universe is not changed. There is no absolute stationary. The software project is also the same. There is a series of linkage relationships between changes in demand, changes in capital investment, team personnel, change in mass range, time limit change, etc. have a series of linkage.

There are two opposite attitudes to respond.

Through the determination input in the phase, the output is avoided, and the input is confirmed to be fixed (reviewed), which can be designed to generate the desired next output. This is the so-called "push" mode, this method seems to avoid the change, pay attention, our previous figure 2. Said that even if the functional point change is also common, this change is known. And the response is actually postponed to the post-customer acceptance phase of the project.

Another attitude is actively responding to this change, and the entire process of project development encourages the addition of new demand.

If you ignore many arguments, it is generally, trying to circumvent or say that the linear development method of obtaining a demand in place is to correspond to the "Waterfall Model", while positive response changes through multiple repeated incremental processes. It is "Iterative Model". It is necessary to explain that the inventors of the waterfall model say that he is the support of the iterative model, it just thinks that the waterfall model is the simplest model in software development.

Let's take a look at some pictures, Intuitively look at these two models.

Figure 4. It is a waterfall model and its high risk drawing. From this figure we can see that over time, the risk increases. It is because of the early low risk, it makes people like to use this model for a long time. Fear of risk is a common problem of humanity. And this model is simple, a monotonous process, easy memory, is also simple to operate. Demand - Design - Implementation - Test.

Figure 4. Waterfall model and its high risk diagram With more and more evidence, the waterfall model itself has changed since the high-risk and high failure rate of the waterfall model, so that some people continue to use this model change Body is developing project development. As I have written in previous documents, this model generally is not suitable for software development.

Figure 5. It is the overall cost relationship between the waterfall model over time, newly increasing change factors (such as demand changes, etc.).

Figure 5. The overall cost of the change of the waterfall model

An important issue in this model is lack of feedback. He is done by unidirectional control and believes this control is correct, such as from Analysis -> Design, designed according to the analysis of the resolution, and believes that this Analysis is correct. This is similar to the marching, each superior thinks his instructions are implemented correctly, the correctness of this instruction is not talking about (this involves professionalism of the control personnel of each layer), obviously will appear in the foreign army Uncomfortable situation, or lose a million, a thousand miles. Its control process is a PUSH, a layer of layers push down, as shown in Figure 6. Here only one of them is intercepted.

Figure 6. A fragment in the PUSH mode has learned a control theory knows that a simple reason, "FEEDBACK, no control". The basic principle of feedback is to feed the output to the input. If the deviation is large, the control process is adjusted, and eventually make the output to meet the needs of the input. Overall, the input of software development is the customer, the output is a software product, and the control process is the development process of software projects. If it is just one-time delivery to the customer, it is clear that there is no feedback. The process is linear: "Customer-> Project Implementation -> Customer" such a process, the risk is very, so you should cooperate with customers, how many processes are made more, let the entire development process adaptive, and finally delivered Successful product. Figure 7. Down: Figure

Feedback, adaptive process

Figure 7. The process of project development, is a multiple iteration. Each iterative process is a specific and micro "demand-design-implementation-test" monotonic process. It is this multiple iteration, which reduces the risk of final delivery of products.

Let us look at the iterative process, the figure below:

Figure 8. Iterative process diagram Each iterative process is a specific and micro "requirement - design - implementation - test", through such a small step, gradually constructed into a complete system. As shown in Figure 9. Multiple iterations, system incrementally perfection.

Figure

Multiple iterations, system incremental type is improved

Over time, the focus of each iteration is different, Figure 8. We can see that during the early iteration, the specific gravity of demand is large, and the medium term is the specific gravity of design and implementation. Test is a relatively important link :-). Test is controlled from beginning to end, reducing risks. The figure below shows the contrast of the waterfall test and iterative test.

Each iterates, complete the risk of high-level risk (corresponding to)

User-stories

). Each time you are determined

User-stories

When you are allowed to join the new demand, once the next iterative process is to be implemented

User-stories

After the list, this list is not allowed until this iterative process ends. By the way, all

User-stories

The list is the basis for the final function test and acceptance test.

User-Sotiry

Unlike

User-case

, Simply, can

User-story

Be seen as

User-case

The description section is easy to write. The details are refined in each iterative iterative design phase, and then simply designed, just enough to meet the application. Complex design will have a lot of questions, do a collective project, not when you express code skills.

Figure 10. Overall cost trend of introduction of changes in the iterative process

Every iteration begins to join new demand changes, so that gradually reduces the risk of product completion, the overall cost diagram of the iterative model for changes is shown in Figure 10.

One advantage of multiple iterations is to be more accurately estimated. Do not build prototypes, light is talking on paper, it is difficult to accurately determine the project's construction / work time and workload (moon). The so-called prototype can be a discarded or non-discarded, and the purpose of this prototype can also be used to obtain a customer and obtain a winning chance. More importantly, it can be used to estimate the workload and time of the project, because of your team, the number of function points completed by the previous iteration of this model, can process the production efficiency and continuity of your team. The speed of progress. Thus, how to determine the time of the project. Here is a figure shows the uncertainty of estimating project time:

Figure

11.

After the initial iteration, the time schedule can be substantially estimated.

In addition: You can study how the "Agile Iterative Development - Manager Guide" on how to sign two-stage contract: If I am from Party A, I will give me the company in the first stage to prepare for bidding. A prototype of the demand (can be a sketch), eventually winning, and paying a single job. As for contractual things, specific operations are studied by the marketing department. How to operate: P) In short, Waterfall-Like Model is implemented, and it is necessary to experience rich, no matter which stage is. (Experience and uncertainty) We can see Figure 12.) For example, the demand analysis phase, the ability to obtain demand, analyze the ability to analyze the needs; the design phase is even more such, even before the entire project is formed, in this designer's brain There is already a branched project tree, all incomparable, and even which branches of the branches, how to make the size, color, maturity, and the wind blowing of X-direction, how to do sports, etc. . If you don't have the same project, you have designers who have such precise design. You tell me, I will go to visit and ask for advice. What's more? Is there a project group? ! . Tutor Stalin said: Developing the right policy, we must rely on the party's cadres. And don't say there is an omnipotent leader person, but also a loyal and unsatisfactory business level. Every process must not have any objection (objection is some feedback). The class waterfall model is this system, which seems to be out of date. (Team members know that I have several incisive software engineering and software development metaphors, I don't know how everyone thinks this metaphor / (^ o ^) /, such as why multiple inherited trouble and object model is difficult to do.)

Figure

12.

Relationship between experience and (estimation, estimating design) uncertainty

The iterative model is suitable for responding to varying, the technical level is general, but there is a small and medium-sized project team that has advanced positive winning. In the face of complexity, it emphasizes the importance of feedback in terms of quality assurance, emphasizes the community and exchanges in decision-making, and emphasizes courage in technical difficulties and technical risks. No value belief, it is difficult to let the team members take the inertness. Push mode members, habitual "CODER" (especially the project is in auditing, demand analysis, summary design, detailed design, document review phase, CODER is doing it?), Not a "software engineer". In this street, it is a "customer manager", "sales engineer" era, called a professional degree to be a general "codec", even if the salary is attractive, professional prospects are not obvious. People who have advanced heart will have a moving idea. This is reasonable.

3. Several important methods of iterative mode (as an example of XP) Take a horse

Agile method is in the position of the coordinate diagram, as shown in Figure 13. The ordinate is the strict level of the waterfall model; the abscissa is the formal extent of the document. The UP (unified process) is an iterative model. It has a formal document. If you use the UP process, it will find that it will form a large number of documents, charts, uml use-case, etc., iterative cycle scalable range Big. In fact, it is most famous in RUP.

Figure

13.xp

Schematic diagram of several other agile methods

Let us focus on XP (EXTreme Programming), which is an incremental iterative (IID) development method created by Kent Beck. This approach improves user satisfaction by rapidly creating high-value software, skills, and smooth software development technologies and flexible response variations. It is mainly suitable for small and medium-sized teams, and the delivery date is a year. The limitation means that all kinds of good practices can be played, I mentioned in the unit test lecture.

There are only some informal workpieces, such as the total feature requirements index card, called Story-Cards. Important practice of XP (around these practices, training should be trained: - *):

Figure

14. XP

Important practice

Each practice is worth going to study. For those who have controversial, seek a compromise solution, and it is better than no program. I will not say it. You can compare Figure 15. Look at the implementation of these practices: Figure 15. Feedback from XP

So many practices must be guided by people. So just started

The team is equipped with a coach. More important to make everyone agree with this way. Mengfu said

No occurrence of no worries!

. Fighting millennium, I add a sentence

People worthless belief

. A development team, a development model to establish a belief, a value, below

Value,

Also

Top weight:

communicate with

The importance of communication is self-evident, but still encourages encouragement. The daily item of the project group

Minutes of the rest of the day, understand the tasks and items of the day. Immediate exchange between developers is designed and encoded. Customer participation and promotion communication with customers, and its way is to write acceptance tests and plan games. In short, there is no software development without communication. It's big enough.

Simplicity

Simpality means

Do just enough

. Simplicity refers not only to design, but also refers to requirements, project management tools, etc. For example, project documentation, your three or five teams, have time maintenance of the upper layer of document? Especially I want to say that it is a design document, and it is the detailed design document. think

Don't use the detailed design is misunderstood, it is getting

User-stories

After that, the time before encoding is simple to design.

Do not reject the document, but think it is a cost,

Confident (documentation) code is the best document. Not too lazy, don't want to write a document, it is to maintain this document three times or more. Time: I draw a lot of discussion on the whiteboard, you must first copy, then write it into a standard

Word

Openoffice

Document, I have to draw pictures,

UML

I have to draw again. So simplify it: draft, line, archive! Whiteboard, line, photo archive. Will sufficient personnel and time sneak?

Improve the documentation when knowledge sharing and training in the project productization stage! Formulate the draft of the archive. Different designers always tend to adopt exquisite, complex design, as if they don't have a good designer; this complexity also brings problems to exchange and understanding, more likely to affect other simple design Cooperate with you

Exquisite design

To do complex changes.

Feedback

Feedback guarantees quality and adaptation. Customer writing

User-story-card

When programmers can assess them immediately, such customers know the workload. Test the first line has feedback, and there is feedback in Xiaji etiquette and continues to integrate. Project tracking personnel get daily

User-Sotries-List

Follow the trace record feedback of the completion situation, the client has an important feedback, etc.

courage

In the face of a bunch of code, even if you are writing, do you dare to change? If you have a change, there will be no problem? Further, do you dare to make a major change? Without the value beliefs and practices in front, you must not say confidence. Our beliefs and practice have now made a lot of things: unit testing, acceptance testing, continuous integration, reconstruction code, consistent coding specification. With these guarantees, you have more courage than before :). In addition to the discomfort changes, courage also includes new knowledge. In the face of new technologies, keep a young heart!

Life cycle:

Test phase

purpose:

Fully assess the first iteration

Story-cards

Feasibility

activity:

Establish a prototype (

20%

The demand is the most important infrastructure, the previous discussion)

Technical demonstration

- Sotry-Cards

Writing and evaluation

Publishing Planning Game (Release Planning Game

)

purpose:

Date of the first iteration and

Story-cards

Reach a consensus

activity:

Publish plan activity

Story card (

Story-cards

Writing and evaluation

Iterative plan game

(Interation Planning Game)

)

purpose:

Clarify this iterative task

activity:

Users from

User Stories

Determine the most valuable feature as the goal of this iteration

Join the last iteration and did not pass the acceptance test

User-stories

Iterative development

purpose:

Implemented in an iterative cycle

User-stories

activity:

Simple design, test, pair programming, reconstruction

, Iterative testing and continuous communication cooperation with customers on demand details

release

(

If there is no work before the release, return to

Iterative Planning Game Stage

)

purpose:

Product, release products

activity:

Product documentation, skills training and team knowledge sharing, exclude project

Ideas

Phenomenon (in real rotation matching reduces the existence of intellectual islands, the knowledge is island lets developers don't know other parts of the software, this is a disaster period)

product release

Maintenance period

(slightly)

XP workpiece, role and practice:

➢

Workpiece (no documentation, in addition to software, what is the other?

)

Story-cards -

Record the needs of concise characteristics (non-

Use-case

And the scene) paper card, indicating that the need for further detail, granularity

2-10

day.

It is a feature drive not to be driven by an example.

)task list

Each iteration is targeted

Story

Written task list card or table, task grain size

1-2

day.

) Visualization chart

Used to facilitate communication.

➢

Character

client

Write a story

(Stories)

Acceptance test

Select the story for publishing and iteration

Develop

programmer

Write tests, design, and code

Reconstruct

Determine, receive the task

Estimation

Develop

Tester

Help customers write and develop tests

management

coach

(experienced

Teams can not be set)

Process counseling

Process customization

Intervention and training management

Project tracker

Collection metric

Report progress

Feedback based on simple estimation

other

consultant

Wait

Technical consultation and guidance

➢

practice

Corresponding to demand: (Who said

Do not do demand, but also continue to get demand! )

Planning game

On-site customer

Acceptance Test

design:

System metaphor

Frequent reconstruction

Simple design

achieve:

Frequent reconstruction

Coding standard (consistent style, documentation

(

Such as

Doxygen

) Note, this can be the best design and implementation of documentation)

Pair programming

Code ownership return team

Test and verification:

Acceptance test, customer test

Test a first development unit test

On-site customer

Project management:

Planning game

Small release

Stable work progress

Standing a short meeting

Configure and change the management environment:

Continuous inheritance

Public room

Planning game

Core practice and description:

(Taken from

Craig Larman

Agile and ITERATIVE DEVELOPMENT: a Manager's Guide

)

Do not translate, look at the original.

practice

description

The entire team works together, or at the on-site customer participation

The whole team-programmers and customers-work together in a common project room One or more customers sit more-or-less full time the team with;. They are expected to be subject matter experts and empowered to make decisions regarding requirements and their priority .

The customer contribution includes detailed explanation-to the programmers-of the features briefly summarized on story cards, Planning Game participation, clarification, and writing acceptance tests in collaboration with a programmer.

........................

The first release of xp spoke of online.

Small and frequently released

Evolutionary Delivery. Not Applicable To All Projects. NOT To Be Confused With Organizing One Release Cycle Into Many Short Items.

test

Acceptance test and customer test

Testing practices in XP are very important. All features must have automated acceptance (functional) tests. All tests (acceptance and unit) must run with a binary pass / fail result, so that no human inspection of individual test results is required. The acceptance Tests Are Written with Collaboration of The Customer-They Define A Testable Statement of What Acceptance Means. This Is Called Customer Tests in Xp. Test

Test driver development and customer testing

Unit tests are written for most code, and the practice of test-driven development (and test-first development) is followed. This includes the practice that the unit test is written by the programmer before the code to be tested. It is a cycle Of Test õ Code, Rather Than Code õ Test. Usually, The Open-Source XUnit Testing Framework Family (SUCH AS JUNIT) IS Applied (See

Www.junit.org

). All Acceptance and UNET TESTS Are Automatically Run Repeatedly in A 24/7 Continuous Integration Build and Test Cycle.

See p. 292 for a detailed example.

Publish plan game

The Release Planning Game goal is to define the scope of the next operational release, with maximum value (to the customer) software. Typically a half-day one-day session, customer (s) write story cards to describe features, and developers estimate them. There may also exist story cards from prior exploration phase work. The customer then chooses what's in the next release by either 1) setting a date and adding cards until the estimate total matches the time available, or 2) choosing the cards and calculating The Release Date Based on Their Estimates.

Iterative plan game

The Iteration Planning Game goal is to choose the stories to implement, and plan and allocate tasks for the iteration. It happens shortly before each new iteration (1-3 weeks in length). Customer (s) choose the story cards for the iteration. For each, programmers create a task list (on cards or whiteboard) that fulfill the stories. This is followed by a volunteering step in which the programmers choose a set of tasks. They then estimate their task lengths. If tasks are not estimated in the Half-day to two-day range, they area refactored. Simple design

Avoid speculative design for possible future changes. Avoid creating generalized components that are not immediately required. The design should avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible.

Pair programming

All production code is created by two programmers at one computer; they rotate using the input devices periodically Pairs may change frequently, for different tasks The observer is doing a real-time code review, and perhaps thinking more broadly than the typist, considering.. Tests and so forth.

Certainly, team productivity is not simply a function of the number of hands typing-it is more nuanced. The XP claim is that the combination of cross learning, the peer pressure of more disciplined practice observance and more hours actually programming than procrastinating, defect reduction Due to Real-Time Code Review, And The Stamina and Insight To Carry On When ONE Programmer is Stuck, All add up to an Overalll Team Improvement.

Frequent reconstruction

Refactoring in the XP context is the continual effort to simplify the fine-grained code and larger design elements, while still ensuring all tests pass. That is, cleaning the code and design, without changing functionality. There is supposed to be "lots" of refactoring in XP. This practice is also known as continuous design improvement.The goal is minimal, simple, comprehensible code. It is achieved by small change steps, verifying tests after each, and ideally the use of refactoring tools, now available in some IDEs .

Code belongs to the collective

Any pair of programmers can improve any code, and the XP value system is that the entire team is collectively responsible for all the code The value of "it's her code, and her problem" is not endorsed;. Rather, if a problem or chance To Improve Is Spotted, It's The Spotter's Responsibility. A RevelTed GOAL IS FASTER Development by Removing The Bottleneck Associated with Change Requests in an Individual Code Ownership Model.

The obvious danger of modifying code one did not originally write is ameliorated in XP by some of the other practices: The guaranteed-present unit and acceptance tests running within an automated continuous integration build process inform you if you broke the code, your pairing partner brings .

Continuous integration

All checked-in code is continuously re-integrated and tested on a separate build machine, in an automated 24/7 process loop of compiling, running all unit tests and all or most acceptance tests. There are several open-source tools for this, Built On The Ubiquitous Ant Technology, Including CruiseControl and Anthill.

Stable work rhythm

Frequent overtime is rightly considered a symptom of deeper problems, and does not lead to happy, creative developers, healthy families, or quality, maintainable code. XP does not support it-rather, it promotes "no overtime." Standup

With collective code Ownership, Frequent Refactoring, and Regular Swapping of Pair Programming Partners, Everyone Needs to Follow The Same Coding Style.

System metaphor

To aid design communication, capture the overall system or each subsystem with memorable metaphors to describe the key architectural themes. For example, the C3 payroll system was described in terms of an assembly line of checks with posting rule "machines" operating on them, extracting Money from Different "Bins"

Many Have Reported this The Least Necessary Practice.

Other practices and values:

On-site customer agent

- Many groups wishing to apply XP can not find full-time "ultimate" customers to work in the project room For example, consider a new internal system for (very busy) commodity traders And this problem is common for commercial products for an external.. market. The common solution is to designate customer proxies that do join the team in the project room, have good (though not as ideal as true customer) knowledge of the domain and requirements, and that represent the ultimate customers. If proxies are used, IT Is Important That The True Customers at Least Participate in End-of-Iteration Demos, And Preference, In The Planning Games.

Contact customers at any time

- When the Onsite Customer Is Not Present, Arrange Matters So That The Customer Representative IS Committed to Fast Access, Such As Via a Mobile Phone.

Hug

- The Overarching Attitude That XP Promotes Is To Embrace Rather Than Fight Change, In The Requirements, Design, and Code, and Be Aable To Move Quickly in response to change.

Completely voluntary

(

Accept task

) -.. Tasks are not assigned to people Rather, during the Iteration Planning Game, people choose or volunteer for tasks This leads to a higher degree of commitment and satisfaction in the self-accepted responsibility, as has been explored in [DL99].

Very lightweight model

- XP encourages programming very early and does take to "extreme" the avoidance of up-front design work Any more than 10 or 20 minutes of design thinking (eg, at the whiteboard with sketches or notes) before programming is considered excessive Contrast.. This With Scrum or the Up, For Example, WHERE A HALF-DAY OF ITERATION IS ACCEPTABLE.

Minimum or

Just enough document

"- With the goal of getting to code fast, XP discourages writing unnecessary requirements, design, or management documents The use of small paper index cards is preferred for jotting brief descriptions, as are verbal communication and elaboration Note that the practice of.." Avoiding Documentation "Is Compensated by the Presence of An Onsite Customer. xp is not Anti-Documentation, But Notes It Has A Cost, Perhaps Better Sprent On Programming.

measure

-. XP recommends daily measurement of progress and quality It does not mandate the exact metrics, but to Examples include numbers of completed tasks and stories, and number and success rate of running tests "use the simplest ones that could work.".

Wall chart

- The Collected Metrics Are Daily Updated On Wall Graphs for All to Easily See.

Track and daily tracker

- The regular collection of task and story progress metrics is the responsibility of a tracker This is done with a walk-about to all the programmers, rather than email; commenting on this-and very telling of the XP attitude-Ron Jeffries (one. SAID, "XP is about people, not computers." TEST Metrics Can Be Automatically Collected by Software.

Increasing infrastructure

- XP recommends (as do the other iterative processes) that the back-end infrastructure (for example, a persistence layer) not be the main focus of implementation in the early iterations, but rather, only enough is implemented to satisfy the user-functional Requirements of each ity.

Public project studio

- XP projects are run in a common project room rather than separate offices Pair programming tables are in the center of the room, and the walls are clear for whiteboard and poster work Of course, people may have a private space for private time,.. But Production Software Development Is A Team Sport in XP.

Daily standing meeting

- AS in Scrum, There is a Daily Short Stand-Up (To Keep It Short) Meeting of Status.

Ideal Engineering hours

(IEH) - Task Estimates-And Possibly Story Estimates-Are Done in Terms of IEH, or Uninterrupted, Dedicated, Focused Time To Complete A Task.

Story assessment

- To Estimate Larger Stories, Some XP Practitioners Recommend Using Only Coarse Values of One, Two, or Three Week Duration Rather Than Ieh or Day-Level Estimates.

Too much text, still see some charts, everything is not in not saying!

Figure 16. is an overview of the Extreme Programming Project Process

Figure

16. XP

Project Overview

The figure below is the XP iterative process.

Figure

17. XP

ITeration

The picture below is the development of XP. Figure 18. XP DEVEOPMENT map -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------------- The picture below is the collective code of XP, which is actually how to develop. Figure 19. Collective code of XP All

4. Several questions in our direction and important research

First, it is clear that the class waterfall model is definitely not suitable for software development. XP is not a hacker's writing edge change method. Learn from iterative models and agile development methods is bound to be, and all or part of important methods and practices have been used on past projects (I know on the project of SWORK Cao & Robin Qiu). In fact, breaking, these important practices are more or less contained. It is clear that the direction of agile software development is to explore and study in several places. For example, how to carry out business negotiations, the contract is signed; how to let customers or their agents to join the development team or to communicate in time; how to do release plan Game; how to be iterative planning game; how to make a short-time standing meeting; how to make simple design; refactoring; how to automate unit testing and continuous integration; acceptance test, and product chemical process learning And knowledge sharing.

In general, in such a team, the project members can get exercise and knowledge accumulation, not such a boring, lack of communication and self-confidence, lack of courage and fatigue in the Push mode. . Therefore, it can enter a positive, easy to communicate, a cooperative atmosphere, and have a good circulation of a sense of accomplishment.

Software development has a bitter and happiness. One of myself was alone alone alone, three months of stuffy, to see the point to see the computer, there is no fun, boring, and the project is not complete. As a programmer, we will find someone to entertain yourself. For example, SUNWAH is the most qualified programmer Daniel Cao on Play Violin, the past is a, should there be a melody? ! .

5. Scenes and templates of XP

XP has a sample project, but I didn't see it to get those information.

I have not collected more pictures. Here is some, there is an important link. Everyone must look at it. If all copied, the space is too big.

Development site, Figure 20. Down. People who have seen Microsoft know that on the walls of the conference room, the walkway and even the room glass window is full of charts. This picture does not have the exaggeration of Microsoft.

Figure

20.

Common development site, air out of all wall spare

Stand in the meeting, shown in Figure 21. In fact, we are also so meeting :) Sitting will be easy to run, time is not well controlled, standing, time is tired, thinking about the snack.

Figure 21. 10 minutes a day

The length is too big, see an important link

XP Team Room (http://www.scissor.com/resources/teaMroom/)

I give a picture, causing everyone's interest first!

Figure

22. XP

Team studio one corner

6. Appendix

Agile Software Development Declaration

· Individual and interactive process and tools

· The software that can work is better than the document

· Customer cooperation is better than contract negotiations

· Response change is better than planning

That is, although it is also worth it, we believe that the items on the left have greater value.

The principle of agile software development we follow the following principles:

What we have to do is to make customers satisfied by doing valuable software as soon as possible. 2) Even later, it is also welcome to change demand. Agile process uses changes to create competitive advantages for customers. 3) Software that is often delivered, the interval delivered can be delivered from several weeks to a few months, the shorter the time interval delivered, the better. 4) During the development of the entire project, businessmen and developers must work together every day. 5) Build a project around an individual that is embraced. Give them the required environment and support and trust them to complete the work. 6) The way the team is internal and between the team, the most effective and efficient delivery information is the face-to-face conversation. 7) The software that can work is the primary progress metric. 8) The agile process advocates a smooth development. 9) Sponsor, developers and users should be able to maintain a long-term, constant development speed. 10) Continuously pay attention to excellent skills and good designs will enhance agile capacity. 11) Simple - to maximize unfinished work - it is fundamental. 12) The best architecture, demand and design are self-organized teams. 13) Every time, the team will reflect on how to make it more effectively, and then adjust their behavior accordingly. 7. Reference

Craig Larman - Agile and ITERATIVE DEVELOPMENT: a Manager's Guide

Auer, K., And Miller, R. 2002. - Extreme Programming Applied: Playing to Win. AddIn-Wesley.

Kent Beck, Cynthia Andres - Extreme Programming Explained: EMBRACE CHANGE, SECOND Edition

Ambler, S. 2002. - Agile Modeling, John Wiley & Sons

Larman, C. 2001. - Applying Uml and patterns: an introduction to oa / d and the unified process, 2nd edition.

Mike Cohn - User Stories Applied for agile software development

Ivar Jacobson, Grady Booch, And James Rumbaugh, Rational Software - The Unified Process

http://www.extremeprogramming.org

http://www.xprogramming.com

Paul Hamill - Unit Test Frameworks

David Astels - Test-Driven Developments: a Practical Guide

Martin Fowler - Refactoring: Improving The Design of EXIXANG CODE

Robert C. Martin - Agile Software Developments: Principles, Patterns, And Practices

8. Postscript

I originally wanted to write an article about the waterfall model and iterative model. Later, since there was related information to be quoted, it also introduced some agile software software development and limit programming, and I personally compare XP practices in agile methods. So many parts are XP aspects.

It takes time to write a document, and I don't have a graphic graph to seriously, then copy it. I feel that there are still many places to do better, and there are many places and need to be expanded. At this stage, our status quo is to extend the document space; after you are familiar with these processes, you can explicitly collar, and achieve the effect of the view. That is, the document is thinned. A sentence:

It is easy to have a complex thought.

It is difficult to have a simple thinking.

- Carver Mead

2005-10-18

Robin Qiu at SWHSS

转载请注明原文地址:https://www.9cbs.com/read-130208.html

9cbs

New Post(0)