Essayez les nouveaux filtres d’activité des cartes pour Trello web !

Les nouveaux filtres vous montrent les cartes qui sont :

•Actives au cours de la dernière semaine

•Actives au cours des deux dernières semaines

•Actives au cours des quatre dernières semaines

•Aucune activité au cours des quatre dernières semaines

Source  : https://community.atlassian.com/t5/Trello-articles/A-new-way-to-filter-Trello-cards-saying-goodbye-to-the-Card/ba-p/2374997

Partager les pages de Confluence sur Slack

Vous avez peut-être interagi avec la fonctionnalité Confluence Share qui vous permet de partager du contenu avec d’autres via des notifications intégrées au produit. Vous avez peut-être également utilisé l’option Copier le lien pour générer une URL courte permettant de partager une page avec d’autres utilisateurs. La fonctionnalité Partager est désormais plus flexible que jamais, avec l’introduction de la fonctionnalité Partager dans Slack, qui vous permet de partager directement une page Confluence avec un utilisateur ou une chaîne dans Slack !

Source  : https://community.atlassian.com/t5/Confluence-articles/A-more-mindful-way-to-publish-is-coming-soon/ba-p/2384411

Changements dans la publication de Confluence

Pour que la publication se fasse de manière plus réfléchie, nous ajoutons une nouvelle boîte de dialogue de publication pour publier des projets pour la première fois et mettre à jour des pages existantes.

Source  : https://community.atlassian.com/t5/Confluence-articles/A-more-mindful-way-to-publish-is-coming-soon/ba-p/2384411

Amélioration de la recherche rapide dans Jira Software

1.Trouver rapidement les tickets grâce au filtre « reported by me ».

2.Voir les projets sur lesquels vous travaillez actuellement en haut des résultats de votre recherche

3.Trouvez ce que vous cherchez à l’aide d’une expression exacte

4.La requête intelligente va devenir optionnelle

5.Filtrer les résultats de la recherche en fonction de vos étiquettes

6.Lorsque vous survolez les résultats de recherche, une info-bulle apparaîtra avec plus d’informations sur le ticket.

7.À partir de bientôt, lorsque vous utiliserez la recherche rapide, un message « Vouliez-vous dire ? » s’affichera pour vous guider dans la recherche des termes et de l’orthographe corrects.

Source  : https://community.atlassian.com/t5/Jira-articles/Try-3-new-quick-search-improvements-in-Jira-Software-and-preview/ba-p/2387998

Créer des tickets Jira à partir de Confluence

Fini le temps où il fallait créer manuellement un ticket Jira Software à chaque fois que vous publiez une page dans Confluence !

Créer un nouveau ticket Jira Software directement à partir de Confluence Automation !

Créer un nouveau ticket Jira Software directement à partir de d’une Tâche Confluence à l’aide d’Automation !

Source  : https://community.atlassian.com/t5/Confluence-articles/Create-Jira-issues-directly-from-Confluence-with-the-latest/ba-p/2404119

Nouvelle navigation des espaces dans Confluence

1.Un tout nouvel onglet « Tout le contenu » : vous pouvez désormais rechercher et découvrir tout le contenu d’un espace en un seul endroit.

2.Mise à jour des sections (raccourcis, contenu, applications) – nous avons modifié l’ordre et rendu chaque section extensible afin que vous puissiez accéder rapidement au contenu et aux fonctionnalités qui vous intéressent.

3.Amélioration de l’accessibilité – nous avons ajouté des infobulles au survol pour tous les éléments de la barre de navigation latérale et mis à jour leurs états de sélection afin de mieux les distinguer.

4.Modernisation de l’apparence et de la convivialité – nous avons resserré la densité et l’espacement et mis à jour l’iconographie pour rendre l’expérience plus moderne.

Source  : https://community.atlassian.com/t5/Confluence-Cloud-Admins-articles/A-brand-new-space-navigation-experience-is-coming-to-Confluence/ba-p/2423193

Jira Work Management Premium

Débloquez la productivité à grande échelle sur Jira Work Management Premium.

Planifiez, livrez et rendez compte de votre travail à grande échelle avec des fonctionnalités Premium pour soutenir votre croissance.

Introduction d’un nouveau niveau de gestion du travail Jira : Premium, qui a été lancé le 17 juillet 2023.

Source  : https://www.atlassian.com/blog/jira-work-management/introducing-premium

Le thème sombre arrive au Data Center !

L’ajout d’un thème sombre vous permet de contrôler votre interface, de travailler dans la palette de couleurs de votre choix et d’aider un grand nombre de vos utilisateurs à mieux se concentrer sur leur écran. Ces mises à jour de l’expérience utilisateur permettent à chacun de travailler plus efficacement tout en réduisant les distractions visuelles.

Source  : https://community.atlassian.com/t5/Data-Center-articles/Dark-theme-is-coming-to-Data-Center/ba-p/2431400

Liens publics dans Confluence Cloud

Les liens publics vous permettent de partager une version d’une page en affichage limité avec toute personne sur Internet qui possède le lien public. (Remarque : les liens publics ne sont actuellement disponibles que pour un petit pourcentage de clients, mais nous espérons étendre cette fonctionnalité à tous nos clients payants dans le courant de l’année).

Source  : https://www.atlassian.com/blog/jira-work-management/introducing-premium

Jira Service Management Agent virtuel AI

Soutenu par Atlassian Intelligence, avec de puissantes capacités d’IA générative et un moteur de traitement du langage naturel de premier ordre, l’agent virtuel aide à fournir un support conversationnel rapide et automatisé via Slack (Microsoft Teams bientôt). Il analyse et comprend l’intention, le sentiment, le contexte et les informations de profil pour personnaliser l’assistance, et apprend de chaque interaction.

Qui y a accès ? L’agent virtuel (bêta) est actuellement disponible dans Slack pour tous les clients Jira Service Management Cloud Premium et Enterprise.

Source  : https://community.atlassian.com/t5/Jira-Service-Management-articles/Now-in-beta-Jira-Service-Management-AI-virtual-agent/ba-p/2462062

Amélioration de la recherche rapide

Vous pouvez accéder plus rapidement aux tickets récemment mise à jour. La dernière mise à jour signifie qu’une modification a été apportée au ticket. Voici quelques exemples :

•Le statut est passé de « à faire » à « en cours ».

•Un commentaire a été laissé sur la question

•La mise à jour d’un champ, par exemple l’ajout ou la suppression d’une étiquette.

Source  : https://community.atlassian.com/t5/Jira-articles/You-can-now-filter-by-last-updated-in-quick-search/ba-p/2466260

Nouvelles fonctionnalités pour Bitbucket Cloud

•Mise à l’échelle des flux de travail CI/CD : Importez les fichiers yml de Bitbucket Pipelines à travers les dépôts afin que tous les développeurs d’une équipe puissent utiliser le même flux de travail cohérent, en effectuant les mêmes étapes et les mêmes tests à travers le projet.

•Trouvez plus rapidement les commentaires non résolus : Lorsque vous avez plusieurs fichiers à examiner et de nombreux commentaires, il peut être difficile de trouver les commentaires qui nécessitent encore de l’attention. Nous avons ajouté une nouvelle liste déroulante dans la page de demande de retrait qui vous permet d’accéder aux commentaires non résolus ou de trouver des commentaires résolus spécifiques.

•Prise en charge des runners Linux ARM auto-hébergés : Si vous avez des builds qui nécessitent des runners ARM, vous pouvez maintenant faire pointer vos builds cloud utilisant Bitbucket Pipelines vers vos runners derrière le pare-feu.

•Vérifications de fusion au niveau du projet : Si vous avez un projet complexe avec de nombreux dépôts, vous pouvez maintenant appliquer un ensemble standard de vérifications à tous les dépôts d’un projet, ce qui facilite la gestion et le maintien d’un flux de travail cohérent.

Source  : https://community.atlassian.com/t5/Bitbucket-articles/Five-exciting-new-features-coming-to-Bitbucket-Cloud/ba-p/2475385

Nouveau modèle pour Jira Cloud Automation

Aujourd’hui, l’utilisation de l’automation est mesurée différemment selon les types de règles et les produits Atlassian. Actuellement, il n’y a qu’une seule limite commune pour tous les produits Jira Cloud.

Chaque fois qu’une règle d’automation s’exécute, elle est prise en compte dans cette limite, qu’elle ait réussi ou non. Le nouveau modèle d’emballage apporte une manière plus simple et plus cohérente de mesurer l’utilisation de l’automation. Chaque produit aura désormais un nombre fixe d’exécutions de règles mensuelles basé sur le plan.

Source  : https://community.atlassian.com/t5/Automation-articles/Introducing-our-new-packaging-model-for-Jira-Cloud-Automation/ba-p/2446099

