Ich suche Rat bei der Implementierung oder Definition eines Entwicklungsprozesses für mein Team. Es fällt mir schwer, etwas zu finden, das zu passen scheint, aber es kann nur an einem Missverständnis der Prozesse liegen.
Ich leite ein kleines Team von einem halben Dutzend Softwareentwicklern, die auf zwei Hauptsysteme/Projekte aufgeteilt sind, an denen wir arbeiten, 3 Entwickler auf jedem System, obwohl das Team gewachsen ist und ich erwarte, dass diese Zahlen noch größer werden. Das ist einer der Gründe, warum ich hoffe, die Dinge jetzt strukturierter zu bekommen.
Bis zu diesem Zeitpunkt gab es keinen wirklich definierten Entwicklungsprozess, aber seit ich angefangen habe, das Team zu leiten, versuche ich, die Dinge so gut wie möglich zu organisieren/strukturieren, während ich die Entwicklung am Laufen halte.
Die meiste Arbeit, die wir leisten, erfolgt über eine Reihe von Anfragen im Stil eines Ticketsystems, bei denen wir Benutzerberichte über Fehler oder Anfragen nach kleinen Funktionen/Änderungen erhalten, und wir bearbeiten die Anfragen in der Reihenfolge ihrer Einreichung und Priorität. Wir arbeiten regelmäßig an größeren Funktionen, die einige Wochen der Entwicklung erfordern können, aber für die meisten Dinge dauert die Entwicklung nur wenige Stunden an Änderungen.
Diese Systeme haben keine automatisierten Tests, worauf wir auch hinarbeiten, also durchlaufen die Tickets nach Abschluss der Entwicklung einen Peer-Review-Prozess und dann führe ich eine abschließende Überprüfung/einen manuellen Test durch, bevor die Änderungen vorgenommen werden in Updates zusammengeführt und für Live-Systeme freigegeben (was normalerweise immer dann passiert, wenn genügend ausstehende Änderungen vorhanden sind, um die Veröffentlichung eines Updates zu rechtfertigen).
Ich habe verschiedene Entwicklungsmethoden überprüft, bin mir aber nicht sicher, was gut zu unseren Anforderungen passen würde. Es scheint, als ob die meisten Methoden darauf ausgelegt sind, größere Projekte durchzuführen, die sich über mehrere Wochen erstrecken und viel Hin und Her mit den Endbenutzern haben, aber das ist sehr selten etwas, was wir tun. Das ist jedoch nur mein Verständnis von dem, was ich gelesen habe, also verstehe ich vielleicht nur etwas falsch.
Alle Gedanken oder Ratschläge zum weiteren Vorgehen wären sehr willkommen, und lassen Sie es mich bitte wissen, wenn ich noch etwas klären sollte.
Willkommen bei pm.stackexchange!
Wie @nvogel vorgeschlagen hat, kann die Kanban-Methode für Ihre Art von Arbeit geeignet sein. Auch hier sollten Sie, wie er vorgeschlagen hat, das Entwicklerteam „selbstorganisieren lassen und ihm erlauben, eine Arbeitsweise zu wählen, die zu ihm passt“.
Ich würde jedoch vorschlagen, dass Sie ein Pilotprojekt der Kanban-Methode durchführen, das dem Entwicklerteam ein praktisches Gefühl dafür gibt, wie der Prozess funktioniert und ob er zu ihnen passt.
Es hört sich so an, als könnten Sie davon profitieren, so etwas wie die Kanban-Methode zu übernehmen . Ich persönlich möchte das Team dazu ermutigen, sich selbst zu organisieren und es ihm ermöglichen, eine für ihn passende Arbeitsweise zu wählen. Entwicklungsteams sind in der Regel am produktivsten, wenn sie kollektive Eigenverantwortung und Verantwortlichkeit sowie die Freiheit zur Innovation haben, aber viel hängt vom Charakter und der Erfahrung der betroffenen Personen ab. Siehe: selbstorganisiertes Team .
Ich würde vorschlagen, keine "Methodik" so zu verwenden, wie sie ist. Versuchen Sie einfach, Schwachstellen zu finden und einige Methoden/Artefakte in Ihren aktuellen Prozess zu implementieren und ihn zu verbessern. Sie können mit Entwicklern sprechen und dafür Metriken verwenden. Wenn sich Ihr Team beispielsweise unwohl fühlt, weil es Kommunikations- oder Transparenzprobleme gibt, versuchen Sie, tägliche/wöchentliche Besprechungen hinzuzufügen und zu erleichtern, und lassen Sie Ihr Team so arbeiten, wie es früher war, aber mit kleinen Verbesserungen.
Sie können eine Liste von Scrum-Artefakten oder beliebige Methoden verwenden. Sie können das Problem, das Sie gefunden haben, für das gesamte Team hervorheben und versuchen, es gemeinsam zu lösen, um eine Lösung zu finden, die zu Ihrem Team passt. Was selbstorganisierte Teams betrifft, stimme ich @nvogel vollkommen zu.
Ich meine, Sie brauchen immer grundlegende Prozesse, aber Ihr Team arbeitet jetzt schon, es besteht keine Notwendigkeit, arbeitende Dinge zu bremsen, selbst für den guten Zweck.
Ich würde auch daran arbeiten, dem Team die Idee vorzustellen, dass „jeder an allem arbeiten kann“. Haben Sie zum Beispiel nicht drei Entwickler, die jedem System gewidmet sind : Alle Entwickler sollten mit allem vertraut sein. Sie sollten regelmäßig von einem zum anderen wechseln, und sowohl der Prozess als auch das gesammelte Wissen über jedes System sollten streng dokumentiert und diskutiert werden.
Ich warne auch vor einem „ticketgesteuerten“ Workflow. Tickets sollten ein Input für einen periodischen Prozess sein, der bestimmt, was die Teams als nächstes tun werden. (z. B. "ein Sprint"), aber sie sollten diesen Prozess nicht vollständig, dh "reaktionär", vorantreiben .
Sie müssen auf jeden Fall einen Test- und „Preflight“-Prozess aufbauen, unabhängig davon, ob dieser automatisiert ist oder nicht. Sogenannte „testgetriebene Entwicklung“. Jede "anscheinend harmlose, harmlose Änderung" kann zu einer Regression führen ... vertrauen Sie mir darauf. (Auch wenn ich von meinem eigenen Code spreche!)
Josch