Existe-t-il une alternative viable à la méthodologie de développement agile?

Les deux méthodologies de développement de logiciels prédominantes sont waterfall et agile. Lorsque nous discutons de ces deux aspects, nous mettons souvent l’accent sur les pratiques particulières qui les distinguent (programmation par paires, TDD, etc. par rapport aux spécifications fonctionnelles, grande conception initiale, etc.).

Mais les vraies différences sont beaucoup plus profondes, en ce sens que ces pratiques sont issues d’une philosophie.

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.
Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Ma question est la suivante: peu importe ce que vous pensez du TDD ou des spécifications fonctionnelles, la méthodologie de développement en cascade est-elle vraiment viable?

Est-ce que quelqu'un pense vraiment que minimiser les changements dans les logiciels est une option viable pour ceux qui souhaitent fournir des logiciels de valeur? Ou est-ce vraiment la question de savoir quelle sorte de pratiques fonctionnent le mieux dans nos situations pour gérer le changement inévitable?

Bien sûr, la cascade est viable. Cela nous a amené à la lune!

Et c'est un coach agile qui parle ici!

À moins que vous ne puissiez identifier clairement les problèmes liés à la façon dont vous gérez vos projets, il n’ya aucune raison valable de changer.

En guise d'alternative aux méthodologies Agile et Waterfall , je proposerai VOTRE méthodologie . Adapté à votre activité, à votre équipe, à vos produits, à votre façon de travailler, à votre culture d'entreprise ... C'est pourquoi Scrum est appelé un simple cadre plutôt qu'une méthodologie.

Vouloir implémenter une méthodologie parce que quelqu'un sur un blog dont vous aimez parler en parle est aussi stupide que de laisser les problèmes aller sans rien faire.

Tout d'abord, je vais être en désaccord avec vos déclarations:

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.
Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Mon interprétation est:

Waterfall dit: Le client sait ce qu'il veut.
Agile déclare: Le client ne sait pas ce qu'il veut et nous allons donc devoir créer quelques versions différentes.

La meilleure implémentation de «cascade» que j'ai jamais vue était un énorme projet d'intégration avec un très gros client financier et environ 40 sous-projets impliqués. Le package de bureau et de site Web que nous avons fourni ne comprenait qu’un de ces 40 sous-projets. Alors que je pensais qu'ils dépensaient de manière assez excessive dans l'argent des autres, ils avaient leurs affaires en commun et maintenaient plus de 40 navires différents en mouvement. Le projet a été mis en ligne à la date cible (la cible a été déplacée une fois au cours du projet) et, même si je pensais qu'ils auraient pu le faire de manière plus frugale et agile, cela s'est fait dans les délais et les spécifications. L'horaire de la soirée de lancement comprenait environ 100 pages, dont une quarantaine étaient les coordonnées d'urgence de toutes sortes de personnes impliquées. J'ai été très impressionné par ce client.

Ou bien, vous pouvez faire ce que nous faisons, faire le tour et faire le rapport de plainte / bogue le plus récent, et appeler cela agile.

Vous commencez par dire:

Les deux philosophies de développement de logiciels prédominantes sont la chute d’eau et l’agilité.

C'est faux. Cette dichotomie a été construite par la communauté agile afin de créer un adversaire contre lequel se positionner. Avant que Agile ne soit à la mode, les gens parlaient d’une myriade d’approches différentes pour la construction de logiciels. Ils existent toujours aujourd'hui, mais d'une manière ou d'une autre, ils sont souvent regroupés dans un grand gâchis appelé "cascade" par des promoteurs agiles.

J'utilise OPEN / Metis et ses variantes depuis plus de 10 ans avec un grand succès. Ce n'est certainement pas agile, et certainement pas cascade. Des milliers de développeurs créent des logiciels extrêmement complexes pour les avions, les systèmes critiques, les opérations bancaires, etc., en utilisant des méthodes non agiles au quotidien.

Alors oui, bien sûr, il existe une alternative viable à l'agile.

Oui, diverses techniques de développement logiciel sont toutes viables en fonction de votre domaine de problème. C'est "Des chevaux pour les cours".

Par exemple, vous écrivez un logiciel pour contrôler une centrale nucléaire ou pour piloter la navette spatiale de la NASA. Ce type de domaine problématique est probablement mieux adapté à une approche en cascade (ou même plus stricte), vous voulez régler tous les problèmes à l’avance si possible (ou BOOM!).

Construire la dernière interface utilisateur web 2.0 / 3.0 / buzzy marketing? L’agilité est une bien meilleure solution (vous avez besoin de retours rapides et de changements).

Il y a ce que j'appellerais des principes d'artisanat du logiciel qui peuvent toujours être appliqués quelle que soit la méthodologie utilisée, par exemple:

• Contrôle de la source
• construire et CI
• programmation en binôme
• TDD
• Je donne un ^% $$ &

et plus.

Quoi que vous fassiez, n'écoutez pas les fanatiques de chaque côté de l'équation, faites ce qui est juste pour vous, votre équipe et votre domaine de problèmes.

