Question:
On m'a demandé de réaliser un projet sans aucun cahier des charges concret
KTPATEL
2015-06-11 17:51:32 UTC
view on stackexchange narkive permalink

Je travaille dans le domaine du développement logiciel. Mon chef d'équipe et mon manager m'ont demandé de terminer un projet après avoir convoqué une seule réunion pour discuter des détails du projet. Lors de la réunion, très peu d'informations étaient disponibles et en demandant des éclaircissements, ils ont répondu que "vous devriez le créer à votre façon".

Je n'ai aucun problème avec cela, mais après avoir franchi quelques étapes, ils réclament à plusieurs reprises des changements majeurs dans le projet. Je n'ai aucune objection à cela, mais si j'ai une idée claire du projet au début, je peux créer une structure forte et dynamique pour le projet avec un code propre.

Maintenant, ce qui se passe, c'est que je dois faire des correctifs pour les fonctionnalités dans le code car ils ont besoin de fonctionnalités dans un temps très court et je pense que ce genre de travail tue la productivité et la créativité des développeurs.

S'il vous plaît suggère que dois-je faire dans cette situation?

En passant, avez-vous la possibilité d'adapter une méthodologie Agile comme Scrum? Je pense aussi que vous devriez demander ce qu'ils veulent exactement.
Le problème ici n'est pas de ** mettre en place ** des procédures de travail, mais de convaincre vos supérieurs ** qu'ils ont besoin ** de procédures de travail. Une fois qu'ils ont compris cela, trouver «comment» gérer le projet prend quelques heures (car vous vous êtes alors mis d'accord sur la marche à suivre nécessaire). Mais nous avons également besoin de plus d'informations ici: y a-t-il une date limite, y a-t-il quelque chose sur papier, des clients sont-ils impliqués, ...
Et quelles que soient leurs demandes, formez-vous dès que possible à faire de bonnes estimations du temps nécessaire. Gardez une trace du temps qu'il vous a fallu pour implémenter les changements précédents, de sorte que chaque fois qu'ils veulent quelque chose, vous pouvez dire: "OK, cela prendra x jours". Moins ils donnent d'informations concrètes, plus vous devez consacrer de temps à votre estimation.
Vous trouverez peut-être plus sur le sujet sur le site Project Management Stack Exchange ici: http://pm.stackexchange.com/questions - Nous traitons fréquemment ce type de question ...
Ne le créez pas à votre guise. Écrivez une exigence à l'avance et faites-la circuler. Ils ne le liront probablement même pas, mais lorsqu'ils le changent à l'arrière, vous pouvez dire que c'est un changement.
Bien que vous l'appeliez un projet, et c'est le cas, ce que vous construisez est-il considéré comme un prototype ou une preuve de concept? Dans ces circonstances, il pourrait être tout à fait approprié de procéder de cette manière puisque la conception technique n'a pas de durée de vie au-delà de la fin du projet. Dans ce cas, essayer de forcer les gens à fournir des exigences alors qu'ils doivent être très fluides et ne pas avoir une idée claire de ce qui est requis ne fonctionnera pas.
Étape 0: créez les spécifications.
Il y a suffisamment de changements même si vous avez des spécifications, commencer à programmer sans elles est une folie. http://thecodelesscode.com/case/154
Je ne suis pas d'accord avec votre argument «tue la productivité et la créativité». La productivité qui compte est probablement celle de l'utilisateur final, pas de vous, et c'est l'occasion pour vous de montrer votre créativité pour obtenir rapidement les résultats dont ils ont besoin. Je considère ces choses comme un défi, moi-même. Obtenir à un utilisateur quelque chose dont il a besoin en quelques heures, plutôt que les semaines dont la direction informatique aurait besoin pour planifier et fournir une «solution» est formidable pour l'ego.
Exemple classique de sous-estimation de projet. Votre chef d'équipe et votre manager ont pensé que ce serait facile. Vous leur montrez que ce n'est pas aussi simple. Si c'est un projet interne, c'est très bien ... s'il y a un client impliqué, clarifiez maintenant ou cela coûtera beaucoup d'argent à votre entreprise.
** Informations manquantes cruciales: ** Comment ont-ils géré les projets dans le passé, quelles ont été les étapes et combien de temps chacun a-t-il duré? À qui appartient la capture des exigences, qui est responsable de leur révision et quand, qui définit et attribue les tâches, comment les changements d'exigences sont-ils gérés et définis? Leur méthodologie est-elle cascade ou agile? Insistez pour obtenir des données avec des chiffres concrets sur les projets antérieurs afin de savoir ce qui est attendu.
Bienvenue dans le monde réel. La première spécification que j'ai reçue ici était une photographie du produit de la concurrence. J'ai dit, tu veux que j'écrive une spécification? Ils ont dit, non, nous voulons que vous en construisiez un. J'ai écrit une spécification, puis j'en ai construit une.
Dans un projet précédent, j'ai dû changer la conception de la page littéralement ** tous les jours pendant un mois ** parce qu'ils changeaient d'avis. A la fin ils ont eu le culot de me demander "pourquoi ça a pris si longtemps"
Vous décrivez essentiellement mon travail.
Avant tout, définissez la définition de done!
@Stefto en utilisant une méthodologie agile ne signifie pas que vous pouvez combler des exigences à la volée, en fait pour bien le faire, il faut une meilleure idée d'une spécification
Quatorze réponses:
#1
+92
Jay
2015-06-11 20:57:37 UTC
view on stackexchange narkive permalink

