Discussion :

[Amine Horseman]

Jusqu'à quand les entreprises gêneront-elles le développement agile ?
L'organisation au sein de celles-ci serait beaucoup trop rigide

Dans son article intitulé « Apporter l’Agilité à toute l'organisation », Jeff Gothelf, le dirigeant de l’équipe de designers de TheLadders et Web Trends, critique le fonctionnement des entreprises d’aujourd’hui, qui utilisent les méthodes de développement agile, mais continuent de gérer leurs équipes avec rigidité.

Selon lui, avec les méthodes agiles, nous sommes en mesure de déployer des produits rapidement, optimiser le travail des équipes, accélérer les prises de décisions et mesurer les écarts au jour le jour pour éviter de perdre du temps dans le développement de fonctionnalités inutiles. Cependant, l’organisation interne du personnel, des fonds, des récompenses et des rémunérations doit aussi se mettre dans le même niveau d’agilité, pour ne pas perturber le potentiel d’exécution de l’équipe de développement.

Les processus de recrutement de personnel dans les entreprises d’aujourd’hui par exemple suivent tous un schéma identique, et le fait de dresser des profils de personnes pour ne recruter que les éléments qui correspondent à tel ou tel profil pourrait poser problème. En effet, les sociétés doivent toujours rechercher les créatifs non-conformistes. Ce genre de candidats qui ne correspondent à aucun profil. Ce sont ces généralistes bricoleurs multifacettes qui poussent toujours les chefs d’équipes à repenser leurs produits ou services. Et le problème, c’est que c’est difficile de les distinguer de la masse dans un entretien ou dans un test de connaissances.

Mais les détecter et les embaucher n’est pas la seule difficulté. Il faudra aussi savoir comment les garder dans l’équipe et les inciter à travailler, car selon Jeff Gothelf, « la compensation financière n’est pas le principal facteur de motivation pour ces personnes ». En effet, elles cherchent souvent à créer quelque chose de significatif dans leur travail, d’où la nécessité de repenser les stratégies de récompenses et de rémunération du personnel.

Aussi, il faudra changer les processus de prise de décisions dans le niveau entrepreneurial. Ces décideurs qui essaient toujours de couvrir les risques pour rassurer les investisseurs sont souvent très lents à réagir face au feedback des clients. « Faire des erreurs ne doit pas être un crime capital. Au lieu de cela, les erreurs devraient être rapidement analysées et de nouvelles informations devraient être intégrées dans la prochaine série de tactiques ».

En parlant de tactiques, « les équipes ne devraient pas être la préoccupation des gestionnaires ». Ces derniers devraient plutôt se concentrer sur les progrès réalisés et ne plus opter pour des stratégies qui favorisent la prévisibilité et la sécurité au détriment de l’agilité.

Comme conclusion, l’auteur de l’article préconise qu’on doive changer la façon dont nous gérons les entreprises, et ceci pour favoriser : la réactivité dans les prises de décisions, l’agilité dans les modes de financement et la création d’un environnement d'apprentissage continu alimenté par la connaissance du client et son feedback.

Source : Harvard Business Review

Et vous ?

Qu’en pensez-vous ?

[Bousk]

Qu’en pensez-vous*?

Qu'Agile c'est juste le mot-clé du moment pour faire hype/in et se mettre en avant pour se vendre.
Demander aux entreprises de gérer l'humain ? Trop compliqué, elles préfèrent gérer des chiffres et ressources.

[el_slapper]

Je serais moins langue de vipère que Bousk, mais force est de reconnaitre que la majorité des démarches agiles en entreprise n'ont d'agile que le nom.

De plus, si celà est tout à fait adapté comme discours aux éditeurs de logiciels, ça me parait branlant chez un banquier, par exemple. Le banquier préfèrera 10 médiocres qui avancent peu mais sans faire de vagues plutôt qu'un super qui fera 3 fois plus à lui tout seul, mais prendra des initiatives incontrôlées. L'image du créatif, chez un banquier, c'est Jérôme Kerviel. Ce qui n'est pas une image très positive...

a compensation financière est pas le principal facteur de motivation pour ces gens

Là, par contre, je suis d'accord à 100% . Je connais un ingénieur système de très haut niveau qui a changé de boite pour un boulot moins intéressant et pas à la hauteur de son talent, qui a perdu 800 euros mensuels dans l'affaire, tout ça pour qu'on lui foute la paix et qu'on le laisse bosser tranquille.

