9. Entwicklung bei XING
• Standing Teams (1 Team = 1 Domäne)
• SCRUM
• Üblicherweise 2 Wochen Sprintlänge
• kleine Arbeitspakete => große Features
• schnelle Fixes auch außerhalb des Release
Cycle
• KANBAN
• Maintenance
• Kleine, täglich ändernde Aufgaben
• Alle Teile der Plattform ohne Standing Team
11. QA bei XING
• sitzt im Team vor Ort, kennt gesamte
Plattform und insbesondere eigene Domäne
• Eigenverantwortlich im Team
• alle Team-Meetings
12. QA bei XING
• sitzt im Team vor Ort, kennt gesamte
Plattform und insbesondere eigene Domäne
• Eigenverantwortlich im Team
• alle Team-Meetings
• QA Meetings zur Abteilungs-Kommunikation
• Zusätzliches übergreifendes Team für
Testinfrastruktur, Prozesse usw.
14. Gelerntes
• Frühe Einbindung ist wichtig
– Produktvision ist im Team bekannt
– Gemeinsames Produktverständnis im Team entwickeln
– Zusammenarbeit mit dem Produktmanager ab der Spezifikation
– Verschiedene Perspektiven führen zum besseren Produkt
– Fehler vermeiden statt finden
http://www.gridshore.nl/2008/12/30/defects-lean-software-development-offshore-oh-my/
15. Gelerntes
• Frühe Einbindung ist wichtig
– Produktvision ist im Team bekannt
– Gemeinsames Produktverständnis im Team entwickeln
– Zusammenarbeit mit dem Produktmanager ab der Spezifikation
– Verschiedene Perspektiven führen zum besseren Produkt
– Fehler vermeiden statt finden
• Kurze Feedbackzyklen schnelle
Problemlösung
– Durch tägliches Standup bleibt das Team auf dem laufenden
– Defects direkt mit Entwicklern besprechen
– Leichtgewichtiger Prozess zum Defect Management
16. Gelerntes
• Frühe Einbindung funktioniert
– Produktvision ist im Team bekannt
– Gemeinsames Produktverständnis im Team entwickeln
– Zusammenarbeit mit dem Produktmanager ab der Spezifikation
– Verschiedene Perspektiven führen zum besseren Produkt
– Früh potentielle Nebenwirkungen feststellen
– Fehler vermeiden statt finden
• Kurze Feedbackzyklen schnelle
Problemlösung
– Durch tägliches Standup bleibt das Team auf dem laufenden
– Defects direkt mit Entwicklern besprechen
– Leichtgewichtiger Prozess zum Defect Management
– Bei Bedarf schnelle Anpassung der Produkt-Spec mit
Produktmanager
– Kein Warten
17. Gelerntes
• QA kennt das Produkt am Besten -
Ansprechpartner für alle
– Durch hohen Detailierungsgrad beim Testen Kenntnis aller Details
– Berater für den Produktmanager und andere Abteilungen
– Third Level Support
• QA bleibt in einer beratenden Rolle,
Produktmanager entscheidet am Ende
– Testergebnisse dienen als Basis für die Entscheidung
– Keine blinden Entscheidungen, Schwächen sind bekannt
– Unterstützen statt kontrollieren
18. Gelerntes
• Agil ≠ Chaos
– Definierte Prozesse werden eingehalten …
– … aber an die Bedürfnisse angepasst
– Prozessänderungen finden kontrolliert statt
– Kurze Iterationen erlauben schnelle Reaktionen = Evolution
http://students.idv.edu/~9856816/evolution.jpg
19. Gelerntes
• Agil ≠ Chaos
– Definierte Prozesse werden eingehalten …
– … aber an die Bedürfnisse angepasst
– Prozessänderungen finden kontrolliert statt
– Kurze Iterationen erlauben schnelle Reaktionen = Evolution
• Kein Eingriff während der Sprints
– Team ist vor Eingriffen und Umpriorisierung geschützt
– Externe Abhängigkeiten vor der Entwicklung klären / beseitigen
– Ziel: Alle Aufgaben im aktuellen Sprint abschließen
– Nach jedem Sprint ein lieferbares Ergebnis vorhanden
– Jeder Sprint kann der letzte sein
20. Gelerntes
• Agile QA funktioniert
– Nutzen wurde von den Entwicklern erkannt
– Unterstützung der QA durch andere Teammitglieder
– Gefühl der Sicherheit im Team
– Durch kleine Arbeitspakete überschaubares Testen…
– … und weniger Arbeit
– Erfolgserlebnis nach jedem GoLive
Releases im Jahr
50
21. Gelerntes
• Agile QA funktioniert
– Nutzen wurde von den Entwicklern erkannt
– Unterstützung der QA durch andere Teammitglieder
– Gefühl der Sicherheit im Team
– Durch kleine Häppchen überschaubares Testen…
– … und weniger Arbeit
– Erfolgserlebnis für das Team nach jedem GoLive
– Möglichkeit Kundenfeedback einzuarbeiten
23. Gelerntes
• Agile QA funktioniert
– Nutzen wurde von den Entwicklern erkannt
– Unterstützung der QA durch andere Teammitglieder
– Gefühl der Sicherheit im Team
– Durch kleine Häppchen überschaubares Testen…
– … und weniger Arbeit
– Erfolgserlebnis für das Team nach jedem GoLive
– Möglichkeit Kundenfeedback einzuarbeiten
– Mehr Spaß durch mehr Abwechslung
• Teamübergreifende QA bei Kooperationen
26. Gefahren
• Aus großer Kraft folgt große Verantwortung
– Team muss sich evtl. gegen falsch verstandene Agilität wehren
– Kein blindes Einhalten von Regeln
• Burnout & Gruppendynamik
• Großes Bild nicht aus den Augen verlieren
• Agil ≠ Chaos
27. Vielen Dank
für Ihre Aufmerksamkeit!
sergej.mudruk@xing.com
tobias.geyer@xing.com
Notes de l'éditeur
Tobierklärt Agenda
WeristMitlied?Führendes Business-NetzwerkimdeutschsprachigenRaum (DACH) + Spanien und TürkeiHiereinpaarZahlen:
Tobi:Standing teams konzentriert auf einenTeilderPlattform, ca. 5 - 12 MitgliederVorallem SCRUM, aberauchKanbanWirentwickelnauchThemenwie Billing agilMan kannjedeWoche live gehen, muss abernicht
Sergej: QA wurde 2008eingeführt, anfangsnur 3 Personen (konzentriert auf einemProjekt (nicht SCRUM))Heute – über 15 Mitarbeiter, Tendenzsteigend… Kleiner Tip: wirstellenein!
Sergej: Präsenz fast in jedem Team – vor Ort (heißtauch, dasswirQa in Spanienhaben)…Spezialisierung auf einebestimmteDomäne+PlattformübergreifendesWissenJederistEingenverantwortlichfür den gesamten QA-Bereich: - Allrounder: methodisches und technischesWissenVon derTestplanungbiszurAutomatisierungVollständig in den Scrum-Prozessintegriert – Teilnahme an allen Meetings, gleichesMitspracherecht, wiealleTeammitglieder…
Tobi:Zusätzlich zu den Team-Meetings gibteseinmal pro Wocheeinübergreifendes QA MeetingDort AustauschüberanstehendeÄnderungen die allebetreffen, Best Practices, Zugriff auf Erfahrungderanderen QA Mitglieder, Vorträge, …Außerdemneben den QA Mitarbeitern in den Projekteneinübergreifendes Team fürInfrastruktur, Prozesse, …
Sergej:Ichhab den Einführung und Etablierungder QA imUnternehmen (insbesondere des SCRUM-Prozesses) von Anfang an begleitet, wo die QA zumersten Mal in einagilesProjektintegriertwurde:Und kannsagen, dasswir (als Firma und insbesonderealsQa-MitarbeiterdabeieineMengegelernthaben), was nichtimmereinfach war…
Sergej:UnsereErfahrungenzeigen:FrüheEinbindungallerbeteiligten von einemgroßemVorteilistEineallenbekannteProduktvisiondefiniert das Ziel auf das man hinarbeitenkann (gemeinsamesProduktverständnisvermeidet “an einandervorbeientwickeln” ) das heißteinebewußteEntwicklung und nicht ins Blauehinein das heißtjeder Sprint - einekleineEtappe = SchrittzumgroßenGanzenQA beginntbereitsbeidergeneinsamen (mitdemProduktmanager) Entwicklungder Spec dadurchentstehteineausreichenddetailierte Spec, die wenigSpielraumfürZweideutigkeiten hat (wirhabeneineandereSicht auf das Produkt) wiebekanntpräventiveFehlersindbilligeFehler, Vermeidenbedeutetauch: Nebenwirkungenfeststellen
Tobi:Durch Integration im Team bleibt man immer auf demlaufenden und bekommt alleys mit. iPods sindkeineguteIdeeTägliches Standup hilftebenfallsdemgesamten Team Blocker zu erkennen und zu beseitigen.Defects schnellmelden und direktbesprechen Wennsieinnerhalb des Sprints gefundenwerdengibteseinensehrleichtgewichtigenProzess:
Tobi: SchelleAnpassung: WennwährendderEntwicklungbessereLösungengefundenwerden, könnensieeinfachübernommenwerden (mit PO abgesprochen)KeinWarten = kein Mini-Wasserfallwennmöglich, auchZwischenständeanschauen und Rückmeldunggeben
Sergej:UnsereErfahrung hat gezeigt, dass die QA das Produkt am detailiertestenkennt, dadurch, dasswirbeimTestenversuchenalle Edge-Cases zu finden und abzudecken. Deswegenfungierenwir:AlsersterAnsprechpartnerfür die Produkmanager, wennsieFragen zu einerbestimmtenFunktionalitäthabenalsdritte Station, wennKunden-Fragenentstehen und vom Support (1st und 2nd Level) nichtbeantwortetwerdenkönnen (hierbeiEntscheidungen, ob es Bugs sindoder Features) falls Fragenbei den anderenKollegenentstehen – halt antworten (BI, Marketing, Produktmanager)Qa-Positionierung in Teams istmeistensberatende und nichtKontrollierendeRolle:Wirsagen, was die SacheistderProduktmanagerentscheidet, ob esfürihnakzeptabelist:Das heißetkeineblindenEntscheidungen, sondern, wenn, dannmeistensbewußte und bekannteSchwächenDadurchwird die QA zu einerUnterstützungbeimEntwicklungsprozess und nichteinem “gefühlten” Klotz am Bein
Sergej:anders, alses von vielenverstandenwirdistAgilnichtgleich “ichmachealles, was ich will” SCRUM hat schonvordefinierteProzesse und das Scrum Skelettwirdabhängig von den Teams mitLebengefüllt:Es werden die grundsätzlichenRegelneingehaltenAber was nichtfunktioniert wirdverändert (eswirdständigausprobiert und experimentiert, um das beste (passendste) Ergebnis zu erreichenStändigbedeutetdabeidassnachjedem Sprint mitdemgesamten Team entschiedenwirdwelcheKorrekturenvorgenommenwerden das bedeutetnämlichkurzeReaktionszyklen, wennnötig, aberkeineAnarchie
Tobi:Innerhalbeines Sprints dürfennurmitdem Team abgesprocheneÄnderungen an der Spec vorgenommenwerden, das Team hat das Recht “Nein” zu sagenUm die Aufgabenauchwirklichfertigstellen zu könnenmüssenexterneAbhängigkeitenbeseitigtbzw. Minimiertwerden.AngenommeneAufgabenmüssen am Ende des Sprints fertiggestelltsein in einerQualitätdassder Code live gestelltwerdenkann.DerGrunddafüristeinfach: Jeder Sprint kannderletztesein.Entwederweil das Team umverteiltwirdoderweilsich das Thema / die Prioritätenändern.Beispielausder Praxis:Company Profiles: 2 Tagevor Sprint-EndeneuerFokusfür das Team, mitdemnächsten Sprint konntemitvoller Kraft darangearbeitetwerden.
Tobi:FrühergaltausSichtderEntwickler: “wofür QA?” Heute gilt: “NichtohnemeinenQaler” / “Wirkönnen das nichtabschließenweil die QA fehlt”Es wurdeverstandendass QA keinKlickroboteristsonderneinzigartiges, nützlichesWissenbesitztWieschongesagt: QA = Unterstützung, nichtzusätzlicheBelastung / Kontrollinstanzvorder man Angst haben mussUnterstützungdurch das Team: TechnischeUnterstützungzurbesserenTestbarkeit, Testdatengenerierung, … / “Kannich das fürdichtesten?”Dank QA entstehteinGefühlderSicherheitdassder Code den man auf die KundenloslässtauchfunktioniertDurchkurze Sprints werden die Aufgabenüberschaubar, d.h. WenigerArbeitIn der Praxis gilt: Rettet die Bäume – keine 20 Versioneneiner 300 Seiten Spec. KeinPingpong, keineriesigen Teams kurzeKommunikationswegeErfolgserlebnissenachjedem Sprint, man siehtwie die neuenFunktionenvomKundengenutztwerden.
Kundenfeedback: Auchwennfunktionalalles gut istkann das Produktverbesserungswürdigsein. Dank Agilistdiesemöglich
Tobi:Spaß: NichtwochenlangTestfälleschreiben, sondernschnellhintereinanderTestfälle, Ausführung, Defects, …Sergej: Dadurch, dasseinigeFunktionenPlattformübergreifendsind, entstehtderBedarfderKooperationzwischen den Qalernverschiedener Teams:WirunterstützeneinanderüberTeamgrenzenhinwegAgierenberatendbeiFragenEntwickelngemeinsameTeststrategienHelfenmit den TestdatenWas sichsehr oft alsextremzeit- und Aufwandsparenderweist und etwasSicherheit/Rückendeckunginnerhalbder QA bietet….
