Discussion :

[phili_b]

Et ne parlons pas de nos organisations, souvent bureaucratiques à l'excès, parfois rigides jusqu'à la sclérose. Un nombre d'échelons hiérarchiques tels (et des relations hiérarchiques telles) qu'une information essentielle que détient un exécutant n'atteint jamais la moitié de la pyramide (surtout si elle dérange, elle peut même s'arrêter à l'échelon immédiatement supérieur). S'ajoutent à cela des cloisonnements horizontaux, des découpages par domaine, secteur, département, service... avec les éventuelles tensions ou conflits qu'il peuvent exister entre, pour rendre la communication des informations encore plus difficile.

Tout à fait. Et c'est d'ailleurs pour cette raison que je n'aime pas du tout travailler dans les banques.

[Johnny P.]

En informatique et tout particulièrement dans la création d'un produit personne est capable de respecter à la carte un planning parce que un projet est une expérience jamais tenté et unique quand on fait quelque chose qu'on n'a le plus souvent jamais fait comment peut-on penser estimer la finalisation ?

C'est une domaine complexe comme toute création...et avec beaucoup de facteurs qui font que le projet réussi à temps ou non.

S'ajoutent à cela des cloisonnements horizontaux, des découpages par domaine, secteur, département, service... avec les éventuelles tensions ou conflits qu'il peuvent exister entre, pour rendre la communication des informations encore plus difficile.

C'est ce que j'ai vécu et j'avoue que c'est d'une difficulté incroyable quand la mauvaise foi est là et que les gens eux-mêmes ne savent pas expliquer ce qu'ils font...et qu'il faut limite pousser à bout le gars pour enfin comprendre ce qu'il fait d'utile pour lui ... l'informaticien connait mieux le métier que les gars p:

[xelab]

Les seuls inconvénients, c'est les clients dits "chiants" qui n'arrêtent pas de modifier leurs besoins en cours de route en imposant la même deadline.

Généralement c'est aussi quand l'analyse des besoins a été mal faite à la base qu'on a ce genre de comportements. Et puis il y a quand même un cahier des charges à respecter, donc nouvelles demandes = avenants. Pour moi l'agilité consiste à accepter les demandes de modifications ou améliorations de la part du client tant qu'elles restent dans le cadre des besoins initiaux décrits dans le cahier des charges, sinon c'est la porte ouverte au grand n'importe quoi.

[Matthieu Vergne]

La physique quantique nous apprend qu'on ne peut pas mesurer en même temps de manière précise la position et la vitesse d'une particule. De la même manière, on ne peut pas mesurer en même temps de manière précise les fonctionnalités à implémenter et leur vitesse d'implémentation. C'est un excès d'orgueil que de certifier obtenir le système tel que prévu dans le cahier des charges au bout d'un temps prédéfini.

[foetus]

Il y a des méthodes qui existent et dont personne ne parle, et le développement informatique ne se résume pas à Méthodes agiles VS Cycle en V

En fait c'est plus une grosse ossature de méthode: ce sont les méthodes adaptatives (peut être pas le bon terme français).

/Pub on
Le livre "Software Engineering for Game Developers" de John P. Flynt avec Omar Salem explique très bien tout cela
Mais il date de 2005, peut être qu'il y en a un autre plus récent.

Ce livre décrit la création du jeu Ankh
/Pub off

Et donc l'analogie faite avec la randonnée est erronée.


Désolé mais cela va faire un certain temps que j'ai lu le livre et pas que, donc il va y avoir des approximations



L'eXterm Programming (XP) est juste un ensemble de pratiques, et on peut choisir lesquelles utiliser.

Si on dit "il n'y a pas de conception dans l'eXterm Programming" c'est parce que pour les marketeux/ cravateux, les même qui ont imposés MOE/ MOA, conception == cahier des charges.
Il faut savoir que le MOA/ MOE a été emprunté du bâtiment/ génie civil.

Hors c'est totalement faux. l'idée de l'XP: le client ne sait pas ce qu'il veut.
Donc au lieu de s'enfermer pendant X mois avec ses besoins, on va coder et livrer au coup par coup (itérations courtes) tous ses besoins pour qu'il se fasse une idée/ qu'il teste (ces bêtises ).
Ainsi, il pourra nous dire (rapidement) c'est ce qu'il veut/ pense/ rêve.

