Beginnend mit proj stadtchor begann ich kommerziell zu arbeiten (= Erwartungshaltung auf finanziellen Gegenanspruch). Damit verbunden waren die Überlegungen um Preise und Projektmanagement. Nie zuvor hielt ich mich an XP oder andere Konzepte, verwendete hg/git, plante Aufwand/Zeitinvestition oder dachte mir vorab einen Preis aus. Ich muss sagen: jetzt auch noch nicht professionell, aber ansatzweise musste ich mir Gedanken machen und beginne mich an gute Tipps zu halten.
An einer Webseite ist es wohl am einfachsten erklärt: Wenn jemand eine Webseite haben möchte, dann gehe ich einmal her und schreibe eine Textdatei TODO in das Projektverzeichnis. Ist ein Hoster schon vorhanden? Domain bereits fixiert? Stehen Logos und favicons zur Verfügung? Haben wir genug Inhalt? Welche Technologien sollen es sein? Welche existente Software verwende ich? Gibt es Ähnlichkeiten zu anderen Projekten? Und zu guter Letzt: Wann ist das Projekt abgeschlossen und was erwarte ich vom Kunden am Ende?
Dies war die Basis. proj steph wurde genau auf diese Art und Weise geboren. Hierfür benötige ich keine großartige Planung, Software und mache mir keine tiefen Gedanken. Eine simple Textdatei mit Notizen, die mir gerade einfallen. Genau mit dieser Datei komme ich dann zum “Kunden” und bespreche mit ihm Punkt für Punkt durch. Ist alles geklärt, kann das Projekt beginnen. HTML & CSS stand am Anfang, danach kam PHP. Vier wesentliche Elemente mit denen ich mich gerade im Moment beschäftige, sind Roadmaps (setzt Ziele für die nächsten Releases fest), der Sinn von Meetings (Treffen mit Kunden zur Projektplanung), unittests (automatisiertes Testen von Software) und SCM (Source Code Management Systems).
SCM: (ich bevorzuge übrigens hg aus reiner Gewohnheit) wenn man jeder Änderung am Quelltext eine Nachricht zuweisen “muss”, dann beginnt man genauer zu überlegen, was man genau macht und konzentriert sich darauf in den nächsten 2 Minuten nur diesen 1 Bug zu fixen und beginnt nicht wild am Quelltext irgendwas zu verändern, was gerade im Moment nicht zu scheinen passt. Möchte man größere Änderungen machen und weiß nicht, ob die Änderung in Zukunft bestehen bleibt, so “forkt”/”branch”t man das Projekt. Mithilfe des SCM kann man diese Änderungen wieder verwerfen bzw. in den Hauptzweig wieder einfließen lassen. Ganz allgemein möchte ich damit nur sagen, dass Aktionen am Quelltext bewusster wahrgenommen werden, wenn man sie dokumentiert und mit kurzen Stellungnahmen versieht.
Meetings: Faszinierend… manche Kunden stellen überhaupt keine Ansprüche, manche Kunden erwarten eher, dass alles von alleine geht und manche Kunden möchte am liebsten jeden Tag die Fortschritte sehen. Ich bin etwas vorsichtig. Wenn jemand sich treffen will und den Projektstatus besprechen möchte, dann kommen viele Faktoren zusammen und werden gegeneinander abgewägt. Ist für mich alles klar, ich bin mitten in der Arbeit und soll die Arbeit am Projekt für das Projekt unterbrechen, ist das Meeting eher zu vermeiden. Entweder ein Meeting dient dazu Unklarheiten zu beseitigen oder um Motivation für das Projekt zu finden. Mir ist durchaus klar, dass auch der Kunde Unklarheiten haben könnte, aber in dem Fall bemerkt man dies bereits beim Gespräch vorher am Telefon oder im ICQ/Skype. Ein anderer zielführender Faktor um die Sinnhaftigkeit von einem Meeting abzuwägen sind die Kosten. Um es hoch zu rechnen: Ich schätze die Zeit ohne Anfahrtszeit oder sonst was ab (zB 2-3 Stunden), verrechne 10 Euro pro Stunde und wenn ich wegen Punkt 1 ein Meeting unangebracht halte und jetzt auch noch die 2*10 Euro ungefähr/mehr als 20% des erwarteten Preises für das Produkt liegt, dann lehne ich das Meeting auf jeden Fall ab. Letztendlich geht das Projekt bei einem Meeting nicht voran und es wird bloß die Richtung für die Zukunft definiert. 2 Stunden Programmierzeit bringen das Projekt wesentlich weiter als 2 Stunden Meeting, wenn das Ziel ganz definiert ist (PS: Programmieren beim Kunden geht IMHO wegen der Konzentration gar nicht).
Roadmap: Mithilfe einer Roadmap teilt man sich die Zeit genauer ein. Man stellt klare Ziele und versucht einen Zeitplan einzuhalten. Langfristiges Planen. Man überlegt bei jedem Punkt ob dieser essenziell für ein Projekt ist und wenn er nachrangig ist, so verwirft man ihn leichter. So kommt man nicht auf spontane Ideen.
unittests: Software soll stabil sein. Mit unittests ist Software bei mir grundlegend wesentlich stabiler geworden. unittests verlangen aber auch, dass die Problemlösung bereits vorher ganz klar definiert ist. Schreibt man eine Methode um, so ist die Zeit des unittest-Schreibens verlorene Zeit. unittests sollte man vorwiegend vor der Implementierung schreiben. Manchmal ist es auch nachher sinnvoll.
Recent Comments