Méthodologie de développement agile pour
Construire une application Rails
Nous dressons une liste des objectifs, des rôles et des caractéristiques.
- Objectifs - quels sont les objectifs de l'ensemble du projet, qu'ils soient commerciaux ou autres. Cela vous aidera à décider quelles sont les caractéristiques importantes
- Rôles - qui va utiliser le site - visiteurs, membres connectés, administrateurs ? Différentes personnes ont-elles des points de vue différents sur la même information sur le site ?
- Fonctionnalités - quelles sont les catégories de base d'interaction sur le site ? Par exemple : Utilisateurs : inscription, utilisation des forums et création de blogs ; Administrateurs : modération du contenu des utilisateurs.
Nous rédigeons une liste d'histoires
- Une histoire est différente d'une fonctionnalité car elle représente un fil unique d'interaction du point de vue d'un utilisateur particulier.
- Il est courant d'exprimer les histoires sous la forme suivante : "En tant que ____, je veux ____ pour pouvoir _____". Cela vous oblige à répondre à trois questions importantes - À qui cela s'adresse-t-il ? Que veulent-ils faire ? Pourquoi veulent-ils le faire ?
- Si vous ne pouvez pas compléter une histoire sous cette forme, il est probable que vous n'ayez pas encore de réponse à l'une de ces trois questions, et vous devrez donc réfléchir pour obtenir les réponses avant que l'histoire ne soit exploitable.
- Ex : "En tant qu'administrateur, je souhaite bannir des utilisateurs du forum, afin d'améliorer la qualité du contenu soumis par les utilisateurs sur le site.
- Écrivez ces histoires sur des fiches. Cela vous aidera dans l’estimation et la priorisation.
Nous estimons les histoires
- L’estimation est un vaste sujet en soi, mais l’idée de base est d’associer un niveau d’effort particulier à chaque histoire.
- Les échelles les plus courantes sont 0/1/2/3/4, 0/1/2/4/8. Je ne pense pas que cela soit très important, mais choisissez quelque chose et tenez-vous en à cela.
- Ne vous souciez pas trop de l'exactitude des estimations. Beaucoup de choses influencent le temps qu'il vous faut pour terminer une histoire, de sorte que les petites différences dans la complexité de l'histoire ont tendance à se perdre dans le bruit.
- Votre objectif ici est de différencier les choses qui demandent peu d'efforts, comme les histoires qui vous amèneront à créer un simple modèle avec un contrôleur REST, des histoires qui demandent beaucoup d'efforts, comme l'interfaçage de votre application avec une API tierce difficile, ou une histoire qui vous demandera d'utiliser une technologie avec laquelle vous n'êtes pas très familier.
- Écrivez l'estimation sur chaque carte.
Nous donnons la priorité aux histoires
- Réorganisez les cartes dans l'ordre dans lequel vous souhaitez aborder les histoires.
- Seul le responsable du produit peut réellement prendre cette décision. De nombreux éléments entrent en ligne de compte dans l'établissement des priorités : les délais, les tests auprès des utilisateurs, la valeur commerciale, etc. L'estimation peut avoir beaucoup à voir avec l'établissement des priorités, car elle met en lumière le coût d'opportunité. Peut-être que le propriétaire du produit veut vraiment ce tableau de bord administratif détaillé, mais si toutes les histoires pour le faire fonctionner totalisent 40 points, cela vaut-il la peine de passer un mois sur cette seule fonctionnalité. Peut-être que le propriétaire du produit veut toujours l'histoire
- Y a-t-il des histoires qui ne correspondent pas au produit minimum viable à lancer ? Si c'est le cas, vous devriez les déplacer vers le bas. Essayez de mettre au point une application fonctionnelle le plus rapidement possible afin de pouvoir la présenter aux utilisateurs.
- À ce stade, je déplace généralement mes cartes dans Pivotal Tracker, mais je connais beaucoup de gens qui préfèrent le stylo et le papier.
Nous testons la première histoire jusqu'à son achèvement
- Commencer avec Cucumber Ecrire une fonctionnalité Cucumber qui couvre l'interaction de l'utilisateur avec le site du début à la fin. Définissez les étapes indéfinies au fur et à mesure que vous les rencontrez, et lorsque vous rencontrez votre premier échec, vous savez qu'il y a un comportement que vous souhaitez et que votre application n'a pas (cela se produira très rapidement au début, parce que votre application vierge n'a pas beaucoup de comportement).
- Si j'ai des interactions Javascript qui sont un élément clé de l'interaction utilisateur, j'essaie de demander à Cucumber de les tester à l'aide de la balise @javascript.
- Continuer à Rspec Rédigez le test pour le comportement que vous souhaiteriez avoir.
- Écrivez votre code Écrivez le code pour faire passer la spécification. Cela va vous emmener tout au long de votre application, du routage à l'interface utilisateur, aux modèles, au schéma de la base de données, au contrôleur. Vous vous attaquerez à ces éléments de code dans l'ordre indiqué par vos tests.
- Répétez l'opération jusqu'à ce que le concombre passe et que vous ayez terminé l'histoire.
- C'est le bon moment pour corriger le style CSS, en supposant que vous ayez terminé la conception. Si je travaille seul ou sans designer, j'aime essayer de filmer l'interface utilisateur sur papier ou dans un logiciel comme Balsamiq Mockups avant même de commencer à coder l'histoire.
Nous acceptons l'histoire
- L'histoire est-elle acceptable ? Est-ce qu'il fait ce que vous vouliez ? Sinon, vous devez revenir en arrière et faire en sorte que cela fonctionne comme prévu. Écrire des tests Cucumber à l’avance permet d’éviter que cela ne se produise.
- Est-ce que tous vos tests sont réussis ? Vous n'avez pas cassé la compilation, n'est-ce pas ? Si c'est le cas, vous devez réparer ce que vous avez cassé.
- Si vous travaillez seul, il peut être utile de demander à quelqu'un d'autre de procéder à l'acceptation pour vous, car il peut être difficile de voir votre propre travail d'un œil objectif.
Nous répétons l'opération jusqu'à ce qu'elle soit terminée
C'est ainsi que je fais les choses. Ce n'est en aucun cas la seule façon de faire les choses, mais c'est une façon très commune de faire les choses dans Rails. Je pense qu'il y a un bon débat à avoir sur la valeur de l'estimation agile, ou de technologies particulières comme Cucumber vs. Steak ou RSpec vs Test::Unit, mais la plupart des développeurs Rails seront d'accord pour dire que le bon flux de travail est de :
1) Identifier une histoire unique
2) Écrire des tests
3) Complétez-le.
French 
English 
Japanese 
German 
Spanish 
Italian 
Swedish