La conception vint essentiellement des tests et du refactoring
Les tests: il faut écrire les tests avant de coder. On pense à la fonctionnalité. Et après le codage, on a des tests de régression.
L'inconvénient des tests: ce sont des tests Pas toujours de librairie de tests officielle et/ ou intégrée, impossible de tester certaines fonctionnalités (affichage ...)
Un exemple précis: les tests de l'Objective-C (pour une application iOS avec XCode) c'est pas du officiel.

Le refactoring: On refait/ repense une fonctionnalité/ des fonctionnalités/ tout (Have fun)
L'inconvénient du refactoring: peu de développeurs le font encore plus si le projet est gros

D'autres pratiques permettent de concevoir le projet. Par exemple les réunions.
En XP, tous les 5-7 jours, à la fin d'une itération.
Avec Scrum, c'est, il me semble, tous les jours (tous les matins devant le café).
On dessine un bout de schéma de classes ou d'"Use Cases", un bout d'écran ....
Mais c'est semi-formel, et ce n'est pas forcément écrit quelque part (à part au Velleda sur le tableau et on sort la batte lorsque la femme de ménage arrive )


L'énorme truc des méthodes agiles (et que personne ne dit ou ne pense) et qui est une condition de réussite: Un lead programmer avec X années d'expérience et 1 ou 2 gros projets significatifs.
Dans les méthodes classiques, c'est lui qui fait le recueil des besoins et la spécification (le cahier des charges en gros).

Parce que si on veut avancer vite, savoir comment avancer, et ne pas rester bloquer, il faut avoir une grosse connaissance des technologies à utiliser (et pas un truc "j'ai lu 2-3 bouquins, fait le "Hello World" et c'est bon").
C'est lui qui guide le projet, qui dirige les réunions et qui valide les étapes. En conjointure avec le client/ développeur.

Avec l'analogie faite avec la randonnée c'est à la fois le guide, le "Hawk Eye" et les prévisions météo sur 7 jours


Donc pourquoi les méthodes adaptatives?

• Pour faire sérieux. Je sais c'est facile. Mais lorsqu'on va avoir un client qui va mettre X milliers d'€uros, voire X millions d'€uros sur la table, il faut rassurer le client. Ce n'est pas pour rien que ces méthodes sont utilisées pour faire un jeu (mais pas que)
  Rassurer le client et aussi protéger son derrière
• Parce que les méthodes agiles ne peuvent être utilisées qu'avec une petite équipe (pas plus de 10 - 15 développeurs, dont le client, le lead programmeur ....).
• Parce que si le projet explose (mais un truc sévère/ sérieux) il faut pouvoir rassembler les morceaux le plus rapidement possible et proposer "un truc fonctionnel". Exemple récent le jeu Duke Nukem Forever
• Parce que le client ne pas être intégré à l'équipe de développement et valider les itérations (je plaisante, quoi que )

Les méthodes adaptatives partent sur un modèle classique: recueil des besoins, spécification, codage, maintenance

La première différence est le recueil des besoins et la spécification. On va faire le traditionnel cahier des charges (validé par le client). Mais pas que, tout un tas de schémas (de classes, Uses cases, ...) mais aussi des planning de temps/ fonctionnalités/ budget.
Afin de découper et planifier la phase de codage en plusieurs itérations courtes. C'est là "le truc énorme".
Faire un gros légo avec des petites briques

L'idée c'est qu'à chaque itération, on valide le projet/ l'itération. Et en cas de problème mais aussi d'avance, on peut réajuster facilement la phase de codage (en s'aidant "de toute la littérature produite en amont")
La réajustement ce fait itération par itération, ou quelques itérations par quelques itérations, il me semble.

Un exemple: à l'itération N, on doit avoir coder une grosse fonctionnalité. À la fin de l'itération (délai), elle n'est pas finie.
Une solution: On peut forker le projet, mettre X développeurs pendant l'itération N+1 pour la finir, peut être prévoir 2-3 trucs en moins pour l'itération N+1 et faire un merge à la fin de l'itération N+1.

[Nathanael Marchand]

En fait c'est plus une grosse ossature de méthode: ce sont les méthodes adaptatives (peut être pas le bon terme français).

En effet, ca n'est pas le bon terme, c'est méthodes agiles
XP, Scrum sont des methode agiles

[Matthieu Vergne]

Même si c'est pas très clair, il fait bien la différence entre agile et ce qu'il appel adaptatif. Mais de ce que j'en ai compris, l'adaptatif, c'est de l'agile où on s'assure quand même d'avoir une première phase comme dans un cycle en V (une grosse conception). Après quoi il y a un découpage pour arriver à en faire de l'agile.

