Discussion :

[Théolude]

... ça me laisse pantois !!!

Et si la vraie équipe Agile était celle qui savait justement amener tout le monde à suivre ses pratiques, ou pour le moins à ne pas les contrecarrer ?
Cette litanie des insuffisants, incompétents et pénibles potentiels n'a pas de sens et je la trouve très "fascisante", dans n'importe quel projet réel il y aura toute sorte de personne qui rentreront dans cette catégorie, sans qu'il soit nécessaire de les carboniser !!
Le premier levier d'un projet et son management, sa plus grande qualité est sa capacité à faire avec son environnement (et non pas contre à grand coup d'exclusion, de mise à l'index, de coercition, ou que sais je encore).

[Saverok]

Le premier levier d'un projet et son management, sa plus grande qualité est sa capacité à faire avec son environnement

Je suis en phase avec ça et c'est justement le propos du topic !!!
L'idée est d'identifier les qualités/compétences/comportements/personnalités cohérentes avec la mise en place d'une organisation projet Agile et cela, par fonction.

Autrement dit, tu auras beau monter l'équipe de développement la plus agile possible, si ton client n'est pas prêt pour ce mode fonctionnement, ton projet va se casser la gueule
Cela est totalement indépendant des qualités professionnelles de chacun.

L'idée est juste d'identifier les prérequis et les freins à la mise en place de l'Agile et de mettre cela en corrélation avec les profils des acteurs du projet.

[Laurent 1973]

L'attitude de trouver un "responsable" à un problème, je ne la trouve pas du tout Agile justement.

En agilité, on aura tendance à analyser des points de blocage en terme de fait, pas en terme de "coupable".
L'erreur est humaine et on est tous susceptible d'en faire, inutile d'épingler un tel ou un tel pour tel ou tel attitude.

Par contre, la bonne démarche Agile, à mon sens, est justement d'analyser sereinement ensemble des fait.
Sans chercher de responsable, rechercher des causes à cet état de fait et réfléchir ensemble à une action pour y remédier.
Pour ça, il est important essentiellement de bien communiquer.

Les profiles que l'on nous présente me semble aussi regorger de grandes compétences.
Il ne faut pas chercher à les exclure, on a tous nos petits défauts, mais au contraire les aider à progresser pour que ces défauts puisse aussi se transformer en force pour les projets et les équipes.

Le premier levier d'un projet et son management, sa plus grande qualité est sa capacité à faire avec son environnement

