Ich bin kürzlich einem Entwicklungsprojekt beigetreten und wurde plötzlich als leitender Entwickler eingestellt. Meine Hauptaufgabe 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 finde immer wieder eine Liste von Aufgaben, die nicht parallel, sondern nacheinander abgearbeitet werden müssen. Ich habe darüber nachgedacht, es vielleicht in Funktionen aufzuteilen, aber dann haben Sie Aufgaben, bei denen die gleichen Dateien bearbeitet werden müssen. Dies kann dazu führen, dass eine gesamte Aufgabe aufgrund unserer frühen Entwicklungsphase vollständig neu geschrieben wird. 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, um dies zu tun, und mir wurde in dieser Angelegenheit keine Wahl gegeben. Ich habe keine Ahnung, was ich tue, daher sind Tipps und Anregungen in die richtige Richtung sehr willkommen.

Eine richtige Antwort auf Ihre Frage füllt mehrere Bücher . Ich werde eine Aufzählung von Schlagwörtern erstellen, die mir dazu einfallen. Google und die Bücher werden den Rest für Sie erledigen.

1. Grundlagen

   • Geh nicht alleine . Versuchen Sie, Ihre Teamkollegen so weit wie möglich einzubeziehen.
   • Leicht reisen .
   • Demokratie, aber nicht zu viel. Manchmal geht es nicht darum, was die meisten Menschen zufriedenstellt, sondern was die wenigsten Menschen verletzt.
   • Halten Sie was (muss getan werden) und wie (es wird getan) getrennt .
   • Erfahren Sie mehr über Scrum ("was"), XP (Extreme Programming, "wie"), Kanban ("wie viel"), Lean ("was nicht") und DevOps ("mit wem").
   • Bei Lean geht es auch um den Fluss : Für die Gesamteffizienz ist die Flusseffizienz in der Regel wichtiger als die individuelle Effizienz.
   • Erfahren Sie mehr über Software Craftsmanship , Clean Code und Pragmatic Programming .
   • Bei guter Architektur geht es darum, die Anzahl der nicht getroffenen Entscheidungen zu maximieren .
   • Bei Scrum / XP / Lean / Agile geht es darum, den Umfang der nicht geleisteten Arbeit zu maximieren : YAGNI .
   • Der Hauptwert von Software ist, dass Sie sie leicht ändern können. Es ist wichtig, dass es tut, was es tun soll, aber das ist nur sein sekundärer Wert.
   • Bevorzugen Sie einen iterativen und inkrementellen Ansatz, verwenden Sie Zeitfenster für fast alles, insbesondere für Besprechungen. Machen Sie das Parkinson-Gesetz zu Ihrem Freund, da das Hofstadter-Gesetz gilt.
   • Balance Teamstruktur mit einem Verständnis von Conways Gesetz und Tuckmans Stufen der Teamentwicklung .
   • Programmieren ist eine Quaternität, es ist Wissenschaft , Technik , Kunst und Handwerk zugleich, und diese müssen im Gleichgewicht sein.
   • Nur weil Scrum / XP / XYZ gut für jemanden ist (einschließlich mich), heißt das nicht unbedingt, dass es gut für Sie ist / zu Ihrer Umgebung passt. Folge nicht blindlings dem Hype, sondern verstehe ihn zuerst.
   • Inspizieren und anpassen! (Scrum Mantra)
   • Vermeiden Sie die Vervielfältigung - einmal und nur einmal! (XP Mantra) aka DRY - Wiederhole dich nicht aka SPOT - Single Point of Truth

