Évidemment, les différences de l'impact sur les équipes, les clients, le retour sur investissement, etc. d'appliquer les deux approches sont énormes et font l'objet de nombreux livres et discussions et conférences sans fin.
Mais comme je pense plus à ce sujet, j'ai du mal à trouver une différence entre les deux qui ne correspond pas finalement à une seule différence racine qui est la fréquence de libération.
La cascade dépense du temps sur une conception, puis écrivez le code, puis de tester et enfin libérant. Mais Agile fait exactement le même ensemble d'étapes - c'est juste que chacun est plus petit.
Un élément clé de l'approche agile consiste à apprendre de chaque version et à utiliser cela pour laisser la conception plus large émerger au lieu d'essayer de le prédire au début.
Mais la cascade le fait aussi. C'est juste qu'au lieu d'apprendre toutes les 3 ou 4 semaines, l'équipe de cascade n'apprend que tous les 6 ou 9 mois. Mais la conception de la cascade émerge encore. C'est-à-dire que la libération de la cascade 2 reflétera ce qui a été appris dans la libération 1. Le processus n'est donc pas différent, c'est juste qu'il exécute à une vitesse différente.
Agile se concentre sur la collaboration étroite des clients. Mais la cascade le fait aussi. Son que puisque la cascade a une durée d'itération plus longue, une liste énumérée des exigences sous la forme d'un contrat est plus nécessaire pour garder tout le monde sur la même page sur la longue période de temps. Mais encore une fois, ce n'est qu'un artefact de fréquence. Plus la fréquence de livraison est élevée, plus la nécessité de contrat de contrat.
Y a-t-il d'autres différences primitives que je manque - ou est-ce vraiment juste une fréquence?
6 Réponses :
(après chaque fonctionnalité que vous avez terminée ou après la période de boîte temporelle (généralement appelée La différence est assez claire pour moi.
avec
User Story ) d'abord
sprint ou itération ))
C'est un bon point - avec agile, vous commencez à tester lorsque la fonctionnalité est terminée. Avec la cascade, vous commencez à tester lorsque le produit entier est effectué, ce qui fait des cycles de bout en bout plus longs.
Si j'allais me niger, je voudrais peut-être échanger le test / construire - étant l'avocat TDD que je suis :-) Je ne documenterais également que si la documentation était nécessaire. Et je concevrais comme-i-allé plutôt que tout avant :-)
+1 pour "Vous pouvez arrêter quand vous en avez assez". Un point de nombreuses personnes manquent
@Adrianh: Si vous le donnez aux utilisateurs finaux, vous besoin pour documenter les choses parce qu'ils ne seront pas lire le code, peu importe la qualité de sa qualité. Peut-être que vous documentez différentes choses, mais c'est toujours la documentation et il doit toujours être écrit.
Adrian ne vous dit pas l'inverse
@Donal ai-je dit aucune documentation? Nope - J'ai dit "Document si la documentation était nécessaire" :-) Si la documentation de l'utilisateur final est nécessaire - écrivez-le. Encore mieux - apportez vos auteurs UX et techniques et déterminez comment réduire cette documentation au minimum nécessaire. Ne documentez pas seulement CoZ, vous appuyez sur la phase "Document" dans votre processus. Document lorsque la documentation est nécessaire.
@adrianh: OK, donc nous sommes d'accord à un niveau pratique. :-)
Une différence est la transparence: si des personnes à l'extérieur de l'équipe de Dev, pendant le cycle de développement, ont une visibilité dans le processus, les progrès, les obstacles et le résultat final ressemblera.
La cascade n'implique pas la transparence. Souvent (bien que pas nécessairement), il est implémenté comme "les programmeurs entrent dans leur grotte et émergent n semaines / mois plus tard avec un" produit fini ". Les experts en affaires écrivent les spécifications en haut, ce qui peut être la fin de leur implication - ils ne peuvent plus être disponibles lorsque les programmeurs ont des questions pendant la mise en œuvre. Les programmeurs peuvent ne montrer aucun produit livrables à qui que ce soit jusqu'à la fin du cycle.
agile nécessite une transparence - cela fait partie du tissu de base. Les personnes en dehors de l'équipe seront (ou au moins peuvent ) voir ce que l'équipe fait. (Sinon, l'équipe est allongée d'être agile.) Cela pourrait être les réunions quotidiennes de STAND-up de Scrum, ou les grands graphiques visibles et les radiateurs d'informations, ou la démo à la fin de l'itération. L'exigence de XP pourrait être que le client effectue toutes les décisions commerciales, au lieu de laisser les programmeurs à gratter les têtes et à choisir aveuglément une option lorsque les exigences ne sont pas claires. Ce pourrait être le fait que les testeurs - et le client - sont considérés comme faisant partie de l'équipe, pas des équipes distinctes.
Vous êtes certainement pourriez-vous courir de la cascade avec transparence et dans une cascade bien gérée, vous le feriez probablement. Mais avec agile, c'est une donnée.
Retour plus rapide - à toutes les échelles, pas seulement des versions, est certainement un facteur commun dans de nombreuses pratiques agiles. Mais je ne pense pas vraiment que c'est la principale différence entre agile et cascade. Par exemple:
Les équipes de cascade ont tendance à être construites autour du groupe de spécialisations étroites. Les analystes / architectes / concepteurs / codeurs / testeurs ont tendance à être des groupes distincts de personnes travaillant seules. Les équipes agiles travaillent ensemble.
Les processus de cascade dépendent de nombreux documents et transférences. Les équipes agiles sont orientées autour de Code / Produits de travail.
Je ne sais pas que la cascade se concentre sur la collaboration client. Il existe un point de contact unique, avec un petit groupe de l'équipe de développement globale, souvent uniquement au début du processus. Agile est construit autour de la collaboration continue tout au long du processus de développement. Très différent.
Les processus de cascade sont construits autour de l'idée que vous pouvez définir entièrement le produit et l'architecture avant le début du développement. Les processus agiles sont construits autour de l'idée que vous découvrez le produit / l'architecture que vous allez.
La cascade dépense du temps sur une conception, puis écrivez le code, puis de tester et enfin libérant. Mais Agile fait exactement le même ensemble d'étapes - c'est juste que chacun est plus petit.
agile n'est pas une seule entité, mais un parapluie pour de nombreuses méthodologies variables.
Dans au moins certains d'entre eux, comme d'autres l'ont noté, ces "phases" se chevauchent beaucoup plus et sont dans un ordre normal quelque peu différent.
En fait, dans XP, la commande est plus ou moins:
- Test (TDD / Test d'abord)
- code
- Conception (refactoring)
- répète et finalement libérer
Quel type d'invertit la majeure partie de la séquence.
et le test, le code et la conception sont effectués à une note plus fine que la libération.
Un élément clé de l'approche agile consiste à apprendre de chaque version et à utiliser cela pour laisser la conception plus large émerger au lieu d'essayer de le prédire au début.
Mais la cascade le fait aussi. C'est juste qu'au lieu d'apprendre toutes les 3 ou 4 semaines, l'équipe de cascade n'apprend que tous les 6 ou 9 mois. Mais la conception de la cascade émerge encore. C'est-à-dire que la libération de la cascade 2 reflétera ce qui a été appris dans la libération 1. Le processus n'est donc pas différent, c'est juste qu'il exécute à une vitesse différente.
Cela dépend fortement de la pratique. Comme décrit dans DOD-STD-2167A , (section 4.1.1) Le modèle de cascade permet en effet aux phases du processus de développement de se chevaucher et de se chevaucher (en bref, d'être quelque peu agiles). Mais la plupart des pratiques réelles ont manqué cela, et il n'y avait pas d'apprentissage jusqu'à la fin du projet.
Agile se concentre sur la collaboration étroite des clients. Mais la cascade le fait aussi. Son que puisque la cascade a une durée d'itération plus longue, une liste énumérée des exigences sous la forme d'un contrat est plus nécessaire pour garder tout le monde sur la même page sur la longue période de temps. Mais encore une fois, ce n'est qu'un artefact de fréquence. Plus la fréquence de livraison est élevée, plus la nécessité de contrat de contrat.
à nouveau en fonction de la pratique. Je ne vois pas dans la spécification référencée ci-dessus beaucoup de mention des responsabilités du client, sans parler continuellement.
Alors que Jerry Coffin a noté dans un commentaire, la cascade est en effet un patrineur qui se disputait en faveur d'Agile (comme je l'utilise maintenant ...), mais ça vaut la peine de regarder ce document et de penser à ce qu'elle implique et comment cela a été appliqué.
Qu'est-ce que cette spécification montre une focalisation intense sur les contrats, la livraison et la maintenance des plans et des documents, et adhérant au plan . Et je crois que
que a effectué dans la pratique. Le contraste avec agile n'est pas le fusil horaire, mais un changement de valeurs.
comme Le manifeste agile proclame:
Nous découvrons de meilleures façons de développer logiciel en le faisant et en aidant les autres à le faire. À travers ce travail, nous sommes venus à la valeur:
individus et interactions sur les processus et les outils
logiciel de travail sur une documentation complète
Collaboration cliente sur la négociation de contrat
Répondre à la modification de la suite d'un plan
C'est-à-dire, alors qu'il y a de la valeur dans les éléments sur La droite, nous valorisons les articles à gauche plus.
Curieusement, cette déclaration de valeurs ne dit rien sur la fréquence de livraison (bien que la section «Principes» suivante ne fonctionne). Il est-ce que déplace toutefois le système de valeur à l'écart des plans, des documents et des contrats et le dos où il appartient, lors de la fourniture de logiciels de travail.
La libération fréquente est un mécanisme permettant de remplir ces valeurs.
Si vous avez travaillé dans "Mini-cascades", il serait effectivement un peu plus agile que la cascade de la paille BDUF. Mais la fréquence de livraison n'est certainement pas l'histoire entière.
marque,
Comme vous l'avez souligné, les deux approches partagent des «bonnes choses» qui devraient être dans tous les projets. Par exemple, prenez ces deux: commentaires rapides et transparence. Bien qu'il soit vrai que Agile a une structure qui encourage cela, ces deux "bonnes choses" peuvent (et devraient également être dans n'importe quel projet de cascade.
Cependant, j'ai tendance à (respectueusement!) En désaccord avec l'idée que la fréquence de libération est la seule différence. L'une la différence substantielle est la suivante:
La cascade passe du temps sur un design,
Ensuite, écrivez le code, puis testez
et finalement libérer. Mais agile fait
exactement le même ensemble d'étapes - sa
juste que chacun est plus petit.
Je ne pense pas.
À Agile, vous essayez de faire toutes ces choses simultanément, avec une équipe multidisciplinaire.
Je dis "tentative" parce que ce n'est pas quelque chose qui peut être facilement fait ... mais au moins essayer d'aide.
sur la cascade traditionnelle, au contraire, vous vous attendez à avoir des équipes distinctes (recherche / analyse, qa, conception, marketing, etc.) et les mains entre eux. Vous mélangez des disciplines et forment une équipe spéciale uniquement dans des cas exceptionnels, ou lorsque vous devez effectuer une recherche exploratoire ou une analyse des risques dans un projet complexe.
juste mes deux cents ...
J'aime vraiment cette question.
J'ai travaillé entretien avec de mauvais exemples de projets de cascade massifs. Les produits livrables pour les développeurs initiaux ont été plusieurs ensembles de documents et une base de code. Une fois le document de conception de haut niveau terminé, il a été livré et n'a plus jamais mis à jour. Ditto SRS, conception de détail, etc. Il y a une documentation, tout ce qui est peu fiable et suspect.
avec agile, il y a du code. Les développeurs depuis longtemps ont pensé que c'était auto-documentant, car ils étaient en cours avec le projet lors de sa rédaction. (Avez-vous déjà relâché vos propres mémos? Ils ont toujours un sens à l'auteur.) Je vais essayer de discerner l'architecture de la recherche sur 1500-2000 modules. De même, essayant de comprendre la conception de haut niveau. Je vais prendre des notes copieuses. Peut-être même des liants pleins. En regardant le code "auto-documentant" me dire ce qui est fait (dans ce module), mais pas pourquoi. Oh ouais, le personnel qui a collaboré avec les développeurs a été promu (ou effrayé) et n'est plus disponible.
Bad agile n'est pas meilleur qu'une mauvaise cascade. En fait, le mauvais agile peut être pire que la mauvaise cascade. Est bon agile mieux qu'une bonne cascade?
Le manifeste ne dit rien sur la documentation. Le danger réel ici est que "agile" signifie à de nombreux développeurs et clients une justification d'un modèle héroïque bon marché. Pensez-vous que le client aimait lire les trois épaisseurs de liants de trois anneaux de conception de haut niveau? Nous avons tous entendu parler de l'informatique 100 que la majorité du coût des logiciels est la maintenance et non le développement. Suis-je incorrect dans la pensée que l'aspect entretien est totalement ignoré dans cette discussion?
La différence peut être que les clients modernes ne peuvent pas se permettre de ne pas préciser "agile" car ils craignent d'être pensé en arrière.
Des threads de discussion comme celui-ci devraient être des wikis.
Parler de différences à partir du modèle de cascade est stupide - depuis le premier jour, il a été un homme de paille pour les gens de contraster avec tout ce qu'ils avaient préconisé. Je crois que la première description du modèle de cascade était dans: CS .umd.edu / Classe / Spring2003 / CMSC838P / Process / Waterfall.PDF , qui ne le décrit que comme contraste avec la méthode si inévitablement supérieure préconisée par l'auteur.
Non pour me répéter dans une réponse - vous devriez distinguer entre les versions et être prêt-prêt: Andybrandt.net/637/TO-Release-OR-Not-a-Release
AGILE est une série de cascades courtes chacune avec une splashback.