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

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 !

Le « DevOps » et le développeur « FullStack » mettraient en danger le métier de développeur
Le constat inquiétant de Jeff Knupp

Le , par Arsene Newman

156PARTAGES

2  1 
Jeff Knupp est un développeur chevronné basé à New York, aujourd’hui il revient dans un billet de blog sur les deux grandes tendances actuelles du développement logiciel à savoir : le concept de « DevOps » et le développeur de type « FullStack », ainsi que sur le danger qui guette le métier de développeur suite à l’avènement de ces tendances.

« Le DevOps est un concept qui vise une collaboration plus étroite et une combinaison des différents rôles impliqués dans le développement logiciel comme le rôle de développeur, de chargé d’opération ou encore de chargé d’assurance qualité, car les logiciels doivent être produits à un rythme effréné alors qu’au même moment le développement en cascade semble avoir atteint ses limites. »

« L’accroissement des responsabilités du développeur a donné lieu à un futur métier chimérique : le développeur « FullStack », un tel développeur est en mesure d’être le développeur, le chargé d’assurance qualité, l’analyste des opérations, l’administrateur système/BDD. »

« Mais alors d’où viennent ces concepts ? Des startups, mais aussi des adeptes des méthodes agiles. Dans le cas des startups, elles ont besoin de fonctionner de la sorte pour pouvoir survivre les premiers temps, malheureusement ces divers rôles techniques qui sont à la charge du développeur au sein d’une startup par manque de ressources, sont en passe de devenir le minimum requis pour un développeur. »

Alors, la question suivante surgit : Pourquoi le développeur peut jouer autant de rôles différents ? La réponse est simple selon Knupp : « Il existe une hiérarchisation des différents rôles prenant part au développement logiciel. Le développeur est au sommet de cette hiérarchie, suivi par l’administrateur système/BDD. Les chargés d’assurance qualité, des opérations et les coordinateurs de releases constituent la base de cette hiérarchie. »

Son explication ne s’arrête pas uniquement à cela : « Parce que chaque rôle est en mesure de faire le travail des rôles qui lui sont inférieurs dans la hiérarchie. Les startups nous l’ont appris. Mais cela ne marche pas dans le sens inverse, car les rôles inférieurs ne disposent pas du savoir-faire requis pour accomplir certaines tâches »

Quel est donc le danger qui guette le métier de développeur ? Pour le blogueur la réponse est évidente : « Quand le développeur est affecté à d’autres rôles, il n’y a plus personne pour assurer le développement ! » en même temps « Aucun des autres rôles, même lorsqu’ils sont combinés ne sont pas en mesure d’assurer le rôle de développeur ».

Cela conduit entre autre à la non-spécialisation du rôle de développeur, hors pour Knupp : « Nous sommes spécialisés pour une seule raison : les êtres humains ne sont pas capables de retenir autant de connaissances. Sans oublier que le basculement entre les rôles est coûteux pour le cerveau humain.» De plus, forcer les développeurs à prendre en charge des tâches supplémentaires normalement affectés à des spécialistes les conduit à :
  • Ne plus accorder autant de temps au développement ;
  • Gérer une quantité d’informations et de connaissances trop volumineuse ;
  • et enfin à Exploser.


Au final il est urgent de réagir face à cette situation et surtout de « Laisser les développeurs coder », de plus « il apparaît que les entreprises agissent comme si elles étaient des startups » hors « Toutes les entreprises ne sont pas des startups, les startups n’ont pas fait des développeurs des hommes à tout faire par choix, mais par nécessité. »

Source : Blog de Jeff Knupp
Et vous ?
Pensez-vous que le « DevOps » est une bonne chose pour le métier de développeur ? Pourquoi ?
Que faut-il faire pour endiguer ces tendances selon vous ?

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

Avatar de azias
Membre éclairé https://www.developpez.com
Le 22/04/2014 à 9:41
J'ajouterais que le danger n'est pas seulement côté développeur mais aussi du côté de l'entreprise. Je me suis retrouvé dans une situation dans laquelle je me suis retrouvé à, pour ainsi dire, tout faire (j'ai même été l'unique salarié pendant plusieurs mois). Au bout d'un moment: ras le bol de faire le travail de deux ou trois personnes et d'être payé comme un débutant. Je suis parti et l'entreprise n'a pas survécu à mon départ.