Changements à venir dans le processus de sécurité des applications Data Center

Chez Atlassian, l’un de nos objectifs est de faire en sorte que nos clients puissent avoir confiance en la sécurité de nos logiciels. C’est pourquoi chaque produit DC d’Atlassian fait l’objet d’une analyse de sécurité des dépendances tierces pour détecter les vulnérabilités connues. Il est essentiel de remédier aux vulnérabilités dès que possible afin que nos clients puissent continuer à faire confiance à l’écosystème Atlassian. De cette manière, nous serons en mesure de détecter les problèmes potentiels suffisamment tôt pour réduire les risques pour nos clients.

Au fil des ans, nous avons vu évoluer les mécanismes utilisés par l’ingénierie d’Atlassian pour découvrir les failles de sécurité. Il existe des scanners de sécurité, le programme Bug Bounty 5, etc. Les clients s’appuient sur les logiciels d’Atlassian et nous confient leurs données tous les jours.

Les produits Atlassian Data Center font partie d’un écosystème florissant et la grande majorité des déploiements hébergent plusieurs applications Data Center. La sécurité d’une installation aussi complexe dépend de la sécurité de chacun de ses composants.

Source  : https://community.developer.atlassian.com/t/upcoming-changes-to-data-center-app-security-process/70096

2023 Gartner Magic Quadrant pour DevOps

Atlassian propose une plateforme DevOps unique et extensible qui connecte les équipes d’ingénierie, d’ITOps et d’entreprise pour accélérer la vélocité de l’ingénierie, améliorer la santé des applications, augmenter le temps de fonctionnement et la fiabilité, et livrer de la valeur plus rapidement.

Source  : https://www.atlassian.com/blog/devops/2023-gartner-mq-devops-atlassian

Mise à jour du Jira Work Management

1.Formulaires ouverts: Les formulaires ouverts sont en cours de déploiement ! Désormais, vous pourrez collecter les demandes d’admission de toute personne pouvant accéder à votre instance de gestion du travail Jira, et non plus seulement des utilisateurs ayant la permission de créer des tickets.

2.Intégration de Confluence dans la vue du tableau: Les pages Confluence en vue tableau sont également déployées dès maintenant et apportent le contexte dont vous avez besoin à une autre de vos vues préférées. Nous sommes impatients de voir comment vous allez tirer le meilleur parti de cette dernière intégration.

Source  : https://community.atlassian.com/t5/Jira-Work-Management-Articles/Let-the-July-updates-fly-New-University-course-open-forms/ba-p/2413981

Jira & ChatGPT – Tri des tickets avec l’IA

Dans cet article, même si vous n’êtes pas un développeur, vous apprendrez :

1.Pourquoi déléguer le tri à une IA ?

2.Exigences pour le tri automatique des tickets

3.Invitation à trier et à analyser le sentiment dans Jira

4.Comment intégrer Jira Service avec ChatGPT (étape par étape)

5.Coûts et économies générés

6.L’avenir du tri des tickets par l’IA

Accédez à l’article complet via ce lien !

Source  : https://medium.com/@feliperlucena/jira-chatgpt-triage-tickets-and-analyze-sentiments-with-ai-492ce7ead69d

L’article Newsletter Atlassian 3ième Trimestre 2023 est apparu en premier sur AZARA Consulting.

Scrum est un framework de gestion de projet Agile utilisé par les équipes de développement de logiciels pour collaborer. Il se base sur l’apprentissage par l’expérience, l’auto-organisation de l’équipe pour la résolution des problèmes, et la rétrospective périodique pour s’améliorer continuellement.

La méthodologie vient avec un ensemble de réunions, d’outils et de rôles qui interagissent de concert pour aider les équipes à structurer leur travail et à le gérer.

Dans cet article, nous verrons comment se compose le framework Scrum classique avec l’aide du Guide Scrum et comment ses concepts sont matérialisés sur Jira Software, l’outil Atlassian pour la gestion de projets.

Le framework

Scrum est un framework heuristique : il repose sur l’apprentissage continu et l’adaptation à des facteurs variables. Il se base sur le fait que l’équipe ne maîtrise pas tout au démarrage d’un projet et évoluera avec l’expérience. La méthodologie Scrum est structurée pour aider les équipes à s’adapter naturellement à l’évolution des conditions et des exigences des utilisateurs. La redéfinition des priorités et les cycles de livraison courts sont intégrés au processus pour permettre à votre équipe d’apprendre et de s’améliorer en permanence.

Même si Scrum est structuré, il n’est pas tout à fait rigide. Son exécution peut être adaptée aux besoins de n’importe quelle organisation. Cependant, afin de réussir sa mise en œuvre, la communication claire, la transparence et la volonté d’amélioration continue doivent rester les piliers de votre framework.

Artefacts Scrum

Les artefacts sont des outils créés pour résoudre un problème. Dans Scrum, ils sont au nombre de trois : le backlog produit, le backlog de sprint et l’incrément qui regroupe les tâches « terminées ».

• Le backlog produit est la liste principale des tâches à réaliser. Il est géré par le Product Owner ou le responsable produit. C’est une liste dynamique de fonctionnalités, d’exigences, d’améliorations et de correctifs qui fait office de point de départ pour le backlog de sprint. C’est la « to-do list » des équipes. Le backlog produit est constamment mis à jour, et ses priorités sont revues. Il est géré par le Product Owner qui le maintient en fonction de l’évolution du marché et du retour sur expérience de l’utilisateur.
• Le backlog de sprint est la liste d’éléments, d’user stories ou de correctifs de bug que l’équipe de développement a sélectionné en vue de leur implémentation dans le cycle de sprint actuel. Avant chaque sprint, une réunion de planification est organisée. Au cours de celle-ci, l’équipe choisit les éléments sur lesquels elle travaillera à partir du backlog produit. Un backlog de sprint peut être flexible et évoluer durant un sprint. Toutefois, l’objectif fondamental d’un sprint (ce que l’équipe souhaite atteindre à partir du sprint actuel) ne peut pas être remis en question.
• L’incrément (ou l’objectif de sprint) est le produit final exploitable qui a été obtenu pendant le sprint. L’« incrément » est présenté durant la démo de fin de sprint au cours de laquelle l’équipe montre ce qui a été effectué durant le sprint. Vous n’entendrez peut-être pas parler du terme « incrément », puisqu’il est souvent remplacé par la définition de « terminé » : une étape importante, l’objectif du sprint, voire une version complète de l’epic livré. Cela dépend de la façon dont les équipes définissent « terminé » et les objectifs de sprint. Par exemple, certaines équipes choisissent d’effectuer une livraison à leur client à la fin de chaque sprint. Pour elles, « terminé » signifie donc « livré ».Toutefois, cela peut ne pas être réalisable pour d’autres équipes. Par exemple, dans le cas où les livraisons client peuvent être opérées uniquement chaque trimestre. Les sprints sont de deux semaines, mais « terminé » est défini comme achever une portion d’une version plus large qui sera livrée par la suite. Il est utile de noter que plus vous avez besoin de temps pour livrer un logiciel, plus le risque qu’il puisse échoué est élevé.

Cérémonies Scrum

L’ensemble des cérémonies séquentielles que les équipes Scrum effectuent régulièrement constituent des composantes mieux connues du framework.

1. “Product Backlog refinement” : cet événement est sous la responsabilité du Product Owner. Ce dernier a deux tâches principales : faire de la vision du produit une réalité et rester constamment en ligne avec le marché et le client. Par conséquent, il tient à jour cette liste en s’appuyant sur le feedback des utilisateurs et de l’équipe de développement pour aider à définir des priorités et à maintenir un backlog propre et disponible à tout moment.
2. Planification du sprint : l’ensemble de l’équipe de développement planifie le travail à réaliser durant le sprint. Cette cérémonie est animée par le Scrum Master. À cette occasion, l’équipe détermine l’objectif du sprint. Les user stories sont ensuite ajoutées au sprint à partir du backlog produit. Ces stories correspondent toujours à l’objectif, et l’équipe Scrum s’accorde à dire qu’elles sont possibles à implémenter durant le sprint.À la fin de chaque réunion de planification, chaque membre de l’équipe Scrum doit savoir avec certitude ce qu’il est possible de livrer durant le sprint et comment réaliser l’incrément.
3. Sprint : un sprint désigne le délai défini par l’équipe Scrum pour terminer un incrément. Le délai classique d’un sprint est de deux semaines, mais il peut être d’une à quatre semaines. Ceci dit, plus le travail est complexe et plus les inconnues sont nombreuses, plus le sprint doit être court. Mais c’est à l’équipe de développement de voir. Le périmètre peut être renégocié entre le Product Owner et l’équipe de développement si nécessaire. C’est ce qui confère à la méthodologie Scrum sa nature empirique.Tous les événements, de la planification à la rétrospective, ont lieu durant le sprint. Dès lors que le délai du sprint est établi, il doit rester constant tout au long de la période de développement. L’équipe peut ainsi apprendre des expériences passées et appliquer ces enseignements aux sprints futurs.
4. Daily Scrum : mini-réunion quotidienne, rapide, de 15 minutes qui a lieu à la même heure le matin. L’objectif du « Daily Scrum » est de mettre tous les membres de l’équipe en phase avec l’objectif du sprint et de définir un plan pour les prochaines 24 heures.C’est l’occasion de faire part d’éventuelles préoccupations ou blocages concernant l’objectif du sprint.Le format de stand-up courant est de demander à chaque membre de l’équipe de répondre à trois questions sur la réalisation de l’objectif du sprint :• Qu’est-ce que j’ai fait hier ?
   • Qu’est-ce que je prévois de faire aujourd’hui ?
   • Y a-t-il des obstacles ?Le Daily Scrum a pour objectif de limiter les bavardages à une réunion quotidienne. L’équipe peut ensuite se concentrer sur son travail pendant le reste de la journée.
