Ja, die Diskussion ist ja nicht neu. Aber ich merke, dass ich mir selbst schwer tue, eine Meinung zu fassen. Zum einen weiß ich, dass es nicht möglich ist, eine valide Schätzung für den Aufwand eines Softwareprojektes abzugeben. Auf der anderen Seite verstehe ich aber den Kunden (denn ich bin ja auch Kunde), der natürlich einen Preis und ein Datum wissen will. Wie seht ihr das? Wie macht ihr das? Flo
Ich zerlege die Anforderung in so kleine Teile und mach mir ein Kopf um das gesamte System bis ich mir gut im klaren bin wie lange ich für die Realisierung brauchen werde. Mit ein wenig Übung geht das gut.
Für kleinere Sachen denk ich kurz drüber nach wie der Code aussehen könnte, und dann Bauchgefühl mal 2, damit ich genug Luft habe.
Ich kann mich dem Kommentar von puls200 anschließen. Wenn jemand dir eine Aufgabe gibt, musst du versuchen die Aufgabe in Teile zu zerlegen. Klassischer weise können das Dinge sein wie Oberfläche, Business Logik und Datenbank. Dann nimmst du dir zum Beispiel die DB als ersten Teil und zerlegst es weiter: Was will ich speichern? Welches DBMS nehm ich? Gibt es schon was auf das ich aufbaue? Bei einem 4-Gewinnt Spiel ist zum Beispiel das Kernproblem die Vierer / den Gewinner zu ermitteln. Es hilft dabei manchmal Kernprobleme in einer Testanwendung zu lösen und es mit in die Zeitabschätzung ...
... einfließen zu lassen. Du kannst deinem Kunden auch ruhig sagen das es 1 oder 2 Wochen dauert bis du eine Zeit nennen kannst - Das sollte eigentlich kein Problem sein
Hier wird ohne Aufwandschätzung überhaupt nichts programmiert. Fehlerbereinigung mal außen vor. Der Grund ist einfach: Nur mit Zeitangaben ist überhaupt eine Projektplanung möglich..
Eine Aufgabe wird so lange zerlegt, bis keine vagen Beschreibungen mehr enthalten sind wie z.B. "Benutzerverwaltung implementieren". Diese Teile werden dann von Entwicklern geschätzt, Testaufwand und Puffer dazugerechnet. Dann werden Abhängigkeiten bestimmt und das ganze durch MS Project geschickt. Ergebnis sind in der Regel ziemlich genaue Auslieferungstermine.
Wir machen das bis auf Details genauso. Wir machen ausserdem konkurrierende Schätzungen (mehrere, meist auch absichtlich projektunbeteiligte Personen), diskutieren grobe Abweichungen im Team und stützen uns für das Drumherum (Projektsteuerung, Test, Puffer, ...) auf kontinuierlich gepflegte Erfahrungswerte. Project verwenden wir nicht, weil unser ALM alles bietet.
Wir machen es ähnlich wie Nicolai Schönberg. Was die Datumsschätzung angeht, so rechnen wir grundsätzlich damit, dass bei uns niemand zu 100% an einem Projekt arbeiten kann, denn es fällt immer noch Aufwand für Dauerprojekte, Bestandskundenpflege usw. an. Wir rechnen normalerweise, dass jemand bei uns nur zu 50% an seinem "Hauptprojekt" arbeiten kann. Außerdem rechnen wir, solange es von Kundenseite kein absolutes Dringlichkeitsprojekt ist (was dann sowieso anders behandelt wird), zum geschätzten Enddatum möglichst noch 1 oder mehrere Monate dazu. Wenn wir dann früher abgeben können, ist der Kunde glücklich, und wenn wir tatsächlich länger brauchen, ist der Kunde nicht sauer, weil wir ihm ja ohnehin eine längere Lieferzeit gesagt haben. So versuchen wir auch, unserer eigenen Stress zu minimieren.
Die Aufgaben kommen hier eigentlich meistens in recht handlichen User Stories, da ist es dann einfacher eine Aufwandsschätzung zu machen die halbwegs passt. Denke daneben lagen wir da alle schon einmal. Wer hatte noch kein 2h-Zettelchen am Scrumboard und hat das dann eine Woche lang bearbeitet?
Moin zusammen, ich halte es für extrem wichtig, das Briefing so detailliert wir irgend möglich zu gestallten! Der Kunde möchte ja immer die Eierlegende Wollmichlsau haben. Wenn in den Anforderungen schon Unklarheiten bestehen, ist eine genaue Schätzung quasi unmöglich. Bevor du also an eine Aufwandsschätzung abgibst lieber noch ein Meeting mehr um wirklich alles in Detail geklärt zu haben.
Danach kann man im Projekt die Aufgaben entsprechend in kleinere Teilprojekte und Techniken (Architektur, DBMS, Sprache etc.) aufgliedern und diese schätzen. Hierbei sollte Test, Bugfixing und vor allem Dokumentation nicht vergessen werden. Diese Teile nehmen, nach meiner Erfahrung, meistens noch mal so viel Zeit wie die eigentliche Entwicklung in Anspruch. Wir haben bei uns im Team die Erfahrung gemacht, dass das 4 oder 6 Augen Prinzip hervorragen geeignet ist, um Zeiten besser abzuschätzen. Also 2 oder 3 Entwickler geben getrennt von einander Schätzungen ab und diskutieren dann das Ergebnis. Damit kommen wir recht nah an die Realität ran. Und zum Schluss noch ein Puffer für Orga und Kaffee drauf :-).
JA! Diese Diskusion wir in der 3/2012 erwähnt ;-)