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

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.

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.

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 ...

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 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.

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.

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.

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.

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é.