Das Institut unterrichtet Algorithmen, Datenstrukturen, OOP. In einem guten Fall können sie über Entwurfsmuster oder Multithread-Programmierung sprechen. Ich habe jedoch nicht gehört, wie die Arbeitskosten richtig bewertet werden können.

Mittlerweile braucht jeder Programmierer diese Fähigkeit jeden Tag. Es gibt immer mehr Arbeit als getan werden kann. Die Evaluierung hilft dabei, Prioritäten richtig zu setzen und einige Aufgaben ganz aufzugeben. Ganz zu schweigen von Haushaltsfragen wie Budgetierung und Planung. Falsche Schätzungen führen im Gegenteil zu einer Reihe von Problemen: unterschätzt - Konfliktsituationen, Verarbeitung und Lücken in den Budgets, überbewertete - Projekte stornieren oder nach anderen Künstlern suchen.

Fairerweise sollte beachtet werden, dass eine Unterbewertung in der Entwicklung weitaus häufiger vorkommt. Warum? Jemand hält Programmierer für zu optimistisch . Ich werde noch einen Grund hinzufügen: Ein guter Programmierer und ein guter Gutachter zu sein, ist nicht dasselbe. Um ein guter Programmierer zu werden, reicht ein Wunsch nicht aus. Benötigen Sie Wissen und Übung. Warum sollte die Bewertung anders sein?

In dem Artikel werde ich darüber sprechen, wie sich meine Einstellung zur Bewertung von Aufgaben geändert hat und wie Projekte in unserem Unternehmen bewertet werden. Und ich beginne damit, wie Sie nicht bewerten müssen. Wenn Sie bereits wissen, wie Sie dies nicht tun, fahren Sie direkt mit dem zweiten Teil des Artikels fort .

Anti-Evaluierungsmuster

Die meisten Bewertungen in Projekten werden zu Beginn ihres Lebenszyklus vorgenommen. Und das stört uns erst, wenn wir verstehen, dass die Schätzungen früher als die Anforderungen ermittelt wurden und dementsprechend früher als die Aufgabe selbst untersucht wurde. Folglich wird eine Bewertung normalerweise nicht rechtzeitig durchgeführt. Dieser Prozess wird zu Recht nicht als Bewertung, sondern als Vermutung oder Vorhersage bezeichnet, da jeder Punkt in den Anforderungen ein Ratespiel ist. Inwieweit wirkt sich diese Unsicherheit auf die Endergebnisse der Bewertung und deren Qualität aus?

Eine Kleinigkeit, aber unangenehm

Angenommen, Sie entwickeln ein Auftragserfassungssystem, konnten jedoch noch keine Anforderungen für die Eingabe von Telefonnummern entwickeln. Unter den Unsicherheiten, die sich auf die Bewertung des Programms auswirken können, können wir sofort Folgendes hervorheben:

Muss der Kunde die eingegebene Telefonnummer auf Gültigkeit prüfen?
Wenn der Kunde ein System zur Überprüfung der Telefonnummer benötigt, welche Version wird er bevorzugen - billig oder teuer?
Wenn Sie eine kostengünstige Version zum Überprüfen von Telefonnummern implementieren, möchte der Kunde später zu der teuren wechseln?
Ist es möglich, ein vorgefertigtes System zum Überprüfen von Telefonnummern zu verwenden, oder müssen Sie aufgrund einiger Designbeschränkungen Ihr eigenes entwickeln?
Wie wird das Verifizierungssystem aufgebaut?
Wie lange dauert es, ein System zur Überprüfung der Telefonnummer zu programmieren?

Und dies sind nur einige Fragen aus der Liste, die sich im Kopf eines erfahrenen Projektmanagers stellen ... Wie auch aus diesem Beispiel hervorgeht, können sich potenzielle Unterschiede bei der Definition, Gestaltung und Implementierung derselben Opportunities summieren und die Implementierungszeit um das Hundertfache oder mehr verlängern. Und wenn wir sie in Hunderten und Tausenden von Funktionen eines großen Projekts kombinieren, erhalten wir enorme Unsicherheit bei der Bewertung des Projekts selbst.

