Comment écrire une spécification fonctionnelle rapidement et efficacement


17

Je viens donc de lire quelques articles fabuleux de Joel sur les spécifications ici . (A été écrit en 2000 !!) J'ai lu les 4 parties, mais je cherche des approches méthodiques pour écrire mes spécifications.

Je suis le seul développeur solitaire à travailler sur cette application (ou famille d'applications) assez compliquée pour une société financière très connue.

Je n'ai jamais fait quelque chose d'aussi sérieux, j'ai commencé à écrire quelque chose comme une mauvaise spécification, un aperçu de certaines sortes, et cela a perdu beaucoup de temps.

J'ai également fait 3 maquettes-trucs pour mon client, donc j'ai une bonne compréhension de ce qu'ils veulent. J'ai également publié un aperçu (une application de travail à jeter avec le flux de travail le plus basique), et je n'ai écrit et testé que certains des systèmes de base / de base.

Je pense que l'erreur que j'ai commise jusqu'à présent n'est pas d'écrire une spécification détaillée, donc j'y arrive maintenant.

Donc, le tout comprend

  • Un site Web MVC (pour les administrateurs et la visualisation des données)
  • 2 modules Silverlight (pour 2 tâches spécifiques)
  • 1 application de bureau

Je suis totalement à court de temps, de ressources et j'ai besoin de faire vite, je dois aussi m'assurer que ces gars-là le lisent aussi rapidement et sans douleur.

  • Alors, comment dois-je procéder, je cherche des conseils, des trucs du monde réel, comment faites-vous habituellement les gars?
  • Faites-vous une maquette de chaque dialogue / formulaire / page?

Je pense à créer un projet de formulaires Web ASP.NET factice, puis à remplir des fichiers HTML dans des dossiers et à le faire ressembler à ma structure d'URL MVC.

Ensuite, avoir une section dans les spécifications du site Web et rédiger une page pour chaque URL que j'ai avec un screenie.

Pour mon application Win Forms, j'ai fait un peu un projet de démonstration Win Form, est- ce que je mettrais alors une boîte de dialogue ou structurerais tout comme je le ferais dans la vraie application et ensuite la capture d'écran?


Pour un peu de fond sur cette question. J'ai toujours été un mec fou de saut au code, ce qui a bien fonctionné, mais pour l'application sur laquelle je travaille, ce n'est pas seulement complexe, c'est pour une très grande et très réputée entreprise et je dois l'obtenir droite!

(Et ça s'est bien passé jusqu'à présent, aujourd'hui j'ai donné une démo de la version preview que beaucoup de gens ont aimé !! = D)

Si je réussis le design initial, j'aurai également de bonnes affaires avec cette entreprise, il y a déjà beaucoup de gens qui pensent à de nouvelles fonctionnalités "géniales" pour lesquelles ils sont prêts à payer.


C'est pour toi? Le client l'a-t-il demandé? Vous attendez-vous à ce que davantage de développeurs rejoignent l'équipe?
JeffO

C'est principalement pour aider mon développement. De temps en temps, je reçois des gars de la finance au hasard qui me disent "oh nous devrions faire xxx ou yyy" quand nous en avons déjà discuté, puis parfois dans certaines réunions, les gens suggèrent simplement des fonctionnalités aléatoires, le pire est que je n'ai jamais une bonne façon de l'ajout de fonctionnalités supplémentaires pour des frais supplémentaires parce que ma soi-disant spécification plus tôt n'était rien d'autre qu'un résumé! Fondamentalement, j'ai la plupart des problèmes que Joel Spolsky mentionne dans son article lorsque vous n'écrivez pas de spécification.
gideon

Réponses:


22

Avez-vous lu la partie 2 de l'article ou son exemple de spécification ? Ils incarnent quelques principes importants lors de la rédaction d'une spécification.

  • Ne pas trop concevoir. Le but de la rédaction de la spécification est de vous forcer à penser à des choses importantes comme ce qui se passe quand il y a une erreur et comment vous attendez de l'utilisateur qu'il interagisse avec le système. Vous n'avez pas à entrer dans des détails démesurés pour obtenir quelque chose à partir duquel vous pouvez travailler. Vous avez cependant besoin de détails.
  • Il s'agit de communication. Le but de la spécification est de parvenir à un accord commun sur ce qui doit être fait. Ce n'est pas un document à toute épreuve qui requiert force de loi. C'est un outil pour vous aider à mieux comprendre votre client et votre client à mieux comprendre ce que vous voulez faire pour lui.

Le meilleur conseil est d'écrire suffisamment pour être clair sur ce que vous devez faire. Si vous avez des questions ouvertes, documentez-les dans la spécification et obtenez des réponses de votre client. Une fois que vous avez bien compris ce qui est nécessaire, arrêtez .

Si vous ne faites pas attention, le document prendra sa propre vie. Il doit avoir un seul but, n'ajoutez rien au document qui ne correspond pas à ce but. Il devrait être facile à entretenir. Si vous avez l'intégralité de vos diagrammes de classes détaillés ainsi que d'autres détails qui appartiennent vraiment à un test unitaire, vous abandonnerez le document parce que l'entretien est trop ou vous n'obtiendrez jamais le projet terminé.


À propos de l'écriture

Écrire pour les gens est difficile . En fait, les deux choses les plus difficiles à écrire sont de savoir comment commencer et de savoir quand arrêter . Au début, il suffit de faire quelque chose. Mon conseil pour traiter ces deux aspects les plus difficiles est:

  • Connaissez votre public. Qui est censé lire la spécification? Si c'est juste vous et le client, c'est à qui vous écrivez. Si vous avez quelqu'un responsable des tests, vous aurez également quelques notes pour eux.
  • Commencez par la chose la plus prioritaire. Bien que l'authentification soit importante, l'écran de connexion est probablement l'élément le mieux compris que la plupart des gens doivent écrire. Concentrez-vous plutôt sur cette fonctionnalité dont vos utilisateurs ont le plus besoin. Vous savez, cette partie qui leur rapporte de l'argent et c'est la raison pour laquelle ils ont besoin du logiciel.
  • Remplissez les détails au fur et à mesure que les questions se posent et que vous obtenez des réponses. Gardez les choses très simples avec des dessins de serviettes si nécessaire jusqu'à ce que le client soit satisfait de l'arrangement. Il est important de savoir quelles informations sont impliquées et comment elles les utiliseront.
  • Arrêtez quand ajouter plus n'ajoute pas de valeur. Il y a des détails que vous ne voulez tout simplement pas dans une spécification. Vous devez savoir quand vous avez la bonne chose. Vous n'avez pas besoin de savoir qu'il existe une variable à l'intérieur d'une méthode nommée "albaquerque". C'est du code source, pas des éléments de spécification.

+1 merci pour votre réponse. oui. J'ai lu les 4 parties de l'article de Joels. Qu'en est-il de l'ensemble du processus de capture d'écran, devrais-je simplement créer des pages et des formulaires factices (simples)? Pour que je sache ce que je dois écrire? Ou dois-je commencer à écrire?
gideon

Commencez avec ce que vous savez. Restez simple pour ne pas vous enliser, ce qui est joli. Vous avez besoin de l'aide de quelqu'un d'autre si vous suivez cette voie (cela prend du temps que vous n'avez pas). Bien que les jolies spécifications soient plus faciles à digérer, vous avez beaucoup de travail devant vous.
Berin Loritsch
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.