it-swarm-eu.dev

Beste Entwicklungsmethode für eine Person?

Ich verbringe viel Zeit damit, an Projekten zu arbeiten, bei denen ich der einzige Entwickler, Projektmanager, Designer, QT-Mitarbeiter bin (Ja, ich weiß ... schlecht!), Und manchmal bin ich sogar der Kunde.

Ich habe so gut wie alles versucht, um Projekte zu planen und mich selbst zu verwalten, vom Sitzen und Arbeiten im Freestyle bis zur Fertigstellung des Projekts, wie lange es auch dauert, bis zu einer Einzelversion von Scrum, in der ich ein Fortschrittsmeeting mit mir selbst über ein Eins abgehalten habe -man Burndown Chart jeden Morgen (kein Scherz).

Was ist für diejenigen unter Ihnen, die viel Zeit alleine arbeiten, der beste Weg, sich zu organisieren, große Projekte (für eine Person) zu verwalten und die Produktivität so hoch wie möglich zu halten?

77
Eli

Es ist wichtig, eine klare Liste Ihrer Ziele zu führen. Für Feature Creep ist es einfach, ein selbstverwaltetes Projekt zu übernehmen. Hilfreich ist auch der TDD-Ansatz "Es ist fertig, wenn es funktioniert". Dies verhindert, dass Sie ein Perfektionist werden.

Eine Sache, die mir wirklich hilft, ist sich vorzustellen, was ein anderer Ingenieur oder ein Projektmanager in einer bestimmten Situation sagen würde. Oft bin ich in der Lage, mich wegen schlechten Codes zu "beschämen" oder wieder auf Kurs zu kommen, wenn der Zeitplan verrutscht.

29
Jon B

Los geht's ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP lässt sich gut verkleinern, da es für kleine, fokussierte Teams optimal ist.

  • Sie können eine Tabelle mit Feature-Anforderungen erstellen, diese priorisieren und die oberste auswählen.
  • definieren Sie die Akzeptanzkriterien (wie es aussieht) und codieren Sie sie in einen ausführbaren Test
  • Definieren Sie als Nächstes die zu erledigenden Engineering-Aufgaben
  • Schreiben Sie Unit-Tests, machen Sie das Einfachste (YAGNI) und überarbeiten Sie die ganze Zeit. Ziel ist es, den äußeren Abnahmetest zu bestehen
  • Timebox für jede Sitzung. Für ein effektives Zeitmanagement können Sie auch die Pomodoro-Technik betrachten.
  • Verwenden Sie die Versionskontrolle und richten Sie einen CI-Server/eine Batch-Datei ein, um eine Installation oder ein Zip Ihrer Software zu erstellen
  • Demo häufig. Leiten Sie das Feedback in die ursprüngliche Tabelle und priorisieren Sie es neu

Das einzige, was Sie in einem Team nicht tun können, ist PairProgramming.

23
Gishu

Wenn Sie alleine arbeiten. Hier sind die Ratschläge:

  1. Arbeiten Sie so wenig wie möglich auf niedriger Ebene. Verwenden Sie so viele Bibliotheken und Tools wie möglich, einschließlich der Dinge, von denen Sie glauben, dass Sie sie leicht codieren können (tun Sie es nicht, verwenden Sie einfach die Bibliothek).
  2. Gehen Sie von oben nach unten vor. Codieren Sie nur Dinge, die Sie wirklich brauchen.
  3. Wenn Sie ein Problem in abstrakter Form sehen, suchen Sie auf Google und verwenden Sie Forschungsarbeiten aus der akademischen Gemeinschaft, die bereits bewiesen wurden. Sie müssen nur ihren Algorithmus codieren.
  4. Entwerfen Sie Ihr System so, dass Sie die Dinge so weit wie möglich frei ändern können. (einschließlich Kopieren und Einfügen von Code von hier nach dort). Der Zweck ist es, Ihnen Zeit zu sparen, wenn Sie feststellen, dass Sie einen Fehler gemacht haben. Versuchen Sie, den Arbeitsaufwand zu minimieren, den Sie wegwerfen müssen, wenn Sie einen Fehler machen. Ein Teil des Codes, der weggeworfen werden muss (anstatt von hier und da zu kopieren und einzufügen), ist die Äquivalenz der Zeit, die Sie beim Schreiben dieses Codes verloren haben.
  5. Führen Sie viele automatisierte Tests durch, damit Sie bei jeder Änderung regelmäßig Regressionstests durchführen können
  6. Trennen Sie die Verantwortlichkeiten Ihres Entwurfs (d. H. Reduzieren Sie die Kopplung). Machen Sie die Dinge so modular wie möglich
  7. Verwenden Sie einen Debugger zum Debuggen und verwenden Sie die binäre Suche, um einen Fehler zu finden.
  8. Überarbeiten Sie Ihren Code ständig, um die (explizite) Kopplung und die Exposition gegenüber öffentlichen Methoden (implizite Kopplung) zu reduzieren.
  9. Nichts wirklich. Dies ist hier nur für den Fall, dass ich mir etwas Neues einfallen lassen kann: P.