Dans le monde de l'agilité, on veux aussi tendre à avoir du management sans manager: l'auto-organisation et le Management 3.0 (http://fr.slideshare.net/cecileauret...-franais-vue-1).

Et puis, on peux faire un peu évoluer son environnement, sur des petits points simples compris dans notre périmètre.
Par exemple, comme l'ouvrier de chez Toyota, qui déplacera sa boite de boulons à gauche plutôt qu'à droite ... parce que c'est plus simple pour lui et pas besoin d'un grand chef pour lui dire comment organiser son poste de travail.

[Saverok]

Les profiles que l'on nous présente me semble aussi regorger de grandes compétences.
Il ne faut pas chercher à les exclure, on a tous nos petits défauts, mais au contraire les aider à progresser pour que ces défauts puisse aussi se transformer en force pour les projets et les équipes.

Il n'est pas question du "savoir faire" mais de "savoir être"
Le "savoir faire" peut s'acquérir avec de la bonne volonté mais le "savoir être", c'est tout autre chose.
Il est possible de corriger quelques détails à la marge mais la nature revient souvent au galop.

Il ne faut pas oublier que l'Agile est une méthode pour mener un projet à terme, ce n'est pas une thérapie de groupe.
Il y a des jalons à tenir et des livrables à restituer.
Les efforts de l'équipe doivent être orientés vers la réalisation du projet et l'entraide sur les points de comportement d'un membre ne doit pas mobiliser l'attention au détriment du projet.

Tout le monde n'est pas fait pour travailler en Agile.
Cela n'en fait pas du tout de mauvais développeur, loin de là.
Ils sont juste plus à l'aise avec un management plus directif.
Ce n'est pas du tout un jugement, c'est une reconnaissance du tempérament de chacun.

L'Agile n'est pas le but ultime à atteindre qui permet de différencier les "bons" des "mauvais".
C'est une méthode de travail parmi d'autres qui a ses qualités et ses défauts.

[Laurent 1973]

Il n'est pas question du "savoir faire" mais de "savoir être"
Le "savoir faire" peut s'acquérir avec de la bonne volonté mais le "savoir être", c'est tout autre chose.
Il est possible de corriger quelques détails à la marge mais la nature revient souvent au galop.

Il ne faut pas oublier que l'Agile est une méthode pour mener un projet à terme, ce n'est pas une thérapie de groupe.
Il y a des jalons à tenir et des livrables à restituer.
Les efforts de l'équipe doivent être orientés vers la réalisation du projet et l'entraide sur les points de comportement d'un membre ne doit pas mobiliser l'attention au détriment du projet.

Tout le monde n'est pas fait pour travailler en Agile.
Cela n'en fait pas du tout de mauvais développeur, loin de là.
Ils sont juste plus à l'aise avec un management plus directif.
Ce n'est pas du tout un jugement, c'est une reconnaissance du tempérament de chacun.

L'Agile n'est pas le but ultime à atteindre qui permet de différencier les "bons" des "mauvais".
C'est une méthode de travail parmi d'autres qui a ses qualités et ses défauts.

Oui, bien sur que l'Agilité n'est pas une réponse à tout.

On peux être amené à travailler avec un génie techniquement mais humaine impossible à vivre.
Certaine personne sont totalement incompatible avec le travail en équipe voir même avec des exigences économiques et industrielles (et là, indépendant d'Agile ou pas).
Ces mêmes personnes sont parfois imbues d'elles-mêmes au point d'être dans l'incapacité à se remettre en question.

Je pensais juste pour le chacun d'entre nous, avec nos petits défauts, où l'on peux être amené à progresser pour les gommer.
L'agilité n'est pas la seul méthode, bien sur, mais le principe des rendez-vous "rétrospective" est un bon moment pour travailler sur ces petits points sans se sentir mis à banc des accusés.

Et justement, on a souvent des jalons et des livrables à respecter.
On a pas le loisir de pouvoir "remplacer" un tel ou un tel parce qu'il ne rentre pas pile poil dans un "savoir être".
Et parfois, on peux faire évoluer ce petit manque de "savoir être" qui peux être plus simple que de changer le "maillon faible".

Et puis, sans se transformer en thérapie de groupe, l'équipe agile est aussi là pour se sentir aussi bien que possible au travail.

[RedGuff]

La méthode agile déresponsabilise par l'absence de cahier des charges, et les demandes qui changent tout le temps.
Pire, la qualité du code est sacrifiée au profit de nouvelles fonctionnalités mal définies, alors qu'on n'a même pas fini le reste !

[Saverok]

La méthode agile déresponsabilise par l'absence de cahier des charges, et les demandes qui changent tout le temps.
Pire, la qualité du code est sacrifiée au profit de nouvelles fonctionnalités mal définies, alors qu'on n'a même pas fini le reste !

Ton post est une pure caricature
Agile ne veut pas dire anarchie

Ce n'est pas parce qu'une nouvelle demande arrive que tu laisses tout en plan pour débuter une nouvelle tâche

Le périmètre d'un sprint est parfaitement défini lorsqu'il débute
Lorsqu'une nouvelle demande arrive, elle est planifié pour un sprint ultérieur.

Pour ce qui est de la qualité du code, elle est maîtrisée par les outils d'intégration continue exactement comme pour un projet d'une autre méthode.
La qualité du code est une affaire de concepteurs / développeurs totalement indépendante de la méthodologie projet.

J'ai eu l'occasion de voir des horreurs sur des cycles en V et des merveilles d'architectures logicielles sur de l'Agile.

Reporter la faute sur la méthodologie projet est une excuse de déresponsabilisation.

[Laurent 1973]

La méthode agile déresponsabilise par l'absence de cahier des charges, et les demandes qui changent tout le temps.
Pire, la qualité du code est sacrifiée au profit de nouvelles fonctionnalités mal définies, alors qu'on n'a même pas fini le reste !

A mon avis, tu ne faisais pas de l'Agile mais c'est ce que tes manager t'a fait croire pour faire des coupes franches sur la qualité (ainsi, si c'est nul, c'est la faute de la méthode)

Pour rappel, quelque principe que tout projet en mode Agile doit avoir:

Principe N°1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Principe N°7:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Un logiciel opérationnel est la principale mesure d’avancement.

Principe N°9:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

Voir: http://agilemanifesto.org/iso/fr/principles.html