Mais là encore, ça ne s'applique pas à tous les profils de boite. Là ou un haut niveau de contrôle est nécessaire, peut-être vaut-il mieux le laisser partir pour avoir quelqu'un de plus malléable. Hélas pour nous ça n'est pas notre cas.

[Washmid]

[B]
[...]
Les processus de recrutement de personnels dans les entreprises d’aujourd’hui par exemple suivent tous un schéma identique, et le fait de dresser des profils de personnes pour ne recruter que les éléments qui correspondent à tel ou tel profil pourrait poser problème. En effet, les sociétés doivent toujours rechercher les créatifs non-conformistes. Ce genre de candidats qui ne correspondent à aucun profil. Ce sont ces généralistes bricoleurs multifacettes qui poussent toujours les chefs d’équipes à repenser leurs produits ou services. Et le problème, c’est que c’est difficile de les distinguer de la masse dans un entretien ou dans un test de connaissances.

Mais les détecter et les embaucher n’est pas la seule difficulté. Il faudra aussi savoir comment les garder dans l’équipe et les inciter à travailler, car selon Jeff Gothelf, « la compensation financière n’est pas le principal facteur de motivation pour ces personnes ». En effet, elles cherchent souvent à créer quelque chose de significatif dans leur travail, d’où la nécessité de repenser les stratégies de récompenses et de rémunération du personnel.
[...]

Un :
- "créatif non conformiste", ou "généraliste bricoleur multifacettes"
- qui ne recherche pas l'argent mais la "création"
- qui a tendance à change de boulot comme de chemise
- qui a tendance à être mal vus par la hiérarchie parce qu'ils passe beaucoup (trop) de temps à suggérer (ou "proposer", "critiquer", "râler" suivant le point de vue)

En psychologie, ça fait furieusement penser à un zèbre, c'est à dire plus ou moins 2% de la population. Bref, bonne chance aux recruteurs

[Sodium]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

[brulain]

Effectivement, il n'est pas simple ni facile de rendre un parpaing agile.

[dfiad77pro]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Y'a une nuance à avoir tout de même quand on voit que certaines entreprises mettent 6 mois à mettre en production un correctif de bug sur un appli non critique, c'est inadmissible. ( je parle d'un correctif très simple, pour un bug gênant pour l'utilisateur)

Bon la suite de mon post est un peu stéréotypée

Certains processus justifiés il y'a 15 ans ne le sont plus forcément maintenant.

Le développement a évolué, les tests aussi.
Y'a des chercheurs qui ont bossés sur des technos d'intégration, des technos productives....

Trop d'intermédiaire tue la productivité et l'implication du développeur :


Ingénieur de DEV ---> Manager --- > Chef de projet SI --> MOA --> Chef de projet Métier --> Métier

