Méthodologie de développement du point de vue du développeur !!!

La méthodologie de développement selon un développeur consiste à utiliser le chemin suivant pour le développement d'applications Ruby on Rails.

1. Rédigez une liste d'objectifs, de rôles et de fonctionnalités

• Objectifs – quels sont les objectifs de l’ensemble du projet – commercial et autre. Cela vous aidera à décider quelles fonctionnalités sont 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 les mêmes informations 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 blogs ; Administrateurs : modérer le contenu de l'utilisateur

2. Écrivez une liste d'histoires

• Une histoire est différente d'une fonctionnalité car elle représente un seul fil d'interaction du point de vue d'un utilisateur particulier.
• Il est courant d'exprimer des histoires sous la forme « En tant que ____, je veux ____ pour pouvoir _____. » Cela vous oblige à répondre à trois questions importantes : à qui s’adresse-t-il ? Qu'est-ce qu'ils veulent faire? Pourquoi veulent-ils le faire ?
• Si vous ne parvenez pas à terminer une histoire sous cette forme, il est probable que vous n'ayez pas encore de réponse à l'une de ces trois questions. 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 les utilisateurs du forum, afin de pouvoir 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.

3. Estimer 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 ce soit extrêmement important, mais choisissez quelque chose et respectez-le.
• Ne vous attardez pas trop sur l'exactitude des estimations. Beaucoup de choses affectent le temps qu'il vous faut pour terminer une histoire, donc 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 éléments qui demandent peu d'effort, comme les histoires qui vous amèneront à créer un modèle simple avec un contrôleur REST, des histoires qui demandent beaucoup d'effort, comme l'interface de votre application avec une API tierce complexe, ou une histoire qui vous demandera d'utiliser une technologie que vous ne connaissez pas très bien.
• Écrivez l'estimation sur chaque carte.

4. Priorisez les histoires

• Réorganisez les cartes dans l'ordre dans lequel vous souhaitez aborder les histoires.
• Seul le Product Owner peut réellement prendre cette décision. De nombreux éléments entrent en compte dans la priorisation : les délais, les tests utilisateur, la valeur commerciale, etc. L'estimation peut avoir beaucoup à voir avec la priorisation, 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 d'administration détaillé, mais si toutes les histoires pour que cela fonctionne totalisent 40 points, cela vaut-il la peine de consacrer un mois uniquement à cette 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 terminer 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.

5. Testez la première histoire jusqu'à son terme

• Commencez par le concombre Écrivez une fonctionnalité Cucumber qui couvre l'interaction de l'utilisateur avec le site du début à la fin. Définissez les étapes non définies au fur et à mesure que vous y arrivez, et lorsque vous rencontrez votre premier échec, vous savez qu'il y a un comportement que vous désirez et que votre application n'a pas (cela se produira très rapidement au début, car votre application vierge ne le fait pas). avoir 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 vers Rspec Écrivez le test pour le comportement que vous souhaiteriez avoir.
• Écrivez votre code Écrivez le code pour faire passer la spécification. Cela vous mènera tout au long de votre application, du routage à l'interface utilisateur, aux modèles, au schéma de base de données et au contrôleur. Vous aborderez ces morceaux de code dans l’ordre vers lequel vos tests vous dirigent.
• Répétez 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 la conception soit terminée. Si je travaille seul ou sans designer, j'aime essayer de wireframe l'interface utilisateur soit sur papier, soit dans quelque chose comme Balsamiq Mockups avant même de commencer à coder l'histoire.

6. Acceptez 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 réussissent ? Vous n'avez pas cassé la construction, n'est-ce pas ? Si tel est le cas, vous devez réparer ce que vous avez cassé.
• Si vous travaillez seul, il peut être utile que quelqu'un d'autre fasse l'acceptation à votre place, car il peut être difficile de voir votre propre travail avec des yeux objectifs.

6. Répétez jusqu'à ce que vous ayez terminé

C’est comme ça que je fais les choses. Ce n’est en aucun cas la seule façon de faire les choses, mais c’est une manière très courante de faire les choses dans Rails. Je pense qu'il y a un bon débat à avoir autour de 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 conviendront que le flux de travail approprié consiste à : 1) Identifier un histoire unique 2) Écrivez des tests pour celle-ci 3) Complétez-la. 7. Déploiement

Nous vous conseillons de déployer l'application sur le cloud en raison de l'évolutivité, de la disponibilité, de la rentabilité et de nombreux autres facteurs. Nous sommes experts en déploiement sur cloud, que ce soit Heroku, Rackspace ou AWS.

Outils : - Capistrano, Apache, Passenger, Heroku, GIT/SVN (la plupart du temps, GIT est utilisé)

8. Prise en charge post-déploiement

Une fois l'application en ligne, il est toujours nécessaire de la prendre en charge afin que l'utilisateur final vive une expérience agréable. Nous utilisons AMC pour les applications que nous développons et engageons des ressources pour nous occuper des nouvelles améliorations de fonctionnalités, des corrections de bugs ainsi que de la maintenance du serveur 24h/24 et 7j/7. Bref, nous garantissons ainsi que l’application que nous développons est également bien gérée et entretenue !

Outils : - BugZilla, Redmine, Pivotal Tracker, Helpdesks