Discussion :

[Stéphane le calme]

Les ingénieurs logiciels passeraient moins de temps à l’écriture du code
Et plus dans les tâches administratives et autres, selon une étude d'Electric Cloud

Selon une étude menée auprès de 443 ingénieurs logiciels en mars dernier par Electric Cloud, une société privée fournissant des logiciels d'optimisation DevOps, il apparaît que les ingénieurs en logiciels passent plus de temps pour des tâches autres que pour le codage.

Le design et le codage leur prendraient en moyenne 19,1 heures par semaine, contre 22,37 heures en moyenne pour d’autres activités parmi lesquelles : les tâches administratives (5,79 heures), l’attente de la finalisation des tests (3,67 heures), etc.

L'enquête d’Electric Cloud s’est également intéressée à d'autres personnes impliquées dans les processus de développement logiciel, y compris les ingénieurs de tests, les architectes techniques, les chefs de projets et les chefs de produits. L'enquête ne s'est pas limitée aux clients Electric Cloud.

Sans surprise, les ingénieurs logiciels passent plus de temps sur la conception et le codage que les autres personnes interrogées.

Avec un échantillon de 156 personnes, les architectes techniques qui ont répondu au questionnaire sont les seuls à passer presque autant de temps à écrire des lignes de code et à travailler sur le design que les ingénieurs logiciels. Ils y consacreraient 14,3 heures en moyenne par semaine.

Source : Electric Cloud

Et vous ?

Que pensez-vous de ce rapport ? Si vous êtes ingénieur logiciel, vous reconnaissez vous dans ces résultats ?

[vampirella]

Est-ce vraiment la bonne source originel ? Le lien dans l'article renvoie sur une étude du "cloud computing" et non du temps passé sur les divers activités ^^

Ceci dit, qu'appelle-t-on "tâche administrative" ?

[Stéphane le calme]

Ceci dit, qu'appelle-t-on "tâche administrative" ?

Les questions posées aux ingénieurs doivent certainement être en rapport avec les activités clés du cycle de vie d'un logiciel selon le SWEBOK (Software Engineering Body of Knowledge) notamment l'analyse fonctionnelle (analyse des besoins) , l'architecture (schématisation des grandes lignes du mécanisme) , la programmation , les tests, la validation , la maintenance et la gestion de projet( répartition des tâches entre les ingénieurs et respect du calendrier prévu).

A partir de là peux tu faire les rapprochements avec le questionnaire ?

[Pergos]

