Dans quelle mesure un logiciel doit-il être bien défini avant de commencer à coder?


13

Je voulais savoir dans quelle mesure les gens définissent généralement un produit logiciel avant de commencer à coder et dans quelle mesure cela a fonctionné pour eux? Je fais référence à la définition de cas d'utilisation, à l'analyse des risques, à l'élaboration de diagrammes de classes, etc.

Je sais que c'est une bonne idée d'avoir une assez bonne idée de ce que sera le produit final pour pouvoir éviter les risques à l'avenir, mais il est également important de ne pas définir un produit si bien qu'il est difficile de s'y adapter changement.

D'autres questions plus spécifiques seraient probablement:

  1. Quel pourcentage du temps d'un projet est normalement consacré aux étapes de planification avant le développement?

  2. Avez-vous certains critères mesurables que vous essayez de respecter avant de commencer à coder ou est-ce plus une affaire d'intestin?

  3. Avez-vous schématisé toutes les classes avant de commencer à coder, ou essaie-t-il principalement de créer une conception dynamique depuis le début en s'attendant à ce que les choses changent?

Toute expérience que vous êtes prêt à partager serait géniale!

Réponses:


10

La réponse littérale à "comment bien défini?" est

Assez bien défini pour que vous puissiez commencer.

Assez bien défini pour que vous puissiez identifier une portée de travail initiale (pour un concept initial). C'est juste assez pour aider à identifier les changements qui se produiront inévitablement.

Assez bien défini pour que vous puissiez hiérarchiser les sprints.

Je fais référence à la définition de cas d'utilisation,

Toujours serviable. Mais pas tous . Vous devez d'abord hiérarchiser et couvrir les cas d'utilisation importants. D'autres cas d'utilisation seront couverts dans les versions ultérieures. Certains cas d'utilisation auront une priorité si faible qu'ils ne seront jamais réalisés.

analyser les risques,

Généralement une perte de temps.

dessin de diagrammes de classes, etc.

Si ça aide.

Quel pourcentage du temps d'un projet est normalement consacré aux étapes de planification avant le développement?

Cela varie beaucoup. Achetez un bon livre, comme Software Engineering Economics pour obtenir des chiffres "faisant autorité".

Avez-vous certains critères mesurables que vous essayez de respecter avant de commencer à coder ou est-ce plus une affaire d'intestin?

"mesurable". C'est presque impossible à définir.

"intestin". Mauvaise politique.

Le problème est "comprenez-vous ce que vous faites?"

Ce n'est pas quelque chose d'intestin. C'est une question Oui / Non.

Ce n'est pas "mesurable" car c'est juste une question oui / non.

Et, en outre, vous devez établir des priorités. Tu ne fais pas tout. Juste assez pour gérer les premiers sprints.

Avez-vous schématisé toutes les classes avant de commencer à coder, ou essaie-t-il principalement de créer une conception dynamique depuis le début en s'attendant à ce que les choses changent?

Vous ne pouvez pas tout savoir à l'avance.

N'essaye pas.


Personnellement, je trouve que passer trop de temps à écrire des diagrammes de classes est une perte de temps car le modèle et le code avec lui changent de toute façon après avoir commencé.
AndersK

Je suis d'accord que vous ne pouvez pas tout savoir à l'avance, mais un bon document de conception vous aidera au moins à identifier la portée et le fluage des fonctionnalités quand cela se produit.
Tim Post

@Tim Post: Bonne suggestion. C'est une façon de définir le "comment bien défini" dans la question. Il "vous aidera à identifier la portée et le fluage des fonctionnalités". Pas beaucoup plus, non?
S.Lott

@Tim Post: "identifier la portée" est trompeur. Cela implique qu'il existe une certaine connaissance précise de la «portée» à votre disposition au début du projet, ce qui n'est pas vrai. La portée changera tout au long du cycle de vie du projet à mesure que les besoins de l'entreprise évoluent, car aucun marché n'est statique.
Rein Henrichs

@Rein Henrichs: J'ai légèrement modifié la réponse pour intégrer votre point. Assez de définition de portée pour commencer. Je suis tenté d'ajouter "et pas plus".
S.Lott

2

Si votre client rejoint activement le projet en tant que membre de l'équipe de projet, qui est disponible pour les développeurs pour des questions et prendre des décisions rapides sur les fonctionnalités. La spécification pourrait alors être moins détaillée.

Si votre client est loin et n'est pas disponible pour des commentaires sur une longue période, votre spécification doit être très détaillée.

Dans notre entreprise, nous créons des user stories et jouons à Planning Poker avec les développeurs du projet. Cela nous donne une bonne indication des heures à consacrer à une user story.


