Chapitre 11

Gestion et exploitation informatique

Dans ce chapitre :

Faciliter les migrations Big Data
Rationaliser le stockage
Augmenter la sécurité des données
Valoriser l’entreprise
Résoudre les défis organisationnels d’exploitation et de maintenance

« Toute technologie suffisamment avancée équivaut à de la magie. »

Sir Arthur C. Clarke

Dans le Chapitre 7, j’ai abordé Scrum dans l’industrie du logiciel. Vous avez pu lire plusieurs exemples de la puissance de Scrum dans ce domaine. Certaines personnes supposent que les technologies de l’information (TICE) et la création de logiciels sont des domaines très proches. Mais nous verrons que cette vision est erronée.

N.d.T. : dans la suite, nous utilisons le terme « informaticiens » pour désigner les personnes du service informatique des entreprises

Le développement de logiciels concerne la création de programmes qui fonctionnent sur des systèmes informatiques et des appareils numériques. Les technologies de l’information, elles, concernent les systèmes d’informations et de télécommunications nécessaires pour stocker, envoyer et récupérer des données numériques.

Chaque entreprise ne dispose pas d’un service de développement logiciel, mais il est rare de trouver une entreprise pouvant survivre sans une équipe de professionnels de l’informatique, des personnes chargées d’administrer et de superviser les moyens de traitement de l’information.

Toutefois, les opérations informatiques peuvent varier considérablement d’une organisation à une autre. Les rôles et responsabilités peuvent varier. Le type de travail à effectuer peut varier de jour en jour. De plus, ce domaine connaît des changements rapides, car la technologie évolue sans cesse, apportant toujours de nouvelles possibilités.

Comme pour tous les domaines en pleine croissance, les défis abondent. Les systèmes peuvent être saturés, les services interrompus, des traitements critiques ne doivent pas être interrompus sans entraîner un gaspillage de ressources, une perte de revenus ou de clients. La charge d’une équipe informatique peut grossir aussi vite que celle d’une équipe de développement.

Dans ce chapitre, j’aborde la gestion des moyens informatiques. Nous verrons comment Scrum fournit des solutions en termes de temps et de réduction des coûts pour ces défis contemporains.

Le Big Data et les migrations à grande échelle

Le volume des données est en croissance exponentielle. Alors que j’écris ces lignes, il est devenu difficile de quantifier combien de données sont manipulées par le Big Data.

Considérez ces quelques chiffres :

Walmart réalise 1 million de transactions par heure, ce qui alimente les bases de données avec plus de 2,5 pétaoctets (presque 200 fois la taille des données de tous les livres de la Bibliothèque du Congrès des États-Unis d’Amérique).
Facebook héberge plus de 40 milliards de photos.
eBay gère 50 pétaoctets d’informations chaque jour.
Pour décoder le génome humain, 3 milliards de paires de bases doivent être analysées. La première fois, il a fallu 10 ans ; maintenant cela ne prend plus qu’une semaine.

Cisco estime qu’en 2013, la quantité de trafic annuel a atteint 667 exaoctets.

Qu’est-ce qu’un exaoctet ? Un milliard de gigaoctets, ou 10 puissance 18 octets d’informations numériques. Voici quelques explications :

1 octet est l’équivalent d’un caractère numérique unique de texte (tel que la lettre a).
1 ko est un kilo-octet, soit environ 1 000 octets de données.
1 Mo est un mégaoctet ou 1 million d’octets.
1 Go est un gigaoctet, soit 1 milliard (10 puissance 9) d’octets.
1 To est un téraoctet, ou 1 000 milliards d’octets.
1 Po est un pétaoctet, donc un milliard de milliards d’octets.
1 Eo est un exaoctet soit 10 puissance 18) octets de données (ou environ 250 millions de DVD).

Le Big Data est un gigantesque volume de données dont un bon nombre, personnelles et sensibles, peuvent affecter notre vie et notre société.

Le défi consiste à rassembler, gérer et interpréter rapidement ces données de manière efficace et correcte. De plus, il faut prendre en considération les processus de stockage et de récupération pour pouvoir les réutiliser dans l’avenir. Ces données doivent devenir des renseignements utiles. Les anciennes façons de faire sont devenues insuffisantes ; le Big Data devrait croître de 800 % au cours des cinq prochaines années.

Un défi important est que 80 % de ces données sont non structurées (e-mails, blogs, feuilles de calcul, documents texte, images, vidéo, audio et résultats de recherches). Cette portion non structurée augmente plus vite que celle des données structurées (les bases de données). En d’autres termes, la majorité des données sont inutilisables telles quelles. Ce ne sont que des données, pas encore des informations.

La sécurité des données et la protection de la vie privée sont plus importantes que jamais ; en même temps, elles sont plus difficiles à assurer, car les environnements et les processus de gestion de données traditionnels sont incapables de traiter de tels volumes. La rapidité, la souplesse et une capacité de réaction instantanée sont nécessaires (je suis certain à présent que ces termes vous semblent familiers). Un délai de six mois est devenu trop long pour qu’un nouveau système non encore testé soit opérationnel. Durant cette période, il est probable que les besoins aient changé.

