software measurement in agilen projekten mit open source tools
DESCRIPTION
eBay Europa hat ein neues Verfahren zur Messung von Reife und momentanem Status von Software Projekten eingeführt. Diese Präsentation illustriert den Mechanismus dieser sogenannten Projekt Surveys and zeigt anhand von Beispielen aus eBay Projekten auf, wie sich die Software Qualität nach Anwendung des Verfahrens signifikant verbessert hat. Das Survey wird teils manuell und teils automatisch unter Verwendung des Open Source Tools “SONAR” ausgeführt. Sonar ist ein webbasiertes Dashboard / Cockpit, das die Daten aus den Testausführungen, statischer Codeanalyse, dupliziertem Code und Code Komplexität aggregiert und darstellt. Der manuelle Teil besteht aus Reviews von Dokumentation, Source Code, Test Code und Test Cases. Zusammen mit den Ergebnissen aus dem automatisierten Teil wird das Gesamtergebnis übersichtlich und klar in einem Dashboard dargestellt, aufgrund dessen auch Verbesserungsmöglichkeiten klar ersichtlich sind.TRANSCRIPT
Software Measurement in agilen Projekten mit Open Source Tools
Michael Palotas & Dominik Dary eBay Quality Engineering Europe 2011-10-11
Erstellt von: Michael Palotas & Dominik Dary
2
Agenda
• Komplexität und Herausforderungen bei eBay • Ausgangssituation • Manuelles und Tool-basiertes Software Measurement
• Auswirkungen des Software Measurement
Erstellt von: Michael Palotas & Dominik Dary
Komplexität und Herausforderungen bei eBay
60 million lines of code
10.000+ Java application servers
2 billion page views/day
25,000 searches per second
110 million items in > 50,000 categories
25 Petabyte of data processed by Data Warehouse/day
4.4 billion API calls per month (public API)
48 billion SQL executions/day
2 Terabyte of application log files/day
2 million outbound emails/day
14 Gbps peak network utilization
Erstellt von: Michael Palotas & Dominik Dary
Ihre Referenten
4
Michael Palotas • Head of Quality Engineering
Europe • E-Mail: [email protected]
Dominik Dary • Senior Software Engineer in Test • E-Mail: [email protected]
Erstellt von: Michael Palotas & Dominik Dary
Ziele von Software Measurement?
Wir möchten uns ständig verbessern in dem was wir tun
Festlegung von Akzeptanzkriterien aus der Sicht der Qualitätssicherung
Schaffung der Vergleichbarkeit von Projekten und Teams
Ermittlung der aktuellen Reife (Maturity) der Projekte
Anreiz für das Team um sich zu verbessern
Um von dem „gutem Bauchgefühl“ Measurement Ansatz
wegzukommen J
5
Image Source: http://www.clickbuyhelp.org/wp-content/uploads/2010/03/Continuous-Improvement.jpg
Erstellt von: Michael Palotas & Dominik Dary
Tool-basiertes Software Measurement
6
Beispiel: eBay Deals Anwendung
Erstellt von: Michael Palotas & Dominik Dary
Software Measurement in der Praxis?
Manuelles Audit - Durchgeführt vom QE
Engineer - Alle 3-5 Iterationen
Tool-basiert - SONAR Open Source Tool
7
Warum reicht Tool-basiertes Measurement nicht aus?
Ganzheitlicher Ansatz im Gegensatz nur zur Verwendung von statischer Analyse-Tools
Nicht nur die “harten Fakten” werden mit einbezogen
Einige Kriterien können nicht Tool-basiert verifiziert werden (i.e.
Testfallqualität, Qualität der Dokumentation, Testplan)
&
Erstellt von: Michael Palotas & Dominik Dary
Unsere Vision
8
Automated Testing
Large Tests
Small Tests
Integra-tion
Tests
Manual Tests
Exploratory Testing
Acceptance Test
SCM Continuous Integration
Tools
Wiki
Engineering Practices
QA QE DEV
Proj
ekt A
udits
Fast Delivery
Erstellt von: Michael Palotas & Dominik Dary
Maturity-Definition der Key-Area “Test Strategy”
9
Manual Tests
Automated Tests
High level test
Low level test
Dev Tests
User Acceptance Tests
Regression Tests
Large Tests
Small Tests
Integration Tests
System Tests
Test Plan
1
4
2 3
• Level 1: Ein Testplan existiert für das Project.
• Level 2: Ein manueller Testplan existiert
• Level 3: System Tests & automatisierte Large Tests sind vorhanden und sind aufeinander abgestimmt.
• Level 4: Low-Level Testplan existiert
• Level 5: High-Level und Low-Level Tests sind aufeinander abgestimmt.
Maturity Definition
5
Erstellt von: Michael Palotas & Dominik Dary
Wie wird mit den Ergebnissen des Audits umgegangen?
Feedback an das SCRUM-Team & das Management
Scrum Master + Product Owner entscheiden basierend auf den vorgeschlagenen Maßnahmen
Maßnahmen werden übers Produktbacklog umgesetzt
10 Image Source: http://en.wikipedia.org/wiki/File:Scrum_process.svg
Erstellt von: Michael Palotas & Dominik Dary
Auswirkungen des Software Measurement
11
Messbare Verbesserung der Qualität des Quellcodes und des Produkts Team sind motiviert sich beständig zu verbessern
Anreiz zwischen den Teams
Beispiel Darstellung eines Audits Entwicklung der Maturity Levels:
Erstellt von: Michael Palotas & Dominik Dary
Unsere Erfahrungen als Auditoren
Positive Erfahrungen • Erste Audits benötigen
einige Vorbereitungszeit • Später durchgeführte
Audits können schnell durchgeführt werden
• Schnelles Feedback über die Projekte
• Die Leistungsfähigkeit liegt in der Einfachheit der Audits
Was haben wir geändert: • Neue Metriken:
• Continuous Integration • Code Reviews • Source Code Management
12
Erstellt von: Michael Palotas & Dominik Dary
Kommentare, Vorschläge oder Fragen?
13
Erstellt von: Michael Palotas & Dominik Dary
Vielen Dank für Ihre Aufmerksamkeit!
14