Que faire si le patron reporte toujours les décisions importantes concernant les exigences et la conception globale?

Lors du démarrage d'un nouveau projet, mon patron évite toujours de prendre des décisions fixes. Il dit généralement: ok, commencez simplement à écrire quelque chose et soyez aussi générique que possible. Lorsque vous avez terminé, nous regardons comment nous continuons. Son argument est fondamentalement que vous ne savez jamais et "développement agile".

Pour garder la question aussi générique que possible: que faites-vous si votre patron n'aime pas prendre des décisions?

Il suffit de s'y tenir et d'écrire du code qui pourrait subir une refactorisation lourde et une réécriture partielle quelques semaines plus tard? Ou continuer à discuter jusqu'à ce que le patron prenne au moins quelques décisions? C'est plus ou moins ma stratégie actuelle. Parce que c'est comme une loi de la physique, à un moment donné, quelque chose doit être livré. Soit parce que le patron du patron veut voir des résultats, soit parce que les choses deviennent ridicules à un moment donné.

J'observe également que mon patron critique presque tout. Même des suggestions basées sur les siennes ...

Construire des prototypes

Commencez simplement à dessiner des écrans qui ne font rien au début (vous en avez probablement assez?)

Vous devriez être en mesure de le rendre partiellement fonctionnel lentement, et éventuellement de remanier une partie du mauvais code lorsqu'il devient plus clair ce que vous essayez de faire.

C'est un problème courant qu'ils ne savent pas ce qu'ils veulent jusqu'à ce qu'ils voient quelque chose et réalisent que ce n'est pas ce qu'ils veulent. J'ai trouvé que lorsque quelqu'un veut que vous commenciez simplement à construire un «cadre» ou quelque chose de «générique» comme ce qu'il vous dit, vous aurez juste des ennuis si vous essayez. Les frameworks sont déjà écrits, vous n'avez pas besoin de le faire.

Il y a plusieurs problèmes que j'ai rassemblés à partir de votre message: 0-Ce n'est pas votre travail de gérer le projet et ce n'est pas votre travail de rassembler les exigences des utilisateurs finaux. 1-Le patron ne connaît pas les exigences exactes 2-Le patron ne parle pas aux utilisateurs finaux des exigences 3-Le patron lance une terminologie qu'il ne comprend pas vraiment agile 4-Vous travaillez sur une solution qui écrit plusieurs fois et vous n'êtes pas content

Quant aux 1,2 et 3, il n'y a pas grand-chose à faire si vous n'êtes pas une personne âgée. Cependant, les actions suivantes peuvent être effectuées:

A - Demandez-lui de partager avec vous le plan de projet. Il peut en avoir un ou en construira un indiquant les tâches et les délais. L'un d'eux devrait porter sur l'analyse et la collecte des exigences. Sinon, suggérez-le.

B - Préparer quelques références sur l'importance des exigences pour la réussite d'un projet logiciel

C - Préparez-lui une page de ce qu'est et n'est pas Agile.

D - Préparez-lui une liste d'entrées typiques à l'étape de la conception et convaincez-le de la valeur de chacun.

E - Suggérer l'ajout d'un analyste d'affaires et / ou d'un modélisateur de données à l'équipe. Ces rôles devront appartenir à l'utilisateur final et vous fourniront les informations requises ou au moins une bonne partie de celles-ci.

F - Voyez comment d'autres développeurs ont coopéré avec ce type.

Quant au # 4, vous pouvez lui suggérer d'utiliser une approche de prototypage ou un générateur de code qui l'aiderait, vous et l'utilisateur, à se faire une idée des aspects fonctionnels de l'application. La plupart des outils ne génèrent pas une interface graphique parfaite, mais au moins vous pouvez capturer les fonctionnalités requises.

Dans tous les cas, assurez-vous de documenter clairement chacune des itérations et de lui envoyer un e-mail concernant les informations que vous avez reçues, ce que vous avez fait (en détail) et le résultat. Assurez-vous d'attribuer les résultats à la cause appropriée, par exemple (manque d'exigences, etc.).

Malheureusement, certaines personnes n'acceptent pas les conseils. Faites donc attention à la façon dont vous communiquez avec lui.

Ça ne va pas bien!

Bonne chance.

J'avais un patron comme ça - en fait, je plaisantais que sa devise était "l'indécision est la clé de la flexibilité".

