Étiquettes

, , ,

devops-barriers_1c41b571

Le plan de transition présenté, est rythmé selon un cadencement d’évolution aboutissant au mode DevOps au bout de 12 mois.

Une étape est lancée seulement lorsque l’étape précédente est franchie et stabilisée.

Le plan de travail repose sur la capacité à

  • mener de front plusieurs activités ;
  • orchestrer les changements aussi bien auprès des équipes métiers, qu’auprès des équipes techniques et que celles assurant les développements ;
  • garantir l’intégrité du fonctionnement du système d’information pendant la période de cohabitation des deux méthodes (cycle en V et AGILE);
  • assurer le fonctionnement en parallèle des développements traditionnels et du fonctionnement en mode AGILE.

La proposition de plan repose sur sept étapes principales : la première étant l’étape préparatoire.

Etape 1 – Etape préparatoire

Cette étape consiste à identifier l’ensemble des éléments et des acteurs qui vont être impactés par la mise en place de la nouvelle méthode de travail, afin de déterminer la trajectoire du changement pour chacun d’eux et préciser le planning de travail à respecter pour que chacun des composants soit au rendez-vous du démarrage des étapes futures.

En d’autres termes, la démarche consiste à établir un rétro planning à partir de chaque étape clé et lister tout ce qui est nécessaire pour que l’étape considérée puisse fonctionner.

Parmi les éléments de l’étape préparatoire, nous pouvons citer parmi les plus importants

  • la définition de la nouvelle organisation à la cible.

Le fonctionnement en mode AGILE et en DevOps implique des évolutions très structurantes par rapport aux fonctionnements existants et impose une refonte en profondeur de la répartition des rôles et responsabilités entre les équipes métiers, les équipes de développement et les équipes de production.

Un point majeur réside dans la mise en place de l’organisation des Product Owners ;

  • le mode AGILE repose sur le principe des Product Backlog.

Le(s) Product Backlog contient (nent) tous les sujets que les métiers veulent voir développer. Chacun de ces sujets est associé à deux notes : l’une représente la priorité qui lui est associée par le métier, l’autre est donnée par les équipes techniques et représente la complexité à développer.

Ce sont ces notes qui permettent de définir un ordre de préséance entre les différents sujets ;

  • l’organisation des locaux permettant la tenue des Daily Scrum, et la mise en œuvre des solutions de visio conférence ;
  • la mise en place du nouveau socle technique capable d’accueillir les nouveaux outils, les frameworks, les langages ;
  • le dimensionnement du réseau permettant l’échange des données entre les équipes ;
  • le Definition of Ready : liste et contenu des informations qui doivent être remises aux équipes SCRUM pour réaliser leurs développements ;
  • le Definition of Done : liste et contenu des livrables que les équipes de SCRUM s’engagent à remettre à l’issue de leurs périodes de sprint.

Etape 2 – Se lancer dans le bain du SCRUM – T0 à T + 10 semaines

L’étape consiste à se lancer en mode SCRUM avec 2 équipes, et de développer plusieurs sprints sur une période de 10 semaines.

L’objectif est de permettre de « roder » dans la « vie réelle » tous les éléments issus de la réflexion sur un périmètre réduit, limité aux développements, aux tests et à la fourniture de la documentation afférente

  • Technique : outils, framework, Plates-Formes, environnements ;
  • Fonctionnelle : Product Backlog, Sprint Backlog ;
  • Process : l’ensemble de l’approche AGILE, depuis la « definition of Ready » (DoR), jusqu’à la « Definition of Done » (DoD) ;
  • Organisation interne des équipes Front, Développement, et organisation des Product owners ;
  • La gestion des partenaires, des sous-traitants, et la validation des SLAs ainsi que les conventions de service ;
  • Comités et Reporting.

Le fait d’alimenter deux équipes en parallèle permet de vérifier les fonctionnements de coordination et de synchronisation des remontées d’information multi-équipes vers les Product Owners de référence et vérifier la pertinence de l’organisation.

Etape 3 – Industrialiser le mode Scrum – T+ 10 semaines à T + 4 mois

A l’issue des 10 semaines de l’étape 2, 2 semaines sont consacrées à établir les « lessons learnt » et à définir les fonctionnements qui présideront au démarrage en mode industriel.

L’industrialisation du mode SCRUM est effectuée durant 1 mois, sur la base des enseignements tirés, pour assurer un démarrage opérationnel de l’étape 4.

En parallèle toutes les tâches nécessaires pour que les équipes de Sprint puissent démarrer leurs activités en mode industriel sont effectuées

  • les équipes métiers, et MOA travaillent enrichissent le Product backlog et définissent les DoR ;
  • les environnements techniques sont alignés sur la base des lessons learnt ;
  • le Plan d’Assurance Qualité est rédigé avec la convention de services afférente.

Etape 4 – Stabiliser le mode SCRUM industriel – T + 4 mois à T + 6 mois

La stabilisation du mode AGILE industriel s’effectue durant deux mois.

En parallèle, de cette étape de stabilisation, les activités permettant de « containériser » les développements, sont poursuivies.

Etape 5 – Containeriser –  T + 6 mois à T + 8 mois

Cette étape cinq, a pour objet de simplifier le fonctionnement entre les « Développements » et l’entrée dans le monde de la Production.

Le principe consiste à définir plusieurs (pour répondre à différents cas de figure) environnements standards, qui permettent aux équipes de Sprint de « poser » leurs développements dans un environnement (Container) qui va être plugger de plates-formes en plates-formes, au fur et à mesure de l’avancement dans le cycle de fabrication, sans que le contenu ne soit impacté.

C’est le container qui change de Plate-forme, sans que son contenu n’évolue.

L’image correspond à celle d’un « légo » qui passe d’une construction à l’autre.

Cette étape peut démarrer au mois de mars 2016.

Etape 6 – Travailler en Design Thinking – T + 8 mois à T + 10 mois

L’objectif de cette étape six, est d’intégrer les développeurs directement dans les activités de création/conception et de modélisation menées dans l’approche Design Thinking.

L’idée consiste en amenant les développeurs au plus tôt dans la phase de conception d’une part de faciliter leur compréhension des besoins et d’autre part de permettre d’apporter dès cette phase les commentaires de nature technique.

Le but, en permettant une interaction directe entre les utilisateurs finaux (pas seulement le métier) et les équipes techniques, est d’ouvrir un dialogue qui aboutisse à une définition de besoin qui embarque dès le départ les contraintes techniques

Etape 7 – Instaurer le DevOps – T+ 10 mois

Lorsque les 6 étapes précédentes sont franchies, la « touche finale » consiste à fluidifier le passage du monde du développement au monde de la production en mettant en œuvre le fonctionnement DevOps.

Cette opération est la plus délicate à réaliser car elle impacte directement les process d’exploitation.

Publicités