Qu'est-ce que Scrum ?

Scrum est une meilleure façon de travailler

Scrum est sûrement une meilleure façon de travailler. Par-dessus tout, Scrum est une méthode de gestion de projets qui fait partie des méthodologies agiles. Scrum est un cadre qui fournit seulement quelques règles à suivre. Il réduit les risques, maximise le retour sur investissement, et dit la stricte vérité sur l'évolution du projet. Les métriques utilisées pour mesurer la vélocité de l'équipe offre un nouveau point de vue sur le développement du produit et permet une meilleure précision sur la planification à long terme du développement.

Fondements de Scrum

"En 1995, Ken Schwaber et Jeff Sutherland ont présenté la méthodologie Scrum durant le Business Object Design and Implementation Workshop tenu lors de l'Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA'95), à Austim, au Texas, sa première présentaiton publique."
(Traduit de l'anglais : wikipedia.org)

"Scrum est un simple cadre qui permet une collaboration d'équipe efficace sur des projets complexes. Scrum fournit un petit ensemble de règles qui crée une structure suffisante qui permet à l'équipe de se concentrer sur son innovation à résoudre ce qui pourrait autrement représenter un défi insurmontable."
(Traduit de l'anglais : Scrum.org)

L'équipe Scrum

L'équipe Scrum compte trois rôles principaux :

• Scrum Master, responsable d'appliquer les règles proposées par la méthodologie Scrum
• Product Owner, responsable du meilleur retour sur investissement (généralement représenté par le client)
• Development Team, responsable de la réalisation, de l'implémentation des fonctionnalités

Maintenant, pour les traductions de ses rôles :

• Scrum Master : On ne voit pas vraiment de traduction française pour ce rôle. Quoiqu'il en soit, il pourrait peut-être être traduit comme "Maître de mêlées", ou encore comme "Chef de mêlées". Bref, aucune traduction à ce jour, à ma connaissance du moins, n'a été définie.
• Product Owner : Ce rôle est souvent traduit par "Responsable de produit", ou encore on entend souvent simplement l'acronyme "PO".
• Development Team : Ce terme est souvent traduit par "Équipe de réalisation" ou tout simplement par le mot "Équipe", qui sous-entend l'équipe de développement.

Le Scrum Master

Le Scrum Master est bien sûr responsable de l'application des règles de Scrum, mais encore lui incombe-t-il de remplir les tâches suivantes :

• Retirer les obstacles
• Guider l'équipe de réalisation dans ses décisions du point de vue de Scrum
• Guider le responsable de produit dans son rôle
• Rédiger les rapports de rétrospectives
• Rédiger les bilans d'itération
• Mesurer le succès d'une itération en se basant sur les métriques définies par Scrum
• Informer le responsable de produit et les parties prenantes de l'évolution des travaux
• Accompanger l'équipe de réalisation dans la proposition de voies d'amélioration sur sa façon de travailler ou de s'organiser
• Aider le responsable de produit, l'équipe de réalisation et les parties prenantes à mieux comprendre le développement logiciel avec Scrum
• Mettre l'emphase sur la communication directe avec le client
• Assurer que les périodes de temps définies par Scrum sont respectées (Planification d'itération, rétrospective, démonstration, mêlée quotidienne et l'itération en elle-même)
• Conseiller l'équipe de réalisation quant à la façon d'évaluer la complexité des histoires-utilisateurs
• Proposer différentes stratégies de réduction du risque
• Aider l'équipe de réalisation à estimer le temps requis à la réalisation des tâches
• Planifier la disponibilité de l'équipe de réalisation
• Informer le responsable de produit de la disponibilité de l'équipe de réalisation

Le responsable de produit

Le responsable de produit est quant à lui responsable d'une part d'assurer le meilleur retour sur investissement, and selon le cas, de définir les critères d'acceptation :

• Définir les fonctionnalités requises
• Écrire les critères d'acceptation
• Informer dans le détail l'équipe de réalisation au besoin
• Prioriser les fonctionnalités dans le carnet de commande
• Obtenir les réponses que l'équipe de réalisation ne peut obtenir d'elle-même
• Assister à la mêlée quotidienne autant que possible (pas obligatoire, néanmoins très encouragé)
• Accepter, avec les parties prenantes, les fonctionnalités livrées durant la revue d'itération (le responsable de produit a préscéance sur les parties prenantes en ce qui a trait à l'acceptation des livraisons)
• Participer aux rétrospectives d'itération
• Décider si oui ou non une histoire peut être stuatée Terminée lors de la revue d'itération

L'équipe de réalisation

L'équipe de réalisation a la responsabilité, disons-le, de réaliser le développement des fonctionnalités requises par le produit. Cela comprend donc :

• Évaluer la complexité des histoires-utilisateurs prescrites au carnet de commande (alias Poker de planification)
• Estimer en heure le temps requis pour réaliser les tâches (ou selon l'unité de mesure choisie par l'équipe)
• S'engager à livrer les fonctionnalités prescrites par les histoires-utilisateurs en respect à l'échéancier prescrit par l'itération (basé sur le pointage évaluer de l'équipe et sa vélocité)
• Définir le terme Terminé avec le Scrum Master et le responsable de produit dans le but qu'une seule définition soit comprise
• Documenter les travaux
• Écrire les tests d'acceptation basés sur les critères d'acceptation fournis par le responsable de produit
• Tester les fonctionnalités développées pour qu'elles répondent aux exigences
• Créer les tâches nécessaires à la réalisation de chacune des histoires-utilisateurs
• Développer les fonctionnalité, bien entendu
• Préparer la revue d'itération avec les histoires complétées et préparer un ou plusieurs cas/scénario au besoin