Ein weiteres hervorragendes Beispiel für eine „Schwellung“ scheint eine elementare Voraussetzung zu sein. Lesen Sie dazu den Artikel „ Wie sind zwei Wochen ?! “.

Kegel der Unsicherheit

Die Softwareentwicklung - und viele andere Projekte - besteht aus Tausenden von Lösungen. Die Forscher fanden heraus, dass Projektschätzungen in verschiedenen Phasen der projizierten Unsicherheit inhärent sind. Der Unsicherheitskegel zeigt, dass Schätzungen im Verlauf des Projekts genauer werden. Bitte beachten Sie, dass in der Phase des ursprünglichen Konzepts (in der häufig Schätzungen vorgenommen und Verpflichtungen eingegangen werden) der Fehler 400% betragen kann (vierhundert Prozent, Karl!). Es ist optimal, nach Abschluss des detaillierten Entwurfs Verpflichtungen einzugehen.

Mythischer Mannmonat

Es gibt immer noch Führungskräfte, die der Meinung sind, dass bei einer festen Festlegung der Funktionalität jederzeit eine Verkürzung der Zeit erreicht werden kann, indem Mitarbeiter hinzugefügt werden, die mehr Arbeit in kürzerer Zeit erledigen würden. Der Fehler dieser Argumentation liegt in der Maßeinheit, die bei der Bewertung und Planung verwendet wird: Mannmonat. Die Kosten werden wirklich als Produkt der Anzahl der Mitarbeiter und der Anzahl der aufgewendeten Monate gemessen. Das Ergebnis wird jedoch nicht erreicht. Daher ist die Verwendung von Mannmonaten als Maßeinheit für das Arbeitsvolumen ein gefährliches Missverständnis. Alle Forscher waren sich einig, dass die Verkürzung der Nenndauer den Gesamtarbeitsaufwand erhöht. Wenn die nominelle Amtszeit für eine Gruppe von 7 Personen 12 Monate beträgt, wird eine einfache Erhöhung des Personals auf 12 Personen den Zeitraum nicht auf 7 Monate verkürzen.

In großen Gruppen steigen die Kosten für Koordination und Management und die Anzahl der Kommunikationswege steigt. Wenn alle Teile der Aufgabe getrennt voneinander koordiniert werden müssen, steigen die Kommunikationskosten quadratisch und die „Leistung“ des Teams linear. Drei Arbeiter benötigen dreimal so viel paarweise Kommunikation wie zwei, vier für sechs.

Bild

Das Projektteam versucht, mit den Hinterteilen fertig zu werden // Ivan Aivazovsky, 1850

Wenn 8 Personen in 10 Monaten ein Programm schreiben können, können 80 Personen in einem Monat dasselbe Programm schreiben? Die Ineffizienz extremer Verschärfungsfristen wird besonders in extremen Fällen deutlich - beispielsweise bei 1.600 Personen, die an einem Tag ein Programm schreiben müssen. Lesen Sie mehr darüber im gleichnamigen Buch von Frederick Brooks .

Bewertungsmuster

Mit den Problemen ist also alles klar. Was kann getan werden?

Zersetzung

Anstatt eine große Aufgabe zu bewerten, ist es besser, sie in viele kleine Aufgaben zu unterteilen, sie zu bewerten und die Abschlussnote als Summe der Anfangsnoten zu erhalten. So töten wir sofort bis zu vier Fliegen mit einer Klappe:

