vendredi 30 novembre 2012

Agile Tour Paris 2012 : Equipes de production ITIL et équipes de développement agiles, comment bien travailler ensemble ?

Alexandre Jacob de Coactiv revient sur son expérience dans la gestion de la relation entre des équipes de production et de développement où survenaient des problèmes de communication et de travail.

Voici le contexte :

D'un côté une équipe de développement agile :
- avec des livraisons hebdomadaires.
- plusieurs projets en parallèle.
- un besoin business instable.
- des technos vieilles et contraignantes (ça par contre, c'est hors agilité).

De l'autre côté, une équipe de production ITIL :
- un ensemble de bonnes pratiques.
- centrée sur le client.
- une plateforme stable.
- elle essaie d'avoir le moins de mise à jour possible.
- elle veut savoir ce qui est livré et quand.
- elle effectue des retours arrière faciles.
- elle est un détecteur de problèmes.

=> Les priorités et les valeurs sont différentes :
- mises à jour fréquentes vs. peu de mises à jour.
- développement rapide vs. détecter les problèmes + existence de procédures.
- mode réactif vs. mode proactif.
- ajout de fonctionnalités vs. faire vivre l'existant.

Cependant il y a des forces de l'équipe de production ITIL pour l'agilité :
- CSI : Continuous Service Improvement.
- très réactive face aux problèmes.
Par contre, ce qui n'est pas bon :
- la gestion du changement est complexe.
- le rythme des releases n'est pas adapté.

La question qui s'est alors posée était : "Comment rendre son équipe de production agile ?"
- le plus universel : Kanban.
- Passer aux flux tirés.
- avoir un backlog alimenté par l'équipe QA qui pousse les items testés.
- faire des rétrospectives.
- être piloté par la valeur métier.
- automatiser ce qui a peu ou pas de valeur ajouté.

Ainsi, Alexandre Jacob nous propose les clés suivantes pour organiser une équipe de production pour qu'elle soit agile :
- accepter le changement.
- collaboration avec l'équipe de développement (daily, planning).
- objectifs communs et partagés.
- automatiser les process de delivery.
- simplifier les process de gestion du changement et de release.
- créer une synergie et de la collaboration entre les équipes de dév et de prod.
- organiser le suivi et le traitement des anomalies ensemble.
- pour aller plus loin dans la collaboration : DevOps


ROTI : 4/5

lundi 26 novembre 2012

Agile Tour Paris 2012 : Tests et agilité - la vraie vie

Sylvain François de la start-up Kalistick nous propose une démystification des tests.
Il part du constat suivant :
- L'agilité est empreinte de la notion de "Definition of Done" pour les user story et les tâches.
- Cependant il subsiste une difficulté à définir le Done pour les tests.

Cela est difficile en Agile à cause :
- des livraisons rapides
- du développement incrémental
- de l'adaptation au changement
...
beaucoup de challenges donc et un besoin d'automatisation des tests.

Différents mythes tournants autour des tests ont engendré ce constat.

Mythe n°1 : la phase de test est incontournable
Dans les faits, cela n'arrive pas forcément, on a plutôt ça :
- pas de ressource spécialisée dans le test
- P.O = testeur
- pas de stratégie de test
- mal outillé pour les tests
exemples concrets :
- pas de tests fonctionnels poussés
- désactivation voir modification des tests pour les faire passer


Mythe n°2 : il existe une synergie testeurs / développeurs
En réalité, les testeurs et les développeurs ne vivent pas dans le monde et les objectifs sont parfois antagonistes (surtout quand les testeurs sont par exemple objectivés sur le nombre de bugs découverts). Les testeurs ont pour tâche d'identifier du bug Les développeurs ont pour tâche de "cacher" du bug
exemples concrets :
- des développeurs qui refusent des fiches de bugs si elles ne sont pas assez précises
- des testeurs qui refusent de tester
- des testeurs et des développeurs qui ne se parlent pas


Mythe n°3 : l'application est testée le plus en amont possible
Sylvain François nous explique que la pyramide de Mike Cohn est souvent inversée en tests manuels :
Il faut donc mettre en place des tests dès le développement !
Mais ce n'est pas évident : les TDD par exemple sont difficiles à mettre en place, l'écriture et la maintenance sont coûteuses.
Exemples concrets :
- des tests manuels sont effectués sur le sprint n puis les tests automatisés sont écrits au sprint n+1
- il faut alors dédier une équipe à l'automatisation des tests


Syndrome du fromage suisse
Le principe est que chaque couche de tests ne peut être exhaustif mais chaque couche couvrant potentiellement des parties non couvertes par d'autres, les zones se recouperont.
Il arrive que des cas ne soient pas testés du tout et là, il y a deux scénarios :
- cette partie ne fait pas partie des modifications livrées donc elle n'a pas généré de bug avant
- cette partie fait partie des modifications livrées et elle devient donc prioritaire à tester


Le graal de l'automatisation
Automatiser les tests c'est :
- des gains de productivité
- de la reproductibilité
- de la traçabilité
- moins ingrat pour les testeurs


Mais il y a des problèmes :
- le démarrage (monter en compétence, prioriser les tests à automatiser, refondre les tests existants, choisir l'outil)
- le coût de maintenant (compléxité d'implémentation, résistance des tests au changement)
- l'exploitation des résultats (origine des KO ?, pertinence des OK ?)
- performances (volume à analyser)


Conclusion :
- il est important de savoir ce qui est testé ici et là
- il est important de prioriser les tests car l'exhaustivité n'est pas atteignable
- il y a des écarts entre objectifs et réalité
- automatiser ne solutionne pas tout
- il faut identifier des critères de priorisation
- la couverture de code est une réponse mais il y en a d'autres


ROTI : 4/5

vendredi 23 novembre 2012

Agile Tour Paris 2012 : REX - 10 pièges à éviter

Tuan Vo Vinh de la Société Générale nous propose son retour d'expérience de la transformation agile et plus particulièrement de la mise en place de Scrum au sein des équipes qu'il gère. Il nous explique que sa motivation était sa frustration de n'avoir assisté jusqu'ici qu'à des conférences présentant des retours d'expérience de transition agile positive et sans problème. Son objectif est donc de nous présenter les erreurs et ratés qui sont survenus sur ses projets mais également les solutions qu'ils ont trouvées pour régler ces difficultés. Sa présentation consistait donc en une liste de 10 erreurs commises par une partie ou l'autre et ce que lui, en tant que non-agiliste, et ses coaches ont appliqué comme solution.

1) La fraude sur la marchandise :
Certaines choses paraissent évidentes pour les utilisateurs comme par exemple le fait que les anciennes fonctionnalités seront inclus dans le projet de refonte de leur produit. Malheureusement, ils n'expriment pas ce besoin auprès du PO qui acte donc le fait qu'ils ne souhaitent plus certaines fonctionnalités...
Solution proposée : avoir une liste d'exigences et un minimum viable product bien définis.

2) La prime d'assurance :
Le coût de l'agilité n'a pas été anticipée. Surtout l'erreur a été commise de considérer que les sprints seraient un succès à 100%, ce qui a entrainé un surcoût au final.
Solution proposée : prendre en compte le coût de l'agilité (rituels et estimation)

3) Oublier la vision :
Il survient au fil des sprints un problème de vision à long terme. Le PO reste focalisé sur le sprint N+1 voir N+2 mais en oublie qu'il y a par exemple une v2 dont les exigences peuvent demander certains aménagements pour éviter le faire/défaire/refaire.
Solution proposée : Remember the future en permanence !