17
InformedA

Code-Bewertungen.

Diese sind besonders nützlich, da Sie den Code jemandem erklären, der nicht an demselben Projekt gearbeitet hat, damit er keine Ihrer Annahmen darüber hat, wie er funktionieren soll.

Sie haben außerdem den zusätzlichen Vorteil, dass sie ihr Wissen im gesamten Unternehmen teilen können. Wenn also jemand anderes an dem Projekt arbeiten muss (weil die Leute anderswo beschäftigt sind, krank sind, zurückgetreten sind oder entlassen wurden), müssen sie nicht bei Null anfangen .

13
ChrisF

Ich habe meine eigene Version von Agile entwickelt, die auf Storys, intensiver Kundeninteraktion, häufigen Releases und testgetriebener Entwicklung basiert. Ich benutze ein Wiki, um Geschichten zu verfolgen, den Kunden so weit wie möglich in das Schreiben einzubeziehen und den Kunden mit mir zusammenarbeiten zu lassen, um Prioritäten zu setzen und in Releases zu organisieren. Ich benutze TDD, um das Design und die Implementierung voranzutreiben. Ich habe einen QS-Server eingerichtet, auf dem der Kunde häufige Releases ausprobieren kann (manchmal täglich, wenn neue Funktionen entwickelt werden), damit ich schnell Feedback bekomme. Ich gehe selten mehr als 3 Iterationen ohne eine Freigabe für die Qualitätssicherung. Der Kunde kann entscheiden, wann die QS-Version über genügend Funktionen verfügt, um live geschaltet zu werden - und ob keine weiteren Funktionen von der Liste entwickelt werden müssen.

7
tvanfosson

In meiner Firma arbeitet unsere Gruppe alle am selben Projekt, aber an relativ unabhängigen Teilen davon. Eine Sache, die wir hier häufig tun, ist, wenn etwas, das Sie tun, etwas schwierig erscheint oder wenn Sie an einer Weggabelung mit mehr als einer Möglichkeit stehen, etwas umzusetzen, greifen Sie zu jemand anderem und diskutieren die Vor- und Nachteile vorher Sie fahren fort. Wenn Sie warten, bis Sie der Meinung sind, dass Ihr Code für eine Überprüfung fertig ist, haben Sie normalerweise bereits zu viel Zeit investiert, um wichtige architektonische Änderungen zu berücksichtigen, obwohl bei Codeüberprüfungen sicherlich viele Fehler aufgedeckt werden.

Außerdem ist mir klar, dass testgetriebene Entwicklung in letzter Zeit ein kleines Schlagwort ist, aber es kann eine große Hilfe für Solo-Entwickler sein, da es eine Qualitätsprüfung bietet, wenn Sie schwierig werden, und wenn Tests schwierig zu schreiben sind, wissen Sie, dass Sie wahrscheinlich eine Umstrukturierung Ihrer benötigen Code. Es hilft auch späteren Betreuern, den Code nicht versehentlich auf schwer zu erkennende Weise zu beschädigen.

7
Karl Bielefeldt

Ich schlage Ihnen Folgendes vor:

  1. Testgetriebene Entwicklung
  2. Verwenden Sie "TODO: hier notieren" in Ihrem Code, wenn Sie etwas sehen, das Sie nicht sofort tun können, und kehren Sie zu ihnen zurück, wenn Sie Zeit haben, stattdessen auf Facebook zu bleiben und darauf zu warten, dass Ihr Kunde zurückruft
  3. Schreiben Sie Ihren Code, während Ihr Kunde ihn kauft. Betrachten Sie den Code nicht nur als Ergebnis. Stellen Sie sich Ihren Kunden als Vorsitzenden für eine Codeüberprüfung vor.
  4. Füllen Sie Ihren Assert-Code aus
4
Gaetano Mendola

ich wünschte, ich könnte sagen, ich könnte 100% der Zeit üben, was ich predige, aber BDD scheint ein guter Ansatz zu sein, um Ihre Situation zu berücksichtigen:

Hier ist ein Link mit weiteren Informationen: http://en.wikipedia.org/wiki/Behavior_driven_development

3
Levi Rosol

philosophie: XP/TDD + GTD

allgemeiner Überblick:

  • stakeholder interviewen
  • bildschirmmodelle, exemplarische Vorgehensweisen, Papierprototypen (falls erforderlich)
  • feature/Story-Brainstorming (mit und ohne Stakeholder)
  • testfall-Brainstorming (mit und ohne Stakeholder)
  • gesamtüberlegungszeit für Design/Architektur (nach Bedarf)
  • iterationsplanung (mit Stakeholdern)
  • iterationen
  • prozessüberprüfung, Schulung, Wartungsplanung usw. (falls erforderlich)
