it-swarm.com.de

Wie kann man ein Programmierprojekt in Aufgaben für andere Entwickler aufteilen?

Ich habe mich kürzlich einem Entwicklungsprojekt angeschlossen und wurde plötzlich zum leitenden Entwickler ernannt. Meine Hauptverantwortung besteht darin, den Programmierteil des Projekts in Aufgaben aufzuteilen, diese Aufgaben den anderen Entwicklern zu übergeben und dann sicherzustellen, dass die Teile zusammenarbeiten.

Das Problem ist jedoch, dass ich keine Ahnung habe, wie das geht. Ich habe mein Wochenende mit Bleistift und Papier verbracht, um es herauszufinden, aber ich habe immer wieder eine Liste von Aufgaben erstellt, an denen nacheinander statt parallel gearbeitet werden soll. Ich habe darüber nachgedacht, es vielleicht in Funktionen aufzuteilen, aber dann haben Sie Aufgaben, bei denen dieselben Dateien bearbeitet werden müssen. Aufgrund des frühen Entwicklungsstandes muss möglicherweise eine gesamte Aufgabe vollständig neu geschrieben werden. Ich könnte einige Entwickler warten lassen, bis das Programm etwas vollständiger und einfacher zu erstellen ist, aber dann würden Leute auf ihren Händen sitzen, die wissen, wie viele Wochen.

Ich hatte ein Gespräch mit meinem Chef über meine Qualifikationen, und ich hatte in dieser Angelegenheit keine Wahl. Ich habe keine Ahnung, was ich tue, daher wären Tipps und Anstöße in die richtige Richtung sehr willkommen.

168
khm

