L'intégration continue/déploiement continu (CI/CD) introduit l'automatisation dans les étapes de développement d'applications pour les livrer fréquemment aux clients. CI/CD introduit une automatisation et une surveillance continues tout au long du cycle de vie de l'application, des tests à la livraison, puis au déploiement.
Aspect
Explication
Définition
Intégration continue (CI) et Déploiement continu (CD) sont des pratiques de développement de logiciels visant à améliorer l’efficacité et la qualité du processus de développement et de déploiement. – Intégration continue (CI) implique intégrer automatiquement les changements de code de plusieurs développeurs dans un référentiel partagé. Les développeurs valident régulièrement leur code, déclenchant des builds et des tests automatisés. L'objectif premier est de détecter les problèmes d'intégration à un stade précoce et assurez-vous que la base de code reste stable. – Déploiement continu (CD) va encore plus loin avec CI en automatiser le processus de déploiement. Ça implique déploiement automatique des modifications de code aux environnements de production après avoir réussi les tests et les contrôles. Le CD réduit le temps entre l'achèvement du code et sa disponibilité pour les utilisateurs finaux. CI et CD favorisent tous deux versions logicielles fréquentes, petites et fiables.
Concepts clés
- Test automatisé: CI et CD s'appuient tous deux sur des tests automatisés pour garantir que les modifications de code n'introduisent pas de défauts ou de régressions. – Contrôle de version: les modifications de code sont gérées à l'aide de systèmes de contrôle de version (par exemple, Git), permettant la collaboration et le suivi des modifications. – Construire l'automatisation: les pipelines CI/CD automatisent le processus de construction, convertissant le code source en logiciel exécutable. – Deploy Automation: CD automatise le déploiement des modifications de code dans les environnements de production ou de transfert. – Rétroaction continue: Les développeurs reçoivent un retour immédiat sur la qualité de leur code grâce à des tests et des contrôles automatisés. – L'infrastructure comme code: Le CD implique souvent de gérer l'infrastructure et les configurations sous forme de code pour garantir la cohérence et la répétabilité.
Caractéristiques
- Automation: CI et CD s'appuient fortement sur l'automatisation, réduisant ainsi les interventions manuelles et les erreurs humaines. – Test continu: Les tests automatisés sont un composant essentiel, garantissant que les modifications du code n'introduisent pas de défauts. – Rétroaction rapide: Les développeurs reçoivent un retour rapide sur la qualité du code, ce qui leur permet de résoudre les problèmes rapidement. – Changements progressifs: Les modifications de code sont généralement petites et fréquentes, ce qui réduit le risque de pannes à grande échelle. – Fiabilité: Les pipelines CI et CD visent une fiabilité et une prévisibilité élevées dans le processus de développement logiciel.
Avantages
- Développement plus rapide: CI/CD accélère le cycle de développement, permettant une livraison plus rapide des fonctionnalités et des corrections de bugs. – Risque Réduit: Les tests et le déploiement automatisés réduisent le risque d'introduction de défauts dans les environnements de production. – Collaboration améliorée: CI encourage la collaboration entre les développeurs, car les modifications sont continuellement intégrées dans une base de code partagée. – Assurance qualité: CD garantit que les modifications de code répondent aux normes de qualité avant d'être déployées, améliorant ainsi la qualité globale du logiciel. – Cohérence: Le CD favorise la cohérence en automatisant le provisionnement et les configurations de l'infrastructure.
Inconvénients
- Complexité: La mise en œuvre de pipelines CI/CD peut être complexe, nécessitant du temps et des efforts pour la configuration et la maintenance. – Intensif en ressources: CI/CD peut nécessiter des ressources informatiques importantes, notamment pour les tests et le déploiement automatisés. – Courbe d'apprentissage: Les développeurs et les équipes devront peut-être apprendre de nouveaux outils et processus pour adopter efficacement le CI/CD. – Faux positifs: Les tests automatisés peuvent parfois produire des résultats faussement positifs, nécessitant une enquête et des ajustements potentiels.
Applications
- Développement la toile: CI/CD est largement utilisé dans le développement Web pour déployer en continu des mises à jour et de nouvelles fonctionnalités sur les sites Web et les applications Web. – Développement Mobile App: Les équipes de développement d'applications mobiles utilisent des pipelines CI/CD pour automatiser les tests et le déploiement des applications Android et iOS. – Services Cloud: Les fournisseurs de cloud proposent souvent des services CI/CD qui s'intègrent parfaitement à l'infrastructure cloud. – Développement IoT: Les projets Internet des objets (IoT) bénéficient des pratiques CI/CD pour garantir la fiabilité des logiciels embarqués. – Logiciels d'entreprise: Les grandes organisations utilisent CI/CD pour gérer des systèmes logiciels complexes avec plusieurs équipes de développement.
Cas d'usage
- Site Web de commerce électronique: Un site Web de commerce électronique met en œuvre CI/CD pour déployer en permanence de nouvelles listes de produits, fonctionnalités et contenus promotionnels, garantissant ainsi une expérience d'achat transparente pour les utilisateurs. – Application mobile: Une équipe de développement d'applications mobiles adopte CI/CD pour automatiser les tests et le déploiement des mises à jour d'applications, en fournissant rapidement des corrections de bogues et de nouvelles fonctionnalités aux utilisateurs. – Plateforme SaaS: Un fournisseur de logiciels en tant que service (SaaS) utilise CI/CD pour déployer des mises à jour régulières de sa plate-forme, améliorant ainsi la satisfaction des utilisateurs et conservant un avantage concurrentiel. – Dispositif IoT: Un fabricant d'appareils IoT utilise CI/CD pour fournir des mises à jour de micrologiciels et des correctifs de sécurité aux appareils connectés, garantissant ainsi leur fiabilité et leur sécurité. – Suite logicielle d'entreprise: Une grande entreprise utilise CI/CD pour gérer une suite d'applications logicielles d'entreprise, en coordonnant les efforts de développement de plusieurs équipes et en garantissant la compatibilité entre les composants.
Alors que la notion de développement logiciel continue de s'étendre, de nombreuses facettes adjacentes du processus de développement logiciel sont devenues des cibles de choix pour la prise en charge du code. Des exemples de ces objectifs incluent l'intégration et le déploiement, qui constituent la base de CI/CD.
CI/CD introduit une automatisation et une surveillance continues tout au long du cycle de vie de l'application, des tests à la livraison, puis au déploiement. L'automatisation lors de l'exécution du script réduit la probabilité d'introduire des erreurs et, par conséquent, nécessite moins d'intervention humaine.
De plus, les modifications de code sont continuellement créées, testées et déployées à chaque itération pour réduire les risques que le code soit basé sur des bogues ou des versions antérieures ayant échoué.
Le pipeline CI/CD
Collectivement, ces pratiques sont appelées « pipeline CI/CD » et sont soutenues par des approches agiles telles que DevOps ou Site Reliability Engineering (SRE). Ce pipeline présente plusieurs avantages pour les entreprises, notamment :
La capacité de réduire les coûts et les complexités et de détourner les ressources vers les domaines qui offriront le meilleur retour sur investissement. En fin de compte, le pipeline CI/CD équilibre avec précision les ressources du projet dans le contexte des contraintes du projet.
Fiabilité améliorée. Les pipelines CI/CD gèrent la complexité de l'intégration logicielle où le travail de plusieurs développeurs doit être combiné. Ceci est réalisé à l'aide du test de certification d'intégration continue. Le test est composé de trois composants : des validations quotidiennes sur la branche principale, le déclenchement automatisé de la construction et du test, et la réparation de toute construction ayant échoué dans les dix minutes.
Rendre l'équipe plus attractive pour les développeurs. Les chances d'attirer des talents qualifiés peuvent être augmentées en mettant en œuvre le pipeline CI/CD, qui permet automatiquement aux équipes de répondre à 25 % des éléments du test Joel. Cela donne l'impression d'une équipe professionnelle et performante.
Les deux composantes de l'approche CI/CD
L'approche CI/CD comporte deux éléments essentiels. Bien qu'étroitement liés, chaque composant doit être incorporé par l'entreprise pour un effet maximal.
Voici un aperçu de chacun :
Intégration continue. L'automatisation fait partie intégrante d'un workflow de développement efficace et donne aux équipes de projet le temps de se concentrer sur ce qui est important. En effet, chaque tâche pouvant être automatisée devrait être automatique. Le test est l'un de ces processus. Ils doivent vérifier que les étapes qu'un client suivra dans un système fonctionnent, quelles que soient les modifications apportées. Cela donne aux membres de l'équipe la confiance nécessaire pour expérimenter, intégrer de nouvelles fonctionnalités, détecter les problèmes tôt et livrer rapidement.
Déploiement continu. Essentiellement, le déploiement continu est la publication de chaque bonne version qui passe des tests automatisés en production. Cela nécessite une capacité à mettre en production de nouvelles fonctionnalités, des modifications de configuration et des corrections de bogues. Surtout, cela doit être réalisé de manière sûre, durable et rapide en veillant à ce que le code soit toujours dans un état déployable. Cet état doit être maintenu face à de nombreux développeurs effectuant quotidiennement des centaines voire des milliers de modifications.
Différences entre les termes des composants de base et la formulation
De nombreux praticiens utilisent le déploiement continu de manière interchangeable avec un autre terme : livraison continue.
Cependant, il existe une différence de sens entre chaque terme. Comme nous l'avons vu, le déploiement continu concerne l'automatisation de la publication d'un bon build dans l'environnement de production. Certains préfèrent appeler ce composant « version continue » pour cette raison.
La livraison continue, d'autre part, vise à garantir que chaque bonne construction est potentiellement prête pour la production libérer. Idéalement, cela signifie que la construction est soumise à des tests d'acceptation par les utilisateurs.
Études de cas
Entreprise de développement de logiciels : CI/CD pour la livraison de logiciels agiles
Le défi : Une entreprise de développement de logiciels souhaite rationaliser son processus de développement de logiciels, réduire les interventions manuelles et garantir des versions logicielles fréquentes et fiables.
Application de CI/CD :
Intégration continue:
Les développeurs valident régulièrement les modifications de code dans un référentiel partagé.
Des pipelines de génération et de test automatisés sont déclenchés après chaque validation.
Les tests unitaires, les tests d'intégration et les contrôles de qualité du code sont automatiquement effectués.
Toute défaillance dans le pipeline déclenche des notifications immédiates à l'équipe de développement.
Déploiement continu :
Une fois que les modifications de code ont réussi tous les tests automatisés et contrôles de qualité, elles sont automatiquement déployées dans un environnement de test.
Des tests d'acceptation utilisateur automatisés (UAT) sont effectués dans l'environnement de test.
Si l'UAT réussit, les modifications sont automatiquement déployées dans l'environnement de production.
Une surveillance continue et des mécanismes de restauration automatisés sont en place pour résoudre tout problème de production.
Résultat: En mettant en œuvre CI/CD, la société de développement de logiciels obtient des versions logicielles plus rapides et plus fiables. Les développeurs peuvent se concentrer sur le codage tandis que les processus automatisés garantissent la qualité du code et minimisent les risques de déploiement.
Plateforme de commerce électronique : CI/CD pour le déploiement continu de fonctionnalités
Le défi : Un commerce électronique plateforme souhaite fournir en permanence de nouvelles fonctionnalités et mises à jour à sa boutique en ligne pour rester compétitif et réactif aux demandes des clients.
Application de CI/CD :
Intégration continue:
Les équipes de développement travaillent sur de nouvelles fonctionnalités dans les branches de fonctionnalités.
Les modifications du code sont continuellement intégrées dans la base de code principale.
Des tests automatisés, notamment des tests de charge et des analyses de sécurité, sont exécutés sur chaque intégration.
Les révisions de code et les commentaires des pairs sont intégrés au processus.
Déploiement continu :
Après une intégration et des tests réussis, les nouvelles fonctionnalités sont automatiquement déployées dans un environnement de test.
Des tests A/B sont effectués dans l'environnement de test pour évaluer l'impact des nouvelles fonctionnalités sur le comportement des utilisateurs.
Si les résultats sont positifs, les modifications sont automatiquement déployées dans l'environnement de production.
La surveillance et l'analyse en temps réel aident à suivre les performances des fonctionnalités et l'engagement des utilisateurs.
Résultat: Le commerce électronique plateforme obtient un avantage concurrentiel en fournissant continuellement de nouvelles fonctionnalités et mises à jour à ses utilisateurs. CI/CD permet une expérimentation et une adaptation rapides en fonction des commentaires des utilisateurs.
Fournisseur d'infrastructure cloud : CI/CD pour Infrastructure as Code (IaC)
Le défi : Un fournisseur d’infrastructure cloud souhaite gérer et mettre à jour sa vaste infrastructure de manière efficace et avec un minimum d’erreurs humaines.
Application de CI/CD :
Intégration continue:
Les modifications de l'infrastructure, définies sous forme de code, sont stockées dans des référentiels contrôlés par version.
Des tests automatisés et des scripts de validation sont exécutés pour garantir l'exactitude du code.
Des examens par les pairs sont effectués pour les modifications du code des infrastructures.
Les modifications de code sont fusionnées dans le référentiel principal.
Déploiement continu :
Les modifications d’infrastructure approuvées déclenchent un provisionnement et un déploiement automatisés.
Les mises à jour de l'infrastructure sont appliquées à divers centres de données et régions cloud.
Des contrôles de santé et des restaurations automatisés sont en place pour gérer tout problème lors du déploiement.
La surveillance en temps réel garantit les performances et la disponibilité de l'infrastructure.
Résultat: Le fournisseur d'infrastructure cloud gère et met à jour efficacement son infrastructure à l'aide de CI/CD pour Infrastructure as Code. Cette approche minimise les erreurs de configuration, réduit les temps d'arrêt et améliore la fiabilité de l'infrastructure.
Points clés
L'intégration continue/déploiement continu introduit l'automatisation dans le processus de développement logiciel pour aider les entreprises à rester compétitives.
Les pratiques d'intégration continue/déploiement continu sont collectivement connues sous le nom de pipeline CI/CD, qui est pris en charge par des approches agiles telles que DevOps.
L'intégration continue/déploiement continu est basé sur les deux composants principaux de l'intégration continue et du déploiement continu. Les deux travaillent ensemble pour garantir que l'automatisation - qui devrait être introduite dans la mesure du possible - est présente dans presque toutes les facettes du cycle de vie du produit.
Faits saillants
Comprendre l'intégration continue/le déploiement continu (CI/CD) : CI/CD automatise les étapes de développement de logiciels pour les livrer fréquemment aux clients. Il garantit une automatisation et une surveillance continues depuis les tests jusqu'au déploiement, réduisant ainsi les erreurs et les interventions humaines.
Pipeline CI/CD et avantages :
Le pipeline CI/CD gère la complexité de l’intégration logicielle et réduit les coûts.
Il améliore la fiabilité grâce à des tests d'intégration et de certification continus.
L'attractivité pour les développeurs est renforcée, mettant en valeur une équipe professionnelle.
Composants principaux de CI/CD :
Intégration continue: Automatisez des tâches telles que les tests pour garantir le bon fonctionnement des étapes du système, permettant ainsi l'expérimentation et une livraison rapide.
Déploiement continu : Publiez automatiquement les bonnes versions en production, en conservant un état déployable au milieu de multiples changements.
Différencier le déploiement continu et la livraison continue :
Déploiement continu : Automatise la publication des bonnes versions en production.
Livraison continue : Garantit que chaque bonne version est potentiellement prête pour la production, souvent soumise à des tests d'acceptation par les utilisateurs.
Principaux plats à emporter:
CI/CD introduit l'automatisation pour un développement logiciel compétitif.
Les pratiques CI/CD forment le pipeline CI/CD, pris en charge par DevOps.
Les composants de base incluent une intégration et un déploiement continus, favorisant l'automatisation tout au long du cycle de vie du produit.
AIOps est l'application de l'intelligence artificielle aux opérations informatiques. Il est devenu particulièrement utile pour la gestion informatique moderne dans des environnements hybrides, distribués et dynamiques. L'AIOps est devenu un composant opérationnel clé des organisations modernes basées sur le numérique, construit autour de logiciels et d'algorithmes.
Agile a commencé comme une méthode de développement légère par rapport au développement de logiciels lourds, qui est le paradigme central des décennies précédentes de développement de logiciels. En 2001, le Manifeste pour le développement logiciel agile est né comme un ensemble de principes définissant le nouveau paradigme du développement logiciel comme une itération continue. Cela influencerait également la façon de faire des affaires.
La gestion de programme agile est un moyen de gérer, de planifier et de coordonner des travaux interdépendants de manière à mettre l'accent sur la valeur ajoutée pour toutes les parties prenantes clés. La gestion de programme agile (AgilePgM) est une approche agile disciplinée mais flexible pour gérer le changement transformationnel au sein d'une organisation.
La gestion de projet agile (APM) est une stratégie qui décompose les grands projets en tâches plus petites et plus gérables. Dans la méthodologie APM, chaque projet est réalisé en petites sections - souvent appelées itérations. Chaque itération est complétée selon son cycle de vie de projet, en commençant par le DESIGN et passer aux tests puis à l'assurance qualité.
La modélisation agile (AM) est une méthodologie de modélisation et de documentation de systèmes logiciels. La modélisation agile est essentielle à la livraison rapide et continue de logiciels. Il s'agit d'un ensemble de valeurs, de principes et de pratiques qui guident une modélisation logicielle efficace et légère.
Agile Business Analysis (AgileBA) est une certification sous forme d'orientation et de formation pour les analystes commerciaux qui souhaitent travailler dans des environnements agiles. Pour soutenir ce changement, AgileBA aide également l'analyste métier à relier les projets Agile à une organisation plus large. mission or stratégie. Pour s'assurer que les analystes disposent des compétences et de l'expertise nécessaires, la certification AgileBA a été développée.
Le leadership agile est l'incarnation des principes du manifeste agile par un manager ou une équipe de direction. Le leadership agile a un impact sur deux niveaux importants d'une entreprise. Le niveau structurel définit les rôles, les responsabilités et les indicateurs de performance clés. Le niveau comportemental décrit les actions que les leaders montrent aux autres sur la base des principes agiles.
Le système andon alerte le personnel de gestion, de maintenance ou autre d'un problème de processus de production. L'alerte elle-même peut être activée manuellement avec un bouton ou un cordon, mais elle peut également être activée automatiquement par l'équipement de production. La plupart des cartes Andon utilisent trois lumières colorées similaires à un feu de circulation : vert (aucune erreur), jaune ou orange (problème identifié ou contrôle de qualité nécessaire) et rouge (production arrêtée en raison d'un problème non identifié).
La gestion de portefeuille bimodale (BimodalPfM) aide une organisation à gérer simultanément des portefeuilles agiles et traditionnels. La gestion de portefeuille bimodale - parfois appelée développement bimodal - a été inventée par la société de recherche et de conseil Gartner. L'entreprise a fait valoir que de nombreuses organisations agiles avaient encore besoin de gérer certains aspects de leurs opérations en utilisant des modèles de livraison traditionnels.
La Brochure innovation consiste à créer de nouvelles opportunités pour une organisation de réinventer ses offres de base, ses sources de revenus et d'améliorer la proposition de valeur pour les clients existants ou nouveaux, renouvelant ainsi l'ensemble de son activité modèle. Affaires innovation découle de la compréhension de la structure du marché, adaptant ou anticipant ainsi ces changements.
La Brochure modèleinnovation consiste à accroître le succès d'une organisation avec des produits et des technologies existants en créant un proposition de valeur capable de propulser un nouveau modèle d'affaires pour augmenter la clientèle et créer un avantage concurrentiel durable. Et tout commence par la maîtrise des clients clés.
Un consommateur brand Une entreprise comme Procter & Gamble (P&G) définit la « perturbation constructive » comme : une volonté de changer, de s'adapter et de créer de nouvelles tendances et technologies qui façonneront notre industrie pour l'avenir. Selon P&G, il s'articule autour de quatre piliers : lean innovation, brand bâtiment, chaîne d'approvisionnement, numérisation et analyse de données.
C'est un processus qui nécessite une boucle de rétroaction continue pour développer un produit de valeur et créer une entreprise viable. modèle. Continu innovation est un état d'esprit où les produits et services sont conçus et livrés pour les ajuster autour du problème des clients et non de la solution technique de ses fondateurs.
A DESIGN sprint est un processus éprouvé de cinq jours où les questions critiques de l'entreprise reçoivent une réponse rapide DESIGN et le prototypage, en se concentrant sur l'utilisateur final. UN DESIGN le sprint commence par un défi hebdomadaire qui devrait se terminer par un prototype, un test à la fin, et donc une leçon apprise à itérer.
Tim Brown, président exécutif d'IDEO, a défini DESIGN comme « une approche centrée sur l'humain innovation qui s'inspire de la boîte à outils du concepteur pour intégrer les besoins des personnes, les possibilités de la technologie et les exigences du succès de l'entreprise. Par conséquent, l'opportunité, la faisabilité et la viabilité sont équilibrées pour résoudre les problèmes critiques.
DevOps fait référence à une série de pratiques exécutées pour effectuer des processus de développement de logiciels automatisés. Il s'agit d'une conjugaison des termes « développement » et « opérations » pour souligner la manière dont les fonctions s'intègrent dans les équipes informatiques. Les stratégies DevOps favorisent la création, le test et le déploiement transparents des produits. Il vise à combler un fossé entre les équipes de développement et d'exploitation afin de rationaliser le développement dans son ensemble.
La découverte de produits est un élément essentiel des méthodologies agiles, car son objectif est de s'assurer que les produits que les clients adorent sont créés. La découverte de produits implique l'apprentissage à travers une série de méthodes, y compris DESIGN la réflexion, le lean start-up et les tests A/B pour n'en nommer que quelques-uns. Dual Track Agile est une méthodologie agile contenant deux pistes distinctes : la piste « découverte » et la piste « livraison ».
eXtreme Programming a été développé à la fin des années 1990 par Ken Beck, Ron Jeffries et Ward Cunningham. Pendant ce temps, le trio travaillait sur le Chrysler Comprehensive Compensation System (C3) pour aider à gérer le système de paie de l'entreprise. eXtreme Programming (XP) est une méthodologie de développement logiciel. Il est conçu pour améliorer la qualité des logiciels et la capacité des logiciels à s'adapter aux besoins changeants des clients.
Le développement piloté par les fonctionnalités est un processus logiciel pragmatique centré sur le client et l'architecture. Le développement piloté par les fonctionnalités (FDD) est un développement logiciel agile modèle qui organise le flux de travail en fonction des fonctionnalités à développer ensuite.
Un Gemba Walk est un élément fondamental du lean management. Il décrit l'observation personnelle du travail pour en savoir plus sur celui-ci. Gemba est un mot japonais qui se traduit vaguement par « l'endroit réel » ou, dans le monde des affaires, « l'endroit où la valeur est créée ». Le Gemba Walk en tant que concept a été créé par Taiichi Ohno, le père du système de production Toyota de fabrication allégée. Ohno voulait encourager les cadres dirigeants à quitter leurs bureaux et à voir où se passait le vrai travail. Cela, espérait-il, établirait des relations entre des employés aux compétences très différentes et renforcerait la confiance.
GIST Planning est une approche agile relativement simple et légère de la planification des produits qui favorise le travail autonome. GIST Planning est une méthodologie allégée et agile qui a été créée par l'ancien chef de produit Google Itamar Gilad. GIST Planning cherche à remédier à cette situation en créant des plans légers, réactifs et adaptables au changement. GIST Planning améliore également la vélocité, l'autonomie et l'alignement de l'équipe en réduisant l'influence omniprésente de la direction. Il se compose de quatre blocs : objectifs, idées, projets par étapes et tâches.
Le modèle de notation ICE est une méthodologie agile qui hiérarchise les fonctionnalités à l'aide de données selon trois composants : impact, confiance et facilité de mise en œuvre. Le modèle de notation ICE a été initialement créé par l'auteur et augmentation l'expert Sean Ellis pour aider les entreprises à se développer. Aujourd'hui le modèle est largement utilisé pour hiérarchiser les projets, les fonctionnalités, les initiatives et les déploiements. Il convient parfaitement au développement de produits à un stade précoce où il existe un flux continu d'idées et où l'élan doit être maintenu.
An innovation l'entonnoir est un outil ou un processus garantissant que seules les meilleures idées sont exécutées. Dans un sens métaphorique, l'entonnoir sélectionne des idées innovantes pour la viabilité afin que seuls les meilleurs produits, processus ou modèles d'affaires sont lancés sur le marché. Un innovation funnel fournit un cadre pour la sélection et le test d'idées innovantes pour la viabilité.
Selon le niveau de définition du problème et le niveau de définition du domaine, nous avons quatre principaux types d'innovations : la recherche fondamentale (problème et domaine ou non bien définis) ; percée innovation (le domaine n'est pas bien défini, le problème est bien défini) ; soutenir innovation (le problème et le domaine sont bien définis); et perturbateur innovation (le domaine est bien défini, le problème n'est pas bien défini).
La innovation loop est une méthodologie/un cadre dérivé des Bell Labs, qui a produit innovation à grande échelle tout au long du XXe siècle. Ils ont appris à tirer parti d'un hybride innovation gestion modèle basée sur la science, l'invention, l'ingénierie et la fabrication à grande échelle. En tirant parti du génie individuel, de la créativité et des petits/grands groupes.
La méthodologie Agile a été principalement pensée pour le développement de logiciels (et d'autres disciplines commerciales l'ont également adoptée). La pensée Lean est une technique d'amélioration des processus où les équipes priorisent les flux de valeur pour l'améliorer en permanence. Les deux méthodologies considèrent le client comme le principal moteur de l'amélioration et de la réduction des déchets. Les deux méthodologies considèrent l'amélioration comme quelque chose de continu.
Une start-up est une entreprise de haute technologie qui essaie de construire une entreprise évolutive modèle d'affaires dans les industries axées sur la technologie. Une start-up suit généralement une méthodologie Lean, où la innovation, entraîné par des boucles virales intégrées est la règle. Ainsi, la conduite augmentation et la construction effets de réseau en conséquence de cela stratégie.
Comme l'a souligné Eric Ries, un produit minimum viable est la version d'un nouveau produit qui permet à une équipe de collecter le maximum d'apprentissage validé sur les clients avec le moins d'effort grâce à un cycle de construction, mesure, apprentissage ; c'est le fondement de la démarrage maigre méthodologie.
Kanban est un cadre de fabrication allégée développé pour la première fois par Toyota à la fin des années 1940. Le cadre Kanban est un moyen de visualiser le travail au fur et à mesure qu'il progresse en identifiant les goulots d'étranglement potentiels. Il le fait grâce à un processus appelé fabrication juste à temps (JIT) pour optimiser les processus d'ingénierie, accélérer la fabrication des produits et améliorer la mise sur le marché. stratégie.
Le jidoka a été utilisé pour la première fois en 1896 par Sakichi Toyoda, qui a inventé un métier à tisser textile qui s'arrêtait automatiquement lorsqu'il rencontrait un fil défectueux. Jidoka est un terme japonais utilisé dans le lean manufacturing. Le terme décrit un scénario dans lequel les machines cessent de fonctionner sans intervention humaine lorsqu'un problème ou un défaut est découvert.
Le cycle PDCA (Plan-Do-Check-Act) a été proposé pour la première fois par le physicien et ingénieur américain Walter A. Shewhart dans les années 1920. Le cycle PDCA est une méthode d'amélioration continue des processus et des produits et un élément essentiel de la philosophie de fabrication au plus juste.
Le processus unifié rationnel (RUP) est une méthodologie de développement logiciel agile qui décompose le cycle de vie du projet en quatre phases distinctes.
RAD a été introduit pour la première fois par l'auteur et consultant James Martin en 1991. Martin a reconnu et a ensuite profité de l'infinie malléabilité des logiciels dans la conception de modèles de développement. Le développement rapide d'applications (RAD) est une méthodologie axée sur la livraison rapide grâce à une rétroaction continue et à des itérations fréquentes.
Des analyses rétrospectives ont lieu après un projet pour déterminer ce qui a bien fonctionné et ce qui n'a pas fonctionné. Ils sont également menés à l'issue d'une itération en gestion de projet Agile. Les praticiens agiles appellent ces réunions des rétrospectives ou des rétrospectives. Ils sont un moyen efficace de prendre le pouls d'une équipe de projet, de réfléchir au travail effectué à ce jour et de parvenir à un consensus sur la manière d'aborder le prochain cycle de sprint. Ce sont les cinq étapes d'une rétrospective selon une analyse de l’Université de Princeton pour une gestion de projet Agile efficace : préparez le terrain, rassemblez les données, générez des idées, décidez des prochaines étapes et clôturez la rétrospective.
Scaled Agile Lean Development (ScALeD) aide les entreprises à découvrir une approche équilibrée de la transition agile et des questions de mise à l'échelle. L'approche ScALed aide les entreprises à répondre avec succès au changement. Inspiré par une combinaison de valeurs lean et agiles, ScALed est basé sur les praticiens et peut être complété par divers cadres et pratiques agiles.
La méthode SMED (single minute exchange of die) est un cadre de production allégée pour réduire les déchets et augmenter l'efficacité de la production. La méthode SMED est un cadre pour réduire le temps associé à l'achèvement d'un changement d'équipement.
Le modèle Spotify est une approche autonome de mise à l'échelle agile, axée sur la communication culturelle, la responsabilité et la qualité. Le Spotify modèle a été reconnu pour la première fois en 2012 après Henrik Kniberg, et Anders Ivarsson a publié un livre blanc détaillant comment la société de streaming Spotify a abordé l'agilité. Par conséquent, le Spotify modèle représente une évolution de l'agile.
Comme son nom l'indique, TDD est une technique pilotée par les tests pour fournir rapidement et durablement des logiciels de haute qualité. Il s'agit d'une approche itérative basée sur l'idée qu'un test défaillant doit être écrit avant l'écriture de tout code pour une fonctionnalité ou une fonction. Le développement piloté par les tests (TDD) est une approche du développement logiciel qui s'appuie sur des cycles de développement très courts.
Le timeboxing est une technique de gestion du temps simple mais puissante pour améliorer la productivité. Timeboxing décrit le processus de planification proactive d'un bloc de temps à consacrer à une tâche dans le futur. Il a été décrit pour la première fois par l'auteur James Martin dans un livre sur le développement logiciel agile.
Scrum est une méthodologie co-créée par Ken Schwaber et Jeff Sutherland pour une collaboration d'équipe efficace sur des produits complexes. Scrum a été principalement pensé pour les projets de développement de logiciels afin de fournir de nouvelles capacités logicielles toutes les 2 à 4 semaines. C'est un sous-groupe d'agile également utilisé dans la gestion de projet pour améliorer la productivité des startups.
Scrumban est un cadre de gestion de projet qui est un hybride de deux méthodologies agiles populaires : Scrum et Kanban. Scrumban est une approche populaire pour aider les entreprises à se concentrer sur les bonnes tâches stratégiques tout en renforçant simultanément leurs processus.
Les anti-modèles Scrum décrivent toute solution attrayante et facile à mettre en œuvre qui finit par aggraver un problème. Par conséquent, ce sont les pratiques à ne pas suivre pour éviter que des problèmes n'apparaissent. Certains exemples classiques d'anti-modèles Scrum comprennent les Product Owners absents, les tickets pré-assignés (faisant travailler les individus de manière isolée) et les rétrospectives à prix réduits (où les réunions de revue ne sont pas utiles pour vraiment apporter des améliorations).
Scrum à l'échelle (Scrum@Scale) est un cadre que les équipes Scrum utilisent pour résoudre des problèmes complexes et fournir des produits à haute valeur ajoutée. Scrum at Scale a été créé par le biais d'une joint-venture entre Scrum Alliance et Scrum Inc. La joint-venture était supervisée par Jeff Sutherland, co-créateur de Scrum et l'un des principaux auteurs du Manifeste Agile.
Six Sigma est une approche et une méthodologie axées sur les données pour éliminer les erreurs ou les défauts dans un produit, un service ou un processus. Six Sigma a été développé par Motorola comme une approche de gestion basée sur des fondamentaux de qualité au début des années 1980. Une décennie plus tard, elle a été popularisée par General Electric qui a estimé que la méthodologie leur avait permis d'économiser 12 milliards de dollars au cours des cinq premières années d'exploitation.
Les objectifs étendus décrivent toute tâche qu'une équipe agile prévoit d'accomplir sans s'engager expressément à le faire. Les équipes intègrent des objectifs étendus lors d'un sprint ou d'un incrément de programme (PI) dans le cadre de Scaled Agile. Ils sont utilisés lorsque l'équipe agile n'est pas sûre de sa capacité à atteindre un objectif. Par conséquent, les objectifs étendus sont plutôt des résultats qui, bien qu'extrêmement souhaitables, ne font pas la différence entre le succès ou l'échec de chaque sprint.
Le système de production Toyota (TPS) est une forme précoce de fabrication allégée créée par le constructeur automobile Toyota. Créé par Toyota Motor Corporation dans les années 1940 et 50, le système de production Toyota vise à fabriquer les véhicules commandés par les clients le plus rapidement et le plus efficacement possible.
Le cadre de gestion de la qualité totale (TQM) est une technique basée sur le principe que les employés travaillent en permanence sur leur capacité à apporter de la valeur aux clients. Il est important de noter que le mot « total » signifie que tous les employés sont impliqués dans le processus, qu'ils travaillent dans le développement, la production ou l'exécution.
La cascade modèle a été décrit pour la première fois par Herbert D. Benington en 1956 lors d'une présentation sur le logiciel utilisé dans l'imagerie radar pendant la guerre froide. Puisqu'il n'existait pas à l'époque de stratégies de développement de logiciels créatives et basées sur les connaissances, la méthode en cascade est devenue une pratique courante. La cascade modèle est un cadre de gestion de projet linéaire et séquentiel.
Gennaro est le créateur de FourWeekMBA, qui a atteint environ quatre millions d'hommes d'affaires, comprenant des cadres de niveau C, des investisseurs, des analystes, des chefs de produit et des entrepreneurs numériques en herbe rien qu'en 2022 | Il est également directeur des ventes pour une mise à l'échelle de haute technologie dans l'industrie de l'IA | En 2012, Gennaro a obtenu un MBA international avec un accent sur la finance d'entreprise et la stratégie commerciale.
Découvrez plus de FourWeekMBA
Abonnez-vous maintenant pour continuer à lire et accéder aux archives complètes.
