Der Entwicklungsprozess bei NAVIGON - Stuttgart 16.02.11 - Dr. Mark Nischik
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Der Entwicklungsprozess bei NAVIGON
Dr. Mark Nischik
Stuttgart
16.02.11
1Über NAVIGON
• Gegründet 1991
• Hauptstandorte Hamburg, Würzburg und Cluj-Napoca (Rumänien)
• Nummer 3 im Europäischen PND Markt, Nummer 1 auf
Smartphones Weltweit
• Über 350 Mitarbeiter an 19 Standorten
2NAVIGON – Geschäftsbereiche
NAVIGON AG
Mobility Automotive
3NAVIGON - Innovationsführer seit 1991
Onboardnavigation für WP7
2 Millionen Apps
2010 NAVIGON select
2009 Onboardnavigation für iPhone
2007 NAVIGON eigener PND
2004 Onboardnavigation für Smartphones
2002 Navigationslösung mit TMC
2000
Navigationssoftware für Mobiltelefone
1996 Dynamische GPS Navigation “Autopilot”
4Von der Idee bis zum Produkt…
Der Produktentstehungsprozess bei NAVIGON AG
5Der Entwicklungsprozess
einer internen Produktentwicklung
6Ablauf einer internen Produktentwicklung
Grobe Anforderungen durch Produktmanagement
Verfeinerung der Anforderung, Aufwandsschätzung, Planung (in mehreren Interationen)
Projektfreigabe
In mehreren Iterationen / Sprints
- Verwalten der Anforderungen mittels Polarion
- Erstellen des Workflows und HMI-Designs
- Erstellen der Detailspezifikationen
- SW-Design, Interface-Abstimmungen mit Core und Content & Services
- Implementierung / Unit-Tests
- SQA-Testspezifikation / Testdurchführung
- Fehlerbehebung „Bugfixing“
Abnahme durch PM
Produktion / Vervielfältigung
Auslieferung an den Händler / Kunden
7Anforderungsmanagement 8
Detailspezifikationen 9
UI-Design 10
Toolgestütze Umsetzung des UI-Designs 11
SW- Architecture Mobile Navigator
Red: platform independent framework and core components (like routing)
Dark Blue: GUI independent Components
Light blue: GUI dependant components
12SW-Design 13
Kontinuierliche Builds 14
Software Quality Assurance (SQA)
Navigon branded
SQA-3 products only
Beta Tester
System Test
Beta Test
SQA-2
Integration Tests
Test Planning
Map Quality Control
Unit IntegrationTests
SQA-1
Unit Tests (Core Components)
MN8 Automated Tests
(Unit Integration Tests)
(Test Planning)
15Map Tests Overview
SQA-2
SQA Map Tests
Map Quality Control Map Integration Test
Automated Tests Manual Tests
Map Layout
DP Tests MA Auto Tests Auto Tests Test of all part maps with the real
(Routing) Buildserver Lessons application on the specified hardware
General Learned
routing Motorways Addresses
functionality (AddressTester) Zip codes /
(City Center Border Crossings Addresses
Test Tool) Alternative (manual test
Ferries Names cases)
RDF/PSF (Alternative-
Comparison NamesTester)
Pass Roads Cities/
(Address- Residential
Time Zone
Compare- Streets
(TimeZone-
Tool)
Tester)
Random Routing
Test
(FullRouting
Tester)
16R&D Defect Processing
Bugfix Validation
Fixed? Validated
(Regression Tests) Checks Sets
SQA
Reopen
Adds Reassigns
required
Add to generic Lessons Learned Test Specification
Defect Reporting
Resolved / Worksforme
information
Developer
Resolved / Fixed
Resolved/Invalid-Wontfix*-Duplicate NO Investigates
Assigns
Reassigns
Valid?
Unique?
Project Lead Checks YES NO
Investigation Sufficient
Scheduling information?
NO
Prioritization
Checks
Assignment YES Reproducible?
YES
Check
NO Fix possible? YES
Unique bug?
Relevant for
other / later projects?
Creates bug clone in other project
Bug Fixing
(Lessons Learned)
R&D Defect Processing
*) potential CCB decision
17Project-Related SQA Metrics (2) 18
Vorgehensmodelle
Agile Entwicklung und Wasserfall Modell
1920
NAVIGON Software Architektur
Core
Applikation
Components
Positioner
MN7
TMC / Traffic
Advisor
Advice Drawer iPhone
GPS Receiver
Beacon
MapMatcher MobilePhone
Player
PhonemFetcher
Automotive
Routing
NameBrowser
OEM Software
MapDrawerEntwicklungsformen
Components
Applikation
Wasserfall Agile
Core
Modell Entwicklung
21Wasserfall Modell
Feature Definition
Meist genutzt für Entwicklung der Kern Komponenten
Langfristige Projekt- und Ergebnisplanung Detaillierte
Spezifikation
Top-Down Verfahren
Definiertes, konkretes Ergebnis am Ende des Projektes Review Entwicklung
/ Übernahme
Klassische Teilung:
Lastenheft – Auftraggeber - PM
Pflichtenheft – Auftragnehmer - PL Entwicklung
Verwendung von Change Requests
Spezialisten für jeden dedizierten Bereich vorhanden Qualitäts-
kontrolle
Späte Änderungen sind teuer
Produkt
22Agile Entwicklung - Scrum
Meist genutzt für Entwicklung der Applikation
Finale Produkt-Anforderungen müssen nicht gegeben sein
Maximale Flexibilität innerhalb des Teams
Keine Change Requests
Erstellen des Produkt Backlog
Regelmäßige Sprint Planung (nach Prioritäten)
Tägliches Scrum Meeting
Sprint Präsentation (Sprint Review) und Abnahme der Features
Sprint Lessons learned (Sprint Retrospective)
23Vorteile durch Scrum
Kundenzufriedenheit:
- Man kann agil auf Änderungen der Anforderungen reagieren
- Rasches Feedback aus der Entwicklung
- Jederzeit lieferbare SW
Effektivitätssteigerung:
- Hohe Transparenz über Stand im Projekt
- Kurze Feedbackschleifen
- Vermeiden von langen Testphasen zu Projektende
Verbesserte Teamarbeit:
- Selbstorganisation
- Mehr Eigenverantwortung
24Scrum: Definitionen - Rollen
Product Owner:
o Legt das gemeinsame Ziel fest, welches das Team erreichen muss
o Legt fest, welche die wichtigsten Features sind, aus denen das Entwicklungsteam
eine Auswahl für den nächsten Sprint trifft.
o Ist verantwortlich für das Produkt Backlog
Scrum Team:
o Schätzt die Aufwände der einzelnen Backlog-Elemente ab
o Implementiert die für den nächsten Sprint machbaren Elemente.
o Arbeitet selbstorganisiert im Rahmen einer Time Box (dem Sprint)
o hat das Recht, selbst zu entscheiden, wieviele Elemente des Backlogs nach dem
nächsten Sprint erreicht werden müssen (Commitments).
Scrum Master:
o Überwacht die Prozesse der Entwicklung und Planung
o Überwacht die Aufteilung der Rollen und Rechte zu überwachen.
o Hält die Transparenz während der gesamten Entwicklung aufrecht
o Steht dem Team zur Seite, ist aber weder Product Owner noch Teil des Teams.
o Sorgt mit allen Mitteln dafür, dass das Team produktiv ist, also die
Arbeitsbedingungen stimmen und die Teammitglieder zufrieden sind.
25Scrum: Definitionen - Backlogs
Product Backlog:
o Enthält die Features des zu entwickelnden Produkts
o Beinhaltet alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer
Abhängigkeiten
o Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und
priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt
werden.
o Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in
den Sprint Backlog übernommen.
o Hoch priorisierte Features werden sehr detailliert beschrieben. Niedrig priorisierte
Features werden oberflächlich beschrieben
o Das Product Backlog muss nicht vollständig sein; es wird laufend fortgeführt.
Sprint Backlog:
o Enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen.
o Eine Aufgabe sollte nicht länger als 16 Stunden dauern
o Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden
o Bei der Planung des Sprint werden nur so viele Aufgaben eingeplant, wie das Team
an Kapazität aufweisen kann.
Impediment Backlog:
o Enthält alle Hindernisse des Projekts
o Der Scrum Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen.
26Definitionen - Meetings
Sprint Planning (max. 8h)
o Beginn von jedem Sprint
o Product Owner stellt Product Backlog Einträge vor
o Team schätzt Aufwände und übernimmt Produkt Backlog Einträge in das Sprint
Backlog (Commitment)
Sprint Review (max. 4h)
o Nach jedem Sprint (vorzugsweise letzter Tag des Sprints)
o Team stellt das Ergebnis des Sprints vor (z.B. Vorführung von SW)
o Der Kunde prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht, eventuelle
Änderungen werden im Product Backlog dokumentiert.
Sprint Retrospective (max. 3h)
o Wertfreien Rückblick auf die Ereignisse des Sprints
o Fragen: „Was war gut?“ (Best practice), „Was könnte verbessert werden?“
o Jedes Verbesserungspotential wird priorisiert und einem Verantwortungsbereich
(Team oder Organisation) zugeordnet.
o Alle der Organisation zugeordneten Themen werden vom Scrum Master
aufgenommen und in das Impediment Backlog eingetragen. Alle teambezogenen
Punkte werden in das Product Backlog aufgenommen.
27Definitionen - Sonstiges
Sprint:
o Bezeichnet die Umsetzung einer Iteration, Scrum schlägt ca. 30 Tage als
Iterationslänge vor.
Daily Scrum (max. 15min):
o Täglich, zur selben Zeit, am selben Ort
o Fragen: "Was hast Du seit gestern gemacht?", "Was planst Du bis morgen zu
machen?", "Gibt es ein Problem, das Dich blockiert?"
o Dient dem Informationsaustausch des Teams untereinander. Hier geht es darum,
dass möglichst alle alles wissen.
o Hindernisse werden vom Scrum Master in das Impediment Backlog eingetragen
Burndown Chart:
o Graphische, pro Tag zu erfassende Darstellung des noch zu erbringenden Restaufwands
pro Sprint.
28Zusammenfassung
Produktentstehungsprozess definiert einen Rahmen
- Definierte Meilensteine zur Synchronisation zwischen dem Abteilungen
- Aber Freiräume zur Ausgestaltung innerhalb einer Abteilung
- Je nach Projektkategorie: „maßgeschneiderte“ Prozessvariante notwendig
Das agile Vorgehensmodell wurden sehr erfolgreich in der Applikationsentwicklung
eingeführt
Klassisches Vorgehen nach dem Wasserfallmodell ist für spezielle Projekte (wie z.B.
Plattformentwicklung) nach wie vor angemessen
29Fragen? 30
Sie können auch lesen
