Énoncé budgétaire Agile, comment faire ?

Avant-propos

Je fus très occupé ces derniers temps, ce qui ne m'a pas permis d'entrenir mon blogue. Et tant qu'à publier juste pour publier, des articles sans contenu valable, j'ai préféré attendre de pouvoir prendre le temps et rédiger quelque chose avec plus de substance.

Ce nouvel article m'est venu suite à une soumission que j'ai faite à un nouveau client.

Le client, après m'avoir exposé le sommaire des fonctionnalités qu'il avait besoin dans un nouveau système, m'a demandé de lui produire une soumission dans un délais plutôt court lui indiquant combien de temps de réalisation pensais-je que son projet nécessitait. C'est un piège ! Car en corrélation avec le taux horaire de mon entreprise, il pouvait s'attendre à un prix X, ce qui n'est pas forcément un estimé réel.

Le développement logiciel n'a rien de simple. Dans la négociation d'un contrat, il y a toujours un compromis à faire.

Malheureusment, et j'en ignore la raison, on dirait que les clients, une fois qu'ils ont défini leur besoins généraux, pensent que nous, les entreprises de développement logiciel, allons pouvoir arriver avec un prix bien précis, et trouver toutes les fonctionnalités dont ils ont besoin pour ensuite fixer tout cela dans le béton avec un contrat - pèse fort, trois copies ! - Mais non !

Dans cette publication, je vais tenter d'expliquer en quoi le développement ne peut fonctionner comme cela. Les clients perdent trop ! C'est désavantageux pour vous, mesdames et messieurs les clients ! 

Les trois incontournables

Il existe trois variables incontournables dans la gestion de projets. Et ce, peut importe le type de projet. Que ce soit en construction, en développement logiciel, en entretien ménager, bref, tous les domaines à ma connaissances ont ces trois variables.

1. Qualité
2. Portée
3. Prix

Le meilleur des mondes voudrait qu'on ait un logiciel de la plus grande qualité, avec toutes les fonctionnalités souhaitées, et au meilleur prix. 

La façon de ce faire, est d'établir une relation de confiance avec une firme de développement logiciel qui adhère scrupuleusement aux méthodologies Agiles.

La qualité

Qu'arrive-t-il quand vous ne voulez pas payer trop cher pour un article ? 

On sacrifie souvent sur la qualité du produit.

Le rénovateur professionnel

Dans le but d'éviter qu'une perceuse ne le lâche dès la première journée, il est concevable que l'entrepreneur en rénovation aille vers des marques plus reconnues pour leur qualité et leur caractéristiques techniques.

• La dimension du mandrin,
• S'il a'git d'une perceuse à percussion
• Les rotations par minutes
• Le torque de celle-ci
• Fonctionnalité de débrayage, pour le gypse, par exemple.

Ces "fonctionnalités" se trouveront, pour des outils de qualité professionnelle, chez des marques comme DeWalt, Bosh, Ridgid, Milwaukee et plusieurs autres du même calibre.

Le rénovateur ne veut pas de compromis sur la qualité de ses outils, car il peut perdre un temps précieux si un outil brise en plein milieu d'un chantier.

La qualité de son outil est non-négociable !

Le développement logiciel

Le développement logiciel cible les petites, moyennes et grandes entreprises (PMGE). Or, il s'agit alors de la création d'un outil de qualité professionnel. La qualité n'est donc pas un compromis intéressant à faire, d'autant plus que la firme de développement logiciel joue sa réputation à chaque produit qu'elle crée, alors je doute qu'elle soit intéressée à compromettre la qualité d'un système.

En clair, la qualité, ça se paie !

La portée

La portée peut être vue comme la quantité de travaux à effectuer par rapport à un temps donné. Plus il y a de fonctionnalités à développer, plus de temps cela prendra, et plus cher le système coûtera.

S'il y a une constante dans le développement logiciel dont je suis sûr, c'est bien que la portée change toujours au cours d'un projet de développement. C'est en raison de cela qu'il est si difficile de fixer les prix dans un contrat, car il faut aussi fixer la portée.

En général, on s'entend pour établir trois niveaux de foncitonnalité.

• Obligatoire
• Linéaire
• Facultative

Les fonctionnalités obligatoires

Les fonctionnalités obligatoires sont celles qui définissent votre système. Sans elles, votre système n'a aucune raison d'être. Celles-ci représentent ce qui donne le plus de valeur à votre système. Elles constituent les fonctionnalités qui vous procureront le meilleur retour sur investissement.

On leur donne une valeur d'affaires de dix (10).

Les fonctionnalités linéaires

