CGI fait l’acquisition de Facilité Informatique

CGI fait l’acquisition de Facilité Informatique, une firme de services conseils en TI, renforçant ainsi sa position de leader au sein du marché canadien

Montréal (Québec), le 16 mai 2018 – CGI (TSX : GIB.A) (NYSE : GIB) a annoncé aujourd’hui l’acquisition de Facilité Informatique, une firme de services-conseils en technologie de l’information (TI) ayant une solide présence locale à Montréal et à Québec. Grâce à ses pratiques établies en services numériques, Facilité Informatique permet à CGI d’accroître encore davantage son vaste éventail de capacités afin d’offrir à ses clients les solutions les mieux adaptées à leurs besoins.

Depuis plus de 25 ans, les experts de Facilité Informatique collaborent avec des clients issus de divers secteurs d’activité, y compris le transport et la logistique, les services publics, les services bancaires, les télécommunications, les gouvernements, l’assurance et le secteur manufacturier. Facilité Informatique détient également une vaste expertise en méthodologies agiles et en sécurité. Grâce à cette fusion, 350 nouveaux professionnels se joindront aux quelque 11 000 professionnels de CGI au Canada et aux 73 000 à l’échelle mondiale.

« Cette fusion renforce notre solide base de compétences à Montréal et à Québec. Elle nous permet notamment d’approfondir notre expertise dans les services-conseils en management et en technologie, qui aideront nos clients à réaliser la transformation numérique de leur organisation, a précisé Mark Boyajian, président des opérations canadiennes de CGI. Nous souhaitons chaleureusement la bienvenue à nos nouveaux collègues. Nous sommes également enthousiastes à l’idée de présenter notre portefeuille de services et solutions aux clients de Facilité Informatique. »

« Cette transaction est conforme à notre stratégie de croissance interne et par acquisition, a souligné George D. Schindler, président et chef de la direction de CGI. Les activités de CGI au Canada demeurent stratégiques et Facilité Informatique représente une autre étape importante de l’évolution du modèle de proximité client de CGI et renforce notre expertise ainsi que nos capacités. »

À propos de CGI

Fondée en 1976, CGI figure parmi les plus importantes entreprises indépendantes de services-conseils en technologie de l’information (TI) et en management au monde. Grâce à ses 73 000 professionnels établis partout dans le monde, CGI offre un portefeuille complet de services et de solutions : des services-conseils en TI et en management, des services d’intégration de systèmes et d’impartition ainsi que des solutions de propriété intellectuelle. La collaboration de CGI avec ses clients repose sur un modèle axé sur les relations locales, conjugué à un réseau mondial de prestation de services, qui permet aux clients de réaliser la transformation numérique de leur organisation et d’accélérer l’obtention de résultats. CGI génère des revenus annuels de 10,8 milliards de dollars canadiens. Les actions de CGI sont inscrites à la Bourse de Toronto (GIB.A) ainsi qu’à la Bourse de New York (GIB). Apprenez-en davantage sur cgi.com.

Lire la suite

L’entretien et l’évolution

Slack Facilité, 20 avril 2018:

« Hey gang! Petite question du vendredi: l’un de nos projets part en mode support v1/dev v2 avec 40 personnes au total et 6 max pouvant être dédiées au support v1. Dans vos expériences, qu’avez-vous mis en place en terme de répartition de l’équipe de support? On a déjà pensé à 5 équipes de dev (SCRUM) + 1 équipe de support et améliorations (KANBAN), 6 équipes (SCRUM) avec un membre de support dans chaque équipe ou une équipe de support qui tourne, d’autres idées? »

Mets-en que j’ai d’autres idées!

J’ai même d’autres questions. À quel moment dans notre histoire commune est venue l’idée de séparer l’entretien de l’évolution? Séparer le développement de nouvelles fonctionnalités du support de celles déjà livrées?

On s’entend que d’un point de vue Fordisme, cette division verticale du travail a beaucoup de sens. On peut même étendre ce raisonnement en amont, appliquer la même équation à la conception (architecture, design, analyse) et structurer le travail comme une bonne et belle chaîne de montage où chacun cogne sur son clou avant de passer le travail au suivant.

En ajoutant une belle matrice d’imputabilité, on peut même forcer chaque division à accomplir sa tâche, et uniquement sa tâche, de manière standard et mesurée.

