0
Agile Development with Scrum
            and XP
           Joe Drumgoole
   http://twitter.com/jdrumgoole
A Little Bit Of History
  Requirements


               Functional Spec


                            Design


           ...
Why Waterfall Sucks
• Can’t tell good software by observation
• What we see changes what we want
• Users are rotten at art...
Waterfall Works…
•    When specs are detailed and unchanging
•    E.g X400, TCP/IP stack, SMTP etc.
•    Requirement to de...
Performance Potential

                                                     Mentor
    Move




                          ...
Software Sector
•    Highly Motivated individuals
•    Don’t need more process
•    Need more mentoring
•    .. So PRINCE2...
Conway’s Law
    Organisations which design systems … are
    constrained to produce designs which are
    copies of the c...
Software Development
•    Takes 15 minutes to get in the zone
•    Interrupts reset the 15 minute timer
•    Takes 6 month...
Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
C...
What does this mean?
•    Avoiding Software Engineering
•    Mostly we don’t know what we are doing
•    … so do less of i...
XP & SCRUM
• Loose Definitions
       –XP is what the programmers do
       –SCRUM is what the management do




23 July 2...
Extreme Programming
•    On site Customer
•    User Stories
•    Simplest possible Design
•    Pair Programming
•    Short...
XP: On Site Customer
•    Customer available to team
•    Detailed domain knowledge
•    Understanding of ROI
•    Explain...
XP : User Stories
•    Simple stories that detail end-user functions
•    Written by the user
•    Fit on a single card
• ...
XP: Simplest Possible Design
•    Over Architecture
•    You are probably building the wrong thing
•    Linear list/flat f...
XP : Pair Programming
• Most difficult XP practice to adopt
• Not a master/slave, mentor/acolyte Role
• A sharing by peers...
Short Iterations
•    Don’t go dark
•    Validate your assumptions
•    Get customer feedback early and often
•    Don’t d...
Test Driven Development
•    Write the tests first
•    Tests fail initially
•    Tests start to pass as code gets written...
Refactoring
•    Driven by user stories
•    Performance demands a new sort
•    Flat files cannot be restructured for new...
Continuous Integration
•    Single Code Repository
•    Automate the Build
•    Make The Build Self Testing
•    Everyone ...
Incremental Releases
• Get the smallest feature working
• Use tests to validate working system
• Make sure each release mo...
Visibility
• Broken tests detected and fixed
• Broken builds detected and fixed
• Clear stats on:
       – No of builds
  ...
XP : Velocity
• An understanding of how many stories we can
  complete
• Measured like the weather
• Feedback loop leads t...
XP : Example Velocity
                       350
                                Example Velocity for SaaS Project
       ...
XP: 80/20 Rule
                  120
                        Example Velocity for SaaS Project
                        Exa...
Velocity Errors
•    Need to focus on consistent sprint tasks
•    Tasks must be > 4 hrs
•    Tasks must be < 16 hrs
•    ...
Exercise
• Write two User Stories for your software




23 July 2010      http://twitter.com/jdrumgoole   27
SCRUM


Scrum is an agile process that allows us to
focus on delivering the highest business
value in the shortest time


...
General George Patton


  A good plan, violently executed
   now, is better than a perfect
          plan next week


23 J...
Its Been Around a While
     • Jeff Sutherland
           – Initial scrums at Easel Corp in 1993
           – IDX and 500+...
SCRUM Users
•    Microsoft                            •    Intuit
•    Yahoo                                •    Nielsen M...
Key Facets
     • Self-organizing teams
     • Product progresses in a series of two- to
       four-week “sprints”
     •...
SCRUM Overview




23 July 2010      http://twitter.com/jdrumgoole   33
The Sprint – Coin of the Realm
• A release is broken down into sprints
• Sprints are of fixed identical duration
       – ...
Scrum Structure
• Roles
       – Product Owner
       – Scrum Master
       – Team
• Processes
       –   Sprint Planning
...
Roles: Product Owner
     • Define the features of the product
     • Decide on release date and content
     • Be respons...
Roles : Scrum Master
     • Represents management to the project
     • Responsible for enacting Scrum values and
       p...
Roles: The Team
     • Typically 5-9 people
     • Cross-functional:
       – Programmers, testers, user experience
      ...