Les fonctionnalités linéaires représentent des foncitonnalités très près de votre coeur, elles ont une importance certaine, et elle figurent au deuxième rang, après les fonctionnalités obligatoires. Ce sont des foncitonnalités dites "nice to have", et elles sauraient ajouter une valeur à votre système à coup sûr, et leur valeur sont tout de même moindre que les fonctionnalités obligatoires.

On leur donne une valeur d'affaires de vingt (20).

Les fonctionnalités factulatives

Les fonctionnalités facultatives sont, tel que suggéré par leur nom, optionnelles. Elles devraient être les premières à être sacrifiées dans le cas où des coupures au niveau des foncitonnalités doivent être faites.

On leur donne une valeur d'affaires de trente (30).

La portée en développement logiciel

La portée est à la fois la seule variable négociable, et la plus difficile à évaluer. C'est elle qui rend l'estimation d'un développement logiciel aussi complexe.

Je dis souvent qu'il est possible de tout faire avec les technologies de l'information. Mais à quel prix ?

La portée viendra nécessairement influencer le coût d'un développement logiciel. 

Prenons par exemple notre rénovateur professionnel énoncé plus haut. Il vous fera un estimé pour la rénovation de votre salle de bain. Si vous êtes bricoleur le moindrement, vous saurez qu'il est parfois impossible de savoir à l'avance quels seront les travaux nécessaires à effectuer, car c'Est souvent en commençant les travaux qu'on s'aperçoit qu'une partie du plancher est pourrite, ou qu'il y avait une fuite minime d'eau, pas assez importante pour que vous l'ayez constaté avant, mais suffisamment pour avoir fait pourrire le contreplaqué du plancher. Vous ne pourrez ignorer cela ! Vous devrez alors augmenter la portée des travaux, et résoudre votre problème de plomberie, en même temps que de changer votre contreplaqué, et refaire votre plancher, même si ce n'était pas prescrit dans vos intentions initiales.

C'est la même chose en développement logiciel, mais en plus complexe, car il n'est pas possible d'établir de métriques précises sur un projet, car le même logiciel développé pour deux clients différents ne résultera pas au même système.

D'ailleurs, la seule constante dont tous les fournisseurs en développement sont certains, c'est que la portée changera tout au long du projet. Alors, comment anticiper les changements ?

Une foncitonnalité qui peut sembler simple à première vue, peut s'avérer très complexe une fois qu'on l'explore plus en détail. Malheureusement, on n'explore pas tout en détail lors de l'évaluation, autrement on devrait charger, et ça, faut éviter, pour une estimation !

Il est donc très important pour vous et pour nous que vous sachiez catégoriser vos fonctionnalités selon leur niveau.

En clair, seule la portée peut être négociable.

Le prix

Le prix dépend de la portée et de la qualité du développement. Comme la qualité n'est pas négociable, on parle donc ici d'une variation en fonction de la portée.

Pour s'assurer de créer de la valeur pour vous, monsieur le client, l'industrie du développement logiciel a adopté depuis plusieurs années maintenant des nouvelles méthodologies dites Agiles.

En développement logiciel

Étant certaine d'une seule chose, l'augmentation de la portée dans le temps, l'entreprise en développement logiciel qui sera forcée d'établir un prix forfaitaire devra soumissionner deux et trois fois plus cher que le système en coûterait développé selon les méthodologies adaptées à son industrie.

Autrement, elle devra absorber les débordements de coûts, et fera faillite dans les prochaines années, ayant dû absorber trop de fois la perte liée à l'augmentation de portée.

Les deux seules issues sont alors la faillite de l'entreprise en développement logiciel, ce qui vous laisse sans support, pour un système que vous avez fait développé. 

Ou encore, vous payez beaucoup trop cher, car l'entreprise de développement logiciel n'envisage pas la faillite pour votre projet. Dans les deux scénarios, vous êtes perdant.

La méthodologie Scrum

Scrum est un cadre de gestion de projet agile qui vous permet de choisir le niveau de risque que vous êtes prêt à prendre pour le développement de votre système. 

La durée de l'itération est ni trop longue, ni trop courte selon le niveau de risque que vous êtes prêt à supporter. L'itération peut avoir une durée d'une deux ou quatre semaines.

Lorsque le temps de l'itération est écoulé, l'équipe de développement vous démontre les travaux effectuer. C'est alors que le lein de confiance s'établira avec votre fournisseur, en voyant une partie de votre système fonctionner devant vous en un si court lapse de temps.

Vous êtes responsable de l'entretien du carnet de produit. Celui-ci contient toutes les fonctionnalités souhaitées dans votre futur système. Elles sont priorisées de la plus importante en haut, à la moins importantes en bas.

L'équipe de développement s'engage alors à vous livrer une partie de ces foncitonnalité à la fin de l'itération, dans le but de vérifier avec vous si le développement correspond à votre besoin.

