Ich finde oft, dass ich an einer Funktion weniger als komplett arbeite, besonders in der Entwurfsphase. Ich erkenne mehrere Gründe:
Ich kenne dieses Verhalten seit einiger Zeit, doch ich finde es immer noch nicht gelungen, das zu kompensieren. Sind Sie auf ähnliche Probleme gestoßen? Wie nähern Sie sich der Lösung?
Ich benutze ein paar Techniken. Die erste ist eine einfache To-Do-Liste. Am Morgen schreibe ich meine Aufgaben für den Tag auf. Ich versuche, an einer Aufgabe zu arbeiten, bis ich es durchgehen kann. Ich überschreite es nur, wenn ich zu meiner eigenen Zufriedenheit fertig bin. Meine To-Do-Liste hilft mir, konzentriert zu bleiben. Wenn eine Unterbrechung eintritt, kann ich bewusst wählen, ob es wichtig genug ist, um das, was ich gerade mache, zu unterbrechen.
Die zweite Technik, die ich benutze, besteht darin, die Idee "fertig" für ein Design aufzugeben. Stattdessen konzentriere ich mich auf das, was ich als "Abfolgen" bezeichne, wo ein Design vorhersehbare Stadien durchläuft. Jede Stufe unterstützt die aktuelle Funktionalität gut und wird irgendwann in der nächsten Stufe erfolgreich sein. So kann ich einen guten Job machen, einen Job, auf den ich stolz sein kann, ohne überzuarbeiten.
Ich habe die Intuition, dass es einen kleinen Katalog solcher Abfolgen gibt (wie Ссылка ), der den größten Teil des Designs abdecken würde . In der Zwischenzeit versuche ich mich daran zu erinnern, dass "die Probleme des Tages ausreichen".
Ich stoße sehr oft auf dieses Problem.
Meine Lösung ist ein Notebook. (Die altmodische Papierart).
Ich schreibe auf, wie ich die Lösung als Liste mit Aufzählungszeichen implementieren möchte, und dann versuche ich, jeden Punkt auf der Liste auszuarbeiten.
Oft stoße ich dabei auf Probleme, an die ich nicht gedacht habe.
Natürlich gilt die 80/20-Regel immer noch ... Ich stoße immer noch auf Dinge, wenn ich tatsächlich die Umsetzung mache, die mir nicht eingefallen ist, aber mit der Erfahrung neigen sie dazu, sich zu verringern.
EDIT: Wenn ich am Ende dieses Prozesses immer noch nicht sicher bin, habe ich einen Prototyp-Testbed zusammengestellt ... Es ist wichtig, darauf zu achten, dass er wegschmeißt, sonst riskiert man ein paar böse Hacks in seinem echte Codebasis.
In der Planungsphase eines Projekts, besonders im Bereich der Softwareentwicklung, ist es sehr häufig, dass Sie Randfälle und Details übersehen. Bitte fühlen Sie nicht, dass dies ein persönliches Versagen ist; Es ist etwas Endemisches.
Um dem entgegenzuwirken, sind viele Methoden der Softwareentwicklung entstanden. In letzter Zeit haben sich viele Entwicklungsteams zu "agilen" Methoden hinbewegt, bei denen der Fokus auf einer schnellen Entwicklung mit wenig technischem Design liegt (schließlich werden viele Komplexitäten erst entdeckt, wenn Sie tatsächlich mit der Entwicklung beginnen). Ich benutze derzeit das Scrum-System, das in meinem kleinen Team hervorragend war:
Wenn Sie feststellen, dass Ihre Organisation nicht akzeptiert, was sie als eine radikale Änderung des Ansatzes betrachten, könnte es sich lohnen, zu untersuchen, ob sie der Entwicklung eines Prototypsystems zustimmen werden. Dies bedeutet, dass Sie eine Funktion programmieren können, um die beteiligten Technologien zu untersuchen und zu beurteilen, ob dies machbar ist, ohne sich auf die vollständige Entwicklung, eine Qualitätsbar, Testpläne usw. festzulegen. Der Prototyp sollte verworfen werden, sobald die Machbarkeit bewiesen oder widerlegt wurde , dann kann die richtige Entwicklung beginnen, einschließlich alles, was Sie in diesem Prozess gelernt haben.
Wenn Ihr Problem eher mit der Zeitverwaltung zusammenhängt, empfehle ich den Ansatz "Getting Things Done" ( Ссылка ). . Dies ist pragmatisch und einfach und konzentriert sich darauf, Sie produktiv zu machen, ohne Sie mit Informationen zu überladen, die für Ihre aktuelle Arbeit nicht unmittelbar relevant sind. Ich habe festgestellt, dass ich manchmal mit Projekt- / Featureideen überfordert bin und es wirklich hilft, alles niederzuschreiben und für eine spätere Zeit abzulegen, wenn ich die Ressourcen zur Verfügung habe, um effektiv zu arbeiten.
Ich hoffe, das hilft und viel Glück!
Kommunikation.
Der beste Weg, sich nicht in Programmierfehler zu stürzen, ist Kommunikation. Ja, gute alte Rechenschaftspflicht. Wenn eine andere Person im Büro in den Prozess involviert ist, ist das Ergebnis besser. Wenn ein Programmierer die Aufgabe einfach übernimmt, ohne sich um irgendjemanden zu kümmern, dann besteht eine höhere Wahrscheinlichkeit für Fehler.
Checkliste für die Verantwortlichkeit:
Ein skepticle comrad ist normalerweise gut genug, um zu helfen. Funktionale Spezifikationen sind gut, normalerweise beantworten sie alle diese Gedanken. Aber manchmal kann eine Konversation mit einer anderen Person Ihnen dabei helfen und Sie können die Tür schneller öffnen.
Ich habe gelernt, durch jahrelange Fehler (obwohl ich sie immer noch mache), dass fast alles, was ich immer wieder benutzen oder verteilen möchte, richtig gestaltet sein muss. Wenn du dich genug verbrennst, wird das deinen Optimismus beenden.
Wenn ich vom Management Druck bekomme, sage ich ihnen, dass ich den Gedanken trotzdem einbauen muss, also sollte ich es tun, wenn es billig ist. Ich denke auch auf dem Papier, also kann ich tatsächlich beweisen, dass ich etwas mache und es meine Finger auf der Tastatur hält, die beide eine beruhigende Wirkung auf das Management haben. ; -)
Auf die Gefahr hin, offensichtlich zu sein - sei pessimistisch. Ich hatte ein paar Erfahrungen, bei denen ich dachte "das sollte ein paar Stunden dauern" und es dauerte ein paar Tage wegen all der kleinen Dinge, die unerwartet auftauchen.
Bei weitem der beste Weg, den ich gefunden habe, um Dinge zu verwalten, ist (ähnlich wie Andrews Antwort) das Design und die Anforderungen als Ausgangspunkt zu schreiben. Dann gehe ich durch und suche nach Schwachstellen in Design, Fall und weiteren Anwendungsfällen. Ich versuche, dies als eine kritische Übung zu betrachten - es gibt noch keinen geschriebenen Code, also ist es an der Zeit, völlig rücksichtslos zu sein und nach jedem zu suchen Schwachstelle. Suchen Sie nach Fehlerbedingungen, die Sie behandeln müssen, und wie viel Zeit auch immer Sie für die Fertigstellung der einzelnen Funktionen benötigen, packen Sie diesen Betrag sehr viel. Ich hatte Zeiten, in denen ich meine ursprüngliche Schätzung verdoppeln konnte und immer noch nicht so weit daneben war.
Es ist sehr schwierig für Programmierer, die Debugging-Zeit realistisch zu prognostizieren - das Schreiben des Codes ist leicht zu schätzen, aber das Debuggen in funktionierenden, gültigen Code ist etwas ganz anderes. Daher finde ich, dass es keine exakte Wissenschaft dafür gibt, aber ich packe nur Aufgaben um einen ganzen Haufen, so dass ich genug Platz zum Debuggen habe.
Siehe auch Evidence Based Scheduling , das ein faszinierendes Konzept für die Planung ist, das von FogCreek entwickelt wurde FogBugz Produkt.
Sie und der Rest der Welt.
Sie brauchen mehr einen detaillierteren Entwurf, eine genauere Schätzung und die Bereitschaft zu akzeptieren, dass manchmal die optimale Lösung nicht unbedingt die beste Lösung ist (zB könnten Sie eine Schleife in Assembler programmieren, um optimale Leistung zu erhalten, aber das wird es tun) nehmen Sie viel länger als nur tun
%Vor%). Ist die Zeit, die damit verbracht wird, wirklich wert für ein Buchhaltungspaket über ein Raketensystem.
Ich mag es zu entwerfen, aber im Laufe der Zeit habe ich festgestellt, dass viel Design im Vorfeld viel wie das Bauen von Schlössern in den Himmel ist - es ist zu viel Spekulation, wie gut gebildet, fehlende kritische Rückmeldung von der tatsächlichen Implementierung und Verwendung des Designs .
Heute bin ich viel mehr damit einverstanden zu akzeptieren, dass ich bei der Implementierung eines Designs viel Neues darüber lernen werde und dieses Lernen wieder in das Design einfließen lassen muss. Dies ist eine Fähigkeit, die Spaß macht zu lernen, einschließlich der Fähigkeit, ein Design flexibel zu halten, indem es einfach gehalten wird, frei von Duplizierung und zusammenhängend und entkoppelt, das Design in kleinen, kontrollierten Schritten (= Refactoring) verändert und das Notwendige schreibt umfangreiche Suite von automatisierten Tests, die diese Art von Änderungen sicher machen.
Dies scheint für mich eine viel effektivere Herangehensweise zu sein, als besser bei "vordergründiger Designspekulation" zu sein - und außerdem macht es mich genauso gut auf den unvermeidlichen Moment vorbereitet, wenn das Design aufgrund einer einfach unvorhersehbaren Veränderung geändert werden muss in den Anforderungen.
Teilen, teilen, teilen. Listen Sie all die Schritte auf, die zum Beenden des Projekts erforderlich sind, und listen Sie dann alle Schritte auf, für die diese Schritte abgeschlossen sein müssen, usw., bis Sie atomare Objekte erreichen absolut sicher, dass Sie an einem Tag oder weniger beenden können. Fügen Sie die Dauer all dieser Werte hinzu, um zu einem bestimmten Zeitpunkt zu gelangen.
Dann verdoppeln Sie es. Jetzt haben Sie eine Nummer, die, wenn sie deprimierend ist, zumindest etwas realistisch ist.
Wenn möglich, "Sleep auf Ihrem Design" vor der Veröffentlichung. Ich finde, wenn ich die Arbeit verlasse, denke ich normalerweise an Dinge, die ich vermisst habe. Dies geschieht normalerweise, während ich im Bett liege, bevor ich einschlafe oder sogar am nächsten Tag dusche.
Ich finde es auch wertvoll, einen Peer / Freund zu haben, dem ich vertraue, bevor ich ihn verteile. Jemand anderes sieht fast immer etwas, an das ich nicht gedacht oder falsch kommuniziert habe.
Ich mache gerne, wie andere hier gesagt haben. Notieren Sie im Pseudocode, was der Fluss Ihrer App sein wird. Dies hebt sofort einige detaillierte Bereiche hervor, die möglicherweise weitere Aufmerksamkeit erfordern, die vorher nicht offensichtlich waren.
Pseudocode ist auch für Geschäftsbenutzer lesbar, die überprüfen können, ob Ihr Ansatz ihren Anforderungen entspricht.
Durch die Verwendung von Pseudocode wird auch eine Reihe von Methoden erstellt, die in der endgültigen Lösung als Schnittstelle verwendet werden können. Sobald der Pseudocode ziemlich eng ist, suchen Sie nach Mustern und überprüfen Sie einige gängige GOF-Muster. Sie müssen nicht perfekt sein, aber wenn Sie sie verwenden, können Sie den Code später während der Revisionen, die mitkommen werden, neu schreiben müssen.
Wenn man nur ein oder zwei Stunden pseudo-Code schreibt, erhält man später einige unschätzbare zeitsparende Teile: 1. Ein Objektmodell entsteht 2. Der Programmablauf ist für andere klar definiert 3. Es kann als Dokumentation Ihres Designs mit einigen Verfeinerungen verwendet werden 4. Kommentare können einfacher hinzugefügt werden und sind klarer für andere, die Ihren Code überprüfen.
Viel Glück für Sie!
Ich habe festgestellt, dass der beste Weg, um sicherzustellen, dass Sie ein gutes Design gewählt haben, sicherzustellen, dass Sie das Problem verstehen, die Einschränkungen kennen und wissen, welche Dinge Must-Haves vs. Nice-To sind -haves.
Um das Problem zu verstehen, müssen wir mit den Menschen sprechen, die das Bedürfnis haben, und sie an dem festhalten, was zuerst getan werden muss, anstatt wie sie es für richtig halten. Sobald Sie wissen, was tatsächlich passieren muss, können Sie zurückgehen und über die Anforderungen sprechen.
Wenn Sie Ihre Einschränkungen kennen, ist das ganz einfach: Sie müssen auf dem iPhone laufen. muss eine Webanwendung sein; muss in den bereits vorhandenen Java-Code und das Deployment-Setup integriert werden; und so weiter. Es kann ziemlich schwierig sein: Sie wissen nicht, was die potenzielle Größe Ihrer Benutzerbasis ist (Hunderte? Tausend? Millionen?); Sie wissen nicht, ob Sie es lokalisieren müssen (obwohl, wenn Sie nicht sicher sind, davon ausgehen, dass Sie müssen).
Must-haves vs, nice-to-haves: Dies ist möglicherweise der schwierigste Teil. Benutzer haben sehr oft emotionale Bindungen an "Anforderungen" ("Es sollte genauso aussehen wie Excel"), die nicht wirklich Teil des "muss passieren" Zeug sind. Sie müssen oft Funktionalität gegen Wünsche jonglieren, um eine akzeptable Implementierung zu erhalten. Du kannst nicht immer jedem ein Pony geben.
Achte darauf, dass du alles aufschreibst! Selbst wenn es sich auf dem Weg entwickelt oder das Design klein ist, erleichtert es Ihnen, wenn Sie eine "Dies ist, was wir jetzt vorhaben" Anleitung, wenn Sie eine Entscheidung über das Commit von Ressourcen treffen müssen, sich von der Implementierung zu beschränken eine wirklich coole Whiz-Bang-Funktion anstelle eines langweiligen Must-Do.
Da Sie feststellen, dass Sie das Gefühl haben, eine schnelle Lösung anbieten zu müssen, wird es Sie möglicherweise langsamer machen, um zu erkennen, dass Sie das Problem wahrscheinlich schneller lösen und schneller bereitstellen können, wenn Sie mehr Zeit für das Design aufwenden. Zum Beispiel, wenn Sie 3 Stunden Design und 30 Stunden schreiben Code verbringen, bedeutet es wahrscheinlich, dass, wenn Sie verbringen 6 Stunden Design müssen Sie nur 10 Stunden verbringen Code schreiben. (Dies sind keine tatsächlichen Zahlen, nur Beispiele). Sie könnten versuchen, dies bei den nächsten Projekten, die Sie machen, selbst zu quantifizieren. Machen Sie ein Paar, wo Sie sich wie gewohnt verhalten und sehen Sie, welches Verhältnis von Design / Codewriting / Testen & Debuggen Sie tatsächlich haben. Erhöhen Sie dann beim nächsten Projekt bewusst den Prozentsatz der Zeit, die Sie für die Designphase aufwenden, und sehen Sie, ob sich die Zeit für die anderen Phasen verkürzt. Sie müssen für mehrere Projekte auch versuchen, eine echte Grundlinie zu erhalten, da die Projekte ziemlich unterschiedlich sein können. Machen Sie es als Test, um zu sehen, ob Sie Ihre Leistung in den anderen Phasen verbessern können und somit ein schnelleres Produkt liefern, wenn Sie 20% mehr Zeit oder 50% mehr Zeit oder 100% mehr Zeit für das Design ausgeben.
Denken Sie daran, dass Sie später das Problem mit einem Design finden, das schwieriger (und zeitaufwendiger) zu beheben ist.
Tags und Links design project-management