5. Revue de sprint : à la fin du sprint, l’équipe se rassemble afin d’effectuer une démo de l’incrément ou de l’inspecter. L’équipe de développement présente aux parties prenantes et à ses collègues les éléments du backlog terminés pour avoir leur avis. Le Product Owner peut décider de livrer ou non l’incrément.Cette revue est également l’occasion pour le Product Owner d’apporter des modifications au backlog produit sur la base du sprint actuel, lesquelles peuvent ensuite être intégrées à la session de planification du prochain sprint. Pour un sprint d’un mois, envisagez de « time-boxer » votre revue de sprint à un maximum de quatre heures.
6. Rétrospective de sprint : la rétrospective est l’occasion pour l’équipe de se rassembler afin de documenter ce qui a fonctionné ou non dans un sprint, un projet, des relations, des outils, chez des personnes, voire dans certaines cérémonies et d’en discuter. L’idée est de créer un espace dans lequel l’équipe peut se concentrer sur ce qui a bien fonctionné et sur les choses à améliorer.

Trois rôles essentiels pour la réussite de Scrum

Une équipe Scrum doit rassembler trois rôles : le Product Owner, le Scrum Master et l’équipe de développement. Et, comme les équipes Scrum sont pluridisciplinaires, l’équipe de développement comprend des testeurs, des concepteurs, des spécialistes de l’expérience utilisateur et des ingénieurs opérationnels, en plus des développeurs.

Le Product Owner Scrum

La priorité du Product Owner est de comprendre les exigences du business, des clients et du marché, puis de prioriser le travail de l’équipe d’ingénierie en conséquence. Le Product Owner efficace :

• crée et gère le backlog produit ;
• travaille en étroite collaboration avec le business et l’équipe pour s’assurer que tous savent en quoi consistent les tâches du backlog produit ;
• fournit à l’équipe des orientations claires sur les prochaines fonctionnalités à livrer ;
• décide du moment où le produit doit être livré, avec une prédisposition pour des livraisons plus fréquentes.

Le Product Owner fait en sorte que l’équipe de développement offre un maximum de valeur ajoutée au business. Il est également important que le Product Owner soit une seule personne. Aucune équipe de développement ne se réjouira de recevoir des directives différentes de plusieurs Product Owners.

Le Scrum Master

Les Scrum Masters sont les champions de Scrum au sein de leur équipe. Ils coachent l’équipe, les Product Owners et le business sur le processus Scrum et cherchent les façons d’affiner leur pratique en la matière.

Un Scrum Master efficace comprend parfaitement le travail que l’équipe doit réaliser et peut aider celle-ci à optimiser la transparence et le flux de livraison. En tant que chef d’orchestre, il prévoit les ressources nécessaires (humaines et logistiques) pour planifier le sprint, le stand-up, la revue et la rétrospective de sprint.

L’équipe de développement Scrum

Les équipes Scrum abattent le travail. Elles sont les championnes des pratiques de développement durables. Elles comptent généralement entre cinq et sept membres. Une façon de déterminer la taille de l’équipe consiste à suivre la règle des « deux pizzas » du PDG d’Amazon, Jeff Bezos : deux pizzas doivent suffire pour nourrir l’équipe.

Les membres de l’équipe présentent des compétences variées. Ils se forment les uns les autres afin qu’aucun ne devienne un goulot d’étranglement dans la livraison du travail. Les équipes Scrum efficaces s’organisent de façon autonome et adoptent une attitude du « nous » dans leur approche des projets. Les membres de l’équipe s’entraident tous afin de garantir la réussite du sprint.

L’équipe Scrum détermine le plan pour chaque sprint. Elle prévoit la quantité de travail qu’elle pense pouvoir assumer tout au long de l’itération en se servant de sa vélocité comme guide. En gardant une longueur d’itération fixe, l’équipe de développement bénéficie d’un feedback important sur son processus d’estimation et de livraison. Avec le temps, ses prévisions deviennent donc de plus en plus précises.

Scrum, Kanban et Agile

Scrum est un framework Agile si populaire que ces deux méthodologies sont souvent confondues l’une avec l’autre. Il existe toutefois d’autres frameworks, comme Kanban, qui est une alternative populaire. Certaines entreprises choisissent même de suivre un modèle hybride de Scrum et Kanban, appelé « Scrumban » ou Kanplan.

Scrum et Kanban utilisent tous deux des méthodes visuelles, comme le tableau Scrum ou Kanban, pour suivre l’avancement du travail. Tous deux donnent la priorité à l’efficacité et à la subdivision de tâches complexes en plus petits blocs gérables. Leur approche pour réaliser cet objectif diffère toutefois.

Scrum se concentre sur des itérations à durée limitée. Une fois la durée d’un sprint finalisée, les stories ou les entrées du backlog produit qui peuvent être implémentées durant ce cycle de sprint sont déterminées. Dans Kanban, le nombre de tâches ou la quantité de travail en cours (limite Work In Progress) à implémenter au cours du cycle actuel est fixé(e) au préalable. Le temps nécessaire pour implémenter ces fonctionnalités est ensuite calculé en remontant dans le temps.

Kanban n’est pas aussi structuré que Scrum. Hormis la limite Work In Progress, cette méthodologie est relativement ouverte à l’interprétation. Scrum intègre toutefois plusieurs concepts catégoriques dans le cadre de son implémentation, comme la revue de sprint, la rétrospective, la mêlée quotidienne (Daily Scrum), et bien d’autres. La méthodologie insiste également sur la transversalité, c’est-à-dire la capacité d’une équipe Scrum à ne pas dépendre de membres externes pour atteindre ses objectifs. Il n’est pas toujours simple de former une équipe transverse. En ce sens, Kanban est plus facile à adapter, alors que Scrum peut être considéré comme un virage fondamental dans le processus de réflexion et dans le fonctionnement d’une équipe de développement.

Mais, pourquoi Scrum ?

Le framework Scrum en lui-même est simple. Les règles, artefacts, événements et rôles sont faciles à comprendre. Son approche semi-normative aide véritablement à lever les ambiguïtés du processus de développement, tout en offrant aux entreprises la liberté suffisante pour ajouter leur propre touche.

L’organisation de tâches complexes en user stories gérables en fait la méthodologie idéale pour les projets complexes. Par ailleurs, la démarcation claire des rôles et les événements planifiés garantissent la transparence et la responsabilité collective tout au long du cycle de développement. Les livraisons rapides maintiennent la motivation de l’équipe et la satisfaction des utilisateurs à un niveau élevé, car il est possible de voir l’avancement dans un bref laps de temps.

Toutefois, la parfaite compréhension de Scrum peut prendre un certain temps, en particulier si l’équipe de développement est habituée à un modèle en cascade classique. Les concepts d’itérations plus restreintes, de mêlées quotidiennes (Daily Scrum), de revues de sprint et l’identification d’un Scrum Master pourraient s’avérer un virage culturel difficile à prendre pour une nouvelle équipe.

Toutefois, les avantages à long terme prévalent nettement sur la courbe d’apprentissage initiale. Le succès de Scrum dans le développement de produits logiciels complexes, quels que soient le secteur et le marché, en fait un framework attrayant à adopter pour votre organisation.

Si vous envisagez de mettre en place la méthode SCRUM, n’hésitez pas à nous contacter. Nos équipes constitués de consultants certifiés SCRUM et Atlassian ont à leurs actifs plusieurs projets mis en place avec succès et seront ravis de partager avec vous leurs retours d’expériences.

L’article Fonctionnent de la méthode Scrum est apparu en premier sur AZARA Consulting.