Même en imaginant que le salarié le supporte bien, quand on concentre trop de compétences et de responsabilités sur une seule personne, l'entreprise se met elle-même en danger. Je crois qu'on a déjà tous vu des développeurs (et pas seulement des développeurs) agréger volontairement un maximum de responsabilités sur eux-même et écrire le minimum de documentation (voire rien du tout) pour se rendre quasiment invirable. C'est pourtant généralement ceux-là dont on voudrait se débarrasser.
4  0 
Avatar de Pierre-Yves Le Dévéhat
Membre régulier https://www.developpez.com
Le 18/04/2014 à 20:12
Citation Envoyé par Arsene Newman  Voir le message
[B][SIZE="4"]
Cela conduit entre autre à la non-spécialisation du rôle de développeur, hors pour Knupp : « Nous sommes spécialisés pour une seule raison : les êtres humains ne sont pas capables de retenir autant de connaissances. Sans oublier que le basculement entre les rôles est coûteux pour le cerveau humain.» De plus, forcer les développeurs à prendre en charge des tâches supplémentaires normalement affectés à des spécialistes les conduit à :
  • Ne plus accorder autant de temps au développement ;
  • Gérer une quantité d’informations et de connaissances trop volumineuse ;
  • et enfin à Exploser.

Une chose est sûre : on ne peut pas être à la fois un "développeur chevronné basé à New York" et un expert en neurologie et autres sciences du cerveau et de la mémoire ! On nage dans les affirmations gratuites fleurant bon l'amateurisme.
Il reste largement à prouver que le "basculement" dont il est notamment question est "couteux" alors que les observations dans le milieu du travail en général ont largement prouvé depuis des lustres que la diversité est psychiquement bénéfique.
Pour ce qui est de retenir des connaissance, il faut se garder de considérer la mémoire comme un vase qui connaitrait une limite. Il s'agirait bien plutôt de l'inverse encore une fois : plus on apprend, plus notre cerveau est disposé à apprendre, c'est notable dans l'apprentissage des langues par exemple. Il me parait bien plus juste de considérer que la diversité des schémas de savoir développe d’avantage cette capacité à assimiler ainsi que les aptitudes créatives.
4  1 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 19/04/2014 à 0:34
En tout cas, quand je vois les annonces d'emploi, j'ai l'impression que l'on demande de plus en plus de chose au dév., j'en ai même vu où ça ressemblait plus à un mouton à 18 pattes (ex : spec, dév., base de données (remplir), graphiste, rédaction, traduction, communication sur les réseau sociaux, contact client, etc.) Je vois pas comment on peut réussir à tout faire correctement. Je vois bien ce que ça a donnée dans une petite boîte où j'avais tellement de casquettes, que le dév, c'est limite plus possible de l'assurer.
2  0 
Avatar de Blopss
Candidat au Club https://www.developpez.com
Le 19/04/2014 à 7:20
Salut,
Je crois qu'il n'y a pas besoin d'être dev "fullstack" ou de faire du DevOps pour être un developpeur submergé. Pierre-Yves a raison quand il dit que la diversité a du bon, par contre quand on switch de projet voire de type de tâche toutes les 15 minutes (si c'est pas 5), c'est invivable à long terme, et il n'y a pas besoin d'avoir fait du scrum pour être au courant.