Pour faire face à ce tsunami de données, de nombreuses entreprises et organisations se tournent vers le cloud. Beaucoup ont même leurs propres nuages internes ou des environnements virtualisés. (Voir le Chapitre 7 pour plus de détails sur le cloud computing.)

La gestion de projet d’entrepôt de données

Les projets d’entrepôt de données sont traditionnellement considérés comme difficiles à gérer. Nous pouvons généralement délimiter les phases de début et de fin d’un projet, mais dans le cas d’un entrepôt de données, ce dernier n’est jamais fini, il change et ses besoins croissent sans cesse.

Un entrepôt de données n’est pas un bâtiment entouré de barbelés et cantonné à la périphérie de la ville. C’est un environnement informatique destiné au stockage et au traitement des données d’une entreprise ou d’une organisation.

Il s’agit d’une architecture basée sur la connaissance qui facilite les prises de décision stratégiques et tactiques.

Une complexité supplémentaire provient de l’activité continue de fusion et d’acquisition. Lorsque de nouveaux actifs ou sociétés sont achetés, leurs données et leurs processus doivent être pris en charge. Maintenir des applications héritées d’autres sociétés qui ne s’intègrent pas forcément au système existant peut s’avérer plus onéreux que de les convertir.

Un exemple de mise en œuvre réussie de Scrum est celui d’une société du secteur de l’énergie opérant entre les États-Unis et le Brésil. Les fréquentes fusions et acquisitions ont créé un besoin pour une intégration rapide et fiable des données. Les managers ont besoin de rapport sur les nouvelles entités ainsi que sur leurs produits et clients, et plus précisément sur le projet lié à l’efficacité énergétique, afin de garder une forte emprise sur ce segment de clientèle.

Toutefois, les données existaient dans de multiples formats à travers de multiples applications : sous forme de données budgétaires et financières dans des feuilles de calcul, d’outils de gestion de la relation client, et de données récupérées via une variété de sondages auprès des clients.

Les étapes du processus d’intégration de Scrum se sont faites comme suit :

Les rôles ont été établis :
- • Les utilisateurs finaux ont été identifiés comme parties prenantes.
- • Les intervenants et sponsors ont été identifiés comme le propriétaire du produit.
- • Le chef de projet est devenu le Scrum Master.
- • L’équipe de développement a été représentée par l’architecte de données, l’architecte système, et un architecte ETL (Extract Transform Load).
Les parties prenantes et le propriétaire du produit ont déterminé un point de départ le plus prioritaire : les données budgétaires.
Extraction, transformation et chargement (ETL) ont constitué le périmètre initial du projet. Lorsque les données sont devenues disponibles, le propriétaire du produit a travaillé avec les parties prenantes pour identifier les rapports qui pourraient être réalisés de manière incrémentale et les a ajoutés dans le backlog de produit pour les prioriser dans les sprints à venir.
Sprint 1 : les données du budget ont été chargées dans l’entrepôt de données. Les données ont été ensuite vérifiées en utilisant des exemples de rapports.
Sprint 2 : les données commerciales issues d’un logiciel CRM ont été chargées dans l’entrepôt. Des exemples de rapports ont également été utilisés pour valider les données.
À la suite du deuxième sprint, les parties prenantes ont identifié de nouvelles exigences dans les données budgétaires après les avoir comparées avec les données CRM chargées. Celles-ci ont été ajoutées au backlog et priorisées.
Sprint 3 : les données des enquêtes ont été chargées et validées avec des exemples de rapports.
À partir du troisième sprint, de nouvelles sources de données ont été découvertes et chargées pendant le sprint.
Sprint 4 : l’intégration des trois sources de données a été vérifiée avec des exemples de rapports.
Dans les sprints restants, les rapports ont été rédigés en fonction des priorités.

En seulement quelques mois, la migration de base de données a été entièrement terminée. L’entrepôt de données est entièrement fonctionnel, et un processus a été mis en place pour gérer les nouvelles données et leur modification. Une raison de la réussite de ce projet provient du fait que les équipes commerciales et de développement ont travaillé ensemble sur des objectifs communs.

ETL signifie Extraction (lire les données), Transformation (convertir les données) et chargement (écrire les données), ce qui correspond aux trois fonctions d’ingénierie de base de données utilisées pour extraire des données d’une base de données et les stocker dans une autre.

Le processus a également été plus rapidement opérationnel, car il n’a pas déclenché d’effet de cascade qu’aurait pu entraîner une approche consistant à charger d’abord toutes les données à partir de toutes les sources possibles puis à analyser le résultat. Au contraire, les données de plus haute importance ont été implémentées les premières puis analysées et adaptées au fil de l’eau. De nouvelles découvertes ont été incorporées dans les sprints suivants et les autres données extraites à leur tour selon leur priorité.

Les progiciels de gestion intégré (ERP)

La planification des ressources d’entreprise (ERP) est une suite d’applications intégrées que les sociétés utilisent pour collecter, gérer, interpréter et intégrer les processus métiers que sont la planification, les achats, la fabrication, l’inventaire, le marketing, les ventes, la distribution, la finance et les RH.