Cette chaîne de communication ( cyclique) est bien réelle et même simplifiée ( et non issue d'une SS2I, donc en interne) ...
Ce qui fait que presque aucune information n'arrive rapidement au DEV ( et encore par fois elle se perd) à par un dossier de SPEC qu'il faut renvoyer 200 fois (
Et ils te prétendent faire de l'agile...

Ce genre de chaîne à rallonge donne aucun pouvoir à l’ingénierie de développement !

Ce n'est pas faire preuve de prudence que de ne pas changer les process caduques !

Et là je sens les arguments du genre : "T'est trop jeune , t'a pas d’expérience et de recul".

Je rappel qu'à 27 ans on commence a se sentir vieux lorsqu'on voi certains commerciaux de SS2I qui font du recrutement à moins de 24 ans !

Certes, mais alors :
- pourquoi les seniors sont t'ils fortement touchés par le chaumage, c'est eux qu'on devraient embauché ?
- pourquoi grand nombre de développeurs perdent leur passion et ne touchent plus une ligne de code ?

[Traroth2]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Désolé, mais c'est juste n'importe quoi, ça.

[Saverok]

A la fois, je partage l'analyse de l'article et même temps, je le trouve très / trop sévère
Il n'est pas évident de tout changer d'un coup

La conduite du changement, ça vous dit quelque chose ?

Tout ne peut pas être changé d'un coup, il faut y aller petit à petit
L'agilité, plus qu'une méthode, c'est un état d'esprit et ça prend beaucoup plus de temps à changer qu'une "simple procédure"

Quand je propose de l'agilité à mes clients, la première question qu'on me pose est "est-ce que ça ne va pas faire exploser le budget ?" et celle qui vient juste après est "est-ce qu'on tiendra les délais ?"
D'expérience, avec l'agilité, on se retrouve souvent avec un projet moins complexe (moins de fonctionnalités, des actions plus simples et plus directes) avec une meilleure qualité et une meilleure adhérence de la part des utilisateurs pour un budget presque identique.
Faire comprendre aux clients qu'ils auront moins mais mieux n'est pas évident
C'est une démarche qui prend du temps

Au niveau de la gestion RH, c'est la même chose, l'adaptation prend du temps
En agile, la hiérarchie est gommée et les développeurs sont fortement impliqués dans la conception et l'évolution du projet
Il est évident qu'ils ne peuvent plus être managés comme avant (et ce n'est pas un mal, bien au contraire)

Au niveau de la nécessité d'avoir des créatifs, je ne suis pas d'accord
Je pense surtout qu'il faut des gens avec un grand sens critique et cela requière de l'expérience, du vécu
L'agilité réclame une équipe majoritairement senior car la conception et le dev sont intimement liées et cela nécessite de l'expérience pour le mettre en oeuvre et le frontal client quotidien implique de bien comprendre les demandes, les besoins et les envies du client non seulement pour leur donner corps mais aussi pour les devancer et être force de proposition pour les enrichir et il n'y a que le vécu qui permette cela.

Un "créatif" risque de brouiller le client plus qu'autre chose
Sans oublier que lorsqu'il y a plusieurs "créatifs", ils ont tendance à se tirer la bourre plutôt que d'avancer dans le même sens
D'expérience, les "créatifs" n'ont à intervenir que lors de l'expression du besoin ensuite, le seul qui reste est le "product owner" autour de qui la construction du projet va se faire

[Serge Mazille]

Sodium :

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Mouais... C'est très généralisé tout ça... J'imagine que tu as eu de mauvaises expériences, mais associer 'Manque de compétences techniques' et créativité c'est

Washmid :

En psychologie, ça fait furieusement penser à un zèbre, c'est à dire plus ou moins 2% de la population. Bref, bonne chance aux recruteurs

C'est exactement la réflection que je me faisais

[Sodium]

Mouais... C'est très généralisé tout ça... J'imagine que tu as eu de mauvaises expériences, mais associer 'Manque de compétences techniques' et créativité c'est

Les faibles compétences entraînent un manque de recul sur ce que l'on ignore d'un domaine. Cela conduit à une surestimation de ses compétences / compétences des collègues et une méconnaissance des obstacles techniques.

[Saverok]

Les faibles compétences entraînent un manque de recul sur ce que l'on ignore d'un domaine. Cela conduit à une surestimation de ses compétences / compétences des collègues et une méconnaissance des obstacles techniques.

Oui, mais où est le rapport avec la créativité ?

On peut être créatif et compétent
L'un n'empêche pas l'autre

Mon côté manager de projet fait que je recommande du grand classicisme dans le développement.
Un code trop "original" est souvent complexe à lire et difficilement maintenable.
Pour le code, mieux vaut faire simple et clair car le code continue de "vivre" une fois le projet terminé (TMA).

[Invité]

De ce que j'ai pu observer dans le monde professionnel, les soi-disant créatif sont généralement des gens :
- Déconnectés des limitations induites par le budget alloué au projet
- Déconnectés du processus de production. Ils ne mettent jamais la main dans le cambouis et ont donc une méconnaissance totale des difficultés techniques engendrées par certaines idées et par des changements de dernière minute sur un code propre et solide
- Manquent de compétences techniques. Une personne peu compétente dans un domaine a tendance à ne pas se représenter ce qu'elle ignore de celui-ci et donc de sa complexité, ils peuvent donc se montrer trop optimistes quant à la faisabilité en temps et en heure, ou même la faisabilité tout court d'une idée

Les deux derniers points correspondent tellement à mon ancien ... patron

[LSMetag]

D'un autre côté, les recruteurs, pour la plupart, ne cherchent que des profils conformes, maléables. Je fais partie de ces profils anti-conformistes, plutôt créactifs et réactifs, donc les objectifs sont de satisfaire et se satisfaire.

Même quand on parle d'agillité, dans presque tous les cas, on se retrouve avec un système rigide avec plein d'intermédiaires et en effet des mois s'écoulent entre la proposition de correctif que tu as fait, sa mise à l'ordre du jour, et surtout sa livraison au client.

Il n'y a que dans une seule entreprise où j'ai fait du vrai agile. Seulement, c'était une SSII qui faisait à la fois de l'interne et de l'assistance technique. J'ai fait 3 mois d'interne, c'était bien, mais dès que je suis arrivé en clientèle, de nouveau la rigidité.

Je ne peux faire de l'agile que quand c'est moi qui gère des projets annexes, où je dialogue directement avec la source du besoin et les utilisateurs. On me fait une demande approuvée par celui qui énonce le besoin, je la note et je la fais si ça n'empêche pas d'être dans les délais. Sinon j'explique.

Et pour les bugs, normalement, on ne doit jamais te dire QUAND et SI corriger un bug. Tu le signales au chef, on le note dans le bugtracker, quelqu'un le prend en charge dès qu'il peut et puis c'est tout ! Pareil pour une erreur dans les spécifications ou une demande incongrue. Tu discutes directement avec l'auteur du besoin et ton supérieur pour comprendre le pourquoi du comment et ajuster si nécessaire.

Evidemment tu rends compte de tout à ta hiérarchie.

Après j'imagine qu'il faut avoir les pieds sur Terre pour pouvoir bosser en agile car ça implique de faire rapidement dans sa tête un autochiffrage réaliste et de gérer son temps de façon autonome.
Mais pour moi, ce qui compte avant tout, c'est la satisfaction du client. Donc la qualité à la livraison. Si je dois bosser 40h au lieu de 35 pour livrer ce qui est demandé, sans bug, et dans les temps, moi ça ne me gêne pas.

J'ai lu plus haut qu'on pouvait assimiler un mec créatif et agile à quelqu'un qui faisait du code compliqué. Mais le rôle du développeur c'est aussi d'anticiper les besoins futurs et de facilité leur mise en oeuvre. Donc un code conci et efficace, bien commenté et malléable.

C'est la proximité et le dialogue avec les utilisateurs que j'apprécie. Alors quand on se tape des MOE et MOA pour un simple bug et ne parlons jamais à l'utilisateur, c'est très énervant. Surtout qu'après on nous engueule si on a corrigé le bug sans autorisation, même s'il n'y a aucun effet de bord.

Je me qualifie d'électron encadré. C'est à dire que je suis autonome et assure une qualité optimale pour le besoin, en dialoguant avec mon supérieur direct et les sources des besoins.

Je ne trouve jamais ça et je suis alors frustré et démotivé. Résultat, je crée ma propre start-up où je pourrai m'épanouir comme je l'ai décrit ci-dessus.

[gangsoleil]

Mon côté manager de projet fait que je recommande du grand classicisme dans le développement.
Un code trop "original" est souvent complexe à lire et difficilement maintenable.
Pour le code, mieux vaut faire simple et clair car le code continue de "vivre" une fois le projet terminé (TMA).

Etre classique dans le développement ne veut pas dire qu'on n'a pas des idées pour améliorer les choses, ou que l'on ne propose pas du hangement, ce qui est le cas ici si je comprends bien.

Pour moi, le coté créatif, c'et celui qui regarde la machine à café qui est en cours de dev, et qui dit "Et si on ajoutait des modules optionnels simples à brancher qui pourraient faire tout et n'importe quoi ?". C'est comme ça que tu te retrouves avec des machines à café qui proposent des potages à la tomate, et ça se vend.

Et ce côté là n'empèche pas de faire les choses dans les règles de l'art en interne : je suis le premier à gueuler contre les imaginatifs du code, ceux qui savent mieux que le langage comment parcourir une chaîne de caratères (vécu). Et pourtant, je suis le premier à vouloir proposer de nouvelles idées, de modifier certaines choses, tout en restant réaliste : ce n'est pas parce que c'est mal écrit que ça ne fonctionne pas, et vice-versa.

[LSMetag]

Etre classique dans le développement ne veut pas dire qu'on n'a pas des idées pour améliorer les choses, ou que l'on ne propose pas du hangement, ce qui est le cas ici si je comprends bien.

Pour moi, le coté créatif, c'et celui qui regarde la machine à café qui est en cours de dev, et qui dit "Et si on ajoutait des modules optionnels simples à brancher qui pourraient faire tout et n'importe quoi ?". C'est comme ça que tu te retrouves avec des machines à café qui proposent des potages à la tomate, et ça se vend.

Et ce côté là n'empèche pas de faire les choses dans les règles de l'art en interne : je suis le premier à gueuler contre les imaginatifs du code, ceux qui savent mieux que le langage comment parcourir une chaîne de caratères (vécu). Et pourtant, je suis le premier à vouloir proposer de nouvelles idées, de modifier certaines choses, tout en restant réaliste : ce n'est pas parce que c'est mal écrit que ça ne fonctionne pas, et vice-versa.

Parfaitement. Je n'ai aucune honte à utiliser un goto qui me renvoie 10 lignes plus tôt et m'épargne 30 lignes de codes. Ca reste plus lisible, dès lors que c'est commenté. Après évidemment, le goto est à éviter, mais il faut peser le pour et le contre. Si tu as besoin de te déplacer de quelques ligne 1 fois, et que ça permet d'avoir un code simple, c'est pas grave, celui qui maintient sera même plutôt content.

[Sodium]

Oui, mais où est le rapport avec la créativité ?
On peut être créatif et compétent
L'un n'empêche pas l'autre

Le rapport c'est que tout le monde peut être créatif.
Si tu montres un projet à une personne externe à celui-ci, elle trouvera forcément dix façons de l'améliorer.
Il y aura probablement de bonnes idées dans le tas, mais elles seront souvent trop complexes à mettre en place pour l'équipe de production.
Elles pourront par contre sans doute un manager déconnecté des aspects techniques qui ne voit souvent l'équipe de production que comme un frein aux idées nouvelles.
C'est de cette manière que le jeu duke nukem forever a connu le destin qu'on lui connaît par exemple.

[Saverok]

Le rapport c'est que tout le monde peut être créatif.
Si tu montres un projet à une personne externe à celui-ci, elle trouvera forcément dix façons de l'améliorer.
Il y aura probablement de bonnes idées dans le tas, mais elles seront souvent trop complexes à mettre en place pour l'équipe de production.
Elles pourront par contre sans doute un manager déconnecté des aspects techniques qui ne voit souvent l'équipe de production que comme un frein aux idées nouvelles.
C'est de cette manière que le jeu duke nukem forever a connu le destin qu'on lui connaît par exemple.

Connais-tu le principe du brainstorming ?
Le but est de proposer le maximum d'idées, en vrac, sans soucier de la faisabilité ni mettre de frein à la créativité
Ensuite, on fait le tri
Le tout est ensuite de savoir ce qui est pertinent de ce qui ne l'est pas, évaluer la valeur ajoutée de chaque idée ainsi que la faisabilité (difficulté technique de mise en oeuvre et temps)
Ce n'est qu'après, que effectue la conception puis la réalisation
Même parmi les idées non retenues, il se peut (et cela arrive même la plupart du temps) qu'une fraction soit retenue ou encore qu'elles aient permis de nourrir le débat et d'ouvrir des pistes dans des directement inattendues.

Tout ça pour dire qu'être force de proposition ne peut être que positif (que les propositions soient retenues ou non)
Ouvre ton esprit
Ne reste pas cloisonner dans ton carcan technique plein de limites et de frustration

C'est aux chefs de projet, aux architectes, aux concepteurs et à l'ensemble de l'équipe de développement d'évaluer ce qui peut être fait et comment
Dire oui à tout est un profond signe d'incompétence, de même que l'opposé
L'esprit agile est justement fait pour laisser place à l'adaptation et au changement

Personnellement, j'ai déjà eu des clients très créatif et il est vrai que ce n'est pas facile à gérer mais que c'est stimulant !!
Je préfère de loin avoir quelqu'un en face de moi prêt à tenter des choses nouvelles que quelqu'un de fermer dans son objectif et qui ne s'écarte jamais d'un poil des dossiers de spécifications comme s'ils étaient gravés dans le marbre.

L'esprit agile doit être partagé par l'ensemble des acteurs et cela va du client en passant par l'ensemble de l'équipe projet (DP, CP, concepteurs, développeurs front / back, graphistes, etc.) et équipe RH.
L'article du topic met le focus sur la gestion RH et on trouve aussi pas mal d'autres sujets sur l'adaptabilité des clients à ces méthodes. Par contre, on a tendance à ne pas trop parler des équipes de développement qui ne sont pas tjrs prêtes à ces nouveaux modes de fonctionnement.
Beaucoup de développeurs (et ce n'est pas une question d'âge) se sentent rassurer dans les planifications standards avec des listes de tâches bien identifiées et chiffrées longtemps à l'avance. C'est clair, limpide, facile à comprendre, on peut organiser son temps de travail simplement.
L'agilité demande aussi beaucoup d'adaptabilité aux développeurs qui ne connaissent pas leurs tâches au début de chaque sprint. De même, les spécifications sont parfois approximatives et il faut se prendre en main pour aller à la pêche aux infos car il y a une "fusion" de la MOA et de la MOE...

L'agilité est l'affaire de tous

[dfiad77pro]

Connais-tu le principe du brainstorming ?
Le but est de proposer le maximum d'idées, en vrac, sans soucier de la faisabilité ni mettre de frein à la créativité
Ensuite, on fait le tri
Le tout est ensuite de savoir ce qui est pertinent de ce qui ne l'est pas, évaluer la valeur ajoutée de chaque idée ainsi que la faisabilité (difficulté technique de mise en oeuvre et temps)
...

se sentent rassurer dans les planifications standards avec des listes de tâches bien identifiées et chiffrées longtemps à l'avance. C'est clair, limpide, facile à comprendre, on peut organiser son temps de travail simplement.
L'agilité demande aussi beaucoup d'adaptabilité aux développeurs qui ne connaissent pas leurs tâches au début de chaque sprint. De même, les spécifications sont parfois approximatives et il faut se prendre en main pour aller à la pêche aux infos car il y a une "fusion" de la MOA et de la MOE...

L'agilité est l'affaire de tous

Je plussoie, la passion s'entretien avec l'implication du développeur dans le métier.

ça sert à quoi de faire BAC+ 30 si c'est pour recopier des algorithmes tout fait dans des DSFD et ne pas réfléchir

C'est aussi une des raisons de l'échec de l'externalisation de la main d'oeuvre (Inde ou autre pays ) par certaines entreprises :

- Le DSFD coûte très cher à établir et revient souvent à l'entreprise source (langue et psycologie différente, situation du pays différente)
- Le projet final ne correspond pas à la demande le corps exécutant n'étant pas assez proche du métier
- Le codage n'est pas flexible car ils ne prévoient pas les évolutions (lorsqu'on est dans le métier on a souvent du flair pour détecter ce qui potentiellement va changer)


