Comment signaler l'avancement de mon projet (Agile) à mon employeur (qui n'est pas programmeur)?


15

J'ai un problème à signaler les progrès à mon employeur. Je suis programmeur à temps partiel et je gère un projet logiciel pour le département (non technique) de mon école.

Personne de contact:
1. Le personnel qui utilise réellement le logiciel et soulève des demandes de fonctionnalités,
2. Mon patron (non programmeur), et elle n'est pas l'utilisateur du logiciel.

La nature du projet:
il s'agit d'un logiciel prêt à l'emploi, acheté auprès de tiers. Je dois modifier ou ajouter une fonction / fonction à ce logiciel afin de répondre aux besoins du service. Il s'agit d'un logiciel à utiliser tout au long du semestre. Toutes les fonctionnalités ne doivent pas être utilisées au début.

Par conséquent, nous utilisons le modèle Agile: lorsque le personnel a besoin d'une certaine fonctionnalité, il soulève une demande et je fais les changements. À la fin du semestre, je suppose que toutes les fonctionnalités requises seront augmentées et mises en œuvre.

Le problème: à
chaque fois que mon patron me demandait comment l'avancement des travaux, je ne peux pas répondre, car je ne sais pas comment répondre. Je n'ai pas la liste complète de toutes les fonctionnalités requises. Même si j'ai terminé des fonctionnalités qui ont été soulevées la semaine dernière, je ne peux toujours pas dire à mon patron que j'ai "terminé", car de nouvelles fonctionnalités arrivent également, et je ne sais pas combien. Je ne peux pas dire "Nous avons combien de% d'achèvement" ni "Nous allons le terminer par xxx". Parfois sur 3 demandes, j'arrive à en terminer 2, je dirais à mon patron "J'en ai terminé 2, mais il y a une fonctionnalité pas encore terminée". Après une longue période de temps, je sonne comme "J'ai toujours quelque chose de pas fini, après si longtemps".

Le fait de ne pas pouvoir signaler les progrès me fait vraiment mal. Il ne s'agit pas de savoir combien j'ai fait, mais de faire savoir aux gens. Si j'étais le manager et que mon personnel n'arrive pas à me signaler les progrès accomplis pendant des mois, je me sentirais aussi incapable de ce type.

Avez-vous une idée de comment signaler ou répondre à une question aussi simple que "quel est l'état / la progression de la modification du logiciel"?

MISE À JOUR Mon patron ne participe pas directement à la tâche de développement, donc elle n'a aucune idée de ce que je fais ou du fonctionnement du programme. Nous ne nous rencontrons pas régulièrement car elle est occupée, et je pense que ce sera une perte de temps car elle n'est pas la principale utilisatrice, elle ne connaît pas le détail du programme.

Je rencontre régulièrement le personnel qui utilise et connaît mieux le logiciel.

J'ai du mal à expliquer les progrès à mon patron.

Réponses:


24

C'est un problème courant lorsque vous êtes un programmeur qui travaille de manière indépendante et que vous rapportez à quelqu'un qui n'est pas technique.

Les boss comme ça veulent surtout pouvoir comprendre quelques choses:

  • Les utilisateurs sont-ils satisfaits?
  • Les utilisateurs veulent-ils que les choses soient faites?
  • Ce que vous faites vaut-il l'argent que vous êtes payé?

Un burn-out Agile ou autre chose comme ça serait une idée terrible! Comme vous l'avez dit, votre patron est vraiment occupé, donc il n'aura pas le temps de l'apprendre, et il n'est probablement pas intéressé de toute façon.

Donc, si j'étais vous, je leur enverrais un rapport une fois par semaine contenant:

  • Un "résumé exécutif" au début: "A terminé 3 fonctionnalités cette semaine et a reçu 2 nouvelles demandes de fonctionnalités. Au début de cette semaine, il y avait 11 demandes de fonctionnalités inachevées et à la fin, il y en avait 10."
  • Une liste d'état des fonctionnalités, avec une courte phrase chacune, en trois groupes:
    1. Les fonctionnalités que vous avez réalisées au cours de la semaine
    2. Les demandes de fonctionnalités qui sont arrivées pendant la semaine
    3. Les autres fonctionnalités du "backlog"
  • Une brève discussion de tout ce qui était compliqué ou inhabituel, de préférence en utilisant un langage non technique.