La mise en œuvre d’un système ERP consiste généralement à réaliser le développement simultané de différents domaines fonctionnels (marketing, ventes, stocks et achats) afin de pouvoir réaliser la totalité d’une transaction commerciale. La mise en œuvre implique la conception et la configuration simultanées de plusieurs modules. Ces modules, bien que réalisés individuellement, doivent également être conçus pour interopérer. Par exemple, lors de la conception du module de vente, les processus en amont et en aval doivent être étudiés minutieusement.

Pour illustrer cela, imaginez comment caractériser les ventes dans un processus de « bout-en-bout ». Vous commencez avec l’inventaire, mais vous devez être en mesure ensuite de facturer vos commandes. Par conséquent, le module de vente doit s’intégrer à la fois au module d’inventaire et à celui de trésorerie (et votre module d’inventaire avec celui de fabrication). De même, le module d’achat doit s’intégrer au module de trésorerie, et ainsi de suite).

Malheureusement, la conception et la réalisation de ces modules individuels prennent en général des années avant même que la phase de test intégrée ne commence. Durant ce délai, des écarts peuvent survenir, qui nécessiteront encore plus de temps à être identifiés et corrigés. Un petit écart entre les ventes et les finances peut entraîner des mois de travail supplémentaire. Et il est fréquent que ces « ajustements » ne s’intègrent pas parfaitement avec un autre des modules du processus. Dans un mode de travail « en silos », il n’est pas possible de détecter rapidement avant la phase de test ces écarts et incompatibilités. Traditionnellement, les fournisseurs d’ERP traitent cette interdépendance en verrouillant dans une séquence les développements spécifiques.

À présent, avec des équipes Scrum bien dimensionnées (voir le Chapitre 12), nous pouvons faire ces paramétrages en parallèle, chaque équipe Scrum se concentrant sur un domaine fonctionnel spécifique et utilisant des tests d’intégration automatisés pour s’assurer que les transactions de l’entreprise fonctionnent avec chacun des modules. Les techniques agiles permettent en effet de tester l’intégration et de produire des résultats tous les jours (dès le premier jour), par opposition aux mois d’allers/retours nécessaires dans un projet traditionnel.

Même si ces interdépendances modulaires paraissent être un handicap, elles simplifient en fait la décomposition du travail en différentes parties correspondant aux équipes Scrum qui travaillent sur des sprints synchronisés. La priorisation du carnet de commandes des produits est fixée au niveau du programme, et les demandes de modifications supplémentaires sont minimisées. Vous conservez ainsi la souplesse de Scrum, tout en accélérant considérablement le rythme de mise en œuvre. (Encore une fois, j’aborde ce modèle de découpage vertical au Chapitre 12.)

L’architecture des systèmes d’ERP s’oriente de plus en plus vers le modèle SaaS (Software as a Service, voir le Chapitre 7), ce qui signifie que les composants monolithiques deviennent plus modulaires que ceux proposés sous forme de programmes à installer chez les clients.

En outre, les tâches requises pour configurer les systèmes ERP sont généralement répétitives, la cadence et l’estimation peuvent donc être établies dès le début, afin de fournir une estimation précise du dimensionnement et des dates de synchronisation.

Dans le Chapitre 12, nous étudierons davantage le dimensionnement de Scrum avec plusieurs équipes afin de faire face aux problématiques de mise en œuvre simultanée de plusieurs projets ERP et d’en accélérer la livraison.

Une utilisation efficace de Scrum permettra à des équipes multiples de structurer leur définition de Terminé et d’inclure les problématiques d’intégration, de régression, de performance, de sécurité et de réaliser les tests de régression au moment du sprint plutôt qu’à celui de la livraison. Cela sera nécessaire en raison même de la nature des systèmes ERP qui rend très difficile la correction des conflits introduits au cours de la production.

Scrum fonctionne vraiment bien avec ces types de projets lorsqu’ils sont axés sur la réalisation d’outils de business intelligents pour l’organisation. Les implémentations de logiciels ERP s’étendant sur plusieurs années sont habituelles, mais les organisations ne peuvent plus attendre aussi longtemps. Elles ont besoin de solutions rapides et moins chères. Il est essentiel que les clients voient un retour sur investissement le plus rapidement possible, tout en améliorant la satisfaction de leur clientèle.

L’itération, l’inspection et l’adaptation à travers Scrum rendent cela possible.

Un de mes clients, une structure à but non lucratif, a pris récemment un projet de conversion massive de plusieurs systèmes existants dans un nouveau progiciel de gestion intégré (ERP). Jusqu’ici, cela aurait été un véritable cauchemar, quelque chose comme de vouloir faire rentrer des carrés dans des trous.

La feuille de route du client stipulait une durée de projet de 18 mois. La vision était une solution de bout en bout destinée à la gestion des actifs immobiliers mondiaux de l’entreprise. Les mesures définies étaient les suivantes :

