Wo sollte Design in einen agilen Prozess eingebunden werden?

Damit haben wir auch zu kämpfen. Das fasst unsere Reise irgendwie zusammen, das heißt nicht, dass die gleichen Dinge für Sie gelten!

Designarbeit wird im Sprint erledigt

Früher war das in Ordnung, als wir lange Sprints (4 Wochen) machten und es Zeit für ein Hin und Her zwischen dem Designer, UX und dem Marketing gab, wie das endgültige Design aussehen sollte. Selbst in langen Sprints würden die Stakeholder mehr Zeit zum Nachdenken wünschen, als im Sprint vorhanden wäre, wenn wir ein ganz anderes Design als das, was derzeit existiert, machen würden (z. B. Marken-Redesign). Ich denke, dieser Ansatz kann funktionieren, wenn Ihre Sprintlänge angemessen lang ist, Sie nach strengen Markenrichtlinien arbeiten und Ihr PO Designs selbst absegnen kann, ohne zu anderen Stakeholdern gehen zu müssen

Als unsere Iterationen kürzer wurden und wir durch immer mehr Geschichten, die auf die Freigabe des Designs warteten, verbrannt wurden, versuchten wir Folgendes:

Design als separate Geschichten

Dadurch konnten wir die Arbeit früher einbringen und besser planen, wann wir mit der Designarbeit beginnen mussten, um sicherzustellen, dass sie rechtzeitig für die Arbeit an der Geschichte abgezeichnet wurde. Dies hat gut funktioniert, verursacht jedoch einige Probleme mit Geschwindigkeit und Schätzung (siehe Lunivores Antwort) und ich war nie daran interessiert, abhängige Geschichten im Backlog zu haben (Design ist wertlos ohne den Entwickler, Entwicklung kann nicht ohne den Entwurf durchgeführt werden).

Wir machen jetzt:

Design ist Teil unserer Definition von Ready

Wir haben eine „Bereit für den Sprint“-Spalte auf unserem Board – Geschichten können nur dann aus dem Rückstand in den Status „Bereit“ übergehen, wenn sie eine angemessene Größe haben, Akzeptanzkriterien haben und abgeschlossene, freigegebene Designs haben. Dies gibt uns immer noch Einblick in bevorstehende Geschichten, für die wir Designs benötigen, ohne „Design für die xyz-Seite“ separat im Backlog zu haben, und die Designarbeit wird außerhalb des Sprints durchgeführt, sodass sie die Schätzung oder Planung nicht beeinflusst.

Das heißt, wir haben immer noch einige Geschichten, die durchkommen, wo wir am Ende die Entwicklung von Wireframes durchführen, um die Dinge an die richtige Stelle zu bringen, und am Ende das CSS ein oder zwei Wochen später machen, wenn wir die eigentlichen Designs haben.

Es gibt drei Gründe für die Schätzung:

• Um herauszufinden, wie viel das Team in jedem Sprint aufnehmen kann
• Um herauszufinden, wie lange es dauern wird, bis eine Veröffentlichung abgeschlossen ist, wenn das Team zur Verfügung steht
• Damit das Team ein gemeinsames Verständnis über den Umfang der Arbeit erzielen kann.

Es geht nicht wirklich um die Größe der Arbeit, sondern eher darum, wie viel Sie in Ihre Entwicklungspipeline einbauen können.

Aus diesem Grund neige ich dazu, Teams zu ermutigen, sich um den Entwicklungsaufwand zu kümmern, anstatt auch Analyse, UI-Design, Tests usw. einzubeziehen. Die Entwicklung bildet normalerweise den am stärksten eingeschränkten Teil der Pipeline. Es gibt eine Menge, was Entwickler tun können, um Analysten und Testern zu helfen, wenn sie überarbeitet werden, aber wenn ein Teammitglied nicht programmieren kann, können sie den Entwicklern nicht viel helfen – also konzentriere ich mich nur auf Entwicklungspunkte. Allein die Konzentration auf Entwicklungspunkte reicht aus, um all diese drei Dinge zu erreichen.

Im Hinblick auf die Zusammenarbeit anstelle von Abhängigkeiten habe ich die Analysten und Designer normalerweise ermutigt, den Entwicklern einen Sprint voraus zu sein und sicherzustellen, dass genug getan wird, damit die Entwickler eine Vorstellung vom Umfang ihrer Arbeit haben im Planungsgespräch übernehmen und so selbstbewusst wie möglich einschätzen.

Ich fand es hilfreich, Designer dazu zu bringen, darüber nachzudenken, was später leicht geändert werden könnte – Text, Farben, Platzierung usw. – und sich darauf zu konzentrieren, ein Drahtmodell zu skizzieren, das Entwickler verwenden können, um die richtigen Steuerelemente auf eine Seite oder einen Bildschirm zu bringen . Sie können dann im späteren Teil des Sprints zusammenarbeiten, um die feinen Details zu korrigieren. Ich habe festgestellt, dass dies auch ein nützlicher Ansatz für Analysen und Details wie Validierung, Fehlermeldungen oder für die Architektur und den tatsächlichen Inhalt von HTML-/XML-Nachrichten, RESTful-Schlüsselwörtern usw. Dass die Dinge später leicht geändert werden können, macht die Pre-Sprint-Analyse sehr gut viel leichter und kann Teams dabei helfen, effektiver zusammenzuarbeiten, unabhängig von ihrer Rolle.

