Fermer

mars 4, 2024

Six points pour faire progresser le développement agile

Six points pour faire progresser le développement agile



Plus de 60 % des entreprises ont adopté le développement agile

Depuis la pandémie de coronavirus, les grandes entreprises font toutes la promotion du DX. La numérisation est un élément essentiel permettant aux entreprises d’améliorer leur productivité, la satisfaction de leurs clients et de réduire leurs coûts dans un contexte de changements sociaux rapides.

Le développement de systèmes, qui constitue la pierre angulaire de ces stratégies DX, subit des changements majeurs dans les méthodes de développement en raison de la propagation d’Internet et du cloud computing.

Jusqu’à présent, le développement du système était réalisé à l’aide d’une méthode en cascade, qui implique la définition des exigences, la conception, le développement et les tests.

Cependant, récemment, l’attention s’est portée sur une méthode de développement appelée AJAL, qui divise le développement en unités plus petites et poursuit le développement en répétant la mise en œuvre et les tests pour chaque unité.

Selon une enquête sur l’état d’adoption de l’agilité menée par Gartner, l’une des principales sociétés de recherche technologique au monde, du 10 au 12 juillet 2023 (ciblant 400 entreprises), 17,5 % des entreprises ont répondu « tout développement est agile », 44,3 % des les entreprises ont répondu qu’elles « utilisent en partie le développement agile », indiquant que plus de 60 % des entreprises ont déjà introduit le développement agile.

« Le développement agile est en plein essor depuis plusieurs années. Les grandes entreprises ayant de nombreux projets de développement, il n’est plus rare que certains projets utilisent le développement agile. En effet, il est nécessaire de réagir rapidement aux changements. Je pense qu’il existe un désir de développer plus rapidement et à moindre coût avec le développement agile.Cependant, il est difficile de développer soudainement quelque chose qui a été développé en utilisant Waterfall en utilisant Agile.Je pense que de telles méthodes attirent l’attention sur de nouvelles pièces, de nouvelles applications, etc. il existe également des cas où le développement agile est envisagé dans des domaines qui étaient auparavant considérés comme non adaptés au développement agile. Masu »

Harutoshi Katayama, analyste directeur principal chez Gartner Japon, explique :

« Qu’est-ce que le développement agile ? »

Tout d’abord, qu’est-ce que le développement agile ? M. Katayama dit qu’il s’agit « d’une approche (méthode de développement) pour se rapprocher de la bonne réponse sans connaître la bonne réponse ».

La principale caractéristique est que la valeur (valeur commerciale) est réalisée par essais et erreurs grâce à des méthodes incrémentielles et itératives.

Concernant la différence entre le développement d’une cascade et le développement d’une cascade, M. Katayama a déclaré : « Dans le développement traditionnel d’une cascade, le projet est réalisé en sous-traitance, et une fois le projet terminé, l’équipe est dissoute. Vous ne savez pas ce qui va se passer ensuite. .En revanche, avec l’agile « Lors du développement, nous procédons étape par étape et de manière itérative afin de nous rapprocher de la bonne réponse, afin de pouvoir vérifier les résultats au fur et à mesure. Je pense que la principale caractéristique est que nous n’avons pas pour continuer à faire des choses. »

M. Katayama classe l’agilité en quatre modèles.

La première méthode consiste à répéter le développement dans un court laps de temps. Nous construisons une période appelée timebox basée sur une à deux semaines (la période est déterminée par le projet), solidifions un sprint pour la conception, le développement et la publication des spécifications pour chaque timebox, et développons en répétant ce processus plusieurs fois. méthode pour le faire. Il est souvent utilisé dans le cadre du Lean Development (une application de la méthode de production de Toyota), qui élimine les déchets du processus de fabrication et ne laisse que le nécessaire.

Le deuxième modèle consiste à répéter le processus en amont petit à petit. Il s’agit d’une méthode dans laquelle la partie définition des exigences est répétée et discutée, et le processus de développement se déroule en cascade. Il est utilisé dans le design thinking, qui découvre les problèmes et les besoins essentiels des services et des produits du point de vue de l’utilisateur et résout les problèmes commerciaux.

La troisième méthode consiste à créer un prototype après avoir défini et conçu les exigences, et à l’améliorer de manière répétée tout en recevant les commentaires des utilisateurs. Il s’agit d’une méthode utilisée lors de l’adoption de logiciels packagés, etc., et a été utilisée par les grandes compagnies aériennes lors de l’introduction des systèmes de réservation et de billetterie utilisés à l’étranger.