Comme cette méthodologie s'adapte très bien au changement, vous pourrez modifier la portée à votre guise, tout en étant conscient que cela a un impact sur le prix.

Ce qui est magnifique dans cette méthodologie, c'est que vous êtes en tout temps au courant de ce qui se trime, et des difficultés rencontrées, ce qui vous aide à mieux saisir l'impact de certains éléments sur la complexité du projet.

En étant mieux informé, vous êtes en mesure de prendre de meilleure décision quant à la portée du projet et à l'augmentation des coûts inhérants.

Comme cela, tout le monde gagne !

Conclusion

En somme, tentez d'éviter les contrats à prix fixes. Plutôt, fixez la portée qui elle viendra définir le prix. Et comme la portée change toujours en développement logiciel, le prix changera toujours aussi. Et vous serez avisé en quoi le prix a changé, et il n'en tient qu'à vous après cela d'accepter l'augmentation du prix, ou de le maintenir en retirant une fonctionnalité du niveau de votre choix.

L'expérience-utilisateur, un gage de qualité !

Dans une récente publication, j'ai parlé des dépassements de coûts et des échéanciers du développement logiciel. J'ai tenté en vain d'expliquer quelques unes des causes probables selon mes observations et mon expérience du terrain au sein d'entreprises d'envergure et de ministères et organismes gouvernementaux du Québec.

Les dépassements de coûts et des échéanciers peuvent aussi venir jouer sur la qualité d'un logiciel développé à la hâte dans des délais trop serrés. Le client doit être conscient de cela, car ce logiciel a pour objectif de l'aider dans son processus d'affaires et lui faire épargner temps et argent. Pourtant, encore aujourd'hui des logiciels font perdre d'importantes sommes aux entreprises et aux gouvernements.

Dans un premier cas, je vous citerai certains cas d'exemple tiré du Spetrum IEEE et du Québec, pour enchainer sur la façon dont tout cela peut être éviter, pour finir avec l'approche agile du développement logiciel piloté.

Exemples de projets qui ont mal virés

Spectrum IEEE

Plusieurs cas de logiciels défaillants sont rapportés par le Spectrum IEEE. Certains logiciels ont causé la faillite de certaines entreprises, tandis que d'autres ont coûté des millions, voir même des milliards de dollars.

Avez-vous déjà vu disparaître un entrepôt ? En 2005, le système de gestion d'inventaire de la compagnie Hudson Bay Co. (Canada) fait disparaître un entrepôt. L'entrepôt était toujours là physiquement, et des travailleurs y travaillaient chaque jour. Néanmoins, les produits destinés à cet entrepôt étaient redirigés vers d'autres entrepôts par le système informatique. Pendant trois ans, rien n'a été réceptionné ni n'a quitté cet entrepôt. Le système de paie étant administré par un autre système, les employés de l'entrepôt disparue étaient payés. En bout de ligne, le système informatique a contribué à 33,3 M$ en perte à l'entreprise.

En octobre 2004, au Royaume Uni, le géant de la distribution alimentaire J Sainsbury PLC a dû laisser sur la tablette son investissement de près de 527 M$ pour un système de gestion de la chaîne logistique automatisée. Il semble que la marchandise était coincée dans les dépôts et les entrepôts de la société. Sainsbury a été contraint d'embaucher environ 3 000 employés supplémentaires pour stocker ses étagères manuellement.

Pour d'autres anecdotes tirés du Spectrum IEEE : Why Software Fails.

Au Québec

La CARRA a fait les manchettes avec sa solution RISE évalué initialement à 30M$, et qui a coûté plus de 100M$ au final (Rien ne va plus à la CARRA). De plus, comme si ce n'était pas suffisant, des problèmes persistent !

Le CSPQ engloutit près de 450M$ dans le projet le plus important du gouvernement, SAGIR (450M$ engloutis dans le projet SAGIR)

Des moyens de contraception

Ces problèmes bien qu'informatiques, ne sont pas liés directement à la technologie de l'information proprement dit. Il s'agit d'abord et avant tout d'un système de valeur inaproprié et d'une incompréhension de la complexité du développement logiciel et de tout ce qui y ait relié.

Au gouvernement, les projets informatiques ne regardent pas seulement le développement logiciel, bien qu'il s'agisse du point généralement le plus important. On parle aussi de d'infrastructures réseaux, de plusieurs centaines de serveurs, avec des stations de stockage réseau et toute l'expertise pour mettre tout cela en place. 

Quoiqu'il en soit, les demandes de service sont toujours rédigés de sorte que la soumission du consultant doit comprendre un montant forfaitaire qui englobe tout, tout, tout ! Si on se fie aux mésaventures illustrées ci-haut, ce n'est pas possible.

