Entwicklungsmethodik aus Entwicklersicht!!!

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

• Ziele – was die Ziele des gesamten Projekts sind – geschäftliche und andere. Dies wird Ihnen bei der Entscheidung helfen, welche Funktionen wichtig sind
• Rollen – wer wird die Website nutzen – Besucher, angemeldete Mitglieder, Administratoren? Haben verschiedene Personen unterschiedliche Ansichten zu denselben Informationen auf der Website?
• Funktionen – was sind die grundlegenden Kategorien der Interaktion auf der Website? Zum Beispiel: Benutzer: Registrierung, Nutzung der Foren und Bloggen; Administratoren: Moderieren der Benutzerinhalte

2. Schreiben Sie eine Liste mit Geschichten

• Eine Story unterscheidet sich von einem Feature, weil sie einen einzelnen Interaktionsstrang aus der Perspektive eines bestimmten Benutzers darstellt.
• Es ist üblich, Geschichten in der Form auszudrücken: „Als ____ möchte ich ____, damit ich _____ kann.“ Dies zwingt Sie dazu, drei wichtige Fragen zu beantworten: Für wen ist das? Was wollen sie tun? Warum wollen sie es tun?
• Wenn Sie eine Geschichte in dieser Form nicht fertigstellen können, haben Sie wahrscheinlich noch keine Antwort auf eine dieser drei Fragen. Sie müssen also etwas nachdenken, um die Antworten zu finden, bevor die Geschichte umsetzbar ist.
• Beispiel: „Als Administrator möchte ich Benutzer aus dem Forum verbannen, damit ich die Qualität der von Benutzern eingereichten Inhalte auf der Website verbessern kann.
• 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.
• Die gebräuchlichsten Skalen sind 0/1/2/3/4, 0/1/2/4/8. Ich denke nicht, dass das besonders wichtig ist, aber wählen Sie etwas aus und bleiben Sie dabei.
• Hängen Sie sich nicht zu sehr auf die Genauigkeit der Schätzungen ein. Es gibt viele Faktoren, die beeinflussen, wie lange es dauert, bis man eine Geschichte fertig hat, daher gehen kleine Unterschiede in der Komplexität der Geschichte oft im Lärm unter.
• Ihr Ziel hier ist es, Dinge zu unterscheiden, die einen geringen Aufwand erfordern, wie etwa Storys, die dazu führen, dass Sie ein einfaches Modell mit einem REST-Controller erstellen, von Storys, die einen hohen Aufwand erfordern, wie etwa die Anbindung Ihrer Anwendung an eine anspruchsvolle API eines Drittanbieters Eine Geschichte, die den Einsatz einer Technologie erfordert, mit der Sie nicht sehr vertraut sind.
• Schreiben Sie den Kostenvoranschlag auf jede Karte.

4. Priorisieren Sie die Geschichten

• Ordnen Sie die Karten in der Reihenfolge neu an, in der Sie die Geschichten angehen möchten.
• Diese Entscheidung kann wirklich nur der Product Owner treffen. Es gibt viele Dinge, die in die Priorisierung einfließen – Fristen, Benutzertests, Geschäftswert usw. Die Schätzung kann viel mit der Priorisierung zu tun haben, weil sie die Opportunitätskosten beleuchtet. Vielleicht möchte der Produktbesitzer wirklich dieses detaillierte Admin-Dashboard, aber wenn alle Storys, die dafür sorgen, dass das funktioniert, insgesamt 40 Punkte ergeben, lohnt es sich dann, einen Monat nur für diese Funktion aufzuwenden? Vielleicht möchte der Produktbesitzer die Geschichte trotzdem haben
• Gibt es Geschichten, die nicht in das Produkt passen, das auf den Markt gebracht werden soll? Wenn ja, sollten Sie sie nach unten verschieben. Versuchen Sie, eine funktionierende App so schnell wie möglich fertigzustellen, damit Sie sie den Benutzern präsentieren können.
• 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 Schreiben Sie eine Cucumber-Funktion, die die Interaktion des Benutzers mit der Site von Anfang bis Ende abdeckt. Definieren Sie die undefinierten Schritte, sobald Sie darauf stoßen, und wenn Sie zum ersten Mal fehlschlagen, wissen Sie, dass es ein gewünschtes Verhalten gibt, das Ihre App nicht haben soll (dies wird zunächst sehr schnell passieren, da Ihre leere App dies nicht tut). viel Verhalten haben).
• 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.
• Wiederholen Sie diesen Vorgang, bis die Gurke vorbei ist und Sie mit der Geschichte fertig sind.
• Jetzt ist ein guter Zeitpunkt, das CSS-Design zu korrigieren, vorausgesetzt, Sie haben das Design fertig. Wenn ich alleine oder ohne Designer arbeite, versuche ich gerne, die Benutzeroberfläche entweder auf Papier oder in etwas wie Balsamiq Mockups zu verdrahten, bevor ich überhaupt mit dem Codieren der Geschichte beginne.

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.
• Bestehen alle Ihre Tests? Du hast den Build nicht kaputt gemacht, oder? Wenn ja, müssen Sie reparieren, was Sie kaputt gemacht haben.
• Wenn Sie alleine arbeiten, kann es hilfreich sein, die Abnahme von jemand anderem übernehmen zu lassen, da es schwierig sein kann, Ihre eigene Arbeit mit objektiven Augen zu sehen.

6. Wiederholen Sie den Vorgang, bis Sie fertig sind

So mache ich Dinge. Es ist keineswegs die einzige Möglichkeit, Dinge zu tun, aber es ist eine sehr verbreitete Art, Dinge in Rails zu tun. Ich denke, es gibt eine gute Debatte über den Wert der agilen Schätzung oder bestimmter Technologien wie Cucumber vs. Steak oder RSpec vs. Test::Unit, aber die meisten Rails-Entwickler sind sich einig, dass der richtige Workflow darin besteht: 1) Identifizieren eines einzelne Geschichte 2) Schreiben Sie Tests dafür 3) Füllen Sie es aus. 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

Sobald die Anwendung live ist, besteht immer Bedarf, die Anwendung zu unterstützen, damit der Endbenutzer ein angenehmes Erlebnis hat. Wir nehmen AMC für die von uns entwickelten Anwendungen in Anspruch und engagieren Ressourcen, um uns um neue Funktionserweiterungen, Fehlerbehebungen sowie die Serverwartung rund um die Uhr zu kümmern. Kurz gesagt, wir garantieren damit, dass die von uns entwickelte Anwendung auch gut verwaltet und gewartet wird!

Tools: BugZilla, Redmine, Pivotal Tracker, Helpdesks