Presentation on theme: "Agile and Extreme Programming: A Pragmatic Approach"— Presentation transcript:
1 Agile and Extreme Programming: A Pragmatic Approach Neal FordApplication ArchitectThoughtWorksBlog: memeagora.blogspot.com
2 Questions, Slides, and Samples Please feel free to ask questions anytimeThe slides will be available atI’ll show that address again at the end
3 What This Session Covers The history and context of Agile development generally and Extreme Programming specificallyWhat makes XP a discipline and not just a random set of activitiesHow to gradually introduce Agile practices within an organization and still get the benefitsWhat to say to your bossWhat to say to your boss’s bossLots of questions and answers
4 Evolution of Methodology Lots of thought on this subject since groups started building software“Use of GOTO Considered Harmful” Communications of the ACM, DijkstraBy the 1990’s, we had arrived at the Waterfall methodologyAlso known as BDUF (Big Design Up Front)
6 Characteristics of Waterfall Methodologies Requirements are gathered up frontBusiness analystsEnd usersInterested departmentsMaybe a JAD (Joint Application Design session?)Requirements lead to designDesign leads to implementationImplementation leads to acceptance testingIt is deployed
7 Where Does Waterfall Work Well? Organizations where requirements don’t changeStable requirements leads to stable design…Stable design leads to “no surprise” implementationEtc.Who has requirements like this?NASA. . .Does this reflect your requirements?What happens when requirements change?
8 Changing Requirements The later in the development cycle that a requirement changes, the bigger the impact on the scope of the changeDocumented by Barry BoehmChanges to well established code may have a ripple effect, causing side effects in other codeHow can you make coding changes with confidence?
9 The Evolution of Agility Problem: much of the methodology work in software engineering has been based on traditional engineeringDesignImplementDeploySoftware is fundamentally differentIn its very natureThe way that people want to design, use, and modify softwareProblem: we’ve been trying to tell developers how to successfully write software…maybe we should find out how they work best
10 Lots of smart guys got together and re-thought how software is built AgilityLots of smart guys got together and re-thought how software is builtIn the nick of timeMost software projects failThe business risk of software development is far too highIt seems hard to predict what will cause one project to succeed and another failObserve successful projects and figure out what they did rightObserve unsuccessful projects and figure out what they did wrongThis led to the Agile Manifesto
11 17 Really Smart Guys met in Snowbird, Utah in February 2001: The Agile Alliance17 Really Smart Guys met in Snowbird, Utah in February 2001:Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, Dave ThomasThe agreed on a manifesto and supporting principles
12 The Agile Manifesto“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more”.The Agile Alliance
13 The Culmination of Current Thinking The ideas in the Agile Manifesto didn’t just fall from the skyThey had been percolating for several years in different formsThe Agile Manifesto just documented what a lot of people were already thinking
14 Principles of Agile Development Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Agile focuses on the delivery of softwareDelivering software early and often allows for quick wins and early feedback about the requirements, the team, and the processThe emphasis is to deliver the most important parts firstIf the project ends, there are still valuable artifactsDevelopment proceeds from most important to less importantNote that this may (and will!) change during the course of the project
15 Principles of Agile Development Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Most projects run 1 to 3 month cycles [Cockburn]Within the cycle, work is done in short iterationsIterations usually last from 2 to 4 weeksThe iteration is complete at the end of the iteration, at the expense of moving requirementsXP iterations are 2 to 3 weeksUsers review progress throughout the process
16 Principles of Agile Development Working software is the primary measure of progress.Code is the most important deliverableAgile methodologies place a premium on getting something up and running early and evolving it over timeAgile does not discard the need for design documentationDiagram to understand, then move to codeDocumentation is secondary to working code
17 Principles of Agile Development Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.This works because ofEarly and frequent delivery of running softwareUse of iterative and timeboxing techniquesContinual attention to architectureWillingness to update the designIf you can gracefully accommodate changing requirements and your competition cannot, you win
18 Principles of Agile Development Business people and developers must work together daily throughout the project.There is a strong correlation between links to users and project success [Frakes 1995]The best links are through onsite business expertise and daily discussionThe longer it takes to get information to and from the developers, the more damage will occur in the projectInformation flow is similar to convection currentsXP insists that business stakeholders are part of the development team
19 Principles of Agile Development Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.“It is better to have motivated, skilled people communicating well and using no process at all than a well-defined process used by unmotivated individuals.” [Cockburn 2002]“We hire good people, give them the tools and training to get their work done, and get out of their way.” [Thomas]
20 Developers are the KeyYou cannot overemphasize this point: developers, project managers, and business analysts make or break the project"All other factors being equal, a 90th-percentile team of analysts and programmers will be about four times as productive as a 15th-percentile team.“ [Boehm 1981]You should hire the smartest people you can find
21 Principles of Agile Development The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Communication is like air conditioningCockburn defines modalities of communications and their effectiveness (Agile Software Development, 2002)
23 Face to face communication about specific topics is most efficient Agile also takes advantage of “knowledge radiators”Simple, low-tech information storesPoster board with index cards or Post-it notesProject status beside the coffee potAutomated build report via web browser (I’ll talk about continuous integration later)
24 Principles of Agile Development The best architectures, requirements, and designs emerge from self-organizing teams.This means either that architectures, requirements, and designs emergein small steps over timeas a logical consequence of human-centric rules the team usesAll 3 must be allowed to adjust over timeAn architecture that grows in steps can follow the changing knowledge of the team and the changing wishes of the users
25 Principles of Agile Development Continuous attention to technical excellence and good design enhances agility.The design must evolveYou must create good designs initiallyYou must review and improve designs regularlyDesign cleanup as compared to debt [Cunningham 2001]Technical excellence applies to all aspects of the projectBuild managementCoding standardsCollaboration documentation
26 Principles of Agile Development Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Social aspectAn alert, engaged staff is more effect than a tired, plodding staffLong hours are a symptom that something has gone wrongOnly work 8 hours a day; never put in overtime 2 weeks in a rowTechnical aspectSoftware development can be viewed as a long strategic gameEach move sets up the next move
27 Principles of Agile Development Simplicity--the art of maximizing the amount of work not done--is essential.“This letter is longer than I wish, for I had not the time to make it shorter” Blaise PascalIt is sometimes more difficult to make things simplerA cumbersome model is easier to produce than a simple oneDRY principle (Don’t Repeat Yourself)“Design for simplicity; add complexity only where you must.” Art of Unix Programming, Raymond 2003“Code smell”
28 Principles of Agile Development At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.Constant awareness is keyNever get lazyXP encourages this every step of the wayQuestions:How light is too light?How simple is too simple?Can we make this simpler
29 Some Agile Methodologies Extreme programmingScrumThe Crystal MethodologiesCrystal ClearCrystal OrangeCrystal Orange Web
30 What Spawned Extreme Programming? In the early 1990s, Kent Beck was thinking about better ways to develop software.He and Ward Cunningham had experienced an approach to software development that made every thing seem simple and more efficient.Kent contemplated onWhat made software simple to createWhat made it difficultIn March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development -- the result was the Extreme Programming (XP) methodology.
31 The 4 XP DimensionsWhat Kent came to realize is that there are four dimensions along which one can improve any software project.You need to improve communication.You need to seek simplicity.You need to get feedback on how well you are doing.And you need to always proceed with courage.Communication, Simplicity, Feedback, and Courage are the four values sought out by XP programmers.
32 XP: Rules and Practices PlanningUser stories are written.Release planning creates the schedule.Make frequent small releases.The Project Velocity is measured.The project is divided into iterations.Iteration planning starts each iteration.Move people around.A stand-up meeting starts each day.Fix XP when it breaks.
33 XP: Rules and Practices DesignSimplicity.Choose a system metaphor.Use CRC cards for design sessions.Create spike solutions to reduce risk.No functionality is added early.Refactor whenever and wherever possible.
34 XP: Rules and Practices CodingThe customer is always available.Code must be written to agreed standards.Code the unit test first.All production code is pair programmed.Only one pair integrates code at a time.Integrate often.Use collective code ownership.Leave optimization till last.No overtime.
35 XP: Rules and Practices TestingAll code must have unit tests.All code must pass all unit tests before it can be released.When a bug is found tests are created.Acceptance tests are run often and the score is published.
40 Recall the 4 dimensions of XP Feedback LoopsRecall the 4 dimensions of XPYou need to improve communication.You need to seek simplicity.You need to get feedback on how well you are doing.And you need to always proceed with courage.The goal: a less extreme (pragmatic?) version of XPFirst pass: let’s get rid of the stuff that scares the boss and just do the rest
41 Why You can’t Pick and Choose Your Practices XP isn’t just a group of fun activities that fit together because Kent Beck says they doXP is carefully calibrated for feedbackRemember the diagrams for XP?
42 Feedback Loops in XP XP relies on feedback to work Feedback loops relate to time scalesThe tighter the time scale, the more immediate the feedback
43 Creating a Kinder, Gentler XP If you want to only do some of the XP practices, you have to replace the current XP activity with something that gives you the approximate same level of feedbackThat’s the only way you get the benefits from XPYou cannot randomly pick and choose what practices you want to use!XP becomes worse than many other methodologies because you’ve destroyed one of the dimensionsYou are sure to fail with XPYou’ll unfairly talk badly about XP to others
44 Substituting Practices: Planning The Planning PracticesUser stories are written.Release planning creates the schedule.Make frequent small releases.The Project Velocity is measured.The project is divided into iterations.Iteration planning starts each iteration.Move people around.A stand-up meeting starts each day.Fix XP when it breaks.
45 User stories are written. User stories Used to create the time estimates for release planning and acceptance testingWritten by the customers as things the system needs to do for themSimilar to usage scenarios but not limited to describing a user interfaceIn the format of about 3 sentences of text written by the customer in the customer’s terminology without techno-speakDiffer from traditional requirements in the level of detail
46 User Story Substitutions Traditional requirements gathering toolsMust be very flexibleMust be granularCaliberRM is an outstanding choice for thisEspecially for companies that require traceability for requirementsEasy to modify requirementsEasy to attach custom fields to requirements recordsRequirements should be as narrative as possible, not just a dry list of factsThe narrative conveys not just functionality but also workflow
47 User Story Substitutions Requirements must be flexibleUser stories have lower detail than traditional requirementsThe developers and customer create detailed requirements face to face when it comes time to implement the featureRequirements and dependencies must be fluidNeither user stories or requirements should ever delve into technical details
48 Release planning creates the schedule A release plan meeting is used to create a release plan, which lays out the overall projectThe release plan is used to create iteration plans for each individual iterationDecisionsTechnical decisions made by technical peopleBusiness decisions made by business peopleThe development team estimates each user story in terms of ideal programming weeks
49 A project may be quantified by 4 variables Release PlanningDo not change the estimates for user stories if management is displeased with the amount of time it takesA project may be quantified by 4 variablesScope - how much is to be doneResources - how many people are availableTime - when the project or release will be doneQuality - how good the software will be and how well testedManagement may choose 3 of the 4 valuesDevelopment gets the remaining variableLowering quality may have later project impact
50 Release Planning Substitutions The goal is to achieve consensus between developers, management, and business peopleDon’t stop until everyone is happy (or at least equally unhappy)XP release planning makes the business stakeholders a integral part -- don’t allow the substitution to leave them outYou must have business stakeholders to make it workYou wouldn’t change your accounting practices without someone from accounting there, would you?
51 Make frequent small releases to customers (or customer proxies) These are releases, not “90% done”This is a critical feedback loopYou need customer feedback to feed the remainder of the development cycleThe longer you wait to introduce an important feature, the less time you will have to fix itSmall releases tend to focus developer productivityForces the development team to solve tough problems rather than delay them
52 Small Release Substitutions This one is hard to substituteThis is the feedback loop between the customer (i.e., consumers of the application) and the developersYou can simulate this by creating small releases within your departmentYou’ve got to be diligentIf you start slipping into the “90% done” mode, you’re sunkTry hard to get User Acceptance Testing into this small release cycle if you can“Quick releases:Help find bugs fasterLet’s the users get to play with it faster”
53 The Project Velocity is measured This is the measure of how fast work is getting done on your projectCount how many user stories (or programming tasks) were completed during the iterationTotal up the estimates that these stories receivedThis helps future estimations during the next Iteration Planning MeetingDuring the Iteration Planning Meeting, developers sign up for the same number of programming tasks equal to the project velocity measured in the previous meeting
54 Don’t divide the velocity by the number of developers in the iteration Project VelocityThis mechanism allows developers to recover and clean-up after a difficult iterationDon’t divide the velocity by the number of developers in the iterationDoesn’t help determining the overall velocityCan’t compare it to other projectsDiscourages team buildingProject velocity will rise and fall during the project, which is normalRe-estimate if you see dramatic changes
55 Project Velocity Substitutions It’s OK to use other metrics for this as long asThey are reasonable, accurate metrics1They are team based, not individual basedThey provide real valueThey are simple enough to understandIn general, don’t try to measure this with Microsoft ProjectPerhaps the most misused piece of software ever writtenPeople use it to create meaningless charts and statisticsTesting is important in XP, including Meta-testing of the methodology as it proceeds1 There are very, very few of these -- see Brian Sletten’s Applied Object-oriented Metrics or David Bock’s Software Metrics and the Great Pyramid of Giza
56 IterationsThe project is divided into iterationsDivide the development schedule into about a dozen iterations, each lasting 1 to 3 weeksDon’t schedule tasks in advanceSchedule tasks in the Iteration Planning MeetingIt is against the rules to look ahead and try to implement anything not scheduled in this iterationYAGNI - You Ain’t Gonna Need ItThere is plenty of time later to respond to changing requirements
57 Iteration Substitutions Iterative development is hard to substituteTight iterations provides valuable feedbackKeep development team focusedKeep iterations short and cohesiveKeep tasks very small and cohesiveAvoid the temptation of gold platingAvoid “Big Bang” deploymentsEven if you must deploy that way in your organization, do internal “Little Bang” deploymentsDeploy often to User Acceptance Testing“Faster feedback on bugs and problems”
58 Iteration planning starts each iteration A meeting is called at the first of every iterationDevelopment work is selectedUser stories are chosen by the customerFrom the release planMost important firstFailed acceptance testsDevelopment work is translated onto index cardsEach task should be 1 to 3 Ideal programming daysDevelopers sign up for tasks then estimate how long it will take
59 Don’t be tempted to change your task and story estimates Iteration PlanningThe Project Velocity is used to determine if the iteration is overbookedDon’t be tempted to change your task and story estimatesThe planning process relies on the cold reality of consistent estimatesFudging them to be lower means you are lying to yourselfIt is normal to re-estimate stories and release plan every 3 to 5 iterationsAlways implement the most valuable stories first
60 Iteration Planning Substitutions You can change this phase with a similar planning sessionIt should be tied to iterationsLong-term estimates must be fluidIt is important for developers to create their own estimatesGets developer buy-inTheir estimation skill gets better over time“We’re getting developers more interested in the project management side and honing their estimation skills”
61 Change developer assignments weekly, daily, or hourly Move People AroundMove people aroundChange developer assignments weekly, daily, or hourlyPrevents serious knowledge loss and bottle necksSpreads overall knowledge aroundMay be as simple as encouraging everyone to try working on a different section of the system at least part of each iterationPair programming eliminates transition timeMove one of a pair at a timePlay “Musical Chairs” after lunch every day
62 Move People Around Substitutions Harder if you don’t pair programThe feedback goal here is to spread understanding around the projectYou can do this with regular code reviewsMuch less effective than pair programmingBetter than nothingThis helps avoid the Truck Number anti-patternExplain Truck NumberCall this “cross training”
63 A stand-up meeting starts each day Every day starts with the entire development team standing in a circle to communicateProblemsSolutionsImpedimentsTo improve team focusIt is more efficient to have one short meeting with everyone than a lot of little meetingsCross-team communication is the primary purpose
64 Stand-up Meeting Substitutions This is part of the daily feedback loopSubstitute with something that provides daily updates, problems encountered and solved, etc.You can set upA Wiki to share informationInformation RadiatorsHowever, this isn’t as rich a communications channelCockburn defines modalities of communications and their effectiveness (Agile Software Development, 2002)
66 Fix XPFix XP when it breaksFix the process when it breaksYou should be willing to do this with any methodologyDon’t buy into strictly prescriptive solutions
67 It is important to evolve your approach over time Build Your Own ToolsAt ThoughtWorks, most of the Project Managers create their own tools for tracking projectsMostly created around ExcelIt is important to evolve your approach over timeIt changes from project to projectYou get better and better at itBy the way - it's really, really important that PMs (especially client PMs) build their own tracking sheet. Taking someone else’s and mushing it around to make it work for the next project doesn't work. It's a psychology thing about owning the thing you built - and it's really important that PMs own their tracking tools.Roger Marlow, PM, ThoughtWorks
68 Substituting Practices: Designing The Designing PracticesSimplicity.Choose a system metaphor.Use CRC cards for design sessions.Create spike solutions to reduce risk.No functionality is added early.Refactor whenever and wherever possible.
69 SimplicitySimplicityA simple design takes less time than a complex oneWhen you find something complex, replace it with something simpleKeep things as simple as possible as long as possible by never adding functionality before it is scheduledKeeping a design simple is hard work“The present letter is a very long one, simply because I had no leisure to make it shorter. “Blaise Pascal
70 Simplicity Substitutions There is no substitute!FollowThe Pragmatic Programmer rulesThe Art of Unix Programming2. Rule of Clarity - Clarity is better than cleverness.5. Rule of Simplicity - Design for simplicity; add complexity only where you must6. Rule of Parsimony- Write a big program only when it is clear by demonstration that nothing else will do.13. Rule of Economy - Programmer time is expensive; conserve it in preference to machine time.14. Rule of Generation -Avoid hand-hacking; write programs to write programs when you can.
71 Choose a system metaphor Keeps the team on the same page by naming classes and methods consistentlyGood names =>Understanding the overall design of the systemCode reuseStick as close to the problem domain as possible
72 System Metaphor Substitutions Take the time to do this no matter what your methodologyMakes everything in the project make sense because it provides context“We’re trying to create a way that we can describe this to the business side to get their buy-in”
73 CRC CardsUse CRC (Class, Responsibility, and Collaboration) cards for design sessionsAllows people to break away from procedural thought and more fully appreciate object technologyIndividual CRC Cards represent objects
74 CRC CardsA CRC session proceeds with someone simulating the system by talking about which objects send messages to other objectsBy stepping through the process weaknesses and problems are easily uncoveredDesign alternatives can be explored quickly by simulating the design being proposed
75 CRC Card Substitutions This is one of the easier characteristics to changeMake sure that you find a design technique that isVery flexibleInteractiveInvolves the entire development teamServes the needs of the stakeholdersAllows for “What if” gamesMany organizations prefer more documentation CRC cardsOK as long as you don’t get the cart before the horseDon’t let a static medium discourage flexibility
76 Documentation “We have to have documentation so that… We can re-create it?We can kill more trees?We know what it does?”The tests are better documentation than any outdated Word documentYou have to keep them updated if the requirements changeYou can verify the requirements (tests) anytimeYou know what it does by the testsIf he has to have documentation…Make it a task within the iterationSpread it aroundTry to apply the DRY principle to it as much as possible
77 SpikesCreate spike solutions to reduce riskProof of concept projects to reduce technical riskIgnores all outside concernsExpect to throw it away (this is not a prototype!)This is common in most methodologiesAvoid the temptation to just build up from the spike
78 YAGNINo functionality is added earlyOne of the hardest things for developers to not do!We are all tempted to add functionality now that we are just sure is going to be needed laterExtra functionality always slows us down and squanders resources
79 No Functionality Added Early Substitutions Don’t!You start creeping towards Big Design Up FrontFocus on the task at hand
80 RefactorRefactor whenever and wherever possibleYou must be willing to change code anytime it should be changedDon’t’ live with broken windowsToo much software becomes brittle because of 100’s of tiny compromisesYou must be willing to refactor
81 Substituting Practices: Coding The Coding PracticesThe customer is always available.Code must be written to agreed standards.Code the unit test first.All code is pair programmed.Only one pair integrates code at a time.Integrate often.Use collective code ownership.Leave optimization till last.No overtime.
82 The customer is always available CustomersThe customer is always availableBusiness stakeholder must be availableIf you can’t get a business person, get a worthy substituteOne of the few hard requirements of XP“We have to know what to build…Requirements documents are out of date as soon as they are writtenGetting this right is important to the businessWe want to be able to respond quickly to changing requirementsDevelopers != business people”
83 StandardsCode must be written to agreed standardsAlmost every methodology does thisDon’t try to substitute this!
84 Test-first CodingCode the unit test firstCreating a unit test helps a developer to really consider what needs to be doneRequirements are nailed down firmly by testsThere can be no misunderstanding a specification written in the form of executable code
85 Test-first Coding Substitutions Test-first coding is the most effective way to write codeYou get nearly as good feedback if you make sure you write tests concurrentlyThey must be written right awayPlanning to write them next week doesn’t count!You can delay testing your code slightly, but you must write tests!Tests are the only way you can write code with confidence“This is the set of requirements”“Here is a coverage test that shows how much of our code is verified.”
86 Pair ProgrammingAll code is pair programmedThe most Extreme practice in XP!Two people working at the same computer will add as much functionality (or more) than 2 people working separately except that it will be much higher in qualityPair programming increases software quality without impacting time to deliverWorks best with 2 developers of more or less equal skill
87 Get ComfortablePair programming feels awkward at firstIt helps if you are set up for itPair Programming at ThoughtWorks
88 Pair Programming Substitutions Tough because this represents the most immediate code feedback loop, on the order of minutesYou can achieve the (greatly diminished) similar effect with very frequent code reviewsVery frequent means daily or at least once weeklyThink about how much code is written before it is peer reviewedStill pair on particularly complex parts (to help figure out how to make it simpler)Try it, with useful metrics, to help convince your boss
89 Pair Programming -- Politically “You’re going to do what!?!”You must show quantifiable resultsTry keeping useful metrics before and afterDon’t make it about silly things like lines of codeUse bug countsUse passed testsIf you already support code reviews in your organization, this is really just real-time code reviewsStart doing it without telling anyone on really complex parts
90 IntegrationOnly one pair integrates code at a timeDesigned to cut down on regression test failures that cascadeThis is do if you have effective source code control in placeThis assume a canonical source for your codeStrongly consider continuous integration to automate testing
91 Integrate OftenIntegrate oftenDevelopers should be integrating and releasing code into the code repository every few hours, whenever possibleAlways work in the context of the latest codeThere is a direct correlation to this feedback loop and its benefit which has nothing to do with XP
92 Collective Code Ownership Use collective code ownershipAny developer can change any line of code toAdd functionalityFix bugsRefactorThere is no one person (not even an architect) who has the entire visionThe code base is continually changingUnit tests and frequent integration preserve order
93 Collective Code Ownership Substitutions Hard!You should try to adopt this attitude no matter what your methodologyThis is a meta-feedback loop -- it enables the others to workThis is one of the enabling characteristics for real teamwork
94 OptimizationLeave optimization until lastDo not optimize until the endNever try to guess what the system's bottle neck will beMeasure it!Make it work, make it right, then make it fastWe should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.Donald Knuth
95 OvertimeNo overtimeWorking overtime sucks the spirit and motivation out of a teamProjects that require overtime to be finished on time will be late no matter what you doHard to substitute this because its worth is self evidentMake a rule that you never work overtime 2 weeks in a rowPrevents the (very real) danger of complete burnout“Our developers start writing code that causes a lot of test failures after 12 hour days!”
96 Substituting Practices: Testing The Testing PracticesAll code must have unit tests.All code must pass all unit tests before it can be released.When a bug is found tests are created.Acceptance tests are run often and the score is published.
97 Testing: Unit TestsAll code must have unit testsOne of the cornerstones of XP (and modern development practices)Compilers only tell you if the spelling is rightTests tell you if it does what you think it doesDon’t substitute for this, incorporate it
98 Unit tests are both feedback and meta-feedback All code must pass all unit tests before it can be released to version controlUnit tests are both feedback and meta-feedbackA strong suite of unit tests enables refactoring, collective code ownership, etc.Don’t substitute or slack on this one eitherBe careful about getting behind on tests (you’ll never catch up)Won’t happen if you do Test-first developmentDon’t substitute, incorporate
99 Bugs and TestsWhen a bug is found tests are createdIf you are testing anyway, you should create a test every time you find a new bugPrevents that bug from ever reoccurringDon’t substitute, incorporate
100 Acceptance TestsAcceptance tests are run often and the scores are publishedCreated from user storiesAnother important part of testingProvides confidence that you are creating the right thingThe highest scope feedback loop, from Create User Stories all the way to final codingYou must have some criteria to determine when you are doneRequirements => Acceptance tests
101 Organization Roles in XP Projects Project ManagerPlanningProject VelocityCat herdingBusiness Analyst/StakeholderKnows why the application is being writtenDeveloperTesterArchitectDoesn’t remove the need for Enterprise ArchitectureApplication Architects act as on-going policeman for the overall structure of the codeMay be overridden at any time by developers
102 Substitution ScaleUser Stories, Release Planning, Fix XP, CRC Cards, Spike SolutionsEasySmall Releases, Project Velocity, Iteration Planning, Move People Around, Stand-up Meeting, Coding Standards, Pair Programming, No overtimeIntermediateIterations, Simplicity, System Metaphor, Early Functionality, Test-first Coding, Integrate Often, Collective Code Ownership, Optimize last, Acceptance tests are run oftenHardRefactor, Customer is Always Available, All code must have unit tests, All code must pass unit tests, Create tests when a bug is foundNoSubstitute
103 You are never going to convince him with just arguments What to TellYou are never going to convince him with just argumentsToo much of XP is counter-intuitiveHe thinks you are trying to pull a fast oneDemonstrate that this worksCreate a pilot projectPick a small-scoped, orthogonal projectPick a team that can work togetherRock and roll!Use useful metricsNumber of tests passed (should be higher)Number of bugs (should be lower)Extrapolate
104 When All Else Fails…Trade this guy for that guy
105 Questions? Samples & slides at www.nealford.com memeagora.blogspot.comThis work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 license.