2. "Welche Welt" Arbeitspanne

   • Sammeln Sie Anforderungen als User Stories / Job Stories in einem Product Backlog .
   • User (of User Story) ähnlich Actor (in UML) ähnlich Persona ähnlich Role .
   • Verfeinern Sie User Stories, bis sie die Definition von Bereit basierend auf INVEST (unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar) Ihres Teams erfüllen . (Scrum Meeting: Backlog-Verfeinerung )
   • Sortieren Sie das Product Backlog nach Geschäftswert .
   • Beginnen Sie nicht mit der Arbeit an einer Story, bevor sie fertig ist (fertig gemäß der Definition von fertig).
   • Verwenden Sie Planning Poker , um den Aufwand von Story Points zu schätzen . Verwenden Sie den Triangulationsvergleich , um die Konsistenz der Schätzungen sicherzustellen.
   • Das gestrige Wetter ist die beste Schätzung, die schlechteste Hoffnung.
   • Teilen Sie Geschichten auf, wenn sie zu groß sind.
   • Verbessern Sie die Lieferkultur mit einer Definition von "Fertig" .
   • Akzeptieren Sie die Implementierung einer User Story nicht, bevor sie fertig ist (gemäß der Definition von "Fertig").
   • Mehrere Teams auf derselben Codebasis sollten sich auf dieselbe Definition von Done einigen und diese teilen (insbesondere die Coding-Standards ).
   • Überprüfen Sie Ihren Fortschritt mit Burndown-Diagrammen .
   • Überprüfen Sie regelmäßig mit Ihren Stakeholdern, ob das Team die wirklich benötigten Ergebnisse liefert. (Scrum Meeting: Sprint Review )

3. Aufschlüsselung der Geschichte

   • Auflisten und Beschreiben Benutzer / Personas / Schauspieler / Rollen (Product Owner)
   • Epic -> Stories (User Story oder Job Story) (Product Owner)
   • Story -> Akzeptanzkriterien (Product Owner)
   • Story -> Unteraufgaben (Entwicklerteam)
   • Abnahmekriterien -> Abnahmetests (Spezifikation: Product Owner, Impl: Dev Team)
   • Beginnen Sie mit einem gehenden Skelett, das ein minimalistisches Ende-zu-Ende (halbes Ende) ist .
   • Erstellen Sie ein MVP - Minimum Viable Product .
   • Erweitern Sie den MVP mithilfe von SMURFS - Speziell marktfähige, nützliche, freigebbare Funktionssätze .

4. "Wie Welt" Realisierung

   • Verwenden Sie OOA / D- , UML- und CRC-Karten , aber vermeiden Sie das große Design im Voraus .
   • Implementieren Sie objektorientiert , strukturiert und funktional so viel wie möglich, unabhängig von der Programmiersprache.
   • Verwenden Sie die Versionskontrolle (vorzugsweise verteilt ).
   • Beginnen Sie mit Abnahmetests .
   • Wenden Sie TDD an und lassen Sie sich von den drei TDD-Gesetzen durch den Rot-Grün-Refaktor-Zyklus führen , mit Single-Assert-Rule , 4 A's , GWT (Given When Then) von BDD .
   • " Unit Tests sind Tests, die schnell ablaufen ." - Michael Feathers
   • Wenden Sie das SOLID und das Paket Grundsätze zur Verwaltung Kopplung und Kohäsion . Beispiel: S in SOLID ist SRP = Single Responsibility Principle, reduziert die Anzahl der Bearbeitungen bzw. Zusammenführungskonflikte in Teams.
   • Kennen Sie Gesetz von Demeter / Tell, fragen Sie nicht .
   • Verwenden Sie Continuous Integration , ggf. auch Continuous Delivery (DevOps).
   • Verwenden Sie Collective Code Ownership basierend auf einem vereinbarten gemeinsamen Codierungsstandard (der Teil der Definition of Done sein sollte ).
   • Kontinuierliche Designverbesserung anwenden (fka Continuous Refactoring).
   • Der Quellcode ist das Design . Noch immer ist vorausschauendes Denken unabdingbar, und niemand wird ein paar gute UML-Diagramme zur Klärung beanstanden.
   • XP bedeutet nicht, dass kein Tag ein Tag der Architektur ist, sondern, dass jeder Tag ein Tag der Architektur ist. Es ist ein Fokus auf Architektur, kein Defokus, und der Fokus liegt im Code.
   • Halten Sie Ihre technischen Schulden niedrig, vermeiden Sie die vier Designgerüche Zerbrechlichkeit , Steifheit , Unbeweglichkeit und Viskosität .
   • In der Architektur geht es um Geschäftslogik, nicht um Persistenz- und Bereitstellungsmechanismen.
   • Architektur ist ein Mannschaftssport ( in der Architektur gibt es kein Ich ).
   • Entwurfsmuster , Refactoring und die Priorität der Transformation .
   • Der Projektcode ist die ATP-Trinity mit den Prioritäten: 1. Automatisierungscode , 2. Testcode , 3. Produktionscode .
   • Überprüfen Sie regelmäßig mit Ihren Teamkollegen, ob die Leistung des Teams verbessert werden kann. (Scrum Meeting: Sprint Retrospektive )
   • Tests sollten ZUERST durchgeführt werden - schnell, unabhängig, wiederholbar, selbstvalidierend und zeitnah.

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 dir Angst machen! Es ist keine leichte Aufgabe, Softwareentwicklungsprojekte in Teams zu absolvieren, und nur selten werden die Menschen in dieser Kunst angemessen geschult und ausgebildet. Wenn Sie dies erschreckt, funktioniert Ihre Intuition ordnungsgemäß. Hören Sie zu. Sie möchten vorbereitet sein. Sprechen Sie mit Ihrem Chef, nehmen Sie sich Zeit und trainieren Sie.

