Tipps & Tricks

• Jegliche Entwicklung findet aufgrund von Aufgabenstellungen statt. Aufgaben können z.B. Weiterentwicklungen, Fehlerbehebungen, Untersuchungen, Ausbildungsschritte sein.
• Jede Aufgabe bekommt eine Nummer und eine Überschrift. Weitere Parameter sind Zugehörigkeit zu einem Produkt, einem Kunden und einem Auftrag, Dringlichkeit der Aufgabe, die jeweilig zuständige Person, zu informierende Teammitglieder, Verknüpfungen zu anderen Aufgaben, Gelöst in, durchgeführter Test. Weiterhin können Dateien einer Aufgabe angehängt werden.
• Jede Aufgabe durchläuft mehrere Zustände. In unserem System gibt es die Zustände:
  
  • Open: Aufgabe ist unfertig
  • inReview: Aufgabe ist aus Sicht des Entwicklers fertig und bedarf der Begutachtung
  • integrate: Wird von uns nicht verwendet, da bei uns Begutachtung und Integration ein Schritt sind
  • onDeck: Auch diesen Zustand verwenden wir nicht
  • Waitcust: Wir warten auf die Rückmeldung eines Kunden, entweder auf weitere Informationen, oder auf Abnahme
  • Deferred: Verschoben, derzeit nicht aktuell
  • Obsolete: Veraltet, Aufgabe wird nicht mehr benötigt, es gibt aber auch kein Ergebnis
  • Rejected: Abgelehnt, z.B. ist dies eine doppelt erteilte Aufgabe
  • Closed: Erledigt, es gibt ein Ergebnis
• Jede Aufgabe beginnt im Zustand Open und endet in einem der Zustände Obsolete, Rejected oder Closed.
• Bei uns findet die Zeiterfassung im Aufgabenbeschreibungssystem statt. Auch Zwischenschritte, wozu auch Fehlschläge gehören, sollen beschrieben werden.
  
  

• Vor dem Zustand Closed liegt der Zustand inReview. Es muss eine positive Begutachtung vorliegen, um einen Fall mit Closed zu schließen.
• Wir arbeiten in der Regel mit Bündeln (Bundles), die wir als Ganzes publizieren. Beim Versionsschema haben wir die Ideen von Cincom aufgegriffen. ^[1]
• Am Ende der Entwicklung steht die Übergabe an den Gutachter mit den notwendigen Angaben, was geändert wurde und welche Tests zu den Änderungen gehören.
• Wir setzten in all unseren Images in den Einstellungen die Option „Always open Merge Tool before performing Merge“ (siehe auch unten).
• Zum Begutachtungsprozess gehören in der Regel folgende Aufgaben:
1. Lesen allen geänderten Codes (mithilfe des Merge-Tools)
2. Überprüfen der Kommentare
3. Ausführen der Testsuite (SUnit)
4. Durchführung der Code-Kritik, wobei wir inzwischen eine erweiterte Version einsetzen, die auch Kommentare prüft
5. Ausprobieren der Anwendung
6. Zurückweisen an den Entwickler bei Problemen, mit klarer Beschreibung der gefundenen Probleme
7. Integration der Änderungen in den Hauptstrang (auch zulässig, wenn die Probleme ausschließlich in Kommentaren liegen)
8. Codeänderungen außer Formatierungen führen dazu, dass der Schritt zu einem Entwicklungsschritt wird und die Aufgabe der Begutachtung an ein anderes Teammitglied fällt. In diesem Fall findet auch keine Integration im Hauptstrang statt.
• Diese Vorgehensweise haben auch schon Industriekunden von uns übernommen und setzen sie erfolgreich ein.
  
  

• Wir haben das Aufgabensystem Mars (Minimal Action Request System) von Cincom übernommen und nennen unsere Aufgaben ebenso ARs.
• Ebenfalls setzen wir ein Store-Unterstützungspaket für diesen Prozess ein, das wir auch schon Kunden in angepasster Fassung geliefert haben. Diese Kunden setzten unterschiedliche Ticketsysteme ein.
• Wir setzen derzeit standardmäßig in VisualWorks 8.2 folgende Resolutions ein:
• Res104181
• Res106266
• Res106722
• Res107008
• Res107022
• Res107179
• Res107211
• Res107278
• Res107284
• Res107302
• Res107311
• Res107345
• Res107477
• Res107522
• Res107547
• Res107701
• Res106667
• Darunter sind einige, die das Arbeiten mit dem Merge-Tool deutlich vereinfachen (Res107008, Res107022, Res107179).
  
  

• Wir verwenden eine Einstellung, durch welche sich das Merge-Tool bei jedem Mergen von Änderungen öffnet
  
  
• Im Published-Item-Dialog von Store kann man erkennen, an welchen Aufgaben gearbeitet wurde. Als weitere Hinweise auf den Reifegrad der Version gibt man auch das Blessing-Level an
  
  
• Es kann auch vorkommen, dass ein Entwickler an mehreren Aufgaben arbeitet, bevor er sie gemeinsam zur Begutachtung abgibt, sichtbar ist dies an den doppelten Aufgabennummern. So kann die Versionsnummer 8.2 - 30 + AR 8887 1 + AR 8897 1 folgendermaßen verstanden werden:
  1. Der Entwickler ist ausgegangen von der Version 8.2 - 30, das ist die 30. Stammversion der eigentlichen Versionsnummer 8.2.
  2. Zunächst hat er an der Aufgabe 8887 gearbeitet und bei dieser Arbeit einmal publiziert.
  3. Anschließend hat er an Aufgabe 8897 gearbeitet, aufbauend auf seiner Arbeit an Aufgabe 8887.
  4. Am Reifegrad Integrated kann man erkennen, dass diese beiden Aufgaben gemeinsam begutachtet und in den Stamm integriert wurden.
• Etwas mehr Versionen kann man an einem anderen Paket erkennen
  
  Hier ist durch das Anklicken zusätzlich sichtbar, dass die Version MARS Client Report
  (8.1.1 - 6 + AR 8887 3 + AR 8897 1,georg) von Daniel integriert in die Version 8.1.1 - 7 wurde.
• Das Merge-Tool zeigt die Änderungen dem Gutachter an
  
  In diesem Fall hat offensichtlich eine Refaktorisierung stattgefunden. So erscheint die nun verwendete Methode reportApplication als neue Methode in der Liste.

Eine Besonderheit gibt es bei uns beim Paar-Programmieren

1. Beim Paar-Programmieren dürfen Programmierung und Begutachtung gleichzeitig stattfinden.
2. Es hat sich als sinnvoll herausgestellt, trotzdem zuerst eine sog. AR-Version zu publizieren und danach den Integrationsschritt mithilfe des Merge-Tools durchzuführen.
   
   1. So wird sichergestellt, dass später die Aufgabennummer in der Versionskette sichtbar ist und...
   2. ...dass keine ungewollten Änderungen in eine Stammversion übernommen werden.

^[1] Versioning

• "Trunk" package versions are of the form <versionprefix><space><dash><space><non-negative-integer>. For example: 7.7 - 1.
• Upon starting work on a new release, bundles and packages must be republished whole with version zero.
• All changes must be backed up by an AR, and all ARs must be merged back into the trunk from their specific, AR versioned packages.