Premièrement: Bienvenue dans cette petite chose que j'aime appeler "la vraie vie".

Les développeurs de logiciels disent toujours qu'avant de démarrer un projet, toutes les exigences doivent être parfaitement définies, à partir de descriptions détaillées d'algorithmes pour cribler les maquettes, et une fois le travail de développement commencé, aucun changement ne devrait être autorisé. Lorsque le produit sera livré, nous corrigerons bien sûr tout écart par rapport aux exigences écrites, mais aucun changement impliquant une modification des exigences n'est autorisé.

Oui, cela faciliterait beaucoup la vie du développeur du logiciel . Et c'est une demande absurde.

Imaginez que vous vouliez acheter une voiture. Alors vous allez chez le concessionnaire automobile et constatez que c'est juste un bureau avec un gars derrière un bureau. Il vous tend une feuille de papier vierge et vous dit: "Écrivez ici exactement ce que vous voulez dans une voiture. Nous trouverons ensuite une voiture répondant à ces exigences et vous la livrerons. Une fois que vous aurez signé le papier, nous commencerons la recherche. pour une voiture, donc à ce stade, aucun changement n'est autorisé. " "Mais," vous dites, "j'ai une idée générale de ce que je veux, mais je voudrais certainement essayer quelques voitures différentes, les emmener pour des essais routiers ..." "Non, je suis désolé," il dit: "Ce n'est pas possible. Écrivez simplement ce que vous voulez et nous vous fournirons une voiture répondant à ces exigences."

Supposons maintenant qu'en plus de cela, vous n'avez jamais conduit de voiture auparavant. Comment sauriez-vous ce que vous voulez avant de l'essayer? Les choses qui semblent être une bonne idée sur papier peuvent ne pas fonctionner aussi bien en pratique, etc.

Je ne serais pas inquiet des exigences vagues, À condition que toutes les personnes impliquées comprennent que les exigences sont vagues, que vous vont devoir combler les lacunes, et que lorsqu'ils verront les décisions que vous avez prises, il y aura des décisions qu'ils n'aiment pas et les choses devront être retravaillées.

S'il s'agit d'un environnement lâche et coopératif, il ne devrait y avoir aucun problème. Vous produisez quelque chose, apportez-le pour examen, ils vous disent ce qu'ils aiment et ce qu'ils n'aiment pas, vous apportez des changements, peut-être en plusieurs cycles. J'ai fait beaucoup, beaucoup de projets comme ça dans ma vie. Souvent, l'utilisateur doit essayer le logiciel pour voir ce qui fonctionne dans la pratique et ce qui ne fonctionne pas.

Si le patron ou le client font des demandes déraisonnables, ou si vous ne savez pas quel est l'environnement comme, alors vous devez obtenir les choses par écrit pour vous protéger. J'ai fait quelques projets dans ma vie où le patron ou le client dit: "Je ne sais pas quelles sont toutes les exigences, vous inventez juste quelque chose". Ensuite, j'invente quelque chose et quand je le ramène, ils hurlent: "Quoi! Ce n'est pas ce que je voulais! Quel genre de crétin êtes-vous? Il était sûrement évident que ..." et ensuite de donner toute une série d'exigences qui ils n'en ont jamais parlé auparavant et cela n'était pas du tout évident pour moi. Dans ce genre d'environnement - même s'il ne s'agit pas de cris et de menaces de vous licencier ou d'annuler le contrat, ce ne sont peut-être que des expressions de déception et de frustration graves - dans ce genre d'environnement, rédigez un article décrivant ce que vous proposez de faire et le leur rendre pour approbation. Si vous avez de la chance, cela mènera à une discussion sur les véritables exigences. Au pire, ils disent "oui oui quoi qu'il en soit" et les brossent. Mais au moins à ce stade, lorsque vous revenez avec le logiciel, s'ils disent: "Ce n'est pas ce que nous voulions", vous pouvez ramener le document et dire: "Oh, je suis désolé, c'est ce que nous avons convenu Je devrais faire. Voyez, c'est écrit ici même, et vous l'avez approuvé. " Dans un environnement amical, vous dites cela de manière amicale; dans un environnement hostile, vous devrez peut-être être plus énergique. Dans les deux cas, vous dites alors: "D'accord, alors quels changements voulez-vous apporter aux exigences?" Ensuite, mettez-les par écrit et démarrez un autre cycle.

Si le patron ou le client s'attend à des délais d'exécution impossibles et vous blâme lorsque des exigences impossibles ne sont pas satisfaites, alors franchement, il est temps de commencer à chercher un autre emploi ou un autre client. Ou si vous avez suffisamment besoin de ce travail / client, vous le sucez et prenez l'abus. (J'ai de bons souvenirs de la fois où mon patron m'a demandé combien de temps il faudrait pour convertir un grand système complexe que notre société avait construit il y a des années d'un ancien langage informatique à un langage plus moderne. J'ai commencé à essayer de réfléchir un peu à voix haute , nous avions fait une telle traduction sur un autre produit donc nous avions une certaine expérience, mais personne dans l'entreprise aujourd'hui ne connaissait ce produit, bla bla, puis il a dit: "Je n'ai pas besoin d'une réponse exacte, juste à peu près : deux jours? trois jours? "J'étais sidéré," Hum, non, "j'ai dit," La question est de combien de mois. "Il est parti en marmonnant.)