Cela dit, cela me fait penser à de la méthode agile adaptée à un client qui s'attend à du cycle en V (adapté pour pouvoir faire un contrat avec des délais finaux donc).

[Nathanael Marchand]

Même si c'est pas très clair, il fait bien la différence entre agile et ce qu'il appel adaptatif. Mais de ce que j'en ai compris, l'adaptatif, c'est de l'agile où on s'assure quand même d'avoir une première phase comme dans un cycle en V (une grosse conception). Après quoi il y a un découpage pour arriver à en faire de l'agile.

Cela dit, cela me fait penser à de la méthode agile adaptée à un client qui s'attend à du cycle en V (adapté pour pouvoir faire un contrat avec des délais finaux donc).

Euh... En Scrum aussi on part avec un cahier des charges et une date de livraison finale (j'ai envie de dire, encore heureux). C'est juste le "pendant" qui change... Les premières itérations ne peuvent contenir que des livrables "techniques" on va dire : pose de l'architecture du projet, etc. avec rien finalement aucun écran à montrer en démo au client (c'est pas pour ca que y'a rien à échanger avec le client d'ailleurs, ca peut être autour de diagramme, schéma, protos, etc).

[foetus]

Euh... En Scrum aussi on part avec un cahier des charges et une date de livraison finale (j'ai envie de dire, encore heureux). C'est juste le "pendant" qui change...

Effectivement mais ce n'est pas un "vrai" cahier des charges qui a demandé 2-3 mois, voire plus, à établir.

À mon avis c'est le côté "faux-cul" de la chose.

Méthode Agile == Pas de cahier des charges, mais de la conception continuelle.
Idée Maitresse: Le client ne sait pas ce qu'il veut
Édit 1: pas de cahier des charges, à nuancer parce pas pour toutes les méthodes agiles et avec différents stades de "précision"

Édit 2: d'après Wiki eXterm Programming != Méthode Agile

Mais cela fait peur à la fois au client et à la fois aux développeurs (mais nettement moins, surtout au début lorsque le projet roule sans soucis)

Alors on fait un "carnet du produit"
Même si je conçois qu'il est utile en étant "un fils d'Ariane"

Et je le redis Méthode Agile == petite équipe (15-20 personnes), un lead programmer qui s'y connait, un client omniprésent.
Ce sont de fortes contraintes

Pour faire un jeux vidéo, par exemple, c'est entre 60 et 100 personnes.
Et pas tous des développeurs: des créas, pour la modélisation, pour le "level design", pour le "story board", pour la "capture motion", pour le marketing ...
Et même les développeurs sont répartis en plusieurs équipes: moteur 3D, moteur physique, outils production, développeur animation, développeur audio, ...
Et sans compter les sous traitants.

Va appliquer une méthode agile avec tout cela

Un petit lien:
Iterative and incremental development

Un petit lien que je trouve assez instructif
Utiliser les développements incrémental et itératif ensemble

[Nathanael Marchand]

Effectivement mais ce n'est pas un "vrai" cahier des charges qui a demandé 2-3 mois, voire plus, à établir.

À mon avis c'est le côté "faux-cul" de la chose.

Méthode Agile == Pas de cahier des charges, mais de la conception continuelle.
Édit: d'après Wiki eXterm Programming != Méthode Agile

Ben mince, je ne sais pas ce qu'il te faut :

En informatique et plus particulièrement en génie logiciel, Extreme Programming (XP) est une méthode agile plus particulièrement orientée sur l'aspect réalisation d'une application, sans pour autant négliger l'aspect gestion de projet. XP est adapté aux équipes réduites avec des besoins changeants

Encore une fois, partir en scrum sans un cahier des charges bouclé, c'est faux. Au début du produit y'a un product backlog : toutes les fonctionnalités de l'application. Faut que ca soit clairement défini, ne serait ce que pour définir le contenu de chaque itération : d'un product backlog correctement défini découle les priorités et dépendances entre les stories.
Tu confonds agile et arrache...

[flottegauche]

Depuis que je fais de l'informatique, j'ai l'impression d'être un maçon:
"ha, mais ma p'tite Dame, va y avoir un dépassement de devis"...
A fortiori dans le dépannage. Impossible (sauf cas très classiques) si un débuggage va me prendre 5minutes ou 5h...

[imikado]

Une bonne illustration du problème:
http://www.commitstrip.com/fr/2013/0...ons-du-projet/

[souviron34]

l'adaptatif c'est de l'agile où on s'assure quand même d'avoir une première phase comme dans un cycle en V (une grosse conception).

Effectivement mais ce n'est pas un "vrai" cahier des charges qui a demandé 2-3 mois, voire plus, à établir.

À mon avis c'est le côté "faux-cul" de la chose.

Méthode Agile == Pas de cahier des charges, mais de la conception continuelle.

Comme le dit Nathaniael....


Où avez-vous lu ça ??????????

C'est ce qu'on vous enseigne ??? C'est ce qui se passe aujourd'hui avec le buzz-word ????


Non seulement ce n'est en rien partie de l'approche agile, mais c'est même le contraire... Je vous en prie, relisez le Manifeste...

Il n'est absolument nulle part mentionné qu'on ne doive pas faire de cahiers des Charges, ni que les étapes identifées lors de l'établissement du Cycle en V ne doivent pas être respectées...


La SEULE chose qui change, c'est primo le caractère non-définitif des architectures / décisions établies au départ, secondo la légerété des documents associés à chaque étape, et tertio un cycle ultra-court et partiel par rapport à un cycle long et total...


ça me déséspère de voir que de telles idées se propagent - ou sont malheureusement appliquées...

Une méthodologie agile n'est qu'une MANIERE SOUPLE de faire un développement standard...

IL FAUT connaître et les étapes et les documents standards du développement global (dont Waterfall et cycle en V sont tirés) et avoir/produire les documents et étapes essentiels..



ça m'énerve, ces trucs de mode qui finalement dénaturent tout le fond de la pensée... .

Il FAUT avoir un Cahier des Charges, une spec, une architecture, des tests, bref tout ce qui est prévu. normalement......

[Matthieu Vergne]

secondo la légerété des documents associés à chaque étape

Ben excuse-moi, mais l'interprétation "ne pas faire de grosse conception" reste tout à fait plausible pour avoir un cahier des charges "léger".

[souviron34]

Ben excuse-moi, mais l'interprétation "ne pas faire de grosse conception" reste tout à fait plausible pour avoir un cahier des charges "léger".

Sauf que justement le Cahier des Charges, de même que la spec, n'est en rien visé....

Ce qui est visé, c'est par exemple les différents Dictionnaires, associés à chaque étape de documents dans le cycle normal... De même que la documentation exhaustive des TU, ou la conception détaillée sous forme de document..



Sauf que pour savoir ça, il faut au préalable ête familier avec les documents et étapes prévues dans le Cycle en V normal....


Un cycle normal est :

• Cahier des Charges
• Analyse système
• Spécification système
• Conception Préliminaire
• Conception détaillée
• Codage
• Tests Unitaires
• Test Systèmes

L'esprit général dans lequel le Manifeste a été créé est :

• Le Cahier des Charges, de même que l'Analyse Système sont inchangés.
• La Spécification Système est "priorisée" et pas totalement détaillée
• Le Conception préliminaire subit le même sort
• La Conception détailée est supprimée
• Les TU sont faits (a priori sans doc particulière) au fur et à mesure
• Les Tests Systèmes également, avec par contre des docs succintes
• Partout on supprime les "Dicitonnaires"

ça ne fait qu'introduire de la souplesse, mais absolument toutes les étapes du cycle normal doivent être faites, même si elles ne sont pas identifées comme telles...


En fait, j'ai bien l'impression que l'on confond "agile" et "sloppiness", comme on dirait, c'est à dire "quick and dirty"..

Les auteurs du Manifeste n'avaient certainement pas cela en tête, mais je réitère que c'est fait pour une "élite", c'est à dire des gens expérimentés et bons, et non pas pour tout le monde... Et surtout des gens qui savent parfaitement se servir d'un cycle normal complet....

[foetus]

Non seulement ce n'est en rien partie de l'approche agile, mais c'est même le contraire... Je vous en prie, relisez le Manifeste...

Tu as raison:

Les méthodes Agiles et XP ont été créées à partir des expériences des développements entre 1960 et 1990 et reprennent notamment les idées de IID

Par exemple, le "carnet de produit" (ou backlog) de Scrum est un élément très important de IID

Sauf que pour savoir ça, il faut au préalable ête familier avec les documents et étapes prévues dans le Cycle en V normal....


Un cycle normal est :

• Cahier des Charges
• Analyse système
• Spécification système
• Conception Préliminaire
• Conception détaillée
• Codage
• Tests Unitaires
• Test Systèmes

Je pense que le Cycle en V est une méthode à part qui date de 1980 (20 - 30 ans après les premières méthodes)

Parce que les méthodes sont basées sur PDCA

En gros, les tests doivent être automatisés et intégrés à la phase de codage.

La phase de spécification et de conception est plus ou moins faite au début (soit au minimum, soit ce qu'il faut, soit de façon complète, soit de façon ultra-complète (avec gestion des risques par exemple)).

Mais elle n'est pas figée et pendant le codage elle va évoluer avec tous les indicateurs choisis (feedback client, feedback développeur, avancement du projet, délai imposé, ....)

Encore une fois, partir en scrum sans un cahier des charges bouclé, c'est faux. Au début du produit y'a un product backlog : toutes les fonctionnalités de l'application. Faut que ca soit clairement défini, ne serait ce que pour définir le contenu de chaque itération : d'un product backlog correctement défini découle les priorités et dépendances entre les stories.
Tu confonds agile et arrache...

Oui je vois bien le truc

Mais par exemple dans un cahier des charges tu as de l'UML (diagrammes de classes, diagrammes USE CASES, diagrammes de déploiement), tu as des planning ....

Édit: Je me suis planté Cahier des charges == fonctionnel

[souviron34]

T'as déjà un léger problème :

Mais par exemple dans un cahier des charges tu as de l'UML (diagrammes de classes, diagrammes USE CASES, diagrammes de déploiement), tu as des planning ....

• Pourquoi y aurait-il un outil paticulier pour un Cahier des Charges ????? Un simple papier et crayon ou un éditeur de texte suffit..
  
• Il ne peut pas y avoir de "diagramme de déploiement" dans un CdC
  
• Encore moins de planning...

Mais quel foutoir vous avez dans la tête !!!!

Vous mélangez le quoi, le comment, le quand...

• Le Cahier des Charges c'est quoi, un point c'est tout...
  
• Comment, ça devient de la conception...
  
• Quand, c'est du planning, et ça dépend des pressions/contraintes/méthodologies/budgets/difficultés, etc etc...

Quant aux méthodes XP et Scrum, et autres, elles sont apparues après.. Et je suis de la génération des gens du Manifeste, merci pour eux

Ce pourquoi eux (et moi) sommes arrivés à ces conclusions c'est par une longue pratique des cycles en V dans de grosses équipes.....

[Nathanael Marchand]

Mais par exemple dans un cahier des charges tu as de l'UML (diagrammes de classes, diagrammes USE CASES, diagrammes de déploiement), tu as des planning ....

Je complèterai les propos de souviron34 en disant que mettre de l'UML dans un cahier des charges c'est une grosse connerie
Un cahier des charges exprime un besoin, les diagrammes de classes ou l'UML sont une modélisation d'une solution répondant (plus ou moins) à ce besoin (et valide à un instant T) et par conséquent, c'est déjà faire des choix. On n'est donc plus dans l'expression de besoin...

[xelab]

Je complèterai les propos de souviron34 en disant que mettre de l'UML dans un cahier des charges c'est une grosse connerie
Un cahier des charges exprime un besoin, les diagrammes de classes ou l'UML sont une modélisation d'une solution répondant (plus ou moins) à ce besoin (et valide à un instant T) et par conséquent, c'est déjà faire des choix. On n'est donc plus dans l'expression de besoin...

Ça dépend, un diagramme de cas d'utilisation peut aider à formaliser les besoins sans proposer d'emblée une solution. Encore faut-il que le client y comprenne quelque chose.
Par contre on peut exprimer un début de choix via des maquettes (même très sommaires) expliquant les interactions voulues dans le cahier des charges sans que ça me choque, bien au contraire. Il n'y a rien de pire qu'un cahier des charges flou où les besoins sont mal exprimés.

[r0d]

Et moi qui croyais que l'extrem programming consistait à coder sur un portable, harnaché au flanc d'une falaise de 1000m de haut à -30°C.


ok je --->[]


Sinon oui, un use case dans un cahier des charges peut être le bienvenu je trouve. Mais je suis d'accord qu'il ne faut pas y mettre de tout et n'importe quoi, sinon ça devient un cahier à décharge...
ahem... désolé