Target audience: MontrealXpUsersGroup.
Format: 20 minutes lecture at 19h15 november first. Then open discussion. Expected number of people: around 10. Please be there at 19h00 so we can begin at 19h15! ;-)
Includes: Physical setup.
Reminder: Value the Individuals and interactions over processes and tools.
Goals: To foster, to encourage to use of new tools or to use a tool a "better" way.
Intro: Appropriate use of tools, Tools vs pratices, Tools as physical tokens, when reinventing the wheel.
Conclusion: Explore and choose, let tool emerge, travel light.
Tools are shaping the working environment. They are not only means to an end, but facilitators and inhibitors of human activity. The way we set up the working environment will influence the way we work. We should not underestimate this fact and learn to take advantage of it.
We should look for tools that support XP values:
communication, through open tools that favorise awareness, transparency and empathy.
feedback, by using adequate tools that will favor appropriate and reliable answers from both the team and the machine. (see comparison between unit tests and bugs database)
simplicity, through light tools that will support the programmers' activities rather than increase the load of work and divert attention from the project.
courage, through tools that will help the team to make confident decisions over foolish ones.
Development / Integration Workstations (#dev/2+1)
Ide / Compiler / Debugger / (Profiler)
Automated Acceptance / Unit Tests framework,
Coding Standard reinforcement / Coding help
Index cards, whiteboards, giant post-it
Photocopier / Scanner, Camera (Backup for whiteboard, index cards, ...)
Setting up the environment
The War Room: OpenSpace / Radical Collocation, Walls, PP tables
JeanPhilippeBelanger also suggested to use white vinyl sheets applied on walls, it is less expensive that whiteboards.
Something we have done in past projects is to get strips of plastic and apply magnets to the back of them. Then use them on a whiteboard that has a magnetic background. This way you can have "permanent" and "temporary" information. The strips can be used as CRC Cards or User Stories or whatever and the whiteboard can be used for project notes or velocity, etc. -- IainLowe
Structure of lecture
XP Feedback loop
XP Tools Virtues: openness, support, reliability, confidence
Drawing of physical setup
Tools: Development / Integration Workstations (#dev/2+1)
Tools: Ide / Compiler / Debugger / (Profiler)
Tools: Automated Acceptance / Unit Tests framework,
Tools: Version Control
Tools: Build Script
Tools: Refactoring Browser
Tools: Coding Standard reinforcement / Coding help
Tools: Index cards, whiteboards, giant post-it
Tools: Photocopier / Scanner, Camera (Backup for whiteboard, index cards, ...)
Tools as support mechanism for the Values and Practices of XP
with clients, departments, team members, ourselves.
person to person
collaborative documents (wiki)
Question: When to use low tech tools vs hi tech tools?
(L+) When communicating with other people: they're intuitive and we need to fill the gap through interacting with people (the RTFM syndrome is symptomatic of the gap being closed through the availability of user manuals).
(L+) When we want to keep knowledge between individual and not stored away in a project file.
(L+) When we don't want to leave a memory of the past.
(H+) When we need to make something evolve into something else (ex: source code).
(H+) When we need to be able to go back in time (ex: version control).
(H+) When we need to maintain detailed information about something (ex: knowledge base).
Conclusion (?): Low tech tools and hi tech tools complement themselves. HT works well when we have to build something, externalize knowledge and maintain detailed information about the status of a project (Acceptance Tests gives a true status of what has been done) ; LT put the emphasis on people and how they share, understand things and appropriate knowledge without having to "point their fingers at books" -- they're good at simplification.
from machine, client, team members, departments...
point: where do you get your feedback from? Get the most reliable source (acceptance tests vs bug tracker). A word on competition between tools and the importance of choosing the right tools early in the project.
question: how can tools help us travel light?
automation: let the machine do it for us
experimentation (sand box): let's play with the solutions to start with and dismiss the complex ones before we really implement something
idea: tools also have user requirements. The costs of listening to an inappropriate tyrant (ex: Microsoft Project).
should we use our tools in the simplest way possible?
idea: courage to try out new tools; encourage everyone to experiment with a single tool each month and report on it.
Emphasis on human interaction through low tech tools: index cards, white board, giant post-its,... Physical objects as an intuitive token of project scope (could this actually help prevent featuritism?) Can a tool like MS Project be dangerous?
unit testing, acceptance testing, profiler. Is testing ideally done all with tools?
Physical tools prevent task switching (because the computer is busy), they're readily accessible, more flexible and less cluttered with information than dynamic tools.
wiki, version control.
refactoring editor / browser.
Prototypes, maps, physical tokens can be more expressive of scope than huge boring files. How do we bring some of the advantages of physical tokens to the online world if we never meet out customers face to face?