Logistique. Une équipe dispose d’un espace ouvert organisé dans une salle de l’équipe Scrum, un mur entier est dédié à un tableau de tâches. Une autre équipe est disposée juste à côté, à portée de voix, pour faciliter la collaboration.
Avec l’aide des parties prenantes, le propriétaire du produit détermine le premier produit viable minimal (PPVM) – il s’agit de l’ensemble des processus les plus courants liés aux activités de crédit-bail. Les utilisateurs pourront en bénéficier tout de suite.
La livraison a été prévue, elle comprend quelques sprints dont le but est le nouveau PPVM. L’équipe commence à travailler.
Des développeurs ont été ajoutés à l’équipe, qui peut ainsi mettre en place des outils d’intégration sans avoir besoin de déléguer cette tâche à une équipe extérieure.
L’observation et le jumelage ont été utilisés immédiatement alors que le système était encore nouveau pour tout le monde. Le but était de mettre en place une transversalité des compétences aussi vite que possible.
A également été invité à plein temps un membre de l’équipe de déploiement traditionnel. Il était assis avec l’équipe de Scrum et a ainsi pu apprendre les étapes de configuration pendant les sprints. Au moment de déployer en production, tout s’est passé sans anicroche.
L’équipe s’est lancée dans l’intégration des nouvelles fonctionnalités de la feuille de route, tandis que ses clients ont apprécié les avantages des fonctionnalités récemment développées.

Beaucoup de choses furent apprises durant la réalisation de cette première livraison, ces connaissances ont été incorporées ensuite dans les livraisons suivantes (telles que la planification, la construction, l’exploitation et la maintenance) du nouveau système.

Grâce au processus Scrum, l’équipe a été en mesure de fournir rapidement des résultats, lui permettant ainsi d’aborder sereinement les demandes liées aux fonctionnalités prioritaires suivantes.

Service ou contrôle

La valeur d’un service informatique est stupéfiante. Il maintient le cours des informations à travers toute l’organisation. Les systèmes technologiques qu’il gère deviennent de plus en plus complexes, surtout si l’on y ajoute les ressources de cloud computing, et la tendance en hausse consistant pour les employés à apporter leurs propres appareils pour travailler (BYOD, Bring Your Own Device) ou leurs propres applications extérieures (BYOA).

Rappelons que le BYOD dans la technologie signifie apporter votre propre appareil, en se référant spécifiquement à l’utilisation des applications et des outils non disponibles en interne. BYOA signifie apporter votre propre application.

Trackvia a mené un sondage en ligne auprès de 1 000 employés et de 250 informaticiens. Il a trouvé que la tendance BYOD semble se généraliser. Voici certains de ses résultats :

46 % des cadres supérieurs informaticiens croient que l’utilisation des applications extérieures est à l’origine des fuites de données.
40 % des répondants estiment que leur entreprise n’a pas les ressources financières pour fournir les outils informatiques et les applications nécessaires.
76 % des informaticiens indiquent que leurs outils d’entreprise sont obsolètes et ne donnent pas à leurs clients ce dont ils ont besoin.
50 % des informaticiens pensent que les employés n’utilisent pas seulement les appareils et applications fournis par l’entreprise.

Si les employés n’ont pas le sentiment d’obtenir des informaticiens les outils dont ils ont besoin, il est naturel pour eux de chercher des solutions ailleurs, surtout lorsque ces solutions sont si facilement disponibles par le biais de SaaS et d’applications mobiles. Cette perte de contrôle devient une préoccupation importante pour les équipes informatiques lorsque des appareils et des applications non pris en charge créent des risques de sécurité ou interfèrent avec les solutions d’entreprise approuvées.

Le fait est qu’un équilibre doit être atteint entre fournir aux employés les outils dont ils ont besoin pour faire leur travail et assurer un maintien suffisant sur le contrôle et la sécurité. Considérez ce qui suit :

Les informaticiens ne peuvent pas contrôler les appareils personnels et les applications que les employés utilisent, mais ils peuvent contrôler l’accès aux données. Utilisez Scrum pour développer des applications qui accèdent aux données en toute sécurité. Le cadre de Scrum va affiner les caractéristiques de sorte que le PPPV soit rapidement identifié et mis en œuvre.
Ayez des membres informaticiens qui participent en tant que parties prenantes dans les revues de sprint des équipes Scrum. De cette façon, les informaticiens obtiennent une information de première main sur ce que les équipes de développement réalisent et sur les outils qu’elles utilisent. De plus, des questions peuvent être posées sur place, et les besoins peuvent être abordés d’une manière plus claire.
De même, invitez des représentants de départements aux revues de sprint des informaticiens afin d’obtenir leurs retours sur la feuille de route. Ils peuvent apprendre ce qui est important à l’organisation pour le développement des produits. De cette façon, les informaticiens peuvent s’aligner sur le commercial.

Scrum fournit la réactivité et le maintien d’une proximité avec le client permettant de réduire le recours à des outils externes. Traitez le problème et non le symptôme en donnant aux collaborateurs les outils dont ils ont besoin, quand ils en ont besoin. C’est ce que Scrum vous aide à faire.

Défis de sécurité

Vous avez probablement entendu certains de ces termes : chevaux de Troie, vers, maliciels, hameçonnage (phishing) et violation de la sécurité.