Un «représentant du client» (le rôle que vous proposez au client) est le rôle le plus vital de toute l'équipe. Si votre équipe ne parvient pas à obtenir des réponses sur les produits et les questions commerciales, comment sont-elles censées prendre la bonne décision?
Rein Henrichs

C'est un grand point, merci! Je n'ai pas envisagé comment l'implication du client pouvait changer si radicalement ce qui fonctionnait le mieux pour un projet donné. Certainement quelque chose que je devrais garder à l'esprit. De plus, je n'avais jamais entendu parler de "Planning Poker" et il semble que ce serait vraiment précieux.
attiré le

2

Le degré de définition du projet doit être suffisant pour vous permettre de démarrer et de savoir où vous allez vous diriger au cours des deux prochaines semaines.

En tant que Scrum Master, je dirais simplement que vous devez définir les fonctionnalités brutes de votre produit dans une feuille Excel ou ailleurs, uniquement pour garder une trace de vos fonctionnalités. En faire des User Stories aide beaucoup à réfléchir à la fonctionnalité dont vous avez besoin ensuite. Ensuite, hiérarchisez-les: la fonction la plus importante ou impérative vers le haut et la moins vers le bas.

Une fois que vous avez répertorié certaines des fonctionnalités les plus importantes, sélectionnez les fonctionnalités que vous pensez pouvoir développer amener à l'état Terminé après une période de deux semaines, ou un mois si vous préférez. Ensuite, décomposez ces fonctionnalités sélectionnées afin que vous puissiez commencer à coder en quelques-unes.

Lors du codage, vous penserez certainement à d'autres éléments à développer afin de mettre vos fonctionnalités sélectionnées dans un état Terminé. Terminé signifie que vous n'avez plus rien à faire, c'est-à-dire les tests, le codage, l'assemblage, la documentation est terminée!

À tout moment, votre liste de fonctionnalités sélectionnée peut s'allonger, tant que vous atteignez l'objectif, c'est-à-dire que vous êtes en mesure de développer tout ce que vous aviez dit au cours de la période donnée.

Bref, rien ne doit être parfait. Ajoutez quelques idées, partagez avec vos camarades et voyez si ce qui est écrit est logique pour répondre aux exigences des produits demandés. Si oui, alors vous y êtes! Pour être clair, j'irai avec un simple produit de gestion de la clientèle. Ce qui est necessaire?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Votre première ébauche pourrait être aussi simple que ça! Ensuite, nous pouvons voir que la sécurité est une partie importante de notre système, est-elle suffisamment importante pour faire la priorité ultime (O / N)? Cela dépendra des exigences que vous devrez satisfaire. Disons que la gestion des clients est la chose la plus cruciale ici. Donc, dans le prochain Sprint, nous devons être en mesure de gérer les clients d'une manière basique mais acceptable. Qu'est-ce que la gestion des clients?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Cela illustre déjà suffisamment de fonctionnalités pour pouvoir commencer à développer l'application. Si vos programmeurs ont besoin d'instructions supplémentaires, alors peut-être qu'un développeur qui est à l'aise avec les diagrammes de classes peut concevoir la classe Client et ses propriétés et méthodes! Mais en ce qui me concerne, avec ces quelques-uns que j'ai écrits, j'en aurais assez pour commencer. Certaines fonctionnalités peuvent être ajoutées ou modifiées en cours de route. Ce qui est important, c'est de se concentrer sur ce que vous avez dit qui allait être fait. Dans notre exemple, c'est la gestion des clients. Nous n'avons pas besoin de nous soucier de l'authentification des utilisateurs pour l'instant. Cela viendra plus tard dans le prochain Sprint.

J'espère que ça aide! =)


Merci beaucoup! C'était formidable de voir cela dans un scénario aussi spécifique. Je pense que c'est un bon cadre pour avoir quelque chose qui est au moins quelque peu mesurable par rapport à ce que vous définissez sur le produit global mais en mettant l'accent sur les sous-objectifs et une approche orientée fonctionnalité. Cette approche sera certainement importante alors que je commence de nouveaux projets à l'avenir!
attiré le

Vous êtes les bienvenus! Je suis content que mon grain de sel puisse vous aider! =) Il est important de ne pas définir trop de fonctionnalités en profondeur, car les exigences du produit peuvent changer en cours de route car le client, lorsqu'il verra ce que vous avez fait jusqu'à présent, peut avoir d'autres idées ou modifications à apporter à ce que vous avez Terminé. Vous devrez ajuster le produit en conséquence afin qu'il réponde aux nouvelles exigences. Donc, si vous avez tout établi en même temps au début du projet, imaginez la perte de travail que cela pourrait causer! Peut-être aurez-vous travaillé des heures juste pour le jeter et recommencer à zéro. Laissez-le évoluer =)
Will Marcouiller

