FIAE | Zeitschätzung für nächstes Release

[Gast dnyc]

Wollte mal fragen, wie das so bei euch ist. Bei uns ist es so, dass wir uns Punkte rausnehmen an Bugfixes, neue Funktionen, Verbesserungen, etc und diese dann zeitschätzen sollen. Anhand der geschätzten Zeit wird dann die zu benötigen Tage und Stunden berechnet und dort dann mit einem kleinen Puffer das Release der neuen Version angesetzt.

Mit den Zeitschätzungen tue ich und mein Kollege uns recht schwer. Unser Chef will, dass wir möglichst genau schätzen, wie lange wir für eine Aufgabe brauchen werden, allerdings kann ich das auch oft nicht sagen, da ich nicht weiß, was für ein möglicher Rattenschwanz das mit sich zieht.

Verstehe auch nicht, was das soll mit der Schätzung. Bei einem Kumpel von mir ist es so, dass sie einen Termin für das nächste Release festlegen und dann so viele Aufgaben wie möglich machen. Alles was nicht geschafft wurde wandert dann in's nächste Release.

Dies finde ich auch besser weil praktikabler. Man muss keine Zeitschätzung machen, die eh danebenliegt und hat keinen Druck alle vorgenommenen Aufgaben auch ja zu erledigen, zumal ja während des Prozesses auch neue, wichtige Bugfixes dazu kommen können, wobei aber da der Release nicht verschoben wird, sondern das in der geschätzen Zeit geschafft werden muss.

Ich bin sowieso nícht gut im Schätzen, das liegt mir einfach nicht, finde es aber auch sinnlos, da würde ich es lieber gerne wie bei meinem Kumpel machen.

Wir sind übrigens ein 7 Mann/Frau Unternehmen und mit Chef insgesamt drei Programmierer. Die App, die wir entwickeln wird von unseren anderen 4 Mitarbeiter genutzt.

Was sind eure Gedanken dazu und wie ist es bei euch?

[Velicity]

Läuft bei uns auch nicht so rund. Ist teilweise auch schwer. Entwickelung ist nun einmal ein relativ kreativer Prozess. Wenn dann der Spec auch nicht wirklich detailliert steht oder bei einem Bug alle Fakten bekannt sind und man den Fall problemlos nachstellen kann, dann geht da eben auch eine nicht wirklich schätzbare Zeit drauf. Gleiche bei Sachen mit mehreren Gewerken, wo einen der Gegenüber ausbremsen kann usw. Teilweise ändern sich auch die Anforderung während der Implementierung usw.

Ansonsten sind bei uns viele Schätzungen gefühlt eher, was der Kunde bereit ist zu zahlen, als wie aufwendig es ist. Und das dann meist auch eher für eine schlechte Lösung. Ganz einfach weil es schon immer so war. Wenn man nun für etwas vergleichbar aufwendiges das Doppelte an Zeit haben möchte, dann ist das eben nicht. Das kann man weder Cheffe, noch dem Kunden verkaufen.

Darüber hinaus ist es abhängig davon um was es geht. Wir haben unsere eigenen Erweiterungen am "Core", die werden einfach intern geschätzt und wenn sie so gut wie fertig sind, dann wird der Release geplant.

Soweit bei Entwicklungen für einen selbst. Dann haben wir noch Kunden, die entsprechende Erweiterungen haben wollen. Da wird dann grob geschätzt, wobei das oft nicht vom Entwickler selbst gemacht wird und oft wenig mit der Realität zutun hat. Darauf hin wird ein Release geplant, was dann eben die Deadline ist.

Im Extremfall bedeutet das, dass man mal in der Theorie zwei Tage Zeit hat, für eine Änderung von einer halben Stunde oder anders herum. Dem Kunden wird eh nur das Geschätzte berechnet, gleicht sich also sowohl von der Arbeit, als auch finanziell aus.

Auch ist der Endzeitpunkt schwer abzuschätzen. Es kommen eben noch Supportfälle des Tagesgeschäfts rein, Kollegen brauchen mal Unterstützung usw. Da gibt es eben auch Tage, wo man mit den eigenen Sachen überhaupt nicht voran kommt und die Deadline näher rückt.

Ich denke wir machen es uns im IT-Bereich aber auch schwer. Wenn man es mal vergleicht mit "einfacheren" Bereichen, wie z.B. der Autoreparatur. Da wird ein kostenpflichtiger Kostenvoranschlag gemacht, es wird erstmal genau geprüft, davon ab, dass die Arbeiten sich relativ leicht abschätzen lassen vom Umfang und eben weniger kreativ sind. Dazu gibt es dann noch Wartungen, Inspektionen, teilweise werden Teile ausgetauscht bevor es knallt usw. sowas bräuchte man eigentlich auch bei wachsender Software, im Sinne vom Refactoring usw.