Pour certains, Internet est un superbe terrain de jeu pour développer des activités malveillantes. Les brèches de sécurité concernant les données font trop régulièrement les gros titres. Voici quelques exemples d’entreprises et d’organisations qui ont vu récemment des informations client compromises :

octobre 2014, JPMorgan Chase : 76 millions de personnes ;
septembre 2014, Google : 5 millions de personnes ;
septembre 2014, Home Depot : 56 millions de personnes ;
mai 2014, eBay : 145 millions de personnes ;
février 2014, Université du Maryland : 310 000 personnes ;
janvier 2014 KB Kookmin cartes, Lotte Card, Carte NH Nonghyup : 104 millions de personnes ;
décembre 2013, Target : 110 millions de personnes.

Et les dernières dépêches similaires :

Oregon Dept. Rapports et comptes-rendus ;
« Mayhem » Malware Shellshock ;
Kmart Says » brèche dans les cartes de paiements ;
Dairy Queen ;
Hackers Grab : 800 000 comptes bancaires.

Trop souvent, la sécurité est prise en compte une fois que le mal est fait. Elle est parfois considérée comme « souhaitable », mais que « nous traiterons quand elle deviendra un problème » plutôt que comme un problème très réel. Les risques de sécurité se multiplient et doivent être abordés au plus tôt. Cette section couvre certaines pratiques courantes sur la façon dont Scrum peut vous aider à définir les questions liées à la sécurité et à faciliter l’amélioration de leur mise en œuvre.

Affinez votre définition de « Terminé ». Tant au niveau de la livraison que du sprint, la définition de « Terminé » est essentielle. Définissez les exigences de sécurité qui doivent être respectées pour chaque timebox et qui devront être considérées comme réalisées. En ajoutant une tâche de sécurité à chaque demande sous forme de critère de votre définition de « Terminé », les coûts liés à l’atténuation des risques de sécurité peuvent être étalés sur la durée de vie du projet. Faites-en une priorité haute dès que possible.

En tant que membre de l’équipe Scrum (quel que soit le rôle), si la sécurité ne vous semble pas suffisamment prise en compte, faites-le savoir durant la prochaine rétrospective. Les parties prenantes commerciales et/ou le propriétaire du produit peuvent avoir besoin d’être formés sur ces questions. Identifiez les problèmes et placez-les dans le backlog de produit.

Faites en sorte que des membres de l’équipe informaticiens assistent à la revue du sprint pour fournir un retour sur la sécurité.

Envisagez la création d’une « guilde » de la sécurité au sein de l’organisation pour appeler tout le monde à la vigilance et favoriser le développement de compétences relatives à la sécurité.

Les guildes

Les guildes sont des groupes de personnes au sein d’une organisation qui partagent des connaissances communes, des outils et des pratiques. C’est une sorte de communauté de pratiques, où les gens se livrent régulièrement à un apprentissage collectif et au partage de connaissances. Des guildes peuvent se former autour de sujets tels que la sécurité, l’administration du système, les bases de données, la qualité ou encore Scrum.

Les guildes devraient être ouvertes à tous ceux qui souhaitent transmettre un savoir ou apprendre des autres, ce qui inclut aussi les débutants dans un domaine.
Les membres d’une guilde doivent se rencontrer fréquemment afin de renforcer les connaissances et augmenter les niveaux d’apprentissage et de compétences dans une organisation.

Essayez de faire en sorte qu’au moins une personne par équipe Scrum devienne membre de la guilde de sécurité. Il faut du temps avant que les pratiques de sécurité se répandent et que les équipes y soient toutes sensibilisées.

La retraite des baby-boomers

On estime qu’à partir de 2012, 10 000 baby-boomers partent à la retraite aux États-Unis chaque jour pendant les 15 à 20 années suivantes. Cela fait beaucoup de personnes, et un certain nombre d’entre elles sont des professionnels de l’informatique.

Les nouveaux employés qui les remplaceront sont d’une génération qui n’a pas le même état d’esprit. Chez eux, l’accomplissement personnel et l’ambition l’emportent sur la volonté de rester dans la même entreprise pendant toute une carrière. Cela signifie que les employés à long terme seront de moins en moins fréquents. Cependant, les pratiques agiles suivantes peuvent aider à conserver et développer les compétences de ces nouveaux employés :

Créer un programme de mentorat entre ceux sur le point de prendre leur retraite et leurs remplaçants. Cela augmente l’efficacité en matière de transfert de connaissances et augmente la fidélité et le sentiment d’appartenance à l’entreprise.
Donner aux nouveaux informaticiens des projets et des responsabilités en dehors de leur zone de confort. Donnez-leur une formation et de nouvelles choses à apprendre. Cela améliorera leur engagement sur le plan mental et émotionnel. Les guildes facilitent ce processus en fournissant des groupes d’experts dans chaque domaine. En outre, la collaboration des développeurs juniors et seniors augmente la compétence des deux parties.
Encourager les activités d’échange comme le jumelage et l’observation (voir Chapitre 4).

