> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/management-workflow/coding-process/xtreme-programming.md). # Xtreme Programming (XP) ## what is it? * methodology for teams that face of vague or rapidly changing requirements. * only do what you need to do to create value for the customer. * A way to: Stay aware. Adapt. Change. * To help in improving the ability to cope with change * Distinguished by * short development cycles. * incremental planning approach. * ability to be flexible when the business needs change. * reliance on automated tests. * reliance on oral communication. * reliance on an evolutionary design process. * reliance on the close collaboration. * reliance on practices that work with both the short-term instincts of the team members and the long-term interests of the project. ### Values of XP * Communication * problems within a tema can be caused by lack of Communication. * this should be the first place to look at when problems occurs * How can your team now communicate in order to solve the problem and ensure that the same issue doesn't arise? * helps your team to bond and is a key component to effective cooperation * Simplicity * Focus on working on the simplest thing that could possibly work * Eliminate unnecessary complexity * Feedback * Shorten the feedback cycle as best as you can. * Too much feedback is counter productive * look to find the sweet point * Range of forms * Getting opinions from colleagues, books, internet * Evaluating code produced by yourself, others * How did testing feel * Did the code pass the tests * Does the code work * Courage * Effective action in the face of fear. * Courage may manifest itself * in a bias to action * to be patient to wait for a problem to reveal itself when you feel one approaching * to wait for a problem to reveal itself when you feel one approaching * to change a course of action can lend itself to finding simpler solutions. * Respect * contributions of each person on a team has to be respected * Needed for XP to work ### Principles * Principles guide behaviour * Principles give you a better idea of what a practice is intended to accomplish * Main principles * Humanity * Creating software * should meet human needs, maslov * acknowledge human fallibility * leverage human strength * Economics * everything you do has business value and serves business needs * Think about the 'time value of money' and the 'option value of systems and teams' * What you're building is more valuable the more it earns money sooner and spends money later * How flexible is your software for being used beyondoriginally intended purpose * balance enhancing the option value of the software and the team whilst not wasting money investing in speculative flexibility * Mutual benefits * Every activity should benefit all concerned * Self-Similarity * Try copying the structure of one solution into a new context, even at different scales * Improvement * Aim for excellence through constant improvement * Diversity * need to bring together a variety of skills, attitudes, and perspectives * Reflection * to expose mistakes and learn from them * How is your team working and why are they doing what they are doing? * Why did you suceed? * Why did you fail? * Flow * delivering a steady flow of valuable software by engaging in all activities of development simultaneously * Opportunity * View problems as opportunities to learn, improve, and change * Redundancy * Keep redundancy where it serves a valid purpose, that is, uncovering defects. You may have many practices that catch the same defects, but the defect problem in general cannot be solved with a single practice * Defects corrode trust and trust is the great waste eliminator * Failure * use it to learn from * When you don't know what approach to take, risking failure can be the shortest route to success. * Quality * Sacrificing quality is not an effective means of control. Aiming for higher quality often results in faster delivery; lowering quality standards results in less predictably delivery later on * Baby Steps * What's the least you could do that is recognizably in the right direction? * ou want to avoid 'wastefully \[recoiling] from aborted big changes'. * Accepted Responsibility * With responsibility comes authority. ### Practices * Practices need to be underpinned by values, otherwise they become rote. * Practices are also situation dependent. ## Primary Practices ### Sit together * sit with client * allow to communicate fully * physical proximity enhances communication * open spaces helps with ease of communication ### Whole team * The team needs the skills and perspectives necessary for the project to succeed * cross functional * People need a sense of team * belonging, shared purpose, support * The team is dynamic, should change members depending on needs ### Informative workspace * Make workspace about your work ### Energized Work * Only work for as long as you can be productive * prepared, rested, relaxed mind. ### Pair Programming * PingPong * Roles * Navigator and driver * Experienced or junior dev * Experienced or junior domain wise * These can be any combination. Need to adjust depending on what you are. * It's a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better. * Keep each other on task. * Brainstorm refinements to the system. * Clarify ideas. * Take initiative when their partner is stuck, thus lowering frustration. * Hold each other accountable to the team's practices. * Rotate pairs can be a good idea, * tiring but satisfying. * Pairing and personal space * Different individuals and cultures are comfortable with different amounts of body space. * Personal hygiene and health are important issues when pairing. * Ideally, emotions at work will be about work. * It is important to respect individual differences when pairing. * If you aren't comfortable, the team isn't doing as well as it could. ### Stories * Write stories around the framework of customer-visible functionality * As soon as a story is written, try to estimate the development effort necessary to implement it. ### Weekly Cycle * Plan work a week at a time * Have a meeting at the beginning of the week where you review progress to date and have your client prioritise a week's worth of stories ### Slack * Always leave room for tasks to be dropped if you get behind * You can also structure slack, e.g. hack days ### Ten-Minute Builds ### Continuous Integration * Integrate and test changes after no more than a couple of hours ### TDD * It addresses many problems. * Scope creep: if you really want to put that other code in, write another test after you've made this one work. * Coupling and cohesion: if it's hard to write a test, it's a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test. * Trust: writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you. * Rhythm: it's clearer what to do next: either write another test or make the broken test work. Code, refactor, test, code, refactor. ### Incremental Design * Make the design of the system an excellent fit for the needs of the system that day * design done close to when it is used is more efficient. ## Corollory Practices * Primary practices should be done first before attempting this. ### Real customer involvement * Make people whose lives/businesses are affected by your system be part of the team * Aim to reduce wasted effort * Increase trust with customer -> increased productivity ### Incremental deployment * Big deployments have a high risk and high human and economic costs. * Find a little piece of functionality or a limited data set you can handle right away. Deploy it. * Legacy: Implementing scaffolding between the two systems is the price you pay for insurance against big changes going wrong ### Team Continuity * Keep effective teams together * Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy ### Shrinking teams * As a team grows in capability, keep its workload constant, but gradually reduce the number of team members * Strive to improve efficiency until some of the team members are idle — shrink the team and continue * This frees people to form more teams. * When the team has too few members, merge it with another too-small team. ### Root-cause analysis * When a defect is found or a mistake occurs, eliminate its cause such that the team will never make the same mistake again * Write an automated system-level test and unit test that demonstrates the defect, including the desired behaviour * Fix the system so the unit test works. This should cause the system test to pass also. If not, return to the previous point. * Once the defect is resolved, figure out why the defect was created and wasn't caught. Initiate the necessary changes to prevent this kind of defect in the future. * Use the technique of the 'Five Whys' * The root cause is almost always a people problem ### Shared Code * Anyone on the team can improve any part of the system at any time * Until the team has developed a sense of collective responsibility, no one is responsible and quality will deteriorate. * People will make changes without regard for the team-wide consequences. * pair programming and continuous integration are interesting to try to avoid selfish conducts. ### Code and tests * Maintain only the code and the tests as permanent artifacts. * Generate other documents from the code and tests * Rely on social mechanisms to keep alive important history of the project. * The valuable decisions in software development are: * What are we going to do? * What aren't we going to do? * How are we going to do what we do? ### Single Code Base * Temporary branches should be short lived * Multiple code streams are a huge source of waste * Rather than add more code bases, fix the underlying design problem that is preventing you from running from a single code base. ### Daily Deployment * Put new software into production every night * If you are out of sync with what is in production you risk making decisions without accurate feedback. It is a risk * Prereqs for this: * Defect rate is down to a handful per year * Build environment is smoothly automated * Deployment tools are automated * Ability to roll out incrementally and roll back in case of failure * Highly developed trust within the team and with customers ### Negotiated Scope Contract * Write contracts that fix time, costs, and quality, but call of an ongoing negotiation of precise scope of the system * Sign a series of short contracts instead of one long one * Negotiated scope contracts are a mechanism for aligning the interests of suppliers and customers to encourage communication and feedback ### Pay-per-use * Money is the ultimate feedback. * Connecting money flow directly to software development provides accurate, timely information with which to drive improvement. * If you can't implement pay-per-use, you might be able to go to a subscription model. Then the team can focus on retention rates * Pay-per-release isn't a good option: the supplier is motivated to keep shipping releases with new functionality, whilst the customer wants fewer releases with more functionality, in order to avoid the pain of upgrades ## The whole XP team * The roles and responsibilities of different team members * Members can have multiple roles * The goal is to have everyone contribute the best he has to offer to the team's success * Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action. * Roles: * Testers * catching trivial mistakes is accepted by the programmers * Test-first programming results in a suite of tests that help keep the project stable. * help defining and specifying what will constitute acceptable functioning of the system before the functionality has been implemented. * coach programmers on testing techniques * Testers amplify communication by looking at 'happy paths' and asking about scenarios where things go wrong * Interaction designers * choose overall metaphors for the system, write stories, and evaluate usage of the deployed system to find opportunities for new stories. * Architects * look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories. * help choose the most appropriate fracture lines and then follow the system as a whole * keep the big picture in mind as the groups focus on their smaller section. * Project managers * facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organization. * keeping plans synchronized with reality. * facilitate communication within the team, increasing cohesiveness and confidence. * Product managers * help the team decide priorities by analyzing the differences between actual and assumed requirements * adapt the story and theme to what is really happening now. * Stories should be sequenced for business, not technical, reasons. * goal is a working system from the first week. * encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team. * Executives * provide an XP team with courage, confidence, and accountability. * articulate and maintain large-scale goals. * look for good software coming from the team and continuing improvement as well * free to ask for explanations about any aspect that dont makes sense. * Two metrics to measure the health of XP teams * Number of defects found after development. Each is an opportunity for the team to learn and improve. * The time lag between the beginning of investment in an idea and when the idea first generates revenue * Technical writers * provide early feedback about features and to create closer relationships with users * create closer relationships with users. * help them learn about the product, listening to their feedback, and addressing confusion with further publications or new stories. * Users * help write and pick stories and make domain decisions during development. * have a good relationships with a large potential user community * have knowledge and experience with systems similar to the one being built * Programmers * estimate stories and tasks, break stories into tasks, write tests, write code to implement features, automate tedious development process, and gradually improve the design of the system. * Have good social and relationship skills * Human resources * reviews * Hirings * XP teams put much more emphasis on teamwork and social skills. * best interviewing technique is to have the candidate work with the team for a day * Pair programming provides an excellent test of technical and social skills. ## The theory of Constraints * The Theory of Constraints says that in any system there is one constraint at a time * To improve throughput in a system you need to first identify the constraint * then think about how you can increase its capacity, * offload some of the work to non-constraints, * or eliminate the constraint altogether. * How do I identify a constraint? Work piles up in front of one * when you eliminate one constraint you create another * avoid micro-optimization and look at the whole situation before starting to make changes. * Software development is a human process not a factory. ## Planning: managing scope * starts with putting the current goals, assumptions, and facts on the table * With current, explicit information, you can work toward agreement about what's in scope, what's out of scope, and what to do next. * Planning is complicated because the estimates of the cost and value of stories are uncertain. * There is a limit to how much work can be done in a day * More time at the desk does not equal increased productivity for creative work. * Planning also involves deciding what to do next out of all of the possibilities. Plans are not predictions of the future. Rather, they provide you with a starting point and help you to coordinate with other teams. * Everyone on the team should be involved in planning. * Be prepared for the plan not to match reality. ## Testing: early, often, and automated * Defects destroy the trust required for effective software development. * Without trust, people spend much of their time defending themselves against the possibility that someone else may have made a mistake. * Defects are expensive when they occur * The direct costs of fixing the defects. * The indirect costs because of damaged relationships, lost business, and lost development time * Acceptable level is to reduce the occurrence of defects to an economically sustainable level. * eliminating software defects is also expensive. * There will always be defects. The key is to learn from them so there are no repeats. * The sooner you find a defect, the cheaper it is to fix it. * Software testing is double-checking * Beta testing is a symptom of weak testing practices and poor communication with customers. * Tests provide a measure of confidence and a measure of progress. ## Designing: the value of time * If you can generate value without feedback, designing sooner makes more sense * If experience creates most of the value, designing just enough today to get going and then designing mostly in the light of experience makes more sense. * Design is deferred until it can be made in the light of experience and the decisions can be used immediately * Deploy software sooner. * Make decisions with certainty. * Avoid living with bad decisions. * Maintain the pace of development as the original design assumptions are superseded. * Design always * Once and Only Once: DRY * Simplicity * Is it appropriate for the intended audience? The people who need to work with it have to understand it. * Is it communicative? Every idea that needs to be communicated should be represented in the system. * Is it factored? Duplication of logic and structure make code hard to understand and change. * Is it minimal? The system should have the fewest elements possible. ## User stories ## Iteration planning ## Spiking ## Coding standards ## Collective ownerships * All commits have both pairs name on it * Any issue with this code, either one of the pair is responsibile for any issues ## Bugs * New tests are writing for this * to expose the bug (red) * make sure bug is fixed (green) ## Practises ## links * * * * * * *