Wir verstehen den Arbeitsumfang besser. Um eine Aufgabe zu zerlegen, müssen Sie die Anforderungen lesen. Unerklärliche Orte entstehen sofort. Das Risiko einer Fehlinterpretation von Anforderungen wird verringert.
Während der Analyse einer detaillierteren Analyse der Anforderungen beginnt automatisch der Denkprozess der Systematisierung von Wissen. Dies verringert das Risiko, einen Teil der Arbeit zu vergessen, z. B. Refactoring, Testautomatisierung oder den zusätzlichen Aufwand für das Layout und die Bereitstellung
Das Zerlegungsergebnis kann für das Projektmanagement verwendet werden, sofern für beide Prozesse ein Tool verwendet wurde (dieses Problem wird später im Text ausführlicher behandelt).
Wenn wir den durchschnittlichen Fehler der Schätzung jedes während der Zerlegung erhaltenen Problems messen und diesen Fehler mit dem Fehler der Gesamtschätzung vergleichen, stellt sich heraus, dass der Gesamtfehler kleiner als der Durchschnitt ist. Mit anderen Worten, eine solche Bewertung ist genauer (näher an den tatsächlichen Arbeitskosten). Diese Aussage ist auf den ersten Blick kontraintuitiv. Wie kann die endgültige Bewertung genauer sein, wenn wir bei der Bewertung jedes zerlegten Problems einen Fehler machen? Betrachten Sie ein Beispiel. Um ein neues Formular zu erstellen, müssen Sie: a) den Code in das Backend schreiben, b) das Layout erstellen und den Code in das Frontend schreiben, c) testen und auslegen. Aufgabe A wurde nach 5 Stunden bewertet, Aufgaben B und C nach jeweils 3 Stunden. Die Gesamtpunktzahl betrug 11 Stunden. In Wirklichkeit war das Backend in 2 Stunden fertig, das Formular dauerte 4 Stunden und das Testen und Beheben von Fehlern dauerte weitere 5. Die Gesamtarbeitslast betrug 11 Stunden. Ideal um bewertet zu werden. Darüber hinaus beträgt der Fehler bei der Bewertung von Aufgabe A 3 Stunden, Aufgabe B 1 Stunde und C 2 Stunden. Der durchschnittliche Fehler beträgt 3 Stunden. Tatsache ist, dass sich die Fehler, die Schätzungen zu unterschätzen und zu überschätzen, gegenseitig aufheben. Die 3 Stunden, die im Backend eingespart wurden, kompensierten die Verzögerung von 1 und 2 Stunden im Frontend und in der Testphase. Die tatsächliche Arbeit ist eine Zufallsvariable, die von vielen Faktoren abhängt. Wenn Sie krank werden, fällt es Ihnen schwer, sich zu konzentrieren, und statt drei Stunden kann es sechs dauern. Oder es tritt ein unerwarteter Fehler auf, der den ganzen Tag gesucht und behoben werden muss. Umgekehrt kann sich herausstellen, dass Sie anstelle des Schreibens einer eigenen Komponente eine vorhandene usw. verwenden können. Positive und negative Abweichungen heben sich gegenseitig auf. Somit nimmt der Gesamtfehler ab.

Funktionen und Aufgaben

Das Herzstück unserer Zerlegung ist Feature. Ein Feature ist eine Einheit zur Bereitstellung von Funktionen, die unabhängig von anderen in Produktion gehen kann. Manchmal wird diese Ebene als User Story bezeichnet, aber wir sind zu dem Schluss gekommen, dass User Story nicht immer gut zum Festlegen von Aufgaben geeignet ist, und haben uns daher für eine allgemeinere Formulierung entschieden.

Ein Mitglied ist für eine Funktion verantwortlich. Jemand kann ihm bei der Implementierung helfen, aber eine Person geht zum Testen über. Die Aufgabe wird ihm auch zur Überarbeitung zurückgegeben. Abhängig von der Organisation des Teams kann dies ein Teamleiter oder direkt ein Entwickler sein.