4) "In God we trust" :
Penser à tort que le PO sait tout et ne se trompe jamais.
Solution proposée : challenger le PO, par l'équipe ou le project manager.

5) Engagement mou :
Il arrive que l'équipe ait une baisse d'engagement. Les solutions apportées par le management furent dans un premier temps agressives (heures supplémentaires) puis douces (récompenses en temps libre si engagement du sprint respecté). Cela n'eut aucun effet sur l'engagement.
Solution proposée : avoir des profils seniors moteurs

6) "Please do not disturb" :
Pas de gestion des imprévus alors qu'il y a des impératifs. Le sprint est trop isolé.
Solution proposée : l'adaptation ne veut pas dire échec. Acquérir la capacité de déscoper et restaffer.

7) Plaire au client, oublier le reste :
Typiquement les user story au black pour plaire aux demandes des sponsors/clients.
Solution proposée : ne pas sortir du backlog les fonctionnalités non fonctionnelles.

8) "What you see is NOT what you get" :
Conséquence de l'effet démo :le client pense à tort que parceque ça marche en démo, alors la fonctionnalité ne connaitra aucun bug en production.
Solution proposée : toujours avoir des tests UTILISATEURS avant le mise en production accepter les régressions tester les cas limites faire des sprints de bug fix

9) L'armée de clones :
Penser que tout le monde est identique car les performances individuelles sont masquées par l'équipe qui forme une entité. Le manager ne peut pas récompenser l'excellence individuelle.
Solution proposée : "one to one coaching et feedback" sans influence externe.

10) Pas pour les enfants :
l'Agile semble facile. C'est faux : la mise en place et le bon fonctionnement est difficile !
Solution proposée : choisir les bonnes personnes capable de le faire. Si les personnes n'acceptent pas l'agilité, c'est peut-être que ce n'est pas la bonne organisation pour l'appliquer.


Au final, ce qu'on peut voir c'est que l'agilité est difficile d'application. D'un point de vue personnel je ne suis pas d'accord avec certaines des solutions apportées qui font plutôt penser à une mauvaise compréhension de scrum. Cependant, chacun trouvera des solutions aux problèmes selon son contexte et les solutions proposées par Tuan Vo Vinh ont le mérite d'avoir fonctionné pour les projets SGIB, dans leur environnement particulier, ce qui n'est pas forcément une mauvaise chose après tout...

ROTI : 3/5

lundi 5 novembre 2012

Memento Scrum à destination de l'équipe

Mise à jour du 16/01/2013 : La version 1.1 du mémento est disponible en suivant le même lien.
Il est également disponible sur developpez.com !



Ca y est ! J'ai enfin réussi à finir ce mémento ! pfiou... \o/
Comme on me l'avait dit, le cadre de la méthode Scrum se veut simple : il y a les rôles, les artefacts, les rituels.
Mais la mise en oeuvre est complexe et parfois ardue même. Pour qu'elle soit correcte, il faut qu'elle soit suivie en engageant un coach par exemple qui accompagnera votre organisation dans sa transformation agile.

Alors pour répondre au premier besoin, c'est-à-dire constituer un résumé du cadre de la méthode Scrum, un mémento (un anti-sèche si vous voulez) me semble un support assez pratique :)

Quand je dis "à destination de l'équipe", cela veut dire que les informations contenues dans ce document sont utiles aux membres de l'équipe de développement pour leur permettre de travailler sur un projet Scrum. L'idée est d'avoir en un coup d'oeil des renseignements de base, en cas de trou de mémoire (comme on fait lors d'un examen, oups...).

J'aurais pu faire un billet avec exactement le même contenu mais un dépliant est plus facile à consulter une fois imprimé et plié comme montré ci-dessous :

Vous pourrez le poser dans un coin de votre bureau et l'ouvrir dès que vous voulez vous remémorer un élément. Puis vous pourrez le mettre à la poubelle une fois que l'équipe n'aura plus besoin de pense-bête :)

Pour finir, voici le lien vers le fichier PDF à imprimer chez vous !
Si votre imprimante gère le recto verso, il faut cocher l'option "Imprimer en recto verso", puis le radio bouton "Retourner sur les bords courts".


Je tiens à remercier Thierry pour ses nombreuses relectures.