Ces activités peuvent également aider les employés ayant de l’ancienneté à améliorer leurs compétences. Les personnes déconnectées de l’organisation résistent parfois au changement et souhaitent juste passer tranquillement leurs dernières années avant la retraite. Les guildes offrent un moyen de puiser dans leur expertise et dans leur immense savoir. Maintenez ces employés en dehors de leur zone de confort en organisant des ateliers et envoyez-les en formation.

Les séances de déjeuner-causerie fournissent des occasions moins formelles à l’heure du déjeuner pour ceux qui ont des connaissances techniques spécifiques à partager avec d’autres membres de l’équipe de développement et permettent ainsi une transversalité entre les équipes. Si les guildes sont organisées autour de certains domaines de connaissances, tous les membres de l’équipe de développement qui sont intéressés devraient être invités à participer à ce type de séance.

Encouragez de nouvelles personnes à les rejoindre et donnez-leur les moyens d’y participer. Pour éviter que l’ennui n’incite les salariés à quitter l’entreprise, offrez-leur des défis, des opportunités de croissance et de reconnaissance.

Profits et pertes potentiels

Comme je l’ai mentionné précédemment, la valeur commerciale des informaticiens est immense. Elle doit être mise en avant et rappelée régulièrement au reste de l’organisation. Mais parfois, cette valeur est masquée par les problèmes associés à la technologie. Il y a un grand bénéfice à mettre en avant les services apportés par les informaticiens, ne serait-ce que de ceux liés à l’atténuation des risques.

La question clé à se poser est la suivante : « Est-ce que cette tâche ou cette activité améliore les priorités fondamentales de notre organisation ? ». Si oui, gardez-la et priorisez-la. Si non, essayez de vous en débarrasser afin de vous concentrer sur les tâches essentielles à la mission.

Accroître la visibilité de l’organisation (par le biais d’artéfacts tels que la priorisation du backlog des informaticiens et des incréments présentés lors des revues de sprint) donne un aperçu sur l’ensemble de l’organisation et sur la façon dont elle fonctionne pour éliminer les goulets d’étranglement liés à l’information et aux communications, ainsi que sur les outils qu’elle fournit pour améliorer la productivité. Lorsque l’ensemble de l’organisation comprend la valeur apportée par les informaticiens, la collaboration entre l’informatique et les autres départements s’accroît et les informaticiens sont identifiés comme des facilitateurs de la stratégie de l’entreprise.

L’efficacité énergétique est un sujet d’actualité, c’est aussi un bon exemple concernant la manière d’économiser durablement. Un large éventail d’outils est disponible pour vous aider à réduire les coûts en matière d’énergie. Grâce à une meilleure surveillance et à l’emploi de produits économes en énergie, vous pouvez économiser un petit pourcentage qui finira par apporter ses bénéfices.

IBM estime que les coûts énergétiques liés aux centres de traitement de données représentent jusqu’à 75 % des coûts d’exploitation et jusqu’à 60 % des dépenses en immobilisation d’une entreprise.

On estime qu’un centre de données de 2000 mètres carrés dépense plus de 3,5 millions d’euros en énergie électrique par an. Bien que ce nombre ne puisse pas être ramené à zéro, il peut être progressivement diminué, et un petit pourcentage d’une telle somme, ce n’est déjà pas si mal.

L’innovation par rapport à la stabilité

Les entreprises attendent des moyens informatiques de la stabilité, des performances et de la disponibilité. Mais elles doivent cependant toujours innover, ce qui implique de changer rapidement et souvent. La stabilité et le changement sont souvent antinomiques. Peut-on profiter des deux ?

Ce fossé se comble en resserrant la collaboration entre les équipes opérationnelles et les équipes de développement. Ainsi, les outils et les normes mis en place par les informaticiens serviront de support sur lequel les équipes de développement pourront s’appuyer.

Par exemple, lorsque les équipes de développement feront des changements dans leur code, elles pourront rester sereines en sachant que ces modifications sont effectuées dans le respect des normes convenues entre l’exploitation et le développement.

Les modifications dans la structure ou la conception d’une base de données faites dans le respect des normes opérationnelles permettent d’éviter les risques inhérents qui surviennent lorsqu’il n’y a pas de collaboration avec les opérations.

Ces normes sont intégrées dans la définition de « Terminé » de l’équipe. Les informaticiens sont ainsi assurées qu’à l’intérieur de chaque sprint, les équipes restent dans les limites définies d’une zone « bac à sable ». Lorsque des modifications doivent être effectuées, l’exploitation et le développement se consultent afin d’établir les nouvelles limites.

La nécessité d’améliorer la coordination est essentielle, en particulier pour le développement logiciel. C’est ici que le DevOps entre en jeu.

DevOps

DevOps signifie Développement et exploitation. Ce concept, également connu sous le nom « d’exploitation agile »), est une solution de plus utilisée pour pallier une lacune dans le développement d’applications logicielles. La Figure 11-1 montre un exemple de la façon dont DevOps aborde les défis de coordination décrits précédemment.

Développement et exploitation (DevOps) induit la collaboration et l’intégration entre les développeurs de logiciels et le service d’exploitation informatique. Grâce au processus de DevOps, les développeurs et l’exploitation peuvent travailler ensemble durant le cycle de vie complet de la création de produits.