Siehe auch

• Wer schreibt die technischen "User Stories" in Scrum

Weiterführende Literatur (online)

• Portland Pattern Repository von Ward Cunningham et al
• Prinzipien der OOD von Robert "Onkel Bob" C. Martin
• Pragmatische Programmiertipps

Weitere Lektüre (Bücher)

• Clean Code von Robert C. Martin
• Agile Software-Entwicklung: 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 von vorhandenem Code von Martin Fowler
• Refactoring zu Patterns von Joshua Kerievsky
• Der zehn Tage MBA von Steven Silbiger (sic!)
• Domain-Driven Design von Eric Evans
• Anwenderberichte Angewendet von Mike Cohn
• Objektorientierte Analyse und Design mit Anwendungen von Gray Booch et al
• Design Patterns von der Gang of Four
• Test Driven Development von Kent Beck
• Extreme Programming von Kent Beck
• [if Java] Effektives Java von Joshua Bloch

Agil werden

Ich würde folgendes vorschlagen:

Bearbeiten der gleichen Dateien

Verwenden Sie zunächst Git (oder ein ähnliches gleichzeitiges Versionsverwaltungssystem). Solange Sie verschiedene Teile derselben Dateien bearbeiten, treten keine Konflikte auf. Wenn Sie Konflikte haben, werden diese deutlich als solche gekennzeichnet.

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

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

Listen Sie alle Funktionen auf

Zweitens teilen Sie das Projekt in vom Benutzer sichtbare Funktionen auf. Zum 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 Funktionen ausrufen.

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 zusätzliche Karten hinzu, die benötigt werden. Angenommen, Ihre Anwendung sendet SMS-Benachrichtigungen. Vielleicht wissen Sie nicht, wie Sie das machen sollen, also haben Sie eine Frage. Schreiben Sie "SMS-Portale untersuchen" auf eine Karte. Ebenso für alle anderen großen Unbekannten. Sie müssen diese später auspacken. Diese Funktionen schaffen es wahrscheinlich nicht in Ihren ersten Sprint.

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

Poker planen

Versuchen Sie einmal, Poker zu planen. Geben Sie allen Entwicklerkarten, auf denen "1 Punkt", "2 Punkte" usw. steht, bis zu "4 Punkte". Auch eine "mehr" Karte. Ein Punkt entspricht ungefähr einer Stunde.

