XING Agile QA

2.260 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie, Sport
  • Als Erste(r) kommentieren

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

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

×