Les tâches traditionnelles des informaticiens sont transférées aux membres de l’équipe DevOps. Cela permet non seulement d’alléger les tâches du service informatique, mais également de permettre aux équipes de développement associées à l’équipe de DevOps de prendre en charge leur développement jusqu’à la production, tout en diminuant les dépendances informatiques.

Les centres de données virtualisés facilitent de manière incroyable cette approche, car ils gèrent la plate-forme qui permet de créer de nouveaux environnements virtualisés avec les seules capacités d’un membre de l’équipe ayant des connaissances de DevOps.

Les compétences des informaticiens étant à présent disponibkes à l’intérieur de l’équipe Scrum, la vélocité et la qualité des sprints s’en trouvent améliorées.

Figure 11-1 : Représentation visuelle de DevOps illustrant un arbitrage entre les exigences de l’entreprise et la stabilité.

Maintenance

Une fois l’application déployée, les équipes de maintenance fournissent le support. Il peut s’agir de support technique, de correction de défauts ou de la mise en œuvre d’améliorations mineures afin de combler les lacunes de fonctionnalité lors de la production.

Lorsque les équipes Scrum sont concentrées sur la réalisation d’un projet, la prise en charge des problèmes liés au logiciel ou à l’exploitation s’avère contre-productive. L’avancement du projet et la maintenance sont des travaux très différents. Ils impliquent des types de tâches et des rythmes de travail distincts. Si une équipe Scrum est en charge de la maintenance et de l’exploitation, le développement des nouvelles fonctionnalités sera interrompu fréquemment, impactant le planning de livraison des nouvelles fonctionnalités qui doivent apporter de la valeur ajoutée au client. (Reportez-vous au Chapitre 12 pour en apprendre davantage sur le coût du retard pour une équipe de développement).

Figure 11-2 : Une pratique courante pour séparer la maintenance de l’équipe de développement du projet Scrum.

En séparant la maintenance des efforts de développement des équipes Scrum, cette maintenance peut être optimisée et les nouveaux développements peuvent avancer sans être ininterrompus. Je recommande une structure d’équipe de maintenance Scrum séparée pour ces fonctions afin de minimiser les interruptions sans augmenter les coûts (voir les Figures 11-2 et 11-3).

Figure 11-3 : Les membres de l’équipe sont mis en rotation entre les équipes à des intervalles raisonnables pour assurer la pollinisation croisée des connaissances et la transversalité des compétences.

J’ai introduit le concept de kanban basé sur des signes visuels pour gérer des tâches au Chapitre 6. Certaines équipes agiles et Scrum utilisent un tableau kanban pour visualiser leur flux de travail. Mais il ne faut pas confondre cela avec la méthode Kanban elle-même, liée aux méthodes en flux tendu de réalisation du système de production de Toyota. C’est devenu une autre approche du développement incrémental et empirique dédiée à la réalisation de logiciels et à d’autres industries liées à la fabrication. Kanban est basé sur plusieurs pratiques, dont la visualisation du workflow (tableau kanban), la limitation des travaux en cours (WIP), l’optimisation du flux, ce qui rend les processus explicites et améliore la collaboration. Alors que Scrum prescrit des rôles, des artéfacts et des événements, kanban laisse plus de latitude dans ces domaines.

Voici comment le processus des Figures 11-2 et 11-3 fonctionne :

Au début d’un nouveau cycle de production, vous sélectionnez un petit groupe dans l’équipe de développement, avec suffisamment de compétences et de connaissances pour maintenir efficacement le produit et vous en faites une équipe de maintenance.
Comme le montre la Figure 11-2, si vous avez une équipe de développement composée de neuf personnes, vous pouvez par exemple choisir trois développeurs et former avec eux une équipe de maintenance Scrum indépendante, ce qui laisse ainsi six développeurs disponibles pour réaliser le nouveau produit. La taille de votre équipe peut bien sûr varier.
Une équipe plus ou moins importante peut être nécessaire. (Rappelez-vous que même si l’équipe Scrum de développement est ensuite réduite, elle ne sera plus divisée entre les tâches de développement et de maintenance. Disposer de moins de gens ne signifie pas moins de livraisons. En fait, en étant plus concentrés, ils devraient être en mesure d’augmenter de manière significative la fréquence des livraisons du produit.)
L’équipe de maintenance exécute des sprints d’une journée ou utilise kanban pour répondre à l’évolution rapide des exigences (qui changent souvent tous les jours). Chaque matin, l’équipe sélectionne et planifie les priorités pour la journée. Elle exécute les travaux prévus, puis en fin de journée passe en revue ce qui a été accompli et autorise la diffusion (cette diffusion peut survenir à tout moment et n’a pas besoin d’être effectuée chaque jour).
Les équipes de maintenance peuvent être plus petites que les équipes de développement. Le propriétaire du produit et le Scrum Master de l’équipe de maintenance sont souvent les mêmes que ceux de l’équipe projet. La perte est minimale, voire inexistante, car il s’agit d’une seule application.
Pour chaque version réalisée par l’équipe projet (ou si votre équipe publie souvent, à des intervalles raisonnables de 90 jours par exemple), un membre de l’équipe projet transite vers l’équipe d’exploitation et devient un membre dédié à plein temps afin de fournir et de transmettre les connaissances nécessaires pour la livraison. Encore une fois, la perte est minimisée, car cela survient au moment de la livraison et que les membres de l’équipe continuent à travailler sur le même produit. Reportez-vous au Chapitre 14 pour en apprendre davantage sur la manière de minimiser les pertes et de maximiser la stabilité et la rentabilité.
À chaque nouvelle version, un membre de l’équipe de l’exploitation transite vers l’équipe projet en tant que membre à temps plein dédié de cette équipe.
Ainsi, tout le monde a finalement participé au développement et aux activités d’exploitation. Il n’y a plus de « Je suis dans l’équipe A » ou « Je suis l’équipe B ».
La pollinisation croisée des connaissances de ces domaines est un avantage clé.
Les fonctionnalités transverses se réalisent grâce à ces rotations.

