David gegen Goliath. Wie sich kleine RE-Toolhersteller gegen die Großen der Branche in einer Toolauswahl geschlagen haben

Transkript

1 1 David gegen Goliath Wie sich kleine RE-Toolhersteller gegen die Großen der Branche in einer Toolauswahl geschlagen haben

2 2 WAS SIE HEUTE VON UNS MITNEHMEN KÖNNEN? Unsere Argumente und Erfahrungen, warum Demos, Feature-Kataloge und Lizenzkosten nicht genug für eine akzeptierte Tool-Entscheidung sind.

3 3 WIE KAMEN WIR ÜBERHAUPT ZUR TOOLAUSWAHL? Anforderungen verbessern Arbeitsmodell und Informationsmodell finden Tool auswählen Philosophie Arbeitsmodell

4 4 WELCHE PHILOSOPHIE HABEN WIR VERFOLGT? Nutzen muss sichtbar werden Arbeit an operativen Inhalten Gemeinsames Verständnis schaffen Alle Beteiligten sitzen an einem Tisch, direkte Kommunikation Anforderungen und Testfälle in einem Schritt definieren

5 5 GRUNDLAGE: EIN ERPROBTES ARBEITSMODELL Anforderungen gemeinsam erarbeiten Beteiligte o Fachbereich o IT4IPM, Lieferanten Kundenwunsch Ergebnisse o Einzelne Anforderungen mit referenzierten Testfällen o nur in einer gültigen Version Anforderung Testfall Zusammenarbeit o Direkte Kommunikation o Gemeinsames Verständnis Neues Software-Release Arbeitsumgebung o Gemeinsam und zentral o Schreibender Zugriff

6 6 WELCHE RAHMENBEDINGUNGEN HATTEN WIR? GEMA und IT4IPM als zwei Organisationen Toolauswahl in 6 Monaten Softwareentwicklung in Projekt- und Linien-Organisation Standorte in München und Berlin

7 7 WIE WOLLTEN WIR UNSERE ZIELE ERREICHEN? Prinzipien Ziele Betroffene zu Beteiligten machen (für eine hohe Akzeptanz, Anwender frühzeitig und intensiv einbeziehen) Tools zur Verwaltung von Anforderungen und Testfällen evaluieren und eine Toolempfehlung abgeben Ergebnisse offen und transparent kommunizieren Arbeitsmodell mit Projekten und Weiterentwicklungen verifizieren und ggf. anpassen

8 8 WER WAR BETEILIGT? Kernteam (2+2) Fachbereich (17) Management (7) Test Management (2) Management (5) Service Management (2) Einkauf (1) Entwicklung (5) 22 Beteiligte 20 Beteiligte IT-Betrieb (2) Architektur (2)

9 9 WIE SIND WIR VORGEGANGEN? Kernteam IT4IPM & GEMA Longlist (9) erstellen IT4IPM & GEMA Piloten Pilotierungen durchführen IT4IPM & GEMA Piloten Piloten-WS durchführen IT4IPM & GEMA Tooldemos durchführen Shortlist (4) erstellen IT4IPM & GEMA Management Kernteam & GEMA Funktions- Kriterien bewerten IT4IPM & GEMA Management Kernteam Empfehlung erarbeiten Kriterien-WS durchführen Mgmt-Kriterien bewerten IT4IPM Integration EA, Cherwell, QC Beteiligte Kernteam: Piloten: Management: Kundenmanagement IT4IPM, HOOD Projekt- und Weiterentwicklungsteams CEO, IT-Einkauf, IT-Betrieb, IT-Entwicklung, IT-Strategie, GEMA

10 10 WOHER KAM DIE LONGLIST? Quellen Tool-Workshop auf der REConf 2016 (110 Anbieter) Verfügbare Tools bei der IT4IPM und GEMA Gartner Studien etc. Kernteam Ergebnis: Longlist Tool Anbieter DOORS Next IBM Polarion Polarion Enterprise Architect Sparx Jama Jama ObjectIF RPM MicroTool JIRA / R4J Atlassian / easesolution (3 rd party) RM Dimensions SERENA HP ALM HP TFS / SmartWord Microsoft / edev (3 rd party)

11 11 WIE WURDEN DIE TOOLS VORGESTELLT? Basis für die Demos 3 h Einzelbewertung Grund- Funktionen Kernteam, IT-Betrieb, GEMA Szenarien Informations- Modell

12 12 WIE WURDE DIE LONGLIST ZUR SHORTLIST? 1. Reflektion und Selbsteinschätzung aller Tools 2. Identifikation der zwei schwächsten Tools (8+9) 3. Identifikation der zwei besten Tools (1+2) 4. Ranking der übrigen 5 Tools (3-7) Gemeinsamer Workshop in Berlin Konsensentscheidung Rang Anbieter 1 Serena 2 Jama 3 Microsoft / edev (3 rd party) 4 Atlassian / ease Solutions (3 rd party) Polarion HP 5-9 IBM MicroTool Sparx

