Gestionnaire de logiciels qui oblige les développeurs à faire de la gestion de projet

Je suis un développeur de logiciels travaillant dans une entreprise de systèmes embarqués. Nous avons un chef de projet, qui s'occupe du calendrier global du projet (y compris électrique, qualité, logiciel et fabrication), donc son calendrier logiciel est très bref.

Nous avons également un gestionnaire de logiciels, qui est mon patron. Il me fait écrire et maintenir le calendrier du logiciel, les documents de conception (conception de haut et bas niveau), SRS, la gestion des changements, les plans et rapports de vérification, la gestion des versions, les révisions et bien sûr le logiciel.

Nous n'avons qu'un seul ingénieur de test pour toute l'équipe logicielle (10 membres), et à tout moment, il y a quelques projets en cours.

Je passe 80% de mon temps à faire ces documents. Mon patron est issu du processus et pense que nous avons besoin d'une meilleure documentation pour améliorer les logiciels:

1. Il considère que la conception est primordiale, le codage consiste à "simplement écrire la conception", cela ne devrait pas prendre trop de temps et "tout le code devrait être écrit avant que le matériel ne soit prêt".
2. Ne comprend pas la différence entre un contrôle de version centrale et distribuée, même après que nous lui ayons dit qu'il était plus facile de collaborer avec un modèle distribué.
3. Ne comprend pas le code et souhaite comprendre chaque bogue et sa solution proposée.
4. Estime que la vérification doit être effectuée par le développeur et la validation par le testeur. Le fait est que notre vérification vérifie uniquement si la mise en œuvre est correcte (nous n'écrivons pas de tests unitaires, elle n'est jamais prise en compte dans le calendrier), et la validation est un test de boîte noire, donc les tests unitaires sont manquants.

Je suis vraiment confus.

1. Suis-je responsable de la conservation de tous ces documents? Cela me donne l'impression de faire la gestion de projet logiciel, essentiellement. Je suis d'accord avec la documentation technique, mais je pense que la planification / planification ne devrait pas être faite par le développeur.
2. Je n'aime pas vraiment créer des documents, je veux résoudre des problèmes et écrire du code. D'après mon expérience, la création de documents de conception n'aide que dans une certaine mesure, ce n'est jamais la solution à un code meilleur ou plus rapide.
3. Je pense que le patron ne se soucie pas vraiment de fabriquer de meilleurs produits, mais seulement d'être un bon gestionnaire aux yeux de la direction.

Que puis-je faire? Cette année, j'ai effectué 3 mois de codage, le reste vient d'être consacré à la création de documents et à l'attente des rapports de bogues des clients.

Vous parlez comme un ingénieur logiciel.

Un gestionnaire de projet se concentre davantage sur l'état d'avancement du projet dans son ensemble et sur l'allocation efficace des ressources pour garantir que les jalons sont atteints et en temps opportun. Ils suppriment également les obstacles et aident les ressources du projet à se concentrer sur leurs fonctions spécifiques.

La rédaction et la maintenance de la conception et de la documentation technique sont des éléments importants pour être ingénieur logiciel et conviennent à votre rôle. Trop d'une bonne chose peut être mauvaise cependant (voir l' analyse Paraylsis ).

Il considère que la conception est primordiale, le codage consiste à "simplement écrire la conception"

Si le chef de projet considère les documents de conception comme primordiaux, il s'attend à ce que les documents soient livrables dans le processus. Ce n'est pas une perte de temps de votre part s'il estime qu'ils sont suffisamment importants pour y consacrer 80% de votre temps.

cela ne devrait pas prendre trop de temps et "tout le code doit être écrit avant que le matériel ne soit prêt".

Il s'agit d'un vœu pieux et d'une vue assez désuète sur le fonctionnement du développement logiciel. Elle n'est jamais aussi propre, quelle que soit la conception et la préparation que vous y consacrez. Sur cette note cependant, vous devriez avoir des spécifications matérielles claires et des environnements de test appropriés et des simulations matérielles simulées pour que votre code interagisse, mais encore une fois, le monde réel est en désordre.

La gestion de projet est incroyablement facile dans un monde parfait. Cependant, le monde n'est pas parfait, peu importe à quel point vous le souhaitez, ce qui rend la gestion de projet réelle incroyablement difficile. C'est pourquoi ils sont payés beaucoup d'argent.

(2) Ne comprend pas la différence entre un contrôle de version centrale et distribuée.

Pourquoi devrait-il s'en soucier? Comment cela affecte-t-il les jalons? Ce n'est pas le cas.

3) Ne comprend pas le code et veut comprendre chaque bogue et sa solution proposée

Son objectif est de faire fonctionner des logiciels et le vôtre devrait l'être aussi. Il n'a pas besoin de comprendre le code mais il a besoin de comprendre les problèmes qui empêchent le logiciel de fonctionner. Une fois que vous serez d'accord sur ce niveau de base, votre objectif mutuel vous aidera à travailler ensemble plus efficacement.

(4) estime que la vérification doit être effectuée par le développeur et la validation par le testeur.

Quel est le problème avec ce sentiment? Les testeurs dans le rôle d'assurance qualité devraient être concernés par la validation des fonctionnalités et des exigences. Les développeurs doivent tout mettre en œuvre pour vérifier et tester leur travail avant de passer aux tests.

Je n'aime pas vraiment créer des documents, je veux résoudre des problèmes et écrire du code.

Si vous préférez être un simple programmeur, vous devriez peut-être en parler à votre patron et voir s'il y a un meilleur rôle pour vous dans le projet. Quelqu'un a besoin d'écrire et de maintenir la documentation technique, donc peut-être qu'un autre développeur peut vous aider avec certaines de ces tâches afin que vous ne passiez pas 80% de votre temps à écrire de la documentation.

