System Team – blog.erlem.fr https://blog.erlem.fr Agilité Sat, 19 Jan 2019 16:32:59 +0000 fr-FR hourly 1 https://wordpress.org/?v=6.0.4 System Team https://blog.erlem.fr/system-team/?utm_source=rss&utm_medium=rss&utm_campaign=system-team https://blog.erlem.fr/system-team/#respond Tue, 01 Jan 2019 15:10:16 +0000 https://blog.erlem.fr/?p=530

Le tout est plus grand que la somme de ses parties.

—Aristotle

La System Team est une Agile Team spécialisée qui aide à créer et à prendre en charge l’environnement de développement Agile, notamment le développement et la maintenance de la chaîne d’outils qui prend en charge le Continous Delivery Pipeline. La System Team peut également prendre en charge l’intégration des actifs des équipes agiles, effectuer des tests de solution de bout en bout si nécessaire et assister au déploiement et à la mise à jour à la demande.

Dans SAFe, les équipes agiles ne sont pas des unités autonomes. Au lieu de cela, ils font partie de l’Agile Release Train (ART), collectivement responsable de la création d’une valeur plus grande pour les systèmes et les solutions. Lors de la transition vers l’Agile, des travaux d’infrastructure supplémentaires sont généralement nécessaires pour intégrer les ressources de la solution plus fréquemment. Pour ce faire, une ou plusieurs équipes système spécialisées sont souvent formées. Ils aident à créer les environnements et à l’intégration des systèmes et des solutions. Ils aident également à démontrer la solution à mesure qu’elle évolue.

Une fois l’infrastructure arrivée à maturité, les System Teams sont parfois éliminées d’un ART, et les équipes de développement assument la responsabilité de la maintenance et de l’utilisation des systèmes. Dans les solutions plus vastes, il est plus probable que des spécialistes restent dans une ou plusieurs System Teams, la centralisation de certaines personnes, compétences et ressources techniques offrant la meilleure valeur économique.

Détails

La System Team assiste un ou plusieurs ART dans la création et l’utilisation de l’infrastructure d’environnement de développement Agile (y compris la chaîne d’outils du pipeline de distribution continue), l’intégration des actifs des équipes Agile et la réalisation de tests de solutions de bout en bout. Ils participent souvent à la System Demo à la fin de chaque Iteration et à la Solution Demo à la fin de chaque Programme Increment (PI), ou plus fréquemment, le cas échéant. Les démonstrations aident les équipes et les autres parties prenantes en fournissant des informations rapides sur l’aptitude à l’emploi et l’intégrité de la solution de bout en bout en évolution. Les System Teams peuvent également aider à la libération et à la coordination des Trains pour les Value Streams importants.

Cependant, la System Team et les Agile Teams partagent cette responsabilité. Sinon, l’équipe système deviendra un goulot d’étranglement et les Agile Teams ne seront pas entièrement capables de fournir des produits de valeur, ni de les rendre responsables.

Les System Team dans les Solution Train

Pour les value streams multi-ART nécessitant les constructions de la Solution Train, les System Teams sont particulièrement utiles pour prendre en charge les défis d’intégration à grande échelle. En fonction de l’étendue et de la complexité du flux de valeur, il existe trois modèles principaux pour structurer l’équipe système:

  • Une seule System Team par ART coordonne l’intégration et la validation de la solution sans aide supplémentaire.
  • Il existe une System Team uniquement pour le train de solutions, qui peut assumer ces responsabilités pour chacun de ses ART.
  • Il y a des System Teams pour les ART et le la Solution Train

La décision concernant le modèle à utiliser dépend du contexte spécifique du flux de valeur. Les facteurs incluent la structure de l’ART dans le flux de valeur (articulé autour de features ou de components), l’architecture de solution, les stratégies de branchement et d’intégration à travers l’ART, la testabilité du système et l’infrastructure de développement.

Responsabilités

Les principales responsabilités de la System Team sont la mise en place de l’infrastructure de développement, l’intégration de solutions, les tests de bout en bout, les démonstrations de systèmes et de solutions, ainsi que la publication. Ces responsabilités sont décrites dans les sections suivantes.

Construire l’environnement de développement

