Wie lässt sich erklären, dass es schwierig ist, den Zeitaufwand für ein größeres Softwareprojekt abzuschätzen?

37

Ich bin ein Junior-Entwickler und es fällt mir schwer einzuschätzen, wie lange es dauert, ein größeres Softwareprojekt fertig zu stellen. Ich weiß, wie man die Architektur im Allgemeinen strukturiert, aber es fällt mir schwer zu wissen, welche Details ich tun muss und welche Probleme ich lösen muss. Es ist schwer einzuschätzen, wie viel Zeit ein größeres Projekt in Anspruch nehmen wird, da ich nicht weiß, welche Probleme ich lösen muss und wie lange es dauert, sie zu lösen.

Wie erkläre ich dies einer Person, die kein Softwareentwickler ist ?

Jonas
quelle
5
Neugierig: Warum ist es Ihre Aufgabe als Junior-Entwickler, Nicht-Software-Entwicklern dies zu erklären? Befindet sich in Ihrer Arbeitsgruppe oder Managementkette jemand, der Ihnen bei der Überzeugungsarbeit helfen kann, wen Sie überzeugen müssen?
Alex Feinman
@Alex: Nein, es ist keine Person in derselben Firma. Nur eine Person mit Ideen für ein Startup. Und ich bin der einzige Entwickler, mit dem er Kontakt hat.
Jonas
1
Verwandte

Antworten:

48

Sie könnten ihn / sie fragen, wie lange es dauern würde, bis sie an einem weit entfernten Ort in einer unbewohnten Ecke der Welt ankommt. Als extremes Beispiel wählen wir einen weniger bekannten Gipfel im Himalaya, auf den nur sehr wenige (wenn überhaupt) Menschen geklettert sind. Sie würde eine Menge Vorbereitung und Übung benötigen, bevor sie überhaupt mit der Reise anfing, sowie eine Reihe von Genehmigungen, von denen jede die Reise um Monate bis Jahre verzögern kann ... und ein gutes Support-Team ... dann einmal auf den Hügel Am Hang müsste sie warten und für gutes Wetter beten, um auf den Gipfel zu klettern.

Und der Punkt ist: Jedes Softwareprojekt ist ein bisschen wie das Besteigen eines neuen Berges, wo noch niemand zuvor gewesen ist, sodass niemand direkte Vorkenntnisse hat. Erfahrene Entwickler haben vielleicht Erfahrungen mit mehr oder weniger ähnlichen Projekten gesammelt , aber es wird immer neue Elemente und Überraschungen geben - andernfalls hätte es absolut keinen Sinn, dies zu tun , wenn ein Softwareprojekt genau wie ein vorheriges Projekt wäre .

Péter Török
quelle
Mehr Unbekannte bedeuten mehr Unsicherheit.
Surfasb
9
Vergiss weit weg. Bitten Sie sie, auf die Minute genau zu schätzen, wann sie heute Abend von der Arbeit nach Hause kommen. Was passiert, wenn der Verkehr anders ist, wenn es anfängt zu regnen, wenn Sie während der Fahrt einen Anruf erhalten usw. Wenn etwas so Alltägliches und so oft wie die Heimfahrt durchgeführt wird, kann es nicht mit einem gewissen Grad an Genauigkeit gemessen werden - wie dann? Können wir erwarten, dass wir die Zeit, die für die Implementierung einer komplexen Software erforderlich ist, besser einschätzen können, die unzählig mehr und bedeutendere Variablen enthält als eine mühsame Heimfahrt von der Arbeit?
Quentin-Starin
8
@qes, ich benutze öffentliche Verkehrsmittel, daher kann ich mit ungefähr 10% Genauigkeit sagen, wann ich zu Hause ankomme - ich denke, die meisten SW-Projektmanager wären mit dieser Genauigkeit zufrieden ;-)
Péter Török
1
Die Ziele von Softwareprojekten ändern sich ebenfalls, sodass das OP sie nach einer Schätzung ihres Zeitbedarfs fragen könnte, ob sie noch pünktlich wären, nachdem ihnen jemand gesagt hat, dass sie die Spitzenwerte wechseln sollen, wenn sie sich in der Mitte der ersten befinden.
Paul
18