13 13 WIE WAREN DIE ANWENDER BETEILIGT? Ziel Usability der Tools im operativen Geschäft durch Anwender bewerten Workshops Pro Team ca. 7 Workshops Rahmenbedingungen Zeit für Toolevaluierung Operative Themen Offenheit und Motivation Arbeitsmodell 6 Pilotprojekte insgesamt ca. 25 Mitarbeiter 2 Teams - Neuentwicklung (Projekt) 4 Teams - Weiterentwicklung (Linie) Praktischen Tooleinsatz Pro Team, ein Tool Operativen Einsatz RE-Methodik Formulierung Verschiedene Notationen Qualitätskriterien

14 14 WIE BEKAMEN WIR DAS ANWENDER-FEEDBACK? Am Ende der Pilotierung Im gemeinsamen Piloten-Workshop Bewertungsteil 1 Bewertungsteil 2 Bewertungsteil 3 Einzelbewertung des eigenen Tools (Szenarien) Gruppenbewertung der anderen Tool* (Szenarien) Einzelbewertung aller Tools durch Ranking * Hinweis zu Microsoft TFS/eDev: edev (SmartWord4TFS) war nicht lauffähig und somit war weder eine Pilotierung noch ein Experten-Review (durch Kernteam) möglich. Der Anbieter scheidet aus diesem Grund aus.

15 15 WIE HABEN DIE ANWENDER BEWERTET? Bewertungsteil 1 Bewertungsteil 2 Bewertungsteil 3 Einzelbewertung des eigenen Tools (Szenarien) Note x 1 Gruppenbewertung der anderen Tool (Szenarien) Note x 2 Einzelbewertung aller Tools durch Ranking Note x 3 Gesamtnote

16 16 WIE HABEN WIR DAS MANAGEMENT INVOLVIERT? Management-Kriterien Ausschreibung Einzelbewertung Konsensentscheidung

17 17 GAB ES KEINEN FEATURE KATALOG? Feature Katalog Kernteam, GEMA 43 Anforderungen wurden parallel in allen drei Tools bewertet durch: Testfällen (18) Review (10) bewerteten Antworten von den Herstellern (7) der Szenarien durch die Bewertung der Pilotteams (8)

18 18 WIE WURDEN SCHNITTSTELLEN BERÜCKSICHTIG? Service Management Architektur Test

19 19 WIE WICHTIG WAR SUPPORT UND CUSTOMIZING? Bewertungskriterium 1 Bereitstellung von Pilotlizenzen 2 Unterstützung bei der initialen Konfiguration Qualität und Geschwindigkeit bei der Beantwortung von Rückfragen Qualität der erhaltenen Ausschreibungsunterlagen vom Hersteller Erbringung der Leistungen in der Pilotphase durch den Hersteller Möglichkeiten der Konfiguration durch das BRM Team hinsichtlich Anlage von Usern, Artefakten, Feldern, Projekten, usw. Support Administration

20 20 WIE ENTSTAND DIE GESAMTBEWERTUNG? Pilotprojekte Anwender- Bewertung Gewichtung Management -Team x3 Management- Bewertung x2 Kernteam, GEMA Funktions- Bewertung x2 x1 Gesamtbewertung Tool- Empfehlung Kernteam Administration/ Support

21 21 WELCHES TOOL BEKAM DIE BESTE NOTE? 1,00 1,50 1,73 2,00 1,97 2,50 2,75 3,00 ease Jama Serena

22 22 WAS HABEN WIR EMPFOHLEN? Chancen Hohe Anwenderakzeptanz Großes Angebot von 3rd Party Herstellern Risiken Mehraufwand und mögliche Inkonsistenzen durch hohe Freiheitsgrade Keine Systemsicht, wenn Rückfall in alte, unerwünschte Arbeitsweisen Chancen Gute Chancen für Änderungswünsche am Tool Genaue Umsetzung des Informationsmodells Risiken Hohe Lizenzkosten, da Jama-Lizenzen inklusive der Task-Top Lizenzen angeboten werden Hauptsächliche Gründe hierfür Bevorzugtes Tool der Pilotanwender Kostengünstigste Variante, sowohl alleine betrachtet als auch mit Schnittstellen an EA und HP QC inklusive

23 23 WAS HABEN WIR GELERNT? Eine gute Usability ist entscheidend für die Akzeptanz der Anwender Lizenz- und Betriebskosten lassen sich gut Vergleichen und Bewerten Die Toolbewertung durch aktive Nutzung der Anwender ist sehr wertvoll Tooldemos liefern viele Informationen über die Funktionalitäten der Tools Eine einfache Toolintegration erleichtert das Zusammenspiel der Systeme ABER ABER ABER ABER ABER nur direkte Kommunikation und Zusammenarbeit verbessert die Ergebnisse. nur wenn die Arbeit der Teams unterstützt wird, sinken Entwicklungskosten signifikant. erst im Vergleich mit anderen Tools wird die Bewertung aussagekräftig. es sagt wenig darüber, wie man mit dem Tool arbeiten kann. die beste Schnittstelle ist KEINE Schnittstelle.

24 WELCHE FRAGEN HABEN SIE? 24

25 25 WIE FINDEN SIE UNS? Malin Winterhalder Business Relationship Managerin Jens Donig Principal Consultant