Wie wenden Sie Scrum auf den Design-Teil der Web-Entwicklung an?

Question

Ich fange an, etwas über Scrum zu lernen, und ich bin daran interessiert, es mit unserem Entwicklerteam auszuprobieren. Ich habe viele Fragen dazu ... aber mein größter geistiger Hinderungsgrund ist das tatsächliche grafische Design.

Mit unserem aktuellen Entwicklungszyklus [Wasserfall-esque], unser grafischer Designer legt die Seite mit allen Bildern und solche basierend auf einer losen PRD. Wenn wir die Methoden von Scrum anwenden würden, wie würde diese Entwicklung stattfinden? Ich denke, wir sind daran gewöhnt, das große Ganze zu sehen und darauf zuzusteuern ... im Gegensatz dazu, die visuellen Teile zusammenzufügen, was ich von der Scrum-Richtlinie für grafisches Design erwarte.

Wäre es unerhört, zumindest die Funktionalität im Backlog zu verkabeln? Oder wäre es klüger, im ersten Sprint seine Funktionalität so zu gestalten, dass wir die neuen Features anderer Sprints auch noch hinzufügen können? (Wenn es Zeit für ein neues Feature ist, diskutieren Sie "Wo würde das in das aktuelle Design passen?")

Answer 1

hier ist, wie ich würde vorschlagen, Sie es tun (dh, wie wir es zu tun haben versucht)

Pre-Sprint 0: stellen Sie sicher, Sie haben eine gute Vorstellung davon, was Sie tun möchten. Muss nicht sehr detailliert sein, aber sollte nicht "wir wollen eine Website, die soziale ist"

Sprint 0: Entwickler-Tool - Setup der CI-Server, arbeiten an den Bereitstellungsskripts usw., so das gesamte Grundgerüst ist fertig. Am Ende sollten Sie in der Lage sein, einen Knopf zu drücken (schlimmstenfalls: einen einzelnen Befehl auf einem REMOTE-Server ausführen), der den Code in Ihrem Versionskontrollsystem übernimmt, ihn erstellt, verpackt und alle gewünschten Tests ausführt Es meldet dies zurück und installiert es, wenn möglich, auf einem Testserver (oder atleast führt zu einem Paket, das Sie auf dem Testserver installieren können).

Zu dieser Zeit macht der Designer die Wireframes. Ihr Ziel ist es, grundlegende Wireframes für so viel von der Website zu machen, wie Sie es für notwendig halten (denken Sie an Sitemap und fließen Sie nicht an Felder und Pixel). Dann, wenn das erledigt ist, trainieren Sie mit den PM's was am wichtigsten ist, und gehen Sie ins Detail - Wireframe. Nicht Pixel YET.

Projektmanager und Ähnliches arbeiten mit dem Designer und dem Unternehmen/Stakeholder zusammen, schreiben Geschichten und Aufgaben für Sie viel zu tun und zu verfolgen. Offensichtlich müssen sie eine Idee der Sitemap usw. haben, um dies zu tun.

Dies kann mehr als einen Sprint erfordern. Beginnen Sie mit einem (ich empfehle 2-3 Wochen Sprints - 1 ist zu kurz, 4 ist zu lang), sehen Sie, wie viel Sie noch tun müssen etc.

So am Ende der Sprint 0, Sie haben:

• Viele Geschichten, in Prioritätsreihenfolge (Sie können später weitere hinzufügen, infact Sie werden immer als Anforderungen ändern)
• eine Sitemap (dh eine allgemeine Vorstellung davon, was die ganze Sache enthalten wird)
• Wireframes für den ersten Block der Arbeit
• Alle Ihre Werkzeuge arbeiten und Setup
• Sie CI, Bugtracking, Quellcodeverwaltung und Bereitstellungssysteme an Ort und Stelle sind, beginnen Sie also

dann Sprint 1

Beachten Sie, dass für den ersten 3-4 Sprint, werden Sie nicht wissen, wie viel Arbeit, die Sie im Sprint tun, so erwarten es falsch verstehen! Nimm so viel Arbeit weg (in der Reihenfolge, in der das Unternehmen/PM sie eingeführt hat), da du denkst, dass du SICHER damit fertig werden kannst. Sie können später immer mehr nehmen!

Sie entwickeln diese Seiten, und der/die Designer (n) erstellen den nächsten Seitenblock (wie von den PMs festgelegt). Vielleicht macht der Designer die Kunst für diese Seiten, so können Sie es im nächsten Sprint tun

Also, Sie entwickeln, was Sie haben, und die Designer arbeiten an Sachen für Ihren nächsten Sprint.

Natürlich könnten sie auch einen Scrum-Prozess haben, nur sie haben einen Sprint früher gestartet!

jetzt wiederholen, bis Sie aus der Arbeit laufen

während eines Sprints, wenn (beispielsweise) ein Anforderungsänderungen oder etwas Neues hinzugefügt wird, dann wird eine neue Geschichte für das geschrieben wird, und es ist in die geplante Arbeit. Wenn es eine sehr hohe Priorität hat, kann es ganz oben stehen und das Top-Item für den nächsten Sprint sein (normalerweise 1-2 Wochen). Oder es ist schön zu haben, also geht es ganz nach unten - das Geschäft entscheidet.