Leider gibt es manchmal große Funktionen. Es wird sehr lange dauern, allein an einem solchen Volume zu arbeiten. Und für eine lange Zeit müssen Sie den Akzeptanzprozess testen und implementieren. Dann ändern wir die Art der Aufgabe in Epic. Epic ist nur ein sehr dickes Feature. Wir beginnen nichts weiter als ein Epos. Das heißt, Epen können einfach groß, riesig oder gigantisch sein. In jedem Fall wird das Epos in Teilen (Features) an die Annahme gesendet.

Zur genaueren Auswertung werden Features in separate Unteraufgaben (Task) zerlegt. Ein Feature könnte beispielsweise die Entwicklung einer neuen CRUD-Schnittstelle sein. Die Struktur der Aufgaben kann folgendermaßen aussehen: "Tabelle mit Daten anzeigen", "Filterung und Suche beschleunigen", "Neue Komponente entwickeln", "Neue Tabellen zur Datenbank hinzufügen". Die Struktur der Aufgaben ist normalerweise für das Geschäft überhaupt nicht interessant, aber für den Entwickler äußerst wichtig.

Auswertung in Gruppen, Pokerplanung

Programmierer sind zu optimistisch in Bezug auf den Arbeitsaufwand. Nach verschiedenen Quellen schwankt die Unterbewertung meist im Bereich von 20 bis 30%. In Gruppen wird der Fehler jedoch reduziert. Dies ist auf eine bessere Analyse aufgrund unterschiedlicher Sichtweisen und die Bewertung des Temperaments zurückzuführen.
Die häufigste Praxis mit der wachsenden Popularität von Agile ist die Praxis der „ Pokerplanung “. Mit der Gruppenbewertung sind jedoch zwei Probleme verbunden:

Sozialer Druck
Zeitkosten

Sozialer Druck

In fast jeder Gruppe variieren die Erfahrung und die persönliche Effektivität der Teilnehmer. Wenn das Team ein starkes Team / eine starke Technologie hat - den Lead / Lead-Programmierer - fühlen sich andere Mitglieder möglicherweise unwohl und unterschätzen absichtlich die Noten: „Nun, wie kann Vasya das tun, aber bin ich schlechter? Das kann ich auch! “ Die Gründe können unterschiedlich sein: der Wunsch, besser zu wirken als es wirklich ist, Wettbewerb oder einfach nur Konformismus. Das Ergebnis ist eines: Eine Gruppenbewertung verliert alle ihre Vorteile und wird individuell. Timlid gibt Noten, und der Rest stimmt ihm einfach zu.

Ich habe lange Zeit Druck auf das Team ausgeübt, um Bewertungen zu erhalten, die meinen Erwartungen besser entsprechen. Dies führte ausnahmslos zu einer Qualitätsminderung und einer Aufschlüsselung. Infolgedessen habe ich meine Einstellung geändert und jetzt ist meine Bewertung oft die größte. Während der Diskussion weise ich auf mögliche Probleme hin, die mir in den Sinn kommen: „Hier würde Refactoring nicht schaden, hier ändert sich unsere Datenbankstruktur, es wäre notwendig, einen Regressionstest durchzuführen.“

Es gibt mehrere Hauptempfehlungen:

Die meisten Bewertungen werden unterschätzt. Sie können nicht zwischen zwei Bewertungen wählen? Nimm den, der größer ist.
Nicht sicher über die Bewertung - werfen Sie die Karte "?" oder eine tolle Bewertung. Vielleicht fast nie trägt.
Vergleichen Sie immer Plan und Fakten. Wenn Sie wissen, dass Sie nicht zweimal passen, geben Sie eine Schätzung an, die doppelt so hoch ist wie Sie denken. Begonnen zu übertreiben? Multiplizieren Sie in Ihrem Kopf mit eineinhalb. Nach einigen Iterationen sollte sich die Qualität Ihrer Noten erheblich verbessern.

Zeitkosten