Si j'étais votre patron et que je n'avais reçu aucun rapport, je serais très heureux de recevoir cela chaque semaine. Et si je voulais quelque chose de différent, je vous le demanderais.


5
+1. L'e-mail serait également utile à tout le monde, pas seulement au patron qui ne semble pas avoir de numéro de projet. Tous les gestionnaires aiment une liste de tâches qui descend.
DBlackborough

Oui, cela semble très sensé. Demandez également où allez-vous à long terme - est-ce suffisant pour continuer à répondre aux demandes de fonctionnalités dans un ordre raisonnable? Dans ce cas, continuez à le faire. Ou serait-il préférable d'essayer de gagner du temps pour regarder vers l'avenir et de dire "allons-nous arriver à un point où le logiciel est plus" complet "qu'il ne l'était" ou "nous devrions abandonner un certain nombre de ces demandes de fonctionnalités et les regrouper en certaines changement plus important "? Si c'est le cas, vous devrez peut-être comprendre cela par vous-même, mais aussi en parler au patron.
Jack V.

3
La clé ici est de connaître votre public. Parlez leur langue. Comme l'indique la réponse, mais il est très important d'être aussi succinct que possible en leur donnant des informations qui signifient réellement quelque chose pour eux. Elle voudra peut-être juste savoir que vous travaillez. Il est difficile pour quelqu'un en position d'autorité de ne pas avoir la moindre idée du vaudou que vous faites.
Ominus

J'avais à l'origine cela dans ma réponse, et après réflexion, je pense que c'est mieux. C'est simple et il est facile de comprendre si l'arriéré s'améliore ou s'aggrave.
Joe McMahon

1
J'envisagerais d'ajouter une "notes" ou une section similaire où vous pouvez commenter l'interaction avec les utilisateurs dans le sens de "Les utilisateurs semblaient ravis d'avoir la fonctionnalité X ajoutée au système" ou "Les demandes récentes se sont concentrées sur la partie XYZ du système". Cela donnera à votre patron une base de conversation avec les utilisateurs si cela se produit. Créer une opportunité pour elle de discuter de l'application de manière informelle avec vos utilisateurs devrait l'aider à se sentir à l'aise avec vos progrès.
TomG

3

Il semble que vous n'ayez aucun moyen de savoir si vous avez terminé ou jusqu'où vous en êtes. C'est bon.

Gardez une liste des fonctionnalités demandées, lesquelles sont terminées, en cours ou non démarrées. Suivez-les sous forme de graphique d'une semaine à l'autre du total dans chaque catégorie. Cela vous donnera un ensemble de points que vous pouvez extrapoler à la date de fin. Autrement dit (en ne regardant que le nombre de fonctionnalités "terminées")

  • Semaine 1 - 2 terminée
  • Semaine 2 - 5 complète (2 de la semaine 1, 3 de la semaine 2)
  • Semaine 3-8
  • Semaine 4 - 12

