Discussion :

[geforce]

Bonjour,

je viens de trouver une news, il parle entre-autre de faire un mix entre trois « méthodes » : Scrum, XP (Extreme Programming) et UP (Unified Process)....

je n'est pas bien comprit le principe ?

il donne comme exemple les cas qui sont partage entre les méthode :

Par exemple. Elles reposent toutes sur les mêmes piliers : rendre visible l’information (via le « radiateur d’information »), collaborer quotidiennement, livrer fréquemment, chercher la simplicité dans la conception et dans les échanges et tendre vers une amélioration continue.

pour moi sa reste très flou ? (je voudrai sa voir si vous été dans mon cas, ou si vous avait une expérience à nous proposer qui soit plus significatif )

Cordialement

[souviron34]

tout est dans ton titre...


Qui est exact, si on lui enlève le point d'interrogation...

[geforce]

tout est dans ton titre...
Qui est exact, si on lui enlève le point d'interrogation...

au sujet de la possibilité de mélanger les Méthode, sur qu'elle point en pourrai le faire ? (un exemple serai le bienvenu, bien sur selon votre un état d’esprit)

ps: selon moi il y a rien de technique dans les méthode Agile, dite moi si je me trompe.

Cordialement
GeForce

[Drawingrom]

Bonjour,

ps: selon moi il y a rien de technique dans les méthode Agile, dite moi si je me trompe.

Tu te trompes, de gens au profil technique majoritairement participé à l'écriture du manifeste agile. Quand tu regardes les pratiques de dev proposées par XP, c'est quand même très technique (TDD, intégration continue,...).

Ces derniers temps, je trouve que les aspects techniques sont moins considérés dans les communications sur l'Agilité. Ils ne font d'ailleurs pas partie de Scrum (car la technique y est supposée acquise), qui est la "méthode" la plus populaire. Les articles un peu "bisounours" comme celui que tu présentes vont malheureusement dans le même sens.

Si tu veux pouvoir livrer souvent du logiciel de qualité, il faut des gens solides techniquement dans ton équipe, peut-être d'avantage qu'avec un temps de développement long pendant lequel tu peux avoir le temps de t'apercevoir qu'il faut revoir une partie du code. Sans ça, on entendra toujours : "srum c'est nul, ça ne marche pas".

Du fait que les aspect techniques sont de plus en plus négligé, le mouvement du software craftsmanship est apparu : http://manifesto.softwarecraftsmanship.org/

Cool, non ?

[Bruno Orsier]

Pour des infos sur la combinaison de Scrum et XP, voir Scrum et XP depuis les tranchées ... http://henrik-kniberg.developpez.com/livre/scrum-xp/

Pour la combinaison de Scrum et Kanban, voir la traduction française http://www.aubryconseil.com/post/2em...anban-et-Scrum)

Bruno

[geforce]

merci bien pour ces liens il sont très intéressant je vais de ce pas les voire.

donnes mon cas (mon groupe) en est entrain de faire la combinaison entre UP et des méthode Agile comme Scrum. [en vient de commencer]

vous pensez que c'est faisable ? (dans quel cas sa ne les pas ?)

Merci d'avance
Cordialement
GeForce

[rad_hass]

Bonjour,



Tu te trompes, de gens au profil technique majoritairement participé à l'écriture du manifeste agile. Quand tu regardes les pratiques de dev proposées par XP, c'est quand même très technique (TDD, intégration continue,...).

Ces derniers temps, je trouve que les aspects techniques sont moins considérés dans les communications sur l'Agilité. Ils ne font d'ailleurs pas partie de Scrum (car la technique y est supposée acquise), qui est la "méthode" la plus populaire. Les articles un peu "bisounours" comme celui que tu présentes vont malheureusement dans le même sens.

Si tu veux pouvoir livrer souvent du logiciel de qualité, il faut des gens solides techniquement dans ton équipe, peut-être d'avantage qu'avec un temps de développement long pendant lequel tu peux avoir le temps de t'apercevoir qu'il faut revoir une partie du code. Sans ça, on entendra toujours : "srum c'est nul, ça ne marche pas".