Les commentaires ne sont pas destinés à une discussion approfondie; cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/24816/discussion-on-answer-by-jay-i-have-been-asked-to-complete-a-project- sans aucun).
#2
+73
mcknz
2015-06-11 18:49:43 UTC
view on stackexchange narkive permalink

Vous devez repousser. Obtenez du temps sur leurs calendriers. Poser des questions. Poser beaucoup de questions. Posez tellement de questions qu'ils en ont assez de vous et vous donneront les détails dont vous avez besoin.

S'ils ne le savent pas, proposez des exigences spécifiques et obtenez votre approbation. Documentez leurs réponses et renvoyez-leur les réponses pour confirmation. Cela montre clairement que la cause du changement et du retard est qu'ils changent d'avis, et non votre développement.

Quand ils disent "construisez-le à votre façon", ce qu'ils veulent vraiment dire, c'est "faites quelque chose que je peux regardez et changez. " Il est beaucoup, beaucoup plus facile de réviser et de modifier les exigences avant leur mise en œuvre.

J'ajoute: Présentez souvent pour obtenir des commentaires
Et en fait, c'est votre travail de rédiger les exigences. S'ils veulent des changements, ils devraient et vous le diront. Cela leur fera gagner beaucoup de temps en lisant et en proposant des changements plutôt qu'en les écrivant à partir de zéro. Et leur faciliter la vie fait également partie de votre travail.
@dyesdyes En tant que personne dont la profession est d'écrire les exigences (pas un développeur mais un ingénieur des exigences), je dirai que s'il est censé rédiger les exigences, il aura besoin des ressources pour cela. Tout d'abord, il y a des tonnes d'accès aux parties prenantes, ce qu'il ne semble pas avoir. Et s'il ne l'a pas fait auparavant ou appris comment, il va vivre des moments intéressants. Je ne peux que lui souhaiter que sa direction reconnaisse bientôt que ce n'est pas quelque chose qui se fait en agitant la main à côté du développement.
@dyesdyes Je ne saurais trop insister sur l'importance que les développeurs n'écrivent pas les exigences.Chaque projet que j'ai réalisé où les développeurs écrivent des exigences au lieu d'un BA, d'un PM ou d'un utilisateur professionnel a été un clusterbomb complet.
@corsiKa Je suis d'accord, mais quand vous êtes abandonné dans la nature avec rien d'autre, vous feriez mieux de les écrire parce que les exigences des développeurs sont meilleures que pas d'exigence, il vaut mieux y penser à l'avance et aussi pour vous couvrir le cul.
Couvrir votre cul parce que quelqu'un n'a pas fait * son * travail ne fait pas de * son * travail * votre * travail.
Montrez-leur des maquettes dessinées à la main et posez des questions. Dessinez sur le tableau blanc. Posez des tonnes de questions, jusqu'à ce que vous ne puissiez penser à aucune. Alors demandez plus. Demandez-leur de décrire les étapes du flux de travail. Faites des recherches et présentez plus d'idées et posez plus de questions. Etc. Soyez un analyste d'affaires.
Poser trop de questions peut se retourner contre vous - c'était déjà le cas pour moi. Des collègues se sont spécifiquement plaints de cela. "" "faire quelque chose que je peux regarder et changer." "** est une méthode de travail valide (et parfois supérieure) **.
#3
+31
ero
2015-06-11 19:40:11 UTC
view on stackexchange narkive permalink

De manière générale, lorsque les exigences du client sont très vagues, ce que vous devez faire est d'écrire ce que vous êtes sur le point de faire (c'est-à-dire les spécifications techniques et fonctionnelles) et leur faire valider le document . De cette façon, s'ils veulent changer quelque chose pendant le projet, vous pouvez leur faire remarquer que ce n'est pas ce qui a été convenu et les facturer. Au moins tout aussi important est le fait qu'ils ne peuvent pas vous blâmer de l'avoir fait «dans le mauvais sens».

Si votre projet n'est pas trop avancé, j'essaierais quand même d'y arriver. Cela peut sembler une perte de temps à court terme, mais cela vous empêchera de toute une vie de mise en œuvre des changements.

Si vous avez presque terminé (en supprimant la liste interminable des changements à venir évidemment), eh bien c'est plus compliqué. Vous regardez ici le contrôle des dégâts. Faites en sorte que votre responsable le reconnaisse, de préférence par écrit. Vous ne voulez pas être un bouc émissaire si le projet devient vraiment compliqué.

Pour le dire franchement, cela me semble être une mauvaise gestion de projet. J'aurais une discussion avec le responsable pour éviter cette situation à l'avenir

Excellent, car d'abord vous prenez le contrôle de la situation, ensuite en écrivant les exigences, il est plus difficile pour un boss désemparé de trouver des exigences totalement aléatoires et changeantes. Et si vous êtes le seul adulte, il vaut mieux avoir une spécification écrite par un adulte.
#4
+14
Craig Brunetti
2015-06-11 23:00:29 UTC
view on stackexchange narkive permalink

Marv, je pense que la plupart de ces réponses sont superflues.

Ce n'est pas la réalité du développement logiciel. C'est l'effet de ne pas gérer assez bien une boutique de logiciels.