Les ministères gouvernementaux et organismes paragouvernementaux devraient, à mon avis, être administrés comme des entreprises privés, d'une part, pour s'assurer de maximiser le retour sur investissement. D'autre part, l'utilisation des méthodologies agiles pourraient contribuer à une plus grande valeur et une plus grande qualité des produits développés, alors que celles-ci visent à créer la plus grande valeur d'affaires suivant la meilleure qualité possible. Autrement, on crée un système qui n'a aucune valeur aux yeux des utilisateurs et ce même système finira sur les tablettes. Or, à mon avis, il faut d'abord se soucier des utilisateurs et créer un système avec une excellente expérience utilisateur. C'est ce qui fait maintenant la qualité d'un système informatique.

Un gage de qualité

Aujourd'hui, on n'impose plus aux utilisateurs d'utiliser notre système. Les règles du jeu ont changées, et heureusement pour le mieux !

Plusieurs systèmes qui étaient développés en fonction de ce que les administrateurs d'une entreprise veulent, sans tenir compte des volonté ou de la réalité du terrain. Cela finissait pas des résistances aux changements de la part des employés qui finissaient par faire des épuisements professionnels ou rendaient simplement leur démission. Ces mêmes systèmes venaient compliquer la tâche de l'utilisateur final au nom d'une meilleure gestion des administrateurs, soit disant. Par ailleurs, il existe une expression populaire en informatique qui dit "garbage in, garbage out". Cette expression anglaise veut qu'un système ne produise seulement ce qui est saisi. Alors si on saisit n'importe quoi dans le système, on récoltera n'importe quoi à la sortie !

Apple a misé sur l'expérience utilisateur dans le passé, créant des outils conviviaux à la hauteur du génie de Steve Jobs. Voyez ce que cela donne aujourd'hui ! C'est en produisant des systèmes qui créent de la valeur aux utilisateurs que le système sera apprécié. Autrement, ce même logiciel sera considéré comme de la merde, et ce, même si la meilleure architecture est en place.

Des notions comme le design, l'ergonomie et la simplicité d'utilisation sont maintenant des prérequis nonobstant le système à créer. Et plus important encore : ne pas programmer un produit dont l'utilisateur n'en a rien à faire. Tout cela se résume par l'expérience-utilisateur, un gage de qualité !

Car en créant la plus grande valeur d'affaires en répondant aux besoins précis du client, en conjonction avec une excellente expérience-utilisateur qu'un système informatique gagnera des points vis-à-vis les clients.

Les dépassements, parlons en !

Les dépassements de coûts en développement logiciel en choquent plus d'un. Des projets dont l'estimé initial tourne autour de 17M$ se révèlent coûter plus de 100M$ à l'état. Pourquoi ?

Lors d'une récente publication, j'ai parlé de l'agilité, de son historique et un peu des valeurs qui y sont véhiculées. Quoiqu'il en soit, certaines personnes ne comprennent toujours pas les dépassements de coûts en développement logiciel, et du coup se révèlent plutôt hésitant, voir méfiant vis-à-vis les méthodologies agiles. Or je vais tenter d'éclaircir le tout selon mon point de vue personnel et mes expériences au sein du gouvernement du Québec en développement logiciel. Je parlerai d'abord des demandes de services, ensuite de la méthodologie Waterfall en V, et je parlerai aussi de quelques concepts clés de l'agilité, pour finir en faisant certains parallèles avec les deux méthodologies et la façon de négocier un contrat en TI.

La méthodologie Waterfall en V

Cette approche vient de la gestion de projets en construction. Le développement logiciel étant une jeune industrie encore aujourd'hui, on ne savait pas encore comment gérer un projet de développement logiciel de grande envergure. Ce qu'on avait de plus similaire ce sont les travaux d'importants chantiers de construction où, bien entendu, toutes les étapes jusqu'à la réalisation sont réalisées en séquence.

