Hallo Viktoras und Stefan

@all

Ich möchte die richtigen Anmerkungen von Dir Viktoras und Dir Stefan nicht kommentieren,

denn sie sind richtig und man kann sie nur etwas unterschiedlich priorisieren oder formulieren.

Viel wichtiger ist mir der Prozess in dem wir uns befinden.

Letzte Woche war ich auf einer Travel Tech Konferenz in Köln und habe eine Podiumsdiskussion

von 3 Startups verfolgt. (Habe ich auf Grund der Kürze des Meetings heute weggelassen, passt hier aber gut.)

Die folgenden wesentlichen Aussagen habe ich mitgenommen:

- Fuck it – ship it

o Nicht lange drüber nachdenken, ob etwas noch besser, schneller, etc. werden kann

o Raus zum Kunden und schnell auf Fehler reagieren

o Ist sicher einerseits zu Bedenken, was bei uns alles dran hängt und kaputt gehen kann

o Andererseits müssen und können wir schneller werden und dabei auch den Ansatz von Sören aus dem Meeting im Hinterkopf haben

o Wie können wir schneller Ergebnisse produzieren und uns mit überschaubaren Schritten größeren Zielen nähern
Natürlich dabei keine inkonsistente und fehlerhafte Situation erzeugen

- Die besten Mitarbeiter finden und denen komplexe Aufgaben und Verantwortung übergeben

o Ich bin schon sehr froh welches Team wir inzwischen haben

o Klar geht immer mehr und immer besser aber wir sind auf dem Weg und ich bin sehr zufrieden

o Viele werden jetzt denken und wie ist das mit der Verantwortung

§ So wie im ersten Punkt

§ Ihr könnt sie euch nehmen und ausfüllen

§ Ein klare Aufforderung an z.B. Viktoras weiter solche Mails zu schreiben oder Ideen wie die Paketierung anzugehen

§ Ich werde sehr gerne immer mehr abgeben – versprochen

§ Natürlich wird nicht alles sofort perfekt, solange es besser wird sind wir auf dem richtigen Weg

o Allerdings, es muss halt funktionieren und das tut es immer besser,
sonst müssten wir nicht überlegen, wie wir die nächsten Schritte angehen.

Mit freundlichen Grüßen / Best regards

Haiko Gerdes
- Geschäftsführer / Managing Director –

___________________________________________________________________________
TraSo GmbH
Georg-Schumann-Str. 294

D-04159 / Leipzig

Tel.: +49 341 355 740 – 10 // Fax: +49 341 355 740 - 11

Mobil: +49 172 610 2849

Internet: http://traso.de E-Mail: h.gerdes@traso.de
___________________________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850

Von: team [mailto:team-bounces@lists.traso.de] Im Auftrag von Stefan Rank-Kunitz
Gesendet: Mittwoch, 27. April 2016 13:36
An: team@lists.traso.de
Betreff: Re: [Team] Arbeitsprozess Meeting: Minority Report VBE

Hallo Viktoras,

Zuerst VIELEN Dank für Deine Rückmeldung. Ein Ziel des Gesprächs heute MUSS es sein, die Diskussion weiter zu führen und Stück für Stück den Workflow unseres Unternehmens zu optimieren. Emails wie Deine tragen dazu bei! Einer Anregung von Marcus folgend schlage ich vor, dieses Gespräch in 4 oder 6 oder 8 Wochen zu wiederholen und auf diese Weise dauerhaft Kritik und Optimierung in unsere Arbeit aufzunehmen!

Aus meiner Sicht muss das "Testing"/"Überwachung" von xRes- und xMid-Systemen 3stufig sein:

automatisiertes Testing
manuelles Testing
Überwachung im Livebetrieb

Zu 1:
Deine Vorschläge für ein weitergehend automatisiertes Testing nehme ich sehr gern auf. Bereits vor längerer Zeit habe ich den Einsatz von Selenium und die Erweiterung von PhpUnit-Tests vorgeschlagen, beides sind aber Prozesse, die einige Zeit brauchen und erst zukünftig zu einer Reduzierung des manuellen Testings beitragen werden.
Wir sind dort aber auf einem sehr guten Weg (wir haben in 1,5 Jahren fast 2500 einzelne UnitTests erstellt) und ich BITTE Dich, dies auf diese herausragende Weise fortzusetzen.

Zu 2:
Was wir leider durch Automatisierung nicht lösen können, ist "miteinander zu sprechen" und "selbstständig zu denken". Ein automatischer Test:

hat eine begrenzte Reichweite (d.h. er testet nur vorgegebene Szenarien und begrenzte Komplexität),
ERSETZT nur dann einen manuellen Test, wenn der menschliche Tester von Existenz und Umfang des automatischen Tests weiß,
kennt die inhaltlichen Prozesse und Workflows der Veranstalter nur im einprogrammierten Umfang
findet keine Seiten-Effekte zu einer vorgenommenen Änderung

An diesen Stellen werden wir manuelles Testing weiterhin brauchen und müssen dieses aus kapazitiven Gründen durch die Entwicklung unterstützen. Zur Entlastung des Support ist es erforderlich, dass Entwicker das manuelle Testing vor-arbeiten durch

automatisches Testing UND dessen Dokumentation im JIRA-Task
manuelles Testing UND dessen Dokumentation im JIRA-Task
Hinterfragen / Abstimmen / Rückfragen zu Ist- und Soll-Zustand einer Aufgabe UND deren Dokumentation im JIRA-Task.

Zu 3.
Deine automatischen Report-Emails zum Thema Hotel und Flug sind wirklich große Klasse und entlasten den Support erheblich! Wenn Du dieses Vorgehen mit Carsten sogar noch erweiterst, hat dies meine volle Unterstützung!
Leider finden diese Reporte ein Problem frühstens dann, wenn es in einem xRes-Livesystem auftritt und kann damit Schritte 1 und 2 als präventives QM nicht ersetzen.

Fazit:
Haiko und ich haben heute vorgeschlagen, die Arbeitsweise der TraSo an den folgenden Punkten zu verbessern:

geänderter Release-Zyklus:
Es wird (besonders für den Support) vorhersehbarer und steuerbarer, was in einem Release enthalten ist und die Kunden-Kommunikation kann entsprechend optimiert werden.
Die zeitliche Differenz zwischen "Ich habe mal einen Task erstellt" und "Ich muss eine Änderung testen, habe aber den Task längst wieder vergessen" geringer. Darüber hinaus erfolgt die Testing-Rückmeldung des Support an den Entwickler zeitlich kürzer (nach der Entwicklung) und nachträgliche Anpassungen / BugFixes erfordern weniger "Hinein-Denken".
Im Sinne des Kunden sind wir in der Lage, dynamischer auf Kundenwünsche / -probleme einzugehen und arbeiten enger an der Anforderung.
Arbeit mit dem JIRA: Dort herrschte von allen Seiten große Unzufriedenheit und undurchsichtiger Task-Wildwuchs. Durch mehr Abstimmung und bessere Dokumentation werden wir dabei besonders dem Support gerecht. Auf der anderen Seite werden wir der Entwicklung damit gerecht, die immer wieder Tasks zurück gehen lässt und diese damit (teilweise längere Zeit) in eine unnötige Warteschleife schickt.
Unterstützung des Testings durch die Entwicklung: Deine Vorschläge (und Umsetzungen) zu automatisierten Tests und automatischem Monitoring finden meine volle Unterstützung. Dennoch betrachte ich sie als Teil eines weiter gefassten Qualitätsmanagements (siehe oben 1-3) und bin der Überzeugung, dass die heute eingeführten Maßnahmen unsere Prozesse ZUSÄTZLICH optimieren.

VG SRK

Mit freundlichen Grüßen

Stefan Rank-Kunitz

 - Lead Developer -

________________________________________________________

TraSo GmbH

Georg-Schumann-Str. 294

D-04159 Leipzig

Tel.: +49 341 355 740 - 43

E-Mail: s.rank-kunitz@traso.de

________________________________________________________

Handelsregister: Amtsgericht Leipzig, HRB 21850

Am 27.04.2016 um 11:56 schrieb Viktoras Bezaras:

Hallo Team,

leider sind unsere Meetings Zeitlich sehr limitiert und es ist nicht möglich alle Meinungen zuzuhören. Und ich bin der Meinung, dass die Vorgeschlagene Änderungen in großer Ordnung nichts oder sehr wenig bringen. Bisschen bessere Planung, bisschen bessere Kommunikation, ja schön. Löst das Problem, dass Support überfordet ist nicht.
Für mich ein kritischer Punkt ist: Entwickler müssen die Code Anpassugen selber testen und dann ein Test log schreiben, ansonsten werden die verfolgt. Das Problem an der Stelle ist, dass Teil 1 "selber testen" ist absolut richtig, währen Teil 2 bringt nichts und ist, meiner Meinung nach, schädigend. Ah ja, und löst das Problem immer noch nicht. Man bekommt dadurch nur Stress und Ärger, und den haben wir schon genug in unserem Alltag.
Wir sind 9 Entwickler, Support ist 6 Leute. Wir werden nicht weniger "Ausgabe" produzieren, Support wird immer noch nicht weniger testen müssen. Außer wenn die Idee ist durch noch mehr Jira-Verkehr und nicht-entwicklungs-Aktivitäten den Entwicklern bremsen.
Ich denke, wir müssen unseren Support dadurch unterstützen, dass wir für Support die Tools geben/bauen sollen. Wir selber benutzen gern git und stash, und bamboo, und phpstorm u.s.w. Weil die Tools manche Aufgaben automatisieren. Warum möchten wir denn nicht so viel wie möglich Support Aufgaben automatisieren? Ich selbe nehme die Schritte: Autocheck für Hotels und jetzt Flugcheck, und ich habe schon mit Carsten abgesprochen für ihm auch das gleiche machen. Mit Hotelcheck haben wir schon sehr viel Probleme sehr schnell gefunden. Und das reduziert die Last.
Die Unit-Tests sind auch sehr wichtig, obwohl, das hat direkt nichts mit Support zu tun. Meine erste Aufgabe bei Traso habe ich mir selber angelegt und in den habe ich nur Unit-Tests für MTS geschrieben. Heute sind bis zu 50% der Unit-Tests von mir. Das bedeutet, viele Bugs sind schon beim Testing gefunden, und nicht im Support. Und das reduziert die Last.
Es gibt auch weitere Test Tools, wie z.B. Behat und Selenium. Man kann die Tests für die Oberfläche machen, oder für die bestimmte Funktionalität. Z.B. Test-Fall: neues Hotel im xAdmin anlegen, oder ein Flug löschen. Würden wir 1000 solche Test-Fälle haben, werden wir sicher, dass die Funktionen funktionieren so wie erwartet. Und das ist möglich täglich automatisch prüfen. Und das auch reduziert die Last.
Es gibt noch viele weitere Tools für z.B. Monkey-Testing (das Tools versucht das System kaputt zu machen durch chaotische Angabe), oder auch Monitoring Tools, sodass wir die Probleme schnell finden, bevor die Kunden sich melden.
Ich glaube das ist die Richtung, die wir gehen sollen. Wenn wir natürlich nicht zu Beschäftigt für die Innovationen sind.

Viele Grüße
Viktoras
-- 
 
Mit freundlichen Grüßen
 
Viktoras Bezaras
 - Entwickler -
________________________________________________________
TraSo GmbH
 
Georg-Schumann-Str. 294
D-04159 Leipzig
Tel.: +49 341 355 740 44
 
E-Mail: v.bezaras@traso.de
Internet: http://www.traso.de
 
________________________________________________________
Geschäftsführer: Haiko Gerdes
Handelsregister: Amtsgericht Leipzig, HRB 21850
_______________________________________________
team mailing list
team@lists.traso.de
https://lists.traso.de/listinfo/team