Bewertung und Planung in Softwareprojekten - ohne Kürzungen

    Guten Tag Freunde!

    Wir führen eine Reihe von „No-Bills“ -Publikationen über entwicklungsbezogene Projekte fort, häufig mit dem Präfix „Web“. Heute werden wir darüber sprechen, wie man Arbeitsauswertungen am schnellsten und schnellsten durchführt und Releases eines Softwaresystems plant. Neulinge Manager und energische und selbstsüchtige Entwickler werden höchstwahrscheinlich von den Empfehlungen geschockt sein. Aber glauben Sie mir, es gibt ein Ziel und nur ein Ziel: Ihnen zu einem echten Jedi zu verhelfen, der Unternehmen Vorteile bringt, Projekte bewegt und gleichzeitig Menschen entwickelt. Ein solcher Jedi, der es aufrichtig nicht verdient, als Mumie in einem dunklen Server zwischen den Racks mit Webservern und Datenbanken eines Webprojekts entdeckt zu werden, das ohne einen mental dokumentierten Code in die Zukunft fliegt, ist die TK nur mit der Energie des reinen "X". Also lass uns gehen!

    Leistung und nahe Analoga


    Es ist wichtig, extrem wichtig, vor allem die Schlüsselstärke des Projekts - für Entwickler, exzellente Spezialisten, die täglich ihre Fähigkeiten in modernen IDEs abschütteln, um zu verstehen, dass der Mangel an gesundem Menschenverstand bei der Bewertung der Arbeit bereits vor dem Wunsch beginnt, eine „Idee“ zu entwickeln. Besonders häufig geschieht dies in der Webentwicklung, wo Sie während der Ausschreibung das politisierte Problem von Hühnchen und Eiern als "strenge Lösung" betrachten müssen.

    1. Der Kunde weiß immer noch nicht, was er will, oder er weiß sehr vage und widersprüchlich (das heißt, er weiß es nicht, aber er will und vor allem pünktlich!)
    2. Der Kunde möchte, dass die Ingenieure die Kosten für "Ich weiß noch nicht was noch?" Berechnen.
    3. Der Kunde möchte, dass die Ingenieure sich an die Fristen halten und "Ich weiß nicht, was noch nicht ist", beispielsweise am 1. September, einführen, und dass "natürlich nicht wissen, was noch nicht ist" keine Fehler enthalten
    4. Die Klienten delegieren häufig die Details zu "Ich weiß nicht, was noch nicht" in der Hierarchie an Mitarbeiter, die überraschenderweise anfangen, "Verstecken und Suchen des Geistes" zu spielen, sie auszulachen, sich mit einem Bein zu mischen, die Tür zuzuschlagen und das Gummi zu ziehen!

    Es wird etwas einfacher, wenn Sie nahe Analogien zu der oben beschriebenen merkwürdigen Leistung in der umgebenden Natur finden:
    1. schöne umwerbung des männlichen zum weiblichen ... häusliche demontage in der küche
    2. Kartoffeln auf dem Markt kaufen
    3. Wahrsagen, Astrologie, Numerologie
    4. Cthulhu-Opfer usw.



    Es ist klar, dass es bisher nicht einfacher geworden ist, insbesondere wenn wir uns daran erinnern, dass "zertifizierte Psychologen" auf beiden Seiten oft an der Aufführung teilnehmen, überzeugend und entschlossen aussehen können und "Ja, natürlich tun!" Und die Grundprinzipien der Softwareentwicklung nicht verstehen. Und wenn Sie sich daran erinnern, dass manchmal „zuversichtlich“ an beiden Enden des Projekts die Frontlinie überquert, sich verbrüdert, sich zusammenschließen und anfangen, ehrlich empört etwas Spezifisches von Ingenieuren zu fordern, ohne klar formale Antworten auf klar gestellte Fragen zu geben ... - Ich möchte nur zu akademische Feiertage in der Antarktis und vergessen, Pinguine und kaltes Wasser umarmen, aber nicht weniger schön, Meerjungfrauen :-)

    Push der Liebe


    Die oben beschriebene Leistung wird von den Ingenieuren nüchtern und analytisch streng bis zum Punkt der Blutung aus den Augen wahrgenommen. Daher führen sie mehrere bekannte psychologische Schritte aus, die sich den Besonderheiten und der tatsächlichen Arbeit annähern:

    • Sie müssen sich anlächeln
    • Muss ja sagen, auch wenn KEIN Vertrauen besteht
    • Wir müssen versprechen, einander zu helfen
    • Sie müssen sich auf die Brust klopfen (wie KinKong) und Vertrauen zeigen!
    • Muß in der Liebe ins Grab schwören

    Aber im Ernst, es ist zu diesem Zeitpunkt notwendig, alle Mitglieder des Projektteams sehr klar zu erkennen:

    • dass es immer noch die Details zu verstehen gibt und viele interessante und unerwartete Pop-ups, aber wenn Sie sich erst einmal anlächeln, werden Sie es schaffen, es gemeinsam zu lösen
    • Wenn die Frist festgelegt ist, müssen Sie das emotionale Chaos so schnell wie möglich aufdecken, die wichtigsten Dinge über die absteigenden Dinge abschätzen und anfangen, etwas zu tun, und es wird immer etwas nicht gemacht, und dies ist richtig
    • Je emotionaler und politischer Brei am Anfang, desto mehr Zeit muss der Analyse- und Designphase zugewiesen werden

    Am Ende der Aufführung sollte also ein ständiger Vorstoß in eine unbekannte Zukunft und eine gute, fröhliche Stimmung und das gemeinsame Verlangen, einander zuzuhören und zu hören, folgen.



    "Totgeborene" Projekte


    Leider ist manchmal buchstäblich sofort klar, dass das Projekt, das gestartet wird, niemand braucht, es zuckt, friert und wird ins Archiv geworfen:

    • Das Projekt hat kein klares, charismatisches Ziel. Sie müssen nur etwas tun, denn es ist nicht klar, was wichtiger ist. Deshalb musst du mindestens ALLES tun, das Gehalt wird berechnet - es muss einen Grund geben :-)
    • Es werden Versuche unternommen, nicht die „Motoren“ des Projektteams zu finden, energische Menschen, die sich und andere inspirieren und an das Erreichen des Ziels glauben, sondern die Verantwortlichen suchen (die bei Problemen für alles verantwortlich gemacht werden können). Fühle den Unterschied.



    Effektive Arten von Aufführungen


    Es ist erfreulich, aber oft gibt es auch regelmäßige Projektanläufe, die sich durch die folgenden Zeichen unterscheiden. Halten Sie sich an diese Liste und versuchen Sie, solche Befehle per Haken oder durch Gauner zu erreichen:

    • Es gibt einen oder mehrere Leute, die vor Ideen brennen und aufrichtig an das Erreichen des Ziels glauben. Die Ausstrahlung und Wärme, die von ihnen ausgeht, ermöglichen es dem Projektteam, flexibel zu sein und Missverständnisse und Missverständnisse auszuräumen.
    • Auf Kundenseite besteht ein ausreichendes Bewusstsein für die Unsicherheit der eigenen Wünsche, Risiken und den Wunsch, Ingenieure zu treffen. Es besteht das Bewusstsein, dass Sie Ihren Kopf viele Male belasten und denken müssen, auch wenn Sie als Kunde bereits alles bezahlt haben.
    • Auf Kundenseite gibt es entweder oder ... Es gibt ein Verständnis für die Notwendigkeit, eine kritische Masse grauer Materie in Form adäquater Analysten und Fachexperten anzulocken, die in der Lage sind, die Feinheiten der bevorstehenden Geschäftslogik ohne "e ... s ... wow ..." zu erklären. Projekt.
    • Auf Kundenseite besteht der Wunsch, Geschäftsziele auf kürzestem und schnellstem Weg zu erreichen. Ich erinnere mich an das Projekt, bei dem der Kunde viel Zeit mit einem „schönen, cleveren Website-Administrationsbereich“ für Mitarbeiter verbringen wollte und die an der Oberfläche liegenden geschäftlichen Probleme ernsthaft übersehen hatte.

    Aber denken Sie daran - ein Treffen mit einem derartig vorbereiteten Kunden bedeutet für das Ingenieurteam, von den versprochenen IT-Himmeln, Schweiß, Arbeit und Blut abzukommen. Alle Kenntnisse über Entwurfsmuster werden aus Ihnen herausgerüttelt, sie werden Sie lehren, einfachen Code sofort ohne Fehler zu schreiben, und Sie werden den Wunsch ablehnen, aus 20 Zeilen eine Klassenfabrik zu machen, anstatt einen Scripter für PHP als dämonische Versuchung zu machen. Am Morgen, wenn Sie Kaffee einschenken, sind Sie überrascht, dass der Kunde nach (nach!) Ihrer Testabteilung weitere 30-40 Fehler in dem Bug-Tracker gefunden und registriert hat, und empfiehlt, dass Sie (Sie!) Unit-Tests gründlicher schreiben und die Gehirne des Testers ändern ... aber es pumpt gut :-)

    Wie bewerten Sie ein Softwareprojekt?


    Ich werde direkt sprechen. Vernünftige Leute, inkl. Ingenieure verstehen, dass es unmöglich ist, etwas zu bewerten, was noch nicht erfunden wurde, um es milde auszudrücken. Man kann nur zuversichtlich lügen. Aber wie Sie wissen, funktioniert die formale mathematische Logik nicht für alle. Daher werden Sie manchmal Gesprächspartner treffen, die 1 + 1 = 11 behaupten, und es ist so überzeugend, dass sogar Tränen in den Augen erscheinen.

    Aber der Ausweg ist: eine Analogie. Nicht umsonst wird im modernen agilen Ansatz genau diese Analogie als grundlegender Bewertungsstein verwendet. Arbeitsbeispiele für Analogien in der Webentwicklung:

    • Es ist notwendig, einen typischen Online-Shop zu erstellen. Und wir haben schon ein Paar gemacht. Wir sprechen die Einschätzung entsprechend der Angemessenheit des Kunden / der Erfahrung des Teams in Form der Fibonacci-Zahl aus.
    • Wir bewerten das Feature in Story-Punkten , aber nicht in Arbeitsstunden. Wir betrachten 1 Speicherpunkt als die Komplexität der Erstellung eines Informationsblocks mit einer Liste von Nachrichten .
    • Manchmal können Sie die Art des Webprojekts anhand der Anzahl der darin enthaltenen Standardmodule und dem Anteil der Anpassungen grob bestimmen . Wenn es ähnliche Arten von Projekten mit ähnlichen oder ähnlichen Modulen und Anpassungsmöglichkeiten gab, können Sie die Analogie sicher verwenden.
    • Manchmal geben sie einen ungefähren Schätzwert an, indem sie die Dicke des TK in Millimetern messen. Ich meine es absolut ernst - ich habe es gesehen und überraschenderweise funktioniert es.

    Es ist wichtig, den Ansatz mit der Analogie und den Qualifikationen des Teams zu verwenden:

    • Diese Tölpel wurden vier Wochen lang miteinander verschraubt und dann waren es 2 Wochen, in denen die Wanzen auftraten. Multipliziere die Punktzahl mit 10.
    • Dieser Entwickler kann die Site mit dem Layout für die Woche integrieren. Fügen Sie 3 weitere Tage hinzu, um gutes Verhalten zu erzielen.

    Irgendwie so. Ja, Sie können argumentieren, was ist mit PMBoK, Gantt-Diagramm, Velicity , Karten in Kanban, dicken Büchern über "Agile Estimation", Teambeschleunigung, Metriken, Petriks? Ehrlich gesagt funktioniert es nicht und ich werde eine Analogie zum „maschinellen Lernen“ ziehen.

    Maschinelles Lernen und Schätzen


    Sie werden 5 Jahre lang an 50 Arten von Mathematik an der Universität unterrichtet, dann weitere sechs Monate in teuren Kursen über DataScience und MachineLearning. Dann erfahren Sie plötzlich, dass ... es in diesem Bereich keinen wissenschaftlichen Ansatz gibt, Sie müssen alle Optionen für Hyperparameter durchgehen, nur Zeit dafür Niemand wird geben (Tage und Monate) und bleibt göttliche willkürliche rohe Gewalt und vor allem INTUITION. Und nichts bleibt übrig, als ... zurückzukehren und die Theorie in den Kursen zu lesen. Mit der Bewertung der Arbeit in Softwareprojekten - viele Theorien, aber nur ein Körnchen Wissen, die in tiefe Intuition verwickelt sind, und, wie auch immer, Erfahrung, arbeiten in der Praxis.

    Um die Komplexität des Programmierens wirklich beurteilen zu können, müssen Sie die Städte verlassen, mit den Ureinwohnern leben, rohes Fleisch essen, warme, pulsierende Blutflocken trinken - bleiben Sie näher an der Natur = Code, Bugs, Produktion, bärtige Administratoren, schlafen Sie ein paar Nächte im Serverraum und lernen Sie, wie man Planken macht anstelle von Toilettenpapier. Minimalismus und der Wunsch, einfach und klar zu sein - werden es dem Team ermöglichen, häufiger in die Bewertungen einzusteigen, und der Kunde - um schnell aufsteigen zu können. Es ist in der Tat notwendig, diese rettende Kultur so schnell wie möglich zu pflegen und in das Projekt einzuführen.


    Bekannter Missbrauch


    Es ist komisch, aber manchmal stoßen solche Missbräuche an Bewertungen auf, die erfahrene Ingenieure mit einem Lächeln belächeln:

    • Es wird eine riesige TK pro 1000 Seiten geschrieben, die veraltet wird und nicht erst am nächsten Tag "riecht". Niemand hat es bis zum Ende gelesen, aber sie beziehen sich oft darauf. Es ist widersprüchlich, wässrig, politisch und neerotisch. Aber er wurde beurteilt, bei der Wiederholung abgeschnitten, sie wurden auch beurteilt, und nun versuchen alle, in diese logische Hölle zu passen.
    • Es erstellt ein riesiges Gantt-Diagramm. Weil Die Anforderungen werden ständig diskutiert und geändert, eine Abteilung für die Bewegung von Streifen im Gantt-Diagramm wird zugewiesen - sie sitzen und bewegen sich den ganzen Tag
    • Features werden ausgewertet und in der Mailbox gespeichert. Niemand außer dem Manager sah alle Funktionen und Bewertungen. Der Manager nimmt plötzlich sein eigenes Leben und das Projekt ... wird geschlossen.
    • Es gibt Boards und Marker, aber Filzstifte, entweder langjährige oder dauerhafte, und während einer Show der Kommunikation und Bewertung etwas Obszönes auf das Board schreiben, es ist unmöglich, es zu löschen :-)

    Nützliche und funktionierende Evaluierungspraktiken in Softwareprojekten


    Wenn Sie den Beitrag bis zu diesem Punkt gelesen haben, befinden Sie sich offensichtlich nicht mehr in der Kategorie "Je mehr Papier vorhanden ist, desto sauberer", "Sie stellen die falsche Frage", "Sie stellen die Aufgabe nicht mathematisch", sondern möchten dies wirklich tun Programmprojekt in angemessener Zeit und zu angemessenen Mitteln. Wir beheben die folgenden, wirklich funktionierenden Praktiken:

    • "Einfach, durchschnittlich, schwer." Ja, wir beraten uns mit einem erfahrenen Entwickler oder einem Team und setzen für jedes Feature in ProductBacklog eine mögliche Bewertung von 3 fest. Es ist ratsam, alle bekannten Merkmale des Projekts durchzugehen und mindestens eine solche Beurteilung vorzunehmen. Es ist möglich und notwendig, nur die Hände dabei zu haben - Freigaben bereits zu planen.
    • "Poker planen". Es gibt viele Informationen zu diesem Thema, aber wenn Sie während der Bewertung eine gesunde und positive Atmosphäre der Kommunikation und des Vertrauens zwischen Ihnen, den Teammitgliedern und dem Kunden sicherstellen, funktioniert dies gut.
    • "Rufe einen Freund an." Wenn Sie ein Unternehmen / Team oder einen vertrauten, erfahrenen Entwickler haben, sprechen Sie mit ihm. Leider verschwören sich die Teams manchmal und versuchen, die Zeit zu verlängern - der Experte kann die Implementierung angemessen beurteilen.
    • Features und Kommunikation werden maximal visualisiert. Separate Korkbretter heben sich hervor, Flugblätter mit Merkmalen hängen davon, Leute kommen hoch, diskutieren, zeichnen auf anderen Brettern, die Aufmerksamkeit haben, nicht getrocknete Flamaster und eine funktionierende Waschmaschine. Hier ist eine großartige Ressource zu diesem Thema.

    Werkzeuge und wirksame Praktiken sind oft wichtiger als Pläne und Fristen.


    Ich hoffe, es ist klar und offensichtlich geworden, dass selbst wenn die Anforderungen an ein Softwareprojekt sehr klar und formalisiert sind (dies geschieht, wenn auch selten), es aufgrund der Unerfahrenheit eines Ingenieurs oder Analytikers so viele plötzliche Überraschungen geben kann, dass ... nur Intuition und Analogie gut funktionieren. Lassen Sie uns die Beispiele von Überraschungen untersuchen - Sie müssen den Feind persönlich kennenlernen:

    1. Selbst wenn Gesetze, die von Gesetzgebern auf der ganzen Welt erstellt wurden, oft Wasser und logische Widersprüche enthalten können, die körperliche Gehirnschmerzen verursachen, dann ist TK die richtige Wahl. Wenn ein Widerspruch gefunden wird, ist es natürlich dringend, Änderungen am Code vorzunehmen. Die Änderung wird schnell vorgenommen und danach bricht das System zusammen, so dass die N-Tage wiederhergestellt werden und es unmöglich ist, N wissenschaftlich vorherzusagen!
    2. Es gibt einen Konflikt zwischen Softwarebibliotheken, und Sie müssen entweder eine davon oder Gladiolus deaktivieren. Es ist unmöglich, einen einfachen vorherzusagen.
    3. Bereits bei einer geringen Last wird die Unzulänglichkeit der gewählten Algorithmen erkannt (der algorithmische Wert der Anwendungsfälle wurde unterschätzt ), weshalb das System langsamer wird. Sie können das Problem in Stunden und Monaten finden und beheben. Es ist unmöglich vorherzusagen. Erfahrung, nur Erfahrung oder Boxed-Lösungen .
    4. Der Hauptentwickler hatte vor der Veröffentlichung überarbeitet und begann unter dem Einfluss aufkommender Emotionen im Serverraum auf einem Rack mit Web-Balancer zu urinieren. Bügeleisen kurzgeschlossen Plötzlich einfach - 2 Tage.

    In Anbetracht der oben genannten unvermeidbaren Risiken ist es üblich, anders zu handeln - mit dem System Bunker War (erinnern Sie sich an StarCraft) und den Taktiken: Verwenden Sie bewährte Konstruktionsmethoden und Werkzeuge und glauben Sie, dass wir durch das Einhalten dieser Taktik strategische Ziele erreichen werden. Ich sage dasselbe leichter: Wenn Sie nach oben drücken, laufen, den Expander drücken und abends die Bar benutzen, dann ist die Chance, abends ins Haus zu kommen, viel höher. Wenn wir einen Schutz vor Hooligans im Gantt-Diagramm planen, die Wahrscheinlichkeit berechnen, dass zwei oder drei Personen je nach Heimweg und Jahreszeit zu erreichen sind, wird es schwieriger und viel länger und jede Änderung der Wahrscheinlichkeiten muss jeden Tag berücksichtigt werden :-) Wir sind einander im Allgemeinen verstanden.

    1. Boards, Marker, Wikis - für maximale offene Kommunikation untereinander und mit Kunden
    2. Rundungsprojekt Anstatt die Kommunikation zu beenden und verzerrte Informationen und langsam korrupte Hierarchietelefone einzuführen, wird das Projekt so gerundet, dass alle Teammitglieder und Kundenvertreter im Ellenbogenabstand zur Verfügung stehen.
    3. TK ist nicht irgendwo, sondern hängt an Brettern, Wänden und so viele Menschen wie möglich können "lesen" und diskutieren.
    4. Verfügbare Assessment-Tools analog, Archiv der vorherigen Assessments, für alle zugänglich
    5. Entwickler schreiben automatisierte Unit-, Modular- und Integrationstests für den Code. In etwa sollten Tests genauso viel Code enthalten
    6. Normalerweise gibt es in jedem Softwareprojekt mehrere Orte, an denen Nebel herrscht, und Dämonen werden in ihren Pools gefunden. Es ist notwendig, die Prototypen so schnell wie möglich zu erhöhen, um diese Orte wiederzugeben, Last- und andere Tests durchzuführen und daraus eine Schätzung zu erhalten. Diese Bewertung ist in späteren Phasen des Projekts sehr nützlich.

    Das Projekt mit den richtigen Team-Kommunikationsmitteln abdecken, ein einfaches, aber korrektes System von taktischen Werten anwenden und soweit möglich auf den Kunden übertragen - die Chancen, die Bewertungen und Freigaben anzupassen, sind erheblich erhöht. Und niemand wird uns mehr Garantien geben - das ist eine Tatsache des Lebens.



    Gesamt


    Fassen wir zusammen. Kurz gesagt, wir haben von verschiedenen Seiten gesehen, dass Smart-Long-Politized-Methoden zur Bewertung von Softwareprojekten in einer Kaninchen-Papagei-Uhr nur unter idealen Bedingungen mit Testdaten arbeiten, jedoch nicht in der Praxis. Die Situation wiederholt die Ansätze und Ergebnisse des maschinellen Lernens - Sie können viel lernen und lange Zeit verstehen, dass nur Intuition / Erfahrung / Analogie funktioniert. Es ist extrem teuer, alles vorher detailliert in formale Würfel zu sortieren, und dafür ist in der Regel keine Zeit. In der realen Welt ist es für die Bewertung am besten, sich auf die Analogiemethode zu verlassen, auf einfache priorisierte Listen von Merkmalen ohne Hierarchien und Abhängigkeiten. Entwickler müssen den Code selbstdokumentierend machen, sich nicht auf die sofort verblassende TK verlassen und Autotests in den Code schreiben. Umsetzung und Einhaltung der Werte der offensten Kommunikation, Visualisierung der Anforderungen des Softwareprojekts, eine warmherzige und inspirierte Atmosphäre, einfache kategoriale Bewertungen - werden zum Veröffentlichungsdatum viel mehr als das endlose Verschieben von abstrakten Stöcken in Gantt-Diagrammen und anderen, die es mögen. In diesem und nur in diesem Fall gibt es jede Chance, das Projektteam mit Champagner in der Hand zu sehen, mit einem Lächeln, das die vollständige Veröffentlichung markiert, die mit dem neuen Jahr zusammenfällt. Und über die Mumie des Managers im Serverraum - es kam Ihnen einfach so vor :-)

    Schöne Ferien und gute Laune!

    Jetzt auch beliebt: