Development Methodology From Developer’s Angle!!!

Laut einem Entwickler besteht die Entwicklungsmethodik darin, den folgenden Pfad für die Ruby on Rails-Anwendungsentwicklung zu verwenden.

1. Schreiben Sie eine Liste mit Zielen, Rollen und Funktionen auf

• 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. Schreiben Sie eine Liste mit Geschichten

• 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.
• Schreiben Sie diese Geschichten auf Notizkarten. Dies hilft Ihnen bei der Einschätzung und Priorisierung.

3. Schätzen Sie die Geschichten

• Schätzungen sind an sich schon ein riesiges Thema, aber die Grundidee besteht darin, jeder Geschichte ein bestimmtes Maß an Aufwand zuzuordnen.
• 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.
• Schreiben Sie den Kostenvoranschlag auf jede Karte.

4. Priorisieren Sie die Geschichten

• 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.
• Zu diesem Zeitpunkt verschiebe ich meine Karten normalerweise in Pivotal Tracker, aber ich kenne viele Leute, die Stift und Papier bevorzugen.

5. Testen Sie die erste Geschichte bis zur Fertigstellung

• Beginnen Sie mit Gurke 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).
• Wenn ich Javascript-Interaktionen habe, die ein wichtiger Teil der Benutzerinteraktion sind, versuche ich, diese mithilfe des @javascript-Tags von Cucumber testen zu lassen.
• Weiter zu Rspec Schreiben Sie den Test für das Verhalten, das Sie sich wünschen.
• Schreiben Sie Ihren Code Schreiben Sie den Code, damit die Spezifikation erfolgreich ist. Dies führt Sie durch Ihre gesamte Anwendung, vom Routing über die Benutzeroberfläche, die Modelle, das Datenbankschema bis hin zum Controller. Sie werden diese Codeteile in der Reihenfolge in Angriff nehmen, zu der Sie durch Ihre Tests aufgefordert werden.
• 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. Akzeptieren Sie die Geschichte

• Ist die Geschichte akzeptabel? Macht es das, was Sie wollten? Wenn nicht, müssen Sie zurückgehen und dafür sorgen, dass es so funktioniert, wie es sollte. Das vorherige Schreiben von Gurkentests hilft, dies zu verhindern.
• 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. Wiederholen Sie den Vorgang, bis Sie fertig sind

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. Bereitstellung

Aufgrund der Skalierbarkeit, Betriebszeit, Kosteneffizienz und vieler anderer Faktoren empfehlen wir, die Anwendung in der Cloud bereitzustellen. Wir sind Experten für die Bereitstellung in der Cloud, sei es Heroku, Rackspace oder AWS.

Tools: - Capistrano, Apache, Passenger, Heroku, GIT/SVN (hauptsächlich wird GIT verwendet)

8. Unterstützung nach der Bereitstellung

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!

Tools: BugZilla, Redmine, Pivotal Tracker, Helpdesks