Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Amine Horseman

41PARTAGES

13  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 17/11/2014 à 23:28
Citation Envoyé par Amine Horseman Voir le message
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.
18  6 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 18/11/2014 à 13:18
Citation Envoyé par Sodium Voir le message
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).
10  0 
Avatar de brulain
Membre régulier https://www.developpez.com
Le 18/11/2014 à 10:59
Effectivement, il n'est pas simple ni facile de rendre un parpaing agile.
8  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 18/11/2014 à 11:56
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
8  0 
Avatar de
https://www.developpez.com
Le 18/11/2014 à 13:49
Citation Envoyé par Sodium Voir le message
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
7  0 
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 18/11/2014 à 13:58
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.
7  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 18/11/2014 à 11:02
Citation Envoyé par Sodium Voir le message
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 ?
8  2 
Avatar de Serge Mazille
Membre du Club https://www.developpez.com
Le 18/11/2014 à 12:10
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
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 26/11/2014 à 10:33
Citation Envoyé par gangsoleil Voir le message
Bah oui, mais moi je bosse avec des humains... Et le système pyramidal, j'en ai bien bien vu les limites :
  • Mon chef, manager de 12 personnes, unanimement reconnu comme extrêmement compétent (aussi bien par les dev que par la hiérarchie), n'a jamais été plus haut, car il disait ce qu'il pensait -- et il a donc dit un jour qu'une décision n'était pas la bonne, avec arguments. Soucis : le type qui a pris la décision était un bon ami des hauts placés.
  • Mes N+2 : j'en ai vu 3 ou 4 en 5 ans dans une seule entreprise, je ne sais même plus. Entre celui qui ne disait pas bonjour aux grouillots (sur 14 dans l'open space, il disait bonjour aux 2 chefs), celui qui faisait des choix techniques aberrants (mais qui lui permettaient de "jouer" avec le matériel), etc... Et absolument aucun ne défendait ses sous-fifres.
  • Dans un grand groupe, les chefs, même au plus bas niveau, sont plus difficiles à joindre que l'administration française, car ils sont réellement tout le temps en réunion.
  • Et je ne pense pas que la segmentation du travail soit une bonne chose : dans une entreprise, il y avait un service documentation qui rédigeait les docs utilisateur. Et ce rédacteur technique avait parfois des questions sur les logiciels, donc il venait voir les devs, ce qui nous prenait environ 5 minutes de temps en temps, et en plus il était sympa, donc tout allait bien. Et puis un jour, le chef des dev n'a pas supporté que le rédacteur vienne poser une question - la question de trop visiblement, et donc il a demandé à ce que la voie pyramidale soit respectée : lorsque le rédacteur a une question, il la pose à son chef, qui transmet au chef des développeur, qui choisit à quel développeur il transmet la question. Celui-ci doit alors répondre par mail à ce même chef, qui transfert au chef du rédacteur, qui transfert au rédacteur.

Résultat : une doc pourrie car plus d'interaction, une ambiance pourrie, et bien sur le rédacteur qui est allé voir ailleurs, donc en fait plus de doc.

  • etc etc etc


Donc oui, je pense que si tout le monde était beau, gentil, compétent à la place qu'il occupe, et s'occupait de son poste, alors le système pyramidal serait peut-être quelque chose de bien. Mais là, non, c'est vraiment pas le pied, donc oui, je trouve que tout système qui a tendance à applatir cette pyramide pour que les gens puissent s'exprimer, c'est une bonne chose.
Mais pourquoi je suis toujours d'accord avec toi. Pourquoiiiiiiiiiiiiiiii?????

Le truc le plus important, je crois, c'est la qualité de la communication. Avant même la compétence des gens, leur motivation, ou leur capacité de remise en cause(qui sont pourtant des facteurs essentiels). On est pas à l'armée ou les informations à passer sont simples(3 hostiles au deuxième étage - demande appui!) et ou le respect de la chaine hiérarchique complète est essentiel. La communication, dans nos domaines, ne peut pas se permettre la moindre approximation. Or, à chaque intermédiaire, à chaque passe-plat, on introduit des risques d'approximation ou d'oubli.

Le genre de communication qu'on a, c'est du genre "il faut dispatcher les paiements entre TIP, virement, et chèque. LE TIP est prioritaire, sauf si montant supérieur à 1 million". Sauf que généralement sont oubliés plein de détails, comme "1 million inclus, ou exclus?" "Quelle priorité entre virement et chèque? Si on ne vient pas d'un TIP au montant trop élevé? Et si on en vient?". Et caetera. Sur un bête aiguillage tout con, on se retrouve déjà avec plein de subtilités.

Si on passe par la chaine hiérarchique complète, ce genre de subtilités passe complètement à l'as. Le grand chef a autre chose à foutre que de gérer ce genre de détails(et c'est parfaitement légitime, ce n'est pas son rôle). C'est la première raison pour laquelle il faut communiquer directement entre sachants, sans se farcir 7 étapes intermédiaires.

La deuxième raison, c'est qu'en plus, ça permet de comprendre pourquoi. Quand un programmeur sait pourquoi il doit faire une chose, il anticipera facilement plein de détails. Par exemple, la limite du TIP à 1 million, j'ai fini par l'apprendre, était due à la taille du pré-imprimé : 6 caractères avant la virgule. Donc ça n'était pas du tout un caprice, et ça répondait aussi mécaniquement à la question de savoir si la limite était inclusive ou exclusive(et à 2 ou trois autres, parce-qu'en fait le cas était beaucoup plus compliqué).

La segmentation du travail est une catastrophe dans notre domaine parce-que justement elle éparpille la connaissance, et la maitrise qui va avec. A mon sens, il ne doit jamais y avoir plus de trois intervenants sur le chemin d'un élément(correction, évolution, morceau de projet) : Métier, Réalisation, Tests. Quitte à découper dans l'autre sens, et avoir plein de gens différents sur plein de sujets différents. A l'extrême rigueur, le métier peut être représenté par une MOA, mais les réalisateurs et les testeurs doivent quand même avoir accès au vrai métier.

Sinon? Sinon, ben personne ne comprend rien, et des gens très compétents se plantent, parce qu'ils n'ont pas saisi toutes les subtilités du projet.
6  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 18/11/2014 à 11:37
Citation Envoyé par Sodium Voir le message
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.
6  1