La quatrième méthode consiste à décider d’abord de la définition des exigences et de la conception générale, puis à les développer à la manière de Satsuki sur une base fonctionnelle et opérationnelle. Il est utilisé dans le développement à grande échelle tel que le développement de systèmes de base. Cette méthode a été utilisée par une grande société immobilière lorsqu’elle a intégré et amélioré ses systèmes métiers de gestion de copropriété et de gestion des ventes, et elle a également été utilisée par une grande compagnie d’assurance non-vie lors de la restructuration de son système d’assurance responsabilité civile automobile obligatoire.

 » Au cours de la discussion, il y a une opinion selon laquelle le numéro 1 est authentique, mais les numéros 2 à 4 sont faux, mais du point de vue de la poursuite du projet, il n’y a pas d’authentique ou de faux. Tout ce que vous avez à faire est de faire, c’est choisir une méthode.Récemment, le développement du low-code, du no-code, etc. progresse.Il semble qu’il ne soit pas rare que ces méthodes de développement combinent les deuxième et troisième méthodes. » (M. Katayama) )

Agile a l’image d’être « bon marché » et « rapide », mais ce n’est pas forcément le cas.

« En Agile, le développement se déroule par essais et erreurs, mais en Waterfall, le développement se déroule étape par étape, donc lors du développement d’un système d’une certaine échelle, le développement Agile prend plus d’heures de travail que Waterfall. (Dans les cas où les objectifs sont clairs et le processus est hautement prévisible), le simple fait de passer des méthodes en cascade aux méthodes agiles peut en fait augmenter les coûts. C’est vrai. » (M. Katayama)

Points à garder à l’esprit lors du démarrage du développement agile

Alors, à quoi devons-nous faire attention lorsque nous procédons au développement agile ? M. Katayama a soulevé six points.

  • Avoir une compréhension commune de « Pourquoi Agile ? »
  • Ne négligez pas la qualité
  • Mettre en place un système de prise de décision rapide
  • Surmonter les bloqueurs externes (en dehors du projet)
  • Coordonner avec les autres équipes (Waterfall, etc.)
  • Mettre en place un système de formation du personnel inexpérimenté

Jetons un coup d’œil à chacun.

Agile est un concept très connu, mais il existe de nombreuses interprétations différentes. L’interprétation diffère selon l’interprétation. Si les parties prenantes telles que les développeurs et les utilisateurs ont des images complètement différentes de l’Agile, les résultats souhaités seront naturellement différents.

Les personnes qui recherchent « bon marché » et « rapide » et celles qui recherchent « ce dont elles ont besoin » obtiennent naturellement des résultats différents. « J’ai entendu dire que même si vous faites quelque chose d’agile et obtenez ce dont vous avez besoin, ce n’est ni bon marché ni rapide, donc une entreprise interrompra temporairement le développement agile. » (M. Katayama)

On peut en dire autant des délais. Si Agile est « une approche pour se rapprocher de la bonne réponse sans connaître la bonne réponse » et que la valeur est réalisée au travers de petites itérations, la question se pose de savoir où se situe le délai.

En cascade, lorsqu’un projet est terminé, il est transformé en produit puis dissous, mais agile s’apparente davantage à un processus de développement de produit dans lequel le produit est continuellement amélioré, plutôt qu’à un projet. Il est également nécessaire d’avoir une solide compréhension de la question en tant que compréhension commune.

Il est important d’avoir une compréhension commune de l’Agile entre les parties prenantes afin d’éviter de développer différents projets au même niveau.

Agile est une approche permettant de se rapprocher de la bonne réponse sans connaître la bonne réponse, de sorte que certains échecs peuvent survenir.

Toutefois, cela ne signifie pas qu’il faille négliger la qualité.

« Le logiciel en cours de sortie doit fonctionner correctement et il ne doit pas être publié avec de nombreux bugs. Le contrôle de la qualité est plus difficile que la cascade car la qualité doit être contrôlée dans un court laps de temps.  » (M. Katayama)

Les pratiques commerciales existantes sont l’ennemi de l’agilité

Pensons ensuite à « la mise en place d’un système permettant une prise de décision rapide ». Lors du développement de logiciels utilisant Agile, les décideurs du côté métier qui les utiliseront, les dirigeants du côté des développeurs (internes ou externes) et la haute direction de l’entreprise et de l’informatique dans son ensemble partagent toujours des problèmes et prendre des décisions agiles. Je dois décider. Il est important de ne pas rater l’occasion.

« Avec Agile, le développement progresse dans un laps de temps court, les décisions doivent donc être prises rapidement. Avec Waterfall, il y a des réunions hebdomadaires et mensuelles avec les parties prenantes, et les décisions sur les problèmes majeurs sont prises. Je pense que les décisions sont souvent prises une fois par semaine. mois.Même lors des réunions mensuelles, si les membres ne parvenaient pas à se coordonner, il n’y avait aucun problème à reporter cela au mois suivant.En conséquence, la prise de décision était souvent retardée.Récemment, des outils tels que la vidéoconférence sont devenus disponibles, donc il est possible d’accélérer la prise de décision par les cadres supérieurs, et il est important d’accélérer la prise de décision. » (M. Katayama)

Dans le développement agile, il existe divers obstacles externes au projet. Jusqu’à présent, le développement de systèmes au Japon reposait sur des fournisseurs externes, ce qui est devenu la norme, et de nombreuses entreprises ont établi des règles internes basées sur la méthode traditionnelle en cascade.

