XING Agile QA

2.150 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie, Sport
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.150
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
61
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Tobierklärt Agenda 
  • WeristMitlied?Führendes Business-NetzwerkimdeutschsprachigenRaum (DACH) + Spanien und TürkeiHiereinpaarZahlen:
  • Sergej:Enwicklungfindetstatt:In demHauptsitz (Hamburg)In Spanien (Barcelona)
  • Tobi:EinpaarWortezumEntwicklungsprozessbei XING
  • 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 sindkeineguteIdeeTä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….
  • Tobi:Wirwollenehrlichsein:AgilesVorgehenbringtauchGefahrenmitsich
  • XING Agile QA

    1. 1. Sergej Mudruk & Tobias Geyer XING AG Oktober 2010 Agile QA es funktioniert!
    2. 2. Inhalt • XING • Entwicklung bei XING • QA bei XING • Gelerntes • Gefahren
    3. 3. XING
    4. 4. Releases im Jahr 50
    5. 5. Entwickler >50
    6. 6. Wir entwickeln hier… …und dort
    7. 7. ENTWICKLUNG BEI XING
    8. 8. 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
    9. 9. http://www.flickr.com/photos/true2death/ QA BEI XING
    10. 10. QA bei XING • sitzt im Team vor Ort, kennt gesamte Plattform und insbesondere eigene Domäne • Eigenverantwortlich im Team • alle Team-Meetings
    11. 11. 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.
    12. 12. GELERNTES
    13. 13. 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/
    14. 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 • 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
    15. 15. 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
    16. 16. 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
    17. 17. 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
    18. 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 • 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
    19. 19. 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
    20. 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 Häppchen überschaubares Testen… – … und weniger Arbeit – Erfolgserlebnis für das Team nach jedem GoLive – Möglichkeit Kundenfeedback einzuarbeiten
    21. 21. Gelerntes
    22. 22. 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
    23. 23. Gelerntes
    24. 24. GEFAHREN
    25. 25. 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
    26. 26. Vielen Dank für Ihre Aufmerksamkeit! sergej.mudruk@xing.com tobias.geyer@xing.com

    ×