Nous fêtons notre 12ème sprint

www.agiletour.com19/10/2011

Nous fêtons notre 12ème sprint demain

(le 21 octobre)Grégory CLADERA Régis DE PORRE

et la société RG SYSTEMES


Qui sommes-nous ?

RG Systèmes - Historique2008 Naissance du projet, puis POC et prototypage

fin 2008 Création de la société en SARL 2 créateurs : Régis De Porre et Grégory

Cladera

2009 +1 associé : Edouard Cole, RG Supervision version 1

2010 5 personnes, augmentation du capital à 50 000 € (fonds

propres)

2011 8 personnes, levée de fonds,passage en SAS à 130 000€, adoption de SCRUM + XP

Aujourd’hui 9 personnes (dont 5 développeurs)


Notre activité

Editeur de la solution SaaS RG SupervisionRG Supervision est une solution de monitoring de serveurs qui simplifie la vie des administrateurs systèmes car tout le back-office est hébergé par RG Systèmes (mode SaaS). Accès à une console web pour tout le paramétrage.

Développement continu Mises en production fréquentes

Back-Office : Bases SQL, programmes spécifiques en C++ (framework Qt)Front-Office : PHP, JavaScript, framework Symfony2Agent à déployer : C++ (framework Qt), multiplateforme Windows + Linux


L’équipe

EdouardLead DeveloperScrum Master

RégisResponsable technique

Product OwnerDirecteur général de RG

GrégoryResponsable commercial

« Client »Président de RG

FabienDéveloppeur Web

Membre de l’équipe

AlexandreDéveloppeur C++


GwegDéveloppeur C++


ValentinDéveloppeur C++


Marie-AdelineAssistante commerciale

NatachaComptable


Pourquoi SCRUM ?

Sortie du mode « héros »Mode héros : parfait pour démarrer et aller vite au début, beaucoup de

POC, de prototypages etc., mais trop hasardeux au niveau planification, trop fatigant à long terme.

Besoin de méthodologie de projetMode empirique inadapté pour encadrer une équipe qui grossit

Besoin d’organisation pour les développementsLa masse de code produit est plus une charge qu’une richesse et il a fallu

absolument rationnaliser l’organisation de nos sources.

Besoin de visibilité au niveau de la roadmapIl nous fallait absolument de nouveaux outils efficaces pour estimer la

charge des développements futurs, à long terme, et donc avoir une roadmap la plus juste possible.

Renforcement de la qualitéNécessité d’adopter des pratiques telles que XP pour augmenter la qualité

du code produit.


Outils & Méthodes

Le Backlog Redmine + Plugin Scrum + Modifs « maison »


Outils & Méthodes

Les storiesDécoupage fonctionnel


Outils & Méthodes

Le planning poker

Suite de FibonacciVotes plus petit et plus grand s’exprimentMoyenne ou re-vote

L’engagement

L’équipe décide de s’engager sur un certain nombre de storiesCalcul de la vélocité prévue pour le sprint suivant


Outils & Méthodes

Le sprint en cours


Outils & Méthodes

Le daily scrum

Réunion quotidienne de l’équipeDeboutAvancement

Notre notion de « fini »

Test / Démo => IntégrationT.U. (Qt) C++ AutoTest tous navigateursCoding Guidelines

Code review / Pair programmingPushed dans GITCode sauvegardéLivraison en Beta


Outils & Méthodes

Le Burndown Chart des tâches

Le Burndown Chart des stories

Les outils


La revue de sprint

Environ 2h en fin de sprintPhase de validation des développementsEn présence du clientQuestions / RéponsesIdéesL’occasion de brainstormer

Outils & Méthodes


Outils & Méthodes

La rétrospective

Environ 1h Equipe, Scrum Master et Product OwnerFaire ressortir les choses positives et les choses négatives


Les gains

Prise de conscience du statut d’éditeurLe passage à SCRUM, et surtout l’accompagnement à ce passage, nous a fait prendre

conscience de notre statut d’éditeur et de toutes les contraintes liées à ce statut.

Renforcement tangible de la qualité au travers de pratiques XPTests unitaires et automatisésProgrammation en binômeStandards de codeRythme soutenableUtilisation d’un gestionnaire de sources : GITIntégration continue

Meilleure estimation donc meilleure planificationDécoupage en stories : permet de rédiger des spécifications « sans douleur »Planning poker : ludique mais efficace car engageantSprints : Planification à long terme grâce au calcul de vélocité (exemple : agent linux)

Meilleure productivitéDécoupage en tâchesSwap moins fréquent entre les tâchesChacun sait en permanence ce qu’il a à fairePas de problèmes individuels bloquant : C’est l’équipe, ensemble, qui résout les

problèmes


Les bonnes surprises

Les tests automatisés : pas si difficile à mettre en œuvre

Des outils simples et performant existent.Exemple : Selenium pour le dashboard web, Jenkins pour le

back office

L’agile n’est pas la caricature dont certains parlent

« L’agilité, c’est pour les enfants et les singes… »Pas qu’un effet de mode

Management de l’équipeImplication et responsabilité des développeurs

OrganisationUne aide pour l’intégration d’un nouveau

développeur


Les difficultés

Sortie du mode « Héros » : Partage des rôlesQui a quelle fonction ? Choix du Scrum Master et du Product Owner3 têtes pour 2 casquettes…Rôles et responsabilités de chacun à cloisonner, fonctionnement contraire

au mode « démocratique » d’avant

Impression de ralentissement de la roadmapPériode de rodageAugmentation de la qualitéMise en évidence des dettes techniquesMise en évidence du « reste à faire » colossal (nombre de stories énorme

au début)

« Ah ouais je comprends pourquoi on appelle cela : sprint ! »

dixit les développeurs.Bouleversement des méthodesImpression de courir après les points et uniquement après les pointsNotion de finiEngagez-vous qu’y disaient !Avancement « visible » de tous (burndown chart) et comparé à la courbe

« idéale »


Le bilan

Bilan Positif !

Le SCRUM nous colle à la peau

Très adapté aux éditeurs de logiciels, et encore plus dans le monde du SaaS / Cloud

QUESTIONS / REPONSES


Merci à nos sponsors !

Nous fêtons notre 12ème sprint

Technology

Transcript of Nous fêtons notre 12ème sprint