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

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!

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.

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.

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! =)

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.

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.

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.