(de l'analyse des besoins au codage, et du codage à la recette)

On doit avoir complété à 100% chaque étape avant de passer à la suivante. Par exemple, si la Conception détaillée révèle une anomalie, l'étape de la Conception architecturale doit être reprise au complet! Et lorsqu'on passe la phase du codage et qu'on est rendu aux tests unitaires, et que les tests révèlent une anomalie, on doit reprendre la Conception détaillée, puis le codage, et ensuite recommencer la phase des tests unitaires. On définit ici une anomalie par un bogue du système ou encore un changement prescrit par le client, par exemple. C'est pourquoi ce modèle est très coûteux et très lourd dans le développement logiciel. On utilise un modèle de gestion de projets qui est bien adapté et mature pour l'industrie de la construction. Ce modèle est malheureusement inadéquat pour le développement logiciel, une industrie qui bouge très vite et qui doit s'adapter aux changements.

De plus, les équipes de développement typiques sont formées de plusieurs membres qui ont chacun leurs responsabilités et leur rôle à jouer. Ce qui signifie qu'on ne peut demander, par exemple, à un architecte de développer une fonctionnalité si les programmeurs sont dans le jus.

Les méthodologies agiles

Les méthodologies agiles proviennent de l'expérience de 17 professionnels internationaux qui oeuvrent en technologies de l'information (voir Qu'est-ce qu'Agile?) qui se sont réunis pour définir certaines règles tirées de leur expérience. De leur rencontre ressort entre autre Scrum, une méthodologie agile de gestion de projets. Le cycle de développement diffère en plusieurs points de l'approche Waterfall en V.

Cycle de développement selon Scrum

Ce qui signifie qu'au bout de 30 jours, une équipe peut livrer un incrément fonctionnel potentiellement livrable du logiciel. C'est lors de la revue d'itération que l'équipe de réalisation présente le logiciel à date au responsable de produit et aux parties prenantes.

Pour une raison ou une autre, si les fonctionnalités développées ne correspondent pas à la volonté du client, on s'adapte et on reprend les travaux pour les 30 prochains jours, après avoir eu un ou des entretiens avec le client (ou responsable de produit) afin d'apporter les changements nécessaires. C'est lors de la rétrospective d'itération que l'équipe Scrum se rencontre pour faire le point sur l'itération et suggérer des pistes d'amélioration quant au déroulement de l'itération qui se termine. Ces suggestions devront être mises en application immédiatement à la prochaine itération, i.e. celle qui débute de suite.

Durant chaque itération, l'équipe de réalisation se concentre uniquement sur les fonctionnalités pour lesquelles elle s'est engagée, et les réalise en ordre de priorité établi par le responsable de produit pour qui la responsabilité la plus importante constitue le retour sur investissement du développement du produit. Une itération comprend les activités suivantes:

1. Analyse des besoins
2. Développement des fonctionnalités
3. Préparation de la démonstration au responsable de produit (et aux parties prenantes, s'il y a lieu)

Le développement des fonctionnalités

Durant la phase de développement, des tests d'acceptation et unitaires sont élaborés dans le but d'assurer la qualité du logiciel développé et renforcir une meilleure architecture. Or, c'est en faisant usage du développement piloté que l'architecture se conçoit d'elle-même en même temps que le développement évolue. Les équipes sont multidisciplinaires et interfonctionnelles.

Les dépassements

L'industrie du logiciel a subi une mauvaise presse en utilisant un modèle de gestion de projets qui n'était pas du tout adapté pour le développement logiciel. Néanmoins, en présence d'une nouvelle industrie émergente, on devait trouver une façon de gérer les projets et l'essayer. Ce fut alors l'adoption de la méthodologie Waterfall. L'industrie s'ajuste maintenant vers une nouvelle approche! Et ça a commencé à changer dans certains organismes paragouvernementaux qui ont adopté l'agilité.

Est-ce que tous les dépassements sont liés à cette méthodologie ?

Sûrement pas ! Ces dépassements sont aussi dû à certains choix technologiques ou des politiques d'utilisation de certains outils qui freinent le développement. La complexité de certaines entreprises privés ou de certains ministères ou organismes gouvernementaux viennent accroître ces dépassements de coûts et d'échéancier. Et il est possible que des dépassements de coûts surviennent dans le futur même avec l'adoption de l'agilité. Une méthodologie n'a aucun effet si l'administration d'un organisme, d'un ministère ou d'une entreprise n'adopte pas les valeurs de ces méthodologies. L'agilité représente bien plus qu'un simple ensemble de méthodologies appliqué au développement logiciel, et peut s'appliquer à la gestion d'une entreprise également.

Les contrats en TI

En développement logiciel, il est difficile d'établir une règle de trois pour déterminer combien de ressources on aura besoin.

Par exemple, dans le cas de la construction d'une niche à chien, à partir du moment où on connaît la grandeur du chien qui va habiter la niche, on peut déterminer la superficie du plancher, la hauteur des murs et du toit de la construction. On peut aussi calculer combien de clous on aura besoin, combien de feuilles de contreplaqués, etc. On a une excellente idée du coût de la construction.

En développement logiciel, il n'en est pas aussi simple. Et pourtant, combien de fois on me demande "Combien cela peut me coûter" ? On veut toujours savoir combien va nous coûter un projet avant même qu'il soit construit. Et c'est normal, compte tenu des budgets alloués par département ou par par projets. Par ailleurs, à moins d'un projet très simple, mais très très simple, il est quasi impossible de prévoir combien peut coûter un projet de développement logiciel, à mon humble avis. Pensez-y, un logiciel optimise en général vos processus d'affaires, chose qu'on ne savait faire sans le logiciel ! Un logiciel vous permet aussi de faire plus en moins de temps, ça a un coût - et ce coût devient un investissement lorsque bien géré et les risques bien contrôlés. Bien entendu, je ne parle pas d'un simple site Internet de quelques pages, mais bien d'un système de gestion intégrés complexes qui peut comprendre plusieurs sphères de vos activités.

Or, les projets gouvernementaux représentent souvent des projets de très grandes envergures. Il est certain qu'aucune personne peut évaluer avec exactitude combien il en coûtera. Néanmoins, les firmes de services conseils sont appelées à établir un montant, montant à partir duquel une idée du projet est faite et une stratégie de développement est développée. En bout de ligne, les prérequis changent, les besoins ont évolués ou on ne pouvait prévoir un élément de complexité caché, et c'est là que le coût du projet explose.

Conclusion

J'espère que cet article vous éclaire sur le dépassement des coûts et des échéanciers des projets de développement logiciel. Par l'expérimentation de la méthodologie Waterfall en V, on s'est aperçu que ce n'était pas adapté à l'industrie du logiciel. Cette industrie maintenant plus mature a trouvé un ensemble de méthodologie qui lui est plus adapté et qui, par la même occasion, devrait améliorer la réputation des services conseils en développement logiciel. Je suis curieux de voir ce qu'il en sera dans une trentaine d'années !

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 !

Qu'est-ce qu'Agile ?

On a toutes et tous sa définition du mot "agile". On sait par exemple qu'un chat est agile. Mais que signifie, dans l'industrie des technologies de l'information (TI), Agile ? Je réponds à cette question aujourd'hui.

D'abord, si vous pensez qu'Agile est nouveau, détrompez vous ! Le manifeste Agile a été signé en 2001 par un groupe de professionnels qui ont une réputation internationale. Tiré de l'article Agile manifesto sur Wikipédia :

"En février 2001, aux États-Unis, dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du Wiki via WikiWikiWeb, Kent Beck, père de l'extreme programming et cofondateur de JUnit, Ken Schwaber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l'ASD, Alistair Cockburn pour la méthode Crystal clear, Martin Fowler et Dave Thomas ainsi qu'Arie van Bennekum pour DSDM (Dynamic System Development Method), la version anglais du RAD (développement rapide d'applications)."

(Je rajouterais ici Robert C. Martin ("Uncle Bob"), père du Clean Code, soit la réingénierie et la réorganisation du code)

Or, de ces 17 experts mondiaux du monde du développement logiciel sont ressorties les règles qui régissent aujourd'hui les méthodologies agiles. Les valeurs ou règles des méthodes agiles encouragent la livraison rapide de fonctionnalités potentiellement livrables, tout en misant sur la qualité du contrôle qualité et du code source produit par l'équipe de développement.

• Les individus et leurs interactions plus que les processus et les outils
• Du logiciel qui fonctionne plus qu'une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L'adaptation au changement plus que le suivi d'un plan 

Cette énumération de valeurs des méthodologies agiles signifient que bien qu'il y ait de la valeur dans les de droite, l'agilité favorise les éléments en gras.

Les individus et leurs interactions plus que les processus et les outils

Cela signifie que bien qu'il soit important d'avoir de bons outils de communication comme les courriels, les espaces collaboratif de travail et autres, il est tout de même préférable d'interagir directement avec les individus. On favorise la communication la plus directe possible. On sait que parfois il est difficile d'exprimer certain degré de complexité dans un courriel ou autre, on encourage donc l'interaction directe, que ce soit en personne ou en vidéo-conférence, ce n'Est pas important, ce qui est important c'est être en équipe et échanger entre équipiers.

Du logiciel qui fonctionne plus qu'une documentation exhaustive

Vous est-il déjà arrivé de devoir entretenir une documentation complète, et de documenter chaque changement ? Combien de fois vous est-il arrivé de vous retrouver devant une documentation désuette ? L'agilité favorise une documentation minimale, car en bout de ligne, c'est avec un logiciel qui fonctionne que vous voulez travailler ! De plus, bien des gens ne lisent même plus les livres ou les guides utilisateurs, alors à quoi bon faire une documentation complète et doubler le temps requis du développement, alors qu'on peut documenter ce qui est nécessaire, et produire un logiciel qui fonctionne ?

La collaboration avec les clients plus que la négociation contractuelle

Cet élément est extrêment important, selon moi. Et c'est ici que j'ai le plus de difficulté, à faire participer les clients. D'abord, ce point met l'emphase sur une relation de confiance avec le client. Maintenant, je ne dis pas que l'agilité est contre les contrats ! Comprenez-moi bien, on préfère collaborer avec le client, amener le client à travailler avec nous pour la réussite du projet. En ce sens, si le client s'implique, il est en mesure de comprendre ce qui se passe, il est à l'affût des difficultés rencontrées et des directions prises par l'équipe de développement. Et s'il y a des changements à apporter, le client peut les apporter immédiatement, en étant informé de l'évolution des travaux en tout temps. De plus, la collaboration du client signifie également que c'est au client à définir SES priorités ! À partir du moment où le client a bien priorisé les éléments de travail, l'équipe de développement sait où elle s'en va et ce qu'elle doit faire en ordre pour rajouter de la valeur au client. Seul le client sait ce qui est important pour lui. De plus, cela évite de confier la responsabilité importante du développement de votre système informatique à une firme, et de ne plus en entendre parler durant des semaines, et en arriver au point où la moitié du logiciel est à reprendre car il y a eu des malentendus ou des erreurs dans les analyses préalables au développement.

L'adaptation au changement plus que le suivi d'un plan

On le sait, les besoins évoluent. C'est comme ça, on n'y peut rien ! Et comme il peut prendre un certain temps avant de compléter un système de gestion intégré, par exemple, il se peut que le besoin du client change en cours de route. Bien sûr il est important d'avoir un plan, on dira ici les grandes lignes directrices, si on veut. Néanmoins, on encourage ici l'adaptation au changement. Bien que le besoin initial était X, si maintenant il est Y, alors le système doit répondre au besoin Y, car X est périmé, invalide ou dépassé ! Un autre exemple pourrait être que comme client, vous n'êtes pas forcément au courant de tout ce qu'on peut faire en TI, ou encore des limites de certaines technologies. Et en suivant l'évolution du projet, des idées peuvent surgir de votre expérience, ou encore, vous aviez simplement oublié ce faire mention d'un détail qui vous paraissait anodin au départ, et qui au final se révèle crucial pour votre système. Ce détail peut entrainer plusieurs changements. Alors on favorise l'adaptabilité dans le but de répondre à VOTRE besoin, et non le nôtre.

Il existe plusieurs méthodologies dites Agiles comme Scrum et Kanban, pour la gestion et le suivi de projets, le BDD, DDD et le TDD pour le développement et l'écriture de code, et plusieurs autres outils adaptés et développés pour aider les équipes de développement et vous, comme client, à bien suivre les principes et ensemble collaborer pour des systèmes d'information de plus grandes qualité en moins de temps qu'il n'en faut pour le dire !

Mon histoire, là où tout a commencé

Dans ma dernière publication, j'ai dit que j'allais écrire un peu sur moi de manière à faire ma connaissance davantage. Alors voici mon histoire !

Lorsque j'ai gradué du Collège Shawinigan en 2005, j'avais déjà commencé à offrir des services techniques résidentiels et commerciaux sur site. À l'obtention de mon diplôme, j'ai offert mes services aux employeurs de la région de Shawinigan et Trois-Rivières, QC Canada. Malheureusement, j'avais le diplôme et je n'avais pas le profil, m'a-t-on à répétition. Aucun employeur n'était prêt à me donner ma chance. J'ai alors décidé de fonder mon entreprise en février 2005. Le mois suivant, un important incendie a ravagé ma résidence et j'ai tout perdu. Avec l'aide de mes proches, famille et amis, j'ai acheté mes premiers équipements, un bureau de travail et un ordinateur.

En octobre 2005, j'ai su qu'une compagnie de transport avait besoin d'un nouveau logiciel de gestion intégré. Nommons-la ABCT. J'ai offert mes services à l'entreprise et environ 7 mois après, à l'été 2006, un ami et moi-même livrions la solution quasi complète. Bien entendu, je n'avais pas encore entendu parlé des méthodologies Agile dans ce temps ! Seulement environ un mois après, lorsque les commis de bureau sont devenus plus aisés de travailler avec Transport Manager, et au final ils étaient capable de performer davantage à deux commis qu'à trois à l'ancienne façon. J'avais optimisé les processus d'affaires, simplifié la façon dont l'information était saisie et de plus, on avait dorénavant à la saisir qu'une seul fois, dans une seul système ! Ces améliorations représentaient une économie d'environ 45 000,00 $/an. Tout un succès pour une personne avec aucune expérience !

En 2007, la crise économique commence à sévir plus particulièrement au niveau des produits du bois, et ABCT a dû fermer ses portes. Je suis retourné sur le marché de l'emploi et ai décroché un emploi comme formateur en programmation dans un collège privé en technologies de l'information de la région (Multihexa de Trois-Rivières). Je me suis alors décourvert une réelle passion : le partage des connaissances ! Rien n'a été plus enrichissant pour moi que d'enseigner à des étudiants mon savoir et ma jeune expérience. C'est même à se demander s'ils ont appris autant que moi ! Malheureusement, le Collège a arrêté le programme par faute d'inscriptions. Je me suis alors dirigé vers une autre entreprise pour débuté l'intégration du système comptable Accpac. Après quelques mois, je ne m'y plaisais pas, alors j'ai décidé d'aller voir ailleurs si j'y étais. Finalement, je me suis retrouvé chez Alcoa Canada - divison primaire, l'usine de Deschambault. J'y ai travaillé plus d'un an, et à cause de la crise économique qui continuait de ralentir le marché, Alcoa a annoncé une réduction de 15% des heures travaillées. Parmi ces coupures, j'ai fait parti du lot de congédiement. C'est alors que j'ai décidé de revenir à la charge avec ma propre entreprise, et bien que l'économie ne soit pas en faveur, j'ai commencé à regarder pour des contrats à la grandeur de la province. Mon premier contrat a été comme analyste-programmeur pour développer des rapports pour la RAMQ. 2009 a été assez tranquille.

En 2010, j'ai eu la merveilleuse opportunité de rencontrer monsieur Ken Schwaber lui-même, co-fondateur de Scrum et président de Scrum.org. J'ai suivi ma formation de Scrum Master avec lui, et je suis maintenant certifié Professional Scrum Master I ! Mon premier mandat comme Scrum Master était l'enfer ! Il y a vraiment tout un monde de différence entre la théorie et la pratique ! Et maintenant que je le maîtrise, je souhaite partager avec quelques unes de mes Aventures Agile.

En 2013, j'ai décidé de changer l'image de mon entreprise. Ma famille et moi-même trouvions que Général Informatique donnait plutôt l'image de la boutique d'informatique du coin de la rue. Alors j'ai mis tout en oeuvre pour changer l'image et voici que maintenant, mon entreprise fait affaires sous le nom de la Société Groupe Conseil WMI. Et c'est où j'en suis aujourd'hui !

Maintenant que vous me connaissez mieux, je crois avoir quelques savoirs à échanger avec vous autant comme entrepreneur que professionnel en technologies de l'information. Bien que personne n'ait la science infuse, je pense qu'on peut grandir ensemble en partageant et en redonnant aux autres. C'est l'objectif de ce blogue. J'espère que vous avez apprécié en apprendre davantage sur moi, et que cette histoire saura en inspirer d'autres.

Merci de votre lecture !

Bienvenue à vous !

Je suis Will Marcouiller, fondateur et président de la Société Groupe Conseil WMI.

Dans ce blogue, je désire partager mes passions : l'entreprenariat et les technologies de l'information (TI, informatique). Bien sûr, j'ai d'autres passions, dont la minimécanique et les sports motorisés, et il se peut que j'en parle de temps à autre. Néanmoins, autant que possible, j'essaierai de me servir de ce blogue comme un journal d'apprentissage lié à ma carrière, et vous serez bien sûr invités, si vous le voulez, à émettre votre point de vue, faire part de vos opinions. Ensemble, nous pouvons grandir en échangeant sur des idées les plus intéressantes les unes des autres.

Dans mon domaine, je m'intéresse beaucoup aux méthodologies Agile. J'aime bien la facilité et la simplicité que l'agilité apporte dans l'industrie. Bien que les technologies de l'information ne soient pas gérées par aucun ordre, plusieurs certifications et organisations tentent de définir certains standards. Comme il s'agit d'un domaine assez jeune, et que ce dernier évolue très vite, il est parfois difficile de suivre les tendances. De plus, la majorité des publications sont en anglais. Alors je vais tenter, par la même occasion, d'offrir une fenêtre d'échange pour les professionnels francophones des TI.

De plus, j'invite également tous les dirigeants d'entreprises et toutes les personnes qui s'intéressent de près ou de loin aux TI à suivre mon blogue et à échanger dans le but de mieux comprendre certains aspects du développement logiciel, et en quoi ses pratiques peuvent aider votre organisation. Il est normal de ne pas tout comprendre, et je vais tenter, dans ce blogue, de démystifier tout cela en vulgarisant certains concepts. Et si vous avez des idées d'articles qui sauraient vous intéresser, ou des questions à poser, n'hésitez surtout pas à me contacter à l'aide du formulaire de ce blogue !

Dans ma prochaine publication, je me présenterai davantage en vous expliquant mon parcours, et ce qui m'a conduit à devenir entrepreneur en informatique.

 Merci de votre intérêt et au plaisir d'échanger avec vous très bientôt !