SAFe définit le cadre pour l’alignement, la collaboration et le delivery entre un grand nombre d’équipes agiles. Il s’articule autour de trois principaux blocs de connaissances : le développement logiciel agile, le développement de produits lean et la pensée systémique.

À mesure que les entreprises grandissent, SAFe apporte une approche structurée pour le scaling agile. Quatre configurations sont proposées en fonction du niveau de scale souhaité : Essential SAFe, Large Solution SAFe, Portfolio SAFe et Full SAFe.

Dean Leffingwell et Drew Jemilo ont lancé SAFe en 2011 pour aider les organisations à concevoir de meilleurs systèmes et logiciels qui répondent mieux aux besoins changeants des clients. À cette époque, les équipes utilisaient des processus de gestion de projet classiques pour livrer des logiciels. Mais à mesure que la nécessité de répondre rapidement aux conditions évolutives du marché augmentait, de nouvelles méthodologies ont émergé pour aider les entreprises à améliorer la livraison de solutions dans leurs entreprises : SAFe a vu le jour. Aujourd’hui, SAFe est l’une des méthodologies agile à l’échelle les plus utilisées, et la communauté mondiale de praticiens de SAFe continue de le faire évoluer.

Les principes et les valeurs fondamentaux

Valeurs fondamentales

Les valeurs fondamentales de SAFe décrivent la culture que le leadership doit favoriser pour réussir la mise en œuvre de la méthodologie.

Alignement

L’une des exigences de SAFe est la mise en place des cadences de planification et de réflexion à tous les niveaux de l’organisation. Une fois en place, tous les collaborateurs ont une idée claire sur l’état actuel de l’entreprise, les objectifs et le rôle de chacun pour atteindre ces objectifs. En synchronisant régulièrement les personnes et les activités, tous les niveaux du portefeuille restent alignés. Les informations circulent à la fois vers le haut et vers le bas en temps opportun, contrairement aux structures traditionnelles top down.

Qualité intégrée

Dans le cadre de la démarche SAFe, l’agilité ne doit jamais se faire au détriment de la qualité. SAFe exige des équipes à tous les niveaux qu’elles définissent ce que « done» signifie pour chaque tâche ou projet et qu’elles intègrent des pratiques de développement de qualité dans chaque contrat de travail. Selon SAFe, il existe cinq dimensions clés de la qualité intégrée : le flux, la qualité de l’architecture et de la conception, la qualité du code, la qualité du système et la qualité des livraisons.

Transparence

SAFe encourage la mise en place d’un climat de confiance et de transparence, notamment en planifiant le travail en petits lots afin que les problèmes puissent être identifiés plus tôt, offrant une visibilité en temps réel sur l’avancement de la backlog à tous les niveaux, ainsi que les rituels d’inspection et d’adaptation.

Exécution du programme

L’exécution du programme est au cœur de SAFe et soutient tous les autres aspects du framework. Les équipes et les programmes doivent pouvoir fournir régulièrement un service de qualité, des logiciels opérationnels et une valeur business.

Direction

SAFe requiert un comportement de leadership Lean/Agile, car seuls les leaders peuvent transformer le système et mettre en place l’environnement nécessaire pour inculquer toutes les valeurs fondamentales.

Principes SAFe

Les principes SAFe sont destinés à améliorer l’entreprise dans son ensemble en éclairant la prise de décision Lean/Agile au-delà des limites fonctionnelles et organisationnelles. Les principes visent à influencer non seulement les décisions des dirigeants et des responsables, mais aussi celles de tous les membres de l’organisation, et à les encourager à passer d’une pensée classique en waterfall à une pensée Lean/Agile, qui applique des pratiques telles que la gestion de portefeuilles Lean.

Principe n° 1 : Adopter une vision économique

D’après les théories sur le flux de développement produit tirées des best-sellers de Donald Reinertsen, chaque intervenant dans la chaîne de décision doit comprendre les implications économiques des retards pour obtenir le délai d’exécution le plus court possible. Il ne suffit pas toujours de livrer tôt et régulièrement. Selon SAFe, classer les tâches pour optimiser les bénéfices, comprendre les échanges économiques et travailler en respectant des budgets serrés sont autant de responsabilités qui doivent être communiquées à l’échelle de l’organisation. De nombreux concepts et outils sont tirés des théories de Donald Reinertsen sur le flux de développement produit.

Principe n° 2 : Appliquer une pensée systémique

SAFe encourage les personnes qui utilisent le framework à appliquer une pensée systémique sur trois axes clés : la solution elle-même, l’entreprise qui développe le système et les flux de valeur. Les solutions peuvent concerner des produits, des services ou des systèmes fournis au client, qu’ils soient internes ou externes à l’entreprise.

Les solutions d’envergure comportent de nombreux composants interconnectés. Les membres de l’équipe doivent avoir une vision d’ensemble pour savoir comment leur élément s’intègre dans la solution.

Les adeptes de SAFe doivent prendre en considération l’ensemble des acteurs de la chaine de réalisation de la solution, du système de management et des processus de réalisation. Ainsi, si une organisation cherche à optimiser les méthodes de travail, elle devra peut-être éliminer les silos, devenir transverse, et conclure de nouveaux accords de coopération avec les fournisseurs et les clients. Finalement, l’entreprise doit clairement expliquer comment la valeur passe du concept au financement dans les flux de valeur de développement de solutions. Les dirigeants et la direction doivent optimiser le flux de valeur au-delà des limites fonctionnelles et organisationnelles.

Principe n° 3 : Supposer la variabilité, conserver les options

Par défaut, la conception de systèmes et de logiciels est un exercice incertain. Ce principe répond à cette incertitude en introduisant le concept de « Set-Based Design » (design basé sur un ensemble), qui implique de garder plusieurs exigences et options de design pendant une période prolongée dans le cycle de développement. Le « Set-Based Design » s’appuie également sur des données empiriques afin de se focaliser sur la dernière option de design dans la suite du processus.

Le « Set-Based Design » aide à prendre des décisions éclairées en période d’incertitude en identifiant les options et les résultats escomptés, sur le même principe qu’un choix stratégique. Le concept visant à intégrer des « étapes importantes d’apprentissage » (qui font référence à la date limite pour prendre des décisions) joue un rôle clé dans le « Set-Based Design ». Plus les équipes apprennent au fil du temps, plus elles peuvent éliminer de choix. Plus elles éliminent de choix, plus il est facile d’identifier la meilleure voie à suivre et de produire le meilleur résultat possible pour les clients.

Principe n° 4 : Se développer de manière itérative à l’aide de cycles d’apprentissage rapides et intégrés

À l’instar du principe n° 3, ce principe aborde le risque et l’incertitude par le biais d’étapes importantes d’apprentissage. Il ne suffit pas que chaque composant du système soit fonctionnel, il faut tenir compte de l’ensemble du système pour évaluer la faisabilité des choix de design actuels. Les points d’intégration doivent être planifiés à intervalles réguliers, afin d’accélérer les cycles d’apprentissage. Ces points d’intégration constituent un parfait exemple du cycle PDCA (plan-do-check-adjust) de Walter A. Shewhart, un framework pour l’amélioration continue de la qualité et un mécanisme pour contrôler la variabilité du développement. Les travaux de Walter Shewart et ceux qu’il a inspirés se concentrent souvent sur SAFe.

Principe n° 5 : Baser les étapes importantes sur une évaluation objective des systèmes de travail

La démonstration d’un véritable système de travail constitue une meilleure base pour la prise de décision qu’un document d’exigences ou toute autre évaluation superficielle de la réussite. Inclure dès le départ les parties prenantes dans ces décisions de faisabilité permet de renforcer la confiance et encourage une pensée systémique.

Principe n° 6 : Visualiser et limiter le travail en cours (Work in Process, WIP), réduire la taille des lots et gérer la longueur des files d’attente

Limiter le travail en cours aide les parties prenantes à évaluer avec précision le déroulement des opérations.

Les trois éléments de ce principe représentent les principaux moyens d’optimiser le débit et d’accélérer la création de valeur ou, en d’autres termes, d’implémenter le « flux ». Comme le dit l’adage « Ne mettons pas la charrue avant les bœufs ».

En appliquant ce principe au développement logiciel, vous limitez le nombre de tâches se chevauchant, la complexité de chaque tâche et le volume total de travail à réaliser à un moment donné. La petite taille des lots permet de vérifier en permanence que le travail est sur la bonne voie. Et que la longueur des files d’attente est correctement gérée…

Ce principe vise à donner des conseils sur l’optimisation de ce processus en vue d’obtenir les meilleurs résultats.

Principe n° 7 : Appliquer la cadence, synchroniser avec la planification transverse

Les équipes Agile appliquent naturellement la cadence par le biais de sprints ou d’itérations. La création d’une cadence pour tous les sujets possibles réduit la complexité, répond à l’incertitude, développe la mémoire musculaire, renforce la qualité et incite à la collaboration. La synchronisation de ces cadences permet aux personnes et aux activités de fonctionner comme des rouages où les informations apprises éclairent les décisions et la planification incrémentielle.

