La R&D de Polarion passe au DevOps

• Un produit complexe.
• La cadence de lancement est connue à l'avance et doit être respectée.
• Chaque version doit avoir des incréments fonctionnels et de qualité.
• (Suffisamment substantiel pour être utile à nos clients.)
• Une demande continue non seulement de changer ou d'adopter une nouvelle architecture, mais aussi de mettre à jour l'interface utilisateur. (Afin qu'il s'aligne sur d'autres produits Siemens et implémente les meilleures pratiques et composants d'interface utilisateur pour maximiser la convivialité.) Un groupe d'équipes Scrum intègre différents composants à la gamme de produits et doit continuellement être conscient des dépendances croisées.
• Tâches de maintenance inter-produits (améliorations, correction des défauts, améliorations des performances et de l'évolutivité) qui affectent généralement de nombreux domaines de l'application. Ils ne relèvent pas de la responsabilité d'une seule équipe et leur impact sur la base de code peut être considérable.
• Priorisations en constante évolution (projets nouveaux/financés, escalades de clients et changements d'estimation) qui peuvent entraîner une nouvelle priorisation des arriérés, etc.

A acquérir :

• Une infrastructure qui permet à plusieurs équipes de travailler en parallèle sans se déranger, notamment lors des phases d'intégration.
• Le système doit pouvoir suivre la progression de l'exécution de plusieurs sujets. (À des fins de création de rapports et de synchronisation.)
• Chaque fonctionnalité développée doit être soigneusement testée. (D'abord localement par l'équipe de développement, puis de nouveau après l'intégration. Cela garantit la stabilité générale de la version et élimine les éventuelles régressions.)
• L'intégration à plusieurs niveaux du code source doit toujours fournir une traçabilité entre les tâches/exigences et le code. (Active le processus de révision du code et garantit que toutes les modifications peuvent être auditées.)
• Une plateforme de collaboration utilisable pour que les équipes puissent se concerter efficacement, Support et Services. Cela devrait aider à faciliter :
• Fils de discussion avec un moyen facile de trouver des notes et des conclusions.
• Capable de demander et de recevoir une expertise spécifique de l'ensemble de la communauté.
• Assistance client sur site. (Pour nous, cela signifie généralement avoir un chef de produit et/ou un propriétaire de produit disponible en permanence pour des conseils ad hoc.)
• La possibilité de rendre compte des progrès en continu et sans trop de temps.

Besoins de l'entreprise  
Chaque bon produit est accompagné d'idées et de propositions innovantes sur la manière de répondre aux besoins existants ou prévus des clients. Ces idées proviennent de diverses sources. Des membres de l'équipe créative qui pensent à quelque chose de complètement nouveau, des équipes de vente qui collectent les données et les exigences des clients, ou des collègues de service qui savent comment améliorer les fonctionnalités existantes ou mettre en œuvre des solutions établies dans le monde réel. 

Les exigences opérationnelles sont généralement représentées par un ensemble de documents décrivant l'énoncé du problème et une proposition de ce qui doit être résolu. 

Ces exigences seront mises en œuvre dans notre environnement en suivant le cadre SAFe et en utilisant Scrum/Kanban au niveau de l'équipe. 

Le Scaled Agile Framework (SAFe) est une base de connaissances de principes, pratiques et compétences éprouvés et intégrés pour Lean, Agile et DevOps, permettant aux grandes entreprises d'idéaliser, de planifier et d'exécuter de grands projets qui peuvent avoir des dépendances, des contraintes commerciales et bientôt. 

Capacités
Une capacité est un comportement de solution de niveau supérieur qui s'étend généralement sur plusieurs Agile Release Trains (ART). Les capacités sont dimensionnées et divisées en de nombreuses fonctionnalités pour faciliter leur mise en œuvre dans un seul incrément de programme (PI). 

Une capacité typique dans notre contexte sera une partie importante de la fonctionnalité, par exemple, liée à un domaine particulier ou à un ensemble de services et de cadre couramment utilisé, ou à une nouvelle approche d'architecture. 

Les capacités sont regroupées en Epics pour permettre un niveau encore plus élevé d'agrégation et de planification stratégique. Un Epic est un conteneur pour une importante initiative de développement de solutions qui capture les investissements les plus importants au sein d'un portefeuille. En raison de leur portée et de leur impact considérables, les Epics nécessitent la définition d'un produit minimum viable (MVP) et l'approbation par le  Lean Portfolio Management (LPM ) avant la mise en œuvre. 

Les épopées et les capacités nécessitent généralement le plus d'attention de la part de la direction, de la gestion des produits et des responsables de développement. C'est là que le budget des équipes doit être aligné, les capacités correspondantes données, le plan d'exécution rédigé et les risques identifiés. Très souvent, les Capacités ne sont pas directement liées à un engagement client, mais elles servent de plate-forme pour la mise en œuvre de nombreuses Fonctionnalités décrites ci-dessous. 

Caractéristiques 
Une fonctionnalité est un service qui répond au besoin d'une partie prenante. Chaque fonctionnalité comprend une hypothèse de bénéfice et des critères d'acceptation. Une fonctionnalité est dimensionnée ou divisée selon les besoins afin qu'elle puisse être fournie par un seul ART dans un PI. 

Demande client ou demande d'amélioration (ER) 
Ces éléments sont enregistrés lorsqu'un client professionnel demande l'amélioration d'une fonctionnalité existante. En règle générale, il s'agit d'ajouts d'utilisabilité ou de fonctionnalités à ce qui a été livré prêt à l'emploi et qui devraient augmenter la productivité. Ces éléments sont classés par ordre de priorité par le support et la gestion des produits, puis ajoutés au backlog de développement. 

Élément du carnet de produit 
Un élément de backlog de produit est tout élément de notre processus qui doit être planifié dans un sprint. Les user stories, les défauts à l'échelle du produit et les correctifs sont tous des éléments du backlog du produit. Au départ, nous les appelions toutes des histoires d'utilisateurs, mais au fur et à mesure que notre processus évoluait, nous les avons divisées en catégories supplémentaires car différentes parties prenantes priorisent différentes choses. Par exemple, les défauts sont triés et classés par ordre de priorité par un comité. Une fois cette opération terminée, le Product Owner de l'équipe détermine une priorité de Sprint appropriée. Les correctifs, en revanche, sont décidés par la gestion des produits. Une fois décidé, la création et la distribution des correctifs aux clients incombent généralement à une équipe. (Cette équipe n'a peut-être pas été impliquée dans la correction des Défauts corrigés par le Patch.)   

Une User Story est l'élément Agile le plus largement utilisé pour capturer les besoins et les exigences. Son but est de capturer la conversation naturelle sur ce qui doit être intégré au produit du point de vue de l'utilisateur. Il doit initier et suivre la discussion entre celui qui veut la fonctionnalité et les développeurs chargés de la construire. Il est essentiel que les développeurs comprennent l'utilisation prévue de la fonctionnalité et créent la meilleure solution possible dans les limites architecturales et technologiques. Lorsque l'équipe de développement comprend pourquoi un utilisateur le veut et ce que l'utilisateur veut réaliser, elle peut proposer un ensemble de solutions possibles.

Tâche 
Une tâche est un travail qui amène la User Story vers sa mise en œuvre. Habituellement, plusieurs tâches sont créées pour une User Story afin d'identifier le degré d'implication d'une équipe qui est nécessaire et si d'autres parties (comme la documentation et l'UX) doivent être impliquées dans le Sprint. 

Test 
Outre la définition de terminé et les critères d'acceptation d'une user story, un ensemble de tests peut être défini pour fournir des preuves reproductibles qu'une fonctionnalité livrée fonctionne comme prévu. (Dans les contextes actuels et futurs potentiels.) De nombreux tests sont écrits en code (automatisation des tests) et ne nécessitent pas de création individuelle en tant qu'élément de travail pour une user story. Cependant, lorsque le test automatique est exécuté, l'objet correspondant est automatiquement créé et les résultats d'exécution sont suivis dans Polarion pour chaque test. 

Essai 
Ensemble de tests exécutés pour prouver qu'un domaine de produit sélectionné fonctionne correctement.