Kanban au sein d’une structure Scrum

Les équipes de maintenance fonctionnent généralement sur des sprints quotidiens ou sur kanban plutôt que sur des cycles d’une semaine comme les équipes Scrum de projet.

Je recommande d’effectuer des sprints quotidiens plutôt qu’un kanban, car j’apprécie les étapes imposées par Scrum que sont la rétrospective et la revue de sprint. Toutefois, la méthode Kanban peut être efficace si elle s’intègre dans une structure Scrum.

La pratique de kanban pour visualiser le flux de travail correspond bien à l’esprit de Scrum. La limitation des travaux en cours que j’ai abordée dans les chapitres précédents permet également aux équipes de rester concentrées.

La gestion des flux et de l’estimation basée sur le délai (temps écoulé entre la demande et la livraison) et le temps de cycle (temps écoulé depuis le début des travaux jusqu’à la livraison) sont également utiles pour les équipes utilisant kanban. Les équipes Scrum trouveront ces données utiles lors de la planification et de leurs communications avec les parties prenantes, ainsi :

Le délai d’exécution correspond à la durée entre la réception d’une demande et la livraison de la tâche terminée.
Le temps de cycle correspond à la durée entre le moment où le travail a débuté et celui où il est livré.

(Par conséquent, le délai d’exécution est celui qui intéresse le plus la partie prenante)

Les équipes utilisant kanban sont également conscientes de la théorie des contraintes, ce qui signifie que le système formé par l’équipe est limité dans ses réalisations par un certain nombre de contraintes.

Avec Scrum, la vélocité est une contrainte que le Scrum Master essaie continuellement de réduire en recherchant des moyens et en fluidifiant l’organisation du travail.

Kanban est limité par son absence de mécanisme de rétroaction. Il est en effet très simple pour des équipes qui utilisent kanban d’éviter cette boucle de rétroaction tout en indiquant à leurs pairs et aux parties prenantes « Oui, nous avons du travail en cours, et nous faisons des progrès ». Bien sûr, leur tableau kanban est visible, mais sont-ils réellement efficaces et adaptent-ils leurs efforts à la fois sur le produit et le processus de production ? Scrum permet d’ajouter cette rétroaction.

Dans le contexte d’un sprint d’une journée, ne soyez pas préoccupé par la surcharge quotidienne des réunions. Un sprint d’une journée correspond au cinquième d’un sprint d’une semaine. Le temps utilisé par Scrum peut s’avérer incroyablement efficace, lisez ce qui suit :

La planification d’un sprint quoditien ne prend au maximum que 25 minutes. Assurez-vous d’impliquer les parties prenantes à l’origine de la demande afin de clarifier tout ce que l’équipe de développement aura besoin de comprendre pour effectuer sa réalisation.
La revue de sprint quotidienne ne doit pas prendre plus de 15 minutes.
La rétrospective quotidienne du sprint dure 10 minutes au maximum. Assurez-vous de son bon déroulement chaque jour, même si vous avez une urgence ou que tout le monde souhaite rentrer à la maison.
Faites également des rétrospectives au niveau macro, en synchronisation avec la rétrospective de sprint de l’équipe de développement, ce qui permettra une inspection à plus grande échelle.
Les mêlées quotidiennes ne sont pas nécessaires, car la planification du sprint dans la matinée va permettre la coordination et la synchronisation des priorités. Cependant, les obstacles devront être abordés à mesure qu’ils surviennent tout au long de la journée. Le Scrum Master doit être vigilant et assurer de manière proactive le suivi des obstacles connus ou potentiels.

La clé du succès d’un sprint d’une journée passe par le fractionnement des demandes afin que ces dernières puissent être réalisées en un seul jour. Cela demande de la pratique. Au début, nos équipes définissaient des tâches sur la semaine ; lorsqu’elles sont passées sur des sprints quotidiens, le nombre de corrections effectuées en fin de semaine a diminué. En outre, la satisfaction du client a augmenté, car ce dernier n’avait plus besoin d’attendre une semaine pour obtenir une modification. L’attente et la satisfaction sont des dynamiques opposées.