Avatar von Michse0815
  • Michse0815

107 Beiträge seit 04.05.2017

Re: Was man aus den Kommentaren herauslesen kann

Eher: ich glaube nicht, dass das in großer Zahl funktionieren wird.

Glauben ist Glückssache. Wir haben ja schon festgestellt, dass du eigentlich nichts über Scrum weißt. Wie kommst du also zu der Aussage, das könne ja nicht funktionieren? Vor allem, da es ja nicht wirklich neu ist und bereits vielerorts eingesetzt wird.

Ich muß dieses Feature aber trotzdem verwalten und in den nächsten Sprint verschieben, oder?

es kommt zurück ins Backlog und wird priorisiert. Ist es wichtig genug, wird es im nächsten Sprint fertiggestellt. Damit ist es weder schneller noch langsamer fertig, als wäre die Aufwandsschätzung größer ausgefallen. Die Schätzung hat keine Auswirkungen auf den Aufwand.

Ok, dann sagt der Entwickler dass es zu Komplikationen bei der Entwicklung gekommen ist. Und jetzt?

Nichts und jetzt. Was soll denn jetzt sein? Die Stakeholder haben frühzeitig von dem Problem erfahren. Der PO weiß es schon lange, genauso wie der Rest des Teams und der ScrumMaster.
Was zum Geier soll jetzt im Review passieren?

Eindeutig ein Modell, das nur bei bestimmten Projekttypen, wo die Entwickler billig und/oder die Firma viel Geld hat, funktionieren kann.

Und da spricht sie wieder. Die totale Ahnungslosigkeit. Bei dieser realitätsferne kann man nur mit dem Kopf schütteln.
Google, Apple, Facebook um nur ein paar Große zu nennen die Scrum in Projekten einsetzen.

Ein Feature wie eine Funktion in der Geschäftslogik, in meinem Fall auf einer Oracle DB in PL/SQL entwickle ich in ein paar hundert Zeilen Code und lasse es dann noch per code review überprüfen, wenn es diese Kapazitäten gibt. Da sitzt kein Zweiter um das gleiche Geld und schaut mir über die Schulter.

Ein Projektleiter der zulässt, dass ein "ach so toller externer Spezialist" auch nur eine Zeile Code eincheckt ohne ein Review und ohne, dass ein interner Mitarbeiter neben ihm sitzt und ihm über die Schulter schaut, sollte sofort gefeuert werden.
Der Externe Entwickler ist irgendwann weg. Die Software bleibt, muss ggf erweitert, ziemlich sicher aber gewartet werden. Und niemand da der das kann weil Wissenstransfer - Fehlanzeige.

Was du mir da beschreibst ist nicht 21. Jahrhundert sondern 60er Jahre Lochkartenverarbeitung, um nicht zu sagen vorsintflutlich. Lowcode ist das Thema, nicht Arbeitsbeschaffungsmaßnahmen für Einsteiger, um auch mal ein Schlagwort in die Runde zu werfen.

PairProgramming ist übrigens ein wichtiger Teil von XP. Es täte dir gut mal ein wenig Zeit in Weiterbildung zu investieren.

Oder dort wo (Teil-)Projekte in Wochen oder gar Tagen abgearbeitet werden - mich wundert bei deiner Beschreibung dass bei solchen Pipifax-Aufgaben mit so einem System überhaupt noch was passiert. Das ist ja tiefstes Mittelalter in der SW-Entwicklung und Projektorganisation, was ich da so von dir lese.

Dass du es nicht verstehst ändert nichts an den Fakten. Siehe o.g Beispiele in denen Scrum eingesetzt wird. Da stinkst du einfach ab.

Dafür gibt es viele Erklärungsmöglichkeiten, z.B. weil ich täglich mit dem Bereich arbeite und er/sie mit anderen Agenden beschäftigt ist?

Und genau deswegen spricht man dann miteinander. Wie oft habe ich schon erlebt, dass der Spezialist für ein bestimmtes Thema z.B den Testaufwand nicht richtig berücksichtigt hat. Schon wird vielleicht aus einer kleinen 3 eine 8.

Damit habe ich dann aber auch eine Verzögerung im Projektplan.

Nochmal. Das Feature hat durch die Schätzung nicht länger gebraucht. Die Zeit bis zur Fertigstellung hat sich nicht geändert. Es wird nur jedem klargemacht, dass es länger dauert als initial geschätzt. Keine Verschleierung von Problemen mehr. Die Stakeholder wissen sofort bescheid und können sich überlegen, ob es ihnen das wert ist oder nicht.

Was wenn es eine Deadline gibt? Wie holt man solche Verzögerungen in deinem Modell auf? Stellt man dann doch nicht 2 Leute für eine Aufgabe ab, um mehr Resourcen zur Verfügung zu haben?

Welche Auswirkungen soll eine Schätzung im Sprint bitte auf eine Deadline haben? Die Arbeit BLEIBT GLEICH. Egal wie du sie schätzt.
Wenns was größeres ist können die Stakeholder entscheiden was ihnen lieber ist.
Im klassischen Projektmanagement wird es den Stakeholdern einfach verschwiegen, das Projekt wird am Ende teurer und dauert länger. Die bekommen es ja erst am Ende mit und können nicht mehr eingreifen. SCHEISSE für den Kunden. Er kann das Projekt am Ende abbrechen oder nehmen was er bekommen hat oder eben doch mehr Zeit und Geld investieren. Mit Scrum wäre das nicht passiert.
Und du behauptest also Pairprogramming sei langsamer und eine 1-Mann-Show wäre schneller. Beweise das. Vielleicht haben Kent Beck & Co ja einfach keine Ahnung wovon sie reden. Mal davon ab ist PairProgramming kein Teil von Scrum. Was nicht heißt, dass man es nicht einsetzen sollte.

Das ist schon richtig, aber wie löst man das Problem dieser Verzögerung jetzt auf? Projektleiter gibt es so nicht, der PO kann zwar priorisieren, aber das war's dann auch schon. Die Entwickler sind ohnehin sich selbst überlassen, was also soll sich jetzt ändern?

Verzögerung ist ERST ein Problem wenn sie den Stakeholdern verheimlicht wird. So können sie nach jedem Sprint sehen, was sie für ihr Geld bekommen und entsprechend entscheiden. Nicht erst am Ende der Entwicklung wenn das Geld verballert und das Produkt trotzdem nicht fertig ist.
Scrum schafft transparenz.

Und damit sehe ich das Hauptproblem - es fehlt jemand der sich auf technischer Basis "kümmert" und den Gesamtüberblick behält, denn die Entwickler sind mit ihren eigenen Agenden beschäftigt.

Und wieder.. Du hast einfach keinen Plan von Scrum und versuchst verzweifelt Probleme herbeizuwünschen wo gar keine sind.
Die Entwickler sind nicht mit eigenen Agenden beschäftigt und die Produktvision ist Aufgabe des PO.
Lies dich erstmal in ein Thema ein, bevor du anfängst zu diskutieren

Bewerten
- +
Anzeige