Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute geht es um das Thema mit dem Schätzen und auch mit den Deadlines.
Und ich möchte vorher nochmal kurz hinweisen auf unsere Diversity-Umfrage für unsere Special-Edition-Episode live von den IT-Tagen zum Thema Diversity in der IT.
Da suchen wir persönliche Erfahrungsberichte von Menschen, die in der Tech-Branche unterrepräsentiert sind oder sich dort nicht immer wohlgeführt haben.
Ich habe den Link, den habe ich noch nicht, aber den packe ich jetzt mal in den Chat.
Das heißt, wenn ihr da mitmacht, das wäre sehr hilfreich.
Dann können wir nämlich bei der Episode über diese Geschichten potenziell anonym reden.
Ansonsten zum Thema.
Ich habe zu dem Thema jetzt gerade einen Heißblock veröffentlicht, zu diesem Schätzenthema.
Das hier ist Software-Architektur im Stream.
Das ist nicht das Kernthema, sondern eher ein Thema von Vorgehen, ob und wie man schätzt.
Das ist nicht wirklich ein Architekturthema.
Bevor ich da in die Details gehe, will ich eigentlich erst mal den Hinweis loswerden.
Anforderungen sind bei Definitionen nicht fest.
Wenn ich ein Projekt starte, habe ich Software.
Die Software setzt sich Menschen vor.
Diese Menschen arbeiten mit der Software.
Dann kriege ich Feedback.
Dann ändere ich das.
Das ist einer dieser Feedback-Zyklen, dieser Apple-Effekt.
Wenn man den Leuten ein iPhone zeigt, dann wissen sie erst, dass sie eigentlich ein iPhone gerne haben möchten.
Vorher hätte man gesagt, ohne Tastatur.
Das ist bei Software ein bisschen ähnlich.
Das heißt, man muss den Leuten etwas vorsetzen, bevor sie Feedback geben können.
Dann kann man erst weiterarbeiten.
Durch die implementierte Software werden Missverständnisse, die es möglicherweise gibt, in Bezug auf Anforderungen oder anderen Themen klar.
Eigentlich will ich eine Software entwickeln.
Eigentlich will ich einen Feedback-Zyklus haben.
Eigentlich will ich von irgendwelchen BenutzerInnen oder von anderen Stakeholdern Feedback haben.
Das bedeutet für die Diskussion, die wir hier haben, dass Abschätzen eigentlich gar nicht so wichtig sein kann, weil die Software im gemeinsamen Feedback-Zyklus entsteht.
Das heißt, ich setze mir etwas vor, die Arbeiten daran, dann bekomme ich Feedback, dann arbeite ich an der nächsten Version usw.
Das heißt, ein Projekt komplett durchzuplanen, komplett durchzuschätzen, das ist die Frage, ob es das wert ist.
Jetzt kann man natürlich sagen, wir machen es einfach, so aufwendig kann es nicht sein.
Aber das Argument mit dem Aufwand fürs Schätzen, das kommt später nochmal.
Wenn wir also sagen, dass sich der Scope sowieso ändert, was er eben tut, dann ist es vielleicht nicht so sinnvoll, das komplett durchzuschätzen.
Das ist kein Rat, den ich abgeben möchte zu irgendetwas.
Ich rate nicht für oder gegen irgendetwas, sondern eigentlich war der Auslöser jemand, der nach einer Konferenz zu mir gekommen ist und gesagt hat, in der Branche, in der ich arbeite, gibt es so etwas Ähnliches wie Fallpauschalen.
Wenn ich im Krankenhaus bin, dann gibt es eine Fallpauschale dafür, dass ich ein gebrochenes Bein habe.
Jetzt war eben die Frage, die er gestellt hat, kann man so eine Art Fallpauschalen für Software entwickeln.
Also könnte man sagen, wenn ich ein Feature habe, das folgendermaßen aussieht und das möchte ich gerne implementiert haben, dann bedeutet das, dass es so lange dauert und so ein Budget ist, was also bedeutet, dass das eine Abschätzung wäre, die entkoppelt ist von dem Team, dass es tatsächlich umsetzt.
Das fand ich eine interessante Frage.
Wir haben dann irgendwie zusammengestanden.
Ich muss gestehen, ich habe Ihnen entweder nicht nach dem Namen gefragt oder den Namen mittlerweile vergessen und haben darüber irgendwie sozusagen philosophiert.
Bevor ich jetzt irgendwie darauf eingehe, ob man das hinbekommt, also ob man solche objektiven Schätzungen, die unabhängig sind vom konkreten Team, ob man das irgendwie hinbekommt, nochmal kurz, warum schätzen wir eigentlich?
Also im agilen Umsetzen ist es typischerweise so, dass ich den Aufwand abschätze, um zu entscheiden, ob ich eine Story implementiere.
Das heißt, ich habe als Product Owner eine Idee, ob das wichtig oder unwichtig ist und welchen Wert die Story hat.
Und durch die Aufwärtsschätzung kriege ich jetzt ein Feedback darüber, wie lange es dauert, diese Story umzusetzen.
Und dann kann ich sagen, okay, das ist es mir wert oder das ist es mir eben nicht wert und kann dadurch priorisiert durch die beiden Parameter Wert und Aufwand schauen, dass ich irgendetwas umsetzen möchte.
Und dieses Schätzen ist optional.
Wir hatten tatsächlich die Episode mit dem Budi Threel, der da eben über No Estimates gesprochen hat.
Und ich fand, also abgesehen davon, dass ich Budi grundsätzlich sehr sympathisch finde, ist es halt darüber hinaus so, dass ich seinen Spirit in Bezug auf No Estimates eigentlich sehr schön fand, weil er im Prinzip gesagt hat, also hör mal zu, ich arbeite im Bereich Softwareentwicklung, ich mache das schon wahnsinnig lange.
Ich habe nie irgendwas geschätzt.
Hier ist halt die Story, warum ich irgendwie so arbeite, wie ich arbeite, was halt irgendwie sagt, okay, ich habe halt keinen missionarischen Eifer, allen irgendwie zu sagen, No Estimates ist das beste ever seit geschnittenem Brot, sondern es sagt halt einfach, hier ist halt meine Art zu arbeiten und ich habe damit bisher Erfolg gehabt.
Und eigentlich ist dann so ein bisschen seine Aussage, dass es nicht nötig ist zu schätzen, wenn alle irgendwie am wichtigsten arbeiten, was man irgendwie argumentieren kann.
Und tatsächlich ist es halt so, ich glaube, da gibt es ein Missverständnis.
Ich habe dem Missverständnis auch erst aufgesessen, aber mittlerweile ist mein Verständnis halt, dass halt die Scrum-Regler beispielsweise sagen, dass man zwar einen Sprint plant, aber die sagen nicht, wie man den plant.
Das heißt also ein Product Owner kann halt einfach sagen, okay, wir implementieren diese Stories, Punkt.
Und da muss ich jetzt irgendwie keine Aufwandschätzung machen.
Das heißt also, das ist irgendwie nicht optional.
No Estimates ist also kompatibel sozusagen mit Scrum.
Und ein Thema, was wir da hatten und auch sonst irgendwie, glaube ich, ein Thema ist, dass Schätzen sozusagen einen Nebeneffekt hat.
Nämlich irgendwie einem dabei hilft, die Idee zu konkretisieren und zu hinterfragen und gemeinsam zu einer guten Idee zu kommen, wie man das halt umsetzen will.
Das kann man ersetzen durch die Frage, naja, wir setzen das ja jetzt eigentlich um.
Aber wenn ich eben anfange und sage, okay, wie lange dauert es dann?
Dann muss ich mir halt überlegen, wie baue ich es denn?
Ja, so, so und so.
Ach so, da ist eine offene Frage.
Da ist halt ein Thema, darüber sollte man nochmal reden.
Und dann komme ich halt irgendwie zu einem besseren Ergebnis.
Weil insbesondere ist es halt so, dass irgendwie nicht abschätzbare Stories auf ein Risiko hindeuten.
Also, dass das eben Dinge sind, wo irgendetwas vielleicht noch nicht ganz stimmt.
Das typische Schätzverfahren, das ich zumindest kenne, nutzt als Basis eine Referenzstory.
Also sagt halt, diese Story hat halt die Größe 1 per Definition.
Das heißt, ich schätze dann andere Dinge relativ dazu ab und nicht in Personentagen.
Die Hoffnung ist, dass man durch diese Analogieschätzung zu besseren Ergebnissen kommt.
Und während eben Personentageschätzungen so die Annahme irgendwie zu schlechteren Ergebnissen führen.
Also die Idee ist dabei, wenn ich jetzt sage, okay, ist das eigentlich schwieriger oder leichter als diese Story?
Und das eben sozusagen vergleiche.
Dann komme ich eben eher zu einem mentalen Modell, wo ich halt bessere schätze.
Und als irgendwie so, wenn ich halt einfach sage, ich habe halt eine bestimmte Anzahl an Personentagen.
Dann kommt halt noch die Velocity hinzu.
Das ist also die Anzahl der Storypoints, die man dann tatsächlich geschafft hat in einem Sprint.
Die sich auch ändert.
Das heißt also, das Team kann schneller oder langsamer sein, weil irgendwelche Menschen in Urlaub sind.
Weil irgendwelche Hindernisse da sind.
Und dadurch habe ich jetzt gegenüber einer objektiven Schätzung, die also sagt, diese Story ist halt drei Personentage, zwei Parameter.
Ich habe halt einmal diese Storypoints, die halt weich definiert sind, relativ zu irgendeiner Story.
Und dann habe ich eben eine Velocity, die sich auch ändern kann.
Und diese beiden Sachen sind das, wie ich jetzt eben Dinge abschätze.
Und die stehen sozusagen zwischen der Abschätzung und dem tatsächlichen Aufwand, der sich dann eben ja tatsächlich in Personentagen bemisst.
Das ist nicht objektiv.
Also das ist offensichtlich nicht so, dass ich jetzt sage, diese Story ist so und so komplex und die sollte halt so und so lange dauern, unabhängig von irgendeinem Team.
Sondern sie ist eben optimiert auf Planung.
Das heißt, ich habe eine hohe Sicherheit herauszufinden, dass ich das in einem Sprint tatsächlich schaffe, weil ich eben die Velocity habe, mit dem ich halt irgendwelche Hindernisse, allgemeine Geschwindigkeit halt irgendwie nivelliere.
Und dann habe ich halt irgendwie die Möglichkeit, durch die Referenzstory zu genauen Ergebnissen zu kommen.
Es gab zu meinem Blogartikel, wie so häufig im Heise-Forum, so eine Diskussion mit verschiedenen Themen.
Eine Sache, die ich da in mir aufgeschnappt habe, ich weiß gar nicht von wem, war da irgendwie diese Frage mit, oder war die Aussage, man darf nicht in Personentagen schätzen.
Also nicht meine Expertise, aber die Aussage ist eigentlich eine andere.
Die Aussage ist, wenn ich in Personentagen schätze, dann bedeutet das halt, dass ich zu weniger präzisen Ergebnissen komme.
Und für die Planung, wofür ich das halt irgendwie brauche, dafür reicht halt dieses Verfahren.
Und dann ist halt irgendwie die nächste Frage, warum will ich eigentlich in Personentagen schätzen?
Also ich bekomme halt für den nächsten Sprint heraus, wie viel ich dort irgendwie machen kann.
Das reicht also.
Da brauche ich keine Personentage, würde ich sagen.
Und ich bin eben nicht sicher, da sind wir wieder bei dem ursprünglichen Thema, ob ich halt für die Gesamtschätzung überhaupt sozusagen den Gesamtaufwand schätzen will.
Also ich habe tatsächlich einige Zeit als Product Owner gearbeitet.
Ich hatte ein relativ großes Backlog, wie es halt so ist.
Also das ich übernommen habe und verwaltet habe.
Also ich habe es nicht selber irgendwie groß aufgebaut.
Und ich war so eine Art Zwischenlösung als Product Owner.
Und ich muss gestehen, die wertvollste Information, die ich hatte, waren die nicht abschätzbaren Storys, weil das waren die Sachen, die halt irgendwie unklar waren, wo wir irgendwie nochmal dran arbeiten müssen.
Wobei man halt auch argumentieren kann, naja, ich lasse die halt erstmal unklar, also kümmere ich mich halt darum, wenn ich halt dahin komme.
Wichtiger Punkt dabei, die Velocity ist halt nicht vergleichbar, denn unterschiedliche Teams sind unterschiedlich schnell und haben unterschiedliche Referenzstorys.
Das heißt also nicht, je nachdem welche Referenzstory ich benutze, komme ich halt zu unterschiedlichen Velocities.
Und ich habe tatsächlich mal in einem Talk gesessen, wo jemand gesagt hat, ja, das ist unser schnellstes Team, weil das hat irgendwie die höchste Velocity.
Das ist halt offensichtlicher Quatsch.
Also ich kann halt, wenn ich unterschiedliche Referenzstorys habe, komme ich zu unterschiedlichen Ergebnissen.
Und das ist eben für die Planung des jeweiligen Teams relevant.
Und man kann das jetzt auch versuchen zu objektivieren durch eine Story, die man halt als die absolute Referenzstory über alle Teams macht.
Ich verstehe nicht, warum, weil die Teams halt an unterschiedlichen Sachen arbeiten, per Definition.
Also warum würde man das vergleichen wollen?
Und es ist außerdem so, dass das halt schwierig ist, weil eben nur ein Team diese Story implementiert hat.
Das heißt, nur ein Team hat die echte Erfahrung.
Diese Vergleichbarkeit finde ich halt irgendwie schwierig.
Genau, jetzt kommt die Familie Eichstätt, die sagt, ich habe sehr gute Erfahrungen mit dem Verfahren Cocomo 2 gemacht.
Da dieser Algorithmus auf Lock- und Komplexitätsfaktoren basiert, dann schätze ich die Größenordnung des Projekts in Lock und Rechne.
Genau, dazu kommen wir sozusagen gleich.
Also erst mal nicht die erste primitive Art und Weise, die ich jetzt haben könnte, mich objektiven Schätzungen halt anzunähern, während ich sich so eine absolute Story wähle.
Ich glaube, das machen einige.
Ich verstehe nicht, warum man das machen wollen würde.
Und dann kommt irgendwie das, was diese Familie Eichstätt hat eben gesagt und auch das, was ich in dem Blogartikel kurz erwähnt habe.
Also Cocomo, beziehungsweise das andere Verfahren, was mir da halt präsent war, ist das Thema mit den Function Points.
Und letztendlich ist es dann so, dass man halt sagt, okay, ich schaue also, was dort gebaut werden soll, schätze das halt irgendwie ab.
Langsam Code finde ich ein bisschen eigenartig, weil das zum Beispiel programmierspannend abhängig ist.
Also zum Beispiel vielleicht den Function Points und schaue dann halt irgendwie, wie lange es dauern wird, so etwas zu implementieren.
Und ich habe dazu sozusagen zwei Bemerkungen.
Ich finde das halt erstmal spannend, dass dieses Feedback kommt, dass man Cocomo 2 nutzen kann.
Die Projekte, die ich typischerweise sehe, nutzen halt diese Ansätze nicht.
Und diese Ansätze sind halt älter.
Das sind halt Sachen, die durchaus alt und etabliert sind.
Und wenn man sich das halt anschaut, dennoch so sind, dass es da halt irgendwie Warnungen gibt.
Also man muss halt erfahren sein.
Es sind halt nur grobe Richtungen.
Also auch das ist nicht wirklich präzise.
Und mein persönlicher Rückschluss daraus, dass das eben mittlerweile kein Thema ist, und dass irgendwie Scrum- und Story-Point-basierte Schätzungen eigentlich das Feld mittlerweile bestimmen.
Mein persönliches Ergebnis daraus ist, dass man solche absoluten Schätzungen vielleicht gar nicht will.
Man sie aber vielleicht mit so etwas, wie diesen Ansätzen halt umsetzen kann.
Und darüber kann man sozusagen diskutieren.
Also der René Hartmann hatte in dem, oder ein Account, der halt René Hartmann heißt, hat in den EISE-Kommentaren irgendwie auch geschrieben, naja, eigentlich will man sowas ja haben.
Eigentlich will man halt in Personentagen schätzen und das halt irgendwie am Ende haben.
Und ja, wenn das so ist, dann nutzt halt diese Verfahren.
Für mich steht ja noch mal das Schöne bei Kokomo, sind die Faktoren IF und SF.
Bedeutet, wie komplex das Projekt und erfahren, ist die Organisation beziehungsweise das Team genau.
Das heißt, ich kann es halt darüber dann sicher auch rausnivellieren.
Also diese Ansätze gibt es halt.
Und ich würde dazu jetzt Folgendes sagen.
Also die eine Sache ist halt, Aufwand schätzen in Personentagen bedeutet halt, dass ich jetzt für irgendwelche festen Anforderungen einen Gesamtaufwand definieren kann.
Wenn sich die Anforderungen ändern, was ich als gegeben annehmen würde, also ich glaube niemand, der schon mal ein IT-Projekt gemacht hat, wird bestreiten, dass eben die Anforderungen sich ändern.
Dafür ist irgendwie die Frage nicht, lohnt sich das eben diese Schätzung so präzise zu machen?
Und ich erinnere mich daran, dass ich halt damals, als ich halt irgendwie das erste Mal mit Extreme Programming insbesondere in Kontakt gekommen bin, das ist halt mittlerweile 25 Jahre her, weil ich eher irritiert darüber, wie einfach das Schätzen ist.
Also dass man halt einfach irgendwie sagt, naja, so ungefähr.
Wo ich vorher aus einer Welt kam, wo ich das Gefühl hatte, naja, das muss halt irgendwie sehr präzise und sehr genau sein.
Was halt bedeutet, dass im Prinzip diese agilen Ansätze im Mainstream eben diese komplizierteren Sachen und aufwendigeren Sachen halt letztendlich so ein bisschen ersetzt haben.
Dann gibt es halt noch so ein paar andere Geschichten.
Ich habe auch bei Heise, verlinke ich auch nachher noch, einen Blogpost geschrieben, wo ich gesagt habe, eigentlich ist halt der Wert entscheidend.
Und das, finde ich, ist immer noch so ein Thema.
Das ist, glaube ich, auch etwas, was mit Agilität zusammenhängt.
Wenn ich halt, also warum bauen wir Software?
Weil die Software hat einen Wert repräsentiert.
Ich kann halt einen Markt besetzen, ich kann Dinge automatisieren, solche Geschichten.
Wenn dieser Wert sollte signifikant höher liegen als die Investitionskosten in die Software, weil wenn ich die Software baue, habe ich halt immer Risiken.
Es kann halt immer sein, dass das Projekt halt schief geht, dass ich mich irgendwo verrenne, dass ich halt Dinge übersehen habe.
Und das bedeutet, dass eigentlich der Wert vielleicht das ist, was ich halt managen möchte und nicht so sehr die Kosten.
Und da gibt es halt irgendwie Ansätze, die halt sagen, naja, ich rechne jetzt irgendwie aus, wie hoch der Businesswert eines Softwareprojekts ist.
Tatsächlich gibt es das in größeren Organisationen teilweise.
Und das sind eben, glaube ich, die interessanteren Metriken gegenüber dem Aufwand.
Weil wenn ich halt wertvolle Software baue, ist halt der Aufwand ein anderes Thema.
Ich habe halt anekdotisch einmal ein Projekt erlebt, wo halt sozusagen durch den Projektbeginn schon das Projekt positiv war, also Geld gebracht hat, weil eben es war ein Finanzdienstleister, der halt irgendwie Geschäfte abschließen konnte, die er vorher halt irgendwie nicht abschließen konnte, weil dann irgendwann die Software da ist, um irgendwelche Dinge halt abzuwickeln in Zukunft.
Also irgendwelche zukünftigen Finanzgeschäfte.
Und die kann ich dann halt irgendwie durch die Software jetzt überhaupt erstmal annehmen.
Und das ist halt die Situation, in der man sein möchte.
Also man möchte eigentlich einen Wert schaffen.
Das sollte halt irgendwie den Aufwand reduzieren.
Eine Sache, die dann für mich bei dieser, wie soll ich sagen, intellektuellen Diskussion relevant war, und die für diese absolute Diskussion und mit diesem ganzen soziotechnischen Zeug, wo man ja eigentlich sagt, dass Softwareentwicklung etwas ist, was halt sehr stark von Organisationen abhängt, was also in diesem Bereich, glaube ich, sehr spannend war, sind so Aufwandausreißer.
Also warum sind die erstmal spannend?
Wenn wir Organisationen haben, die halt einen auffällig niedrigen Aufwand haben, dann führt das dazu, dass man halt die Frage stellen kann, können wir solche Aufwände überhaupt absolut schätzen?
Weil es gibt bestimmte sehr produktive Umgebungen, die halt dazu in der Lage sind, Software sehr, sehr schnell zu implementieren.
Also man kann über Implementierung nachdenken, ohne den Aufwand zu schätzen.
Und ich hatte am Anfang gesagt, dass das eine Frage sein kann.
Also dass ich jetzt sage, wie aufwendig ist das, um dafür zu sorgen, dass ich die Implementierung durchdenke.
Aber das ist nicht zwingend.
Also ich kann die Implementierung durchdenken, ohne dass ich jetzt zwingend eine Aufwandzahl unterschreibe.
Kommen wir nochmal zu den Deadlines.
Und da war MVO’s Hinweis zu diesem ersten Release, glaube ich, ganz gut.
Und da ist, also als ich in dieser Product Owner Position war, war das Projekt, für das ich halt verantwortlich war, was ich da geführt habe für einige Zeit, eben eines der wichtigen Teilprojekte in diesem Kontext.
Und das hatte zur Folge, dass ich mich irgendwie hingestellt habe und eine sehr unangenehme Situation hatte.
Im Prinzip irgendwie gesagt habe nicht, oder öfter gesagt habe, hey, das Projekt, was wir haben, das dauert jetzt irgendwie noch länger.
Weil wir halt neue Dinge herausgefunden haben und unsere Gesamtabschätzung für den Gesamtaufwand ist halt länger geworden.
Oder auch wenn die Geschäftsführung gesagt hat, okay, oder der Geschäftsführer, okay, kann ich dich irgendwie unterstützen.
Also es war eine produktiv hilfreiche Fehlerkultur und dort irgendwie eine gute Sache.
Und wir kennen, glaube ich, in unserer Welt Projekte, die auf so eine Deadline arbeiten.
Die sagen nicht, dann und dann ist das Projekt beendet.
Dann muss es live gehen und vielleicht sogar auch noch mit festen Features.
Wir haben schon darüber gesprochen, dass Features flexibel sein müssen.
Dass man über die Zeit lernt, was eigentlich gebaut werden soll.
Dafür gibt es halt genügend Evidenz.
Da will ich sozusagen nicht so tief reingreifen.
Aber eigentlich führt das zu diesen Deadlines und zu dieser Geschichte, naja, irgendwann muss ja irgendetwas live gehen.
Und vielleicht ist das eben eine Deadline.
So ein agiler Ansatz könnte irgendwie sein, okay, am 1.12. gehen wir mit dem Zeug, was wir dann haben, live.
Das heißt, wir machen ein Timeboxing und dann haben wir eben ein Release, das die entsprechenden Features hat.
Ich könnte jetzt aber auch sagen, naja, ich muss halt mit bestimmten Dingen einfach live gehen, die ja notwendig sind zu einer bestimmten Deadline.
Und meine Erfahrung als Product Owner ist, war in diesem spezifischen Kontext, dass wir so eine Deadline nicht hatten.
Und ich habe ebenfalls auf einer Konferenz auf den XP Days in Stuttgart mit jemandem gesprochen, das mir leider auch der Name entfand, der eine sehr interessante Anekdote erzählt hat.
Und zwar hat er gesagt, naja, ich war Projektleiter und ich habe letztendlich gesagt, hey, wir arbeiten so schnell, wie wir können.
Wir sind halt fertig, wenn wir fertig sind und wir haben eben keine festen Deadlines.
Und dann ist er halt irgendwie als Projektleiter, hat er den Job abgegeben und ab dort gab es halt irgendwie feste Deadlines, die halt irgendwie vorgegeben waren.
Und ich meine, bin ich mir nicht ganz sicher, dass er dann nochmal sozusagen den Job wieder übernommen hat und dann waren die Deadlines wieder weg.
Und das fand ich als Anekdote ganz interessant.
Er hatte mir das, glaube ich, deswegen erzählt, weil ich in meinem Talk gesagt habe, nicht auf Deadlines hinarbeiten, das ist wichtig, die sind nahezu sakrosankt und man muss das irgendwie auf die Reihe kriegen.
Und dieser Effekt, dass die Deadlines plötzlich weg sind, wenn halt jemand anders das Projekt managt, lässt sich ja dadurch nicht erklären.
Und ich würde behaupten, es gibt Deadlines, die halt tatsächlich fest sind.
Wenn wir uns jetzt irgendwie hinstellen und sagen, wir machen was für das Weihnachtsgeschäft, dann muss das halt deutlich vor dem 24.12. live sein.
Wenn wir das nicht schaffen, haben wir das hier nicht erreicht.
Und das ist eben tatsächlich eine harte Deadline.
Und das ist sozusagen trivial.
Die Frage ist, was halt mit anderen Deadlines ist.
Und ich kenne mir jetzt mindestens ein Beispiel präsent, wo man im Prinzip gesagt hat, okay, das ist halt die Deadline, auf die arbeiten wir halt alle zu.
Und dann haben wir irgendwann gesagt, jetzt wo wir nochmal darüber nachgedacht haben, das Projekt ist irgendwie komisch und das hat irgendwie eine Schieflage, lass uns das doch stoppen und lass uns neu organisieren nach einer neuen Deadline.
Das impliziert, dass die Deadline eben nicht fest war.
Also offensichtlich hat man halt gesagt, hey, wir haben halt eine Deadline und die können wir jetzt ohne weiteres, also wir können uns sogar einen Projektabbruch und eine Reorganisation halt irgendwie leisten.
Und dann irgendwie zu schauen, wie wir tatsächlich vorgehen.
Was halt bedeutet, dass diese Deadline das Gegenteil von fest war.
Hätte man den Projektabbruch nicht gemacht und in dem Kontext, in dem wir uns halt dort erstmal befunden haben, war der eben tatsächlich irgendwie festgelegt.
Der hat irgendwie dazu geführt, dass halt bestimmte Entscheidungen getroffen worden sind und die sind irgendwie auch nicht revidierbar gewesen.
Was das halt bedeutet ist, dass Deadlines eigentlich weicher sind.
Also ich kann offensichtlich den Projektabbruch mir schon leisten und dann haben wir die Deadline verschieben.
Was halt zu der Frage führt, wir investieren also in die Verbesserung eines Systems.
Wir bauen also irgendetwas.
Was passiert, wenn wir zu spät sind?
Wir haben halt das bessere System erst später.
Was bedeutet das?
Die Produktivitätsvorteile in der Weiterentwicklung sind halt erst später tatsächlich da.
Ist das ein Problem?
Nein, das ist halt kein Problem, weil das eben nur in Anführungsstrichen bedeutet, dass wir halt später die Vorteile dieser verbesserten Architektur halt bekommen.
Das heißt also, bei einer Migration auf eine Architekturmigration ist es irgendwie schwer zu erkennen, warum da eine harte Deadline sein sollte.
Das ist halt irgendwie nicht so wie das Weihnachtsgeschäft.
So und jetzt ist halt irgendwie die Frage, was bedeutet das für dieses ganze Schätzen und diese absoluten Zahlen?
Also es zeigt eben, dass wir, wenn man sozusagen wirklich ehrlich zu sich ist, vielleicht in einigen Situationen diese Deadlines nicht wirklich benötigen.
Und dann kann ich auch entspannter sein in Bezug auf die Schätzung.
Also in einem Projekt, das irgendwie sagt, wir schätzen nicht, also nur Estimates, das mache ich halt irgendwie nur so.
Wie kann es sein, dass da irgendwie das mit den Deadlines halt funktioniert?
Naja, indem ich eben realisiere, dass die Deadlines halt irgendwie eher weich sind.
So und jetzt ist irgendwie die Frage, warum gibt es dann Deadlines?
Also in der Mehrzahl der Fälle sind die vermutlich eher weich.
Da kann man mit diskutieren.
Ich habe halt irgendwelche Dinge, die ich irgendwelchen Kunden verspreche.
Ich habe irgendwie das Weihnachtsgeschäft und so.
In den Fällen sind sie natürlich nicht weich.
Ich würde trotzdem behaupten, dass sie halt in vielen Fällen oder vielleicht in der Mehrzahl der Fälle eben weich sind.
So und jetzt ist irgendwie die Frage, warum haben wir dann diese Deadlines?
Und ich glaube, das hängt halt zusammen mit der Illusion der Kontrolle.
Also das, was ich gerade eben erzählt habe, ich fühle mich halt tatsächlich dabei unwohl.
Das führt nämlich dazu, dass man im Prinzip sagt, hey, wir bauen halt irgendwie Software.
Nervt uns nicht damit, weil wir fertig sind.
Wir bauen halt einfach irgendwie Software.
Und das finde ich halt irgendwie schwierig, weil wenn ich jetzt ein Fahrrad zur Reparatur bringe, erwarte ich von der Person auch, dass sie mir irgendwie sagt, irgendwann ist das halt irgendwie fertig.
Und für die Arbeit, die wir jetzt in unserer Branche machen, ist das vielleicht so, dass wir dann, wie soll ich sagen, ja, dass wir da vorsichtig sein müssen.
Sorry, ich habe ein bisschen den Fall verloren.
Ich habe nämlich gerade nochmal hier reingeguckt.
Kevin Wittek hat gerade geschrieben, subjektives Schätzen, beliebige Deadlines, a story of my life.
Und das meine ich eben tatsächlich auch nicht.
Also subjektives Schätzen ist das, was wir tun.
Und die Deadlines sind eben, wenn man sie hinterfragt, eben vielleicht doch beliebig.
Und genau, also ein Grund, warum man halt dann trotzdem Deadlines haben möchte, ist, glaube ich, diese Illusion der Kontrolle und der verantwortbaren Entwicklung.
Also diese Idee von, wir entwickeln einfach Software und wir geben uns nicht mit so etwas ab wie Deadlines.
Ich fühle mich dabei halt begrenzt wohl, um ehrlich zu sein.
Obwohl, ich hatte es gerade eben gesagt, ich denke, dass halt in der Mehrzahl der Fälle diese Deadlines vielleicht wirklich nicht so wichtig sind.
Ich glaube, ein weiterer Punkt ist halt irgendwie Druck aufzubauen, was aber letztendlich bedeutet, dass man den Menschen misstraut und dann wie gesagt, wenn ich jetzt keinen Druck durch eine Deadline aufbaue, dann arbeiten sie halt irgendwie nicht schnell genug.
Und ich halte das deswegen für schwierig, weil ich behaupten würde, das Gegenteil ist der Fall.
Wenn wir Leute unter Druck setzen, fangen sie halt an, Technical Depth anzuäufen.
Und ich behaupte halt, dass das eigentlich der Hauptgrund ist für Technical Depth.
Vielleicht auch wegen Koordination zwischen Teams.
Das wäre halt noch ein weiterer Grund.
Ich gucke jetzt noch mal in die Kommentare.
Also der Urs Enzler hat noch mal geschrieben, wir schätzen grob als Grundlage für Entscheidungen, zum Beispiel auch bei harten Deadlines, dann aber mit viel Puffer.
Das passt zu dem, was ich sagte.
Meine Behauptung wäre, ich will nicht sagen, dieses Feature kostet so und so viele Personentage, sondern ich will schätzen, um Entscheidungen zu treffen.
Das bedeutet, ich schätze halt so genau, dass ich eine Entscheidung treffen kann.
Und das ist das, was agiles Schätzen im Prinzip sagt.
Meiner Ansicht nach nicht in Retrospektive, wenn ich mir das von vor 25 Jahren angucke, dann halt sehr hemmsärmlich, also ohne so ein ausgefeiltes, ingenieursmäßiges Vorgehen, wie es eben Cocomo oder Function Points hat.
Dann hat Fabian B. geschrieben, wie ist das mit B2B-Kontexten, wo Deadlines in Verträgen stehen, in Krisenvertragsstrafen, wie bekommt man es hin, dass zähls genügend Wissen hat, und mit dem Kunden realistisch verhandelt?
Naja, ich sage ja nur, dass die Mehrheit der Deadlines weich ist.
Ich sage nicht, alle Deadlines sind weich.
Wenn ich harte Deadlines habe, habe ich irgendwie harte Deadlines.
Das ist halt letztendlich die Frage nach den Festpreisprojekten.
Ich sage halt, dann und dann liefere ich folgendes Software mit folgenden Features.
Meine Meinung dazu ist, wenn man tatsächlich sagt, dass sich die Requirements ändern, haben Festpreisprojekte ein Problem, und ich kann die Kosten reinholen, indem ich Change Requests mache.
Das heißt, was ich spiele ist, ich habe folgendes Ding vertraglich festgelegt, folgenden Funktionsumfang.
Dann kommt der Kunde und sagt, netter Versuch, wir brauchen eigentlich etwas anderes.
Dann sage ich, cool, können wir nachverhandeln.
Und dann erhöhe ich die Kosten und sorge dafür, dass ich mich gesundstoße.
Die andere Möglichkeit ist, das führt zu einem Konfliktpotenzial, dass man auf der einen Seite den Dienstleister hat, der sagt, ich möchte möglichst wenig liefern, möglichst wenig Aufwand haben und möglichst viel Geld abgreifen.
Und der Auftraggeber sagt, ich möchte möglichst viel reinverhandeln und möglichst viel hinbekommen.
Das ist ein Kontext, in dem ich ungern arbeiten wollen würde.
Wenn ich hingegen ein vertrauensvolles Verhältnis habe, dann kann man irgendwie diskutieren.
Dann würde ich sagen, okay, da ist die Deadline.
Jetzt stellen wir fest, wir haben ein Problem.
Lasst uns darüber reden, lasst uns schauen, was wir weglassen können, wo wir Abkürzungen nehmen können, um zu der Deadline das zu liefern, was tatsächlich hilfreich ist.
Dann wird der Auftraggeber nicht anfangen und sagen, das Projekt ist wertvoll und hat etwas gebracht.
Aus meiner Sicht ist der Umgang davon determiniert, wie stark ich dem Kunden vertraue und wie gut das Verhältnis dort ist.
Danach muss man es anpassen.
Die in Hamburg.
Eine verschobene, gerissene Deadline ist aber nicht kostenfrei, oder?
Das ist eben genau die Frage.
Die Frage ist, wie hart sind diese Deadlines, was sind die Ergebnisse, wenn wir das nicht realisieren.
Wenn wir strategisch in die Verbesserung des Projekts investieren, und das ist das Ziel unseres Projektes, bedeutet das nur, dass wir die volle Verbesserung erst später bekommen.
Kevin Wittek hat geschrieben, Druck führt dann zu bestimmten Engineering Trade-offs.
Das ist theoretisch sogar okay, wenn das 1D-Coder bewusst ist.
Es braucht dann aber in der Regel auch starke Manager, die das in der Kommunikation nach oben kommunizieren können.
Stimmt, das war für mich einer der Punkte, weswegen ich das mit den Deadlines aufgenommen habe.
Und weswegen ich darüber noch mal sprechen wollte.
Wenn wir Deadlines sakrosankt machen, bedeutet das, dass wir in der Architektur, wie du richtig sagst, Trade-offs machen, und dann zu irgendeinem Ergebnis kommen.
Das können suboptimale Ergebnisse sein.
Wenn wir tatsächlich realisieren, dass diese Deadlines weich sind, haben wir dort noch einen weiteren Spielraum.
Mir ist mindestens ein Szenario bekannt, wo wir tatsächlich losgegangen sind und gesagt haben, die Deadline ist fest, die muss gehalten werden.
Deswegen haben wir uns zufrieden gezeigt mit einer bestimmten suboptimalen technischen Umsetzung.
Wenn ich aber sage, dass die Deadline flexibel ist, dann kann ich da noch mal das revidieren.
Deadlines nicht als absolut zu sehen, sondern auch zu sagen, wir haben die Chance, da noch etwas zu drehen.
Das ist der Punkt.
Was hat Kevin noch geschrieben?
Führt auch dazu, dass Entwickler in die Ownership aufgeben und einfach nur noch tun, was angefragt ist?
Das ist besonders schlecht, wenn es um innovatives Produkt-Engineering geht.
Genau nicht.
Das ist auch ein Punkt, was uns hilft, technische Innovationen umzusetzen.
Diese Konfrontation will man nicht.
Ein Projekt in so einer Konfrontation ist weder etwas, was das Team umsetzt, noch was der Kunde will.
Die Nürnberg hat gesagt, vertrauensvolles Verhältnis, wo gibt es denn so etwas?
Vielleicht bei Inhouse-Projekten im freien Markt, wenn man bewiesen hat, dass die Nachgefragte Leistung zu abnehmbaren Bedingungen geliefert hat.
In meiner Vergangenheit haben wir in einem gemeinsamen Entschluss, an dem ich beteiligt war, ein Projekt abgelehnt, weil wir nicht dazu in der Lage waren, was wir eigentlich sehr gerne gemacht hätten.
Was im Umkehrschluss bedeutet, dass es so etwas durchaus gibt.
In dem konkreten Fall war es tatsächlich so, dass dieser Konflikt mit – ich sage dir nicht, was ich eigentlich glaube, was die Komplexität dieser Aufgabe ist, damit du anschließend Probleme bei der Implementierung hast, aber es mir trotzdem billig gibst.
Das war dort irgendwie spürbar.
Das hat am Ende dazu geführt, dass wir das Projekt nicht gemacht haben.
Ich weiß nicht, ob irgendjemand das Projekt gemacht hat.
Das ist eigentlich eine Los-Los-Los-Situation.
Für uns als Dienstleister hat das bedeutet, dass wir den Umsatz nicht gemacht haben und die Implementierung nicht umgesetzt haben und uns da reingegraben haben in das Thema, letztendlich umsonst oder ohne den entsprechenden Benefit zu bekommen.
Für den Kunden bedeutet das, dass er investiert hat und auch versucht hat, das vernünftig auf die Reihe zu bekommen und uns unterstützt hat und ausgefragt hat und auch kein Ergebnis produziert hat.
Das bedeutet, wir haben beide verloren.
Die müssen jetzt anfangen und müssen die Zeit, die sie jetzt investiert haben, im Sinne von Zeit, die vergangen ist, aber auch Aufwand, noch mal investieren.
Das ist nicht schön.
Deswegen glaube ich, dass das in gewisser Weise eine Art kollaboratives Spiel ist.
Auch wenn man sagt, das sind zwei Vertragspartner, die scheinbar gegensätzliche wirtschaftliche Interessen haben.
Wenn man am Ende ein erfolgreiches Projekt hat, dann gewinnen beide.
Dazu ist ein vertrauensvolles Verhältnis notwendig.
Oder anders gesagt, ohne ein vertrauensvolles Verhältnis und ohne dass es mit dem Kunden vernünftig funktioniert, ist es eine Illusion zu glauben, dass ich das Projekt vernünftig durch die Tür bekomme.
Das würde dann dazu führen, dass man Informationen vorenthält und andere Schwierigkeiten hat.
Dann würde es trotzdem schiefgehen.
Ich glaube, das ist das Problem, was sie mit Festpreisprojekten haben.
Insbesondere bei Inhouse-Projekten ist das vielleicht einfacher, aber ich sehe das nicht so.
Auch bei Inhouse-Projekten ist es schwierig, dass man in einen Konflikt kommen kann, wo Leute gegeneinander arbeiten.
Gut.
Dann haben wir das erledigt.
Ich habe zumindest keine großen Themen mehr.
Vielen Dank für die Aufmerksamkeit.
Ich ende noch mal an dieser Diversity-Umfrage.
Wenn ihr Erfahrungen habt, sind wir in einer Art und Weise als unterrepräsentierte Gruppe.
Wir freuen uns darüber, wenn ihr die ausfüllt.
Ansonsten haben wir nächste Woche ein Stream zum Thema mit der digitalen Souveränität. Übernächste Woche ist dann das Software-Texture-Gathering.
Da haben wir auch einen Rabattcode.
Dort haben wir gleich mehrere Episoden, die wir live streamen werden.
Hier ist die Nachricht.
Ihr kriegt 15 % off mit dem Rabattcode.
Der Link zu der Konferenz ist da.
Vielen Dank für die Aufmerksamkeit.
Schönes Wochenende.
Bis zum nächsten Freitag mit dem Thema mit der digitalen Souveränität.