D'après mon expérience, la création de documents de conception n'aide que dans une certaine mesure, ce n'est jamais la solution à un code meilleur ou plus rapide.

C'est surtout vrai ... mais seulement si les dix développeurs passent 80% de leur temps à écrire de la documentation technique que personne ne lira jamais. C'est un énorme anti-modèle de gestion dans lequel j'ai vécu auparavant. Si vous constatez que vous effectuez la majeure partie de la documentation pour l'équipe, il ne semble pas juste que l'on vous refuse le droit d'effectuer plus de travaux de codage.

Le fait est que la meilleure documentation technique est le code lui-même.

Je pense que le patron ne se soucie pas vraiment de fabriquer de meilleurs produits, mais seulement d'être un bon gestionnaire aux yeux de la direction

Je pense qu'il fait attention parce que le produit est sa pupille et si les projets et les caractéristiques ne sont pas terminés et les clients ne sont pas heureux , alors la haute direction ne sera pas pour lui prendre soin beaucoup. Le problème est que votre point de vue sur les améliorations de qualité nécessaires ne correspond pas au sien et à la haute direction, et la perception des clients de ce qu'ils ressentent est important.

Essayez de comprendre ce qui est vraiment important pour le produit, car si vous pouvez multiplier par trois l'efficacité d'un processus, si vous passez une semaine entière à le faire, c'est au prix d'une autre caractéristique importante que le client exige.

Nous voulons tous bien paraître aux yeux de notre supérieur. Il n'y a rien de mal à cela, c'est la nature humaine d'être égoïste. C'est une réalité de la vie.

Dans une certaine mesure, je suis d'accord avec votre chef de projet. Le développement de logiciels va bien au-delà des fonctionnalités de codage. :-)

Compte tenu de votre situation, je m'adresserais à lui pour lui expliquer que ses demandes prennent 80% de votre temps, et chercher à comprendre pourquoi il est important pour lui que vous passiez ce temps à maintenir la documentation plutôt qu'à développer (ce qui va au-delà du codage).

FYI, Atlassion , une société de logiciels, a un ratio de 13 développeurs pour une personne QA et la plupart des tests (planification et exécution) sont effectués par les développeurs. J'ai appris cela lors d'une de leurs présentations à Agile 2012 et nos équipes que j'essaie actuellement d'imiter cette pratique.

Cependant, je discuterais également avec votre chef de projet s'il serait disposé à essayer Scrum comme méthodologie pour faire avancer toute l'équipe. Compte tenu de votre description, je ne pense pas que vous utilisez Scrum.

Comme vous, j'étais extrêmement frustré de maintenir des plans en constante évolution et une approche légère Scrum m'a aidé à surmonter cette frustration.

Les équipes les plus performantes de mon expérience étaient celles qui faisaient face au moins de processus nécessaires pour faire leur travail. À un certain point, un processus supplémentaire commence à retirer la qualité du produit. Si QA commence à manquer des bogues parce qu'ils sont plus soucieux de supprimer les documents et que DEV ne code pas les fonctionnalités ou ne corrige pas les bogues parce qu'ils écrivent de la documentation, alors vous avez un problème. Cependant, déterminer si c'est réellement le cas dans votre entreprise est une question très localisée à laquelle seuls les membres de votre équipe peuvent répondre (pas nous).

Il y a une chose à propos de laquelle votre patron a très tort, et c'est le fait que vous avez si peu d'assurance qualité et aucun test unitaire. Un bug créé par un développeur est par définition un oubli de sa part. Attendre des développeurs qu'ils testent toujours leurs propres fonctionnalités et avoir peu de tests en dehors de cela est un problème de processus. Le contrôle qualité peut être remplacé par des tests automatisés en fonction de votre domaine dans une certaine mesure, mais si vous n'avez ni l'un ni l'autre, vous laissez probablement passer les bogues (et cela finit généralement par coûter plus cher que de les trouver tôt).

De plus, d'un point de vue commercial strict, l'embauche d'AQ est moins chère que l'embauche de développeurs. Vous pourrez couvrir plus de terrain pour l'argent dépensé si les équipes ont un bon rapport QA / DEV.

Les implémentations CMMI que j'ai vues ou dont j'ai directement entendu parler ont toutes été lourdes en processus et en documentation; la conviction de vos patrons que la documentation doit être suffisamment détaillée pour rendre la mise en œuvre triviale implique fortement que ses attentes sont similaires.

Si vous recevez une part disproportionnée de la rédaction / maintenance de la documentation, il est raisonnable de demander à ce qu'elle soit distribuée de manière plus uniforme. Si les autres développeurs ont une documentation similaire aux ratios de codage et que vous souhaitez passer la plupart de votre temps à écrire du code; il est peut-être temps d'envisager de trouver un nouvel employeur.

Vous parlez de systèmes médicaux ... donc la sécurité est primordiale - et donc la documentation (en particulier la traçabilité) est essentielle.

Un testeur semble un peu léger, mais à part ça, oui - vous êtes responsable de vous assurer que la documentation est en place.

Mon expérience dans le monde médical est limitée, mais dans le monde de l'aérospatiale / défense, nous avons Do-178B (maintenant C) qui prescrit un modèle de cycle de vie qui spécifie la documentation et le niveau de test nécessaires (en fonction de la criticité de la sécurité [plus spécifiquement, le niveau d'assurance de conception] du logiciel), et dans le monde automobile, nous avons ISO26262 qui fait de même.

Si la documentation n'est pas en place, le produit n'est pas certifié.

Mais l'important est de travailler avec la documentation requise pour améliorer votre produit ... n'essayez pas de procéder à une rétro-ingénierie de la documentation après coup, car cela ne sert à rien dans le monde réel.