Principe n° 8 : Susciter la motivation intrinsèque des travailleurs du savoir

Inspiré par le conseiller en gestion influent Peter Drucker et l’auteur Daniel Pink, ce principe est l’un de nos préférés ! Il permet de libérer le potentiel des équipes et aide la direction à adopter une approche de commandement et de contrôle pour coacher ses équipes et répondre à leurs besoins.

Principe n° 9 : Décentraliser la prise de décision

Réduire la longueur des files d’attente et adopter une approche économique en décentralisant la prise de décision confèrent aux équipes l’autonomie dont elles ont besoin pour accomplir leur travail. Les dirigeants doivent conserver leur pouvoir de décision pour les sujets stratégiques et permettre aux équipes d’opérer des choix éclairés sur tous les autres sujets.

Comment fonctionne SAFe ?

Les organisations prêtes à implémenter SAFe bénéficient généralement d’un parrainage au niveau de la direction, d’une forte volonté de changement et d’une base Scrum.

Scaled Agile, Inc. fournit une feuille de route pour implémenter SAFA, qui contient des étapes détaillées pour vous lancer et configurer l’organisation en vue de l’adoption générale dans tous les portefeuilles. Voici les 12 étapes de l’implémentation de SAFe :

1. Atteindre le point de bascule
2. Former des agents du changement Lean/Agile
3. Former des directeurs, des responsables et des leaders
4. Créer un centre d’excellence Lean/Agile
5. Identifier des flux de valeur et des Agile Release Trains (ART)
6. Élaborer le plan d’implémentation
7. Préparer le lancement de l’ART
8. Former les équipes et lancer l’ART
9. Préparer le lancement de l’ART
10. Lancer d’autres ART et flux de valeur
11. Étendre au portefeuille
12. Maintenir et améliorer

Comment SAFe se situe-t-il par rapport aux autres frameworks Agile à grande échelle ?

Bien que SAFe® soit largement adopté par les entreprises disposant de grandes équipes de développement, d’autres frameworks Agile à grande échelle ont gagné en popularité au fil du temps. Tous ces frameworks partagent cinq composants principaux : l’inspiration des 12 principes du manifeste Agile, la cadence, la synchronisation, Scrum et les pratiques de développement de qualité. Comprendre les origines des autres frameworks, les différences fondamentales et les conditions pour une application réussie permet aux organisations de sélectionner le framework qui répond le mieux à leurs besoins.

Vous souhaitez en savoir plus sur certains des principaux frameworks Agile à grande échelle ? Consultez la page de présentation Agile à grande échelle sur le coach Agile.

SAFe et Scrum@Scale

Dans Scrum@Scale (S@S), tout le monde fait partie d’une équipe Scrum interchangeable. En fonction de leurs objectifs, les réseaux d’équipes Scrum se rassemblent pour former un écosystème. L’objectif de S@S est de créer un réseau d’équipes Scrum grâce à une architecture « scale-free », ce qui signifie que les rôles et les événements Scrum de base sont mis à l’échelle de façon linéaire, sans introduire de nouvelle dynamique de processus. Par exemple, un Scrum de Scrums (SoS) peut ne pas être suffisant pour un produit très complexe comptant 25 équipes Scrum, donc un Scrum de Scrum de Scrums (SoSoS) avec un Scrum de Scrums Master (SoSM) peut être nécessaire.

Bien que S@S soit généralement moins normatif, il propose une question directrice afin d’aider les organisations à déterminer si elles sont prêtes à évoluer : si vous ajoutez d’autres personnes au système, les performances augmentent-elles de manière exponentielle ou la productivité en souffre-t-elle ?

Tout comme SAFe, S@S propose un contenu de référence en ligne, notamment un guide Scrum@Scale complet dont la popularité ne cesse de croître.

Le framework S@S est le plus approprié dans les cas suivants :

• La stack technique est orientée objet (c’est-à-dire que les user stories verticales peuvent être livrées en deux semaines).
• Les « feature teams » de l’organisation possèdent des compétences en forme de T, adoptent des valeurs axées sur le produit et gèrent un minimum de paperasse.
• Aucun outil Agile ou de gestion du cycle de vie Agile (ALM) n’est requis tant que les pratiques ne sont pas devenues une seconde nature.
• L’équipe de direction est prête à se familiariser avec Scrum et à lever les obstacles pour l’organisation.

SAFe et Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) adopte une approche minimaliste des rôles, de la structure et des artefacts. Alors que SAFe propose quatre configurations pour satisfaire des équipes de plus en plus grandes et offrant des solutions de plus en plus complexes, LeSS en propose deux : LeSS pour deux à huit équipes et LeSS Huge pour plus de huit équipes. LeSS se distingue également par sa position selon laquelle les Product Owners devraient disposer d’un contrôle complet sur le contenu et d’une influence stratégique, alors que SAFe encourage une approche plus démocratique. Et si SAFe s’accompagne de nombreux facteurs qui influencent la stratégie, LeSS met l’accent sur une approche orientée client axée sur les clients payants.

À l’instar de S@S, LeSS évolue depuis les événements, les artefacts et les rôles Scrum. SAFe et LeSS mettent tous deux l’accent sur la pensée systémique, la pensée Lean et d’autres principes directeurs similaires. LeSS, en revanche, met fortement l’accent sur la réduction du gaspillage dans l’ensemble de l’organisation, avec pour objectif une amélioration continue.

Le framework LeSS est le plus approprié dans les cas suivants :

• Les équipes Scrum maîtrisent Scrum.
• La direction cherche à se restructurer et à expérimenter en permanence pour le bien commun.
• Un alignement sur la définition du produit existe.
• Un alignement sur la définition de l’état « Terminé » existe.
• Des coachs externes travaillent avec des groupes d’équipes, organisationnels et techniques.
• Des « feature teams » et des « component teams » possédant des compétences en T sont disponibles.
• L’organisation cherche à se débarrasser entièrement de la gestion de projets.

SAFe et DA

Contrairement aux autres frameworks décrits, Disciplined Agile (DA) est un kit d’outils qui permet aux organisations de décider de la méthode de travail la plus logique pour s’y adapter. Il propose une gouvernance Agile légère, qui s’appuie sur Scrum et Kanban, ainsi que des connaissances en matière de transformation dans des domaines, tels que les RH et les finances, la gouvernance, la méthodologie DevOps ou la gestion de portefeuilles. DA implique l’utilisation de différents niveaux d’évolutivité pour chaque projet et met l’accent sur la capacité de prise de décision pour aider à orienter la direction stratégique.

Le framework DA est le plus approprié dans les cas suivants :

• Les organisations veulent définir leurs propres parcours Agile à grande échelle.
• Les organisations souhaitent rester flexibles au sein de l’entreprise.
• Les organisations entendent préserver les choix de processus et/ou de framework.

SAFe et Spotify

Le « modèle » Spotify est un ensemble de pratiques autonome et axé sur les personnes qui peut être appliqué pour coordonner les équipes Agile. Il n’a jamais été conçu comme un modèle ou un framework, mais certaines entreprises l’ont adopté en tant que tel. Spotify met l’accent sur les équipes auto-organisées, transverses et colocalisées appelées « squads » (l’équivalent d’une équipe Scrum). En comparaison, SAFe n’a pas de disposition de ce type sur la colocation des équipes. Elle est encouragée pour la planification d’incrément de programme.

Les squads sont organisés en unités plus importantes appelées « tribus ». Les dépendances entre les squads sont peu nombreuses et sont traitées par le biais d’un Scrum de Scrums lorsqu’elles se produisent. Le partage des connaissances est possible grâce aux « chapitres » et aux « guildes », et des groupes informels sont organisés en fonction des compétences et des intérêts.

Par rapport à d’autres exemples, où des ressources en ligne, des cours de formation et des certifications sont disponibles, les ressources sur le modèle Spotify se limitent à un blog accessible au public et à d’autres éléments complémentaires développés par ses pionniers et ses fans. Le modèle est de plus en plus populaire, il est donc probable que nous en verrons d’autres à l’avenir.

Le modèle Spotify est le plus approprié dans les cas suivants :

• Application des idées dans votre propre contexte commercial.
• La culture organisationnelle est axée sur l’apprentissage, la tolérance aux erreurs et la prise de risques contrôlés.
• Les équipes et les produits sont « légèrement couplés, étroitement alignés » pour éviter tout conflit de dépendance.

SAFe 5.0