A mon avis ce ne sont pas ces méthodes émergentes qui sont fautives, c'est le rythme. Il me semble qu'on peut faire du developpement agile sans être stressé (c'est même censé être un des buts à la base de la méthodo non?) et qu'on peut être stressé sans faire d'agile. Aujourd'hui le temps "réglementaire" n'est souvent pas laissé aux dev (aux genx) pour entrer dans leur tâche, et ils sont bien trop souvent interrompus.

Le bouquin "Rework" de 37Signals evoque entre autres l'idée de laisser aux développeurs des plages horaires fermées, où ils ne peuvent pas être interrompus : pas de demande de la part du pm, pas de réunion, pas de pause café, etc. Je rêve qu'on mette en place ce système là où je bosse...

Note : à la fin de l'article, il y a deux fois la même faute, "hors" à la place de "or".
2  0 
Avatar de ptah35
Membre éclairé https://www.developpez.com
Le 21/04/2014 à 11:18
Prétendre que les différents métiers de l'industrie du logiciel forment une hiérarchie, au sommet de laquelle se trouve celui de développeur est absurde. Bien sûr qu'un développeur doit avoir quelques compétence s'agissant des bases de données et des SGBD et qu'il doit être capable de produire des tests pour son code, mais les compétences nécessaires pour utiliser (ou même modifier une base de données) ne constituent pas, et de loin, l'ensemble des compétences nécessaires à l'administration de plusieurs dizaines de base de données par un DBA. De la même manière, peu de développeurs ont les compétences requises pour la mise en place d'une forge logicielle complexe, choisir une politique adéquate et la renforcer cette politique par tous les moyens à disposition. Tous doit avoir quelques compétences dans les autres métiers, ces compétences permettent à chacun de tenir compte des contraintes des autres et de rendre ainsi le processus plus fluide.
2  0 
Avatar de epsilon68
Membre expérimenté https://www.developpez.com
Le 23/04/2014 à 1:23
Je crois que de toutes facons on n'a plus le choix, et puis c'est ce qui peut nous differencier des indiens et de l'offshore en general. Ils sont souvent dédiés pour une seule tâche, ce qui fait qu'ils sont un peu perdu quand il faut maitriser plusieurs techno...

Maintenant, je suis d'accord, a force de tout faire, on finit par s'y perdre. Aussi on se rend compte que les autres ne font pas forcement autant et c'est assez frustrant. On se voit tout le temps debordé et finalement les autres ont la vie plus cool.

D'autre part, le plus gros probleme c'est pour les vacances. Aucun probleme pour le soi-disant chef de projet, mais pour nous, ce n'est jamais le bon moment, on est devenu une ressource critique... Grrr
2  0 
Avatar de ilalaina
Membre habitué https://www.developpez.com
Le 25/04/2014 à 10:44
Le problème c'est que les recruteurs ne savent même pas qui est censé faire quoi. Parfois même dans leurs annonces ils recrutent des "Informaticiens". Et suit ensuite une description de poste de 3 pages.
2  0 
Avatar de dahtah
Membre éclairé https://www.developpez.com
Le 19/04/2014 à 10:51
En meme temps, y'a beaucoup de conneries dites sur le modele devops. Devops ca veut pas dire que tout le monde fait tout, mais que les devs et ops font partie de la meme equipe. Les specialites restent. C'est pas aprce qu'un gars de ops fait partie d'une equipe devops qu'il se met soudain a faire du dev pur.

L'utilite de devops, c'est que ca permet de prendre en compte les contraintes operationelles au debut des cycles de devs. Ca evite aussi, les "je mets en production sans gerer le passage a l'echelle", les gars de ops vont se lever a 3 heure du mat pour gerer tout ca. La responsabilite en cas de probleme comme de succes est partagee.

On applique ce modele au taf (je bosse pour une tres grosse boite, pas une startup), et ca marche plutot bien je trouve. On a change plusieurs designs des le debut a cause de contraintes operationnelles auxquelles on aurait pas pense.
1  0 
Avatar de Heptaeon
Membre habitué https://www.developpez.com
Le 19/04/2014 à 22:31
Est ce étrange qu'un développeur voie une hiérarchie où le développeur est au sommet ?

Faire un peu de tout dans le but de comprendre l'autre, je trouve ça normale. Et ça n'empêche pas de se spécialiser dans son domaine préféré. Avoir le développeur et le DBA qui refuse de se comprendre l'un l'autre, ça se vois que trop souvent et c'est bénéfique pour personne...
1  0 
Avatar de dlusignan
Nouveau membre du Club https://www.developpez.com
Le 20/04/2014 à 15:40

A l'inverse, si l'on demande une nouvelle fonctionnalité, je vois mal la chaîne:
- le DBA bidouille la DB
- le programmeur serveur récupère/insère en DB les données (déjà, il doit connaître de la DB, donc la casquette DBA prend son sens)
- le programmeur serveur envoit les données au client
- le programmeur client récupère les données du serveur (qui mieux placé sur le programmeur serveur pour connaître les données ? puisque c'est lui qui les envoit)
- le programmeur scripting récupère les données du client via l'interface de scripting (là encore, le programmeur client est bien placé, c'est lui qui les crée)
Donc que toute cette chaîne soit réalisée par une unique personne a du sens amha..
Le développeur "FullSatck" est un phénomène de "StartUp". La structure que tu viens de définir s'applique très bien par contre au sein d'une grosse équipe de développement. Pour un ERP, par exemple. Sinon, même au sein d'une grosse équipe de dev, le développeur est supposé pouvoir faire tout ça dans son environment de développement. Mais pour la production, il n'y a rien d'anormale à devoir travailler avec un DBA et un SysAdmin.
1  0