Conception de logiciels Predictive vs réactive

Mon patron me dit.

Je soupçonne que beaucoup de gens n'ont pas de choix et de vieux patrons n'apprennent pas de nouvelles astuces.

Quand j'ai commencé la programmation (avec Cobol sans moins), la cascade était la "nouvelle" approche. Aujourd'hui, je vous dirais que j'utilise une méthodologie agile de Waterfalferie. Pour les systèmes plus importants, je trouve un type de chute de cascade fonctionne mieux. Ne crée pas d'énormes documents (c'est une perte de temps imo), mais plutôt de prendre des mesures comme la création d'un prototype d'interface utilisateur et / ou d'utiliser des cas pour obtenir la tête autour du problème de l'entreprise à portée de main. Une fois que nous sommes à l'aise, nous avons le problème Scoped et nous avons une solide compréhension, nous entrons dans un mode de développement agile.

Pour répondre à votre question, je pense que la chute de la cascade de grande raison est de nombreuses personnes n'aiment pas le changement. Il est effrayant de changer et de passer de la cascade à Agile est un gros changement.

Si vous connaissez exactement les exigences que jamais chagen, si vous savez combien de temps chaque étape prendra et si vous savez que toutes les ressources sont disponibles au moment où vous pouvez faire de la cascade et cela fonctionnera. Mais dans l'acte, ces types de projets sont assez rares et je pense que je ne ferai jamais une partie de cela.

Lors de la conception de systèmes à utiliser par les utilisateurs finaux, Agile fonctionne souvent bien car les exigences sont susceptibles d'être incorrectes et une grande partie du processus reçoit des commentaires des utilisateurs sous la forme d'une version utilisable.

Toutefois, lors de la création d'un logiciel qui interface avec d'autres logiciels, les exigences peuvent souvent être élaborées dans très clairement. Dans ce cas, il est souvent plus productif de veiller à ce que vous ayez une spécification très claire et précise, des tests unitaires dans ce modèle, vous pouvez également générer des estimations de travail relativement bonnes et il y aurait beaucoup plus de coûts d'utilisation du modèle agile.

Je pense que cette partie de la raison pour laquelle les gens s'accrochent toujours souvent à la cascade, c'est qu'elle donne l'illusion de contrôle. Dans une cascade, vous pouvez faire suffisamment de travail avant de mettre en place une belle horaire qui répond bien à chaque éventualité que vous puissiez penser, puis donner une feuille de route détaillée pour l'avenir à quiconque de l'entreprise qui demande quand la fonctionnalité X sera disponible.

Le problème est que vous ne pouvez presque jamais suivre ce plan à la lettre et vous êtes presque toujours en retard / abandon des fonctionnalités. Cependant, de l'initiement, il a l'air très contrôlé et gérable.

Je suis un grand fan agile, mais ce que j'ai toujours lu avec la feuille de route / la prévision de longue portée qui se produisent souvent par les ventes et les personnes marketing. Je pense que l'illusion de la certitude de la cascade est très réconfortante pour les gestionnaires et les gens d'affaires.

Ne pas prendre parti, mais quasiment toute recherche serait non scientifique au mieux.

Vous dites (l'accent est mis à moi)

Question: Pourquoi quelqu'un voudrait-il utiliser une cascade sur une forme d'agile avec tout l'agile de recherche agile ? Quels sont les arguments puissants pour utiliser de la cascade sur agile?

mais ne liez pas à aucune étude.

C'est l'une de ces choses qui sont connues pour être extrêmement difficiles à tester. Vous ne pouvez pas avoir deux équipes identiques sur le même projet en même temps, car deux équipes identiques ne sont pas telles que deux équipes identiques. Vous ne pouvez pas avoir la même équipe de compléter la même tâche deux fois de suite à l'aide de deux méthodologies différentes sans la première passe de la seconde. Je n'ai jamais entendu parler de personne concevant une étude expérimentale (ou même statistique) qui peut convaincer de manière convaincante toute méthodologie de développement logiciel. Je serais intéressé à en voir un cependant, si vous avez un lien.

À court de preuves réelles, il se résume à la préférence personnelle. Quels sont les arguments forts pour le chocolat sur la vanille?

Je vais jouer à l'avocat du diable et indiquer que Agile est imparfaite est presque autant de façons que la méthode de la cascade est. Je ne suis pas un de ceux qui aiment la méthode de la cascade, mais je n'aime pas l'agile non plus.

Mon expérience avec Agile n'a pas été très positive. Pour être juste, je l'ai utilisé dans un environnement d'entreprise, qui a payé le service des lèvres à "agile" tout en attendant que notre responsable produit des jalons à long terme et des produits livrables initiaux.

Cependant, j'ai trouvé que Agile (Scrum en particulier) Les méthodologies dissimulent souvent des problèmes majeurs avec la conception. Bien que la cascade donne aux gestionnaires l'illusion de contrôle, Agile semble faire la même chose pour les équipes de développement. J'ai vu des équipes où élever n'importe quel problème qui ne sont pas dans le Sprint / Itératon actuel, avec l'attente que cela sera traité "dans le temps". Cela ne nécessite que quelques décisions de conception majeures à ignorer pour que le projet soit venu à l'avenir, tandis que les itérations actuelles se déroulent sans heurts et que le projet semble être sur la bonne voie.

Vous pouvez faire valoir que l'équipe est en faute pour ne pas comprendre l'esprit d'agile, mais j'aimerais voir de meilleures méthodologies intégrant les meilleures parties d'Agile.

Le titre dit tout. (En fait: Proactive VS réactive). Pourquoi a choisi la manière réactive et abandonner le contrôle sauf si vous n'êtes pas obligé? La cascade n'est pas la seule alternative, vous pouvez avoir n'importe quel type de processus de développement ce que vous affinez lorsque vous aimez. Le contrôle est la clé.

C'est un spectre BTW, la cascade à une extrémité et les méthodes de documentation zéro totalement réactives à l'autre extrémité. Si vous travaillez dans le secteur des consultants pour des clients puissants (et généralement indécis), vous devez recourir à des méthodes réactives. Si vous développez des logiciels rétractables, vous pouvez planifier l'avance et gérer les connaissances. Certains projets nécessitent également des tonnes de spécifications et de règles, où le code et l'approche corrigée ne le coupent tout simplement pas. Pour moi, l'ingénierie du logiciel concerne principalement la gestion des connaissances et la conception, le codage est synonyme de seconde.

P.s. Il n'y a pas une telle chose comme un prix agile et fixe. Pas de manière classique, ils vendent généralement la méthode. Voir http://martinfowler.com/bliki/fixedprice.html

Comportement rétroactif

Si vous avez une équipe de quelques dizaines de personnes qui ont au cours d'une décennie, raffinent la stratégie de cascade au point qu'il fonctionne bien pour eux, qui êtes-vous à venir et à dire: "Tu fais que tu fais c'est faux..."? Vraiment, si cela fonctionne pour eux, pourquoi changer les choses? Oui, cela ne fait que basculer la question autour, mais je pense que c'est peut-être un point valide.

L'un des locaux de (au moins) XP est que le changement est bon marché. Le modèle de cascade a été construit sur les principes qui changent, tout changement, est coûteux. L'hypothèse dans le modèle de cascade est qu'une fois que le logiciel a été écrit, la modification est plus chère que d'investir le temps à l'avant de la compréhension «complète» du problème.

L'expérience semble indiquer qu'il est très difficile de se comporter à une compréhension complète du problème et que si certaines précautions sont prises (par exemple, des tests unitaires) peuvent devenir beaucoup moins chers. Par conséquent, si vous rencontrez un problème dans lequel certains des locaux agiles ne tiennent pas de vraies autres approches pourraient encore être réalisables. Entre la cascade et l'agile, il y a au moins un développement spiral qui est - une sorte de - ce que nous pratiquons.

Dans mon équipe, nous avons constaté qu'avec des projets de maintenance (qui est la majeure partie de ce que nous faisons) où nous modifions ou remplacons comme comme s'il n'y avait pas toujours autant besoin d'une entrée de l'utilisateur au-delà de certains prototypes d'interface utilisateur .

Dans ce cas, en particulier, étant donné qu'il y a des transactions commerciales impliquées, l'approche de cascade à un niveau macro peut bien correspondre. Même alors, nous aimons toujours les approches incrémentales / agiles au niveau de la mise en œuvre.

Il convient de noter que la plupart de nos clients sont des organisations volumineuses importantes en amour de leurs documents, de sorte qu'ajoute encore plus d'impulsions pour que nous puissions apparaître au moins traditionnellement traditionnelles.

La documentation générée lors du processus de cascade permet de beaucoup de cyaux. Vous pouvez signaler les doigts lorsqu'un projet passe dans les rails. Très peu de cadres vont être d'accord avec "Oh bien, je suppose que ce projet s'est échappé de nous! Eh bien, au moins, nous avons découvert tôt, pas de mal sans faute!"

En outre, les documents de conception peuvent générer automatiquement des plans de test, utiles pour QA.

Vous devez être suffisamment prédictif pour livrer les marchandises. Vous devez être suffisamment réactif pour traiter les problèmes.

J'étais une fois coincé avec six mois pour achever un projet estimé à prendre un an et basé sur une expérience d'expérience passée en prendrait deux. J'ai donc passé trois mois à rechercher des méthodes. Nous avons terminé à temps (en trois mois), en utilisant les parties appropriées d'un processus de cascade.

Quelques points qui ont fait le travail de méthodoly: - Créez des normes d'utilisation, mettez-les à jour en cas de besoin. - Build Bibliothèques: Faites-le une fois, faites-le bien, réparez-le sans casser le code existant. - Faites juste assez de documentation. - La version contrôle tout ce que vous pouvez. - briser les choses; Une méthode devrait gérer le travail ou faire du travail. - Augmenter la cohésion, diminuer le couplage, la réutilisation. - Achetez ou construisez les outils dont vous avez besoin. - Suivez vos problèmes et vos progrès.

Un autre projet que j'étais bracieusement était un projet de six mois. Je n'ai pas été impliqué avant un an et demi après le début. L'initiative de développement avait été embauchée à une balise extrême alors qu'il quittait une carrière dans un régime de retraite. Au début du projet, il a demandé au chef de projet: "Voulez-vous que je fasse bien ou être réactif?" Pouvez-vous deviner la réponse? La semaine que j'étais impliquée la même fonctionnalité a été mise en œuvre lundi, mercredi et vendredi. Devinez ce qui s'est passé mardi et jeudi?

La force d'Agile est son accent sur juste assez, juste à temps. La force de la méthode de la cascade est qu'elle couvre toutes les choses dont vous avez besoin. Je n'ai pas encore travaillé sur un projet qui a fait ou aurait dû faire toutes les étapes. J'ai travaillé sur de nombreux projets qui ont fait des mesures qui auraient dû être faites à la base d'une entreprise.

Il est assez courant lorsque vous soumettez un contrat que l'une des conditions de repassage est que vous suivez leur "processus" qui sur inspection est la cascade.