Die Aufwärmphase vor der Projektvorstellung

Eigentlich hatte ich zwar im letzten Beitrag versprochen, dass ich als nächstes das erste Projekt vorstellen werde. Aber ich wollte erstmal noch meine Vorgehensweise bei allen kommenden Projekten erklären.

Mir kommt es ja auf Konsistenz an, die ich bei allen Projekten anstrebe.

Die Vorstellung der Projekte

Jedes Projekt wird nach folgendem Schema vorgestellt werden:

• The Big Picture
  Unter dieser Überschrift werde ich meine Vorstellung von der zu entwickelnden Software präsentieren. Was soll sie am Ende mindestens können? Was sind meine persönlichen "must-have"-Features? Es wird eben ein grober Überblick gegeben, um Appetit zu wecken. ;-)
• Herausforderungen und mögliche Schwierigkeiten
  Jedes Projekt wird das ein oder andere Feature enthalten, was ich so noch nie zuvor implementiert habe. Das könnte also Schwierigkeiten machen oder eben sehr knifflig sein. Diese möglichen Stolpersteine werde ich hier aufzählen.
• Der erste Schritt
  Jedes Projekt fängt erstmal klein an. Daher definiere ich unter diesem Punkt die Features der ersten Iteration.

Gemeinsamkeiten aller Projekte

• Sie tragen einen weiblichen Name. (Die Erklärung, weshalb das so ist, habe ich ja schon im letzten Beitrag geschrieben.)
• Die Root-Bezeichnung meiner Namespaces wird entweder die Initialen CGO oder SachsenCoder tragen.
  
  Ich tendiere aber zu SachsenCoder. Das erscheint mir weltweit eindeutiger zu sein.
• Die Projekte werde ich bei github veröffentlichen. (Hoffentlich klappt das auch alles so. Ich habe bisher nur lokale Git-Repositories verwendet. *g*)
  Innerhalb der github-Umgebung werde ich primär alle Texte auf Englisch verfassen. Das macht sich besser, falls doch mal jemand an dem Projekt mitmachen will. So ist es dann wenigstens international verständlich. (Auch, wenn mein Englisch sicher nicht ganz so erstklassig ist. *g*)
• Alle Projekte werden als Basis .NET-Framework 4.0 verwenden.
• Die Sprache selber wird C# sein. (Das ist die einzige Sprache, dessen Syntax mir wirklich gut gefällt!)
• Alle Projekte werden im AppKata-Stil aufgezogen und nach der Spinning-Strategie angegangen. Das heißt, es gibt viele überschaubare Iterationen auf den Weg zum Big Picture und darüber hinaus. Jede Iteration soll einen kleinen, aber echten Nutzen hervorbringen. Jede Iteration wird je nach Komplexität in unterschiedlich kleine Slices aufgeteilt, damit ich/man von den Anforderungen nicht gleich erschlagen wird und ein Problem zeitnah gelöst werden kann.
  Ich halte dieses Vorgehen für unerlässlich, um die Motivation aufrecht zu halten.
• Spätestens nach jeder Iteration (oder dem ein oder anderen Slice) werde ich öffentlich darüber reflektieren, wie es gelaufen ist. Stellten sich die voraussichtlichen Schwierigkeiten wirklich als Hürde heraus? Wenn ja, warum? Wenn nein, warum nicht? Ist die Motivation noch gegeben oder steuere ich auf eine Lustlosigkeit zu? Bin ich mit der entwickelten Lösung zu Frieden? Entspricht sie den gegebenen Anforderungen? Gibt es Möglichkeiten der Verbesserung? Kann ich diese Verbesserungen umsetzen oder komme ich da an eine Know-How-Barriere?
  Diese Art der Reflektion soll mir dabei helfen, die Sachen, die ich da entwickelt habe, nochmal bewusst zu machen. Es soll auch verhindern, dass ich in eine "Frickel"-Ebene abdrifte.
• Die Entwicklung wird weitgehend gebloggt werden. Das heißt, die Lösungsfindung mache ich quasi öffentlich. So, als wenn ich laut denke oder jemanden meinen Lösungsweg erkläre. (Sicher werden mir dabei auch selber eventuelle Denkfehler auffallen.) Zudem gibt es anderen die Möglichkeit, die Entwicklung von Anfang an nachzuvollziehen. (Kann ja sein, dass am Ende wirklich geile Tools dabei rauskommen. Dann ist es doch fantastisch, wenn gerade sowas verständlich dokumentiert ist. Das ist ja im Open-Source-Bereich nicht selbstverständlich.)

Unter'm Strich soll die Entwicklung einen professionellen Charakter bekommen.