Eine genaue Schätzung ist am Ende eben immer sehr wage, gar eine Lüge. Selten ist es ja eine stumpfe Umsetzung, ein paar Buchstaben in die Tasten hauen ist in wenigen Stunden getan. Der Großteil der Zeit geht doch eben dafür drauf herauszufinden, was getan werden muss.

Bearbeitet 17. Mai 2020 von Velicity

[Gast dnyc]

Die Frage ist halt auch, ob du Anschiss bekommst, wenn deine Zeitschätzung daneben lag. Wie sieht es da bei dir aus? Kann ja auch sein, dass dein Chef das nicht sonderlich juckt. Mein Chef dagegen schimpft immer wegen den Schätzungen.

[Velicity]

Kommt drauf an worum es geht. Bei Entwicklungen im Haus ändert sich während der Implementation häufiger mal was und das alles ist nicht so dringend. Da gibt es hier und da ein neckischen Kommentar.

Das hab ich z.B. aktuell wo ich bei etwas gesagt habe, dass ich für die Umsetzung solo gut zwei Wochen brauchen werde. Da wurden dann spontan noch mal zwei andere Leute mit dran gesetzt, wovon einer dann auch wieder abgezogen wurde. Ich bin eigentlich zu nix mehr gekommen als Abstimmung und Verwaltung des Ganzen. Und der Chef hat dann seine Kommentare gebracht, dass es nach einer Woche nicht erledigt war mit 2-3 Leuten, wenn ich es alleine in zwei hätte schaffen wollen. So nach Motto 9 Frauen können ein Kind in einem Monat zur Welt bringen.

Schimpfen tut mein Chef eigentlich nie mit mir. Dabei hat er durchaus seine hysterischen und cholerischen Phasen, wo er mal rumschreit und seine Ausdrucksweise alles andere als angebracht ist. Hat mich bis dato aber nie getroffen. Wäre vermutlich dann irgendwann auch der Punkt wo ich tschüss sagen würde.

Bei den Sachen die direkt für den Kunden sind gibt es die Diskussion diesbezüglich nicht. Wie gesagt da sind die Schätzungen eh Schall und Rauch. Dass die Sachen nicht zur Deadline fertig sind ist aber schlicht keine Option, da gibt es dann im Zweifel eben Überstunden.

Edit: Frage ist da aber wohl auch immer wie man sich ausdrückt, wenn man darüber redet. Ob es konkrete Gründe gibt und man das kurz und knapp benennen kann und den Termin ergänzen kann oder ob man da ne halbe Stunde um den heißen Brei rumstammelt. Glaube das ist so der Punkt, wo mein Chef meist eher etwas aggressiv reagiert.

Bearbeitet 17. Mai 2020 von Velicity

[pr0gg3r]

vor 20 Stunden schrieb dnyc:

Mit den Zeitschätzungen tue ich und mein Kollege uns recht schwer. Unser Chef will, dass wir möglichst genau schätzen, wie lange wir für eine Aufgabe brauchen werden, allerdings kann ich das auch oft nicht sagen, da ich nicht weiß, was für ein möglicher Rattenschwanz das mit sich zieht.

Befasse dich mal mit Thema "Planning Poker". Dabei werden die Aufgaben von den Entwicklern geschätzt und diskutiert. Sagt zum Beispiel ein Entwickler, man braucht für einen Task 3 stunden und ein anderer sagt man braucht 2 Wochen, dann ist hier Klärungsbedarf des Tasks nötig (da hier dann jeder in dem Task etwas anderes sieht). Nachdem der Task dann genauer beschrieben bzw. erklärt wurde, wird erneut geschätzt. Ist der Task dann immer noch nicht schätzbar, ist er eventuell nicht granular genug und muss ggf. in mehrere kleinere Tasks geteilt werden. Das ist insgesamt aber eine Aufgabe des Teams (ich weiß ja nicht, wer die Tasks bei euch erstellt).

An anderes Problem ist "möglichst genau schätzen". Schätzen impliziert ja schon beim Begriff, dass man sich dem tatsächlichen Aufwand nur annähern kann (ggf. durch Methoden wie Planning Poker). Auf mehr sollte dein Chef nicht beharren.

vor 20 Stunden schrieb dnyc:

Bei einem Kumpel von mir ist es so, dass sie einen Termin für das nächste Release festlegen und dann so viele Aufgaben wie möglich machen. Alles was nicht geschafft wurde wandert dann in's nächste Release.