Hast du das der Person erklärt? Sie sind ein professioneller Softwareentwickler. Daher sollte die Person, für die Sie Software entwickeln, Ihre Kenntnisse und Ihr Feedback beim Entwurf und der Implementierung von Softwaresystemen berücksichtigen.

Der Konus der Unsicherheit ist wahrscheinlich ein guter Ausgangspunkt. Softwareprojekte sind schwer abzuschätzen, bis mehr Details bekannt sind, was später im Projekt geschieht. Darüber hinaus ändern sich durch geänderte Anforderungen auch die Schätzungen. Ihre anfänglichen Schätzungen zu Beginn eines Projekts weisen eine große Variabilität auf.

Möglicherweise interessieren Sie sich auch für andere Schätztechniken. Sie haben erwähnt, dass Sie nur ein Junior-Entwickler sind. Generell können erfahrene Entwickler besser einschätzen, da sie mehr Probleme festgestellt, diese behoben und (hoffentlich) die Schätzung im Verhältnis zur tatsächlichen Zeit verfolgt haben. Sie können dies mit Schätztechniken wie Breitband-Delphi oder Planning-Poker nutzen .

Beginnen Sie als Nachwuchsentwickler jetzt damit, Schätzungen und die tatsächliche Zeit zu verfolgen. Vielleicht möchten Sie etwas über den Personal Software Process lesen, der am Software Engineering Institute entwickelt wurde. Die wichtigsten PSP-Bücher sind A Discipline for Software Engineering , PSP: Ein Selbstverbesserungsprozess für Softwareingenieure und Einführung in den persönlichen Softwareprozess . Ich glaube, dass die Einführung in den Personal Software-Prozess die Themen abdecken würde, die Sie am hilfreichsten finden würden. Ich denke, es ist im Allgemeinen übertrieben für die meisten Entwickler, aber es gibt einige gute Ideen und bewährte Methoden, die herausgearbeitet und verwendet werden können, um die persönliche Produktivität zu verbessern und verschiedene Fähigkeiten (einschließlich Schätzungen) zu verbessern, die Sie im Laufe Ihrer Karriere kontinuierlich einsetzen werden.

Wenn Sie viel mehr in der Schätzung arbeiten werden, kann ich zwei von Steve McConnells Büchern wärmstens empfehlen: Software Estimation: Demystifying the Black Art (konzentriert sich auf Schätzung als Kunst und Wissenschaft) und Rapid Development: Taming Wild Software Schedules (allgemeine Software) Engineering-Prozess und Projektmanagement-Themen).

Thomas Owens
quelle
7

Beziehen Sie sich auf Literatur. Es gibt einen riesigen Haufen komplexer und oft widersprüchlicher Materialien, die, wie die Praxis (Experimente) gezeigt hat, nicht wie erwartet funktionieren. Zumindest Akademiker werden von einem Stapel Bücher beeinflusst.

Muss gelesen werden: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Der Mythische Mann-Monat: Essays on Software Engineering ist ein Buch über Software-Engineering und Projektmanagement von Fred Brooks, dessen zentrales Thema darin besteht, dass "das Hinzufügen von Arbeitskräften zu einem späten Software-Projekt es später schafft". Diese Idee ist als Brooks'sches Gesetz bekannt und wird zusammen mit dem Zweitsystemeffekt und der Befürwortung von Prototypen vorgestellt.