Damit hat auch mein Team zu kämpfen.

Und das veranlasste mich, meinem Team eine andere Frage zu stellen.

"Wenn Sie nicht wissen, was das Design ist, wie können Sie die Geschichte herausarbeiten und in die Iteration aufnehmen"?

Wie Sie sich vorstellen können, wurde diese Frage mit leeren Blicken und fassungslosem Schweigen beantwortet. Wir tun es einfach, war die endgültige Antwort.

Letztendlich denke ich, dass der beste Weg, diese Frage zu lösen, darin besteht, klare und definierte Codierungs- und Designstandards zu haben, an die sich das Team mit fast religiöser Leidenschaft hält. Während die Story im Backlog durch wöchentliche Grooming-Meetings überprüft wird, wird sie aktualisiert und ein grobes Design wird basierend auf den vom Team akzeptierten Standards vereinbart.

Wenn Sie diesem Prozess folgen, werden Ihre Sprint-/Iterationsplanungsmeetings viel reibungsloser ablaufen. Dies sollte auch Ihre Geschwindigkeit erhöhen und die Anzahl der Geschichten verringern, die sich nicht durchsetzen konnten, weil sie aufgrund gefundener Arbeit nicht abgeschlossen werden konnten.

Wenn Sie über Grafik und Benutzeroberfläche sprechen, fand ich es immer hilfreich, diese Bemühungen in zwei oder mehr Geschichten aufzuteilen. Die erste Geschichte liefert die Funktionalität ohne Schnickschnack, dies gibt dem Designteam etwas zum Iterieren und Kommen mit einem endgültigen Design in einer folgenden Iteration.

Idealerweise werden alle Designelemente in Ressourcendateien extrahiert, damit sie aktualisiert werden können, ohne die Seite erneut bereitstellen zu müssen.

Jeff

Wenn ich mit Software arbeite, glaube ich, dass Design immer richtig gemacht wird. Ich betrachte Geschichten als geschäfts-/benutzerorientiert, nicht als entwicklungsorientiert. Eine Geschichte wie „Status aus der Datenbank abrufen“. ist entwicklungsorientiert und wird zu vielen Problemen führen. Eine Geschichte wie "Zeige den Status der Bestellung an." ist mehr geschäfts-/benutzerorientiert. Wenn Sie sich dafür entscheiden, diese Geschichte in Aufgaben aufzuteilen (was ich eigentlich nicht empfehle), dann würde ich sie so aufteilen, dass jede Aufgabe alle Ebenen Ihrer Architektur enthält.

Wenn sich Ihr Team daran gewöhnt hat, wird es früh Designüberlegungen finden, und wenn Ihr Team über eine gute Kommunikation verfügt (ein wichtiger Schlüssel in meinem Buch), werden Designentscheidungen zum richtigen Zeitpunkt besprochen, da die Diskussion dynamisch und ungeplant stattfindet.

Ich hoffe das hilft.

Wenn Sie versuchen, die allgemeine Benutzeroberfläche und Architektur zu Beginn des Projekts zu schätzen, überlegen Sie, ob Sie sie auf früheren Projekten basieren oder nicht.

Wenn nicht, würde ich separate User Stories verwenden und ihnen eine hohe Priorität und möglicherweise ein Risiko zuweisen. Ich würde mich fragen, warum frühere UI- oder Architekturdesigns nicht mehr geeignet sind? Dies wird Ihnen helfen, Geschichten zu schreiben, die für den Kunden sinnvoll sind.

Wenn Sie entscheiden, dass die Benutzeroberfläche oder Architektur früheren Projekten ähneln soll, ist eine separate Geschichte wahrscheinlich nicht erforderlich.

Ich denke, dass eine gute Definition von DONE in diesem Fall nützlich ist. Mein Team wird wissen, dass, wenn es eine User Story als FERTIG markiert, sie weiter analysiert, entworfen, implementiert, umgestaltet, getestet, von Experten begutachtet und in den Build integriert werden sollte – die Story ist möglicherweise lieferbar. Hinweisdesign ist drin. Ihre Schätzungen spiegeln dies wider.

Es ist auch hilfreich, wenn Ihr Team Software entwickelt, die eine entkoppelte Präsentationsschicht hat (was bedeutet, dass die Benutzeroberfläche getrennt von der Logik codiert ist). Diese Technik reduziert die Abhängigkeit zwischen den meisten Geschichten. Fragen Sie vielleicht Ihr Team, ob dies der Fall ist.

Leider gibt es, wie bei den meisten Dingen in Scrum, keinen richtigen oder falschen Weg. Sie müssen viele Faktoren berücksichtigen und entscheiden, was für Sie funktioniert.

Wir haben ein "Vorprojekt", bevor das eigentliche Projekt beginnt. In diesem Projekt werden die US's finalisiert, Smart Use Cases erstellt und die Wireframes erstellt.

Auf diese Weise haben wir einen Ausgangspunkt, wenn wir mit dem "echten" Projekt beginnen. Der Designer kann daran arbeiten, wfs in Designs umzuwandeln, das Frontend kann seine Frontend-Sache erledigen und die .Net- und SQL-Entwickler können ihre Arbeit erledigen. Das ganze Team zusammen in einem SCRUM Team.

Natürlich gibt es im "echten" Projekt noch Raum für Änderungen und Verbesserungen