Temps de lecture : 7 min
Cet article de blog fait partie d'une série d'articles couvrant la langue vernaculaire commune associée au développement de logiciels.
Dans le 1er article de blog (en anglais), nous avons couvert les domaines ADLM et SDLC, leurs définitions, leurs origines, leur classification et comment ils sont connectés.
Dans cet article, nous couvrirons ALM, DevOps et EAP (EAPT).
EAP (EAPT)
Commençons par les concept EAP/EAPT (Enterprise Agile Planning ou Enterprise Agile Planning Tools) correspondant à un terme de marché inventé par Gartner ces dernières années. Il élargit le concept d'ADLM depuis l'utilisation de méthodes Agile au niveau de l'équipe / projet vers la mise en œuvre de la philosophie Agile à grande échelle, afin de réaliser un développement Agile au niveau entreprise, dans le but de fournir une plus grande valeur pour toute l'entreprise et pas seulement au niveau d’une équipe.
Une approche Agile centrée sur une équipe a promis un nouveau monde dans la gestion du développement de logiciels, et l'a fait pour l'essentiel. Cependant, comme le nombre d'équipes Agile a augmenté au sein d'une organisation, elle a présenté son propre ensemble de défis. C'est là qu'EAP intervient, en aidant à gérer le cycle de vie du développement lorsque des méthodologies telles que SAFe, LeSS, Disciplined Agile, etc. sont mises en œuvre pour gérer le développement de logiciels Agile à l'échelle de l'entreprise, en utilisant des capacités clés telles que la gestion de portefeuille de projets, l’intégration du Service Desk, le Planning (Classe Entreprise) Agile, la gestion Agile des Backlog et des versions, etc.
Alors où en sommes-nous ? Et comment EAP s'intègre-t-il dans notre contexte global ? Essentiellement EAP (EAPT) est à l’ADLM ce que l’ADLM est à SDLC. Voilà une série d'acronymes. Qu'entendons-nous par là ? En termes simples, EAP est la gestion du cycle de vie du développement, lorsque des méthodologies Agile à l'échelle telles que SAFe ou LeSS ou Disciplined Agile sont mises en œuvre au sein d'une organisation.
Armés de ces informations, examinons la classification EAP et la façon dont il s'intègre dans un grand schéma global.
Une approche Agile centrée sur une équipe a promis un nouveau monde dans la gestion du développement de logiciels, et l'a fait pour l'essentiel. Cependant, comme le nombre d'équipes Agile a augmenté au sein d'une organisation, elle a présenté son propre ensemble de défis. C'est là qu'EAP intervient, en aidant à gérer le cycle de vie du développement lorsque des méthodologies telles que SAFe, LeSS, Disciplined Agile, etc. sont mises en œuvre pour gérer le développement de logiciels Agile à l'échelle de l'entreprise, en utilisant des capacités clés telles que la gestion de portefeuille de projets, l’intégration du Service Desk, le Planning (Classe Entreprise) Agile, la gestion Agile des Backlog et des versions, etc.
Alors où en sommes-nous ? Et comment EAP s'intègre-t-il dans notre contexte global ? Essentiellement EAP (EAPT) est à l’ADLM ce que l’ADLM est à SDLC. Voilà une série d'acronymes. Qu'entendons-nous par là ? En termes simples, EAP est la gestion du cycle de vie du développement, lorsque des méthodologies Agile à l'échelle telles que SAFe ou LeSS ou Disciplined Agile sont mises en œuvre au sein d'une organisation.
Armés de ces informations, examinons la classification EAP et la façon dont il s'intègre dans un grand schéma global.
En regardant la classification globale, il est clair que l'EAP étend l'ALDM, tout en se concentrant progressivement sur l’aspect Agile au niveau des méthodologies. Pour ce faire, il intègre un large éventail de capacités Agile et met l'accent sur la gestion de portefeuille de projets Agile. Bien que EAP inclue également la gestion des versions et l'intégration du Service Desk en tant que capacités essentielles, il ne parvient pas à intégrer pleinement les opérations informatiques en fusionnant l'écart entre le développement et les opérations. C'est là qu'intervient DevOps. Les vraies questions sont qu’est-ce que DevOps et pourquoi en avons-nous besoin maintenant ?
DevOps
Alors que SDLC, ADLM et EAP sont principalement concernés par la gestion du processus de développement des logiciels, DevOps vise à combler le fossé entre la création de logiciels, son déploiement et son utilisation. En règle générale, les activités telles que l'intégration et le déploiement continus (CI / CD) et la gestion des versions sont considérées comme faisant partie des « DevOps ». En fin de compte, l'idée derrière DevOps est de fournir de la valeur, comme nos concepts précédents. Cependant, la principale différence entre DevOps et nos concepts précédents est qu'il le fait en mettant la valeur de l'effort de développement entre les mains de ceux qui peuvent en faire le meilleur usage, plutôt qu'en optimisant intrinsèquement le processus de développement. En ce sens, DevOps est indépendant de la méthodologie de développement utilisée.
En regardant la classification globale, les frontières entre SDLC, ADLM et EAP vs DevOps s'estompent un peu au milieu du processus, lorsque l'on parle d'activités telles que la construction, le test et la publication de logiciels. Cependant, des concepts tels que SDLC, ADLM et EAP s'appliquent généralement aux parties préliminaires du cycle de vie telles que la collecte des exigences ou la création de cas d’utilisation dans le cas du développement de logiciels Agile, la conception / architecture de l'application et son développement global. Alors que lorsque l'on se réfère à DevOps, on a tendance à se référer à des activités ultérieures du cycle de vie telles que le déploiement de logiciels en utilisation ou comme un produit, sa surveillance et ses opérations.
L'argument logique de ce point de vue est que le « Dev » dans DevOps concerne le développement et l'écriture du code, se référant aux premières parties du cycle de vie. Cependant, lorsque nous pensons à DevOps et où il ajoute de la valeur et joue un rôle plus important, il se trouve aux dernières étapes du cycle de vie. En tant que tel, par souci de simplicité, il est préférable de penser que DevOps se réfère à des activités ultérieures du cycle de vie.
ALM
Pour en revenir là où nous avons commencé, nous avons couvert SDLC, ADLM, EAP et DevOps, mais qu'en est-il d’ALM ? Où ALM s'intègre-t-il dans ce schéma global ? Que signifie ALM dans le développement de logiciels modernes ? Et pourquoi est-ce important ?
Considérez ALM comme le récit global qui englobe et inclut les autres. ALM est tout, depuis la naissance ou le début d'une application jusqu'à sa fin de vie. En tant que tels, SDLC, ADLM, EAP et DevOps font tous partie d'ALM, où SDLC, ADLM et EAP se concentrent sur la gestion du développement, DevOps se concentre sur la gestion de la dernière moitié de la publication, de la surveillance et de la maintenance du cycle de vie. Il est important de noter que bien que SDLC, ADLM, EAP et DevOps soient des sous-ensembles d'ALM, ils ne se chevauchent pas nécessairement ou sont des sous-ensembles les uns des autres. Des activités telles que la gestion de portefeuille et l'intégration du centre de services font partie d'ALM mais ne font pas automatiquement partie de SDLC, ADLM ou DevOps.
ALM a également tendance à se concentrer sur la collaboration inter-fonctionnelle, la traçabilité et la conformité du cycle de vie, la réutilisation des actifs et la gestion des variantes, la gestion des risques et des risques des applications et la gestion de la sécurité des applications plus que d'autres. Le concept d'ALM est encore plus large en ce qui concerne les systèmes cyber-physiques, car ils ont tendance à intégrer profondément les composants physiques et logiciels. Dans ce scénario, ALM prend en charge non seulement les activités spécifiques au logiciel, mais prend également en charge les intégrations dans PLM, MBSE, l'intégration avancée logiciel/matériel, la conception et le développement de l'architecture, etc. pour synchroniser les processus de développement logiciel avec ceux de développement matériel.
Considérez ALM comme le récit global qui englobe et inclut les autres. ALM est tout, depuis la naissance ou le début d'une application jusqu'à sa fin de vie. En tant que tels, SDLC, ADLM, EAP et DevOps font tous partie d'ALM, où SDLC, ADLM et EAP se concentrent sur la gestion du développement, DevOps se concentre sur la gestion de la dernière moitié de la publication, de la surveillance et de la maintenance du cycle de vie. Il est important de noter que bien que SDLC, ADLM, EAP et DevOps soient des sous-ensembles d'ALM, ils ne se chevauchent pas nécessairement ou sont des sous-ensembles les uns des autres. Des activités telles que la gestion de portefeuille et l'intégration du centre de services font partie d'ALM mais ne font pas automatiquement partie de SDLC, ADLM ou DevOps.
ALM a également tendance à se concentrer sur la collaboration inter-fonctionnelle, la traçabilité et la conformité du cycle de vie, la réutilisation des actifs et la gestion des variantes, la gestion des risques et des risques des applications et la gestion de la sécurité des applications plus que d'autres. Le concept d'ALM est encore plus large en ce qui concerne les systèmes cyber-physiques, car ils ont tendance à intégrer profondément les composants physiques et logiciels. Dans ce scénario, ALM prend en charge non seulement les activités spécifiques au logiciel, mais prend également en charge les intégrations dans PLM, MBSE, l'intégration avancée logiciel/matériel, la conception et le développement de l'architecture, etc. pour synchroniser les processus de développement logiciel avec ceux de développement matériel.
Au final, comme le reste des méthodologies de gestion du cycle de vie ALM, il s'agit avant tout d'ajouter de la valeur. Cependant, contrairement au reste, ALM ne se concentre pas uniquement sur l'ajout de valeur à l'effort de développement ou à l'effort opérationnel. Il adopte une approche plus holistique du cycle de vie d'une application (c'est-à-dire de sa création à sa fin de vie) et, en tant que tel, il ajoute de la valeur à l'ensemble du cycle de vie. ALM vise également à ajouter de la valeur par le biais de la collaboration inter-fonctionnelle, de la traçabilité du cycle de vie, de la réutilisation avancée, de la conformité, etc. Ceci est de plus en plus important dans le cycle de vie rapide des logiciels d'aujourd'hui, où les produits logiciels doivent être publiés plus fréquemment, avec une plus grande complexité, une variabilité accrue et avec une qualité meilleure.
Revenons au début, maintenant que nous savons « Qui est qui » dans cet espace, la question pertinente est pourquoi est-ce important ? En règle générale, les fournisseurs de ce marché utilisent quelques combinaisons de termes tels que ALM ou DevOps ou EAP, etc. en référence à un sous-ensemble individuel de processus ou parfois même à l'ensemble du cycle de vie, même s'ils ne sont pas des remplacements directs les uns des autres. Par conséquent, il est essentiel de savoir exactement ce qui est couvert lorsque ces terminologies sont utilisées. Chez Siemens pour Polarion, nous nous concentrons sur l'intégralité du cycle de vie, nous adoptons une perspective plus large pour le développement de logiciels visant à ajouter de la valeur à l'ensemble du cycle de vie, y compris non seulement les activités traditionnelles associées au développement de logiciels, mais en les élargissant pour inclure des activités nécessaires au développement de systèmes cyber-physiques. En ce sens, Polarion a une vision holistique du développement logiciel au sein d'une plate-forme de gestion du cycle de vie des applications unifiée.
Intéressé par plus de sujets de leadership éclairé sur le développement de logiciels ? contactez-nous
Intéressé par plus de sujets de leadership éclairé sur le développement de logiciels ? contactez-nous
Source : ici