Du fait que les aspect techniques sont de plus en plus négligé, le mouvement du software craftsmanship est apparu : http://manifesto.softwarecraftsmanship.org/

Cool, non ?

Excellent, je connaissais pas. Merci pour ce lien

Dans le sens des réponses précédentes, je voulais rappeler un des 12 principes du manifeste Agile qui est :

"Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité."

Ce principe exprime l'importance de l'excellence technique dans l'agilité, moi je vois deux branches fondamentales dans l'agilité qui découlent de ce principe qui sont le Refactoring et le Test... D'ailleurs on entend souvent parlé de développement agile ;-)

[Patriarch24]

Si tu veux pouvoir livrer souvent du logiciel de qualité, il faut des gens solides techniquement dans ton équipe

C'est en partie vrai. Le pair programming permet de monter en compétence, en acquérant de nouvelles compétences avec l'aide son binôme. Il n'est pas nécessaire d'avoir une équipe de génies, juste des gens motivés et qui ont soif d'apprendre !

[geforce]

merci bien pour ces liens il sont très intéressant je vais de ce pas les voire.

Mais dans mon cas (mon groupe) en est entrain de faire la combinaison entre UP et des méthode Agile comme Scrum. [en vient de commencer]

vous pensez que c'est faisable ? (dans quel cas sa ne les pas ?)

désoler je fait un petit UP! pour avoir une reponse à ma question ?

de plus je voudrais avoir votre avis sur l'utilisation de la méthode RUP ? (que je n'est jamais utiliser para-pore à ce que j'ai dit dans la citation ci-dessus)

Merci d'avance
Cordialement
GeForce

[Drawingrom]

De l'Agile RUP, j'entends ça par ici aussi. Ca a l'air d'être un gros truc complexe... J'aimerais également qu'on m'explique parce que du peu que j'ai lu ça a l'air trop orienté processes.

[hegros]

pour moi sa reste très flou ? (je voudrai sa voir si vous été dans mon cas, ou si vous avait une expérience à nous proposer qui soit plus significatif )

Cela veut dire que les 3 approches partagent des références communes en terme de conduite de projet (planification agile vs planification traditionnelle), de développement logiciel (pratiques et principes) et de communication (management opérationnel)

J'aimerais également qu'on m'explique parce que du peu que j'ai lu ça a l'air trop orienté processes.

Je te rappelle quand même que la fabrication d'un logiciel c'est un process et que son orchestration aussi, RUP donne à chacun de ces process une description détaillée.

ce n'est pas plus ou moins complexe à comprendre qu'autre chose , en fait elle est aussi conçue pour se coupler avec d'autres méthodos comme Scrum ou XP donc faire du RUP c'est potentiellement faire du Scrum et/ou XP et pas l'inverse à priori.

le vrai problème à mon sens c'est qu'on a tendance à la comprendre dans le sens qu'il faut faire tout ce que la méthode prévoit et dans l'ordre prévu et c'est une erreur qui débouche sur l'argument que c'est une méthode lourde et/complexe (à l'inverse de complète, détaillée et structurée)

[Patriarch24]

le vrai problème à mon sens c'est qu'on a tendance à la comprendre dans le sens qu'il faut faire tout ce que la méthode prévoit et dans l'ordre prévu et c'est une erreur qui débouche sur l'argument que c'est une méthode lourde et/complexe (à l'inverse de complète, détaillée et structurée)

+1. D'ailleurs, un des conseils qu'on retrouve le plus souvent : "tailor your process". En gros, il faut adapter à ses propres besoins les méthodes choisies !

[Bruno Orsier]

le vrai problème à mon sens c'est qu'on a tendance à la comprendre dans le sens qu'il faut faire tout ce que la méthode prévoit et dans l'ordre prévu et c'est une erreur qui débouche sur l'argument que c'est une méthode lourde et/complexe (à l'inverse de complète, détaillée et structurée)

C'est l'avantage de Scrum et XP - on peut les comprendre rapidemment, obtenir des résultats très vite, et on a la possibilité d'emprunter toute chose utile à une autre méthode.

C'est plus abordable que d'autres méthodes tellement personalisables qu'il faut d'abord faire son choix dans une centaine de choses avant de construire sa propre version.

Bruno