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

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 ?

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 .

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).

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 ...

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.

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.

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.

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.