Les exigences ne sont pas la solution, car les exigences changent. Que ce soit parce que les personnes signataires changent d'avis ou parce qu'elles n'ont jamais eu une idée de ce qu'elles voulaient en premier lieu, cela n'a pas d'importance. Même l'entreprise elle-même peut changer de priorités, obligeant à changer les exigences.

Une seule personne semble avoir suggéré Agile. C'est un bon début, mais Agile nécessite beaucoup d'adhésion de beaucoup de gens, des gens qui doivent faire leurs devoirs. De toute évidence, vous ne travaillez pas avec des personnes qui ne veulent pas faire leurs devoirs.

Alors, empruntez à Agile. Demandez à ces parties prenantes d'assister à des conversations dans lesquelles vous dirigez la création d'histoires ( http://www.mountaingoatsoftware.com/agile/user-stories). Conservez ces définitions dans leur langue, afin d'éviter toute confusion sur ce qu'ils ont accepté lors de leur révision trois mois plus tard. Attendez-vous à des cycles de création d'histoires, en les gardant de haut niveau / larges au début, et en divisant les histoires en plus petites au fil du temps selon vos besoins. Des histoires plus petites signifient des domaines de travail plus fins et aident à résoudre des problèmes.

Armé d'un ensemble d'histoires suffisamment petit pour que vous puissiez donner des estimations confortables, vous pouvez établir un calendrier et une hiérarchisation pour le développement de votre projet, indépendamment de dans quelle mesure les parties prenantes aident ou n’aident pas. Assurez-vous que les histoires sont stockées de manière transparente. Et quand les gens veulent que vous passiez du "travail par histoires", alors repoussez.

Maquettes, propositions, PoC, tout cela va bien, mais même ils doivent provenir d'un comprendre ce que vous allez construire pour gagner votre vie. Sinon, c'est juste tirer dans le noir, en croyant qu'un jour vous obtenez un coup chanceux. Prenez le problème par les cornes, scénarisez le projet pour eux s'ils ne le font pas eux-mêmes.

Je pense que vous êtes en fait d'accord avec certaines des autres réponses, en capturant simplement les exigences sous forme d'histoire. Ce qui est certainement un formalisme très légitime dans ce but, mais ce n'est pas le seul, et ce n'est pas incompatible avec Agile si vous faites les deux correctement.
Votre réponse disait essentiellement ce que j'allais dire. Commencez par les cas d'utilisation, obtenez l'adhésion (peut nécessiter des écrans de maquette) pour être sûr que tout le monde est sur la même longueur d'onde. Cependant, la seule chose à noter, c'est que cette approche n'a rien d'extraordinaire. C'est ainsi que le développement en cascade le ferait et l'a fait bien avant que quiconque n'ait inventé le terme de développement agile.
#5
+11
Adam Davis
2015-06-11 22:46:18 UTC
view on stackexchange narkive permalink

"Échouez tôt, échouez souvent."

Lorsque vous avez des exigences minimales, construisez un système minimal, puis montrez-le. Démontrez-le et ses fonctionnalités tout au long du parcours, et demandez et attendez des commentaires qui modifieront votre trajectoire.

Oui, de nombreux développeurs comme vous veulent une spécification vierge, après quoi ils iront à la tour, et le temps plus tard émergera avec l'implémentation correcte, prêt à recevoir le prochain projet.

Cependant, vous avez rejoint une entreprise et une équipe où vous êtes plutôt censé fonctionner avec un minimum d'entrée, jogging un peu, revenir avec des questions et des démos, et jogging pour un peu plus.

Il y a un élément d'inefficacité dans ce processus. Mais souvent, les exigences et les besoins de l'entreprise le dictent. S'ils attendaient de créer la spécification parfaite, le projet ne serait pas terminé à temps et aurait quand même besoin de modifications car personne ne peut prédire l'avenir.

Le développement itératif n'est peut-être pas votre tasse de thé, mais comme vous le découvrirez, c'est beaucoup, beaucoup plus courant que le développement de spécifications parfaites.

La communication, les tests et les commentaires fréquents des utilisateurs / clients / superviseurs et la volonté de suivre les coups deviendront de grandes compétences à avoir si vous les développez.

Si vous voulez vraiment "travailler selon les spécifications", examinez les industries à haute fiabilité. L'automobile et l'espace sont deux industries qui ont besoin d'un logiciel écrit selon les spécifications et où le processus de demande de changement est si lourd qu'il est évité à presque tout prix.
changer d'avis d'avant en arrière sans aucun type de plan n'est pas la façon dont une entreprise prospère est gérée. Le développement itératif NE signifie PAS que vous n'avez pas du tout besoin d'une spécification, en fait, il vous oblige à être encore plus discipliné pour ne pas perdre tout votre temps de développement. Il faut également beaucoup plus de compétences pour concevoir une structure de manière à prendre en charge l'itération et à ne pas finir en désordre.
Deux pouces pour le commentaire de James. Le problème avec le code un peu, obtenez l'adhésion, le code un peu plus, c'est que cela se transforme en une grosse boule de boue si les gens ne sont pas d'un niveau de compétence assez élevé pour toutes les applications, sauf les plus simples. Cela signifie que l'écrasante majorité des développeurs ne peuvent pas réussir.
#6
+8
Yakk
2015-06-11 23:18:00 UTC
view on stackexchange narkive permalink

Au moment où vous démarrez un projet, vous en savez le moins que vous en saurez jamais. Les consommateurs de votre projet en savent également le moins qu'ils en sauront jamais.

Ils peuvent vous donner un petit gâteau "voici ce que je pense qu'il devrait faire, et voici comment je veulent qu'il le fasse ", mais il y a de fortes chances qu'ils se trompent, en particulier dans les détails.

De même, si vous prenez une conception et faites un plan de développement de plus de 2 mois pour l'implémenter, alors partez et travaillez dessus, vous n'allez certainement pas suivre ce plan. Les parties seront plus difficiles ou plus faciles que vous ne le pensez, d'autres seront inutiles lorsque vous y arriverez, et au fur et à mesure que vous travaillerez sur le projet, vous acquerrez de l'expertise sur ce projet.

A semaine après, vous aurez une meilleure idée du plan et de nombreux ajustements. Dans un mois, vous penserez probablement que votre plan était stupide.

Vos clients / patrons ont une idée de ce qu'ils veulent. Ce ne sont pas des experts dans ce qu'ils veulent faire: au mieux, ce sont des généralistes qui savent comment résoudre des problèmes similaires, mais la seule façon de devenir un expert dans la création d'un logiciel est de créer ce logiciel. S'ils avaient déjà créé ce logiciel, ils n'auraient pas besoin de vous.

Votre travail consiste à devenir un expert dans la création du logiciel. Ce que fait le logiciel, au départ, sera vague. Ils ne savent pas vraiment, et vous ne savez pas vraiment. Donc, vous itérez: vous déterminez ce que vous pensez qu'ils veulent, vous leur demandez si cela semble raisonnable, vous mettez en œuvre et obtenez quelque chose devant eux dès que possible. Selon qui ils sont, vous polissez différentes parties et laissez d'autres parties inachevées.

Ensuite, vous recevez des commentaires. Ils aimeront certaines parties, penseront que d'autres parties sont des déchets et penseront que d'autres parties sont une perte de temps. Vous partez et vous changez de logiciel - peut-être même que vous abandonnez le travail et recommencez (car maintenant votre expertise en matière d'écriture de cette première partie s'est beaucoup améliorée - vous venez de le faire, et vous avez probablement appris quelque chose de cela) et obtenez au même point plus rapidement - ou peut-être que vous le modifiez simplement et ajoutez ce qu'ils aiment, et changez ce qu'ils veulent.

Lorsque vous recevez leurs commentaires, demandez-leur de dire ce qu'ils veulent le plus important amélioré. Mettez-le par écrit. Demandez ce qui est le plus important (mettez-le dans une liste ordonnée). Dites que vous leur reviendrez avec des estimations de prototype dans un jour ou deux. Devinez combien de temps il faudra pour prototyper les principales fonctionnalités qu'ils veulent, demandez-leur s'ils sont d'accord avec un prototype (PAS une version finie) prêt à leur montrer dans X jours (inclure le tampon pour les erreurs) de l'un des meilleurs 2 choses qu'ils veulent.

Ensuite, montrez-leur votre prototype, demandez-leur s'ils veulent qu'il soit terminé ou supprimé de la solution. En fonction de qui ils sont, vous voudrez peut-être indiquer clairement par le comportement de l'application qu'il s'agit d'un prototype. À ce stade, vous devriez avoir une bonne idée du temps qu'il faudra pour peaufiner le prototype. Ils peuvent demander plus de changements avant de le «finir», ou ils peuvent demander qu'il soit poli. S'ils demandent plus de changements, revenez à la chose précédente des priorties.

Il s'agit essentiellement de l'agilité axée sur les développeurs, dans laquelle vous vous engagez activement à conclure des accords avec vos consommateurs / votre patron. Ils reçoivent fréquemment des prototypes et sont souvent invités à donner leur avis. Vous devez vous assurer que tout prototype peut et sera supprimé s’il ne vous demande pas de le peaufiner, et qu’ils savent que vos prototypes ne sont pas si proches des fonctionnalités terminées.

En faisant cela, votre expertise dans l'écriture de l'application augmente et leur compréhension de ce qu'ils veulent vraiment grandit au fur et à mesure que vous développez l'application.

Si vous demandez une spécification complète à l'avance, les décisions sont prises avant que vous sachiez ce qui fonctionne et ce qui ne fonctionne pas.

C'est bon. Cela demande de réelles compétences et de l'expérience. Une bonne attitude, une peau épaisse aussi. Je pense qu'en fin de compte, ce type de développeur a vraiment un impact sur les résultats. Et que vous obteniez des éloges ou que vous receviez des demandes plus désagréables de la part du patron, de toute façon, vous devez penser que vous continuez à rentrer votre argent, vous apprenez, c'est la vie.
#7
+2
rumtscho
2015-06-12 04:01:39 UTC
view on stackexchange narkive permalink

Une équipe logicielle a besoin non seulement de développeurs, mais également d'ingénieurs des exigences, de testeurs et de quelques autres rôles. Il est tout à fait possible que dans une petite équipe, la même personne porte plusieurs chapeaux à la fois. Mais notez que le rôle d'un ingénieur des exigences nécessite un ensemble de compétences différent de celui d'un développeur. Si vous essayez de créer des exigences à l'aveuglette, sans connaître la bonne façon de les faire, vous serez très inefficace, en codant essentiellement la mauvaise application pendant la majeure partie de votre temps de développement, puis en vous frustrant lorsque vous devez la gratter et recommencer.

Je vous suggère d'acquérir une partie des compétences nécessaires à un ingénieur des exigences. Dans votre travail actuel, vous deviendrez meilleur dans les tâches qui vous ont été confiées. Dans les emplois futurs, où la spécification des exigences peut être créée par un ingénieur des exigences dédié ou par un consensus au sein de l'équipe, ou bricolée par un client, avoir cet ensemble de compétences (qui s'interfacera avec votre rôle de développeur plus pur) vous rendra plus précieux membre de l'équipe et permettra à votre équipe de travailler plus efficacement ensemble grâce à une meilleure communication avec vous.

La meilleure façon de commencer est avec un manuel complet. Mon préféré est Discovering requirements d'Ian Alexander, un texte très pratique qui est facile à suivre par les débutants. La deuxième lecture de votre liste peut être la conception de l'interface utilisateur de Lauesen pour les ingénieurs. Le titre peut sembler vieilli, mais ce que vous en apprendrez est maintenant connu sous le mot à la mode UX, ce qui est un plus à avoir sur votre CV de nos jours. Et non, ce n'est pas seulement une question d'interface, cela couvre toutes les exigences qui sont perceptibles par l'utilisateur (y compris la question de savoir quelle fonctionnalité inclure).

En même temps, informez vos managers que c'est un vrai travail. Cela signifie que 1) s'ils s'attendent à ce que vous fassiez un travail qui nécessite 10 heures d'analyse des exigences, il ne vous reste plus que 10 heures à coder. Et 2) que, comme tout autre processus, il transforme l'entrée en sortie, et vous devez avoir accès à l'entrée avant de pouvoir produire une spécification: dans ce cas, toutes les informations que vous pouvez obtenir sur l'utilisation future de l'application vous travaillez avec. Même le plus grand génie de la RE ne peut pas créer un bon concept s'il n'a pas accès à de vrais utilisateurs. Les livres vous indiqueront les sources auxquelles vous devez accéder; essayez d'en couvrir le plus possible.

#8
+1
Gustav Bertram
2015-06-15 17:04:16 UTC
view on stackexchange narkive permalink

Je pense que cela revient à éduquer les clients et la direction.

Les changements deviennent plus coûteux à mesure que le projet avance

Vous pouvez consulter presque tous les manuels de génie logiciel pour obtenir les "coûts relatifs de correction des erreurs dans le graphique du cycle de vie du logiciel". Il dit essentiellement que plus vous avancez dans le projet, plus il en coûte pour apporter un changement. Alors pourquoi ne résolvez-vous pas les problèmes lors de la phase de planification chaque fois que vous le pouvez?

Code Complete mentionne que la majorité du coût d'un projet est dans le codage - donc si vous en avez besoin pour répéter que plusieurs fois, le coût de votre projet peut facilement devenir incontrôlable.

Planifiez juste assez pour la complexité du projet

Il existe plusieurs métaphores appropriées au génie logiciel. Mon préféré est la construction de bâtiments. Contrairement à la construction, la quantité de planification n'a pas besoin d'être exhaustive - elle doit seulement être suffisante pour la complexité du produit.

  • Si le projet est trivial (comme une niche pour chien ), alors vous pouvez demander au constructeur de "juste le construire, nous pouvons le changer plus tard", et c'est très bien. La changer est facile.

  • Si vous construisez une maison, vous demandez généralement à un architecte de dessiner d'abord les plans. Le client et l'architecte s'entendent sur une conception avant la construction de la maison. Lorsque les plans sont acceptés, le constructeur peut démarrer. Vous pouvez toujours demander au constructeur de le faire, mais il devra esquisser un plan approximatif avant de commencer, et cela vous coûtera beaucoup plus cher quand il devra le réparer.

  • Si vous construisez un immeuble de bureaux, vous feriez mieux d'utiliser un architecte, sinon il s'effondrera. Si un constructeur incroyablement compétent parvient à construire un immeuble de bureaux sans plan, lui demander d'ajouter un sous-sol parce que vous avez oublié de vous garer est soit extrêmement coûteux, soit totalement impossible.

Vous n'avez pas besoin d'une spécification exhaustive et complète avant de commencer. Vous avez juste besoin de suffisamment pour vérifier que ce que le client a en tête est ce que vous avez en tête.

Vous ne pouvez pas construire plus vite que vous ne pouvez le planifier

Les clients objectent parfois que la planification le ferait prendre trop de temps. Ma réponse à cela est "Vous voulez que nous construisions cela plus rapidement que nous ne pourrions le planifier? La planification est plus rapide, plus facile et moins chère que la construction, donc si vous ne pensez pas que nous pouvons planifier cela en trois mois, alors nous pouvons certainement" t le construire en trois mois. "

Si vous planifiez tôt, alors les idées fausses sont peu coûteuses et faciles à corriger. Sinon, il sera plus difficile de résoudre les problèmes plus tard.

La méthode Agile

Agile adopte une approche très différente.

  • Au lieu d'adopter l'approche en cascade une seule fois, vous divisez le projet en itérations d'une semaine ou deux chacune.

  • Vous faites toujours la planification et la clarification des exigences , mais moins, et vous le faites une fois à chaque itération.

  • Vous obtenez de nombreux commentaires des utilisateurs à chaque itération

  • Vous apportez les modifications les plus simples au logiciel prenant en charge le nouveau exigences avant de présenter à l'utilisateur

  • Vous faites beaucoup de TDD pour vous assurer de ne pas casser des choses avec votre refactoring constant

Mort par un million de changements

Il y a une sorte d'utilisateur qui aime faire une tonne de petits ajustements. "Cette police doit être légèrement plus grande." "Cette police doit être légèrement plus petite." "Faites-en une couleur différente." "Au lieu de la chose parfaitement bonne que nous avons ici, que diriez-vous de la changer en quelque chose de légèrement différent."

Si tel est le cas, ma suggestion est que le client se concentre d'abord sur les fonctionnalités de base, se concentrer d'abord sur des changements plus importants. Vous devriez également leur demander d'articuler l'exigence que le petit changement satisfait.

Il se peut qu'il y ait une exigence importante derrière la demande que vous ne connaissez tout simplement pas. Si tel est le cas, comprenez le besoin et voyez si vous pouvez suggérer quelque chose qui répond mieux à l'exigence.

Souvent, l'exigence est "la facilité d'utilisation générale". La réponse à la "facilité d'utilisation générale" est presque toujours le test utilisateur. Pas de test client, remarquez, mais de test utilisateur par environ six des personnes qui finiront par utiliser le système.

#9
  0
Zibbobz
2015-06-11 21:46:24 UTC
view on stackexchange narkive permalink

Lorsque vous n'obtenez pas les exigences dont vous avez besoin pour démarrer un projet, ce que vous devez faire est de noter toutes les exigences dont vous avez besoin et de les spécifier dès que possible. Faites-leur savoir les exigences exactes dont vous avez besoin et, surtout, lesquelles vous empêcheront de terminer le projet.

Pendant que vous faites cela, codez autant que vous le pouvez avec ce que vous sont donnés au début . Je ne peux insister assez sur ce point. Continuez à travailler sur ce que vous avez reçu jusqu'à ce que vous n'en puissiez plus. Faites-leur savoir lorsque vous avez atteint un point que vous ne pouvez pas dépasser car les exigences n'ont pas encore été définies.

Il peut y avoir une raison légitime pour laquelle votre ou vos supérieurs ne vous ont pas donné les spécifications dont vous avez besoin - ils peuvent avoir besoin d'une maquette pour voir comment cela fonctionne en premier, ils peuvent ne pas avoir encore parce que vos utilisateurs / analystes commerciaux traînent les pieds sur les métriques exactes que vous devez suivre. Quelle que soit la raison qu'ils ont, même si c'est une mauvaise raison, vous devriez toujours faire le plus de travail possible.

Parfois, les exigences vont changer, et vous ne pouvez rien y faire.

Bienvenue dans l'industrie du logiciel.

#10
  0
Andyz Smith
2015-06-12 00:35:14 UTC
view on stackexchange narkive permalink

Cela fait partie de votre travail de gérer des choses comme celle-ci. Un grand nombre de réponses vous donnent des idées plus précises sur la manière de procéder.

Il fait partie de votre travail d’être flexible. Pour créer du code patché, oui, mais compréhensible en premier lieu. Et réparable, au fur et à mesure. votre travail

Il fait partie de votre travail d'écouter les demandes de tarte dans le ciel, faire du codage, faire dire à quelqu'un, ce n'est pas le façon de coder, coder comme ils le souhaitent, ce qui ne fonctionne pas. Ensuite, revenez en arrière et faites-le comme cela fonctionne. Une partie de votre travail

Je suppose que la seule chose compliquée qui ne fait pas vraiment partie de votre travail est de se plaindre que cela est inefficace. Vous pouvez le mentionner, je suppose, ou vous pouvez essayer de le rattacher, lorsque les choses vont de plus en plus tard, vous pouvez suggérer certaines choses, mais cela ne fonctionnera probablement pas vraiment.

Encore une fois, cela va faire partie de votre travail de gérer le désordre. Et sois gentil. Et dites, ok, patron, quand tout est jeté à la poubelle. Et dites, ok patron, quand tout doit être sorti de la benne à ordures, couvert de poubelle et retravaillé.

Une partie du travail. Si vous ne l'aimez pas vraiment, je vous suggère de créer votre propre entreprise, d'embaucher un groupe de programmeurs légèrement arrogants et d'essayer de vous vendre des services et des produits et de faire la paie pendant que vos employés pleurnichards disent, c'est un patron patché, ce n'est pas joli chef de code. alors ...

Une autre chose est que les gens qui dirigent des affaires n'ont souvent, absolument, jamais, le temps de beaucoup de réunions avec vous. Si vous pouvez faire votre travail, vous serez en mesure d'anticiper certaines choses, de réparer les choses que vous ne pouvez pas et de tout faire par vous-même.

#11
  0
Anthony X
2015-06-12 06:24:38 UTC
view on stackexchange narkive permalink

Comme déjà indiqué dans d'autres réponses, vos "clients" (ceux qui ont demandé la solution que vous construisez) ont besoin de quelque chose qu'ils peuvent comparer à leurs exigences afin d'explorer et de comprendre pleinement ces exigences (le pneu d'achat de voiture analogie). C'est pourquoi ils n'ont pas fourni de spécifications complètes et ont commencé à demander des modifications une fois que votre solution a commencé à prendre forme.