Je pense que l'informatique reste un art, l'homme n'est pas une machine,donc par essence l'informatique ne peut pas être entièrement spécifié (on oublis les lancements de fusée, l'aviation embarqué et le métro bien sûr...)

[LSMetag]

Je plussoie, la passion s'entretien avec l'implication du développeur dans le métier.

ça sert à quoi de faire BAC+ 30 si c'est pour recopier des algorithmes tout fait dans des DSFD et ne pas réfléchir

C'est aussi une des raisons de l'échec de l'externalisation de la main d'oeuvre (Inde ou autre pays ) par certaines entreprises :

- Le DSFD coûte très cher à établir et revient souvent à l'entreprise source (langue et psycologie différente, situation du pays différente)
- Le projet final ne correspond pas à la demande le corps exécutant n'étant pas assez proche du métier
- Le codage n'est pas flexible car ils ne prévoient pas les évolutions (lorsqu'on est dans le métier on a souvent du flair pour détecter ce qui potentiellement va changer)


Je pense que l'informatique reste un art, l'homme n'est pas une machine,donc par essence l'informatique ne peut pas être entièrement spécifié (on oublis les lancements de fusée, l'aviation embarqué et le métro bien sûr...)

C'est aussi la mentalité de nos entreprises (RH et Managers notamment) qui est à revoir. On parle d'agilité pour faire bien, pour faire vitrine, mais on est raremement dans l'agilité. On reste toujours très proche (voire pareil) du cycle en V où justement on met tout le monde dans des cases.

- La MOA écrit la demande soit-disant des utilisateurs,
- la MOE récupère les demandes de la MOA et fait des spécifications, parfois erronnées,
- L'architecte a le droit de réfléchir et de proposer des socles techniques. Il a acquis les compétences pour faire de belles architectures, mais il n'a pas toujours les compétences pour créer des architectures adaptées au besoin... Quand on pond la même architecture pour chaque projet, j'appelle ça du bachotage.
- le manager affecte les tâches à chaque machine à coder.
- L'expert est souvent considéré comme une encyclopédie d'une technologie précise, un développeur amélioré
- Le développeur éxécute. Et on sait tous qu'un ouvrier ça doit faire ce qu'on lui dit, pas réfléchir, sinon c'est du temps et de l'argent perdu...

Tu externalise un morceau de projet au Maroc (par exemple à la SNCF), les personnes vont juste respecter à la lettre les spécifications, sans plus, dans la mesure de leur compréhension du français. Si les spécifications sont erronnées, l'application sera erronnée. Sans parler des questions d'évolution et de maintenabilité dont ils n'ont aucune vision, n'étant pas immergé dans le métier, juste ouvriers moins chers.

Le brainstorming, c'est génial, mais c'est rarement fait...