Comment une informatique agile peut-elle transformer l'industrie informatique?

Auteur: Roger Morrison
Date De Création: 20 Septembre 2021
Date De Mise À Jour: 5 Peut 2024
Anonim
Comment une informatique agile peut-elle transformer l'industrie informatique? - La Technologie
Comment une informatique agile peut-elle transformer l'industrie informatique? - La Technologie

Contenu



Source: Darkovujic / Dreamstime.com

À emporter:

Pour beaucoup, le modèle de développement logiciel en cascade est la norme depuis des décennies, mais il est maintenant remplacé par la méthodologie Agile, beaucoup plus flexible.

La méthodologie Agile pour le développement de logiciels peut avoir un impact positif sur l'industrie informatique. Les résultats de l’adoption d’une méthodologie Agile peuvent être mesurés de différentes manières. La rapidité d'exécution des demandes de modification logicielle, la réduction du nombre de bugs, la mesure quantitative des performances de l'équipe et les goulots d'étranglement sont autant de reflets de la mise en œuvre réussie de Agile. Pour mesurer avec succès l'impact de l'agilité, une organisation doit comparer diverses mesures liées au développement pré-agile et post-agile. L'impact réel de Agile ne peut être mesuré uniquement par l'augmentation des revenus ou par le nombre croissant de bugs corrigés. Plusieurs paramètres internes doivent être pris en compte pour comprendre l'impact réel. (Pour plus d'informations sur le développement agile, voir Développement de logiciel agile 101.)


Pourquoi une informatique agile?

L’industrie informatique s’est tournée vers les pratiques Agiles, principalement en raison des contraintes imposées par le modèle de développement logiciel en cascade. De manière générale, il a été observé que les entreprises informatiques ne sont pas en mesure de répondre aux demandes changeantes des clients ou de la situation du marché, ni de réduire les coûts avec le modèle de développement logiciel en cascade. Même si nous contrebalançons cette inclination écrasante en faveur de la méthodologie Agile et considérons que l'excitation n'est que du battage médiatique, il existe de nombreuses réactions empiriques à l'encontre du modèle en cascade.

En termes simples, le modèle en cascade est un modèle de développement logiciel dans lequel le travail est effectué de manière séquentielle - une phase après l'autre. Ce modèle comporte cinq phases: les exigences, la conception, la mise en œuvre, la vérification et la maintenance. Habituellement, une fois qu'une phase est terminée, il est difficile, voire impossible, d'apporter des modifications à une phase antérieure. Donc, l'hypothèse est que les exigences sont à peu près fixes. La principale différence avec le modèle Agile réside dans l'hypothèse qu'il n'y aura pas de changement dans les exigences. Agile suppose que les situations commerciales vont changer, de même que les exigences. Ainsi, les logiciels sont livrés en plus petits morceaux sur SS, alors que dans le modèle en cascade, la première livraison ou publication est faite après une longue période. (Pour en savoir plus sur le développement, voir Comment Apache Spark contribue au développement rapide d'applications.)


La critique la plus notable contre le modèle en cascade est son hypothèse selon laquelle les exigences ne changeront pas. La supposition même est imparfaite et irréaliste. Par exemple, en 2001, une étude portant sur 1 027 projets informatiques au Royaume-Uni a montré que cette hypothèse était la principale raison de l'échec des projets informatiques.

Dans un autre exemple, Craig Larman, l'auteur du livre "Développement agile et itératif: un guide pour les gestionnaires", a souligné qu'un certain nombre de projets exécutés par le Département de la défense (DoD) à l'aide du modèle de cascade aux États-Unis ont échoué. atteindre leurs objectifs. Au cours des années 1980 et 1990, le DoD a dû utiliser le modèle en cascade pour ses projets de développement de logiciels conformément aux normes publiées dans DoD STD 2167. Des statistiques choquantes ont révélé que 75% de ces projets de logiciels n'étaient jamais utilisés. À la suite de ce rapport, un groupe de travail a été créé sous l’égide du Dr Frederick Brooks, un expert reconnu en génie logiciel. Le groupe de travail a publié un rapport dans lequel il commentait: «Le DoD STD 2167 a également besoin d'une refonte radicale pour refléter les meilleures pratiques modernes. Le développement évolutif est le meilleur techniquement, il permet d'économiser du temps et de l'argent. "

Les quatre hypothèses suivantes du modèle en cascade avaient échoué dans des scénarios réels:

  • Les exigences données sont raisonnablement bien définies et ne changeront donc pas de manière significative.
  • Même si les exigences changent pendant la phase de développement, elles seront suffisamment petites pour être prises en compte dans le cycle de développement.
  • L'intégration du système, qui survient après la livraison du logiciel, se déroulera comme prévu.
  • L'innovation logicielle et les efforts nécessaires pour innover se dérouleront selon un calendrier planifié et prévisible.

Comment la méthodologie Agile résout-elle les problèmes du modèle en cascade?