Gehen Sie die Funktionsliste nacheinander durch. Beim Vorlesen einer Funktion muss jeder eine Karte spielen. Wenn eine Person 1 und eine andere Person 4 spielt, liegt ein Kommunikationsproblem vor. Eine Person versteht die Funktion als etwas anderes als die andere Person. Besprechen Sie, was eigentlich gemeint war, und vermerken Sie es auf der Karte.

Wenn Sie zustimmen, dass ein Feature ein "Mehr" ist, ist dieses Feature 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 den Macho, mit dem wir Entwickler häufig zu tun haben, außer Acht. 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 anfangs 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 Features aus der Liste aus, bis zu 150 Punkte. Das ist dein Sprint.

Seien Sie niemals versucht, mehr hineinzudrücken, als passt. Zu vielversprechend verletzt auf lange Sicht alle, auch Sie.

Hier müssen Sie Abhängigkeiten berücksichtigen. Zum Beispiel muss das Setup der Umgebung natürlich im ersten Sprint enthalten sein. Dies ist eigentlich relativ einfach, wenn alle anwesend sind. Sie haben 6 Köpfe 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 hinzugefügt werden, er ist für die 5 Tage gesperrt. Feature Creep wird das Team belasten, die Moral schädigen und alle verlangsamen. Irgendwann wird Creep ein Projekt zum Stillstand bringen. Als Teamleiter müssen Sie Ihr Team vor unkontrolliertem Zugriff schützen. Wenn eine neue Funktionsanforderung eingeht, muss sie dem nächsten Sprint hinzugefügt werden. WENN der nächste Sprint schon voll ist, muss etwas anderes herausgenommen werden.

Seien Sie niemals versucht, Extras einzusammeln. Vielversprechend bedeutet, dass Sie ungefähr einen Tag zufriedener Kunden sind, gefolgt von 4 Tagen Teamstress und möglicherweise mehreren unglücklichen Kunden, wenn das Team nicht pünktlich liefert.

Nun gehe zu ihm.

Karten austeilen, fragen, wer was machen will. Sie haben volle Sicht auf das, was getan wird, und Sie können die Punkte zählen, die bis auf Null ablaufen. Machen Sie zu Beginn eines jeden Tages eine Pause, damit jeder weiß, wer an was arbeitet und was getan wurde.

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

Sichtbarkeit erhalten

Stellen Sie sicher, dass jeder den Status des Projekts sehen kann. Kleben Sie alle Karten an die Wand. Links sind Karten, an denen noch nicht gearbeitet wurde. Auf der rechten Seite 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 Sicht und verhindert, dass Menschen zu sehr auf die Zehen treten.

Es gibt technologische Alternativen zu Karteikarten, aber nichts geht über eine massive Papieranzeige des Projektstatus an der Wand.

Wenn möglich, lassen Sie alle für die Dauer des Projekts im selben Raum. Nehmen Sie die Stakeholder möglichst täglich in Kontakt.

Abbrennen

In einem Burndown-Diagramm können Sie Ihre Punkte grafisch darstellen, die in Richtung Null gehen. Wenn Ihre Best-Fit-Linie Null überschreitet, bevor Sie Ihr Zeitlimit erreicht haben, sind Sie wahrscheinlich auf Kurs. Wenn nicht, müssen Sie Ihren Kunden jetzt informieren, bevor Sie sich der Frist zu sehr nähern.

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 darüber.

Automatisiertes Testen

Wenn mehrere Entwickler zur gleichen Zeit an denselben Dingen arbeiten, werden sie wahrscheinlich von Zeit zu Zeit den Code des anderen knacken. Kommunikation und Sichtbarkeit helfen dabei, aber Sie werden wahrscheinlich einige Technologien einführen wollen, um Probleme zu finden.

