Agile Entwicklungsmethodik für
Rails-App bauen
Wir schreiben eine Liste von Zielen, Rollen und Funktionen auf
- Ziele - was sind die Ziele des gesamten Projekts - geschäftlich und anderweitig. Dies wird Ihnen helfen zu entscheiden, welche Funktionen wichtig sind
- Rollen - wer wird die Website nutzen - Besucher, eingeloggte Mitglieder, Administratoren? Haben verschiedene Personen unterschiedliche Sichtweisen auf dieselben Informationen auf der Website?
- Funktionen - Was sind die grundlegenden Kategorien der Interaktion auf der Website? Zum Beispiel: Benutzer: Registrierung, Nutzung der Foren und Blogging; Administratoren: Moderation der Benutzerinhalte
Wir schreiben eine Liste von Geschichten
- Eine Story unterscheidet sich von einem Feature, weil sie einen einzelnen Interaktionsstrang aus der Perspektive eines bestimmten Nutzers darstellt.
- Es ist üblich, Geschichten in der Form auszudrücken: "Als ____ möchte ich ____, damit ich _____ kann." Das 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 vervollständigen können, haben Sie wahrscheinlich noch keine Antwort auf eine dieser drei Fragen, so dass Sie etwas nachdenken müssen, 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.
Wir schätzen 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 dies unglaublich wichtig ist, aber wählen Sie etwas und bleiben Sie dabei.
- Machen Sie sich nicht zu viele Gedanken über die Genauigkeit der Schätzungen. Es gibt viele Faktoren, die sich darauf auswirken, wie lange Sie für die Fertigstellung einer Geschichte brauchen, so dass kleine Unterschiede in der Komplexität der Geschichte im Rauschen untergehen.
- Ihr Ziel ist es hier, Dinge mit geringem Aufwand, wie z.B. Stories, die zur Erstellung eines einfachen Modells mit einem REST-Controller führen, von Stories mit hohem Aufwand zu unterscheiden, wie z.B. die Anbindung Ihrer Anwendung an eine anspruchsvolle API eines Drittanbieters oder eine Story, die den Einsatz einer Technologie erfordert, mit der Sie nicht sehr vertraut sind.
- Schreiben Sie den Kostenvoranschlag auf jede Karte.
Wir priorisieren die Geschichten
- Ordnen Sie die Karten in der Reihenfolge an, in der Sie die Geschichten angehen möchten.
- Diese Entscheidung kann wirklich nur der Produktverantwortliche treffen. Bei der Festlegung von Prioritäten spielen viele Faktoren eine Rolle - Fristen, Benutzertests, Geschäftswert usw. Die Schätzung kann viel mit der Prioritätensetzung zu tun haben, weil sie die Opportunitätskosten beleuchtet. Vielleicht möchte der Product Owner wirklich ein detailliertes Admin Dashboard, aber wenn alle Stories, die dazu nötig sind, insgesamt 40 Punkte ausmachen, ist es das wert, einen Monat nur für diese Funktion zu verwenden. Vielleicht möchte der Product Owner die Story trotzdem haben
- Gibt es Geschichten, die nicht in das Minimum Viable Product to Launch passen? Wenn ja, sollten Sie sie nach unten verschieben. Versuchen Sie, so schnell wie möglich eine funktionierende App fertigzustellen, damit Sie sie den Nutzern zur Verfügung stellen können.
- Zu diesem Zeitpunkt verschiebe ich meine Karten normalerweise in Pivotal Tracker, aber ich kenne viele Leute, die Stift und Papier bevorzugen.
Wir testen die erste Geschichte bis zur Fertigstellung
- Beginnen Sie mit Cucumber Schreiben Sie eine Cucumber-Funktion, die die Interaktion des Benutzers mit der Website von Anfang bis Ende abdeckt. Definieren Sie die undefinierten Schritte, wenn Sie auf sie stoßen, und wenn Sie auf Ihren ersten Fehler stoßen, wissen Sie, dass es ein Verhalten gibt, das Sie wünschen, das Ihre App aber nicht hat (das wird am Anfang sehr schnell passieren, weil Ihre leere App nicht viel Verhalten hat).
- 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, um die Spezifikation zu erfüllen. Dies wird Sie durch Ihre gesamte Anwendung führen, vom Routing über die Benutzeroberfläche, die Modelle, das Datenbankschema bis hin zum Controller. Sie werden diese Teile des Codes in der Reihenfolge angehen, in der Ihre Tests Sie dazu anweisen.
- Wiederhole das, bis die Gurke vorbei ist und du mit der Geschichte fertig bist.
- Jetzt ist ein guter Zeitpunkt, um das CSS-Styling zu korrigieren, vorausgesetzt, Sie haben das Design fertig. Wenn ich alleine oder ohne einen Designer arbeite, versuche ich gerne, die Benutzeroberfläche entweder auf Papier oder in etwas wie Balsamiq Mockups zu skizzieren, bevor ich mit der Codierung der Geschichte beginne.
Wir akzeptieren 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? Sie haben den Build nicht beschädigt, oder? Wenn ja, müssen Sie reparieren, was Sie kaputt gemacht haben.
- Wenn Sie alleine arbeiten, kann es hilfreich sein, wenn jemand anderes die Abnahme für Sie übernimmt, da es schwierig sein kann, Ihre eigene Arbeit mit objektiven Augen zu sehen.
Wir wiederholen, bis wir fertig sind
So gehe ich die Dinge an. Es ist keineswegs der einzige Weg, Dinge zu tun, aber es ist eine sehr häufige Art, Dinge in Rails zu tun. Ich denke, es gibt eine gute Debatte um den Wert der agilen Schätzung, oder von bestimmten Technologien wie Cucumber vs. Steak oder RSpec vs Test::Unit, aber die meisten Rails-Entwickler werden zustimmen, dass der richtige Workflow ist:
1) Identifizieren Sie eine einzelne Geschichte
2) Schreiben Sie Tests dafür
3) Vervollständigen Sie es.
German 
English 
Japanese 
French 
Spanish 
Italian 
Swedish