L'agilité est-elle plus que de petites cascades?

J'ai principalement utilisé la méthodologie de la cascade pour mes projets, mais maintenant j'étends mes horizons vers des méthodologies agiles. D'après ce que j'ai lu jusqu'à présent, et peut-être que j'ai lu les mauvaises choses, agile signifie petites cascades. Au lieu d'une grande cascade répartie sur un ou deux ans, vous avez de petites chutes d'eau qui durent des semaines ou peut-être quelques mois au plus.

Ma compréhension est-elle correcte ou y a-t-il plus que cela? Quelles sont les philosophies agiles?

À un niveau simple, oui. La simple exécution d'une cascade toutes les deux semaines ne vous rend pas agile , mais elle est itérative (ce qui représente la moitié de l'agilité).

Le modèle en cascade définit les phases - exigences, architecture, conception, mise en œuvre, vérification (test), validation (test d'acceptation) et libération. Dans toute méthodologie itérative, vous passez par chacune de ces phases à chaque itération. Il peut y avoir un chevauchement entre eux, mais vous indiquez et capturez les exigences, adoptez l'architecture et la conception du système pour permettre la mise en œuvre, développez les nouvelles fonctionnalités ou corrigez les défauts, testez les nouveaux modules, puis présentez-le au client pour acceptation. tests et déploiement.

Cependant, l'agilité est bien plus qu'une simple opération itérative et incrémentielle. Les locataires d'Agile sont capturés dans le Manifeste pour le développement de logiciels Agile . Le Manifeste contient quatre points clés:

Individus et interactions sur les processus et les outils

Vous impliquez fréquemment des personnes individuelles. De nombreuses implémentations sont centrées sur des équipes auto-organisées et autogérées. Presque tous ont des interactions fréquentes avec le client ou quelqu'un qui a la voix du client. Plutôt que d'avoir un ensemble formel de procédures à suivre et d'outils à utiliser, vous laissez les personnes travaillant sur le projet guider la façon dont le projet est réalisé pour le faire de la meilleure manière possible.

Logiciel de travail sur une documentation complète

Dans un projet logiciel, l'objectif principal est la livraison de logiciels. Cependant, dans certains projets, la production de documents inutiles n'ajoute aucune valeur. Scott Ambler a écrit un bon article sur la documentation Agile / Lean . Il ne s'agit pas de ne pas produire de documentation, mais de choisir une documentation qui ajoute de la valeur à votre équipe, aux futurs développeurs, au client ou à l'utilisateur. Plutôt que de produire une documentation qui n'ajoute pas de valeur, vos ingénieurs logiciels produisent plutôt des logiciels et des tests associés.

Collaboration client sur négociation de contrat

Plutôt que de définir les conditions et les horaires et les coûts à l'avance, cela devient un effort continu avec le client. Par exemple, vous pouvez capturer vos besoins sous la forme de user stories et leur attribuer des points. Après quelques itérations, vous choisissez une vitesse (points / itération) et pouvez déterminer le nombre de fonctionnalités que votre équipe peut implémenter dans une itération. Au fur et à mesure que votre client fournit des commentaires sur les fonctionnalités qui ajoutent le plus de valeur, il peut décider quand le projet est terminé à tout moment. Un nombre illimité de choses peuvent se produire avec une livraison fréquente et une interaction avec le client - les exigences ont été satisfaites et le projet se termine par la maintenance et finalement la fin de vie, le client découvre qu'il n'a pas besoin de tout ce qu'il pensait alors décide de mettre fin à la projet, le projet échoue et le client le voit tôt et peut l'annuler ...

Répondre au changement au sujet d'un plan

Vous n'avez pas de gros plan ou de plan ultime à l'avant et devez effectuer des retouches chaque fois que ce plan ou plan doit changer. Vous estimez et révisez continuellement les estimations en fonction des informations dont vous disposez. Vous choisissez vos métriques avec soin pour donner un aperçu de la santé du projet et quand apporter des modifications internes. Vous ajoutez, supprimez et redéfinissez fréquemment des priorités avec le client. En fin de compte, vous comprenez que le changement est la seule constante.

Être agile signifie se concentrer sur les gens et répondre à leurs besoins en fournissant rapidement des logiciels de haute qualité à valeur ajoutée. À mesure que les besoins du client évoluent, vous vous adaptez à ces besoins pour vous concentrer sur la valeur ajoutée. Il existe des implémentations spécifiques de méthodologies agiles, mais elles sont toutes centrées sur les personnes, la livraison en temps opportun de logiciels de travail et l'adaptation à un environnement en évolution rapide.

Oui et non - le processus réel peut être vu comme une série de petites cascades, mais la différence est que le processus évolue et est amélioré à partir de la contribution de toute l'équipe (dev, qa, business, etc.), en rétrospectives, ce qui devrait conduire à une unité beaucoup plus serrée qui est capable de réagir aux problèmes et de planifier et de livrer avec précision. Je suis vraiment trop simpliste ici, il y a beaucoup plus, mais je ne pense pas que ce soit un mauvais point de départ.

Je dirais que c'est une façon simpliste de le dire. Oui, quand vous y arrivez, ce sont de petits débits d'eau, mais il y a tellement plus derrière cela qui le fait fonctionner. Toute une méthodologie qui change votre façon d'aborder les projets ... Sans oublier l'état d'esprit nécessaire pour cela.

Si vous êtes sérieux au sujet d'Agile, voici une bonne (et longue) série de webémissions qui pourraient vous intéresser:

http://autumnofagile.net/

Oubliez Agile une minute, pensez à ce que l'on entend par "cascade".

Il y a une phase d'exigences, dans laquelle chacun essaie de comprendre QUELS problèmes le produit final doit résoudre. Les gens se disputent à ce sujet pendant un certain temps, puis ils approuvent tous un ensemble d'exigences. À ce stade, votre portée est définie, les contrats sont signés et le client peut s'éloigner et attendre que vous trouviez un produit qui réponde à ces exigences définies.

Ensuite, il y a une (ou peut-être deux) phase (s) de conception. Les concepteurs (qui peuvent ou non être les développeurs), discutent de la façon dont le système doit aller de pair pour répondre aux exigences de signature. Des problèmes peuvent survenir s'ils ne comprennent pas tout à fait une exigence, ce qui peut signifier qu'ils doivent retourner auprès du client, potentiellement rouvrir la phase des exigences (et obtenir une autre série d'approbations) ou au moins mettre la gestion du changement en action . Souvent, les concepteurs font simplement leur meilleure supposition. Ils peuvent proposer un modèle de données logique et beaucoup d'UML décrivant un nouveau système et comment il devrait fonctionner. Ensuite, ils signent.

Maintenant, les développeurs peuvent commencer à coder, sur la base de la conception approuvée. Des problèmes peuvent survenir s'ils ne comprennent pas très bien la conception, ce qui peut signifier qu'ils doivent revenir au concepteur, potentiellement rouvrir la phase de conception (et obtenir une autre série d'approbations) ou au moins mettre la gestion du changement en action . Les concepteurs peuvent à leur tour réaliser que la confusion remonte vraiment aux exigences, ce qui signifie qu'ils doivent rouvrir les discussions sur les exigences, les approbations et la gestion du changement. Souvent, les programmeurs (qui ont une échéance imminente) font simplement leur meilleure supposition. Ils font ce qu'ils peuvent pour créer du code fonctionnel. Ensuite, ils le mettent à l'essai.

Maintenant, la phase de test du système s'installe. Les testeurs testent en fonction de leur compréhension des exigences et de la conception, et enregistrent ce qu'ils perçoivent comme des défauts dans un système de suivi des bogues / gestion des modifications, ce qui oblige les développeurs à recommencer à développer, sauf s'ils voient le problème comme un défaut de conception, qui le renvoie à la conception, etc ... Finalement, les tests du système réussissent et sont validés.

Enfin, le client revient et effectue des tests d'acceptation des utilisateurs sur le nouveau système. C'est là qu'ils décident si la solution testée par les testeurs, développée par les développeurs et conçue par les concepteurs est réellement ce qu'ils veulent. Si ce n'est pas le cas, vous devrez peut-être revenir à la phase de conception ou même revoir les exigences.

L'idée derrière la cascade est qu'il est difficile (et très indésirable) de revenir en arrière une fois la phase terminée. Différentes personnes sont généralement impliquées dans différentes phases, il y a donc plusieurs transferts - chacun d'entre eux présente un grand risque de mauvaise interprétation et de perte d'informations. Il existe également un écart important entre le moment où les clients disent ce qu'ils veulent et le moment où ils voient ce qui a été construit, période pendant laquelle les exigences réelles peuvent très bien avoir changé.

Les méthodologies agiles se concentrent sur une communication et une coopération solides entre toutes les parties intéressées. Le principe "Collaboration du client sur la négociation du contrat" ​​signifie que vous ne devriez pas avoir à passer par une série de signatures et de transferts, mais plutôt travailler simplement avec le client, chaque itération déterminant les exigences pour une pièce du puzzle. et former immédiatement des tests, une conception et un code de travail - avec tous les acteurs communiquant le plus directement possible (en éliminant les coûts et les risques de transfert). Le code de travail est rapidement testable par le client, éliminant les risques de décalage. Toutes les activités se déroulent dans un tourbillon collaboratif, pas dans un flux descendant.

Pour un excellent aperçu de ce que les méthodologies agiles essaient de faire, je recommande fortement le développement logiciel agile d' Allistair Cockburn : le jeu coopératif .

Oui, c'est plus ou moins correct. Il y a eu beaucoup d'écrits et de discussions sur la façon de s'y prendre, mais un tas de petites cascades en est le cœur.

La mise en œuvre spécifique de la façon d'utiliser un tas de petites cascades n'est cependant pas triviale. Par exemple, vous n'allez pas passer de la réalisation de grands projets dans quelques années à la réalisation de plusieurs petits projets. Il y a toujours le grand projet avec 1-2 ans de travail à y mettre. Vous devez donc diviser le grand projet en plusieurs petits projets. Cela peut sembler assez évident, mais il remplit des pages et des pages de livres.

Est-ce exact ou y a-t-il plus que cela

Tous les deux. Oui, c'est un résumé précis du concept, mais il y a beaucoup de détails qui se résument. Je veux dire, à peu près tous les aspects de la planification changent lorsque vous planifiez uniquement la semaine prochaine au lieu de l'année prochaine.

Si vous regardez la structure statique (définition du processus) d'un projet agile, cela ressemble à de nombreuses petites cascades, oui. Mais l'objectif d'un projet agile est d'obtenir des retours plus rapides et meilleurs .

• Vous faites du développement piloté par les tests pour savoir immédiatement si votre logiciel fonctionne toujours
• Un client est sur place et effectue des tests d'acceptation pour savoir quand vous avez terminé
• Vous avez des rétrospectives pour ajuster votre processus en fonction de ce qui s'est bien passé ou non.

Le manifeste agile met en évidence certaines différences entre l'agile et la cascade (telles que perçues par ceux qui ont signé).

Vraiment «agile» signifie souvent des cascades de 1 à 2 jours, pas des semaines. Cela ne signifie pas que vous ne suivez pas un plan global et que les cycles de sortie réels sont de 1 à 2 jours. Mais vous devriez essayer d'avoir un produit testé et fonctionnel tous les jours, et vous pourriez le publier - en théorie - tous les jours.

Scrum, par exemple, utilise des sprints de 4 semaines, mais un sprint n'est pas seulement une cascade (du moins, il ne devrait pas l'être). Vous pouvez changer les priorités tous les jours chaque fois que vous voyez que quelque chose ne se passe pas comme prévu au début du sprint.