PROJECT LOGBOOK

The important events of the project and the decisions with their justifications are logged into a logbook, last date up.

This helps to integrate new developpers into the project, to find explanations concerning old decisions and to provide proofs for audits.

The logbook is edited in a wiki page to keep it the practice lightweight, share it among the team, keep it alive and enable easy searchs.

PRAGMATIC PROJECT AUTOMATION, Mike Clark

This book explains step by step how to automate builds, tests, continuous integration, release, installation and monitoring of software.
The examples are given for Java applications, using tools such as ant, JUnit and CruiseControl on a Unix platform.
However, the advice may (must?) be set into practice for other languages and using other tools.

EXTREME PROGRAMMING OFFICE

I've published my first article in [Pro]grammez, a french monthly magazine on software development.
It deals with the way our development team organizes its project office to optimize communication.

TEACH AS YOU DEVELOP

This short bill has been refactored by taking into account the feedback provided by the students of this year's session.

I find that a interesting way to teach software development to students is to teach as you develop: Plan, Do, Check, Act (thanks Mr.Demming).
Therefore, the course is led as a software development project.

PLAN!
Each lesson starts by a short and focused meeting. During this 15-minute project meeting, we

• recall the important matters teached in the former session, and
  
• identify what we commit to deal with in the current session.
  

Each feature to teach is then estimated to check it will fit in the day's lesson.

DO!
I never delay an answer to a student's question - even if it forces me to change and re-plan the sequence of the course. The course is driven by the students needs. It must be adaptative.

CHECK!
At the end of each lesson, the students must fill-in a short anonymous evaluation. They are asked provide the following feedback:

• What is really important in today's course?
• What did you not understand clearly (and did not dare to ask orally ;o)?
• Is there something we forgot to talk of?
  
• Do you have any remarks to improve the lesson's animation?

ACT!
With this feedback, I try to continuously improve my teaching and insist on the important matters the students have misundersood (because I was'nt clear enough).

CHECK! (again)
Then, at the end of the full course, I give the students a full anonymous evaluation.

• Rate the contents from 1 to 4.
• Rate the animation from 1 to 4.
• What did you prefer in this course?
• What did you not enjoy in this course?
  
• Do you have any suggestion to improve the course?
• Would you recommend this course to another student?
  

ACT! (again)
With this feedback I try to improve next year's session.

I believe this practice of teaching software development enables students to feel what a develoment project is like. Indeed:

• The customer (the students) are involved in the project (the lesson).

• Each lesson is an increment of knowledge.

• Each lesson is an iteration.

• Each iteration starts with a little planning, a little estimating and some short-term commitment.

• The planning is not predictive. It is adaptative as the contents of an increment (or lesson) may change according to the customers (the students) needs (questions and remarks).

• Each iteration ends with a retrospective to provide feedback to improve the next iteration.

I haven't yet managed to practice continuous testing, as the students would feel the pressure too hard ... one day maybe ;o)

WHICH DEVELOPER ARE YOU?

Of course, while the pragmatic programmer is enjoying a nice diner at 8PM, his automated build is running at work for him, building, testing, measuring the code, measuring the test coverage, generating documentation and providing fresh and complete feedback for the next morning.
Isn't it just great to know someone safe is working for you while you enjoy your time?

A PRAGMATIC DAY

This is a drawing I use to explain what an ordinary pragmatic day is for an agile developer.

TEACHING

I've just started to teach software engineering to a class of last-year engineering students.
As Chad Fowler puts it in "My Job Went To India":

When you teach, you have to answer questions that may never have occurred to you. Through teaching, we clean the dusty corners of our knowledge as they are exposed to us.