Processes : Sprint Planning
• Sprint Prioritization
       – Analyse and evaluate sprint backlog
       – Takes account of...
Processes : Sprint Plan
• Decide how to achieve sprint goal
• Create sprint backlog from product backlog
       – A list o...
Example : Product Backlog
• Product Backlog : Invoicing System
        Feature                                            ...
Exercise
• Prioritise Two Features
• Write sprint backlog with estimates
• Present to group




23 July 2010      http://t...
Process : The Daily Scrum
     • Parameters
           – Daily
           – 15-minutes
           – Stand-up
     • Not fo...
Process : Daily Scrum
• Three Questions for each Team Member
       – What did you do yesterday?
       – What will you do...
Processes : Sprint Review
     • Team presents Sprint Goal
     • Ideally a Demo
     • Informal
           – 2-hour prep ...
Process : Sprint Retrospective
     • Periodically take a look at what is and is not
       working
     • Typically 15–30...
Processes : Sprint Retrospective

           Start Doing


                         Stop Doing


                         ...
Artefacts : Product Backlog
•    The engine that drives scrum
•    All desired work (from users perspective)
•    Articula...
Artefacts : Product Backlog
•    Avoids “infrastructure”
•    Avoids “architecture astronauts”
•    Focuses all efforts on...
Artefacts : Sprint Backlog
• Sprint Goal
       – Centralising paradigm of the overall sprint
       – Put an umbrella ove...
Artefacts : Sprint Backlog
     • Individuals sign up for work of their own choosing
           – Work is never assigned, ...
Artefacts : Sprint Backlog
• Sprint Tasks
       – Each task 8-16 hours
       – Should be achievable by any team member
 ...
Artefacts : Burn Down Chart




23 July 2010            http://twitter.com/jdrumgoole   53
Agile Deployment
• Use what works for you
• Phase 1
       – Test Driven Development
       – Continuous Integration