Eine richtige Antwort auf Ihre Frage füllt mehrere Bücher . Ich werde eine Aufzählungsliste mit Modewörtern erstellen, die mir in den Sinn kommen. Google und Bücher erledigen den Rest für Sie.

  1. Grundlagen

    • Geh nicht alleine . Versuchen Sie, Ihre Teamkollegen so weit wie möglich einzubeziehen.
    • Travel lightweight .
    • Demokratie, aber nicht zu viel. Manchmal geht es nicht darum, was die meisten Menschen zufriedenstellt, sondern was die wenigsten Menschen verletzt.
    • Behalte was (muss gemacht werden) und wie (es wird gemacht) separate .
    • Erfahren Sie mehr über Scrum ("was"), [~ # ~] xp [~ # ~] (Extreme Programming, "wie "), Kanban (" wie viel "), Lean (" was nicht ") und DevOps (" mit wem ").
    • Lean ist auch ungefähr flow : Für die Gesamteffizienz ist Flow-Effizienz normalerweise wichtiger als individuelle Effizienz.
    • Erfahren Sie mehr über Software Craftsmanship , Clean Code und Pragmatic Programming .
    • Bei einer guten Architektur geht es um Maximierung der Anzahl der nicht getroffenen Entscheidungen .
    • Scrum/XP/Lean/Agile handelt von Maximierung der nicht geleisteten Arbeit : [~ # ~] yagni [~ # ~] .
    • Der Primärwert von Software ist, dass Sie leicht ändern können es. Dass es tut, was es tun soll, ist wichtig, aber das ist nur sein sekundärer Wert.
    • Bevorzugen Sie einen iterativen und inkrementellen Ansatz Zeitfenster für fast alles, insbesondere für Besprechungen, machen Sie Parkinson-Gesetz zu Ihrem Freund, weil Hofstadter-Gesetz gilt.
    • Balance Teamstruktur mit einem Verständnis von Conway's Law und Tuckmans Stufen der Teamentwicklung .
    • Programmieren ist eine Quaternität, es ist science , engineering , art und craft alle gleichzeitig, und diese müssen im Gleichgewicht sein.
    • Nur weil Scrum / [~ # ~] xp [~ # ~] /XYZ gut für jemanden ist (einschließlich mich), tut das nicht Das bedeutet nicht unbedingt, dass es gut für Sie ist/zu Ihrer Umgebung passt. Folgen Sie dem Hype nicht blind, sondern verstehen Sie ihn zuerst.
    • Inspizieren und anpassen! (Scrum Mantra)
    • Vervielfältigung vermeiden - Einmal und nur einmal! (XP Mantra) aka DRY - Wiederholen Sie sich nicht aka SPOT - Single Point of Truth
  2. Arbeitszusammenbruch "Welche Welt"

    • Sammeln Sie Anforderungen als User Stories / Job Stories in einem Product Backlog .
    • User (von User Story) ähnlich Actor (in UML) ähnlich Persona ähnlich Rolle .
    • User Stories verfeinern bis sie die Definition von Ready Ihres Teams erfüllen, basierend auf [~ # ~] invest [ ~ # ~] (Unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar). (Scrum Meeting: Backlog Refinement )
    • Sortieren Sie das Product Backlog nach Business Value .
    • Beginnen Sie nicht mit der Arbeit an einer Story, bevor sie Ready Ready (bereit gemäß der Definition von ready) ist.
    • Verwenden Sie Planning Poker , um den Aufwand von Stories in Story Points abzuschätzen. Verwenden Sie Triangulationsvergleich , um die Konsistenz der Schätzungen sicherzustellen.
    • Das Wetter von gestern ist die beste Schätzung, hoffe die schlechteste.
    • Split Stories wenn sie zu groß sind.
    • Verbessern Sie die Lieferkultur mit einem Definition von Done .
    • Akzeptieren Sie die Implementierung einer User Story nicht, bevor sie Done Done (gemäß der Definition von Done) ist.
    • Mehrere Teams auf derselben Codebasis sollten sich einig sein und dasselbe teilen Definition von Done (insbesondere die Coding Standards ).
    • Überprüfen Sie Ihren Fortschritt mit Burndown Charts .
    • Überprüfen Sie regelmäßig mit Ihren Stakeholdern, ob das, was das Team liefert, wirklich benötigt wird. (Scrum Meeting: Sprint Review )
  3. Story Breakdown

  4. "Wie Welt" Realisierung

Die obige Liste ist sicherlich unvollständig und einige Teile könnten sogar umstritten sein!

Wenn dir das alles Angst macht - mach dir keine Sorgen, denn es sollte erschreckt dich! Es ist keine leichte Aufgabe, Softwareentwicklungsprojekte in Teams durchzuführen, und selten werden Menschen in dieser Kunst richtig geschult und ausgebildet. Wenn Ihnen das Angst macht, Ihre Intuition richtig funktioniert, hören Sie zu. Du willst vorbereitet sein. Sprechen Sie mit Ihrem Chef, nehmen Sie sich Zeit und trainieren Sie.

Siehe auch

Weiterführende Literatur (online)

Weiterführende Literatur (Bücher)

  • Clean Code von Robert C. Martin
  • Agile Softwareentwicklung: Prinzipien, Muster und Praktiken von Robert C. Martin
  • Der pragmatische Programmierer - Vom Gesellen zum Meister von Andrew Hunt und David Thomas
  • Effektiv mit Legacy Code von Michael Feathers arbeiten
  • Refactoring - Verbesserung des Designs vorhandenen Codes von Martin Fowler
  • Refactoring zu Mustern von Joshua Kerievsky
  • Der Zehn-Tage-MBA von Steven Silbiger (sic!)
  • Domain-Driven Design von Eric Evans
  • User Stories von Mike Cohn
  • Objektorientierte Analyse und Design mit Anwendungen von Gray Booch et al
  • Design Patterns von der Viererbande
  • Testgetriebene Entwicklung von Kent Beck
  • Extreme Programmierung von Kent Beck
  • [wenn Java] Effektiv Java von Joshua Bloch
217
Christian Hujer

Agil werden

Ich würde folgendes vorschlagen:

Bearbeiten der gleichen Dateien

Verwenden Sie zunächst Git (oder ein ähnliches System zur gleichzeitigen Versionierung). Solange Sie verschiedene Teile derselben Dateien bearbeiten, treten keine Konflikte auf. Wenn Sie Konflikte bekommen, werden diese deutlich als solche gekennzeichnet.

Der Versuch, ein Projekt mit mehreren Entwicklern ohne Git zu verwalten, ist wie der Versuch, einen Pudding ohne Puddingschale herzustellen. Es ist möglich, aber es wird ziemlich schnell ziemlich chaotisch.

Wie in den Kommentaren erwähnt, ist Git kein Allheilmittel, aber in Kombination mit automatisierten Tests hilft es sicherlich sehr.

Listen Sie alle Funktionen auf

Teilen Sie das Projekt zweitens in vom Benutzer sichtbare Funktionen auf. Beispiel: "Wenn sich der Benutzer anmeldet, sollte er eine E-Mail erhalten" oder "Der Benutzer kann einen Artikel hinzufügen". Beziehen Sie hier alle Stakeholder ein. Holen Sie sich alle in einen Raum und lassen Sie alle ihre Gesichtszüge schreien.

Dies sollten vom Benutzer sichtbare Funktionen sein. Sie können später über die Implementierungsstrategie sprechen.

Schreiben Sie alle Vorschläge auf Karteikarten, auch die dummen. Rationalisieren Sie die Liste schnell, um Duplikate zu entfernen, und legen Sie alle Karten auf einen großen Tisch oder sogar auf den Boden.

Fügen Sie alle zusätzlichen Karten hinzu, die benötigt werden. Angenommen, Ihre Anwendung sendet SMS Textbenachrichtigungen. Möglicherweise wissen Sie nicht, wie das geht, daher haben Sie eine Frage. Schreiben Sie "Investigate SMS portals") auf a Ebenso für alle anderen großen Unbekannten. Sie müssen diese später auspacken. Diese Funktionen werden es wahrscheinlich nicht in Ihren ersten Sprint schaffen.

Sortieren Sie nun Ihre Karten in Gruppen, mischen Sie sie herum und erhalten Sie ein Gefühl für sie. Dies ist Ihr Projektumfang.

Poker planen

Planen Sie Poker. Geben Sie allen Entwicklern mit allen zusammen "1 Punkt", "2 Punkte" usw. bis zu "4 Punkte". Auch eine "mehr" Karte. Ein Punkt entspricht ungefähr einer Stunde.

Gehen Sie die Funktionsliste nacheinander durch. Während Sie eine Funktion vorlesen, muss jeder eine Karte spielen. Wenn eine Person 1 und eine andere 4 spielt, liegt dort ein Kommunikationsproblem vor. Eine Person versteht das Merkmal als etwas anderes als die andere Person. Besprechen Sie, was eigentlich gemeint war, und notieren Sie es auf der Karte.

Wenn Sie zustimmen, dass eine Funktion ein "Mehr" ist, ist diese Funktion zu groß. Sie müssen diese Funktion auflösen. Tun Sie dies auf die gleiche Weise wie zuvor.

Wenn Sie einverstanden sind, schreiben Sie die Zahlen mit einem anderen Farbstift auf die Karten.

Punkte sind besser als Stunden

Die Verwendung von Punkten anstelle von Stunden nimmt dem Macho "Schau, wie schnell ich codieren kann" etwas weg, mit dem wir Entwickler uns oft beschäftigen. Es ist ein subtiler Unterschied, aber ich habe festgestellt, dass es ziemlich gut funktioniert.

Jetzt komponiere einen Sprint

Ein Sprint ist ein schneller Ausbruch in Richtung eines Ziels. Entscheide dich für die Sprintlänge, vielleicht 5 oder 10 Tage. Multiplizieren Sie die Anzahl der Tage mit der Anzahl der Entwickler mit der Anzahl der Punkte pro Tag.

Nehmen Sie zunächst 6 Punkte pro Tag und Entwickler an. Dies ist eine erreichbare Zahl. Wenn Sie 5 Personen haben, sind das 5 * 5 * 6 = 150 Punkte. Wählen Sie in Zusammenarbeit mit allen Entwicklern und dem Management Funktionen aus der Liste aus, bis zu 150 Punkte. Das ist dein Sprint.

Seien Sie niemals versucht, mehr hineinzudrücken, als passt. Vielversprechend tut auf lange Sicht allen weh, auch Ihnen.

Hier müssen Sie Abhängigkeiten berücksichtigen. Zum Beispiel muss das Umgebungssetup offensichtlich im ersten Sprint enthalten sein. Dies ist eigentlich relativ einfach, wenn alle anwesend sind. Sie haben 6 Gehirne im Raum, die alle sagen "das hängt davon ab" usw. Sie können dann die Karten mischen, um Abhängigkeiten zu demonstrieren.

Sobald Sie Ihren Sprint haben, kann nichts mehr hinzugefügt werden, er ist für die 5 Tage gesperrt. Feature Creep wird das Team belasten, die Moral schädigen und alle verlangsamen. Schließlich wird Creep ein Projekt zum Stillstand bringen. Als Teamleiter müssen Sie Ihr Team vor Feature Creep schützen. Wenn eine neue Funktionsanforderung eingeht, muss sie dem nächsten Sprint hinzugefügt werden. WENN der nächste Sprint bereits voll ist, muss etwas anderes herausgenommen werden.

Seien Sie niemals versucht, Extras einzudrücken. Wenn Sie zu vielversprechend sind, haben Sie einen zufriedenen Kunden im Wert von rund 1 Tag, gefolgt von 4 Tagen Teamstress und schließlich höchstwahrscheinlich mehreren unglücklichen Kunden, wenn das Team nicht rechtzeitig liefern kann.

Jetzt geh dazu.

Verteilen Sie Karten und fragen Sie, wer was tun möchte. Sie haben die volle Sicht auf das, was gerade getan wird, und Sie können die Punkte zählen, die bis auf Null ablaufen. Machen Sie zu Beginn eines jeden Tages einen Stand-up, damit jeder weiß, wer an was arbeitet und was getan wurde.

5 oder 6 anständige motivierte Entwickler, die als Einheit an klar definierten überschaubaren Zielen zusammenarbeiten, können in einem 5-Tage-Sprint eine ziemlich große Menge an Dingen erreichen.

Sichtbarkeit bewahren

Stellen Sie sicher, dass jeder den Status des Projekts sehen kann. Bluetack alle Karten an die Wand. Links sind Karten, an denen noch nicht gearbeitet wurde. Rechts sind Karten fertig.

Wenn ein Entwickler an einer Karte arbeitet, nimmt er sie von der Wand und legt sie auf den Schreibtisch. Dies erhält die Sichtbarkeit und verhindert, dass Menschen sich gegenseitig zu sehr auf die Zehen treten.

Es gibt technologische Alternativen zu Karteikarten, aber nichts ist besser als eine massive Papieranzeige des Projektstatus an der Wand.

Wenn möglich, lassen Sie alle für die Dauer des Projekts im selben Raum. Haben Sie die Stakeholder so gut wie möglich, idealerweise jeden Tag.

Abbrennen

Sie können Ihre Punkte in einem Burndown-Diagramm grafisch gegen Null darstellen. Wenn Ihre Linie der besten Anpassung Null überschreitet, bevor Sie Ihr Zeitlimit erreicht haben, sind Sie wahrscheinlich auf dem richtigen Weg. Wenn nicht, müssen Sie Ihren Kunden möglicherweise jetzt informieren, bevor Sie sich der Frist zu nahe kommen.

Wenn Sie scheitern, scheitern Sie früh.

Sie können mit Software einen Burndown durchführen, aber ich bevorzuge nur ein großes Stück Papier an der Wand. Zeichne und schreibe alles darüber.

Automatisiertes Testen

Wenn mehrere Entwickler gleichzeitig an denselben Dingen arbeiten, werden sie sich wahrscheinlich von Zeit zu Zeit gegenseitig den Code brechen. Kommunikation und Sichtbarkeit helfen dabei, aber Sie werden wahrscheinlich einige Technologien einführen wollen, um Probleme zu finden.

Beim Unit-Test werden Tests für jeden einzelnen Teil Ihrer Codebasis geschrieben (idealerweise für jede Methode). Ihre Unit-Tests sollten häufig ausgeführt werden, wenn möglich mit jeder Speicherung. Es gibt viele Tools, die dabei helfen können, zum Beispiel Karma oder Rspec.

Beim End-to-End-Testen wird Ihr Projekt als Ganzes getestet und die Interna als Black Box behandelt. Richten Sie diese Tests auf Ihre allgemeinen Geschäftsanforderungen, z. B. "Der Benutzer kann sich anmelden" oder "Der Benutzer kann eine Liste der Elemente anzeigen". Winkelmesser ist ein schönes Beispiel für ein durchgängiges webbasiertes Testframework.

Es gibt ganze Bücher über Tests, aber wenn mindestens einige Abnahmetests vorhanden sind, kann dies dazu beitragen, dass bei der Arbeit an Ihrem Projekt nichts kaputt geht.

Vermeiden Sie technische Schulden und erledigen Sie Ihre Aufgaben

Technische Schulden sind ein Konzept, das Dinge beschreibt, die später bereinigt werden müssen. Eine häufige Quelle für Schulden sind Merkmale, die als erledigt markiert wurden, aber nie "erledigt" wurden. Eine erledigte Funktion wird in Git eingecheckt, vom Stakeholder genehmigt und getestet.

Aktivieren Sie Ihre Funktionen erst, wenn sie fertig sind. Massieren Sie niemals die Grafik. Auch dies tut auf lange Sicht allen weh, auch Ihnen.

Dies ist ein Grund, warum wir zunächst nur 6 Punkte pro Entwickler und Tag angeben. Fertig erledigt erfordert zusätzliche Arbeit, fühlt sich aber großartig an und gibt dem Team einen Schub.

35
superluminary

Es kommt darauf an, dass Sie Ihre Anwendung in Funktionsmodule aufteilen und dann Verträge (Schnittstellen und Datenverträge) zwischen den verschiedenen Modulen einführen müssen. Jedes Modul kann dann an einen anderen Entwickler übergeben werden. Wenn Sie alles wieder zusammensetzen, stellen die Verträge sicher, dass diese Module korrekt miteinander kommunizieren.

Stellen Sie sicher, dass Sie den Entwicklern TDD aufzwingen, um sicherzustellen, dass alle Module einzeln funktionieren.

m Ihnen ein Beispiel zu geben, was ich meine :

Angenommen, Sie möchten, dass einer Ihrer Entwickler einen SQL-Logger erstellt.

Sie definieren eine Schnittstelle und fragen einen Ihrer Entwickler ( oder erstellen eine Story, wenn Sie Agile verwenden), nach der Sie einen SQL-spezifischen Logger wünschen die folgende Spezifikation:

interface ILogger
{
    void Log(string message, int level);
}

Was ich dann von einem Entwickler erwarte, ist Folgendes:

  1. Die SQL-spezifische Implementierung für Logger

    class SqlLogger : ILogger
    {
        private readonly SqlLogRepository _logRepository;
    
        public SqlLogger(SqlLogRepository _logRepository)
        {
            this._logRepository = _logRepository;
        }
    
        public void Log(string message, int level)
        {
            _logRepository.CreateLog(message,level);
        }
    }
    
  2. Beliebiger abhängiger Code, z. B. eine Implementierung für SqlLogRepository

  3. Unit- oder Mock-Tests je nachdem, wonach gefragt wurde. Ein Mock-Test im obigen Fall (wo wir andere externe Abhängigkeiten haben) oder wenn es z. eine einfache Utility-Funktion wie String.ReverseCharacters(string input), dann möchte ich einfach Unit-Tests sehen, die ein paar verschiedene Szenarien testen.

Dies bedeutet, dass :

Über diese Schnittstelle können Sie und Ihr Team jetzt die Entwicklung fortsetzen. z.B.

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

und wenn Sie Ihren Code ausführen müssen, bevor SqlLogger vorhanden ist, können Sie einfach ein NullLogger erstellen:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Und so können Sie es in der Zwischenzeit testen (ich schlage vor, einen ICO für die Abhängigkeitsinjektion in Betracht zu ziehen).

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Zusammenfassung

Ich habe keine Ahnung von der Größe Ihres Projekts, aber dies könnte eine ziemlich entmutigende Aufgabe sein. Wenn Sie noch nie einen Entwicklungsleiter gemacht haben, würde ich vorschlagen, dass Sie diese Aufgabe sehr ernst nehmen und die nächsten Wochen damit verbringen, so viel wie Sie zu lesen kann auf Software-Design und Architektur. Und sei sehr transparent über deine Arbeit ( Softwarequalität usw. ) sonst wirst du schnell in ein tiefes Chaos geraten, das du nicht anziehst Ich weiß nicht, wie ich rauskomme.

Ich empfehle Ihnen außerdem dringend, sich über Design und das objektorientierte Paradigma zu informieren. Sie werden sich bei diesem Projekt stark auf OOP] verlassen.

10
z0mbi3

Das Bearbeiten derselben Dateien ist an sich kein Problem. Es ist nur dann ein Problem, wenn Sie dieselbe Funktion bearbeiten, um zwei verschiedene Dinge zu tun.

Grundsätzlich würde ich das Projekt in separate "Features" unterteilen. Eine könnte sich auf die Behandlung von Netzwerkprotokollen beziehen und eine andere auf eine Konfigurationsdatei und eine andere auf die Behandlung von DBs. Features sind große Dinge.

Als Nächstes möchten Sie diese Funktionen in Aufgaben (Storys) unterteilen. Dies sollten einfache Dinge sein, wie "Wenn der Benutzer auf eine Schaltfläche klickt, lädt das Programm die Datei", "Wenn das Programm startet, lädt es die Konfigurationsdatei" usw.

Einige Aufgaben müssen nacheinander ausgeführt werden ("Das Programm analysiert alle Felder in der Konfigurationsdatei" muss nach "Das Programm lädt die Konfigurationsdatei"). Andere nicht (Sie können gleichzeitig an der Datenbank und dem Netzwerk arbeiten).

Aber höchstwahrscheinlich werden Sie es falsch machen, und hier kommt die Erfahrung ins Spiel. Sie werden nur ein kleines bisschen (oder viel) scheitern, die Zeitschätzungen falsch verstehen und Ihr Projekt wird etwas länger dauern, als es sollte. Nächstes Mal wirst du besser.

Ich würde auch vorschlagen, "Extreme Programming" von Kent Beck zu lesen. Tolles Buch, das mir geholfen hat, als ich Projektmanager werden wollte.

10
Erez Eshkol

Die anderen Antworten haben über die Programmieraspekte gesprochen, aber ich wollte nur den Programmverwaltungsaspekt erwähnen. Ich beginne mit einem Haftungsausschluss: Ich bin kein Programmmanager. Ich habe einen Kurs auf Graduiertenebene für Programmmanagement belegt und meine Berufserfahrung umfasst das Bieten von Stunden für kleine Projekte, die normalerweise unter 500 Stunden und nie über 1000 Stunden liegen.

Aber ich musste helfen, Aufgaben für ein Labor zu definieren, in dem ich 2-3 Personen für 2-4 Monate (Teilzeit und Vollzeit) beschäftigen musste. Eine Sache, die mir wirklich geholfen hat, war die Verwendung von Projektmanagement-Software wie Microsoft Project (ich bin nicht sicher, ob es eine Freeware-Version gibt, aber Ihr Arbeitgeber hat wahrscheinlich so etwas ... Fragen Sie Ihren Vorgesetzten, welche Art von Programm-Management-Software verwendet wird in Ihrer Firma). Insbesondere verwende ich die Gantt-Diagramme ziemlich oft, was die Standardansicht in Microsoft Project ist. Indem Sie alle Aufgaben definieren und festlegen, wie lange sie voraussichtlich dauern werden, können Sie eine Visualisierung zum Spielen erhalten.

Das Gantt-Diagramm hilft mir aufgrund seiner Visualisierung am meisten. Aufgaben auf Papier zu sehen, hilft mir nicht viel, aber hübsche Bilder und ein Diagramm zu sehen, tut es auf jeden Fall. In Microsoft Project können Sie auch Vorgänger und Startdaten festlegen. Die Hauptidee lautet "Finden Sie die minimale Anzahl von Aufgaben, die zum Starten von Aufgabe X ausgeführt werden müssen". Zumindest in meinen kleinen Projekten ist die Anzahl der "echten" Vorgänger recht gering. Tatsächlich hatte ich bei einem Projekt das Problem, dass fast alles gleichzeitig erledigt werden konnte, und musste zwei gleichzeitige Pfade synthetisieren, die etwas zusammenhängend waren. Z.B. Ich habe versucht sicherzustellen, dass Entwickler A, wenn er jemals die GUI berührt hat, auch an Aufgaben arbeitet, die der GUI nahe kommen.

Es hört sich so an, als hätten Sie bereits viel davon getan, was Stift und Papier angeht, aber ich finde es immer sehr hilfreich, die Gantt-Diagramme tatsächlich zu sehen. Wenn ich mir die aufeinanderfolgenden Aufgaben anschaue, denke ich wirklich: "Warten Sie, muss Aufgabe X wirklich vor Aufgabe Y erledigt werden? (Nach meiner bisherigen Erfahrung war ich überrascht, wie oft die Antwort tatsächlich" Nein "lautet.)

2
Shaz

Es sieht so aus, als hätten Sie sich vom Entwickler zum Softwareentwickler entwickelt. Erkennen Sie, dass das Verwalten von Arbeit keine Entwurfsübung ist, aber die beiden gehen Hand in Hand. Sie müssen die geleistete Arbeit verwalten, und das hängt davon ab, wie Ihr Unternehmen die Entwicklung durchführt. Wenn Sie Zeit und Ressourcen haben, sollten Sie eine agile Methodik anwenden - im Internet gibt es Berge schriftlicher Materialien. Finden Sie eine, die für Sie funktioniert, aber beachten Sie, dass sie wie alles andere nicht kostenlos ist. Die Übernahme von Techniken beinhaltet Training, Lernen und Versagen, bevor Sie erfolgreich sind. Wenn Sie nicht über die Bandbreite verfügen, um eine umfassendere Technik anzuwenden, ist eine Meilensteinplanung möglicherweise die Antwort für Sie. Wenn Sie eine Liste sequentieller Aufgaben haben, haben Sie möglicherweise keine Sequenzen gefunden, die können parallelisiert werden. Es kann auch vorkommen, dass Sie Ihre Entwicklung in allgemeinere Aufgaben wie Testen und Implementierung unterteilen möchten. Das allein löst das Berichterstattungsproblem nicht, aber Sie verwalten die Qualität. Ihr Fortschritt kann eine sequentielle Liste sein, aber Ihre Rollen sind parallel. Nur ein Vorschlag. Ein Entwurf, der die von Menschen geleistete Arbeit abbildet, wird als Projektstrukturplan bezeichnet.

Es gibt viele gute Vorschläge, die andere Leute gemacht haben, aber denken Sie daran, dass Sie die Arbeit verwalten. Manchmal können Sie Arbeitskonzepte in das Design/die Architektur abbilden, manchmal können Sie das nicht so einfach tun. Es gibt immer eine Möglichkeit, die Arbeit so zu strukturieren, dass sie nachverfolgbar ist. Ich schlage vor, zu Ihrem Manager zurückzukehren und ihn zu fragen, was für ihn wichtig ist, um den Stand des Projekts zu kommunizieren. Das wird Ihnen sagen, wie Sie sich dem nähern sollen, was Sie tun. Wenn es sich um einen Zeitplan handelt, möchten Sie sich darauf konzentrieren, den Fortschritt zu melden. Wenn es sich um Qualität handelt, möchten Sie über eine Reihe von Metriken berichten, die Sie erstellen müssen. Wenn es kostet, dann werden Sie wahrscheinlich den Aufwand betrachten wollen. All diese Dinge können auch in die Aufgaben oder aus diesen heraus abgebildet werden.

1
Scott Pavetti