Dies finde ich auch besser weil praktikabler. Man muss keine Zeitschätzung machen, die eh danebenliegt und hat keinen Druck alle vorgenommenen Aufgaben auch ja zu erledigen, zumal ja während des Prozesses auch neue, wichtige Bugfixes dazu kommen können, wobei aber da der Release nicht verschoben wird, sondern das in der geschätzen Zeit geschafft werden muss.

Natürlich kann man nur ausliefern was fertig ist, dennoch kann man planen welche Features in welches Release wandern können (zB per Release Roadmap und Story Mapping). Es ist aber auch eine Frage des Teams. Ein Team will möglichst viele Features reinkloppen und ein anderes vielleicht möglichst viel Kaffee trinken und macht dann pro Release ein Feature (übertrieben gesagt).

Wenn sich Prioritäten ändern (zB ein Bug wird entdeckt, dessen Fix höchste Prio hat) muss man natürlich auch die Features für das nächste Release anpassen, so dass dann eben auch Druck genommen wird.

Ich würde sagen, man kann schon ganz gut planen, aber es muss eben gemacht werden. Wenn der Chef eine Minutenlange Schätzung verlangt für Tasks, die schwammig beschrieben sind kann das nicht funktionieren.

 

Bearbeitet 17. Mai 2020 von pr0gg3r

[Gooose]

Wir haben ein relativ gut aufgeräumtes Backlog. Neue Tickets werden soweit angereichert, bis sie den Status "ready for development" haben. Wir schätzen unsere Tickets in Punkten. Mit der Zeit haben wir erkannt, wie viele Punkte innerhalb eines Sprints zu schaffen sind. Das Team trifft gemeinsam die Aussage, ob der Sprint zu schaffen ist oder nicht. Es werden keine Zeiten geschätzt. Tickets sind soweit angereichert, das jeder im Team sie bearbeiten könnte.

[allesweg]

Am 16.5.2020 um 20:52 schrieb dnyc:

Mit den Zeitschätzungen tue ich und mein Kollege uns recht schwer. ..., da ich nicht weiß, was für ein möglicher Rattenschwanz das mit sich zieht.

Warum? Können das andere Entwickler bei euch? 

Meine Erfahrungen sind, dass fixe Releasetermine besser mit Features gefüllt werden können. Den Termin auf “it's done, when it's done“* legen stellt kaum einen Kunden zufrieden. 

Wichtig ist dabei: release early, release often.

 

*dncornholio

[Rabber]

Weiter vorne wurde der Begriff "granular" genannt. Ich glaube, das ist der wesentliche Punkt: Häufig sind die Aufgaben zu groß, um sie sinnvoll schätzen zu können.

Es macht einen Unterschied, ob das Arbeitspaket lautet "Druckliste x mit Daten y zu generieren" oder "Kunde x glücklich stellen". Zweites ist klassischerweise wesentlich schwieriger zu planen und umzusetzen als erstgenanntes.

Deswegen wäre mein erster Anhaltspunkt, dafür zu sorgen, dass die Arbeitspakete so klein wie möglich gehalten werden. Ein Ticketsystem kann hierbei hilfreich sein, sofern noch keines vorhanden ist.

 

Zudem schließe ich mich an, dass "release often" so gut wie möglich umgesetzt werden sollte.

Je häufiger released wird, umso schneller gehen Patches/Bugs/Features an die Kunden raus und gleichzeitig wird jedes Release überschaubarer, was zum oben genannten Thema "granular" passt.

Monster-Releases sind fast immer nachteilig. Schlechter zu planen, schwieriger zu testen und komplexer zu installieren. Gerade in Zeiten von Internet und always on ist der Sinn solcher Updates auch nicht mehr so gegeben wie das noch der Fall war, als man einmal im Quartal ein Update auf DVD bekommen hat.

Bearbeitet 18. Mai 2020 von Errraddicator

[allesweg]

Nachtrag: Kunden dürfen sich immer etwas wünschen. Wenn etwas regulatorisch termingebunden ist, muss es unverzüglich nach Bekanntwerden angefordert werden. Sonstige Wünsche werden grob geschätzt und einem möglichen frühesten Release zugeordnet. Zu diesem Release gehören Termine, zu welchen der Wunsch wie fein als Anforderungen beschrieben sein muss. Werden diese Termine ignoriert, wird die Anforderung ausgeplant.

Im Release werden nicht 100% der Kapazität verplant sondern ein gewisser Anteil für Hotfixes reserviert. Falls diese Reserve nicht benötigt wird, können sauber definierte Anforderungen aus dem Folgerelease vorgezogen werden.

 

Auf diese Weise werden die Anforderer gezwungen, sauber zu liefern. Und wenn sie merken, dass frühzeitig saubere Anforderungen (von anderen Anforderern) auch mal früher kommen, machen sie es plötzlich gerne....