Unit-Tests sind das Schreiben von Tests für jeden einzelnen Teil Ihrer Codebasis (im Idealfall 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-Test wird Ihr Projekt als Ganzes getestet und die Interna als Black Box behandelt. Richten Sie diese Tests an Ihren geschäftlichen Anforderungen aus, z. B. "Der Benutzer kann sich anmelden" oder "Der Benutzer kann eine Liste mit Elementen anzeigen". Winkelmesser ist ein schönes Beispiel für ein End-to-End-Web-basiertes 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.

Technische Schulden vermeiden und fertig werden

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 gekennzeichnet, aber niemals als erledigt gekennzeichnet wurden. Ein erledigtes Feature ist in Git eingecheckt, wurde vom Stakeholder genehmigt und hat einen Test.

Überprüfen Sie Ihre Funktionen erst, wenn sie fertig sind. Massieren Sie niemals die Grafik. Auch dies schmerzt auf lange Sicht alle, auch Sie.

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

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

Grundsätzlich würde ich das Projekt in "Funktionen" aufteilen, die getrennt sind. Eines könnte mit der Handhabung von Netzwerkprotokollen zusammenhängen, das andere mit einer Konfigurationsdatei und das andere mit der DB-Handhabung. 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" erfolgen). Andere nicht (Sie können gleichzeitig an der Datenbank und am 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 machen und Ihr Projekt wird ein bisschen länger dauern, als es sollte. Nächstes Mal bist du besser.

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

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 einem anderen Entwickler ausgehändigt werden. Wenn Sie alles wieder zusammensetzen, stellen die Verträge sicher, dass diese Module richtig miteinander kommunizieren.

Stellen Sie sicher, dass Sie TDD für die Entwickler erzwingen, um sicherzustellen, dass alle Module einzeln funktionieren.

Um 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 ), ob Sie einen SQL-spezifischen Logger gemäß der folgenden Spezifikation möchten:

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

Was ich dann von einem Entwickler erwarte, ist folgendes:

1. Die SQL-spezifische Implementierung für den 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, was gewünscht wurde. Ein Mock-Test im obigen Fall (wo wir andere externe Abhängigkeiten haben) oder wenn es zB eine einfache Utility-Funktion wie ist String.ReverseCharacters(string input), dann würde ich einfach gerne Unit-Tests sehen, die ein paar verschiedene Szenarien testen.

Das bedeutet, dass:

Mit dieser Oberfläche 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 das installiert SqlLoggerist, können Sie einfach Folgendes erstellen NullLogger:

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 zu suchen)

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, und wenn Sie noch nie einen Entwicklungsvorsprung gemacht haben, würde ich vorschlagen, dass Sie diese Aufgabe sehr ernst nehmen und die nächsten Wochen so viel lesen wie Sie können auf Software-Design und Architektur. Und seien Sie sehr transparent über Ihre Arbeit ( Softwarequalität usw. ), sonst geraten Sie schnell in ein Chaos, von dem Sie nicht wissen, wie Sie davonkommen sollen.

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

Die anderen Antworten haben sich mit den Programmieraspekten befasst, aber ich wollte nur den Programmverwaltungsaspekt erwähnen. Ich beginne mit einem Haftungsausschluss: Ich bin kein Programmmanager. Ich habe einen Kurs für Programmmanagement mit Abschluss belegt und meine Berufserfahrung beinhaltet die Teilnahme an Bewerbungsstunden für kleine Projekte, die normalerweise weniger als 500 Stunden und niemals mehr als 1000 Stunden dauern.

Aber ich musste mithelfen, Aufgaben für ein Labor zu definieren, in dem ich 2-3 Personen für 2-4 Monate beschäftigen musste (Teilzeit und Vollzeit). Eine Sache, die mir wirklich geholfen hat, war die Verwendung von Projektverwaltungssoftware 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 Programmverwaltungssoftware verwendet wird bei Ihnen). Insbesondere verwende ich die Gantt-Diagramme ziemlich oft, was die Standardansicht in Microsoft Project ist. Indem Sie alle Aufgaben definieren und wie lange Sie davon ausgehen, dass sie dauern werden, erhalten Sie eine Visualisierung, mit der Sie spielen können.

