2017 a été une année entièrement consacrée à travailler avec des équipes au sein de départements d’opérations TI. Rien de nouveau pour moi, étant donné que j’ai effectué mes premiers pas en tant que professionnel de l’informatique avec un groupe de soutien aux applications au Centre des opérations réseau (Network Operation CenterNOC) de cantv.net à Caracas, au Venezuela.

À l’époque, entre 2001 et 2004, je faisais partie d’une équipe dédiée au développement d’applications pour aider les spécialistes réseau à fournir un soutien et à maintenir le réseau client de Cantv opérationnel 24 heures sur 24 et 7 jours sur 7.

Nous étions responsables de tout ce qui concernait les applications soutenant les opérations du NOC d’un bout à l’autre (du besoin du client au soutien une fois en production) et lorsqu’un bogue survenait, nous étions là pour le résoudre.

Comment pouvons-nous éviter le changement de contexte?

À l’époque, les spécialistes réseau étaient ceux qui traitaient directement avec les clients, les systèmes et les problèmes liés au réseau. Les spécialistes des applications de soutien étaient chargés d’analyser et de développer des applications pour maintenir l’évolution des systèmes de soutien du NOC.

Critères de priorisation

Au sein de l’équipe des opérations, ils géraient le changement de contexte en priorisant les alertes et les incidents en fonction de leurs répercussions sur l’ensemble du réseau, le type de compte client (VIP ou non), la complexité de résolution du problème et les SLA (Service Level Agreement) et OLA (Operational Level Agreement).

Comment avons-nous maintenu la communication et la collaboration entre les deux groupes?

Nous étions physiquement très proches, donc il était facile d’obtenir les commentaires des spécialistes réseau assez rapidement durant le processus de développement. Ils agissaient en tant que principales parties prenantes de l’application de soutien. Nous avons donc maintenu la rétroaction dans les deux sens autant que possible afin de réduire les problèmes une fois en production.

Utilisions-nous des méthodes et des pratiques agiles?

Rôles et responsabilités

L’équipe des applications de soutien avait quelqu’un (le coordonnateur de l’équipe) qui recueillait les besoins du projet et nous (les développeurs) étions responsables de les clarifier et de les mettre en œuvre avec la plus haute qualité possible.

L’équip des spécialistes réseau avait un coordonnateur d’équipe (Service Owner) chargé de maintenir les services du NOC, faisant de son mieux pour garantir les accords de niveau de service (SLA) et de niveau opérationnel (OLA) signés avec les clients internes et externes.

Pratiques d’ingénierie

Nous avons utilisé la programmation en paires (Pair Programming), les révisions de code (Code Reviews) et de groupe (Gang Reviews) pour faire la démonstration de nouvelles fonctionnalités à nos clients (spécialistes réseau).

Tests

Nous avons testé les incréments en utilisant différents environnements (développement et production) mis à jour manuellement. Les spécialistes réseau prenaient part à des séances de Smoke Testing et au lancement des nouvelles fonctionnalités en production.

Carnet

Nous n’avions pas de carnet (backlog) commun pour toute l’équipe, chaque développeur avait le sien et le partageait avec ses clients et son coordonnateur d’équipe. Les deux coordonnateurs d’équipe, les équipes des applications de soutien et des spécialistes réseau se réunissaient souvent pour valider les améliorations et partager les besoins et les potentiels problèmes à résoudre.

Itérations

Nous ne minutions pas les itérations, mais nous avons négocié le travail en cours pour équilibrer notre capacité limitée. L’équipe de spécialistes réseau se réunissait régulièrement pour partager de l’information sur les incidents, les bogues et les corrections en cours.

Conclusion

Je pense donc que nous utilisions les pratiques Agiles à notre façon pour satisfaire nos clients, maintenir nos services aux niveaux convenus et collaborer afin de faire mieux.

C’est la fin de ma première histoire Agile dans les opérations TI, alors merci de l’avoir lue. Dans mon prochain billet, je vais vous partager une autre histoire d’Agilité dans les opérations dans un contexte de fournisseur d’infrastructure TI. Et s’il vous plaît, ne vous arrêtez pas ici et continuez à partager des histoires. Quelle est votre histoire Agile d’opérations TI?

Découvrez notre cours Opérations Agiles  conçu pour combler ce fossé dans le spectre de formation Agile-Lean.

Billet précédent

Besoin d’un Product Owner avec Kanban?

Billet suivant

Comment construire la capacité de votre équipe

Jesus Mendez

Je m'appelle Jesus Mendez et j'aide les gens à collaborer avec coeur. Je me considère comme un apprenant inspirant qui se nourrit des interactions des gens et est extrêmement passionné par le fait d'aider les leaders à survivre et prospérer. Je vous offre des outils et des techniques pour vous aider à inspirer les gens qui vous entourent en partageant ce que j'ai essayé et expérimenté. Je souhaite que nous puissions entrer en contact et créer un monde meilleur, une conversation à la fois!

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *