Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

XING Agile QA

2.279 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

×