Das Gantt-Diagramm hilft mir aufgrund seiner Visualisierung am meisten. Es hilft mir nicht viel, Aufgaben auf Papier zu sehen, aber hübsche Bilder und eine Grafik zu sehen, tut es bestimmt. Mit Microsoft Project können Sie auch Vorgänger und Startdaten festlegen, wobei die Hauptidee lautet: "Ermitteln der minimalen 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 ziemlich gering. Tatsächlich hatte ich bei einem Projekt das Problem, dass fast alles gleichzeitig erledigt werden konnte und ich musste zwei parallele Pfade synthetisieren, die etwas zusammenhängend waren. Ich habe zum Beispiel 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ättest du schon viel getan, was Stift und Papier angeht, aber ich finde es immer sehr hilfreich, die Gantt-Diagramme tatsächlich zu sehen. Wenn ich mir die Aufgaben der Reihe nach ansehe, muss ich wirklich denken: "Warten Sie, muss die Aufgabe X wirklich erledigt werden, bevor die Aufgabe Y erledigt wird? (Nach meiner bisherigen Erfahrung war ich überrascht, wie oft die Antwort tatsächlich" Nein "lautet.)

Es sieht so aus, als ob Sie Ihren Abschluss als Entwickler oder Softwareentwickler gemacht haben. Machen Sie sich klar, dass das Verwalten der Arbeit keine Entwurfsübung ist, sondern dass beide Hand in Hand gehen. Sie müssen die geleistete Arbeit verwalten, und das hängt davon ab, wie sich Ihr Unternehmen entwickelt. Wenn Sie Zeit und Ressourcen haben, sollten Sie sich eine agile Methodik überlegen - im Internet gibt es Berge von schriftlichen Materialien. Finden Sie eine, die für Sie funktioniert, aber beachten Sie, dass sie, wie alles andere auch, nicht kostenlos ist. Das Anwenden von Techniken erfordert Training, Lernen und Versagen, bevor Sie Erfolg haben. Wenn Sie nicht über die Bandbreite verfügen, um eine umfassendere Technik anzuwenden, ist die Planung von Meilensteinen möglicherweise die Lösung für Sie. Wenn Sie eine Liste von sequentiellen Aufgaben haben, haben Sie möglicherweise keine Sequenzen gefunden, die dies könnenparallelisiert werden. Es kann auch vorkommen, dass Sie Ihre Entwicklung in allgemeinere Aufgaben wie Testen und Implementierung unterteilen möchten. Das allein löst das Berichtsproblem nicht, aber Sie verwalten die Qualität. Ihr Fortschritt mag eine sequentielle Liste sein, aber Ihre Rollen sind parallel. Nur ein Vorschlag. Ein Entwurf, der der von Menschen geleisteten Arbeit entspricht, wird als Arbeitsstrukturplan bezeichnet.

Es gibt viele gute Vorschläge, die andere angeboten 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 nachverfolgt werden kann. Ich schlage vor, zu Ihrem Vorgesetzten zurückzukehren und ihn zu fragen, was für ihn wichtig ist, wenn es darum geht, den Stand des Projekts mitzuteilen. Das wird Ihnen zeigen, wie Sie sich dem nähern, was Sie tun. Wenn es sich um einen Zeitplan handelt, möchten Sie sich auf die Berichterstellung konzentrieren. Wenn es um Qualität geht, möchten Sie über eine Reihe von Metriken berichten, die Sie erstellen müssen. Wenn es kostet, dann werden Sie wahrscheinlich Aufwand suchen wollen. All diese Dinge können auch Aufgaben zugeordnet oder daraus entfernt werden.