Wir sind ein kleines Team von 4 Entwicklern, die 2 große Websites + 4-5 kleine Websites verwalten + wir haben einen Kanal für Anpassungen / Entwicklungsservice (einmaliger Service).
Bei allen Websites im Support arbeiten wir nach Stundensätzen. Bei Anpassungen (wir haben sie in ein separates Projekt verschoben) erstellen wir Schätzungen und verkaufen sie zum Festpreis.
Wir haben verschiedene Aufgaben, von kleinen (wie das Verschieben einer Schaltfläche, das Ändern der Farbe) bis hin zu großen (2-8 Tage dauern, wie das Entwickeln einer neuen Erweiterung mit komplexer Logik).
Auf Support haben wir von Zeit zu Zeit sehr unterschiedliche Belastungen. An manchen Tagen haben wir nur wenige Aufgaben, an anderen Tagen können sie 1-2 große Aufgaben und 20-50 kleine und mittelgroße Aufgaben hinzufügen.
Derzeit erstellen wir solche Aufgabentypen:
Wir machen Schätzungen für alle Aufgaben, wo immer dies möglich ist.
Auch wir haben immer wieder Aufgaben, die man lange nicht abschließen kann, auch wenn sie von unserer Seite erledigt werden. Client-Entwickler haben keine Zeit / haben Code auf ihrer Seite nicht fertig gestellt (CRM, vorbereitete Produkte usw.) - wir müssen lange auf solche Aufgaben warten und all diese Aufgaben sind in der Liste offen, um sie nicht zu vergessen; sie können zum Beispiel den Status „Kundentest“ haben, aber noch in der Liste sein.
Im Moment haben wir etwa 200 offene Tickets/Ausgaben.
Sehr oft fragt der Kunde so schnell wie möglich nach etwas und höchstwahrscheinlich würde er dies zur gleichen Zeit wie ein anderer Kunde fragen oder gleichzeitig nach ein paar Aufgaben fragen :)
Kunden fragen uns manchmal, wann eine zukünftige Aufgabe abgeschlossen wäre.
Welche Software können wir verwenden, um damit umzugehen, und wie müssen wir sie konfigurieren, um all dies am besten zu handhaben?
Ich meine, wie können wir in einem solchen Chaos planen und echte Fristen einhalten?
Ich muss auch sagen - derzeit verwenden wir JIRA und ich habe versucht, kurze Sprints wie 1 Woche zu erstellen, dort Arbeit für 1 Woche zu platzieren und in diesem Fall kann ich beispielsweise 2-3 Wochen im Voraus planen. Das funktioniert aber aus folgenden Gründen nicht:
Ich dachte an EasyRedmine mit ihrer Ressourcenplanung, bin mir aber nicht sicher, ob dies helfen kann, all dies zu bewältigen.
Also bitte, irgendwelche Ideen oder Links, wo ich finden kann, wie ich das alles verwalten kann und wie ich diese Prozesse verbessern kann? Wir sind bereit, den gesamten Prozess bei Bedarf zu ändern.
Scrum als Prozess ist eine gute Möglichkeit, ein Projekt zu liefern, für dessen Lieferung mehrere Sprints erforderlich sind. Es ist auch sehr modisch. Es ist jedoch kein so guter Prozess, um Bugfixes und kleine Änderungswünsche mit Vorlaufzeiten von nahezu null bereitzustellen. Die Verwendung eines Kanban-Boards auf JIRA wäre die ideale Lösung, wie Daniel oben erwähnt.
Manchmal weicht unsere Einschätzung stark von der Realität ab - wir arbeiten daran + wir planen einen Sprint für nur 4 Tage (1 Tag ist für solche Fehler und Fehlerbehebung) /
Ohne die Struktur eines Sprints hat das Überschreiten einer Schätzung nicht die gleichen administrativen Konsequenzen.
Einige Aufgaben sind auf unserer Seite fertig, aber nicht getestet oder vom Kunden nicht vorbereitet und am Ende des Sprints müssen wir diese Aufgabe immer wieder in den nächsten Sprint verschieben.
Mehr Sprint-Verwaltung, die Sie mit Kanban nicht benötigen.
JIRA erlaubt es, einen Sprint nur nach Original Estimate zu planen, aber solche Aufgaben wie in Punkt 1 sind schon fast erledigt, aber noch nicht abgeschlossen. Wenn wir sie schließen und später in 3 Wochen, wenn der Kunde es testen würde, werden wir weitere Aufgaben erstellen - dann würde die Gesamtzeit nach Aufgabe getrennt und wir können nicht sehen, wie lange es gedauert hat. Wenn wir die Aufgabe schließen – sie ist noch nicht zum Meistern zusammengeführt – können wir sie überhaupt verlieren und müssen Zeit verschwenden, um die Aufgabe zu finden und dafür zu verzweigen (wir verwenden Zweignamen nach Aufgabe).
Auch hier besteht auf dem Kanban-Board keine Notwendigkeit, eine Aufgabe künstlich zu schließen. Lassen Sie es offen, bis es wirklich fertig ist, und protokollieren Sie die dafür aufgewendete Zeit in einem Ticket. Bugfixes als Ergebnis des Testens sollten in den Lebenszyklus des ursprünglichen Tickets aufgenommen werden. Weitere Änderungswünsche sollten separate Tickets sein.
Einige Aufgaben können nicht einmal geschätzt werden, wie ich zuvor geschrieben habe
Auf dem Kanban-Board spielt es keine Rolle.
Was ist, wenn eine Aufgabe bereits in Produktion ist, wir aber nach 1-2 Wochen einen Fehler darin gefunden haben? Wiedereröffnen hätte die ursprüngliche Schätzung, Unteraufgaben können nicht in den Sprint aufgenommen werden.
Fehler, die in „erledigten“ Tickets identifiziert wurden, sollten als neue Tickets eingerichtet werden. Wenn dies häufig vorkommt, sollten Sie einen Blick auf die Robustheit Ihrer Testprozesse werfen. Im Allgemeinen vermeide ich aufgrund der Einschränkungen die Verwendung von Unteraufgaben in JIRA. Nichts hindert Sie daran, das neue Bug-Ticket mit dem ursprünglichen Feature-Ticket zu verknüpfen, um die Nachvollziehbarkeit Ihrer Arbeit zu gewährleisten.
Noch ein paar Punkte von mir:
Sie erwähnen in Ihren Kommentaren an Daniel, dass Sie mit Kanban nicht nachverfolgen können, „wie weit“ die Entwickler mit einer Aufgabe fertig sind. Sie können nicht zuverlässig messen, wie weit jemand mit einer Aufgabe fertig ist - keine Aufgabe wird genau in der geschätzten Zeit erledigt. Nachzuverfolgen, wie viel Zeit fiktiv für eine Aufgabe "verbleibt", hat keinen Einfluss auf die Fähigkeit des Entwicklers, sie zu liefern. Kommunikation ist der Schlüssel.
WIP-Limits sind optional. Nur weil Sie sich innerhalb eines WIP-Limits befinden, heißt das nicht, dass Sie keine Probleme haben. Habe ich schon erwähnt, dass Kommunikation der Schlüssel ist?
Die Zahlen, die Sie nennen, klingen, als hätten Sie zu viel Arbeit. Versuchen Sie, dies anzugehen, indem Sie entweder Ihre Entwicklerressourcen erhöhen oder die Erwartungen Ihrer Kunden verringern. Eine Software-/Prozessänderung wird Ihre Kapazität nicht über Nacht verdoppeln.
Wer priorisiert Ihre Arbeit? Sie erwähnen nicht, ob dies geschieht oder nicht. Die Priorisierung ist effizienter als die Abholung von Aufgaben basierend darauf, wie lange sie angefordert wurden.
Ich bin mir nicht sicher, ob eine Softwareoption Ihr Problem lösen wird.
Ich würde Kanban auf jeden Fall als eine Möglichkeit betrachten, den Arbeitsfluss in Ihren Teams zu verbessern. Sie können es neben Scrum oder eigenständig nutzen, wenn Sie möchten. Es ist wichtig, alle Kanban-Praktiken zu nutzen, nicht nur das Board. Stellen Sie sicher, dass Sie die laufenden Arbeiten begrenzen, den Fluss messen und kleine schrittweise Verbesserungen vornehmen. Dies wird Ihnen wirklich helfen, Ihre Fähigkeit zu verbessern, all diese Arbeit zu bewältigen.
Achten Sie auch auf die Überlastung des Teams. Viele Teams, die überfordert sind, arbeiten deswegen tatsächlich langsamer. Henrik Kneiberg erklärt das Problem gut in diesem Video:
https://www.youtube.com/watch?v=CostXs2p6r0
Auch hier kommen diese strengen WIP-Limits ins Spiel.
Was die Software betrifft, so funktionieren die Kanban-Boards von JIRA gut, aber wenn es nur ein paar von Ihnen sind, machen Haftnotizen und ein Whiteboard auch wirklich gute Arbeit.
Um die Erwartungen an Funktionen festzulegen, verwendet Kanban meistens die durchschnittliche Lead- und Zyklusbindung, um dies zu berechnen. Für größere Projekte können Sie auch Abbranddiagramme verwenden, aber das kann bei vielen konkurrierenden Prioritäten schwierig sein.
Thiago Cardoso
Alan Larimer