Das Handwerkszeug des Projektteams

In diesem Post soll es um das Handwerks-Zeug aller Akteure in der Software-Entwicklung gehen.
Welche Tools benötigen die Akteure nun, um ihre Aufgaben zu erfüllen?
Wo notiert der Product Owner seine Anforderung? Wo speichert der Entwickler seinen Quellcode? Und worauf greift der Tester zurück, wenn er das Produkt installieren will?
Es gibt mindestens 3 Werkzeuge, die für ein Gelingen vorhanden sein sollten. Weitere Werkzeuge können sinnvoll sein, abhängig von der Situation.
  1. Das Ticketing-System,

    auch als „Bug-Tracker“ bezeichnet, ist eigentlich viel mehr als eine Sammlung
    Es ist die zentrale Anlaufstelle, um alle Änderungswünsche „mundgerecht“ zerlegt auszutauschen:
    * Der Product-Owner kommuniziert seine Wünsche
    * Die Qualitätssicherung meldet Programmfehler („Bugs“), die während vor der Veröffentlichung, dem Release des Produkts aufgefallen sind
    * Der Support meldet Programmfehler, die von Kunden berichtet wurdenJedes Ticket besitzt seine eigene Geschichte, und man kann im Prozess verfolgen, wer ein Ticket bearbeitet hat, und ob bzw. wie es gelöst wurde.Das Ticket-System bildet sozusagen den Dreh- und Angelpunkt der Planung und gibt detaillierten Aufschluss über die Historie bzw. die zukünftige Planung.

  2. Das Repository, auch als Projektarchiv bezeichnet

    Es beinhaltet den nachvollziehbaren Versionsstand einer Software.
    Hier werden alle Quelldateien der Entwicklung eingestellt und alle Änderungen nachvollzogen. Dies ist sozusagen Ihr Kapital, Ihr Projektschatz.
    Sie sind in der Lage Änderungen bis zum Beginn des Projekts zurückzuverfolgen und, falls erforderlich, wieder rückgängig zu machen.

  3. Der Build-Server

    Im Rahmen der Nachverfolgbarkeit ist der Build-Server die Umgebung, die aus einem Software-Stand aus dem Repository immer wieder dieselbe Version an Software liefern kann – auch nach Jahren!Nur die Software, die vom Build-Server gebaut worden ist, kann als vertrauenswürdig und reproduzierbar angesehen werden.Einmal fertig konfiguriert, liefert der Build-Server eine Software-Version, die Sie direkt auf Ihrer Zielumgebung installieren können.

Theoretisch ist es natürlich auch möglich, die Anforderungen per Email zu senden, anstatt Bugtickets zu schreiben, dem Entwickler zu zeigen, was „schief läuft“. Man nimmt dann allerdings in Kauf, dass man nach einigen Jahren nicht mehr weiss, wie man sich mal geeinigt hat. Auf ein Ticketingsystem hat jeder Zugriff, die Mails sind typischerweise nur für persönlich durch einen Mitarbeiter zugreifbar.
Und auch ohne Repository kann man die Daten archivieren: Man erstellt einfach ZIP-Dateien mit dem Tageswerk. Nur fragen Sie sich dann, wann denn die Änderung X eingeflossen ist. Spätestens, wenn Sie mehrere Entwickler auf einem Projekt haben, wird es jedoch unübersichtlich!
Ein Build-Server ist sicherlich die Komponente, die am ehest verzichtbar ist. Eine Software „von Hand“ compiliert und ausgeliefert werden. Allerdings wird man vermutlich Schritte vergessen, die Reihenfolge der Schritte verändern oder vergessen, eine Datei zu übertragen. Und dann haben Sie die Software beim Kunden, und sie läuft nicht.
Glauben Sie nicht? Alles schon erlebt…