Reduzieren Sie die Menge der erforderlichen Hotfixes ohne technische Kenntnisse

Ich bin ein Softwareentwickler, der unter den regelmäßigen Hotfixes leidet, die für eine von mir entwickelte Anwendung erforderlich sind.

Die von mir entwickelte Anwendung hatte von Anfang an nicht viele Infrastrukturanforderungen, aber im Laufe der Zeit wurden diese Anforderungen immer größer. Dies ist nur ein Teil des Problems, denn wenn eine solche neue Anforderung kommt, wird erwartet, dass ich einen Hotfix außerhalb anderer geplanter Arbeiten mache. Denn die Projektverantwortlichen versprachen bereits eine funktionierende Anwendung.

Ich möchte die Menge an Hotfixes reduzieren, die ich machen muss, damit ich mich auf die Aufgabe konzentrieren kann, an der ich gerade arbeite, und sich die Projektmanager nicht entschuldigen müssen, wenn das Produkt nicht von Anfang an funktioniert.

Die meisten dieser Infrastrukturanforderungen haben mit Authentifizierung und Autorisierung zu tun (Active Directory, domänenübergreifende Unterstützung, Identitätswechsel usw.).

Ich denke, weder der Product Owner noch die Projektmanager oder ich wissen genug über die technischen Besonderheiten, um von Anfang an einen Anforderungskatalog zu erstellen.

Das Produkt wird mit Scrum als Projektmanagement-Ideologie entwickelt. (Ich bin auch Teil anderer Scrum-Teams.)

Wie kann ein kleines Unternehmen ohne dieses Wissen solche Hotfixes verhindern?

Ich weiß, dass das Versprechen einer funktionierenden Lösung und das Reservieren von Zeit für Tests und Korrekturen dieses Problem lösen würden. Aber gibt es eine andere Möglichkeit, dies zu verhindern? Oder sollte ich versuchen, mit den Projektmanagern zu sprechen und versuchen, ihren Weg zu ändern?

Für mich klingt das weniger nach Hotfixes (= Fehler beheben) als vielmehr danach, Sie zu drängen, versprochene Features hinzuzufügen. Passt das zu Ihren Eindrücken?
@Kempeth Ja! Das klingt nach der Situation. Und vielleicht ist es die Hektik, die eine gute technische Analyse/Integrationstests verhindert... Aber ich weiß auch nicht, ob wir dieses Problem mit genügend Zeit lösen könnten, da unser technisches Wissen vielleicht zu gering ist.

Antworten (2)

Wenn ich Sie richtig verstanden habe, ist Ihr Ziel, eine stetigere Entwicklungserfahrung zu haben. Weniger "alles fallen lassen und X zum Laufen bringen".

Dein Problem ergibt sich aus mehreren Faktoren:

  • Den Kunden wird versprochen, dass Ihr Produkt etwas kann, was es nicht kann
  • Sie (persönlich und das Unternehmen) wissen zu wenig, welche Anforderungen erwartet werden
  • Ihre Vertriebsmitarbeiter oder Manager sind nicht bereit, auf diese Funktionen zu warten
  • Vor diesen Mängeln sind Sie nicht ausreichend geschützt

Was würde helfen?

  • Erwerben Sie das notwendige Domänenwissen. Entweder durch einen Entwickler, Produktmanager, Power User oder ggf. Berater. Wenn Sie jemanden haben, der weiß, welche Erwartungen an Ihr Produkt gestellt werden, können Sie präventiv an diesen Funktionen arbeiten.
  • Verhindern Sie, dass der Verkauf behauptet, Ihr Produkt mache bereits alles. Das ist sehr schwierig, weil das, was sie gerade tun, aus ihrer Perspektive gut funktioniert. Sie müssen sie entweder davon überzeugen, dass es besser ist, dies nicht zu tun, oder sich von jemandem mit genügend politischem Einfluss für Sie einsetzen zu lassen.
  • Bringen Sie Vertriebsmitarbeiter und Ihren PO dazu, eine stärkere Partnerschaft mit Ihren Kunden aufzubauen und ihre Bedürfnisse besser zu verstehen. Wechseln Sie zu einem offeneren Ansatz, bei dem Sie ehrlich sagen, was Ihr Produkt im Moment kann und wie lange es wahrscheinlich dauern wird, eine bestimmte Ergänzung hinzuzufügen.
  • Bringen Sie Ihren PO, SC und sich selbst dazu, gegen diese Eiljobs Fuß zu fassen. Sie sagten, Sie machen Scrum. In Scrum macht man keine Eilaufträge. Dies ist riskant, da die Weigerung, diese Aufgaben nebenbei zu erledigen, Sie Ihren Job kosten könnte, wenn sich Ihr Unternehmen nicht für Scrum einsetzt. Und nach allem, was ich gelesen habe, scheinen sie es nicht zu sein. Möglicherweise können Sie diese "Freiheit" aushandeln, indem Sie kürzere Sprints anbieten (dh weniger warten, bis eine neue Aufgabe aufgenommen wird). Ihre Fähigkeit, kürzere Sprints anzubieten, ist jedoch dadurch begrenzt, wie lange Sie als scheinbar einzelner Entwickler für ein bestimmtes Feature benötigen . Eine Alternative wäre, Scrum aufzugeben und stattdessen Kanban zu verwenden. Sie haben EINE aktive Aufgabe, an der Sie arbeiten, bis sie erledigt ist. Dann tust du, was sie für die nächstwichtigste Aufgabe halten.
  • Kündigen Sie oder wechseln Sie zu einem anderen Produkt. Es scheint, als wären Sie ein einzelner Entwickler, der nur zeitweise an diesem Produkt arbeitet. Dies würde darauf hindeuten, dass nicht viel in das Produkt investiert wird und das Unternehmen es mit der Einstellung behandelt, „mit minimalem Aufwand so viel Geld wie möglich aus diesem Ding herauszuholen“. Wenn ja, ist das keine Position, die Sie langfristig einnehmen möchten

Ich weiß, Sie sagen, Sie folgen Scrum, aber tun Sie das nach Vorschrift ?

  • Erstellen Sie am Ende jedes Sprints ein potenziell veröffentlichbares Produkt?
  • Überprüfen Sie das Produkt mit den Stakeholdern am Ende jedes Sprints während des Sprint-Review-Meetings?
  • Beziehen Sie das Feedback, das Sie im Review erhalten, in das Produkt ein?

Wenn nicht, wäre das meiner Meinung nach ein guter Anfang.

Danke für deine Antwort. Ich würde sagen, wir versuchen unser Bestes, um die Regeln zu befolgen (ich weiß, dieser Satz lässt es schlecht aussehen und ist es wahrscheinlich auch). Am Ende jedes Sprints haben wir ein potenzielles Produkt, das veröffentlicht werden kann. Aber vor der Veröffentlichung programmieren wir das Produkt nicht für einen Sprint, um die Tester ihre Arbeit machen zu lassen. Und dann korrigieren wir Fehler, wenn nötig, und veröffentlichen sie. Wir überprüfen das Produkt am Ende jedes Sprints, aber die technischen Anforderungen werden im Grunde nie besprochen. Und ja, wir bauen Feedback am Ende des Sprints ein und erstellen daraus Backlog Items für den nächsten Sprint.
Reduzieren Sie die Menge der erforderlichen Hotfixes ohne technische Kenntnisse
AntwortenHierDatenschutz-Bestimmungen1y, 0v