Lorsque le «client» en est conscient, il peut explicitement vous demander ou vous permettre de construire un prototype et développer une spécification plus solide basée sur ce que le prototype a révélé. Cependant, vous pouvez finir par emprunter cette même voie sans que personne (vous ou le client) en soit explicitement conscient. Le problème survient lorsque vous donnez à la livraison ce qui s'avère être le prototype, là où votre client s'attendait à ce que votre devis s'applique au produit fini.

Dans "Le mois de l'homme mythique", il est système "pilote". Essentiellement, construire un système une fois (qui sera jeté) afin d'apprendre tout ce qui est nécessaire pour reconstruire le système à nouveau, de la bonne manière, et à quelle fréquence cela se produit intentionnellement ou non. Vous êtes peut-être sur le point de terminer votre système "pilote", mais la "vraie" solution n'a pas encore été lancée.

Le mieux que vous puissiez faire à ce stade est peut-être de documenter chaque demande de changement - exactement comme vous comprenez l'exigence, et votre devis de ce qu'il faudra pour le livrer - et soyez honnête. Ne commencez pas un travail de plus de deux heures sur un simple accord verbal. Écrivez-le - même un e-mail informel vaut mieux que rien. Vous devrez peut-être vous protéger contre «ce n'est pas ce que j'ai demandé» et «vous ne m'avez pas dit que cela prendrait autant de temps». Le simple fait de dire à votre patron qu'il devrait cesser de demander des changements pourrait être mauvais sur le plan politique. Laissez la piste grandissante des descriptions de modifications citées vous expliquer comment les choses en sont arrivées là où elles sont et comment vous avez fait de votre mieux pour répondre aux demandes de vos "clients".