L’un des principes fondamentaux du framework SAFe est qu’il continue à évoluer en collaboration avec sa communauté d’experts dans le monde entier. Récemment, Scaled Agile, Inc. a lancé la version 5.0 de SAFe. Les principaux changements comprennent l’ajout d’un 10e principe, « Organiser autour de la valeur », et le remplacement de l’étape 12, « Maintenir et améliorer », par « Accélérer ». Mais les implications sont bien plus nombreuses.

Conclusion

Les frameworks comme SAFe et ceux qui ont été évoqués ci-dessus constituent une option viable pour aider les entreprises à se développer efficacement au sein de leur organisation et à atteindre leurs objectifs commerciaux. Mais les outils que vous choisissez pour vous aider à amplifier les pratiques existantes et à en tirer pleinement parti sont tout aussi importants. Nos équipes sont à votre disposition pour vous présenter la solution Jira Align d’Atlassian, une plateforme de planification Agile d’entreprise développée pour SAFe. Grâce à Jira Align, vous pouvez améliorer la visibilité, l’alignement stratégique et l’adaptabilité de l’entreprise afin d’accélérer votre transformation digitale.

L’article Le scaled agile framework Safe : ses principes, fonctionnement et comparaison avec les autres frameworks Agile à grand échelle est apparu en premier sur AZARA Consulting.

De nombreux signes indiquent que les équipes supports informatiques ont du mal à répondre aux besoins de votre organisation et de ses employés. Ceux-ci incluent la backlog des demandes non encore prises en charge, un taux de réponse faible, une productivité à la baisse, les niveaux élevés d’escalades avec des demandes urgentes et les mauvaises performances par rapport aux mesures des engagements de services convenues (SLAs).
De nombreuses organisations utilisent un système rudimentaire de ticketing ou IT Help Desk, mais il manque probablement la plupart des fonctionnalités disponibles dans les solutions modernes de gestion des services informatiques (ITSM). Cela affecte négativement l’efficacité du support informatique et offre une mauvaise expérience utilisateur aux collaborateurs.
Avec les exigences croissantes dans ce monde en constante évolution et sans un moyen efficace pour gérer les demandes des employés, la capacité de support informatique de l’entreprise aura du mal à suivre le rythme des objectifs business. Il est de plus en plus nécessaire que les services informatiques soient plus efficaces et offrent l’expérience utilisateur souhaitée. De plus, les attentes en matière de services informatiques de haute qualité continuent de croître, quel que soit l’endroit où les employés travaillent.

5 Bonnes pratiques ITSM clés pour de meilleure prestation de services IT

L’adoption des meilleures pratiques et outils ITSM modernes peut transformer la façon dont votre équipe de services informatiques fournit le support :

1. Séparer les incidents des demandes de service
2. Mieux utiliser les données relatives aux prestations de services
3. Offrir aux collaborateurs le libre-service 24 heures sur 24, 7 jours sur 7
4. Fournir le service informatique n’importe où, n’importe quand
5. Fournir de meilleurs services en utilisant les dernières technologies

Bonne pratique 1 : Séparer les incidents des demandes de service

Cette séparation est essentielle pour la hiérarchisation efficace des tâches et la meilleure utilisation du temps de l’équipe de support informatique. Et les tâches les plus importantes, basées sur l’urgence et l’impact de l’entreprise, peuvent être traitées en premier et avoir des engagements de services appropriés. D’autant plus que les tâches les plus prioritaires changeront probablement tout au long de la journée.
La séparation est un excellent moyen de réduire, voire d’éliminer, la difficulté de prendre en charge tous les incidents prioritaires.

Amélioration de l’efficacité de 20% *

Réduction des incidents de priorité haute 25% *

Réduction du temps de résolution de 50% *

Bonne pratique 2 : Mieux utiliser les données relatives aux prestations de services

La séparation des incidents des demandes de service, ainsi que la catégorisation des demandes, permettent à l’équipe support informatique de réduire de façon proactive sa charge de travail :

• Les données des incidents peuvent être analysées pour mettre en évidence les problèmes récurrents. Ainsi, la mise en place de la gestion des problèmes et la correction de la root cause va permettre de remédier aux futurs incidents potentiels.
• Les données de demande de service peuvent être analysées pour identifier les types de demandes récurrentes à volume élevé qui peuvent l’objet d’une automatisation.

En plus, l’accès aux données de prestation de services structurées offre également une meilleure compréhension des performances opérationnelles, permettant aux organisations d’aligner les services sur les objectifs business et d’identifier les opportunités d’amélioration.

37% Des employés disent que les employeurs automatisent toujours les processus pour améliorer l’expérience des collaborateurs *
75% Réduction des efforts liés à la génération de rapports et à la gestion des ressources *

Bonne pratique 3 : Offrir aux collaborateurs le libre-service 24/24, 7/7

Les collaborateurs préfèrent disposer d’un portail libre-service simple et intuitif leur permettant de saisir de façon très allégée leurs demandes.
La mise à disposition d’une base de connaissance couplée à de l’intelligence artificielle permet d’offrir une assistance virtuelle en temps réel, personnalisée et de haute qualité. Ce qui augmente la satisfaction des collaborateurs tout en réduisant la charge de travail de l’équipe support leur permettant ainsi de dédier plus de temps à la résolution des incidents et problèmes prioritaires.

77% des collaborateurs préfèrent disposer d’un portail leur permettant d’accéder à l’information de façon centralisée *

Bonne pratique 4 : Fournir le service informatique partout et à tout moment

En plus du libre-service, les collaborateurs de votre organisation s’attendent à avoir accès aux services informatiques à tout moment et de n’importe où.
L’accès au libre service à partir de n’importe quel device (mobile, PC, Tablette…) accélère la prise en charge des demandes, la productivité et augmente de ce fait la satisfaction des collaborateurs.

54% s’attendent à accéder au portail de l’ITSM à partir du mobile *

20% de réduction des demandes dues grâce à l’automatisation et l’intelligence artificielle *

Bonne pratique 5 : Automatisez à l’aide de l’Intelligence Artificielle et le machine learning

L’intelligence artificielle (IA) ou, plus précisément, les fonctionnalités du support informatique basées sur le machine learning sont déjà disponibles dans les principales solutions ITSM. De nombreuses organisations offrent du libre-service et de l’assistance automatique à l’aide des agents virtuels.

Les agents virtuels peuvent, par exemple, fournir les réponses requises et pertinentes à partir de la base de connaissance, ouvrir un nouveau ticket ou commander un service nouveau ou modifié via le chat.
Le machine learning peut aussi catégoriser automatiquement, hiérarchiser et affecter des tickets ou même fournir des solutions recommandées, basées sur des modèles appris. Le machine learning permet également ChatOps et l’analyse fournissant ainsi des services informatiques plus efficients.

Seuls 8% des organisations ont déployées des agents virtuels ou AI Chat Bots *

Adopter ces bonnes pratiques avec Jira Service Management

Atlassian offre une solution modulaire qui couvre l’ensemble des fonctionnalités d’un ITSM à la pointe de la technologie. En effet, Atlassian a été classé leader dans The Forrester Wave : Enterprise Service Management, Q4 2021.

Cette solution modulaire permet de s’intégrer dans le paysage informatique des organisations et de s’appuyer sur les outils déjà en place.

En tant qu’expert Atlassian, AZARA Consulting vous accompagne dans la mise en place d’un ITSM fiable et résilient tout en s’intégrant avec le paysage du parc applicatif de votre organisation.

* Forrester Research, “The Total Economic Impact Of ITSM Applications” (2019)

L’article 5 Bonnes pratiques pour un ITSM fiable et résilient est apparu en premier sur AZARA Consulting.

DevOps est un ensemble de pratiques, d’outils et d’une culture philosophique qui automatise et intègre les processus entre les équipes de développement (change) et les équipes en charge des opérations (Run). Il met l’accent sur la responsabilisation des équipes, la communication et la collaboration entre les équipes et les technologies de l’automatisation.

Le mouvement DevOps a commencé vers 2007 lorsque les communautés les équipes Développement (Change) et les équipes Opérations (Run) informatiques ont soulevé des inquiétudes concernant le modèle de développement logiciel traditionnel, où les développeurs qui codaient travaillaient indépendamment des opérations qui déployaient et prenaient en charge le support post-déploiement. Le terme DevOps, qui est la combinaison des mots “développement” et “opérations”, reflète le processus d’intégration de ces disciplines en un seul processus continu.

DevOps est devenu l’approche de facto dans toute Software Factory, introduisant les principes Lean & Agile afin d’optimiser le Time-to-market : la chaîne de valeur entre la conception de l’application, sa mise en en service et sas maintenance.

Chaque membre de l’équipe doit collaborer et commencer à agir comme s’il était sur le même bateau

Une équipe DevOps comprend les équipes de développement (change) et les équipes en charge des opérations (Run) travaillant en collaboration tout au long du cycle de vie du produit, afin d’augmenter la vitesse et la qualité du déploiement des solutions informatiques. C’est une nouvelle façon de travailler, un changement culturel, qui impacte fortement les équipes et les organisations.

