Catégorie : agile
-
La revue de code
Lorsque nous pensons que la programmation en binôme coûte cher, rappelons-nous les 3 étapes de la relecture de code : 1 – payer un premier développeur pour mal travailler,2 – payer un second développeur afin de s’assurer que, conformément à nos prévisions, le premier a mal travaillé3 – payer une troisième fois pour que le…
-
Et si le projet était agile ?
Nous entendons souvent que le projet serait incompatible avec l’agilité. Et que dans l’agilité il n’y aurait que des produits. Em sommes-nous si sûrs ? Une définition du projet Le projet est parfois défini (et souvent enseigné) comme ayant un objectif définitif, une date de début et de fin définies, un planning, un cahier des…
-
Les sorciers
Alors que les sorciers traditionnels faisaient usage de pentacles dessinés au sol pour conjurer le futur, nos sorciers des temps modernes ont simplifié le folklore. Maintenant, pour influencer le futur, ils dessinent une ligne droite et l’agrémentent de quelques signes difficilement compréhensibles pour le non‑initié. Tout comme leurs illustres aïeux, ils sont convaincus qu’avec leur…
-
Deadlines fortes ? Pourquoi il est important d’arrêter les plannings et les estimations.
Après avoir étudié comment nous pouvions synchroniser des équipes de développement logiciel sans s’appuyer sur des plannings, penchons-nous sur le cas de la deadline, ou limite mortelle, dans le contexte du développement logiciel. Nous pouvons distinguer deux types de dates butoirs. D’une part, les deadlines arbitraires qui sont créées afin de mettre la pression sur…
-
Petit Gantt
Un jour naquit petit GanttQui, avant même que le projet ne démarre,Inexact, se révéla. Point d’inquiétude :il est normal d’ajuster les prévisionsdès que l’inconnu surgit. Quotidiennement donc,le petit Gantt est mis à jour, car, ô surprise,le futur n’en a cure de petit Gantt.Le futur advient,toujours surprenant,jamais là où on l’attend. Mais fort heureusement,après cinq reports,voici la…
-
Est‑il vraiment raisonnable de demander aux développeurs des estimations pour concevoir des fonctionnalités ?
L’idée paraît séduisante sur le papier : demander aux développeurs d’estimer chaque fonctionnalité (en jours ou en points). Et si d’aventure, un développeur estime une fonctionnalité à 8 points et un autre à 13 points, ils discuteront pour harmoniser leurs visions. Le sous‑entendu ? S’ils arrivent tous les deux à la même estimation, c’est qu’ils envisagent la même solution.…
-
Le déchirement
Pendant des siècles, la majorité des humains affirmaient que la Terre était plate. Pas certain qu’elle le soit devenue pour autant. Et aucun problème avec l’idée que la majorité puisse se tromper. De mémoire, une majorité de personnes pensent encore qu’un objet lourd tombe plus vite qu’un objet léger. Si demain, la majorité des personnes…
-
De l’inutilité des plannings afin de synchroniser plusieurs équipes de développement logiciel
L’idée est largement répandue. Répétée à l’envie. Y compris au sein de la communauté agile. Si, pour une équipe isolée, il est possible de travailler sans planning ni estimation, alors, pour des projets complexes impliquant de nombreuses équipes et contraintes, la planification serait la seule manière d’organiser le travail. Relevons d’abord deux contradictions dans cette…
-
Les approches hybrides
Grâce aux approches hybrides, il est désormais possible : – d’avoir de longs cycles courts, – des équipes dont l’auto-organisation est librement définie par un département Process et Méthode au niveau central, – et qui peuvent exprimer leurs singularités grâce à la parfaite uniformisation des équipes, – une foultitude de rôles, comités, intermédiaires permettant à…
-
La fable de la mise à jour
Ne pas livrer le vendredi, parce que veille de week-end. Ni le lundi, tout le monde reprend son poste. Le mardi, impossible, c’est le jour du Codir.Le mercredi, impensable, il y a trop d’absents.Le jeudi est la journée la plus chargée pour nos utilisateurs. Il ne faut pas les perturber.Ne reste que le samedi et…