Bienvenue aux changements !

Plus le projet est complexe, plus il y a de changements. Tous les changements doivent être adoptés le plus tôt possible - le plus tôt le est le mieux !

Si un changement quelconque a lieu, cela ouvre la porte à la flexibilité de s'y adapter et au final, on s'assure de livrer ce que le client a vraiment besoin. Il est certainement impossible de planifier de que vous aurez besoin dans un mois d'ici, car vous ne savez sûrement avec précision ce qui se produira dans un mois !

Le développement logiciel est un domaine extrêmement complexe - ne serait-ce que de comprendre en totalité le domaine des technologies de l'information, en plus de comprendre en tout ou en partie le domaine d'affaires du client. C'est vraiment un travail ardu !

Les changements peuvent survenir directement du client, ou encore du responsable de produit qui n'avait pas pensé à tenir compte d'un élément en particulier. D'autres changements peuvent aussi venir de l'équipe de développement qui comprend davantage le domaine d'affaire du client final ce qui, par la même occasion, invalide certaines décisions prises plus tôt, car elles n'ont plus leur raison d'être dorénavant.

Or pour toutes ces raison, il est important de s'adapter aux changements, d'où une bonne gestion des changements doit être faite, ce que Scrum permet.

Transparence

Les autruches n'ont pas leur place dans une équipe Scrum. Scrum demande par dessus la transparence vis-à-vis le client, l'honnêteté. Si pour une raison ou une autre vous ne pouvez livrer la marchandise selon l'échéancier prévu, vaut mieux en informer le client le plus tôt possible - dans ce cas-ci le responsable de produit. De cette manière, le responsable pourra prendre sur lui de réajuster le tir au besoin, et en aviser les parties prenantes. Un obstacle quelconque pourrait également entrainer un changement dans les priorités, d'où la nécessiter d'en aviser le responsable le plus tôt possible dans le processus de développement.

Au fil dans ans, j'ai appris que les gens comprennent lorsqu'on leur en laisse la chance en les informant de manière totalement transparente. Il ne faut pas prendre cela comme échec, et surtout ne rien prendre personnel. Des difficultés, des obstacles, des empêchements ou autre, ça arrive à tout le monde.

Parlant de transparence, il est important que le responsable de produit et les parties prenantes puissent vérifier l'évolution du projet en tout temps, et ce, en temps réel. Une rigueur supplémentaire est alors requise de l'équipe de réalisation quant au suivi de la fermeture des tâches, de la saisie du temps de réalisation réel versus le temps planifié, l'inscription des bloquants et des bogues est aussi nécessaires pour assurer cette transparence. De cette manière, le client sait vraiment où en est le statut de son projet, ce qui lui donnera nécessairement confiance.

Waterfall versus Agile

L'approche Waterfall, contrairement à l'approche Agile, effectue une analyse complète de votre système et tente de comprendre d'un trait votre domaine d'affaire, ainsi qu'elle veut prévoir toutes les exceptions possibles, alors que même vous, comme fournisseur de services ou de produits, gérez certaines situation en faisant du cas par cas. Cette méthode de développement logiciel est calquée du domaine de la construction où, à chacune des étapes, le plan doit être accepté, certifié par un architecte ou un ingénieur avant de passer à l'étape suivante. Et lorsqu'un élément indésirable survient, on révise le tout en entier pour s'assurer que ça fonctionne bien et des de bien comprendre les impacts que ce changement aura au sein du projet tout entier. Or, cela signifie que toute la phase d'analyse doit être complétée, ensuite toute la phase de l'architecture, ensuite toute la phase du développement, en continuant avec les tests d'acceptation, pour finir avec la documentation. Par ailleurs, si l'une ou l'autre des étapes échoue, on reprend la précédente dans son ensemble, ce qui se révèle à des délais interminables et insensé, entrainant ainsi des dépassements de coûts exorbitants.

Les méthodologies agiles, quant à elles, s'adaptent beaucoup mieux aux changements en traitant toutes les phases du développement logiciel pour chaque fonctionnalité. C'est-à-dire, qu'on prend la première fonctionnalité à développer, et on en fait l'analyse, l'architecture, les tests, le développement et la documentation tout en même temps, ou dans la même itération. Alors, si une erreur survient sur une fonctionnalité seulement, et que les autres sont bonnes, on n'a qu'à reprendre une seule fonctionnalité, et les autres sont tout de même développées et acceptées ! Et nul besoin, surtout, de reprendre tout une phase. Même que si une histoire doit être reprise, sa complexité peut être révisée à la hause ou à la baisse, selon le cas, dans le but de présenter un portrait réaliste au responsable de produit avec l'acquisition d'expérience au fur et à mesure du développement du produit.

Conclusion

Il m'est malheureusement impossible de tout expliquer en une seule et simple publication sur un blogue, alors qu'encore aujourd'hui plusieurs bouquins sont écrits et plusieurs formations sont dispensées sur Scrum et d'autres méthodologies agiles. Dans mon prochain article, j'écrirai donc sur des aspects de Scrum que je n'ai pu couvrir dans celui-ci. Espérant néanmoins avoir piqué votre curiosité et vous en avoir appris un peu plus sur le sujet !

Merci de votre lecture !