La méthodologie Agile est fondamentalement différente du modèle en cascade et cela ressort clairement de ses hypothèses:

  • Personne, pas même le client, ne peut connaître ou comprendre les exigences. Il n'y a aucune garantie que les exigences ne changeront pas.
  • Les modifications apportées aux exigences peuvent ne pas être petites et gérables. En fait, ils viendront dans différentes tailles et continueront à venir. Le logiciel sera donc livré par petits incréments pour suivre les modifications.

Comment Agile a-t-il impacté l'industrie informatique?

Agile est adopté dans de nombreux endroits, tandis que de nombreuses entreprises envisagent de le faire. Bien qu'Agile ait définitivement apporté des changements fondamentaux au secteur des technologies de l'information, les faits et les chiffres restent difficiles à obtenir. Mais l'impact de Agile peut être compris avec l'étude de cas de British Telecom (BT) donnée ci-dessous.

Pas de bugs, pas de stress - Votre guide étape par étape pour créer un logiciel qui change la vie sans vous détruire


Vous ne pouvez pas améliorer vos compétences en programmation lorsque personne ne se soucie de la qualité des logiciels.

Raisons pour lesquelles BT a adopté des pratiques agiles

BT a commencé à connaître un certain nombre de problèmes avec ses pratiques de développement logiciel en 2004. BT a développé un certain nombre de projets logiciels simples et complexes. De nombreux projets logiciels n’ont pas été en mesure d’obtenir des résultats de qualité dans les délais convenus. BT a constaté que les problèmes tenaient au modèle en cascade. Donc, renforcer le modèle de cascade ne va pas aider. Les principales causes des problèmes sont indiquées ci-dessous:

Mauvaise gestion des besoins

  • Trop d'exigences ont été données pour être remplies dans un délai trop court.
  • De nombreuses exigences étaient sans rapport avec les besoins de l'entreprise.
  • Presque toutes les exigences, sinon toutes, ont reçu un statut de priorité élevée.
  • Les exigences représentaient les besoins commerciaux actuels sans se soucier des scénarios futurs. Cela laissait ouverte une possibilité de modifications futures du logiciel.

Mauvaise conception du logiciel

  • Compte tenu du grand nombre d'exigences, les concepteurs ont passé trop de temps à essayer de comprendre ce que signifiaient les exigences. Peu de temps a été laissé pour la conception réelle.
  • Les analystes des besoins se sont ensuite tournés vers d'autres tâches, emportant avec eux des connaissances tacites et non écrites.
  • Les deux facteurs ci-dessus ont entraîné une mauvaise conception. Les concepteurs devaient toujours livrer dans les délais.

Contraintes de développement

Le codage était rapide et de qualité médiocre à cause d'une conception logicielle imparfaite. Les développeurs se rendraient compte qu'une mauvaise conception de logiciel aboutirait à un code médiocre, mais devaient néanmoins être livrés dans les délais convenus. De nombreux bogues seraient signalés lors de l'intégration car les tests unitaires et les tests de régression n'avaient pas été exécutés.

Au moment du déploiement du logiciel, le client note que les exigences ont déjà changé, de même que le scénario de gestion. Le logiciel a aussi beaucoup de problèmes. En réalité, tout l’effort de développement logiciel est maintenant considéré comme un gaspillage.

Qu'est-ce que BT a fait pour résoudre les problèmes susmentionnés?

BT s'est rendu compte que le renforcement du modèle en cascade n'était pas la solution aux problèmes. Il fallait une nouvelle approche. Alors, il a décidé de mettre en œuvre l'approche Agile. Sous la nouvelle approche, les choses suivantes ont été décidées:

  • Au lieu du cycle de développement de 12 mois, BT proposerait désormais des logiciels exploitables dans un cycle de 90 jours. L'idée était de se concentrer sur un ou deux problèmes de l'entreprise et de proposer une solution logicielle dans un délai de 90 jours. Le début de ce cycle a été marqué par une intense discussion entre les différentes parties prenantes afin que les exigences soient clairement identifiées, analysées et hiérarchisées.
  • L’objectif était de fournir des valeurs commerciales claires et concrètes. Le client interne était sous pression pour fournir des exigences claires. Ainsi, au lieu d'objectifs vagues, des user stories ont été données avec des critères d'acceptation clairs.
  • Le logiciel qui serait livré serait entièrement testé et documenté. Le logiciel passerait par de fréquents tests d'intégration pour identifier les problèmes à l'avance.

Avec l’approche Agile, BT pourrait s’adapter plus facilement à l’évolution des besoins ou à la situation des entreprises. La qualité du code s'est améliorée et les bugs de base de dernière minute ont été corrigés.

Conclusion

Agile, malgré tous ses avantages et le battage publicitaire qui l’entoure, en est encore à un stade où son potentiel n’est pas pleinement exploité. En effet, de nombreuses organisations adaptent l'approche de manière à en modifier les principes d'origine. En conséquence, le modèle en cascade fait son retour dans certains cas. Bien que la personnalisation se poursuive, il est important de conserver les principes de base Agiles. De nombreuses organisations prétendent être totalement agiles, mais elles ont encore du chemin à faire pour devenir une entreprise véritablement agile.