J'ai perdu le compte du nombre de systèmes prototypes dans lesquels j'ai été impliqué et qui ne sont pas directement en production. Méfiez-vous de la façon dont vous faites cela ...
#12
  0
moonman239
2015-06-12 08:58:18 UTC
view on stackexchange narkive permalink

Vous pouvez également dresser un tableau ou un schéma de ce que vous pensez que les clients veulent. S'ils veulent un programme qui a des solveurs d'équations, vous pouvez dessiner un schéma (UI et tout) d'un programme dans lequel l'utilisateur est présenté avec un menu, puis autorisé à appuyer sur un bouton pour sélectionner un solveur d'équations. L'équation est ensuite entrée dans une zone de texte, puis l'utilisateur clique sur un autre bouton pour dire au programme de résoudre l'équation.

Aussi, faites-vous une faveur et obtenez la réponse du client par écrit. Pensez-y comme un moyen de vous couvrir les fesses si le client dit plus tard: "Je ne voulais pas ça."

#13
  0
user5820196
2016-01-22 15:12:05 UTC
view on stackexchange narkive permalink

La communication est le meilleur moyen de résoudre votre problème. Posez des questions qu'ils en ont assez de vous et vous donneront les détails dont vous avez besoin. S'ils ne le savent pas, proposez vous-même des exigences. Documentez les réponses données et renvoyez-leur les réponses pour confirmation. De cette façon, vous indiquez clairement que la cause du retard ou du changement est due à un changement d'avis. Lorsque Mgt. dites «construisez-le à votre façon», cela signifie «faites quelque chose que je peux regarder et changer». Théoriquement, le développement de logiciels suggère qu'avant de démarrer un projet, toutes les exigences doivent être entièrement satisfaites, des descriptions détaillées des algorithmes aux maquettes d'écran. Lorsque le produit est livré, nous corrigerons bien entendu tout écart par rapport aux exigences écrites, mais aucun changement impliquant une modification des exigences n'est autorisé. Oui, cela rendrait la vie beaucoup plus facile pour le développeur de logiciels. Je ne serais pas inquiet des exigences vagues, à condition que toutes les personnes impliquées comprennent que les exigences sont vagues, que vous allez devoir combler les lacunes et que quand elles verront les décisions que vous avez prises, il y aura des décisions. qu'ils n'aiment pas et les choses devront être retravaillées. Les demandes qui sont déraisonnables et faites par le patron / la direction ou le client, alors vous devez obtenir les choses par écrit pour vous protéger. Si le patron / la direction ou le client s'attend à des délais d'exécution impossibles et vous blâme lorsque des demandes impossibles ne sont pas satisfaites, alors franchement, il est temps de commencer à chercher un autre emploi ou un autre client.

ce post est assez difficile à lire (mur de texte). Pourriez-vous le [modifier] dans une meilleure forme?
#14
-1
Paddy3118
2015-06-13 12:51:12 UTC
view on stackexchange narkive permalink

Donnez à votre patron l'interprétation minimale et la plus rapide des petites exigences qu'il vous a données et présentez-la rapidement comme une affaire conclue.

Toute future demande de changement peu claire doit être remise en question, en indiquant clairement que le changement est sorti de nulle part où on vous a demandé d'écrire votre propre truc et maintenant il est arbitrairement changé. Demandez des raisons plus concrètes pour tout changement afin que vous puissiez découvrir vos propres exigences et dire à votre patron qu'il renie le fait de vous permettre de faire votre propre truc et de le considérer comme son échec.

Si, de toute façon, vous avez une bonne relation avec votre patron, il pourrait bien vous donner une chance de briller - demandez-lui les moyens de découvrir vos propres exigences, de vous appliquer et de vous livrer!



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...