IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #41
    Expert éminent
    Homme Profil pro
    Big Data / Freelance EURL
    Inscrit en
    mars 2003
    Messages
    2 124
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Big Data / Freelance EURL

    Informations forums :
    Inscription : mars 2003
    Messages : 2 124
    Points : 7 291
    Points
    7 291
    Par défaut
    Citation Envoyé par Frank P Voir le message
    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.

  2. #42
    Membre actif
    Inscrit en
    février 2006
    Messages
    311
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 311
    Points : 253
    Points
    253
    Par défaut
    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:

  3. #43
    Membre expérimenté
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2009
    Messages
    527
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2009
    Messages : 527
    Points : 1 518
    Points
    1 518
    Par défaut
    Citation Envoyé par LSMetag Voir le message
    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.

  4. #44
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 211
    Points : 7 550
    Points
    7 550
    Billets dans le blog
    3
    Par défaut
    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.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  5. #45
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 188
    Points : 9 407
    Points
    9 407
    Par défaut
    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.

  6. #46
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 065
    Points
    8 065
    Par défaut
    Citation Envoyé par foetus Voir le message
    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

  7. #47
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 211
    Points : 7 550
    Points
    7 550
    Billets dans le blog
    3
    Par défaut
    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).
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  8. #48
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 065
    Points
    8 065
    Par défaut
    Citation Envoyé par Matthieu Vergne Voir le message
    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).

  9. #49
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 188
    Points : 9 407
    Points
    9 407
    Par défaut
    Citation Envoyé par Nathanael Marchand Voir le message
    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

  10. #50
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 065
    Points
    8 065
    Par défaut
    Citation Envoyé par foetus Voir le message
    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...

  11. #51
    Candidat au Club
    Homme Profil pro
    Plombier du code
    Inscrit en
    juillet 2013
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Plombier du code

    Informations forums :
    Inscription : juillet 2013
    Messages : 1
    Points : 4
    Points
    4
    Par défaut
    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...

  12. #52
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2006
    Messages
    5 238
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 238
    Points : 19 645
    Points
    19 645
    Billets dans le blog
    17
    Par défaut
    Une bonne illustration du problème:
    http://www.commitstrip.com/fr/2013/0...ons-du-projet/
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  13. #53
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Matthieu Vergne Voir le message
    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).
    Citation Envoyé par foetus Voir le message
    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......
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  14. #54
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 211
    Points : 7 550
    Points
    7 550
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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".
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  15. #55
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Matthieu Vergne Voir le message
    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....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  16. #56
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    4 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 4 188
    Points : 9 407
    Points
    9 407
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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

    Citation Envoyé par souviron34 Voir le message
    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é, ....)

    Citation Envoyé par Nathanael Marchand Voir le message
    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

  17. #57
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 900
    Points
    17 900
    Billets dans le blog
    2
    Par défaut
    T'as déjà un léger problème :

    Citation Envoyé par foetus Voir le message
    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.....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #58
    Rédacteur
    Avatar de Nathanael Marchand
    Homme Profil pro
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 615
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 615
    Points : 8 065
    Points
    8 065
    Par défaut
    Citation Envoyé par foetus Voir le message
    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...

  19. #59
    Membre expérimenté
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2009
    Messages
    527
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2009
    Messages : 527
    Points : 1 518
    Points
    1 518
    Par défaut
    Citation Envoyé par Nathanael Marchand Voir le message
    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.

  20. #60
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    4 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : août 2004
    Messages : 4 261
    Points : 6 667
    Points
    6 667
    Billets dans le blog
    2
    Par défaut
    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é
    Tester c'est douter, corriger c'est abdiquer.

Discussions similaires

  1. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 450
    Dernier message: 09/09/2020, 10h08
  2. Réponses: 45
    Dernier message: 12/05/2014, 23h22
  3. Les développeurs sont-ils condamnés par leurs convictions ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 33
    Dernier message: 27/03/2014, 19h49
  4. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Actualités
    Réponses: 345
    Dernier message: 05/05/2013, 17h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo