Hallo Rainer,

Hallo Team,

da dies ja nun eigentliche eine Fortsetzung der Diskussion des Meetings ist, bin ich der Meinung, dass jeder auch über den Informationsgehalt informiert werden sollte die zur Verbesserung beitragen sollen.

Daher geht diese Email an alle und ich fände dies gut, wenn andere dies auch tun würden.

Es gibt mit Sicherheit Ergänzungen, Diskussionsbedarf, andere interessante Vorschläge, Problemstellungen und anderen Sichtweisen.

Verbesserungen im Ablauf der Softwareentwicklung

Workflows müssen strukturiert, definiert, für alle zugänglich und von allen eingehalten werden.

Hierzu zählen die wichtigen Punkte

• wie / wann erfolgt ein Hotfix

• wie erfolgt ein Deployment (+Testen im Nachgang)

• was hat das Wort Code Freeze für eine Relevanz / in welchen Bereichen kann dies nicht garantiert werden (z.B. Schnittstellen ändern sich)

Abnahme der Software

Ein großes Problem besteht denke ich auch darin, dass es ein Kommunikationsdefizit zwischen QA und Entwicklern gibt.

Szenario:

• Entwickler: entwickelt ein Feature

• QA: Testet 10 Ansätze (9 Erfolgreich), findet eine Fehler

• Entwickler: behebt diesen Fehler am Folgetag

• QA: Testet 6 Ansätze (5 Erfolgreich), findet einen anderen Fehler

• Entwickler: behebt diesen einen Fehler, kennt aber die anderen erfolgreich getetsten Ansätze nicht und macht an dieser Stelle etwas kaputt.

• QA: Testet 8 Ansätze (8 Erfolgreich) ← scheinbar ja alles ok

Sind die getestet Ansätze immer die gleichen Tests, oder handelt es sich hier um vielleicht 15 unterschiedliche Ansätze. Wurden beim dritten Test von QA eventuell einige Tests vergessen?

Ein Entwickler kann an dieser Stelle nur problemorientiert handeln, er mag vielleicht die 2 Fehler Testen die gemeldet wurden, kann aber nicht immer abschätzen ob der Rest auch funktioniert.

Verbesserung an dieser Stelle:

Einziehen einer Test Managment Ebene. Don´t Panic dies ist ein Stück Software und kein weitere Person. Was sich mit JIRA dann verknüpft. In dem werden dann Testfälle angelegt die vom QA getetstet werden. (http://www.getzephyr.com/)

Es wäre auch möglich automatisierte Tests durchlaufen zu lassen (wollen wir ja aber erst einmal nicht)

Die erfolgreichen / fehlgeschlagenen Tests sind für alle einsehbar.

Man bekommt auch eine Aussage ob noch Punkte getetstet werden müssen die in einer Version x enthalten sind.

Wenn ein Entwickler einen Task erneut geöffnet bekommt, hat er die Möglichkeit „alle“ Tests die für den Task hinterlegt sind auch durchzugehen (ich würde dies sogar bei vielen Themengebieten als Bedingung setzen). Zusätzlich sollte der Entwickler auch selbst noch Testfälle definieren, da dieser ja die systemische Veränderung kennt. Dies sollten den Effekt bewirken, dass der Entwickler mehr zu tun hat und der QA weniger. Dadurch sollten wir hoffentlich in der Lage sein zukünftig weniger Tasks „erneut“ zu öffnen.

Ich glauben nicht, dass nur eine Aussage und sei sie auch auf ein Stück Papier gebracht, dass ein Entwickler gewissenhafter arbeiten soll, dies zu einem andern Bewusstsein führt. Ja, dieses Bewusstsein muss geschärft sein, aber nicht durch Aussagen sondern durch konkrete Methoden.

Hotfixes

Das Thema wurde ja nun bereits besprochen. Es muss für jeden Nachvollziehbar sein wann bei welchem Kunde ein Hotfix durchgeführt wurde. Dies unterstützen wir nun durch eine Email.

Zusätzlich hinterlegen wir dies noch bei den Confluence Seite für das Deployment.

https://confluence.activate.de/display/Dev/Deployment+2.1.9

Deployment

Zusätzlich zur versendeten Email, wird nun auch hier der Zeitpunkt festgehalten wann welcher Kunde ein Deployment erhalten hat. Um Rückschlüsse auf Fehler besser ziehen zu können.

https://confluence.activate.de/display/Dev/Deployment+2.1.10

Hierbei kann ein Test Managment System auch beim Testen der Funktionalität nach Livegang helfen.

Zum Zeitpunkt eines Live Deployments, sollten alle Tests bis ca. 9:00 Uhr dann auch abgeschlossen sein. Also eine Stunde Pro Entwickler zum Testen einplanen.

Fehler die im Livesystem entstehen

Zitat: Wir schreiben hinter Fehlern einen Namen.

Wenn man diese Aussage 1:1 umsetzen würde. Kann man letztendlich folgendes festhalten.

- Wir wissen welche Person(en), wann etwas verursacht hat. (Wichtig!)

- Als Ergebnis bei Entwicklern führt es dazu: gehemmt bei refactorieren/optimieren von teilweise schlechten Bestandscode zu sein.

Was passiert an dieser Stelle nicht:

Was muss an welcher Stelle getan werden um diese Art des Fehlers zukünftig zu verhindern. (Workflow(s) anpassen, Projektierung anpassen, Personal schulen).

Da wir in der Regel in der Vergangenheit von der beschreibenden Planungsphase direkt zur Umsetzung übergegangen sind, haben wir „Design und Analysephase“ oftmals übersprungen. Was dann zur Folge hat, dass man im Nachgang Code den veränderten Anforderungen anpassen muss.

Zudem ergibt sich der Umstand durch Schnittstellen, dass wir im Bereich der Anpassungsprogrammierung tätig sind und nicht die vollständige Tragweite von Änderungen an zentralen Komponenten einschätzen können, trotz zwischenzeitlich vorhandener Quellcode Dokumentation.

Jüngstes Beispiel was bei mir auf dem Tisch lag:

Regeln in der Preiserfassung können nicht mehr sortiert werden. Es wurde von einem anderen Entwickler ein Fehler in JQuery UI eingecheckt (keine neue Version sonder eine veröffentlichte Bugfix Version der betroffen Version) für einen ganz anderen Sachverhalt. Dieser hätte die Tragweite an dieser Stelle nicht abschätzen können. Dieser behob den Fehler und wurde vom QA auch abgenommen. Dieser Entwickler hätte aber nicht wissen können, dass dies an einer ganzen anderen Stelle knallen kann (es ist nirgends Dokumentiert, an welchen Stellen dies alles zum Einsatz kommt)

Was können wir im konkreten Fall tun:

Release Notes von JQuery UI betrachten was diese Fehlerbehebung alles bewirkt hätte. Nachfolgende Releasenotes lesen ob nicht neue Fehler durch den letzten Bugfix enstanden sind. Man hätte nachprüfen müssen, welche Änderungen der Releasenotes mit Problemen im Gesammtsystem konfrontiert sind.

(So etwas passiert in der Regel dann in der analytischen Phase, die wir ja so nicht haben)

→ eine erhebliche Permutation an Situationen die abzuwegen und zu testen sind (so etwas ist vom Zeitaufwand nicht abschätzbar). Wir setzen keine getesten, bewehrten Frameworks mehr ein, sondern entwickeln diese Zukünftig selbst (Wo wir uns bestimmt auch noch ein paar dutzend Fehler einbauen. Das zweite Beispiel schliesst dies dann aber auch wieder aus)

Ein weiteres Beispiel, Kinderpreise werden auf einmal nicht mehr korrekt im Pac berechnet (nur Staging).

OPD hat Bestandhotels mit „Komma“ in der Preiserfassung. Korrekt ist aber ein „Punkt“ (dies wurde vor ca. einem Jahr an der Oberfläche behoben). Allerdings trifft dies nicht auf Bestandhotels vor dem Fix zu.

Was nun durchgeführt wurde. An der Klasse die das Datenobjekt bereitstellt werden die Preise Normalisiert und als „float“ (Dezimalzahl) zurückgegeben. Nun ist es aber so, das PHP keine explizite Typensicherheit bei Variablen kennt (ein grosser Vorteil, an dieser Stelle mit fataler Konsequenz). Dies muss aber dann jeweils auch explizit an der Stelle der Verwendung dann geprüft werden. In Hochsprachen ist eine definierte Variable die einen Datentyp Zahl (Int, Float, etc.) hat immer „0“. Bei PHP ist es ein „NULL“. Wenn man nun sagt man gibt explizit den Datentyp Zahl zurück wird dieser „NULL“ nach „0“ gewandelt, was in nachfolgenden Prozessen aber „scheinbar“ anders behandelt wird. Dieser Prüft nur auf NULL und nicht auf „0“

Was können wir im konkreten Fall tun:

Situation im Workshop schildern (bei 50% bleibt diese Information langfristig hängen).

QA hätte nicht nur diesen einen Buchungsfall prüfen müssen, sondern auch die PAC Generierung für alle relevanten Situation. → Entwickler behebt zukünftig keine Fehler mehr an zentralen Komponenten

Unterm Strich kann bei diesen beiden Fehlern sagen: Dies würde mit vorhandenen Unit Tests nicht passieren.

Daher doch vielleicht nochmal die bitte zur Überlegung zu gliedern wo machen automatisierte Tests Sinn und wo nicht.

In beiden Fällen wäre die Tragweite nicht abschätzbar gewesen und auch der QA Aufwand hätte nicht bewertet werden können.

Zeitliche Planung

Keine Verschiebung von Tasks ohne Rücksprache die bereits in der Vergangenheit begonnen wurden oder erneut geöffnet wurden. Man ist an ein Thema dran und wird an dieser Stelle rausgerissen. Ich selbst und mit Sicherheit andere Entwickler müssen aber auch zusehen das Sie nicht mehrere Themen gleichzeitig bearbeiten (hierfür gibt es aber auch Steuerungsmöglichkeit (IT Gestützt), die dies beschränken).

Ich verfolge ehrlich gesagt lieber den Ansatz, wir wollen in nächster Zeit (3 Monate) folgende Aufgaben fertigstellen und das Projektmanagment kann diese dann in die Versionen einplanen.

Vielleicht doch mal mit Theorien wie Drum-Buffer-Rope oder Kanban (sehr gute Integration in JIRA möglich) auseinandersetzen. Es erfolgt nicht umsonst ein Wandel im IT Changemangment in den letzten 10 Jahren.