Quel que soit le travail de développement que vous effectuez, vous êtes probablement mieux placé pour résoudre le problème du client que votre patron. Si vous ne savez pas quel est le problème que le client essaie de résoudre (ce qui n'est pas la même chose qu'une spécification), alors quelqu'un ne remplit pas correctement ses exigences.

Esquissez quelques mises en page ou créez un prototype non / semi-fonctionnel. Mais fais quelque chose. Il ne ressort pas clairement de votre message si vous créez un logiciel client complet ou des applications Web, mais la beauté de ces dernières est que vous pouvez publier tôt, publier souvent. Commencez avec les os nus et continuez à partir de là. Un faux départ ne fait pas de mal s'il fait dialoguer et prendre des décisions.

Nous avons un dicton autour de $ WORK (applications Web internes) pour nos clients: "Je vais vous donner quelque chose pour que vous puissiez me dire ce que vous voulez." Soyez prêt à jeter le premier brouillon, mais vous pourriez être surpris de voir à quel point vous en avez rarement besoin.

Faites-lui remarquer que les livres Agile suggèrent de reporter les décisions aussi longtemps que vous le pouvez mais pas plus que cela . Chaque décision a un point où elle doit être prise, et peut-être vous êtes là en ce moment.

D'un autre côté, remettez-vous également en question. Avez-vous vraiment besoin de décider quelle couche de persistance vous allez utiliser pour cette application? Ou pouvez-vous commencer à l'écrire dans un fichier CSV et à le conserver suffisamment abstrait pour prendre cette décision plus tard?

Écrivez votre propre document de spécification et tenez un examen où vous l'expliquez et il le signe. Ensuite, vous deviendrez patron, et votre patron abordera plus de problèmes de gestion interpersonnelle que de problèmes techniques.

Engagez une discussion sur la `` gestion ascendante '' avec votre patron et vos clients, trouvez des solutions, choisissez la meilleure solution à mettre en œuvre par votre équipe, trouvez les failles dans les autres et `` gérez '' votre manager pour qu'il prenne la `` bonne '' décision.

Et bien sûr, assurez-vous qu'il pense que c'était toute son idée. (surtout quand tout va mal!)

Vous devez concevoir et mettre en œuvre quelque chose. Puisque votre patron ne prendra pas de décisions, prenez-les vous-même. Prenez un peu plus de temps pour documenter vos décisions et hypothèses avant de les mettre en œuvre. Envoyez-le à toute personne concernée, y compris votre patron. J'espère que cette liste comprend plus que votre patron car cela lui mettra un peu de pression pour prendre certaines décisions car il sait que d'autres savent que vous êtes prêt à continuer. Vous serez surpris de la rapidité avec laquelle vous obtenez des commentaires lorsque vous mettez des décisions par écrit, surtout si vous prenez des décisions avec lesquelles d'autres personnes ne sont pas d'accord. En attendant, je procéderais avec les décisions que vous avez prises jusqu'à ce que le contraire soit dit.

Si vous avez fini par perdre du temps à mettre en œuvre ce que votre patron ne voulait pas, c'est à lui et non à vous puisqu'il était conscient du chemin que vous alliez emprunter.

De plus, certaines personnes ont du mal à démarrer, mais une fois qu'elles voient quelque chose de tangible, leur esprit entre en jeu. Peut-être que votre patron est comme ça et que vous lui dites ce que vous prévoyez de faire par écrit, ça le fera avancer.

Prenez vous-même vos décisions et commencez à coder. Bien sûr, le développement d'une manière flexible aidera (lisez les modèles, principes et pratiques agiles de Robert C Martin si vous ne l'avez pas déjà fait), mais toute la flexibilité du monde n'aidera pas si aucune décision n'est jamais prise. Il se peut que vous deviez simplement développer ce que vous pensezest nécessaire, puis en le modifiant selon les besoins. Souvent, les clients / patrons ne savent pas ce qu'ils veulent tant qu'ils ne le voient pas ou jusqu'à ce qu'ils voient quelque chose qu'ils ne veulent pas. Cela vous mènera probablement hors de la portée d'un développeur, mais c'est la vie. Je trouve souvent que mes collègues et moi prenons effectivement des décisions commerciales. Parfois, ceux-ci ne sont pas remis en question et les décisions que j'ai prises commencent à diriger l'entreprise, uniquement parce que personne d'autre ne prendrait la décision. Assurez-vous de répertorier TOUS vos hypothèses et décisions (sans exception) et de les présenter à votre patron.