PMs/Designer müssen wissen, dass sie Dinge ändern können, aber Änderungen haben Konsequenzen, so dass es nicht in ihrem (finanziellen) Interesse ist, Änderungen vorzunehmen. aber die Anforderungen ändern sich, und XP und Scrum behandeln das besser als Wasserfall.

Vergessen Sie nicht:

• Sie einen Sprint jederzeit anhalten und die Planung zurückgehen, zum Beispiel, wenn die Voraussetzungen zu viel ändern, oder Sie laufen aus der Arbeit
• können Sie als weiteren Arbeitsplan Sie haben Zeit zu tun, solange diese Arbeit nicht begangen wurde (dh es ist "extra" oder "stretch" Arbeit)

Ihr PM sollte in der Lage sein, vorherzusagen, wann das Projekt enden wird - schauen wie viel Arbeit du im letzten Sprint gemacht hast (deine Geschwindigkeit) und wie viel Arbeit du noch hast um diese Zahl, und Sie erhalten die Anzahl der Sprints zu gehen. Einfach.

Oh, und lesen Sie Geschichte Punkte - nicht schätzen Geschichten in Stunden oder Tagen. Verwenden Sie Punkte. Um das zu bootstrappen, mach einfach die erste Geschichte, die du schätzst (etwa) eine 8 (die Reihenfolge ist 1,2,3,5,8,13,21,40,60,100, unendlich).Dann nimm die zweite Geschichte und schätze sie relativ zur ersten - verdopple die Arbeit (13)? die Hälfte der Arbeit (5)? ungefähr gleich (8)?

Am Ende des Sprints, summieren Sie, wie viele Punkte Sie getan haben, und das ist Ihre Geschwindigkeit. Die maximale Menge an Arbeit, die Sie im nächsten Sprint tun können, ist dieser Betrag. Du kannst den Sprint immer vorzeitig beenden oder einfach mehr Arbeit vom Backlog usw. abziehen, wenn du früh aus bist. Wenn Sie weitergehen, wird sich Ihre Geschwindigkeit stabilisieren.

Verdammt, ich bin sicher, es gibt Bücher etc. auf, wie es laufen, so dass ich von Jason :)

Answer 2

Ich habe dies schon einmal getan, wo die Designer ihre Sache in den frühen Iterationen gemacht haben, und ihr Arbeitsprodukt wurde verwendet vom Entwicklerteam in späteren Iterationen. Als das Entwicklerteam mit der Arbeit begann, gingen die Designer zu anderen Teilen des Projekts oder möglicherweise zu anderen Projekten über.

Ich denke, wir verwenden, um das große Bild zu sehen und fahre in Richtung es

du noch tun können. Ihre Designer können ein größeres Up-Front-Design erstellen, und das Entwicklerteam kann Scrum verwenden, um darauf hin zu iterieren.

Answer 3

ich stark nicht einverstanden mit der Antwort zur Verfügung gestellt stoppen. Der ganze Sinn von Scrum ist es, die Methode loszuwerden, mit der Designer zuerst "ihr Ding machen" und dann zu anderen Dingen übergehen. Das ist komplett und 100% gegen alle Lean/Scrum-Prinzipien!

Die Art, Designer in einen Scrum-Prozess einzubinden? Wirf sie in die Mischung! Stellen Sie sicher, dass Sie nicht nur ein Wasserfallprojekt in Scrum einbinden, da dies der beste Weg zum Scheitern ist! Scrum funktioniert nur, wenn es ohne Ausnahmen implementiert wird. "Scrum, aber ..." ist das schlechteste Projektmodell. Organisiere Arbeit, so dass es möglich ist, gleichzeitig zu entwerfen und zu entwickeln. Übertreiben Sie nicht das ursprüngliche Design, sondern machen Sie eine Push-Pull-Situation, bei der beide Seiten der Münze die andere beeinflussen. Der Punkt von Scrum ist es zu iterieren, zu iterieren und zu iterieren, also nützt es voll aus.

Auch ist es ziemlich schlank, tatsächlich traditionellen Photoshop-basierten Design insgesamt zu meiden. Sie können mehr über dieses von diesem ausgezeichneten Blogbeitrag in Signal gegen Geräusche lesen: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop

Answer 4

Ich möchte teilen. Ich bin der Scrum Master für ein Entwicklungsteam einer zukünftigen Social App. Dieses Team hat 1 User Interface Designer, 1 User Experience Designer (ich), 1 Frontend Entwickler (CSS, AJAX etc) und 3 Programmierer.

Dies ist unser erstes Projekt, bei dem ein SCRUM-Framework verwendet wurde. Der Trend während unserer täglichen Scrum-Meetings ist, dass unsere Designarbeit nie ganz fertig ist, weil unser anfänglicher Produkt-Backlog Geschichten wie "User will zur Anmeldung überredet werden" hat und dann fügten wir dieser Story einen "Weg zur Demo" hinzu Dort könnten wir bestimmen, was getan werden muss (dh wir müssen Drahtmodell machen, haben Copywriting gemacht, usw.)

