Ich arbeite bei einem Startup, wo ich der einzige Designer (UI/UX/Visual) bin, aber wir haben keinen echten Front-End-Entwickler, also fällt der größte Teil der HTML/CSS-Entwicklung auch auf mich, so wie ich bin auch halbwegs anständig. Wir haben eine Web-App, die ich und die Entwicklung betreuen, aber wir haben auch eine Marketing-Website, die ich im Grunde allein betreue, und ich übernehme auch andere Designarbeiten für das Marketing.
Wir haben einen Product Owner, der uns bei der Priorisierung unseres Backlogs hilft, aber wir haben derzeit leider keinen Scrum Master, also versuchen wir, eine eher „Programmmanager“-Route zu verfolgen, bis wir einen einstellen können.
Wir praktizieren derzeit Scrum für unser Entwicklungsteam, aber wir stoßen auf Probleme bei dem Versuch, herauszufinden, wie wir Velocity projizieren können, da ich technisch gesehen von drei verschiedenen Teams getrennt bin – Entwicklung, Design und Marketing.
Wie verbucht man jemanden, der Teil mehrerer Teams ist? Mir ist klar, dass Scrum nach dem Buch sagt, dass dies wirklich nicht passieren sollte, aber wenn ein Unternehmen nicht über genügend Ressourcen verfügt, wird eine Person in mehreren Teams geteilt.
Ich habe Antworten gesehen, die besagen, dass Sie grundsätzlich Personen mit bestimmten Fähigkeiten (z. B. Design- oder Systemarchitekten) zusammenstellen und sie zu einem völlig anderen Team machen sollten, das seinen eigenen Sprint hat, in dem viele seiner Aufgaben die Arbeit für andere abdecken Mannschaften. Da ich nur eine Person bin, scheint das ein bisschen übertrieben zu sein, aber mir fallen keine anderen möglichen Lösungen ein.
Das größte Problem, das ich habe, ist der Versuch, meinen Designprozess wirklich agil zu gestalten, da die Bewertung eines Designs äußerst problematisch werden kann. Manchmal wird ein Design beim ersten Mal genehmigt, aber manchmal dauert es 5 Iterationen. Der einzige Gedanke, den ich hatte, war vielleicht, jedes Mal, wenn ich eine Iteration machen muss, neu zu punkten und es an die Spitze meines Sprints zu bringen, da das technisch immer noch meine Priorität ist? Wie auch immer, es macht die Prognose des Designs wirklich schwierig, und wenn ich keine halbwegs genauen Story Points für das Design haben kann, wird es unmöglich zu sagen, wie viele Punkte für Front-End-Entwicklungs-Storys für das Entwicklungsteamprojekt zugewiesen werden können, wenn a Die Designgeschichte dauert aufgrund mehrerer Iterationen ewig.
Ich habe schon früher Lösungen gehört, die besagten, diesem Team "X Prozent" zu widmen und dem anderen den Rest, aber das Hauptproblem dabei ist, dass sich meine Zeit drastisch von einer designlastigen Woche zu einer codelastigen Woche verlagert. Die Idee, jedem Team eine bestimmte Zeit zuzuweisen, funktioniert also praktisch nicht.
Ich würde sagen, die Arbeit, die ich mache, sollte das Entwicklungsteam nicht wirklich betreffen, aber es wirkt sich derzeit auf ihre Arbeitsbelastung aus, da sie diejenigen sind, die Code-Reviews durchführen und jedes Ticket testen, da ich nur ein Ein-Mann-Team bin und das nicht kann überprüfe meine eigene Arbeit. Ich bin so ratlos, was ich hier tun soll, da ich gerade vom Design zum Codieren gesprungen bin, hauptsächlich basierend auf dem, was ich im Moment für wichtiger halte, was nicht gerade ideal ist.
Verwandte Frage: Ist es möglich, dass jemand Mitglied in zwei Scrum-Teams ist, und wie kann das am effektivsten funktionieren?
In Ihrer ziemlich langen Frage sticht diese Mischung von Themen als Kern dessen heraus, wonach Sie wirklich fragen:
Manchmal wird ein Design beim ersten Mal genehmigt, aber manchmal dauert es 5 Iterationen. Der einzige Gedanke, den ich hatte, war, vielleicht jedes Mal, wenn ich eine Iteration machen muss, neu zu punkten und es an die Spitze meines Sprints zu bringen, da das technisch immer noch meine Priorität ist? Wie auch immer, es macht die Prognose des Designs wirklich schwierig, und wenn ich keine halbwegs genauen Story Points für das Design haben kann, wird es unmöglich zu sagen, wie viele Punkte für Front-End-Entwicklungs-Storys für das Entwicklungsteamprojekt zugewiesen werden können, wenn a Die Designgeschichte dauert aufgrund mehrerer Iterationen ewig.
Wenn ich das analysiere, springen mir ein paar Dinge ins Auge:
Das Problem ist nur am Rande, dass Sie über mehrere Teams verteilt sind; Das eigentliche Problem besteht darin, dass der iterative Prozess oder der Inspektions- und Anpassungszyklus Ihrer Organisation nicht streng ist.
Eine Geschichte sollte innerhalb einer einzigen Iteration abgeschlossen werden können. Jede Geschichte, die nicht innerhalb einer Iteration abgeschlossen werden kann, ist im Allgemeinen entweder:
Diese Stories sollten als unvollständig markiert, mit keinen Punkten für Velocity oder Burn-down versehen und zur Diskussion während der Sprint-Retrospektive, zur Neupriorisierung durch den Product Owner und zur weiteren Zerlegung oder Analyse während eines zukünftigen Sprint-Planungsmeetings wieder in das Product Backlog gestellt werden wenn die Geschichte wieder auf der Agenda steht.
Jede Geschichte, die nicht vollständig ist, ist „nicht fertig“. Es geht zurück in das Product Backlog, wo der Product Owner es möglicherweise für das Sprint-Ziel Ihres nächsten Sprints relevant findet oder nicht.
Auch wenn es weiterhin oberste Priorität hat, sollte die Arbeit wahrscheinlich nicht so weitergeführt werden. Wenn es nicht innerhalb des Sprints abgeschlossen wurde, sollte es sorgfältig überprüft werden, um Folgendes festzustellen:
Es gibt sicherlich andere Dinge, die man im Rahmen des Inspektions- und Anpassungszyklus über unvollständige Arbeit überprüfen kann, aber die obige kurze Liste hat im Allgemeinen die große Mehrheit der Fälle aus der Praxis angesprochen, die mir begegnet sind. Fühlen Sie sich frei, Ihren eigenen Selbstbeobachtungsstil anzupassen oder zu erfinden; Stellen Sie einfach sicher, dass Sie und Ihre Organisation sich die Zeit nehmen, die Grundursache unvollständiger Arbeit und die Kosten für das Projekt zu analysieren, die dadurch entstehen, dass entdeckte Probleme nicht angegangen werden.
Geschwindigkeit sollte die Kapazität eines Teams widerspiegeln . Wenn Sie in mehreren Teams arbeiten, wirkt sich dies sicherlich auf die Kapazität aller drei Teams aus und sollte sich als sichtbare Kosten für die Projekte widerspiegeln, an denen Sie beteiligt sind. Diese Kosten werden am häufigsten sichtbar durch eine Verringerung der realen Geschwindigkeit im Laufe der Zeit, eine Änderung der Neigung des Burn-Downs des Projekts oder durch die Anzahl unvollständiger Geschichten, die am Ende jeder Iteration übrig bleiben. Eine solche Sichtbarkeit ist eine sehr gute Sache™.
Im Allgemeinen ist es am besten, die Geschwindigkeit als nachlaufenden Durchschnitt über eine Reihe von Sprints zu berechnen. Ich persönlich verwende gerne das statistische Mittel der Iterationen der letzten drei Monate, aber Sie können jede gleitende Zeitbox verwenden, die für Sie sinnvoll ist. Wenn Ihre Geschwindigkeit um mehr als zwei Standardabweichungen vom Mittelwert abweicht, müssen Sie wahrscheinlich Ihren Planungs- und Schätzungsprozess überdenken und eventuell vorhandene versteckte Hindernisse aufdecken.
Der Nutzwert der Tracking-Geschwindigkeit besteht darin, dass sie Ihnen ein Maß an Vertrauen in zukünftige Schätzungen gibt. Wenn Sie wissen, dass Ihre Geschwindigkeit zwischen 5 und 20 Punkten pro Iteration variiert, dann ist die Erwartung, dass 20 Punkte an Stories bei jeder Iteration abgeschlossen werden, einfach keine realistische Erwartung Ihres aktuellen Prozesses, aber Sie könnten sich wahrscheinlich sicher fühlen, 5 Punkte in jedem einzelnen Sprint zu liefern .
Wenn Sie oder Ihr Unternehmen anfangen, Geschwindigkeit als Ziel zu verwenden, anstatt eine detektivische Kontrolle zu verwenden, um festzustellen, ob Ihr Prozess aus dem Ruder gelaufen ist, oder ein Planungstool, um zu bestimmen, wie viele Iterationen der aktuelle Rückstand zum Abschluss benötigt, dann verwenden Sie das Falsche Werkzeug für den falschen Job. Geschwindigkeit ist einfach eine statistische Angabe; es ist kein Werkzeug zur Entwicklung von Zeitplänen oder Lieferterminen mit festem Umfang.
Verwenden Sie Ihre tatsächliche Geschwindigkeit, um zu bestimmen, wie viele Iterationen Sie wahrscheinlich benötigen, um eine bestimmte Reihe von Geschichten zu vervollständigen. Ihr Product Owner kann dann den Umfang des Projekts anpassen, um die Anzahl der geschätzten Iterationen zu ändern, die erforderlich sind, um die Managementziele zu erreichen, aber er kann keine Geschwindigkeit (falsch ausgesprochen „Produktivität“) herstellen, indem er die Zahlen spielt.
Keine unsichtbare Arbeit, niemals!
— Transparenzgesetz von CodeGnome
Wenn Sie sagen, dass es manchmal fünf Iterationen braucht, bis ein Designelement genehmigt wird, ist das nicht per se schlecht. Iterative Entwicklung bedeutet oft, dass Dinge verfeinert oder mehrmals überarbeitet werden. Wenn Designs jedoch nicht in einer einzigen Iteration fertiggestellt werden, bedeutet dies oft, dass ein Prozessproblem vorliegt, wie z. B. ein Mangel an funktionsübergreifenden Teamfähigkeiten oder eine schlecht konzipierte Feedback-Schleife im Designprozess.
Ob die mehrfachen Iterationen zur Verfeinerung eines Designs gut oder schlecht sind, ist eine Beurteilungsfrage für die Organisation. In beiden Fällen stellen sie Kosten für das Projekt dar, und diese Kosten sollten immer sichtbar sein. Wenn es einfach die Geschäftskosten in Ihrem Unternehmen sind, mehrere Redesigns durchzuführen, dann sollten dies als akzeptable Kosten betrachtet werden, und es gibt keinen Grund, sie unter den Teppich zu kehren. Wenn dies als suboptimal angesehen wird, muss die Organisation diese Kosten sichtbar halten, um sie ständig daran zu erinnern, dass die relevanten Prozesse überprüft und angepasst werden sollten, bis die Kosten akzeptabel sind.
Sichtbare Kosten sind das Fett, das die wendigen Räder am Laufen hält. Kosten, die höher als erwartet sind, sind ein Aufruf zum Handeln, und ihr Vorhandensein bedeutet, dass Ihr Prozess diese höher als erwarteten Kosten ordnungsgemäß erkennt. Dies ist kein Prozessfehler , sondern eine Prozesschance . Behandle es als solches.
Wenn Sie dies jedoch tun, bitten Sie Ihren Product Owner, die Storys zu priorisieren, und Ihren Scrum Master, alle Anfragen für Ihre Zeit zu erhalten und zu verwalten. Ihr Team (und Sie) sollten sich jeweils auf eine Story mit der höchsten Priorität (wie von Ihrem Product Owner festgelegt) konzentrieren und sie auf den Status „erledigt“ bringen. Nun zu Ihren konkreten Fragen:
Wie rechnet man jemanden ab, der Teil von 2 verschiedenen Teams ist?
Ein Scrum-Team sollte in der Lage sein, ein „potenziell lieferbares Inkrement“ zu liefern. Also, nein, es ist keine gute Idee, ein Team für das Design und ein anderes für die Entwicklung zu haben.
Das macht die Prognose des Designs sehr schwierig, und wenn ich keine Zeitschätzungen für das Design haben kann, wird es unmöglich zu sagen, wie viel Zeit ich für die Front-End-Entwicklung für das Entwicklungsteamprojekt aufwenden kann.
Versuchen Sie nicht, in Stunden zu schätzen, sondern in Story Points. Jede Softwarearbeit hat eine eingebaute Unsicherheit. Sie können diese Unsicherheit nicht beseitigen. Bestenfalls kann Ihr Team versuchen, Ihre Schätzung auf der Grundlage dessen zu verbessern, was Sie aus früheren Schätzungen gelernt haben. Arbeiten Sie zuerst an der Arbeit mit der höchsten Priorität (wie von Ihrem Product Owner festgelegt). Sobald dies erledigt ist, fahren Sie mit der nächsten Geschichte in Priorität fort. Und besprechen Sie den Entwurfsgenehmigungsprozess in der Retrospektive und prüfen Sie, ob es Möglichkeiten gibt, ihn zu verbessern.
Das Hauptproblem dabei ist, dass sich meine Zeit drastisch von einer designlastigen in einer Woche zu einer codelastigen Woche in der nächsten verlagert.
Was stimmt damit nicht? Das Ziel Ihres Teams sollte es sein, die vom Product Owner priorisierten Funktionen bereitzustellen – und nicht, Sie gleichmäßig mit Design- und Programmierarbeit zu füttern.
Ich bin gerade vom Design zum Codieren gesprungen, hauptsächlich basierend auf dem, was ich im Moment für wichtiger halte.
Genau das soll Scrum vermeiden. Der Kontextwechsel tötet die Produktivität und steigert die Frustration. Verweisen Sie jeden, der Ihre Zeit haben möchte, an den Scrum Master.
Ist es möglich, Mitglied in zwei Scrum-Teams zu sein, und wie lässt sich das am effektivsten gestalten?
Ich habe mit einem Datenbankentwickler gearbeitet, der Mitglied in mehr als einem Scrum-Team war. Ressourcenkonflikte und Prioritäten zwischen mehreren Scrum-Teams können in einem Scrum of Scrums-Meeting zwischen den Scrum Mastern und den Product Ownern der beiden Teams gelöst werden. Sie konzentrieren sich auf die priorisierte Arbeit. Sie aktualisieren auch täglich die verbleibenden Stunden, um offene Aufgaben zu erledigen.
GaTechThomas