Dans un modèle DevOps, les équipes de développement et d’exploitation ne sont plus « cloisonnées ». Parfois, ces deux équipes fusionnent en une seule équipe pour travailler sur l’ensemble du cycle de vie de l’application – du développement et des tests au déploiement et aux supports – et disposent d’un éventail de compétences multidisciplinaires.

Passer au DevOps n’est pas une question d’outils mais une question de technologies et d’interaction humaine : Personnes > Processus > Outils.

Les équipes DevOps utilisent des outils pour automatiser et accélérer les processus, ce qui contribue à accroître la fiabilité. Une chaîne d’outils DevOps aide les équipes à aborder les fondamentaux DevOps importants, notamment l’intégration continue (Continuous Integration), la livraison continue (Continuous Delivery), l’automatisation et la collaboration.

Les valeurs DevOps sont parfois appliquées à d’autres équipes que celles de développement. Lorsque les équipes de sécurité adoptent une approche DevOps, la sécurité est une partie active et intégrée du processus de développement. C’est ce qu’on appelle DevSecOps.

Les phases du cycle de vie DevOps

En raison de la nature continue de DevOps, les praticiens utilisent la boucle infinie pour montrer comment les phases du cycle de vie DevOps sont liées les unes aux autres. Bien qu’elle semble s’écouler de manière séquentielle, la boucle symbolise le besoin d’une collaboration constante et d’une amélioration itérative tout au long du cycle de vie.

Le cycle de vie DevOps se compose de six phases représentant les processus, les compétences et les outils nécessaires au développement (sur le côté gauche de la boucle) et les opérations (sur le côté droit de la boucle). Tout au long de chaque phase, les équipes collaborent et communiquent pour maintenir l’alignement, la vélocité et la qualité.

Planifier

Les équipes DevOps doivent adopter des pratiques agiles pour améliorer la vélocité et la qualité. Agile est une approche itérative de la gestion de projet et du développement des applications qui aide les équipes à découper le travail en plus petits éléments pour offrir une valeur ajoutée.

Développer

Développer en se basant sur les outils de contrôle de version qui offre les fonctionnalités de gestion des branches, les fussions, la réécriture de l’historique du dépôt et de puissants workflows.

Intégrer et livrer continuellement
CI/CD permet aux équipes de publier des produits de qualité régulièrement et de façon prévisible, à partir du dépôt du code source vers la production avec des workflow automatisés. Les équipes peuvent fusionner fréquemment les modifications de code, déployer de nouvelles fonctionnalités et intégrer des tests de bout en bout.

Monitorer et alerter
Identifiez et résolvez rapidement les incidents qui affectent la disponibilité, le temps de réponse et le fonctionnement de l’application. Informez automatiquement votre équipe des changements, des actions à haut risque, afin que vous puissiez continuer à utiliser les services.

Exploiter
Gérer la livraison de bout en bout des services informatiques aux clients. Cela inclut les pratiques impliquées dans la conception, la mise en œuvre, la configuration, le déploiement et la maintenance de toute l’infrastructure informatique de l’organisation.

Améliorer continuellement
Les équipes DevOps doivent évaluer chaque version et générer des rapports pour améliorer les futures versions. En recueillant les feedbacks en continu, les équipes peuvent améliorer leurs processus et intégrer les feedbacks clients pour améliorer la prochaine version.

DevOps By Atlassian

Les outils DevOps traitent les phases clés du cycle de vie DevOps. Ils renforcent les pratiques DevOps en aidant à améliorer la collaboration, à réduire le changement de contexte, à introduire l’automatisation et à permettre le contrôle et le monitoring.

Les solutions d’outils DevOps suivent généralement deux approches : une solution d’outils tout-en-un ou bien une solution ouverte. Une solution d’outils tout-en-un est une offre complète qui ne s’intègre généralement pas avec d’autres outils tiers, tandis qu’une solution d’outils ouverte permet une personnalisation avec différents outils. Il y a des avantages et des inconvénients aux deux approches.

Un exemple de solution d’outils DevOps ouverte est la solution Open DevOps d’Atlassian, qui inclut Jira comme base et s’intègre avec les principaux fournisseurs et applications du marché.

Quels sont les avantages du DevOps ?

Dans l’enquête DevOps Trends 2020 d’Atlassian, 99 % des personnes interrogées ont déclaré que DevOps avait un impact positif sur leur organisation. Les avantages de DevOps incluent des livraisons plus rapides et plus simples, l’efficacité de l’équipe, une sécurité accrue, des produits de meilleure qualité et, par conséquent, des équipes et des clients plus heureux.

Vélocité

Les équipes qui pratiquent DevOps publient des livraisons de façon plus fréquente, de meilleure qualité et plus stable. En effet, le rapport DORA 2019 State of DevOps a révélé que les équipes d’élite se déploient 208 fois plus fréquemment et 106 fois plus rapidement que les équipes peu performantes. La livraison continue permet aux équipes de développer, tester et livrer des applications avec des outils automatisés.

Collaboration améliorée
La base du DevOps est une culture de collaboration entre les développeurs et les équipes opérationnelles, qui partagent les responsabilités et la charge de travail. Cela rend les équipes plus efficaces et permet de gagner du temps lié aux transferts de compétences

Déploiement rapide
En augmentant la fréquence et la vitesse des livraisons, les équipes DevOps améliorent rapidement les produits. Un avantage concurrentiel peut être obtenu en publiant rapidement de nouvelles fonctionnalités et en réparant les bugs.

Qualité et fiabilité
Des pratiques telles que l’intégration continue et la livraison continue garantissent que les modifications sont fonctionnelles et sûres, ce qui améliore la qualité d’une application. Le monitoring aide les équipes à rester informées des performances en temps réel.

Sécurité
En incorporant la sécurité dans le pipeline d’intégration continue, de livraison continue et de déploiement continu, DevSecOps est une partie active et indissociable du processus de développement. La sécurité est introduite lors du développement du produit à travers des audits de sécurité actifs et des tests de sécurité dans la démarche agile et les workflows DevOps.

Comment adopter le DevOps ?

L’adoption du Devops nécessite tout d’abord un engagement à revoir le dispositif existant : personnes, processus et outils. L’objectif est de mettre en place l’infrastructure requise pour permettre à l’équipe Devops d’être autonome dans la conception, le déploiement et la gestion des produits sans trop dépendre des équipes externes.

Nos équipes sont à votre disposition pour vous accompagner dans l’adoption de la démarche en fonction du niveau de maturité de votre organisation.

L’article DevOps : Briser le mur entre Dev et Ops, inculquer un nouveau mindset de collaboration et s’appuyer sur les technologies d’automatisation est apparu en premier sur AZARA Consulting.

Utiliser Trello et Confluence ensemble vous permet d’utiliser ces pièces pour illustrer une plus grande user story, d’organiser projet plus grand et de préparer un planning plus vaste. Mais comment les utiliser ensemble ? Utilisez Confluence pour créer et planifier votre vision, puis utilisez Trello pour travailler et agir sur les détails de l’éxécution de cette vision.

Pour en savoir plus sur la meilleure façon d’utiliser les deux applications, lisez la suite.

Ajouter des cartes ou des tableaux Trello aux pages Confluence

Confluence est l’endroit où vous construisez votre vision. Par contre, Trello vous permet de diviser cela en petites tâches est d’organiser leurs réalisations. Faites-les ensemble en intégrant vos cartes et tableaux de projets dans la documentation. 

En faisant ceci, vous obtiendrez :

• Une mise à jour en temps réel. Toutes les modifications apportées par vous, ou quelqu’un d’autre, à partir de l’un des outils de la suite Atlassian, seront immédiatement visibles. 

• Le respect des permissions. Avant de pouvoir voir une carte ou un tableau, on vous demandera de vous connecter à Trello. Tout contenu que vous n’avez pas la permission de voir affichera une note vous indiquant que vous n’avez pas encore l’accès nécessaire pour le voir.

Comment est-ce qu’on peut intégrer Trello à Confluence ?

Pour intégrer un tableau de projet Trello dans une page Confluence, c’est très simple. Copiez et collez l’URL de votre carte sur une page Confluence et regardez le rendu automatique dans une carte dès que la page est publiée.

Vous pouvez voir l’état de chacune de vos tâches, les commenter, vous abonner pour rester à jour sur les changements ou vous inscrire. Si vous avez besoin d’ajouter plus d’informations, il suffit de cliquer sur la carte. Cela vous mènera dans Trello, où vous pouvez modifier la carte comme d’habitude.