Perso, j'utilise les temps d'attente de compilation et de tests pour effectuer une partie des taches administratives, et une partie du Brainstorming (dans lequel je comprends aussi la prise de recul sur le code, sur l'application, et sur le jeu de test).
Ca compacte un peu tout ça.

[el_slapper]

N'empêche que fluidifier la compilation et le test(par exemple en donnant des machines plus puissantes), c'est un moyen de gagner du temps et de la productivité. Il y a facilement quelques pour-cents à gagner dans de nombreuses boites qui ne donnent que des brouettes à leurs développeurs.

[sevyc64]

N'empêche que fluidifier la compilation et le test(par exemple en donnant des machines plus puissantes), c'est un moyen de gagner du temps et de la productivité. Il y a facilement quelques pour-cents à gagner dans de nombreuses boites qui ne donnent que des brouettes à leurs développeurs.

Mais malheureux que dis-tu ? Oserais-tu contredire la nécessité pour la secrétaire d'avoir la dernière machine surpuissante à la mode pour faire ses 3 lettres quotidiennes sous Word, passer commande de la tunique dernier cri sur La Red**** ou des dernières espadrilles sur S***za, alors que tu toi, avec son ancien PC, tu met le processeur à genoux 3 fois par jour en voulant faire tes compilations dantesques ?

Et que dire de ton collègue dessinateur indus qui a récupéré le vieux CRT21", largement suffisant pour Catia, de la commerciale parce qu'elle a réussi à obtenir le dernier 26" LED en guise de second écran pour son portable 17" Top moumoute pour les 2 1/2journées par semaine ou elle n'est pas en clientèle.


PS : C'est du vécu à peine exagéré

[Lordsephiroth]

Je ne suis pas vraiment d'accord avec la façon de catégoriser les tâches de l'analyse. De mon point de vue, "tâches administratives" regroupe tout ce qui ne fait PAS avancer le projet (à savoir les séances de suivi avec son chef, team building, séances de département, échange d'information et surtout... et surtout... les apéros !!). La gestion des environnements je le classifierait également dans les tâches administratives. Par contre, je suis formellement opposé à l'idée que le brainstorming au sein de l'équipe de dév soit considéré comme de l'administratif. L'attente sur les tests ou les builds... je sais pas trop où mettre ça. Je dirais plutôt côté dév que côté admin...

Dans ma boîte, selon des chiffres que j'avais entendus lors d'un précédent projet, le temps passé au dév était entre 65% et 75%.

Je pense que montrer le temps passé à écrire du code n'a aucun sens. Réfléchir avant d'écrire n'est jamais du temps perdu...

[Kikuts]

Je ne suis pas étonné.

Entre le temps passé à attendre la fin des compilations interminable (pour les gros projets dont le codesource clean fait plus de 200 Mo (sans ressources images and co)) donc 1 à 3 min par build, sur une journée / semaine /mois on arrive à temps non négligeable.

Le temps passé à faire du suivit des tâches, mettre à jours les GANT & co, le planning ...

Attendre que les tests se fassent, qu'ils soient validés, de contacter le testeur pour savoir si c'est bon pour lui ... Puis retester en environnement de préprod, tester avec une base de test pour vérifier que la montée en charge n'a pas d'impact néfaste ...

A demander des spécifications supplémentaires quand le CDC a été fait à la va vite ...

A migrer de VS 2010 à 2012 (ou toutes autres modif de l'environnement de développement par ex : nouvelle machine et hop les SDK et tout le bins à installer)

La mise à jour de référence vers services web ...

Pris séparément, ça fait pas grand chose, mais mis bout à bout, on arrive à des chiffres comme annoncer par cet article.

[prikama]

je pense qu'on passe maintenant de la même passage entre l'assembleur et les langages de haut niveau. maintenant en passe de l'AGL vers "l’environnement de génération de code automatiquement"

[Jérôme_C]

Mais malheureux que dis-tu ? Oserais-tu contredire la nécessité pour la secrétaire d'avoir la dernière machine surpuissante à la mode pour faire ses 3 lettres quotidiennes sous Word, passer commande de la tunique dernier cri sur La Red**** ou des dernières espadrilles sur S***za, alors que tu toi, avec son ancien PC, tu met le processeur à genoux 3 fois par jour en voulant faire tes compilations dantesques ?

Et que dire de ton collègue dessinateur indus qui a récupéré le vieux CRT21", largement suffisant pour Catia, de la commerciale parce qu'elle a réussi à obtenir le dernier 26" LED en guise de second écran pour son portable 17" Top moumoute pour les 2 1/2journées par semaine ou elle n'est pas en clientèle.


PS : C'est du vécu à peine exagéré

Chez nous on a une solution : pas de secrétaire, et le comptable, il ne faut pas le déranger.

Donc on a tous les écrans qu'on veut. Le jour où un stock d'écrans est arrivé pour le client, tout le monde s'est pris sans vergogne un deuxième écran, et on a juste passé une nouvelle commande

Par contre, tous les coups de téléphone, c'est pour bibi

[germinolegrand]

Perso les tâches administratives sont souvent la mise en place d'outils ou la réorganisation d'un repo et d'une chaine d'installation ou de compilation, ce qui comprends parfois le développement d'un outil visant à améliorer les points précédents. Donc au fil du temps ces tâches tendent à être de moins en moins fréquentes au fur et à mesure qu'elles sont automatisées.

Toutefois ces tâches sont bel et bien chronophages en plus d'être peu agréables .

[Caro999]

Perso les tâches administratives sont souvent la mise en place d'outils ou la réorganisation d'un repo et d'une chaine d'installation ou de compilation, ce qui comprends parfois le développement d'un outil visant à améliorer les points précédents. Donc au fil du temps ces tâches tendent à être de moins en moins fréquentes au fur et à mesure qu'elles sont automatisées.

Ce ne sont pas des tâches administratives ça. Ce sont des tâches de gestion de l'environnement ("Environment management" dans l'étude).

Les tâches administratives, c'est le reporting, poser ses vacances, organiser un déplacement (booker son avion, l'hotel), rentrer ses frais de déplacements, le temps de déménagement de son bureau quand ça arrive (faire ses cartons, défaire ses cartons), participer à un exercice de simulation d'évacuation-incendie, assister à une formation pour utiliser le nouvel outil de reporting, le temps de travail perdu à cause d'une panne de réseau ou d'électricité, etc...

Par contre, 5+ heures par semaine, j'ai peur que les gens qui ont participé à l'étude n'aient pas compris de quoi il s'agissait. Mais bon, combien de fois ai-je entendu dans ma carrière (à juste titre) que lire ses mails, c'est pas une tâche administrative. Ben non, c'est pas une tâche administrative quand ces mails ont trait au(x) projet(s) sur le(s)quel(s) on travaille.

Bref, je pense que l'étude a du plomb dans l'aile.

[hugobob]

C'est le problème du vase et son contenu.

[Matthieu Vergne]

En lisant l'article, j'ai l'impression que ces "ingénieurs logiciels" font moins de code que ce qu'ils devraient faire...

1) un ingénieur n'est pas un technicien, il n'est pas là pour pisser le code, donc encore heureux qu'il ne fait pas QUE ça. Il est censé prendre en considération des facteurs internes et externes (y compris facteurs humains) pour identifier les besoins et les priorités, identifier ce qui est raisonnable de faire ou non, et seulement après passer au codage.

