La version d'octobre 2022, la refonte la plus importante de la méthode APIOps Cycles de son histoire, m'a incité à écrire ce blog pour expliquer pourquoi les API ont besoin de leur propre méthode (Lean, Gestion allégée).
L'objectif de Gestion allégée est d'améliorer ce que l'on appelle le temps de cycle et la qualité. Avec Lean API Development et APIOps Cycles , la méthode de développement d'API ouverte et orientée vers les entreprises, vous pouvez créer de bonnes API en peu de temps.
Ne vous méprenez pas ; il ne s'agit pas seulement de bonne qualité, c'est-à-dire d'une mise en œuvre sans faille. Il s'agit de ce qui est le mieux pour votre entreprise, vos clients, vos partenaires et vos équipes de développement.
Lorsque j'ai commencé à créer des cycles ApiOps, je suis tombée amoureuse des principes de gestion Lean. DevOps, en tant que pratique technique et culturelle, trouve ses racines dans le Lean. API Ops, en tant que terme, a été principalement utilisé pour désigner le développement automatisé d'API en utilisant conjointement DevOps et la gestion des API.
Ceux qui parlent d'APIOps cherchent souvent à créer de meilleures API ou au moins à les publier plus rapidement. Réaliser des APIOps appropriés en se concentrant sur la technologie ne suffit pas. Vous avez également besoin de la bonne culture, des bonnes personnes, des bons processus et du bon design.
Le Lean est une philosophie et une pratique de gestion qui tente d'éliminer les « déchets » du processus de production.
Parce que les déchets n'apportent aucune valeur au client. Le gaspillage fait perdre un temps et des ressources précieux à l'organisation. Vous pouvez générer plus de valeur et de revenus avec les mêmes ressources avec un minimum de gaspillage.
1. Défauts
2. Surproduction
3. En attente
4. Transformation sans valeur ajoutée
5. Transport (ou Touches)
6. Inventaire
7. Mouvement
8. Gaspillage des employés et des compétences
Savez-vous comment fonctionne l'API ? Il vous manque des informations ? Existe-t-il un traitement non standard ?
L'API est désormais plus étendue, avec plus de points de terminaison ou d'attributs que nécessaire. Les développeurs croulent sous une énorme quantité de documentation inutile.
Attendre est une perte de temps pour les développeurs et les utilisateurs d'API. Attendre la publication de l'API ou de la nouvelle fonctionnalité est un gâchis. Attendre une API lente et peu performante est également une perte de temps.
Les exemples incluent des procédures et des processus complexes ou une architecture lourde. Utiliser des processus de gestion de projet pour contrôler le développement des API plutôt que la gestion des produits. Avoir une gouvernance trop stricte, c'est-à-dire des processus hiérarchiques pour la publication des API.
Ce gaspillage peut prendre de nombreuses formes : les techniciens et les hommes d'affaires ne parlent pas la même langue. Trop de personnes sont impliquées. Un trop grand nombre de demandes d'API distinctes sont nécessaires pour exécuter une tâche.
La création d'API que les consommateurs d'API n'utilisent pas immédiatement constitue un gaspillage d'inventaire.
Du gaspillage du point de vue de l'efficacité individuelle : combien de documents un utilisateur d'API ou un développeur d'API doit-il examiner pour utiliser ou créer des API exceptionnelles ? Ou à quelle fréquence font-ils des allers-retours, demandent-ils de l'aide, essayent-ils des choses ?
Une équipe API non formée et non motivée n'est pas rentable. Les API qui obligent les développeurs à étudier sérieusement avant de comprendre l'API font perdre du temps à leurs développeurs.
- API et qualité des API
- Développement et consommation d'API
- le lien entre les API et la stratégie
Vous n'avez pas besoin d'être un passionné du Lean pour l'utiliser APIOps Cycles . Je voulais juste voir à quel point il est important de prendre en compte les méthodes que vous utilisez pour développer des API.
APIOps et APIOps Cycles sont des marques commerciales d'Osaango et peuvent être utilisées dans le cadre de l'utilisation de la méthode APIOps Cycles distribuée sous licence CC-BY-SA 4.0.