Cette possibilité d’intégration fonctionne également avec un tableau de projet. Les carreaux donnent un large aperçu de votre tableau, sans les détails approfondis. Utilisez-les pour garder le lien des documents ou des fichiers sur Confluence. Ensuite, lorsque votre équipe a besoin d’ajouter quelque chose à son tableau, elle peut cliquer sur le carreau pour l’ouvrir dans Trello.

Vous pouvez également ajouter des tableaux entièrement interactifs sur votre page Confluence. Choisissez le bouton “+” Trello Board, et après ajouter l’URL de la carte et la hauteur à laquelle vous voulez que votre carte soit embarquée. Cela affichera une carte de projet entièrement fonctionnelle sur votre page Confluence. De cette façon, vous pourriez déplacer les cartes d’une liste à une autre, ajouter ou modifier des détails et faire tout ce que vous feriez habituellement sur un tableau de projet, à partir de Confluence.

Ajouter des pages de Confluence aux cartes Trello

Évidemment, les intégrations vont dans les deux sens. En utilisant la puissance Confluence pour Trello, vous pouvez :

• Attacher les pages Confluence Cloud aux cartes des tâches et accéder à votre contenu depuis votre tableau en un seul clic
• Créer de nouvelles pages Confluence Cloud directement à partir des cartes.
• Voir toute l’activité sur votre page, qui a créé la page et quand elle a été créée, y compris un extrait et le nombre de commentaires sur la page, à partir de la carte Trello.

Quelques cas pratiques

Voici quelques exemples pratiques sur la façon d’utiliser Trello et Confluence ensemble de la manière la plus efficace :

• Gérer votre travail au sein de plusieurs équipes ou projets – Obtenez un aperçu du travail de vos équipes en intégrant chacune de leurs cartes de tâches sur une seule page Confluence. Idéal lorsque vous avez des équipes agiles et vous avez juste besoin de faire une vérification rapide sur les progrès de vos équipes.

• Faire un Brainstorming et partager des idées – Utilisez Confluence pour détailler un problème et des contraintes, puis utilisez Trello pour réfléchir aux solutions possibles.

• Planifier un projet avec Confluence – Ajoutez votre tableau de projet à la page de planification du projet afin que votre équipe et d’autres intervenants puissent suivre vos progrès.

• Créer de la documentation dans Confluence – Utilisez Trello pour planifier votre architecture d’information, afin de pouvoir déplacer des sous-sujets d’un sujet parent à un autre.

• Travailler sur des tâches – Conservez tous vos documents et fichiers connexes dans Confluence, et intégrez les cartes Trello correspondantes sur chaque page. Ensuite, lorsque vous faites des progrès, il suffit de commenter la carte Trello à partir de Confluence.

L’article Trello et Confluence : comment les utiliser ensemble ? est apparu en premier sur AZARA Consulting.

Qu’est-ce que Devops signifie ?

Les entreprises de logiciels deviennent de plus en plus importantes et omniprésentes dans la chaine de valeurs de toutes les entreprises. Dans ce contexte, les modèles traditionnels de développement ne résistent pas aux environnements à forte demande et à forte croissance.

Traditionnellement, les équipes Développement et Opérations ont l’habitude de travailler séparément dans des silos, ce qui entrave la capacité d’agir rapidement suite à des changements ou urgences opérationnelles. La réponse à cette relation litigieuse a été un mouvement appelé DevOps. C’est un terme fantaisiste pour une idée simple :

Une approche permettant de réunir deux fonctions clés de la DSI d’une entreprise chargée du développement d’applications. D’un côté, vous avez terme le “Dev” représentant les équipes de développeurs et de l’autre, vous avez le terme “Ops” représentant les équipes d’exploitation des systèmes d’information (Operations en anglais).

L’objectif de DevOps est que les équipes de développement et d’exploitation travaillent mieux ensemble.

Définition et objectif de DevOps

Voyons donc comment il est possible de créer une infrastructure devops avec Atlassian.

Outils pour la documentation

Si votre équipe travaille dans un environnement agile, il est important de fournir régulièrement des retours d’information et feedbacks aux équipes de développement. Pour ce faire, les interactions entre le Product Owner et les développeurs peuvent être facilitées de plusieurs façons.

Jira Software offre à l’entreprise plusieurs fonctionnalités intéressantes, notamment :

• Un Backlog Scrum où on est capable de peaufiner et de classer les Stories par ordre de priorité.
• La création et le lancement des Sprints en quelques clics.
• Des tableaux agiles qui s’adaptent à votre processus de développement.
• Des rapports détaillant le travail effectué (notamment les rapports de Sprint).

Dans tout cela, Confluence a un rôle très important. Il permet en effet de rendre le tout encore plus organisé. Vous n’aurez plus besoin de chercher parmi les piles de mails pour trouver les informations que vous recherchez, grâce à cette fonctionnalité. Tout les ressources sont centralisées sur Confluence et directement liées au projet de développement.

Outils pour lancer une release

Lorsque les développeurs, le Scrum Master et le Product Owner valident ensemble les fonctionnalités de la nouvelle version et acceptent de le livrer en production, c’est alors que nous parlons de « lancer une release ».

Dans cette phase l’équipe réalise simplement les manipulations suivantes :

• Créer une branche de diffusion de la branche de développement qui prend son nom à partir du numéro de version (par exemple : 2.5). Pour ce faire, il suffit de remplir des champs vides avec des informations utiles.

• Le même numéro de version dans la release du projet Jira relie toutes les Stories de ce sprint, et potentiellement le sprint précédent également s’il n’a pas été publié.

Les actions ci-dessus sont simples – il suffit de se faire guider par le processus de saisie des informations. Il est possible de définir la portée fonctionnelle de la version à la fois dans Jira et Bitbucket, facilitant ainsi le travail pour la documentation (où nous recommandons Confluence) et pour le Product Owner qui pourrait exécuter les tests. Si des anomalies sont détectées, elles peuvent facilement être inclus dans la même version.

Outils d’automatisation Devops pour le déploiement continu

Et voilà que l’outil Bamboo entre en jeu ! Grâce à l’intégration avec Bitbucket et Jira Software, nous pouvons automatiser plusieurs tâches rébarbatives qui prenaient beaucoup de temps pour les développeurs.

Construction du livrable (build) avec Bamboo

Pour gérer les builds des nouvelles version, Atlassian a opté pour une seule version avec un seul déploiement. Cela simplifie la configuration et rend ainsi l’utilisation et la gestion des versions plus gérable.

Dans ce plan de build, un script vérifie le type de branche sur lequel le commit a été réalisé et effectue certaines actions:

• La branche de développement agit comme la branche de base. À chaque commit, le plan de construction est lancé pour chaque commit afin de créer le livrable.
• Un plan est créé manuellement pour la branche master. Lorsqu’un commit est détecté sur cette branche, le livrable est créé et publié.
• Un plan est créé automatiquement pour chaque branche.  Une compilation du projet et un examen du code sont effectués après chaque commit sur une de ces branches.
• Un plan est créé automatiquement pour chaque branche de version et hotfix. Ces plans sont lancés manuellement par les développeurs pour créer le livrable.

Trouver les meilleurs outils Devops pour vos besoins

Il est crucial de disposer des bons outils Devops lors de la transition vers l’approche Agile, telles que : la livraison continue, le déploiement continu ou bien l’intégration continue. Et c’est sur ce point que la suite Atlassian excelle vraiment. Les intégrations entre les applications simplifient le processus tout entier. Indépendamment de l’évolution de vos besoins et de votre équipe, la documentation est toujours hébergée dans Confluence et liée à Jira. 

Tout au long du cycle de développement, le travail effectué sur l’ensemble des activités réalisé pour chaque User Story (code, build et déploiement) est enregistré en temps réel et de manière consistante et organisée. Tout peut donc être suivi et retrouvé sans effort, ce qui permet à chaque membre d’équipe d’orienter et de concentrer ses efforts sur son expertise métier et son rôle à jouer pour la réussite des projets.

Cependant, il n’y a pas de garantie qu’une méthodologie Devops sera adoptée, même lorsque les bons outils seront installés. Il est impératif de définir les processus appropriés que les outils et les gens mettront en œuvre. Cela repose sur une communication solide au sein de l’équipe, qui peuvent être facilitées par des ateliers Agiles et des rencontres périodiques avec tous les interlocuteurs concernés. Cela permet de résoudre rapidement les obstacles techniques et fonctionnels.

Concevoir et bâtir correctement votre infrastructure DevOps n’est en aucun cas une mission facile. C’est pourquoi AZARA Consulting est là pour vous aider. N’hésitez pas à nous contacter, nous serons ravis de vous rencontrer et de connaitre vos besoins pour vous accompagner dans votre aventure de transformation DevOps et Agile.

L’article DevOps : votre infrastructure grâce à Atlassian est apparu en premier sur AZARA Consulting.