Le problème provient de la complexité du logiciel. La cascade est idéale pour la construction de ponts et le pavage de routes, car la physique ne change jamais. Bien sûr, nous allons développer un nouvel asphalte à un moment donné, mais cela ne révolutionnera pas la façon dont les routes sont construites. L'acier dans la suspension d'un pont est soit la bonne taille, soit ce n'est pas le cas. Vous ne pouvez pas cogner ou stub un véritable projet de construction comme vous pouvez le faire avec un logiciel.

Changements de logiciel. Le logiciel change rapidement. La loi de Moore stipule que le nombre de transistors sur une puce double tous les 18 à 24 mois. En corollaire, le nombre de lignes de code dans un programme double également. La complexité entre ces lignes de code augmente donc avec un bigO de quelque chose comme 2 ^ (2t).

Le logiciel change rapidement et sa complexité augmente de manière exponentielle.

Lorsque vous contrôlez le coût du logiciel, vous souhaitez contrôler les facteurs exponentiels , pas simplement les facteurs multiplicatifs ou additifs. Changer de code augmente la complexité (et devient exponentiellement plus complexe à mesure que le projet avance) de manière exponentielle.

Le changement est inévitable. La nature même de la programmation étend le langage avec des classes et des méthodes personnalisées, modifiant ainsi le langage lui-même. Vous ne pouvez faire cela dans aucune autre discipline d'ingénierie (comme la construction de routes. Vous n'inventez pas de nouveaux trottoirs pour simplement paver une route du Kansas sur la Californie).

La méthode agile vous fournit également une plate-forme pour gérer les versions futures et les corrections de bugs. Vous avez déjà les outils de gestion, les processus et les employés formés pour développer des logiciels versionnés. Avec une méthode en cascade, vous auriez besoin de recycler votre équipe pour gérer les corrections de bugs, même mineurs.

de toute façon, mes 2 cents.

Pour répondre à la question, existe-t-il une alternative viable, pour les logiciels peut-être pas - ou pas encore, du moins dans le cas général. Je pense que cela dépend de la nature du logiciel. Les logiciels, étant des informations, peuvent être dupliqués gratuitement. Contrairement à un pont ou une maison. Cela signifie qu'avec de la pratique, je pourrais bien construire une maison et opérer dans un domaine relativement simple. À quel moment, pourquoi ne pas utiliser une approche ponctuelle?

Mais comme les logiciels ne génèrent aucun coût de duplication, pourquoi voudriez-vous faire la même chose deux fois? Le logiciel tend à s'éloigner de la fabrication. Donc, si tous les logiciels sont la création d'un nouveau produit, nous travaillons toujours dans un domaine complexe où, dans une certaine mesure, nous ne savons pas ce que nous faisons. Ou cela coûte cher de savoir à l’avance et moins cher de le savoir en le faisant. Dans un domaine complexe et risqué, je voudrais essayer des expériences, incrémenter et itérer.

Les centrales nucléaires et les systèmes fly-by wire sont souvent cités en exemple de logiciel que vous voudriez utiliser en cascade. Mais le système avionique de la navette n'a-t-il pas été développé de manière itérative? Comme étaient les systèmes de contrôle du trafic aérien canadien et américain?

Et si OPEN / Metis est itératif et incrémental, pour moi, cela ressemble à une philosophie agile même s’il ne s’associe pas à d’autres pratiques agiles courantes.

La méthode des chutes d’eau est certainement viable et est aussi philosophiquement valable que toute autre approche. N'oubliez pas que Waterfall existe depuis beaucoup plus longtemps qu'Agile, mais notez qu'il ne s'agit pas d'un argument pour affirmer qu'une méthodologie est meilleure qu'une autre.

Vous utilisez la méthode Waterfall lorsque vous comprenez très bien le domaine du problème et ce que le client souhaite obtenir dans un progiciel. Vous avez probablement indiqué un prix fixe lors de la prise du contrat, et votre client comprend qu'il ne peut pas déroger aux exigences convenues. Votre processus est strictement un processus qui passe par une série d’approbations entre les différentes étapes du développement, et il est fréquent que chaque étape soit complétée par une équipe différente - parfois même une entreprise différente contact avec les autres. Vous voyez souvent que Waterfall est appliquée à bon escient dans les projets militaires et gouvernementaux lorsqu'ils sont confiés à des entrepreneurs extérieurs. Lorsque Waterfall et d’autres approches similaires ont mauvaise réputation, c’est lorsque les développeurs rencontrent des problèmes, comme une mauvaise estimation, des calendriers planifiés sans temps de réserve ou une compréhension médiocre ou incomplète du domaine problématique. La question n’est jamais vraiment une faute de la méthodologie, mais dans l’application de celle-ci.