Brooks 'Beobachtungen basieren auf seinen Erfahrungen bei IBM während der Entwicklung von OS / 360. Er hatte mehr Programmierer zu einem Projekt hinzugefügt, das hinter dem Zeitplan zurückblieb, eine Entscheidung, die er später widersprüchlich folgerte, um das Projekt noch weiter zu verzögern. Er machte auch den Fehler, zu behaupten, dass ein Projekt - das Schreiben eines ALGOL-Compilers - unabhängig von der Anzahl der beteiligten Mitarbeiter (die länger benötigt werden) sechs Monate dauern würde. Die Tendenz von Managern, solche Fehler in der Projektentwicklung zu wiederholen, veranlasste Brooks, den Titel seines Buches "The Bible of Software Engineering" zu zitieren, weil "alle zitieren, manche Leute es lesen und einige Leute es befolgen". Das Buch gilt weithin als Klassiker der menschlichen Elemente des Software-Engineerings ...

Jürgen Strobel
quelle
2

Finden Sie heraus, was sie mit dieser Schätzung vorhaben. In ihren Gedanken möchten sie wissen, ob es Monate oder Jahre dauern wird und Sie versuchen, die genauen Stunden zu ermitteln (Typischer Ingenieur).

Prüfen Sie, ob Sie an einem Teil des Projekts arbeiten können, und stellen Sie bei Bedarf eine bessere Schätzung zusammen.

Wenn sie weiter drängen, müssen Sie so viele Aufgaben wie möglich auflisten und einen Zeitrahmen festlegen. Sagen Sie ihnen, dass Sie sie informieren werden, sobald Sie etwas sehen, das sich auf die Schätzung auswirken könnte, und nehmen Sie Anpassungen vor. Die Leute versuchen normalerweise, Überraschungen zu vermeiden.

JeffO
quelle
1

Ich habe Leute getroffen, die behaupten, sie könnten Software schätzen, aber ich weiß nicht, wie sie das machen. Keiner von ihnen konnte erklären, wie sie es tun.

Als Berater verlangen meine Kunden oft, dass ich auf einer festen Gebotsbasis arbeite. Daher muss ich abschätzen, damit ich ein realistisches Angebot erstellen kann. Das ist mir noch nie gelungen. Man würde denken, ich würde so oft überbieten, wie ich unterbiete, aber das ist nie der Fall. Das Ergebnis ist, dass ich bei meinen Verträgen oft viel Geld verliere und am Ende viel weniger verdiene, als wenn ich als regulärer Angestellter in einem Unternehmen arbeiten würde.

Ich habe viele Jahre nach einem Buch gesucht, in dem ich lernen kann, wie man Software einschätzt, aber ich habe noch kein Buch gefunden.

Was die Erklärung für jemanden betrifft, der kein Programmierer ist. Sie könnten darauf hinweisen, dass niemand in der Branche konsequent in der Lage ist, seine Schätzungen zu erfüllen. Es kommt immer wieder vor, dass neue Softwareprodukte angekündigt werden, nur um Monate oder Jahre nach dem ursprünglich angekündigten Datum zu versenden.

Wenn ein großes Unternehmen wie Microsoft nicht herausfinden kann, wie viel Zeit für die Herstellung seiner eigenen Produkte aufgewendet wird, wie kann ich dann vorgehen?

Unabhängig davon, ob ich stundenweise oder beruflich bezahlt werde, erwarten meine Kunden immer, dass ich diese Schätzungen vorlege. Ich weiß nicht, wie sie von mir erwarten, dass ich sie erzeuge, wenn eine solche Schätzung nirgendwo gelehrt wird, und ich habe keine rationale Grundlage für meine Schätzungen.