Das könnte besser gemacht werden. Beschreibe jede Aufgabe basierend auf dieser Geschichte und schätze die Zeit für jede Aufgabe. Zum Beispiel könnten wir sie während des Produktrückstands von dort nacheinander erstellen: Site Maps> Task Flows> Wireframes

Jetzt ist die Frage, machen wir all das in einem Sprint? Oder sollten wir das schon vor einem Sprint tun? Besiegt den Zweck des Gedränge, wenn wir Sprints nicht richtig machen?

Diejenigen, die User Experience Design gemacht haben, werden wissen, dass diese Aufgaben ziemlich viel Zeit zur Vorbereitung benötigen. Warum also nicht alle diese Teile eines Sprints? Holen Sie auch Programmierer in diese Aufgaben ein.

Wireframing ist sehr wichtig während der gesamten Projektlaufzeit. Es ist wie der Bauplan eines Gebäudes, wo es von Anfang bis Ende verwendet wird.

Tun Sie also einen ersten Drahtmodell, basierend auf dem Produktstau während des ersten Sprints. Passen Sie das Drahtgitter bei jedem weiteren Sprint entsprechend an. Unsere Programmierer werden ihren Code basierend auf dem Task-Flow entwerfen und dann visuell basierend auf dem Drahtmodell erstellen.

Oh, übrigens, nicht zu viel darüber, wie das Produkt aussehen wird (tho mit einem ursprünglichen Design-Modell ist immer eine gute Sache).Konzentrieren Sie sich stattdessen auf die Bedürfnisse und Wünsche der Benutzer und entwerfen Sie einen sehr benutzerorientierten Ablauf, um genau das zu erreichen. Unser Designer wird später herausfinden, welche Art von Schnittstelle er entwickeln wird. Wenn der Drahtmodell korrekt ausgeführt wurde, wird der Designer sehr wenig Probleme beim Entwerfen der Benutzeroberfläche haben. Gleiches gilt für das Erstellen von Texten.

Zusammenfassend arbeiten Sie bei jeder Iteration Hand in Hand. Für Anfänger da draußen (wie mich) geben Sie SCRUM eine Chance, für Sie zu arbeiten. Wenn es für Firmen wie fantasyinteractive.com funktionieren kann, so kann es für Sie n mich funktionieren :)

p.s. Verwenden Sie Omnigraffle (Mac) für den guten Draht, um die Scheiße!

Answer 5

Für den Entwurfsteil in Sprint 0 können Sie eine Technik wie Stiletyles() verwenden, um den für das Projekt benötigten grafischen Stil zu bestimmen. Sie brauchen also kein großes Design im Voraus und sind immer noch agil, wenn Sie sprinten.

Answer 6

Wenn wir die Methoden von Scrum verwenden würden, wie würde diese Entwicklung stattfinden?

während dieser Beitrag ziemlich alt ist, veranlasste mich, mich selbst zu erforschen. Ich fand Jeff Patton „Zwölf Schwellen practices“ für UX-Designer/Praktiker, die ich speziell auf diese Frage apt gedacht, und ein sehr nützlich Frameset:

1. Antrieb: UX Praktiker des Kunden oder Produkt Besitzer Team.
2. Forschung, Modell und Design im Voraus - aber nur gerade genug.
3. Chunk Ihre Designarbeit
4. Verwenden Sie parallele Spurentwicklung, um voraus zu arbeiten, und folgen Sie dahinter.
5. Kaufen Sie Entwurfszeit mit komplexen technischen Geschichten.
6. Kultivieren Sie eine Benutzervalidierungsgruppe für die kontinuierliche Benutzervalidierung.
7. Planen Sie kontinuierliche Benutzerforschung in einem separaten Track von der Entwicklung.
8. Benutzerzeit für mehrere Aktivitäten nutzen.
9. Verwenden Sie RITE, um die Benutzeroberfläche vor der Entwicklung zu iterieren.
10. Prototyp in niedriger Wiedergabetreue.
11. Behandeln Sie den Prototyp als Spezifikation.
12. Werden Sie ein Design-Vermittler.

wenn man tiefer graben möchten, buchstabiert jeff es

Answer 7

Es ist einfach peasy agileproductdesign.com. out! :) Nun, lassen Sie mich teilen, wie wir es tun.

Erster Sprint

1) Produkt Eigentümer erstellt Drahtrahmen und in dem Rückstand (wir verwenden Yodiz, www.yodiz.com) 2) Unsere Grafiker Mockups erstellen und auf Mockup-Sharing-Tool setzen (www .concept.ly) 3) Unsere Entwickler arbeiten an der Einrichtung von Servern. Wenn alles bereits fertig ist, haben wir einen ziemlich smarten Product Owner, Sie haben immer Artikel im Backlog zur Auswahl.

Sprint Zwei

1) Entwickler beginnen auf den Abschluss Mockups Arbeit, die conceptly finalisiert auf wurden. 2) Designer arbeiten an anderen Drahtrahmen, die vom Produkteigner im Rückstand hinzugefügt wurden.

Ich sagte Ihnen, es ist einfach!