• Pha...
What can go wrong Internally?
•    No onsite customer
•    Sprints too long
•    TDD Lip service (all tests pass, nothing ...
What can go wrong Externally?
• No management buy in
• Expectations that 12 month long waterfall
  schedules will hit thei...
Tools Overview
•    Source Code Control
•    Ticket/Story Tracking
•    Burn Down Charts
•    Sprints
•    Continuous Inte...
Source Code Control
• Subversion
       –   Centralised
       –   Mature
       –   Good tool support
       –   Lots of ...
Tickets: Trac
• Trac
       – Open Source
       – Simple wiki and ticketing support
       – Integration with Mylyn
     ...
Tickets : Assembla
•    Nice Ticket interface
•    Mylyn integration for Eclipse
•    Client interface with good scrum sup...
Tickets: JIRA
• JIRA
       – Hosted or on-premise
       – Great ticketing system
       – Lots of features and integrati...
Burn Down : Charts
• Assembla
• Wush
• Pretty easy to knock out in Excel
       – If they come for free, use them
       –...
Sprints
• Wush
• Assembla
• JIRA
       – All support sprint structures
       – Progress indicators
       – Correlation ...
Continuous Integration
• Hudson
       – Apache, easy to setup, works for all scripted builds
       – Great UI
• Cruise C...
Unit Testing
•    Various xUnit Frameworks
•    Use one
•    Good integration with eclipse for JUnit
•    Every language h...
Acceptance Testing
• Selenium
       – Plugin and IDE
       – Stores web requests and results
       – Reports success/fa...
Summary
•    Get the individual activities working
•    Get the group activities working
•    Embraced rather than imposed...
Deming



                 In God We Trust.
               All others bring data.

23 July 2010          http://twitter.co...
Thanks




23 July 2010   http://twitter.com/jdrumgoole   69
Back
23 July 2010   http://twitter.com/jdrumgoole          70
Upcoming SlideShare
Loading in...5
×

Agile development using SCRUM

2,482

Published on

An overview of using Agile, XP and SCRUM to improve your development process

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,482
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
68
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Needwatefall picture here
  • Analysis of buildings vs analysis of softwareDECnet Phase VPicture of an oil tanker
  • Sometimes you just have to fire all the unhappy people
  • Oracle’s struggles
  • Thumbnails in PutPlace
  • Break into boxes and redraw
  • Transcript of "Agile development using SCRUM"

    1. 1. Agile Development with Scrum and XP Joe Drumgoole http://twitter.com/jdrumgoole
    2. 2. A Little Bit Of History Requirements Functional Spec Design Implementation Test Deploy 23 July 2010 http://twitter.com/jdrumgoole 2
    3. 3. Why Waterfall Sucks • Can’t tell good software by observation • What we see changes what we want • Users are rotten at articulating their desires – Obsessed with How rather than What • Domain knowledge car crash • Requirements change over time • Responsiveness 23 July 2010 http://twitter.com/jdrumgoole 3
    4. 4. Waterfall Works… • When specs are detailed and unchanging • E.g X400, TCP/IP stack, SMTP etc. • Requirement to deliver all at once e.g CREST • Minimal technical innovation required • UI Free Deployments • Project team uses appropriate process/tools 23 July 2010 http://twitter.com/jdrumgoole 4
    5. 5. Performance Potential Mentor Move Support Manage 23 July 2010 http://twitter.com/jdrumgoole 5
    6. 6. Software Sector • Highly Motivated individuals • Don’t need more process • Need more mentoring • .. So PRINCE2/Six Sigma etc. Won’t help • Some things need lots of process – Pharma, Big Oil, Agriculture – Software development ain’t one of them 23 July 2010 http://twitter.com/jdrumgoole 6
    7. 7. Conway’s Law Organisations which design systems … are constrained to produce designs which are copies of the communications structures of these organisations 23 July 2010 http://twitter.com/jdrumgoole 7
    8. 8. Software Development • Takes 15 minutes to get in the zone • Interrupts reset the 15 minute timer • Takes 6 months to build product value • Takes 18 months to build market value • Great developers don’t know how they do it • 10000 hours of practice (Outliers) 23 July 2010 http://twitter.com/jdrumgoole 8
    9. 9. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org/ 23 July 2010 http://twitter.com/jdrumgoole 9
    10. 10. What does this mean? • Avoiding Software Engineering • Mostly we don’t know what we are doing • … so do less of it until we do know • Lets look at some specific processes Extreme Programming & SCRUM 23 July 2010 http://twitter.com/jdrumgoole 10
    11. 11. XP & SCRUM • Loose Definitions –XP is what the programmers do –SCRUM is what the management do 23 July 2010 http://twitter.com/jdrumgoole 11
    12. 12. Extreme Programming • On site Customer • User Stories • Simplest possible Design • Pair Programming • Short Iterations • Test Driven Development • Refactoring • Continuous Integration • Incremental Releases • Visibility 23 July 2010 http://twitter.com/jdrumgoole 12
    13. 13. XP: On Site Customer • Customer available to team • Detailed domain knowledge • Understanding of ROI • Explains priorities from a business perspective • Balances effort /reward • Builds a relationship with team 23 July 2010 http://twitter.com/jdrumgoole 13
    14. 14. XP : User Stories • Simple stories that detail end-user functions • Written by the user • Fit on a single card • Focus on simple incremental improvements • Prune the backlog regularily • Priorities driven by customer demands 23 July 2010 http://twitter.com/jdrumgoole 14
    15. 15. XP: Simplest Possible Design • Over Architecture • You are probably building the wrong thing • Linear list/flat file preferred to DB table • Validate that the feature is desired • Optimise performance as a refactoring • Sometimes slow is good enough 23 July 2010 http://twitter.com/jdrumgoole 15
    16. 16. XP : Pair Programming • Most difficult XP practice to adopt • Not a master/slave, mentor/acolyte Role • A sharing by peers • Oversight at the coal face • The minute you leave the code your knowledge decays exponentially • Moment of creation • Eliminates “ownership issues” 23 July 2010 http://twitter.com/jdrumgoole 16
    17. 17. Short Iterations • Don’t go dark • Validate your assumptions • Get customer feedback early and often • Don’t do work on non-essential stuff • Discover changes in priorities • Making a wrong turn at the start 23 July 2010 http://twitter.com/jdrumgoole 17
    18. 18. Test Driven Development • Write the tests first • Tests fail initially • Tests start to pass as code gets written • Refactoring breaks tests and then passes • Unit Tests (class level) • Acceptances Tests (end user level) • Use automation (xUnit, Hudson, Ant etc.) • If it doesn’t have a test it doesn’t exist • Design for automated test 23 July 2010 http://twitter.com/jdrumgoole 18
    19. 19. Refactoring • Driven by user stories • Performance demands a new sort • Flat files cannot be restructured for new data • Increase users from 10 to 1000 • Environment changes (Windows to Linux) • Software Rot reduction 23 July 2010 http://twitter.com/jdrumgoole 19
    20. 20. Continuous Integration • Single Code Repository • Automate the Build • Make The Build Self Testing • Everyone commits to mainline everyday • Every commit builds the system • Keep the build fast • Test in a production clone • Make it easy to get a production copy 23 July 2010 http://twitter.com/jdrumgoole 20
    21. 21. Incremental Releases • Get the smallest feature working • Use tests to validate working system • Make sure each release modifies a small part of the system • Understand all changes • Focus on end-to-end functionality 23 July 2010 http://twitter.com/jdrumgoole 21
    22. 22. Visibility • Broken tests detected and fixed • Broken builds detected and fixed • Clear stats on: – No of builds – No of tests – No of deployments – Development is Data Centric 23 July 2010 http://twitter.com/jdrumgoole 22
    23. 23. XP : Velocity • An understanding of how many stories we can complete • Measured like the weather • Feedback loop leads to consistent stories 23 July 2010 http://twitter.com/jdrumgoole 23
    24. 24. XP : Example Velocity 350 Example Velocity for SaaS Project 300 250 Tickets Closed 200 150 Total 100 50 0 Sprints (Two Weeks) 23 July 2010 http://twitter.com/jdrumgoole 24
    25. 25. XP: 80/20 Rule 120 Example Velocity for SaaS Project Example Velocity for SaaS Project 100 80 Tickets Closed 60 KP DR 40 20 0 Sprints (Two Weeks) Sprints (Two Weeks) 23 July 2010 http://twitter.com/jdrumgoole 25
    26. 26. Velocity Errors • Need to focus on consistent sprint tasks • Tasks must be > 4 hrs • Tasks must be < 16 hrs • Break up or coalesce • Product Backlog too coarse grained • 80/20 rule goes for performance 23 July 2010 http://twitter.com/jdrumgoole 26
    27. 27. Exercise • Write two User Stories for your software 23 July 2010 http://twitter.com/jdrumgoole 27
    28. 28. SCRUM Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time 23 July 2010 http://twitter.com/jdrumgoole 28
    29. 29. General George Patton A good plan, violently executed now, is better than a perfect plan next week 23 July 2010 http://twitter.com/jdrumgoole 29
    30. 30. Its Been Around a While • Jeff Sutherland – Initial scrums at Easel Corp in 1993 – IDX and 500+ people doing Scrum – Scrum presented at OOPLSA 96 • Ken Schwaber – Scrum presented at OOPSLA 96 – Author of three books on Scrum • Mike Beedle – Scrum patterns in PLOPD4 • Ken Schwaber and Mike Cohn – Co-founded Scrum Alliance in 2002 23 July 2010 http://twitter.com/jdrumgoole 30
    31. 31. SCRUM Users • Microsoft • Intuit • Yahoo • Nielsen Media • Google • First American Real Estate • Electronic Arts • BMC Software • Philips • John Deere • Siemens • Lexis Nexis • Nokia • Sabre • IBM • Salesforce.com • Capital One • Time Warner • BBC • Oce 23 July 2010 http://twitter.com/jdrumgoole 31
    32. 32. Key Facets • Self-organizing teams • Product progresses in a series of two- to four-week “sprints” • Requirements are captured as items in a list of “product backlog” • No specific engineering practices prescribed • Uses generative rules to create an agile environment for delivering projects • One of the “agile processes” 23 July 2010 http://twitter.com/jdrumgoole 32
    33. 33. SCRUM Overview 23 July 2010 http://twitter.com/jdrumgoole 33
    34. 34. The Sprint – Coin of the Realm • A release is broken down into sprints • Sprints are of fixed identical duration – Helps manage velocity – Helps keep a rhythm • Team decides sprint duration • No changes during a sprint 23 July 2010 http://twitter.com/jdrumgoole 34
    35. 35. Scrum Structure • Roles – Product Owner – Scrum Master – Team • Processes – Sprint Planning – Daily Scrum Meeting – Sprint Review – Sprint Retrospective • Artefacts – Product Backlog – Sprint Backlog – Burn Down Charts 23 July 2010 http://twitter.com/jdrumgoole 35
    36. 36. Roles: Product Owner • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results 23 July 2010 http://twitter.com/jdrumgoole 36
    37. 37. Roles : Scrum Master • Represents management to the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences 23 July 2010 http://twitter.com/jdrumgoole 37
    38. 38. Roles: The Team • Typically 5-9 people • Cross-functional: – Programmers, testers, user experience designers, etc. • Members should be full-time – May be exceptions (e.g., database administrator) • Teams are self-organizing – Ideally, no titles but rarely a possibility • Membership should change only between sprints 23 July 2010 http://twitter.com/jdrumgoole 38
    39. 39. Processes : Sprint Planning • Sprint Prioritization – Analyse and evaluate sprint backlog – Takes account of changing business priorities – Define Sprint Goal – Feed into Sprint Plan 23 July 2010 http://twitter.com/jdrumgoole 39
    40. 40. Processes : Sprint Plan • Decide how to achieve sprint goal • Create sprint backlog from product backlog – A list of product backlog tasks aligned with goal • Time estimates for sprint backlog • Sprint backlog is the Sprint Plan 23 July 2010 http://twitter.com/jdrumgoole 40
    41. 41. Example : Product Backlog • Product Backlog : Invoicing System Feature Development Effort (Days) Allow login using facebook credentials 5 Generate PDF copies of invoices 7 Graph credit risk 4 Send duplicates of all invoices 3 Annotate invoice 3 Customise invoice look and feel 5 Support multi-currency 10 Support time sheets for work 10 Store list of clients and allow editing 4 23 July 2010 http://twitter.com/jdrumgoole 41
    42. 42. Exercise • Prioritise Two Features • Write sprint backlog with estimates • Present to group 23 July 2010 http://twitter.com/jdrumgoole 42
    43. 43. Process : The Daily Scrum • Parameters – Daily – 15-minutes – Stand-up • Not for problem solving – Whole world is invited – Only team members, ScrumMaster, product owner, can talk • Helps avoid other unnecessary meetings 23 July 2010 http://twitter.com/jdrumgoole 43
    44. 44. Process : Daily Scrum • Three Questions for each Team Member – What did you do yesterday? – What will you do today? – Is there anything in your way? • Not status updates for Scrum Master • Commitments to your peers • Keeps SCRUM moving forward 23 July 2010 http://twitter.com/jdrumgoole 44
    45. 45. Processes : Sprint Review • Team presents Sprint Goal • Ideally a Demo • Informal – 2-hour prep time rule – No slides • Whole team participates • Invite the world 23 July 2010 http://twitter.com/jdrumgoole 45
    46. 46. Process : Sprint Retrospective • Periodically take a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates – ScrumMaster – Product owner – Team – Possibly customers and others 23 July 2010 http://twitter.com/jdrumgoole 46
    47. 47. Processes : Sprint Retrospective Start Doing Stop Doing Continue Doing 23 July 2010 http://twitter.com/jdrumgoole 47
    48. 48. Artefacts : Product Backlog • The engine that drives scrum • All desired work (from users perspective) • Articulated as value delivered to customer • Prioritised by Product Owner • Should have rough development estimates • Reprioritised at the start of each sprint 23 July 2010 http://twitter.com/jdrumgoole 48
    49. 49. Artefacts : Product Backlog • Avoids “infrastructure” • Avoids “architecture astronauts” • Focuses all efforts on business value • Sprint Backlog articulates technical issues • Anyone can add to the backlog • Product Owner sets priority • Starvation is healthy 23 July 2010 http://twitter.com/jdrumgoole 49
    50. 50. Artefacts : Sprint Backlog • Sprint Goal – Centralising paradigm of the overall sprint – Put an umbrella over a number of backlog items – Can be one backlog item • Example – Support multiple users per account – Integrate Google Docs – Support Sage Accounting 23 July 2010 http://twitter.com/jdrumgoole 50
    51. 51. Artefacts : Sprint Backlog • Individuals sign up for work of their own choosing – Work is never assigned, collective ownership • Estimated work remaining is updated daily • Any team member can add, delete or change the sprint backlog • Work for the sprint emerges • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining as more becomes known 23 July 2010 http://twitter.com/jdrumgoole 51
    52. 52. Artefacts : Sprint Backlog • Sprint Tasks – Each task 8-16 hours – Should be achievable by any team member – Task time limits avoids “skunk works” 23 July 2010 http://twitter.com/jdrumgoole 52
    53. 53. Artefacts : Burn Down Chart 23 July 2010 http://twitter.com/jdrumgoole 53
    54. 54. Agile Deployment • Use what works for you • Phase 1 – Test Driven Development – Continuous Integration • Phase 2 – Continuous Integration – Shorter release cycles 23 July 2010 http://twitter.com/jdrumgoole 54
    55. 55. What can go wrong Internally? • No onsite customer • Sprints too long • TDD Lip service (all tests pass, nothing works) • Techno Bigotry – The solution to everything is a NoSQL Db • Over architecting solutions 23 July 2010 http://twitter.com/jdrumgoole 55
    56. 56. What can go wrong Externally? • No management buy in • Expectations that 12 month long waterfall schedules will hit their dates • Expectations of Quarterly “move the market” releases • No domain expertise • The blame game 23 July 2010 http://twitter.com/jdrumgoole 56
    57. 57. Tools Overview • Source Code Control • Ticket/Story Tracking • Burn Down Charts • Sprints • Continuous Integration • Unit Testing • Acceptance Testing 23 July 2010 http://twitter.com/jdrumgoole 57
    58. 58. Source Code Control • Subversion – Centralised – Mature – Good tool support – Lots of hosting providers – TortoiseSVN for Windows Clients • GitHub – Distributed – Younger Lineage – Better for Branching – A few hosting providers 23 July 2010 http://twitter.com/jdrumgoole 58
    59. 59. Tickets: Trac • Trac – Open Source – Simple wiki and ticketing support – Integration with Mylyn – Lots of hosting providers – Very simple clean interface – Can be deployed on-premise – Nice integration with subversion 23 July 2010 http://twitter.com/jdrumgoole 59
    60. 60. Tickets : Assembla • Nice Ticket interface • Mylyn integration for Eclipse • Client interface with good scrum support • Good wiki integration • Good Multi-project support 23 July 2010 http://twitter.com/jdrumgoole 60
    61. 61. Tickets: JIRA • JIRA – Hosted or on-premise – Great ticketing system – Lots of features and integrations – Comes with full development suite – $125 a month for 5 developers 23 July 2010 http://twitter.com/jdrumgoole 61
    62. 62. Burn Down : Charts • Assembla • Wush • Pretty easy to knock out in Excel – If they come for free, use them – Don’t pay for them – Consider tracking Unit tests and Tickets Closed 23 July 2010 http://twitter.com/jdrumgoole 62
    63. 63. Sprints • Wush • Assembla • JIRA – All support sprint structures – Progress indicators – Correlation with source code control system • Backlog management is hard in Wush • Multi-projects hard in Wush 23 July 2010 http://twitter.com/jdrumgoole 63
    64. 64. Continuous Integration • Hudson – Apache, easy to setup, works for all scripted builds – Great UI • Cruise Control – Older than hudson, but does .NET stuff • Continuum – Apache project, primarily Java builds • Bamboo – Slick but need to pay for it 23 July 2010 http://twitter.com/jdrumgoole 64
    65. 65. Unit Testing • Various xUnit Frameworks • Use one • Good integration with eclipse for JUnit • Every language has a framework • http://en.wikipedia.org/wiki/List_of_unit_testing_fra meworks (66 listed) 23 July 2010 http://twitter.com/jdrumgoole 65
    66. 66. Acceptance Testing • Selenium – Plugin and IDE – Stores web requests and results – Reports success/failure • FIT – Create “fixtures” in Word/Excel – Test using FIT library 23 July 2010 http://twitter.com/jdrumgoole 66
    67. 67. Summary • Get the individual activities working • Get the group activities working • Embraced rather than imposed • Automation really helps • Deliver value before delivering a sea change • Start Small 23 July 2010 http://twitter.com/jdrumgoole 67
    68. 68. Deming In God We Trust. All others bring data. 23 July 2010 http://twitter.com/jdrumgoole 68
    69. 69. Thanks 23 July 2010 http://twitter.com/jdrumgoole 69
    70. 70. Back 23 July 2010 http://twitter.com/jdrumgoole 70
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×