Mike Crawford
quelle
1
Steve McConnells Buch "Software Estimation: Demystifying the Black Art" erklärt sehr gut, wie Softwareentwickler schätzen. Sie können Techniken und Werkzeuge erlernen, aber die einzige Möglichkeit, eine gute Schätzung zu erzielen, besteht darin, kontinuierlich zu schätzen, aus Ihren Schätzungen zu lernen und zu wiederholen. Da niemand ständig in der Lage ist, Schätzungen einzuhalten, gibt es Organisationen, die ihre Schätzungen regelmäßig um einige Prozentpunkte unterschreiten. In McConnells Buch geht es um Organisationen (häufig CMMI Level 4 oder 5, mit kontinuierlicher Verbesserung und detaillierter Nachverfolgung), die dies erreichen konsequent.
Thomas Owens
Wie für dein Problem mit schlechten Schätzungen. Verfolgen Sie Ihre Schätzung im Vergleich zur tatsächlichen Zeit bis zur Fertigstellung? Wenn ja, bestimmen Sie, mit welchem ​​Faktor Sie alle Ihre Schätzungen unterschätzen, und multiplizieren Sie sie mit dieser Zahl.
Kubi
0

Die Schätzung der gesamten Projektzeit wird normalerweise vom Projektmanager und nicht vom Programmierer vorgenommen.

Sie können ein Argument erstellen, das auf der Tatsache basiert, dass der Projektmanager über die vollständige Liste der erforderlichen Aufgaben verfügt. Ohne diese Liste wird jede Schätzung eine "schlechte" Vermutung sein.

Außerdem hängt die Zeit von vielen Faktoren ab, z. B. von der Anzahl der verfügbaren Personen und dem Umfang der Anforderungen, die Sie nicht angegeben haben. Architektur allein reicht nicht aus.

Keine Chance
quelle
Abhängig von der Projektmanagementmethode verfügt der PM möglicherweise nicht über die vollständige Liste der Aufgaben. In so etwas wie Rolling Wave-Projektmanagement gibt es oft einen nebligen Bereich, der ein sehr hohes Maß an Aufgaben beschreibt, das im Allgemeinen zu groß ist, um es mit einem angemessenen Vertrauensniveau abzuschätzen. Wenn frühere Aufgaben erledigt sind, sind die Aufgaben in diesem Bereich klarer definiert und können geschätzt werden. Bei agilen Methoden werden Aufgaben häufig an verschiedenen Stellen hinzugefügt, entfernt oder neu priorisiert, was es wiederum schwieriger macht, langfristige Meilensteine ​​über ein paar Iterationen hinaus abzuschätzen.
Thomas Owens
0

Ein weiterer Punkt, den Sie ansprechen könnten, ist, dass das Software-Engineering im Vergleich zu anderen technischen Bereichen noch in den Kinderschuhen steckt und nicht ausgereift genug ist, um abschätzbare Entwicklungstechniken zu entwickeln.

Auch das Software-Engineering ist in ständigem Wandel. Wenn eine Technologie ausgereift genug ist, um als ausgereift zu gelten, wird sie häufig zugunsten einer neuen Technologie aufgegeben. Dies verhindert, dass jemand genug Erfahrung mit einer Technologie sammelt, um verlässliche Schätzungen erstellen zu können.

Vergleichen Sie dies mit der Konstruktionsabschätzung. Das ist ein sehr gut verstandenes Problem, nicht nur, weil Aufträge auf der Grundlage von Angeboten vergeben werden, sondern auch, weil die Menschheit seit den Anfängen der Zivilisation Dinge aufgebaut hat.

Mike Crawford
quelle
1
Software Engineering ist mit 42 Jahren (bei weitem) noch jünger als die meisten anderen Ingenieurdisziplinen. Es gibt jedoch eine Reihe ausgereifter Schätztechniken und -werkzeuge. Breitband-Delphi (entwickelt in den 1970er Jahren, bekannt geworden durch Barry Boehms Software Engineering Economics im Jahr 1981), Funktionspunkte (1979), SEER-SEM (Wurzeln in den 1960er Jahren), Proxy-basierte Schätzung (verwendet in der PSP, entwickelt 1994 bei die SEI) und COCOMO (1981) und COCOMO II (1997). Auf einem Gebiet, das nur 42 Jahre alt ist, wird bereits seit fast 40 Jahren an der Schätzung von Projekten gearbeitet.
Thomas Owens