Tout à fait. Et c'est d'ailleurs pour cette raison que je n'aime pas du tout travailler dans les banques. :mouarf:Citation:
Envoyé par Frank P
Version imprimable
Tout à fait. Et c'est d'ailleurs pour cette raison que je n'aime pas du tout travailler dans les banques. :mouarf:Citation:
Envoyé par Frank 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.
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:Citation:
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.
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.Citation:
Envoyé par LSMetag
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.
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 :oops: :oops:
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 :D).
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 :aie: 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 :mrgreen:)
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 :lol:
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 :lol:- 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 :aie:)
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 :ccool:
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.
En effet, ca n'est pas le bon terme, c'est méthodes agiles :aie:Citation:
Envoyé par foetus
XP, Scrum sont des methode agiles :)
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).Citation:
Envoyé par Matthieu Vergne
Effectivement mais ce n'est pas un "vrai" cahier des charges qui a demandé 2-3 mois, voire plus, à établir.Citation:
Envoyé par Nathanael Marchand
À 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 :mrgreen:
É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 :cfou: :cfou:
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" :mrgreen:
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 :aie:
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 :lol:
Un petit lien: :ccool:
Iterative and incremental development
Un petit lien que je trouve assez instructif ;)
Utiliser les développements incrémental et itératif ensemble
Ben mince, je ne sais pas ce qu'il te faut :Citation:
Envoyé par foetus
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.Citation:
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
Tu confonds agile et arrache...
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...:?
Une bonne illustration du problème:
http://www.commitstrip.com/fr/2013/0...ons-du-projet/
Citation:
Envoyé par Matthieu Vergne
8O8O8O8O8O8O8OCitation:
Envoyé par foetus
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... :cry:
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... . :cry:
Il FAUT avoir un Cahier des Charges, une spec, une architecture, des tests, bref tout ce qui est prévu. normalement......
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".Citation:
Envoyé par souviron34
Sauf que justement le Cahier des Charges, de même que la spec, n'est en rien visé....Citation:
Envoyé par Matthieu Vergne
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....
Tu as raison: :mrgreen:Citation:
Envoyé par souviron34
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
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) :mrgreen:Citation:
Envoyé par souviron34
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é, ....)
Oui je vois bien le truc :mrgreen:Citation:
Envoyé par 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 ....
Édit: Je me suis planté Cahier des charges == fonctionnel
:sm:
T'as déjà un léger problème :
Citation:
Envoyé par foetus
- 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.....
Je complèterai les propos de souviron34 en disant que mettre de l'UML dans un cahier des charges c'est une grosse connerie :mrgreen:Citation:
Envoyé par foetus
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.Citation:
Envoyé par Nathanael Marchand
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.
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.
:aie:
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é :oops: