RECHERCHE ET DEVELOPPEMENT EN DROME ARDECHE

Nous avons créé une mailing-liste pour développeurs en région Drôme-Ardèche.
L'objectif de ce groupe est de proposer une entre-aide entre développeurs de la région Drôme-Ardèche par la constitution d'un réseau de connaissances et de communication.
Ce réseau permet de rester au courant de:
- l'activité dans la région;
- l'emploi dans le secteur du développement dans la région;
- des technologies utilisées dans la région;
- des méthodes/pratiques utilisées dans la région;
- des partenariats existants;
- ...
Pour s'inscrire, il suffit d'envoyer un mail à RD2607-subscribe@yahoogroupes.fr ou de se rendre à http://fr.groups.yahoo.com/group/RD2607/

COURS DE GENIE LOGICIEL

J'ai mis en ligne (au format pdf) mon cours de génie logiciel destiné à des étudiants en cinquième année d'école d'ingénieur.
Vous pouvez le télécharger ici.
Biensûr, je vais remanier ce cours pour la prochaine session. Je mettrai la nouvelle version en ligne.

Je posterai des billets sur ces cours, car c'est une expérience qui m'a passionné!

ORGANISATION DE GRANDS PROJETS DE DEVELOPPEMENT

La Tour de Babel, par Pieter Bruegel (c. 1525-69), 1563
Ce tableau est la représentation la plus connue de la tour de Babel.

Puisque cela va devenir d'actualité dans mon travail, voici un article - ou plutôt une synthèse - sur l'organisation de grands projets de développement logiciel.
L'article (en pdf) est ici.
L'analogie entre les grands projets de développement et la tour de Babel provient de Frederick Brooks. La tour de Babel est un grand projet qui a échoué par manque de communication et d'organisation - pas pour des raisons techniques.

THE MYTHICAL MAN-MONTH, de Frederick P. Brooks, Jr

A force de voir ce livre cité en bibliographie de mes lectures, je me suis enfin décidé à le lire.
J'avoue que j'étais très curieux. Comment un livre sur le développement logiciel peut-il être autant référencé - après trente ans de parution?
Cette nouvelle édition contient quatre nouveaux chapitres, dont le fameux article "No Silver Bullet".

J'avoue avoir été un peu déçu, car je trouve que certains chapitres ont mal vieilli. Après tout, rien de plus normal : il s'en est passé des choses en trente ans de développement informatique et logiciel!

Par contre, certains passages restent vraiment brillants. Le fameux chapitre intitulé "The Mythical Man-Month" est absolument génial. On se régale de la nature optimiste du programmeur, on constate la confusion entre effort et avancement, on reconnait que l'effort de communication croit avec le nombre de développeurs et que le mois-homme n'a rien de linéaire. On retiendra la loi de Brooks:

Adding manpower to a late software project makes it later.

J'ai également adoré le chapitre "Why did the Tower of babel Fail?". L'auteur constate la si grande importance de la communication et d'une organisation souple et adaptative pour les projets de développement logiciel.
Dans le chapitre "The Documentary Hypothesis", j'ai adoré la si pertinente loi de Conway:

Les architectures sont à l'image des organisations qui les crééent.

C'est si vrai! Et la suite est fabuleuse:

On constate que la première architecture est invariablement pas la bonne. Que faut-il en déduire sur l'organisation qui l'a créé (à son image)?

Bref, pour une architecture adaptative il faut prévoir une organisation adaptative. Enfin, j'ai retenu:

How does a project get to be a year late? ... One day at a time.

Dès 1975, tout ceci et plusieurs références au pilotage par les tests nous amène déjà vers le développement logiciel Agile!

FORMATION ET CERTIFICATION SCRUMMASTER

Fin Janvier, je suis allé suivre une formation certifiante de ScrumMaster. La session, menée par deux formateurs pour douze stagiaires, a duré deux jours.

Praticiens de l'eXtreme-Programming, nous gérions déjà nos projets de manière très similaire à Scrum.
Avant de me rendre à la formation, j'ai pris le temps de me documenter et surtout de lire Agile Software Development With Scrum (de Ken Schwaber et Mark Beedle). A partir de cette expérience et de mes recherches, je pensais avoir déjà une bonne compréhension de la démarche et j'y suis allé essentiellement pour poser des questions aux formateurs sur la mise en pratique de Scrum sur plusieurs équipes au sein d'un même projet - éventuellement multisite.

En effet, j'avoue ne pas avoir appris grand chose. Néanmoins, j'ai tout de même beaucoup apprécié la formation pour plusieurs raisons.
D'abord, les exercices pratiques sont très pertinents, surtout la simulation d'un projet par équipe de six en deux sprints de dix minutes chacun.
De plus, je trouve toujours cela très intéressant de discuter avec des développeurs provenant d'autres domaines et ayant d'autres approches du génie-logiciel.
Aussi, il est très instructif de confronter ses expériences et de présenter ses difficultés aux formateurs, qui sont avant tout des développeurs aguerris.
Enfin, même si on pense avoir peu appris, cela nous conforte dans le fait que nous nous efforçons de travailler correctement - et dans la bonne direction.

Une parole du formateur m'a particulièrement plu. Nous discutions de la difficulté du rôle de ScrumMaster dans le cadre de la suppression d'obstacles liés à l'organisation dans la quelle est menée le projet. En effet, il peut être épuisant de conduire le changement au sein d'une grande entreprise hiérarchisée. Le ScrumMaster peut s'épuiser face à l'inertie de l'organisation. Le formateur m'a fait remarquer:

"Un ScrumMaster mort ne sert plus son équipe ..."

Je suis convaincu que Scrum est une méthode particulièrement adaptée aux équipes pluridisciplinaires. L'avantage de Scrum est même qu'elle n'est pas spécifique au développement logiciel. Dans une entreprise où le savoir-faire logiciel n'est culturellement pas stratégique, les membres d'une équipe pluridisciplinaire de développement logiciel dont la spécialité n'est pas le développement logiciel pourront être réticents à appliquer une démarche comme l'eXtreme-Programming (c'est du vécu!). Ces derniers acceptent mal d'appliquer une démarche provenant du domaine logiciel - même si leur projet n'est autre qu'un développement de logiciel! Dans ces cas, Scrum a l'avantage de ne pas être lié du développement logiciel ...

Pour ce qui est de la certification ScrumMaster, il est clair que les stagiaires ne deviennent pas ScrumMaster grâce à la formation. Il faudra bien de la pratique pour tenir ce rôle de manière efficace. Ainsi, la certification est discutable ... Néanmoins, il est toujours plaisant de faire briller son CV - et si cela peut ouvrir des opportunités ...
Bref, je suis désormais répertorié ici ;o)