La comparaison entre Agile et toute méthodologie est fausse. Agile n'est pas une méthodologie, c'est une philosophie, ou peut-être serait-il préférable de dire que c'est un terme générique qui représente une manière différente de voir comment vous allez développer un logiciel. Une méthodologie est simplement un outil et, en tant que telle, sa valeur sera toujours inférieure aux individus et aux interactions qui sont au cœur de ce que signifie être agile .

Est-ce que quelqu'un pense vraiment que minimiser les changements dans les logiciels est une option viable pour ceux qui souhaitent fournir des logiciels de valeur?

Chaque opportunité de minimiser les changements est précieuse pour le développeur et le client. Les modifications peuvent faire glisser un calendrier ou laisser des fonctionnalités de côté afin de respecter un calendrier. C'est la façon dont vous gérez les effets du changement qui influe sur la valeur de vos projets.

Ou est-ce vraiment la question de savoir quelle sorte de pratiques fonctionnent le mieux dans nos situations pour gérer le changement inévitable?

Vos pratiques peuvent aider à gérer le changement, ou peuvent ignorer complètement le changement. Ce qui compte, c’est la combinaison de vos pratiques de développement et de la gestion de votre relation avec vos clients, et de savoir si ces éléments fonctionnent ensemble de manière efficace pour toutes les parties concernées.

Ceux d’entre nous qui sommes à toutes fins utiles Agile comprennent que vous choisissez une méthode qui fonctionne pour vous. Si vous aimez une approche particulière, suivez-la. Si cela ne vous convient pas, changez-le. La manière dont vous concevez un logiciel consiste réellement à utiliser au mieux les ressources dont vous disposez et à minimiser les pratiques qui peuvent conduire votre projet à l’échec. Vous constaterez souvent que vous devez modifier votre méthode en fonction projet particulier à portée de main.

C’est vraiment une chose de dire «OK, alors nous sommes maintenant agiles», et c’est une toute autre chose que de vivre et de travailler selon la philosophie de l’agile. Que vous utilisiez Waterfall, Incremental, Spiral, SCRUM, XP, FDD ou toute autre méthode, vous êtes fondamentalement agile où vous appréciez:

• Individus et interactions sur les processus et les outils
• Logiciel de travail sur une documentation complète
• Collaboration client sur négociation de contrat
• Répondre au changement au sujet d'un plan

et où vous apportez vos outils, votre méthode et votre expérience pour mettre en application ces valeurs avec succès.

Oui, les modèles de processus hybrides Waterfall, Spiral, Itérative et autres sont tous viables, mais le changement est inévitable. Le processus ne concerne pas seulement la façon de gérer le changement, et (j’affirme que) le plus important facteur est votre degré de connaissance / compréhension du problème et la précision avec laquelle vous pouvez planifier et prédire.

Affirmer que "les deux méthodologies de développement de logiciels prédominantes sont la cascade et l'agilité" est dérisoire, car il existe un large éventail de processus de développement de logiciels, et de nombreuses entreprises synthétisent leur propre version du modèle de processus, changeant souvent pour un projet donné. Il existe plus de deux approches viables pour le développement de logiciels. Bien que Waterfall et Agile aient tendance à tomber aux extrémités opposées du spectre du "changement", il est raisonnable de caractériser ces méthodologies concurrentes comme suit:

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.

Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Mais ce n'est pas toute l'histoire. Les entreprises doivent pouvoir planifier et prévoir, mais les logiciels sont un processus créatif et les estimations sont souvent fausses. Rappelez-vous le bon triangle - rapide - pas cher? Ajoutez une quatrième dimension, processus, et vous constaterez que la réduction des efforts de processus peut également comprimer le calendrier, lorsque les estimations se révèlent fausses et qu'un projet risque d'être retardé. Le logiciel est un processus fongible (modifiable) et Agile, Itératif, Spiral offrent tous la possibilité de fournir des fonctionnalités incrémentielles à des intervalles plus rapprochés.

Les modèles de processus basés sur Waterfall et sur d’autres exigences ont des contrôles pour gérer le changement. Il est donc inexact de dire que Waterfall minimise les changements, il est plus précis de dire que Waterfall reconnaît et gère les changements et communique l’impact de ces changements (car les changements ont un impact avoir des exigences et concevoir à l’avant). Lorsque vous créez un produit ou avez besoin de définir complètement les exigences (fonctionnalités), vous êtes amené à l'un des modèles hybrides.

Et lorsque les estimations sont fausses, le processus (la quatrième branche du triangle de fer) est souvent sacrifié pour respecter le calendrier.

Les approches agiles matures et en cascade sont indiscernables. Votre hypothèse concernant l'objectif de l'approche en cascade est incorrecte. Ils ont tous deux pour objectif de produire un logiciel de qualité. Lorsque vous ne disposez pas d'une approche de développement solide pour l'ensemble de la société , vous devez déterminer quelle approche générera le moins de friction possible lors de l'adoption. À la fin, des cycles de développement courts, une équipe d’assurance qualité solide et une entreprise qui pilote le développement sont les éléments les plus importants pour la production de logiciels de premier ordre.