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 !