Sie kennen den Satz "Wollen Sie arbeiten?" Treffen Sie sich! “ Ein Programmierer versucht nicht nur, die Zukunft vorherzusagen, anstatt Code zu schreiben. Jetzt macht es die ganze Gruppe. Darüber hinaus ist das Ausarbeiten einer Entscheidung in einer Gruppe ein viel längerer Prozess als das Treffen einzelner Entscheidungen. Daher ist die Gruppenbewertung ein äußerst kostspieliger Prozess. Es lohnt sich, diese Kosten von der anderen Seite zu betrachten. Zunächst muss die Gruppe im Bewertungsprozess die Anforderungen erörtern. Dies bedeutet, dass Sie sie lesen müssen. Schon nicht schlecht. Zweitens vergleichen wir diese Kosten mit denen, die dem Unternehmen aufgrund einer Unterschätzung des Projekts entstehen.

Vor vielen Jahren, an einem Novembertag, wechselte ich meinen Job zu einer großen Firma. Mir wurde sofort klar, dass die Arbeit in vollem Gange war. Die Hälfte des Unternehmens arbeitete daran, das Produkt vor Jahresende herauszubringen. Aber nach ungefähr einer Woche schien es mir, dass sie bis Ende des Jahres keine Zeit mehr haben würden. Mit jedem nächsten Tag wurden die Erfolgschancen dieses Unternehmens immer illusorischer ... Das Projekt wurde wirklich im Dezember, wenn auch schon im nächsten Jahr, umgesetzt. Das habe ich viel später erfahren, weil im Sommer Probleme mit der Zahlung von Löhnen an Mitarbeiter begannen und ich zusammen mit etwa der Hälfte der Mitarbeiter kündigte. Man kann sagen: "Natürlich sind Manager Dummköpfe, man musste auf Nummer sicher gehen." Sie haben sich versichert. Sechs Monate gab es keine Probleme mit der Zahlung von Löhnen. Es ist keine leichte Aufgabe, ein halbes Jahr lang ein Betriebskapital zu halten. Ich denke, wenn die Bewertung genauer wäre, gäbe es andere Managemententscheidungen auf der obersten Managementebene.

Wenn wir die Investition in die Bewertung als Investition in die Annahme solider Managemententscheidungen betrachten, dann scheinen sie nicht mehr so teuer zu sein. Gruppengröße ist eine andere Sache. Natürlich muss nicht das gesamte Team gezwungen werden, den gesamten Arbeitsaufwand zu bewerten. Es ist viel vernünftiger, die Aufgabe in ~~Module~~ , Ahem, Mikrodienste zu unterteilen und den Teams Autonomie zu geben. Verwenden Sie auf einer höheren Ebene die Schätzungen jedes Teams, um einen Projektplan zu erstellen. Das bringt uns reibungslos zum Thema des nächsten Absatzes.

Abhängigkeitslayout, Gantt-Diagramme

Wenn Programmierer normalerweise Bewertungen abgeben, ist die Erstellung eines Projektplans das Los der mittleren Manager. Denken Sie daran, ich habe geschrieben, dass diesen Leuten geholfen werden kann, wenn ein Werkzeug für die Zerlegung und das Projektmanagement verwendet wird. Auswertung und Kalenderzeit sind nicht dasselbe. Um beispielsweise eine einfache Datentabelle anzuzeigen, benötigen Sie:

DB-Tabelle
Backend-Code
Frontend-Code

Das Ausführen von Aufgaben in dieser Reihenfolge ist aus technischer Sicht am einfachsten. In der Realität gibt es jedoch unterschiedliche Spezialisierungen. Ein Front-End-Spezialist kann früher freigegeben werden. Anstatt untätig zu sein, ist es logischer, mit der Entwicklung der Benutzeroberfläche zu beginnen, indem die Serveranforderung durch Schein- oder fest codierte Daten ersetzt wird. Wenn die API fertig ist, muss der Code nur noch durch einen Aufruf einer realen Methode ersetzt werden ... theoretisch. In der Praxis kann das maximale Maß an Parallelität wie folgt erreicht werden:

Zuerst prahlen wir schnell, um uns auf die API-Spezifikation zu einigen
Codieren Sie dann die Daten auf der Rückseite oder auf der Vorderseite fest, je nachdem, wer zur Hand ist.
Gleichzeitig machen wir Datenbank, Backend und Frontend. Die Datenbank und das Backend blockieren sich teilweise gegenseitig, aber meistens werden diese Kompetenzen in einer Person zusammengefasst und die Arbeit läuft tatsächlich nacheinander ab: zuerst eine Datenbank, dann ein Backend
Wir sammeln alles und testen
Wir beheben Fehler und testen erneut

Es ist wichtig, dass die Schritte 1, 4 und 5 so schnell wie möglich ausgeführt werden, um die Anzahl der Sperren zu verringern. Neben technologischen Einschränkungen und Einschränkungen bei der Verfügbarkeit von Spezialisten mit der erforderlichen Kompetenz gibt es noch geschäftliche Prioritäten! Und das bedeutet, dass nach drei Wochen eine Demonstration für einen wichtigen Kunden geplant ist und er auf die erste Hälfte Ihres Projektplans spucken wollte. Er möchte das Endergebnis sehen, das frühestens zwei Monate später vorliegen wird. Nun, dann müssen Sie einen separaten Plan für diese Demonstration erstellen. Wir ergänzen den Plan, um die erforderlichen Datenbankdaten einzuschlagen, neue Links für Übergänge zur Benutzeroberfläche einzufügen usw. Es ist auch wünschenswert, dass am Ende 20% des Codes und nicht alle diese Demonstrationen weggeworfen werden mussten.

Das künstlerische Schneiden eines solchen Plans ist keine leichte Aufgabe. Das Erstellen von Abhängigkeiten vereinfacht den Prozess erheblich. Bevor Sie mit dem Berichtsmodul fortfahren, müssen Sie ein Dateneingabemodul erstellen. Ist es logisch? Fügen Sie eine Abhängigkeit hinzu. Wiederholen Sie dies für alle zugehörigen Aufgaben. Glauben Sie mir, viele der Abhängigkeiten werden Sie überraschen.

Bei der Automatisierung von Geschäftsprozessen erhält man normalerweise mehrere lange „Schlangen“ verwandter Aufgaben mit mehreren großen Sperrknoten. In den meisten Fällen ist der ursprüngliche Plan in Bezug auf die Ressourcennutzung nicht effektiv und / oder in Bezug auf den Kalender zu lang. Eine Überarbeitung der Bewertung der Arbeitskosten wird schneller erfolgen - keine Option. Die Einschätzung ist daher höchstwahrscheinlich optimistisch. Wir müssen zur Zersetzung zurückkehren, nach zu langen Ketten suchen und zusätzliche „Gabeln“ hinzufügen, um den Grad der Parallelität zu erhöhen. Aufgrund eines Anstiegs der Gesamtarbeitskosten (mehr Menschen arbeiten gleichzeitig an einem Projekt) wird der Kalenderzeitraum des Projekts verkürzt. Erinnerst du dich an den "mythischen Mannmonat"? Es ist unwahrscheinlich, dass ein Plan um mehr als 30% schrumpft. Damit das Budget und die Frist übereinstimmen, kann der Plan mehrmals überprüft werden. Es gibt verschiedene Tricks, um den Prozess schneller und einfacher zu machen.

Task-Sperre

Den ersten Grund für das Blockieren - Abhängigkeiten - haben wir bereits berücksichtigt.Darüber hinaus kann es einfach zu unverständlichen / ungenauen Anforderungen kommen. Ein Tool wird benötigt, um Aufgaben zu blockieren und Fragen zu stellen. Mit der Spezifikation der Anforderungen können Sie Aufgaben entsperren und die Note anpassen. Dieser Prozess läuft übrigens fast immer während des Projekts ab und nicht davor.

Der kritische Weg birgt Risiken

. , ( ), , , , . , , , , , , . , .

