skip to main |
skip to sidebar
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/
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é!
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.
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!
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)
I read this book to improve our current practices, which are already very close to Scrum.
I particularly appreciated:
- the emphasis on continuously removing impedents to effective work;
- the tips to deal with scaling projects, organizations and teams;
- the comparison between organizations and software. Organizations must emerge and grow in increments, just like software.
- add all tasks to the backlog, not only the functional requirements. However, each Sprint must contains a functional increment.
- the fact that requirements remain complicated even if they are understood by the domain and business analysts as long as they are too complicated for the developpers.
However, I do not agree with the fact that code is own forever by the programmer who wrote it. I prefer the collective ownership approach of eXtreme Programming.Also, I still find that 30 calendar day Sprints are too long ... I prefer shorter iterations, mostly because of the the queueing theory. Smaller items go faster in the workflow. I believe a project will be faster completed if it is managed into shorter iterations.But, I do really recommend this book. It made me want to read Agile Project Management With Scrum, also written by Ken Schwaber some years later.
On our current project, the team has just spent four days of work on a requirement, to finally throw the code over and start again. We got glued into some never ending refactoring which never gave satisfaction as the code never seemed testable. What a waste! We've been through the same experience already a couple of times - and hopefully we are learning from our mistakes.We develop near chaos. This isn't a bad thing. We follow practices very close to eXtreme Programming and Scrum, so unclear requirements and emergent systems are our lot. So, why has the team suffered so much lately?We lacked discipline. In fact, we let go just a little on two major and very constraining disciplines. The problem is that when you develop near chaos, you cannot afford to let go of these two disciplines.By the way, some people really misunderstand agile development. They believe agility means lack of discipline and chaos. Isn't it just the contrary? To develop in a chaotic environment (such as any software development) you need to be so extremely disciplined! Isn't eXtreme Programming such an extremely disciplined methodology?
So, what are these two so important disciplines? Very frequent synchronisation and test-driven development.
On several projects, we've noticed that shortly after a pair or a single developper gets late to synchronise and deliver his code, he gets stuck in painful code and test merging. The system emerges so quickly that members of the team must keep the rhythm. Stock of undelivered code just slows you down and requires energy to catch-up. Stock means waste! Unfortunelty, it is very difficult to learn how to develop in baby steps. Developers often assert that their current task cannot be cut into small increments.
We've also noticed that developpers tend to slowly let go of test-driven-development. The problem is that they take several successive design decisions to finally discover that their code is difficult to test! Therefore, the design is inadequate and must be refactored and tested.
OK, developers gradually let go of frequent synchronisation and test-driven-development. How do you improve your habits and maintain discipline?
The solution we try is to spread good pratices and systemize checking.
- First, the team shares the same office. Therefore, everyone detects a developper or pair struggling on painful merges. Help and advice is naturally provided.
- The team attends a daily short and focused stand-up meeting. Lack of progress and painful struggling is detected. Again, help and advice is quickly provided.
- Pairing is very frequent. The teammate is there to remind the pair to work in baby steps and write tests as it writes code.
- We have a coach on the team. He's responsible for having the practices applied, training the teammembers and helping the team to continuously improve its practices. The coach detects pairs or single developers struggling in merges or falling late to deliver. He must provide advice and help. He visits the pairs and reminds them to synchronise.
In a world of chaos, you just can't let go on discipline! But discipline must not be imposed on the team. The team must reflect on its struggles, understand the cause of their pains and agree on trying disciplined practices to provide scaffolding. This is another subject. For more information on continuous improvement, read this post.