1

Eh bien, ce qui fonctionne très bien pour moi, c'est d'avoir la fonctionnalité "assez bien" spécifiée et l'architecture logicielle spécifiée de manière très lâche.

Pour commencer à travailler, j'ai besoin de savoir vers quoi je travaille. Cela ne fonctionne pas pour moi lorsque je comprends simplement les besoins du client. Même si j'écris un outil pour mon propre usage, je dessine les écrans, décris la fonctionnalité, ce que fait chaque bouton, tout. Sinon, je trouve que je ne peux pas commencer.

D'un autre côté, j'ai renoncé à vraiment dessiner exactement comment je vais développer le code. C'est peut-être une pire pratique, mais ça marche pour moi. Je pourrais définir un ensemble de tables de base de données que je vais créer, mais pas quelles colonnes se trouvent dans chacune. Je pourrais penser aux objets et aux classes dont j'ai besoin, mais je ne dessine certainement pas de diagrammes.

Enfer, parfois je ne sais même pas comment le faire correctement avant d'avoir mal agi. Je le construis une fois, je le démonte et je recommence, maintenant que je sais comment. À ce stade, je peux dessiner une feuille de route assez détaillée et redémarrer.


Merci d'avoir partagé votre expérience. Il semble aller de pair avec le consensus selon lequel l'important est que vous, en tant que développeur, vous sentiez suffisamment à l'aise pour commencer. Bien sûr, vous découvrirez des choses que vous changeriez si vous le faisiez à nouveau, sinon vous avez passé trop de temps à planifier. Je connais le sentiment de vouloir faire une réécriture complète dès qu'un produit est terminé, et c'est en quelque sorte ce que j'essaie d'éviter;) (au moins à un degré raisonnable).
attiré le

1

Quel langage et quelle méthodologie utilisez-vous?

Certains langages, comme Java et C ++, nécessitent plus de structure initiale que des langages comme Common Lisp ou Python (C ++ plus que Java, car le refactoring est plus facile en Java). Leo Brodie (je pense dans "Thinking Forth") a donné deux conseils sur le moment de commencer le codage: plus tôt que vous vous sentez à l'aise avec Forth, plus tard que vous le souhaitez dans une autre langue.

La méthodologie de la cascade (en particulier lorsque la conception précoce est un livrable) nécessitera plus de travail initial que l'agile (bien que vous ne souhaitiez pas non plus négliger la planification précoce des méthodes agiles). Avoir un bon ensemble de tests automatisés rend plus sûr de changer des choses plus grandes et vous permet donc de vous en tirer avec moins de travail initial.

Cela dépend également des individus et de leur familiarité avec le type de logiciel à créer. À un moment donné, lorsque je faisais principalement des applications CRUD, je pouvais écrire un programme complet commençant par quelques spécifications et un morceau de papier vierge de 3 "x5". Je ne peux pas écrire ce que j'écris maintenant comme ça.


Merci pour la perspective. Je n'avais pas réfléchi à la façon dont le langage et la plateforme pouvaient affecter les meilleures pratiques en matière de gestion de projet. Il se trouve que je parle principalement d'Objective-C, UIKit et AppKit. Cependant, je travaille également dans un tas d'autres langages (C, C ++, C #, Java, Python, etc.). Cela signifie que je devrais faire attention à ne pas supposer qu'une certaine méthode sera la meilleure pour tous les projets, je devrais ajuster ma base de méthodologie sur la plate-forme et la langue cibles (et peut-être choisir une langue basée sur cela si j'ai le choix).
attiré le

1

Deux termes utiles ici sont MVP (Minimum Viable Product) et MMF (Minimum Marketable Feature). Un MMF est la plus petite version d'une fonctionnalité qui offre une valeur commerciale. Un MVP est le moins de MMF qui soit viable en tant que produit. Lors du démarrage d'un projet, la meilleure chose à faire est d'identifier les MMF et MVP et de commencer à partir de là.

Libérez votre produit dès qu'il est viable, puis continuez à l'améliorer progressivement.


C'est une très bonne terminologie, merci! C'est de loin la meilleure chose ici pour arriver à quelque chose de mesurable. Bien sûr, ce n'est pas parfait, mais il semble qu'il sera raisonnablement facile de décider si une fonctionnalité est commercialisable et / ou si elle ajoute de la valeur au produit.
attiré le
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.