2) est-ce que je suis le seul à voir que ce diagramme montre quand même clairement que le code est de loin le plus important comparé à n'importe quel autre activité ?

Après, c'est peut-être mon interprétation qui me joue des tours, mais avec un titre "Les travailleurs passent moins de temps à dormir" on verrait tout de suite les gens rappliquer pour parler de conditions de travail déplorables, alors qu'on se contenterait de lire qu'ils dorment moins que ce qu'ils passent de temps éveillés, ce qui est tout à fait normal.

[sevyc64]

En lisant l'article, j'ai l'impression que ces "ingénieurs logiciels" font moins de code que ce qu'ils devraient faire...

1) un ingénieur n'est pas un technicien, il n'est pas là pour pisser le code, donc encore heureux qu'il ne fait pas QUE ça. Il est censé prendre en considération des facteurs internes et externes (y compris facteurs humains) pour identifier les besoins et les priorités, identifier ce qui est raisonnable de faire ou non, et seulement après passer au codage.

2) est-ce que je suis le seul à voir que ce diagramme montre quand même clairement que le code est de loin le plus important comparé à n'importe quel autre activité ?

Après, c'est peut-être mon interprétation qui me joue des tours, mais avec un titre "Les travailleurs passent moins de temps à dormir" on verrait tout de suite les gens rappliquer pour parler de conditions de travail déplorables, alors qu'on se contenterait de lire qu'ils dorment moins que ce qu'ils passent de temps éveillés, ce qui est tout à fait normal.

Entièrement d'accord avec toi.
Mais faut bien préciser que Technicien en dev et en informatique en général, c'est de plus en plus rare. Faut croire que dans le monde du dev, il 'ny a que des ingénieurs capable de travailler, il n'y a que des ingénieurs de recruter, même pour faire de la vulgaire saisie sous Excel.

Et je suis bien placé pour le savoir : + de 10 ans d'xp, mais 40 balais, pas ingénieur. Niveau client final, toujours le même refrain "Mais niveau étude, vous n’êtes pas ingénieur. ben non, je me suis arrêté à bac+4". Mais qu'est-ce qu'on s'en br*** du diplôme avec plus de 10 ans d'xp. Niveau SSII, classement vertical direct sans même répondre.
Et ça fait plus d'1 an que ça dure.

[Matthieu Vergne]

Tu peux remplacer "technicien" par "stagiaire" ou "petit chinois/indien", peut-être que ce serait plus parlant {^o^}.