Edit me

The following pages and posts are tagged with

TitleTypeExcerpt
Values of Extreme Programming Post Note: For more information, review the eXtreme Programming archetype. Simplicity Communication Feedback Respect Courage
Simplicity Post As defined in eXtreme Programming (XP) We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create...
Respect Post As defined in eXtreme Programming (XP) Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over...
Feedback Post As defined in eXtreme Programming (XP) We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way...
Courage Post As defined in eXtreme Programming (XP) We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen. (via extremeprogramming.org/values)...
Communication Post As defined in eXtreme Programming (XP) Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together. (via extremeprogramming.org/values)
Principles of Extreme Programming Post Note: For more information, review the eXtreme Programming archetype. Fundamental Principles Rapid FeedbackAssume SimplicityIncremental ChangeEmbracing ChangeQuality Work Further Principles Teach LearningSmall Initial InvestmentPlay to WinConcrete ExperimentsOpenhonest CommunicationWork with...
Practices of Extreme Programming Post Note: For more information, review the eXtreme Programming archetype. XP’s philosophy on Practices is very non-prescriptive, and advises an explorative approach, based on the XP Principles and XP Values. Practices recommended by Kent Beck Practices as presented in “eXtreme...
Whole Team Post Note: For more information, review the eXtreme Programming archetype. All the contributors to an XP project sit together, members of one team. This team must include a business representative – the “Customer” – who provides the requirements, sets the priorities, and steers the...
Test Driven Development Post Note: For more information, review the eXtreme Programming archetype. Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice “test-driven development”, working in very short cycles of adding a test, then making it work....
Sustainable Pace Post Note: For more information, review the eXtreme Programming archetype. Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that...
Small Releases Post Note: For more information, review the eXtreme Programming archetype. XP teams practice small releases in two important ways: First, the team releases running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose,...
Simple Design Post Note: For more information, review the eXtreme Programming archetype. XP teams build software to a simple but always adequate design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the...
Design Improvement (Refactoring) Post Note: For more information, review the eXtreme Programming archetype. Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well-designed. The alternative would be to slow down and ultimately...
Planning Game Post Note: For more information, review the eXtreme Programming archetype. XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project – which is...
Pair Programming Post Note: For more information, review the eXtreme Programming archetype. All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and...
Metaphor Post Note: For more information, review the eXtreme Programming archetype. Extreme Programming teams develop a common vision of how the program works, which we call the “metaphor”. At its best, the metaphor is a simple evocative description of how the program works, such as...
Customer Tests Post Note: For more information, review the eXtreme Programming archetype. As part of presenting each desired feature, the XP Customer defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove...
Continuous Integration Post Note: For more information, review the eXtreme Programming archetype. Extreme Programming teams keep the system fully integrated at all times. We say that daily builds are for wimps: XP teams build multiple times per day. (One XP team of forty people builds at...
Collective Code Ownership Post Note: For more information, review the eXtreme Programming archetype. On an Extreme Programming project, any pair of programmers can improve any code at any time. This means that all code gets the benefit of many people’s attention, which increases code quality and reduces...
Coding Standard Post Note: For more information, review the eXtreme Programming archetype. XP teams follow a common coding standard, so that all the code in the system looks as if it was written by a single – very competent – individual. The specifics of the standard...