Retour : Page Principale > sommaire méthodologie

Méthode de développement informatique

On utilise une version adaptée de la méthode agile Scrum.

Les grandes lignes

Déjà y a celle-ci :

lol

Sinon, en vrai :

un⋅e scrum master / scrum mistress : garant⋅e de la bonne application de la méthode (ponctualité, respect des dates de réunion, initie le daily-scrum…)
des product-owners : en général des non-informaticien⋅ne⋅s, garant⋅e⋅s de la cohérence des développements pour un projet (logiciel) donné (doivent définir les priorités de développement pour ce logiciel)
un⋅e super-product-owner : actuellement la patronne, qui définit les priorités de développement parmi tous les projets
tous les lundis à 10h00 : un pseudo-daily-scrum
- toute l'équipe (y compris les non-informaticien⋅ne⋅s) se réunit debout en cercle dans une grande pièce
- le scrum-master désigne une personne pour commencer en lui "passant la patate" symboliquement (un petit mime de lancer de légume est le bienvenu)
- cette personne présente brièvement (3mn maxi) ce qu'elle a fait la semaine précédente, et ce qu'elle fera cette semaine, en insistant sur les éléments intéressants pour le groupe (ex : "j'ai corrigé un bug" / "j'ai eu une réunion avec un partenaire potentiel" => oui, "j'ai répondu au téléphone" / "j'ai mangé des crêpes" => non)
- on n'interrompt jamais la personne qui parle, et on garde ses remarques pour la fin
- la personne "passe la patate" au suivant, et ainsi de suite
- le scrum-master clôt la séance et chacun⋅e peut continuer les discussions dans son coin
chaque fin de mois : un bilan de sprint
- on met à jour les sprints en cours sur Taiga (pour chaque projet)
- on met en ligne les nouvelles fonctionnalités développées durant le sprint du mois (si nécessaire on fait une nouvelle release des logiciels : tag Git ou branche SVN)
- on planifie, prépare et exécute une démonstration rapide (1h maximum) des nouvelles fonctionnalités, pour toute l'équipe (tant pis s'il y a des absents)
chaque début de mois : une planif' (peut être faite dans la foulée du bilan de fin de mois)
- on épluche Taiga avec les product-owners et la super-product-owner, et on définit les stories à traiter dans le sprint du mois qui débute, et les priorités parmi celles-ci
- on crée les sprints correspondants dans Taiga, et on reporte éventuellement le tout sur le tableau à cartons (voir ci-dessous)
un suivi des développements sur Taiga
- on formalise toute nouvelle proposition de fonctionnalité retenue par une story dans le projet correspondant, et on la découpe autant que possible en tâches
- on note les bugs au fur et à mesure de leur découverte sous forme de tickets, dans le projet correspondant
- on commente abondamment les stories, tâches, tickets, au fur et à mesure du travail
- on tient tout cela à jour : statut "à tester" lors de la mise en ligne en test, statut "fermé" lors de la mise en prod (au moment du bilan de fin de sprint)
un tableau avec des cartons
- élément historique; si on a vraiment du temps à perdre on peut y reporter sous forme de cartons de couleur l'ensemble des stories planifiées pour le sprint du mois, ce qui permet à l'équipe d'avoir une vision matérialisée trans-projet de la planification (Taiga ne propose pas cette vue…)

Différences avec le Scrum orthodoxe

il y a moins de développeur⋅se⋅s que de projets, par conséquent tous les projets sont réunis dans un même Scrum, afin de pouvoir définir les priorités
une super-product-owner définit ces priorités trans-projets
nos sprints durent 1 mois, du premier au dernier jour du mois, car c'est plus facile de caler les réunions (entre autres)
on ne fait de "daily scrum" que le lundi à 10h00, et les non-informaticien⋅ne⋅s participent aussi

Appliquer la maxime KISS

KISS est une maxime invoquant la simplicité en toute chose. C'est en lien avec le principe de raisonnement du Rasoir d'Occam.
Quelques citations :

« On devrait tout rendre aussi simple que possible, mais pas plus » [Albert Einstein]
« La simplicité est la sophistication suprême » [Léonard de Vinci]
« Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher » [Antoine de Saint-Exupéry]
« Pourquoi faire simple quand on peut faire compliqué ? » [Les Shadoks]
« Arrêtez de m'emm*rder et laissez-moi coder comme je veux » [Mathias]

Vrac

Mise en place d'un développement piloté par les tests

Il serait intéressant de progressivement développer des applications en se basant sur des tests. La méthode de développement pilotée par les tests permet d'avoir un meilleur suivi de la qualité des projets quand ceux-ci s'amplifient avec le temps.