« Les entreprises ont différentes règles de développement. Certaines règles peuvent supposer une pure approche en cascade. Nous ne pouvons même pas lancer un projet s’il ne respecte pas les réglementations telles que les budgets et les documents d’approbation. C’est un problème qui doit être résolu lors de la promotion de l’agilité. développement en tant qu’entreprise. » (M. Katayama)

Dans certaines entreprises, le service « achats » autorise uniquement le développement sur une base contractuelle, tandis que dans d’autres entreprises, les exigences changeantes, comme le développement agile, sont un non-non en raison de considérations « budgétaires ».

Même en comptabilité, il n’existe pas de comptabilité spécialisée pour agile. Par conséquent, la comptabilité doit être effectuée conformément aux normes comptables en vigueur, mais le calendrier et la portée de l’enregistrement des logiciels en tant qu’actifs sont difficiles.

Un autre problème avec les ressources humaines est que les normes du personnel du service informatique ne correspondent pas au système d’évaluation des ressources humaines agiles.

« Une personne dans une entreprise a déclaré que le plus grand obstacle au développement agile était l’approvisionnement, qui est responsable des contrats d’externalisation. Les gens disent que ce n’est pas bon parce que c’est différent des cascades traditionnelles. J’ai entendu des histoires de personnes disant que cela prenait trois mois pour mettre en place un système, et que s’ils avaient pris autant de temps, ils auraient déjà pu avoir un système en place. L’important est de savoir comment se coordonner avec les règles existantes de l’entreprise. (M. Katayama)

La clé du succès est de savoir si vous parvenez à surmonter votre tendance à jeter les choses.

Ce ne sont pas seulement les règles existantes de l’entreprise qui doivent être ajustées. Il est également important de « se coordonner avec les autres équipes (non agiles) ». Même lorsqu’il s’agit de développement de systèmes, de nombreux cas ne peuvent être réalisés par une équipe agile seule. Cependant, il existe des problèmes tels que l’incapacité de coopérer en raison des différences de valeurs et de méthodes, et l’absence d’un leader capable de superviser les deux parties. En conséquence, les méthodes d’agilité, qui permettent aux organisations de réagir rapidement à des environnements en évolution rapide, pourraient ne pas être en mesure de produire les résultats qu’elles méritent.

Par exemple, Waterfall met l’accent sur la qualité et la robustesse, tandis que Agile met l’accent sur la vitesse et la fluidité. Cela signifie qu’une coordination avec les équipes non-Agile est nécessaire.

Partageons nos objectifs commerciaux, reconnaissons-nous et communiquons. Pour y parvenir, il est important de bien s’expliquer, de comprendre la situation et d’accepter l’agile sans l’imposer.

Il est également important de «mettre en place un système de formation des personnes inexpérimentées».

L’équipe de développement doit faire appel à des personnes n’ayant aucune expérience en Agile, ayant de l’expérience dans des départements commerciaux, etc., et ayant une solide compréhension du fonctionnement réel des choses. Nous développons des systèmes et des logiciels sur cette base. La formation de personnes inexpérimentées est donc une condition essentielle.

Cependant, les personnes inexpérimentées peuvent constituer un obstacle au début.

Alors comment le cultiver ? Qui sera formé et à quel poste ? Que pensez-vous de la formation du personnel inexpérimenté du côté des fournisseurs ?

« Toutes les entreprises n’ont pas beaucoup de personnes ayant une expérience agile, donc comment former des personnes inexpérimentées est une question importante. Il existe de nombreuses façons de le faire, comme la formation et l’OJT, mais si vous le faites correctement. Agile devrait être porté par un groupe de professionnels expérimentés, mais il est nécessaire d’inclure des personnes inexpérimentées, que ce soit du côté des fournisseurs ou des utilisateurs. La présence de personnes inexpérimentées sera en soi un frein au projet. Il est également difficile de décider qui prendra soin d’eux. C’est pourquoi il est nécessaire de bien les former. » (M. Katayama)

Alors, de quoi a besoin un DSI pour faire progresser le développement agile ?

« Je pense que la prise de conscience des DSI a changé récemment, mais je souhaite qu’ils étudient ces questions en profondeur. Dans le passé, lorsque les gens du domaine disaient : « Nous le ferons avec Agile », j’ai entendu dire que les gens du secteur des postes tels que les DSI disaient souvent : « Que ferons-nous si les choses tournent mal ? » En conséquence, même si le lieu de travail essaie de réaliser un développement agile, il perd sa vitalité. Le DSI comprend également l’essence du développement agile en lui-même et le partage avec les parties liées.La promotion de l’agilité sera un long processus. Nous devons en être conscients.Le plus gros problème avec la culture d’entreprise est de savoir si nous pouvons ou non surmonter la tendance à tout abandonner.Je pense que les responsables informatiques ceux qui souhaitent mettre en œuvre le développement agile doivent être pleinement conscients de ce point. » (Katayama) M.)

Développement agile




Source link