Lire la suite

Planifications et estimations, pourquoi est-on en retard?

J’ai fait quelques petites lectures intéressantes dernièrement que j’aimerais bien partager avec vous. Je résume en fait une toute petite portion d’éléments provenant du cours en ligne « Agile Estimating & Planning » de Mike Cohn (Mountain Goat Software).

Indépendance des tâches

Il existe quelques raisons expliquant pourquoi les plans ne fonctionnent pas, notamment dans le domaine des technologies de l’information. La première est l’importance majeure qu’ont les dépendances entre les éléments du plan. Il est démontré que si chaque élément était TOTALEMENT indépendant des autres, alors les erreurs d’estimation (sur ou sous-évaluation) s’élimineraient entre elles et on aurait une distribution normale similaire à celle-ci :
DistributionNormale

Si c’était le cas, on pourrait alors avoir confiance aux estimés et aux plans.

Lire la suite

De retour du Lean Kanban North America – Seattle

Image uploaded from iOSNous sommes de retour du Lean Kanban North America 2018 (#LKNA18) et ce fut une expérience incroyable. La conférence permet un rassemblement d’experts et de passionnés de la méthode Kanban provenant des quatre coins du globe.

L’événement se veut un heureux mélange d’ateliers, de conférences d’émérites sur un grand nombre de sujets et de retours d’expériences. Nicolas Mercier et moi avons donc eu la chance d’être invités afin de présenter la vision du Centre d’Excellence Agile de Facilité sur la gestion de portefeuille en mode Kanban et faire un retour sur la transition de l’Agilité organisationnelle dans une agence gouvernementale.

Lire la suite

Le déploiement continu : la licorne du DevOps.

(English follows)

De nos jours, le terme DevOps est partout. C’est le petit nouveau, la nouvelle star, dans toutes les entreprises technologiques. Avec des concepts de bases qui sont des piliers avérés d’une bonne culture d’ingénierie (équipes pluridisciplinaires, systèmes à flux tiré, transfert de connaissances à l’échelle et hyper-collaboration), il ne s’agit pas d’une surprise que les principes derrière ce « buzzword » font énormément de sens lorsque votre marché niche est la livraison logicielle et que vous ne vivez pas dans l’âge de pierre.

J’aimerais tout d’abord partager mon opinion sur un aspect particulier de ce nouveau désir des entreprises à « adopter le DevOps ». Le sujet émerge souvent lors de discussions entourant le délai de mise en marché. C’est par contre ce que j’aime appeler un morceau de licorne.

Lire la suite

Cessez de jouer à Tetris avec votre temps

La surcharge est mère de tous les vices dans la philosophie Lean (Muri). C’est une plaie qui afflige la plupart des travailleurs intellectuels que je croise. La surcharge est tellement perverse que si vous en souffrez, vous ne vous en rendrez compte que trop tard. Voici quelques exemples de ce à quoi vous vous exposez:

  • Mauvaise prise de décision au quotidien;
  • Rater des dates limites;
  • Réduction globale de la productivité;
  • Augmentation de la charge mentale;
  • Fatigue professionnelle;
  • Aucun temps pour l’innovation;
  • Aucun temps pour l’apprentissage;
  • Aucun temps pour la collaboration (vous êtes un bloquant pour les autres);
  • Perte de motivation;
  • Attitude réactive et défensive, au lieu de proactive et constructive;
  • Sensation de perte de contrôle;
  • Perte d’efficacité dans vos communications (ex: envoi d’un courriel au lieu d’une conversation face à face, répondre sèchement par manque de temps, etc.)
  • Impossible de réagir efficacement aux imprévus/changements de plan;
  • Dégradation de votre santé mentale et physique;
  • Dégradation de vos relations professionnelles;
  • Être perçu comme quelqu’un de fermé et d’insensible aux priorités de ses collègues.

Lire la suite

Nous, c’est différent…

Pour le commun des mortels, changer n’est pas quelque chose de facile à faire, voire impossible. Il n’est pas facile de faire des changements personnels et il l’est encore moins de faire des changements organisationnels en groupe, c’est-à-dire dans nos équipes de travail. Cela est plus difficile, car le changement repose bien sûr sur plusieurs individus et celui-ci doit être accepté par tous.

Plusieurs facteurs peuvent influencer ceci dans les équipes ou les organisations. D’abord, il y a la peur d’échouer. Pour certains, changement rime avec angoisse et anxiété. Quoi de mieux que nos bonnes vieilles pantoufles pour nous rassurer et nous sécuriser!

Il y a également la culture de l’entreprise. Si l’entreprise n’encourage pas le changement ou ne le soutient pas, il sera difficile pour ses joueurs de prendre de nouvelles initiatives, des risques, d’être créatif et d’apporter de nouvelles idées pour innover. Non seulement ces initiatives risqueraient de ne pas être reconnues, mais les employés qui les ont élaborées pourraient même être blâmés pour celles-ci. Les joueurs dans ce type d’organisation généralement préfèrent le statu quo.

Lire la suite

Continuons d’évoluer, révisons notre utilisation des points de récits utilisateurs !

Relisez le guide Scrum. Il n’y a pas de notion de vélocité ou de points de récits utilisateurs. Ce fait, qui m’a été rappelé récemment par un collègue, m’a permis de réaliser les multiples biais injectés dans les fondamentaux Scrum et Agile pour répondre à des besoins de métriques.

Amusez-vous à lire cet article.

L’un des biais les plus flagrants est, pour ce billet, la notion de point pour un récit.

“Working software is the primary measure of progress.” – Manifeste Agile

Lire la suite

Prendre des décisions Agile et Lean

Au delà des méthodes et des pratiques, il y a les concepts de base. De nos jours, Agile et Lean sont devenus des buzzwords qu’on utilise à toutes les sauces. Pourtant, quand on creuse la question, on réalise souvent que notre interlocuteur n’a aucune compréhension de la philosophie derrière les mots.

Que se cache-t-il derrière ces grands concepts? Qu’est-ce qui distingue quelqu’un qui est Agile et Lean de quelqu’un qui ne l’est pas?

La réponse réside dans la façon dont les décisions sont prises. Pour déterminer si une méthode, une décision ou une pratique est Agile et Lean, on doit la peser selon un filtre décisionnel bien précis.

Lire la suite

Le parcours d’Eugénie dans son Agilité

Je vous présente Eugénie, chargée de projet depuis plusieurs années pour l’entreprise Complexe-cité. Sa direction, le bureau de projet et d’optimisation des processus (BPOP), relève de la vice-présidence stratégie et efficacité. Cette direction offre, entre autres, de l’accompagnement aux lignes d’affaires pour la réalisation de leurs projets, qui incluent souvent des solutions informatiques. Depuis bientôt deux ans, la vice-présidence des technologies de l’information a adopté l’approche Agile pour la plupart des réalisations des solutions informatiques. Bien qu’elle ait assisté à une formation de Scrum Master et quelques présentations sur l’approche Agile, Eugénie a encore de la difficulté à situer ses actions dans son référentiel de gestion de projet. Elle comprend le rôle du Scrum Master, mais le sien ne lui parait pas aussi clair, et sait encore moins comment s’y prendre avec le Scrum Master. Jusqu’ici, ses préoccupations ne lui avaient pas nui dans la prestation de ses services. Sauf qu’actuellement, elle travaille sur un projet stratégique pour l’organisation et le délai est très serré pour livrer la première version en production. Eugénie rencontre donc sa directrice pour lui faire part de ses préoccupations. Elle lui mentionne les points suivants :

  • « On me demande de faire une planification du projet, mais le focus des équipes est seulement sur la première livraison et le contenu peut changer plusieurs fois avant d’être fixé au début de l’itération. Cette situation amène plusieurs inconnus:
    • Qu’attend-on de moi au niveau de la planification?
    • Comment arrimer les différents contributeurs, affaires et TI?
    • Comment puis-je faire le suivi du projet de façon diligente?
    • Comment partager les responsabilités entre les Scrum Masters et moi comme chargé de projet?
    • On me dit que je peux assister aux mêlées quotidiennes de l’équipe, mais que je ne peux pas parler. Quelles sont les autres occasions dont je dispose pour m’adresser à l’équipe et leur partager des points qui me préoccupent sur leur progression?
    • Je dois préparer mes documents pour la reddition de compte et je ne sais pas trop ce que je dois présenter pour rendre visible la progression du projet. »

Lire la suite