Der Entwicklungsprozess bei NAVIGON

Größe: px

Ab Seite anzeigen:

Download "Der Entwicklungsprozess bei NAVIGON"

Dagmar Hauer
vor 8 Jahren
Abrufe

1 Der Entwicklungsprozess bei NAVIGON Dr. Mark Nischik Stuttgart

2 Ü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 2

3 NAVIGON Geschäftsbereiche NAVIGON AG Mobility Automotive 3

4 NAVIGON - Innovationsführer seit Onboardnavigation für WP7 2 Millionen Apps NAVIGON select 2009 Onboardnavigation für iphone 2007 NAVIGON eigener PND 2004 Onboardnavigation für Smartphones 2002 Navigationslösung mit TMC Navigationssoftware für Mobiltelefone Dynamische GPS Navigation Autopilot 4

eigener PND 2004 Onboardnavigation für Smartphones 2002 Navigationslösung mit

5 Von der Idee bis zum Produkt Der Produktentstehungsprozess bei NAVIGON AG 5

6 Der Entwicklungsprozess einer internen Produktentwicklung 6

7 Ablauf 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 7

HMI-Designs - Erstellen der Detailspezifikationen - SW-Design, Interface-Abstimmungen mit Core und Content & Services - Implementierung / Unit-Tests

8 8 Anforderungsmanagement

9 9 Detailspezifikationen

10 UI-Design 10

11 Toolgestütze Umsetzung des UI-Designs 11

12 SW- Architecture Mobile Navigator Red: platform independent framework and core components (like routing) Dark Blue: GUI independent Components Light blue: GUI dependant components 12

13 SW-Design 13

14 Kontinuierliche Builds 14

15 Software Quality Assurance (SQA) SQA-3 System Test Beta Test Navigon branded products only Beta Tester 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) 15

Planning Map Quality Control Unit IntegrationTests SQA-1 Unit Tests

16 Map Tests Overview SQA Map Tests SQA-2 Map Quality Control Map Integration Test Automated Tests Manual Tests DP Tests General routing functionality (City Center Test Tool) RDF/PSF Comparison (Address- Compare- Tool) MA Auto Tests (Routing) Motorways Border Crossings Ferries Pass Roads Auto Tests Buildserver Addresses (AddressTester) Alternative Names (Alternative- NamesTester) Time Zone (TimeZone- Tester) Map Layout Lessons Learned Zip codes / Addresses (manual test cases) Cities/ Residential Streets Test of all part maps with the real application on the specified hardware Random Routing Test (FullRouting Tester) 16

Addresses (AddressTester) Alternative Names (Alternative- NamesTester) Time Zone (TimeZone- Tester) Map Layout Lessons Learned Zip codes / Addresses

17 R&D Defect Processing Bugfix Validation (Regression Tests) Checks Fixed? Sets Validated SQA Add to generic Lessons Learned Test Specification Defect Reporting Resolved/Invalid-Wontfix*-Duplicate Project Lead Investigation Scheduling Prioritization Assignment Check Adds required information Checks NO Valid? Unique? Reassigns Assigns YES NO Reopen Developer Investigates Sufficient information? YES Checks Fix possible? Unique bug? NO Reassigns YES Resolved / Worksforme Resolved / Fixed NO Reproducible? YES Relevant for other / later projects? (Lessons Learned) Creates bug clone in other project R&D Defect Processing Bug Fixing *) potential CCB decision 17

Prioritization Assignment Check Adds required information Checks NO Valid? Unique? Reassigns Assigns YES NO Reopen Developer Investigates Sufficient information?

18 Project-Related SQA Metrics (2) 18

19 Vorgehensmodelle Agile Entwicklung und Wasserfall Modell 19

20 20 Core Components Positioner TMC / Traffic Advisor Advice Drawer Applikation MN7 iphone NAVIGON Software Architektur GPS Receiver MapMatcher Player Beacon MobilePhone PhonemFetcher Routing NameBrowser MapDrawer Automotive OEM Software

GPS Receiver MapMatcher Player Beacon MobilePhone

21 Entwicklungsformen Wasserfall Agile Modell Entwicklung Core Components Applikation 21

22 Wasserfall Modell Meist genutzt für Entwicklung der Kern Komponenten Langfristige Projekt- und Ergebnisplanung Top-Down Verfahren Definiertes, konkretes Ergebnis am Ende des Projektes Klassische Teilung: Lastenheft Auftraggeber - PM Pflichtenheft Auftragnehmer - PL Feature Definition Detaillierte Spezifikation Review Entwicklung / Übernahme Entwicklung Verwendung von Change Requests Spezialisten für jeden dedizierten Bereich vorhanden Späte Änderungen sind teuer Qualitätskontrolle Produkt 22

23 Agile 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) 23

24 Vorteile 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 24

25 Scrum: 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. 25

26 Scrum: 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. 26

27 Definitionen - 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. 27

28 Definitionen - 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. 28

29 Zusammenfassung 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 29

30 30 Fragen?

Ähnliche Dokumente

Start. Kreative Zielanalyse. Ideenmanagement. Stakeholdermanagement. Nutzung vorhandener Prototypen etc. Extrem schlanker Prozess.

Start. Kreative Zielanalyse. Ideenmanagement. Stakeholdermanagement. Nutzung vorhandener Prototypen etc. Extrem schlanker Prozess. Start Kreative Zielanalyse Ideenmanagement Stakeholdermanagement Nutzung vorhandener Prototypen etc. Extrem schlanker Prozess 3 Rollen 4 Artefakte wenige Regeln 0 1 2 Product Owner (1/2) Kreative Zielanalyse