Une bonne infrastructure prend en charge une vitesse ART élevée, de sorte que l’équipe système peut:

  • Créer et gérer la chaîne d’outils du pipeline de distribution continue, y compris l’intégration continue, les constructions automatisées, les tests de vérification de construction automatisés et le déploiement automatisé
  • Créer des plateformes et des environnements pour les démonstrations de solutions et les tests d’acceptation des utilisateurs
  • Faciliter les aspects techniques de la collaboration avec des tiers, tels que les fournisseurs de données ou de services et les installations d’hébergement

Intégration de solution

Les solutions complexes nécessitent également que la System Team procède comme suit:

  • Participer aux PI Planning et aux Pre et Post-PI Planning au niveau de la Large Solution Level et au raffinement du backlog pour définir des éléments d’intégration et de test du backlog
  • Déterminer et aider à maintenir les décisions et les politiques pour les modèles de lignes réseau et de branchement appropriés
  • Exécuter des scripts d’intégration au niveau solution ou intégrer manuellement lorsque l’automatisation n’est pas encore possible
  • Assister aux réunions des autres équipes pour soutenir les activités quotidiennes

Test de bout en bout

La System Team peut également effectuer certaines tâches de test nécessaires aux équipes agiles:

  • Créer de nouveaux scénarios de test automatisés
  • Étendre les scénarios de test aux ensembles de données qui correspondent mieux à la production
  • Organiser des cas de test conçus par des équipes individuelles en suites ordonnées
  • Effectuer des tests manuels et exécuter des tests automatisés pour les nouvelles Features
  • Prioriser les tests fastidieux, refactoriser et exécuter des suites de tests réduites, le cas échéant
  • Aider les équipes à créer des suites de tests réduits qu’elles peuvent exécuter indépendamment
  • Tester les performances de la solution par rapport aux exigences non fonctionnelles (NFR) et aider l’ingénierie des solutions et des systèmes à identifier les défaillances et les goulots d’étranglement du système

System et Solution demos

Au moment opportun, à chaque itération, l’ART montre le système complet actuel aux parties prenantes participant aux démonstrations. De même, le train de solutions doit intégrer et montrer les progrès réalisés lors de la démonstration de la solution. La System Team participe généralement à la préparation des environnements techniques et leur permet de présenter de manière adéquate et fiable les nouvelles fonctionnalités de la solution.

Release

La System Team possède souvent des compétences et une expérience uniques liées à la solution en évolution. Il peut inclure du personnel d’assurance qualité et des opérations. Le System Architect/Engineer fait souvent partie de cette équipe. Ils ont vu la solution à travers plusieurs itérations, ce qui signifie qu’ils comprennent ce que c’est, ce que ça fait et à quel point cela répond à toutes les exigences prévues. Dans cette perspective, la System Team est susceptible de participer directement à l’appui du PI. Dans le cadre des activités DevOps et de Continuous Delivery Pipeline, ils feront le nécessaire pour aider ART ou Solution Train à préparer, mettre en package et déployer une solution dans l’environnement cible.

Équilibrer les efforts d’intégration et de test de la solution

La System Team, cependant, ne peut jamais être la solution complète au défi de l’outillage et de l’intégration du pipeline. Les équipes agiles doivent également avoir une vue d’ensemble de ce qu’elles créent. Sinon, même l’excellence locale des équipes Agiles ne donnera pas de bons résultats économiques. Le développement efficace de solutions nécessite le partage des meilleures pratiques. Par exemple, si seule l’équipe système teste les NFR et que des équipes individuelles ne réalisent pas de tests de performance, même légers, la vélocité de l’ART sera alors ralentie par la reprise nécessaire pour réussir ces tests de qualité critiques. De même, si les équipes Agiles n’intègrent pas en permanence, au minimum, les composants immédiats avec lesquels elles sont en interface, les efforts de l’équipe système seront un processus long et pénible. Comme le montre la figure 1, l’optimisation de la vitesse des ART nécessite un sens de l’équilibre entre les équipes agiles et les équipes système. Avec maturité et automatisation, le point optimal pour la responsabilité d’intégration se déplace vers la gauche.

Figure 1. Équilibre optimal des efforts d’intégration entre les Agile Teams et les System Teams


© Scaled Agile, Inc.

 

]]>
https://blog.erlem.fr/system-team/feed/ 0