Si vous avez 16 semaines, vous pouvez compléter environ 48 fonctionnalités (ne vous inquiétez pas trop que certaines fonctionnalités soient plus grandes / plus petites que d'autres, après 4-5 semaines, elles seront généralement en moyenne). Vous pouvez ensuite signaler à tout le monde que vous ne pouvez gérer qu'un nombre X de fonctionnalités. À la fin du projet, ce qui est absolument le plus important, c'est que vous avez fourni les fonctionnalités nécessaires et que vous ne vous êtes pas tué au cours des deux dernières semaines. En signalant de cette façon, vous pouvez retirer les exigences clés dès que possible.

L'autre chose que vous voudrez signaler est la capacité dont vous disposez. "Je n'ai reçu que 2 demandes de fonctionnalités, mais j'aurais pu en traiter 3 ... pouvez-vous demander au personnel de proposer plus de fonctionnalités plus tôt?"

Je ne suis pas sûr d'avoir complètement répondu à votre question, alors n'hésitez pas à poser des questions de suivi ...


2

Trois mots ... graver le tableau.

Votre employeur, qu'il soit ou non un toxicomane agile ou simplement un responsable des développeurs, appréciera un tableau de gravure .

Tout le monde aime comprendre quand un projet sera terminé et tirer parti de la météo d'hier fournira le moyen le plus précis et le plus réaliste de prédire l'achèvement d'un projet.


Je suppose que, pour que le graphique Burn Down fonctionne, j'aurai toutes les demandes de fonctionnalités au début de chaque mois, et le graphique montre la tendance d'un mois de progression. Mes demandes de fonctionnalités arrivent chaque semaine. Dois-je faire un graphique BD pour chaque semaine? Cela a l'air bizarre en affichant seulement 3 demandes (par exemple) pour chaque semaine.
Janet Smith

Pour qu'un graphe déroulant capture correctement le travail, toutes les histoires d'une version devraient être associées à des estimations. La somme totale des estimations représente le nombre total de points pour la diffusion. Puis, à mesure qu'une histoire est terminée, ces points sont représentés sur le graphique. C'est correct d'ajouter de nouvelles histoires à tout moment ... ces histoires finissent par augmenter le nombre total de points.
Dakotah North

Un graphique Burn Up pourrait montrer la progression même si les demandes de fonctionnalités continuent d'affluer.
rwong

1

Je suppose que vous faites un tête-à-tête au moins une fois par semaine et que vous pouvez discuter de vos priorités avec votre manager à ce moment-là - ce qui est important de son point de vue (tel ou tel a besoin de sa fonctionnalité avant une autre personne, etc.) - et peut donc indiquer la quantité de choses qui rendent votre manager bien fait par rapport à la quantité de choses que vous avez au total à faire.

Votre manager ne recherche probablement pas une ventilation minute par minute; il essaie juste de voir si le travail est en cours, si les choses importantes attirent plus d'attention et que vous ne vous noyez pas sous la charge ou au ralenti parce que vous êtes empêché de continuer.

Notez que dans un véritable processus agile, vous avez en effet des trucs qui arrivent tout le temps, mais vous et votre manager êtes d'accord sur ce qui est le plus important / le plus nécessaire et combien cela va tenir dans la période de travail actuelle (que ce soit une semaine, deux semaines, un mois ...), décomposant les travaux en petits morceaux si besoin est pour que les morceaux s'inscrivent dans la période.

Une révision majeure de la base de données prenant plusieurs semaines pourrait être décomposée comme ceci: établir des sauvegardes, vérifier que les sauvegardes sont bonnes, concevoir la nouvelle disposition de la base de données, écrire le logiciel de conversion et le tester, configurer la restauration et le tester, essayer la conversion sur la machine de mise en scène, en essayant la restauration au même endroit, puis en faisant enfin la conversion. Chacun de ceux-ci peut probablement être décomposé en morceaux d'une semaine (ou moins). Si certaines étapes peuvent prendre 2 ou 3 semaines, vous devez indiquer votre cheminement lors de la prochaine réunion (en ciblant 50% sur 2 semaines, 33% sur 3 semaines, etc.).

Idéalement, vous auriez un tableau qui contient les choses que vous devez faire par rapport aux choses que vous allez faire maintenant, et vous cocheriez les éléments "faire maintenant" au fur et à mesure. Cela permet à votre responsable de passer et de voir combien de choses sont marquées par rapport aux choses qui sont sur la liste à faire.


Je crois que le manager que vous mentionnez ici, participe normalement directement au développement et attribue la tâche. Mon manager ne s'implique pas dans le développement. Je lui ai déjà envoyé un diagramme Gannt, mais cela n'aide pas, car j'ai réparti les tâches en fonction des fonctionnalités. Elle ne connaît pas les détails du projet, donc cela peut lui sembler écrasant.
Janet Smith

Je pense au "burndown chart", comme celui-ci . Notez qu'il montre votre chemin, ce que vous avez accompli (les "must haves" en haut, les "nice to haves" en bas), et donne une idée de quand vous aurez "fini" avec le travail que vous avez actuellement. Vous devez parcourir la colonne de droite (celle vers laquelle pointe la flèche "nous sommes ici") lorsque vous ajoutez du travail. Vous devriez toujours avoir le tête-à-tête avec votre responsable pour vous assurer que la colonne de droite "Quelle est l'importance de cette" est dans le bon ordre.
Joe McMahon

1

Une fois par semaine (je suppose que la durée de l'itération / du sprint dans votre processus agile est d'une semaine par exemple), procédez comme suit :

  • faire une démonstration du nouveau travail au personnel, pour s'assurer que leurs demandes ont été satisfaites
  • signaler au patron le nombre de demandes que vous avez traitées au cours de la semaine et identifier / décrire ces demandes. Faites un bref résumé
  • signaler au patron le nombre de nouvelles demandes ajoutées à votre backlog / file d'attente au cours de la semaine et le nombre total de demandes
  • dites au patron sur quoi (quelles demandes) vous prévoyez de travailler la semaine prochaine; en d'autres termes, les priorités actuelles. Voici l'occasion pour elle de les confirmer ou de les modifier et pour vous deux d'être clairs à ce sujet
  • dites au patron quel est le plan pour 1-2 semaines après cela.

Je sens que votre patron n'est pas assez technique pour prendre en charge ou comprendre des termes agiles comme la vitesse , le propriétaire du produit ou le tableau de burndown . Le modèle ci-dessus évite un tel jargon, utilise des mots plus simples comme «backlog» et «queue» dans leur sens commun, et devrait ainsi faciliter la communication avec votre patron.


0

J'utiliserais ma vitesse comme principale statistique pour lui. Cela montrera combien de tâches / fonctionnalités j'ai «accepté» de parler pour une semaine particulière (ou une autre période) et combien j'ai terminé. À partir de cela, je mentionnerais certaines des fonctionnalités les plus importantes implémentées, et pourquoi cela a changé par rapport aux itérations précédentes. Vous pouvez également mentionner les obstacles que vous avez rencontrés et dépassés et comment cela a affecté votre vitesse.

D'autres statistiques que votre patron voudra peut-être connaître pourraient inclure le nombre de nouveaux rapports de bogues signalés, les rapports de bogues fermés et les nouvelles demandes de fonctionnalités soumises. Vous devrez soit demander directement ou utiliser votre meilleur jugement pour déterminer lesquels sont les plus importants. En fin de compte, je donnerais un aperçu des progrès accomplis et demanderais s'il y a autre chose qu'il ou elle aimerait savoir. Tout ce que le patron veut savoir, c'est que vous progressez et qu'il y a tout ce dont vous avez besoin pour travailler au mieux.


0

Je vous suggère de valider un rapport hebdomadaire: répertoriez les fonctionnalités demandées. Enregistrez les fonctionnalités modifiées. Signalez ce que vous avez fait.


0

J'essaierais de résumer les choses d'une manière que les gestionnaires comprennent.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Tout simplement parce que votre gestionnaire n'est pas un programmeur, ne pensez pas que cela signifie qu'il s'attend à ce que vous connaissiez une date d'achèvement exacte. Présentez les chiffres que vous avez. Une fois que le gestionnaire a vu le nombre de demandes reçues et terminées, le gestionnaire voit les progrès. Si le nombre de vos demandes devient incontrôlable, le gestionnaire peut intervenir et vous aider en établissant des priorités avant d'être surchargé. Et si vous manquez de travail, ils pourront peut-être vous trouver un petit projet parallèle. Après tout, c'est toujours agréable de faire une pause dans un projet quand il semble qu'il n'y a pas de fin en vue et que les journées de travail passent plus vite et sont plus gratifiantes lorsque vous êtes occupé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.