Development Methodology From Developer’s Angle!!!

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

• Goals – what the goals of the whole project are – business and otherwise. This will help you decide what features are important
• Roles – who is going to use the site – visitors, logged in members, admins? Do different people have different views of the same information on the site?
• Features – what are the basic categories of interaction on the site? For example: Users: registration, using the forums, and blogging; Admins: moderating the user content

2. Écrivez une liste d'histoires

• A story is different than a feature because it represents a single thread of interaction from a particular user’s perspective.
• It’s common to express stories in form “As a ____ I want to ____ so that I can _____.” This forces you answer three important questions – Who is this for? What do they want to do? Why do they want to do it?
• If you can’t complete a story in this form, it’s likely that you don’t have an answer to one of these three questions yet, so you’ll need to do some thinking to get the answers before the story is actionable.
• Ex: “As an admin, I want to ban users from the forum, So that I can improve the quality of user-submitted content on the 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.
• The most common scales are 0/1/2/3/4, 0/1/2/4/8. I don’t think this is incredibly important, but pick something and stick with it.
• Don’t get too hung up on the exactness of the estimates. Lots of things affect how long it takes you to finish a story, so small differences in story complexity tend to get lost in the noise.
• Your goal here is to differentiate things that are low in effort, like stories that will result in you creating a simple model with a REST controller, from stories that are high in effort, like interfacing your application with a challenging third-party API, or a story that will require you to use a technology you aren’t very familiar with.
• Écrivez l'estimation sur chaque carte.

4. Priorisez les histoires

• Rearrange the cards in the order that you’d like to tackle the stories.
• Only the product owner can really make this decision. There are a lot of things that go into prioritization – deadlines, user testing, business value, etc. Estimation may have a lot to do with prioritization, because it illuminates opportunity cost. Maybe the product owner really wants that detailed Admin Dashboard, but if all the stories to make that work total 40 points, is it worth it to spend a month on just this feature. Maybe the product owner still wants the story
• Are there any stories that don’t fit into the very minimum viable product to launch? If so, you should move them down. Try to complete a functioning app as quickly as possible so you can put it in front of users.
• À 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 Write a Cucumber feature that covers the user’s interaction with the site from beginning to end. Define the undefined steps as you come to them, and when you hit your first failure, you know that there’s a behavior that you desire that your app doesn’t have (This will happen very quickly at first, because your blank app doesn’t have much behavior).
• 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.
• Repeat until the Cucumber passes, and you’re done with the story.
• Now is a good time to fix up the CSS styling assuming you have the design done. If I’m working alone or without a designer, I like to try to wireframe the UI either on paper or in something like Balsamiq Mockups before I even start coding the story.

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.
• Do all your tests pass? You didn’t break the build, did you? If so, you need to fix what you broke.
• If you’re working alone, it may be helpful to have someone else do acceptance for you, as it may be hard to see your own work with objective eyes.

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

This is how I do things. It’s by no means the only way to do things, but it is a very common way to do things in Rails. I think there’s a good debate to be had around the value of agile estimation, or of particular technologies like Cucumber vs. Steak or RSpec vs Test::Unit, but most Rails developers will agree that the proper workflow is to: 1) Identify a single story 2) Write tests for it 3) Complete it. 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

Once the application is live there is always a need to support the application so that end user will have a delightful experience. We take up AMC for the applications we develop, and engage resources to take care of new feature enhancements, bug fixes as well as 24×7 server maintenance. In short, we thereby guarantee that the application we develop is also managed and maintained well!

Outils : - BugZilla, Redmine, Pivotal Tracker, Helpdesks