2
Steven A. Lowe

Ich bin in einem sehr ähnlichen Boot. Ich versuche, agilen Prinzipien (so gut ich sie verstehe) so weit wie möglich zu folgen. Ich mache die Dinge wahrscheinlich nicht "richtig", aber ich hatte großen Erfolg bei meinen Projekten, indem ich versucht habe, agilen Prinzipien zu folgen. Es erfordert eine enorme Menge an Disziplin, da es kein Team gibt, das sicherstellt, dass Sie nicht einfach Verknüpfungen verwenden.

2
John Kraft

Ich finde, dass die Verwendung von Code-Formatierungs-Tools wie ReSharper sicherstellt, dass der Code zumindest visuell für andere Entwickler leicht zu finden ist.

In Bezug auf die tatsächlichen Methoden ist es für einen einzelnen Entwickler schwierig, sich an eine bestimmte zu halten. Ich bin ein Berater, der im Allgemeinen alleine arbeitet, und ich finde es sowohl für mich als auch für den Kunden am einfachsten, einen agilen Prozess anzuwenden. Normalerweise versuche ich, meine Kunden dazu zu bringen, ihre Anforderungen direkt in ein Tool wie Trac einzugeben (oder ich werde es in ihrem Namen tun). Dies hilft nicht nur anderen Entwicklern, den Zweck des Codes zu identifizieren, sondern auch Ihnen selbst 3 Monate später!

2
bryanatkinson

Jede geeignete Methodik wird helfen - unabhängig von der Anzahl der Personen im Projekt. Wählen Sie also jeweils eine aus und sehen Sie, wie Sie Ihre Domain anwenden, zuordnen und ihre Erfolge messen können.

Interessanter ist vielleicht die Frage, welche Methoden nicht wegzuwerfen sind, da nur eine Person an dem Projekt arbeitet.

Und der Schlüssel, der mir auffällt, ist die Quellcodeverwaltung (Ja, das ist ein Werkzeug, aber es ist Teil Ihres Arbeitsablaufs, also auch ein Prozess). Die Leute könnten versucht sein, diesen Pass zu geben, da sie "nicht mehrere Leute unterstützen müssen, die den Code gleichzeitig bearbeiten".

Ironischerweise finde ich, dass eine verteilte Versionskontrolllösung wie GIT für eine Person besser ist als SVN.

1
Stephen Bailey

Wenn es sich um Wegwerfcode handelt, kann er mit Methoden ein wenig locker sein, aber alles, was wichtig ist, und ich würde sagen, dass Ihre Art, ihn als Teamprojekt mit einer Person zu behandeln, sehr nett und diszipliniert ist.

Schreiben Sie Ihren Code, damit der nächste Mann ihn liest, nicht Sie ... seien Sie nett zu ihm/ihr. Sogar der "Wegwerf" -Code bleibt für immer bestehen.

0
Nick

Ich denke, Codeüberprüfungen sind ein guter Anfang, aber ich mag es, wenn sie informell und unterhaltsam sind, z. B. eine Überprüfung des Paarcodes oder die Programmierung von Paaren, um ein bestimmtes Problem oder eine Verbesserung anzugehen (z. B. das Ändern von Legacy-Code, um neuen Codierungsstandards zu entsprechen ). Manchmal sind zwei Augenpaare besser als eines und es macht auch Spaß. Ich finde, dass das Teilen und Diskutieren offener erscheint. Sie können auch ein formelles/informelles Mittagessen einnehmen und Sitzungen besprechen, um darüber zu sprechen, was Sie einzeln oder als Gruppe getan haben, z. Erwähnen Sie ein neues Muster, das Sie verwendet haben, oder neue Technologien, wie ein Problem gelöst wurde?

0
MalsR

Agil

funktionen, Geschichten und Testfälle sind weitaus lehrreicher als eine formellere Dokumentation, und eine Reihe von Arbeitstests kann besser demonstrieren, wie etwas verwendet wird oder wie etwas funktioniert, als eine beliebige Anzahl toter Bäume

Es ist auch einfacher, die Arbeit zwischen den Iterationen abzugeben.

0
Steven A. Lowe

Als Berater würde ich vorschlagen, dass Sie einen Weg finden, immer mindestens zwei Entwickler für einen Auftrag zu haben.

Ich bin damit einverstanden, agil zu werden und eine agile Spur von Geschichten und Tests zu hinterlassen, denen andere folgen können, aber ich glaube nicht, dass dies oder ein anderer Prozess oder eine andere Methode bleiben wird, während die Leute alleine arbeiten.

0
Apalala