Kurz gesagt, wenn Sie mit der Struktur der Datenbank durcheinander kommen, müssen Sie die Rückseite neu schreiben, die Last nicht berechnen, möglicherweise müssen Sie die Technologie insgesamt ändern. Ich habe im Artikel " Cost Effective Code " ausführlich über die Risiken von Designarbeiten geschrieben . Je früher die Risiken auf dem kritischen Pfad eintreten, desto besser. Immerhin ist noch Zeit und es kann etwas getan werden. Noch besser, wenn sie überhaupt nicht zustande kommen, aber seien wir realistisch.

Daher müssen Sie mit den schlammigsten, komplexesten und unangenehmsten Aufgaben beginnen, sie in den Status „blockiert“ versetzen und Abhängigkeiten klären, neu bewerten und entfernen, wo immer dies möglich ist.

Akzeptanzkriterien, Testfälle

Natürliche Sprache: Russisch, Englisch oder Chinesisch - egal - es kann sowohl überflüssig als auch ungenau sein. Testfälle überwinden diese Einschränkungen. Es ist auch ein gutes Kommunikationsinstrument zwischen Entwicklern, Geschäftsanwendern und der Qualitätsabteilung.

Projektmanagement

Willst du Gott zum Lachen bringen? Erzähl ihm von deinen Plänen. Selbst wenn ein Wunder passiert ist und Sie vor Arbeitsbeginn alle Anforderungen gesammelt und geklärt haben, Sie über genügend kompetente Mitarbeiter verfügen, der Plan es Ihnen ermöglicht, den größten Teil der Arbeit parallel zu erledigen, sind Sie immer noch nicht immun gegen Krankheiten der Mitarbeiter, Fehler bei der Bewertung und Umsetzung anderer Risiken. Daher ist es notwendig, den Plan regelmäßig zu aktualisieren und mit der Tatsache zu vergleichen. Und dafür ist die Berücksichtigung der Arbeitszeit wichtig.

Zeiterfassung oder Zeiterfassung

Zeit und Anwesenheit sind seit langem der De-facto-Standard in der Branche. Es ist äußerst wünschenswert, dass es im selben Tool wie die Bewertung erstellt wird. Auf diese Weise können Sie die Abweichung der tatsächlich verbrachten Zeit von der geschätzten Zeit verfolgen. Es ist gut, wenn dieses Tool auch vom Projektmanager verwendet wird. Dann werden alle Verzögerungen des kritischen Pfades sofort spürbar. Eine Variante mit verschiedenen Werkzeugen ist ebenfalls möglich, erfordert jedoch erheblich höhere Arbeitskosten für die Wartung des Prozesses, was bedeutet, dass die Versuchung besteht, herumzuspielen. Wir wissen bereits, wie das endet. Wir verwenden YouTrack . Alles, worüber ich in dem Artikel geschrieben habe, ist derzeit sofort verfügbar, obwohl es ein wenig optimiert werden muss.

Fazit

Die Bewertung ist schwierig
Durch die Zerlegung können Sie Lücken in den Anforderungen finden und die Qualität der Bewertung verbessern
Gruppenbewertungen sind genauer als einzelne, verwenden Sie Poker
Blocker, Testfälle und formale Akzeptanzkriterien verbessern die Kommunikation, was wiederum die Erfolgschancen des Projekts erhöht
Sie müssen mit den riskantesten Aufgaben auf dem kritischen Pfad des Projekts beginnen
Evaluation ist keine einmalige Aktion, sondern ein vom Projektmanagement untrennbarer Prozess
Ohne Berücksichtigung der Arbeitszeit ist es unmöglich, den Projektstatus auf dem neuesten Stand zu halten und Ihre Schätzungen anzupassen

Möchten Sie mehr über die Projektevaluierung erfahren?

Lesen Sie das Buch von Steve McConnell " Wie viel kostet ein Softwareprojekt? " Und andere Artikel zu diesem Thema über Habr

Informationen zur Evaluierung und Verwaltung der Softwareproduktentwicklung