Agile World IT. Stefan Recknagel, Matthias Geiß Datum:

Transkript

1 Agile World Stefan Recknagel, Matthias Geiß Datum: Juli 2012

2 Agenda Projektumfeld Erfolgsfaktoren Lessons learned Stefan Recknagel, Matthias Geiß 12. Juli

3 Was ist die KVB? Die KVB ist verantwortlich für die ambulante Versorgung aller gesetzlich versicherten Patienten in Bayern Interessensvertretung, Honorarverhandlung und -abrechnung für über Mitglieder: alle Kassenärzte und Psychotherapeuten Gesetzlicher Auftrag umfasst Sicherstellung und Gewährleistung Stefan Recknagel, Matthias Geiß 12. Juli

4 Was macht die KVB IT? Geschäftsanwendungs- und BI-Management Software Development & Consulting Service Solution Providing MDM Abrechnung BI SAP Windows-Entwicklung Java-Web-Entwicklung GPM, ECM Mammographie-Screening Servicedesk Rechenzentrum Windows-Systeme Unix-Systeme Kernprozesse In Zahlen 160 IT-Mitarbeiter PCs und Thin Clients Ca. 125 physikalische und 400 virtuelle Server-Instanzen 170 Datenbankinstanzen 180 Client- und 210 Web-Applikationen KVB-Arztsuche KVB Stefan Recknagel, Matthias Geiß 12. Juli

5 Nearshore in der KVB IT: Ziele und Zahlen Ausgangssituation Nachgefragtes Projektvolumen permanent höher als verfügbare Entwicklungskapazitäten Ziele Zahlen Geringere Abhängigkeit vom lokalen Angebot für externe Entwickler Kostenreduktion Reaktionsfähigkeit bei kurzfristigen Themen durch langfristige Zusammenarbeit und entsprechendem Wissensaufbau Seit 05/2008 ca. 25 Projekte Projektgröße von 3 bis 10 Personen in SDC: ca PT Nearshore bei ca PT Projektvolumen 0% ungewünschte Fluktuation bei den Nearshore-Entwicklern Stefan Recknagel, Matthias Geiß 12. Juli

6 Scrum und Nearshore in der KVB IT Onshore Nearshore Intern Dienstleister klassisch Intern + Extern Dienstleister KVB PO SM Scrum-Team Stefan Recknagel, Matthias Geiß 12. Juli

7 Was hat sich beim Projektablauf bewährt? Kick-off + Ramp-up Treffen vor Ort TouchDown Rike / PIXELIO manwalk / Manfred Walker / PIXELIO s.media / PIXELIO langfristige Partnerschaft Benjamin Thorn / PIXELIO Stefan Recknagel, Matthias Geiß 12. Juli

8 Was hat sich beim Projektablauf bewährt? Langfristige Zusammenarbeit mit einem festen Partner Kick-off Vertraglicher Rahmen und Vertrauensverhältnis Infrastruktur Gegenseitige Kontakte Anwendungs- und Domänenwissen Erläuterung Ziele und Roadmap Teambuilding gemeinsam vor Ort! Ramp-up / Einarbeitung vor Ort Teambuilding Know-how-Aufbau Effizientes Aufsetzen von Entwicklungs- und Build-Tools Dauer: Abhängig von Komplexität, 2 Wochen waren im Team von Stefan Recknagel etwas kurz, sind generell aber ein guter Anhaltspunkt Regelmäßige Treffen vor Ort Rhythmus per Default alle 6-8 Wochen für 1 Woche In einem kritischen Projekt in Konzeptionsphase alle 3 Wochen für 2 Tage TouchDown / Gesamtretrospektive Gemeinsam: PO, Onshore- und Nearshore-Team, Fachbereich, Betrieb, Teamleiter Erkenntnisse: Infrastruktur ist kritisch, anfängliche Zielbeschreibung kann kaum zu ausführlich sein Stefan Recknagel, Matthias Geiß 12. Juli

9 Wie wird in Regelmeetings kommuniziert? Daily analog: Sprintplanning Marko Greitschus / PIXELIO + Inspect & Adapt RequirementsWorkshop analog: Review und Retro Stefan Recknagel, Matthias Geiß 12. Juli

10 Wie wird in Regelmeetings kommuniziert? Basis Screensharing mit Netviewer Evolution im Daily (analog Sprintplanning und Ad-hoc-Meetings) 1. Pro Raum: Telefon mit Lautsprecher & Freisprechmikrofon 2. Pro Raum: Telefon mit Spinne 3. Pro Person: Telefon mit Headset, Telefonkonferenz (einer ruft alle an) 4. Pro Person: Telefon mit Headset, Konferenzdienst (jeder wählt sich ein) 5. Pro Person: Telefon mit Headset, Konferenzdienst, Webcam Evolution Requirements-Workshop (analog Review und Retro) 1. Telefon mit Headset, wie im Daily 2. Meetingraum mit Spinne 3. Videokonferenz Stefan Recknagel, Matthias Geiß 12. Juli

11 Welche technischen Vorraussetzung waren nötig? Hardware Software / Service VPN TelCo-Service Netviewer Screensharing Pidgin Chat-Client JIRA mit Greenhopper Confluence WIKI Entwicklung Zentrales Repository Christian Meissner / PIXELIO Stefan Recknagel, Matthias Geiß 12. Juli 2012 Lokale Entwicklungsumgebung 11

12 Welche technischen Vorraussetzung waren nötig? Hardware Kabellose duale Headsets am Telefon (abgedichtete und gleichzeitig kabellose haben wir nicht bekommen) Webcam Videokonferenzraum mit Beamer und Tischmikrofon WAN-Anbindung (abhängig vom Datenvolumen) Software / Service VPN Telefonkonferenz-Service Screensharing mittels Netviewer / Livemeeting Pidgin Chat sehr gut zum Überblick, welche Ansprechpartner gerade am Platz sind, und viel genutzt wegen geringerer Hemmschwelle gegenüber einem Telefonanruf JIRA mit Greenhopper-Plugin Confluence WIKI (Standard für Dokumentation gewinnt mit Verteilung noch an Bedeutung) (Paint mit Stift als Whiteboard-Ersatz nur bedingt geeignet) Entwicklung Zentrales Repository für Sourcecode Lokale Entwicklungsumgebung (lokale Tests mit Mocks ohne Zugriff auf zentralen Umgebung) Stefan Recknagel, Matthias Geiß 12. Juli

13 Wie wird trotz Verteilung die nötige Qualität erreicht? Spielregeln Vorgehen / Testing Continuous Integration Clean Code Developer (CCD) Pairprogramming Dokumentation Onshore Code Quality Management Stefan Recknagel, Matthias Geiß 12. Juli

14 Wie wird trotz Verteilung die nötige Qualität erreicht? Projektübergreifende Spielregeln Durch alle Projekte zu erfüllen Onshore-Mitarbeiter beziehen Nearshore-Mitarbeiter mit ein Vorgehen / Testing Jeder Task durchläuft Umsetzung und Test (abhängig von Art des Tasks ein Dokumentenreview, Blackbox-, Whitebox-Tests und/oder Codereview) Zu jeder User Story mit Programmierung gibt es mindestens einen Task zur Entwicklung eines Akzeptanztests (durch 2. Entwickler) Generell: Alles wird im 4-Augen-Prinzip umgesetzt Continuous Integration Läuft nach jedem Check-in und führt auch alle Tests (inkl. Akzeptanztests) durch Unser Anspruch: Build und Tests sind immer grün CCD (Clean Code Developer) Wöchentliches CCD-Meeting inkl. Nearshore-Mitarbeitern (Kommunikation wie im Daily) Vorbereitung zu den Prinzipien und Praktiken erfolgt jeweils durch einen Onshore- oder Nearshore-Mitarbeiter Pairprogramming findet auch über Desktop-Sharing statt Standortübergreifend zeitlich meist auf Minuten begrenzt, wegen Nutzung der Headsets Dokumentation Onshore Dokumentations-Tasks werden primär onshore durchgeführt sonst wäre Nacharbeit nötig Code Quality Management Messung der Compliance von auf die Spielregeln und CCD-Prinzipien abgestimmten Regeln mit Sonar Stefan Recknagel, Matthias Geiß 12. Juli

15 Wie werden 3rd-Level-Tickets bearbeitet? Team-Support-Verantwortlicher Stefan Recknagel, Matthias Geiß 12. Juli

16 Wie werden 3rd-Level-Tickets bearbeitet? Produkte in Wartung Ein speziell vorgesehenes Team übernimmt die Bearbeitung von 3rd Level Tickets Produkte in Weiterentwicklung 3rd Level Tickets werden vom Projekt-Team bearbeitet Gründe: Vorhandenes Know-how wird genutzt, Vermeidung von Branches Team-Support-Verantwortlicher (TSV) Um Störungen gering zu halten, übernimmt ein Teammitglied die rotierende Rolle des TSV TSV ist verantwortlich für Ticketprüfung und ggf. Erarbeitung von Workarounds Aus Gründen der direkten Abstimmung ist der TSV immer ein Onshore-Mitarbeiter Ggf. resultierende Bugfixes können natürlich durch Nearshore-Mitarbeiter umgesetzt werden Stefan Recknagel, Matthias Geiß 12. Juli

17 Wie bewahrt man Akzeptanz bei den Mitarbeitern? Nachvollziehbare Zielsetzung Offenes Ohr Hindernisse beseitigen Claudia Hautumm / PIXELIO Kommunikationsinfrastruktur marika / PIXELIO Schnelle Reaktion S. Hofschlaeger / PIXELIO Matthias Weggel / PIXELIO Stefan Recknagel, Matthias Geiß 12. Juli

18 Wie bewahrt man Akzeptanz bei den Mitarbeitern? Akzeptanz ist ein wichtiges Thema, weil ein verteiltes Team für die Teammitglieder eine Hürde darstellt. Nachvollziehbare Zielsetzung Die Ziele hinter dem Nearshore-Modell müssen den Mitarbeitern genau bekannt sein Wenn Hindernisse nicht adressiert werden, leiden Akzeptanz und Zusammenarbeit im verteilten Team Zur Adressierung von Hindernissen sind wichtig: Commitment des Managements Offenes Ohr Unbürokratische oder zumindest schnelle Adressierung von Themen Von Anfang an konsequente Erfassung und Verfolgung der Themen, damit gefühlte Probleme objektiviert und ggf. eskaliert werden können Kritisch ist die Zuverlässigkeit der Kommunikationsinfrastruktur Konkrete Beispiele zur Adressierung von Hindernissen: Zusammenspiel von Videokonferenzsystemen, Eskalationen beim Nearshore-Partner bzgl. Audio-Verbindung, Wechsel des Telefonkonferenz-Providers und Ersatz von Webcams Stefan Recknagel, Matthias Geiß 12. Juli

19 Welche Eigenschaften des aktuellen Nearshore-Partners sind wichtig in der Zusammenarbeit? Sprachkenntnisse Qualifikation knipseline / PIXELIO Geringe Fluktuation matchka / PIXELIO Stefan Recknagel, Matthias Geiß 12. Juli 2012 Reisebereitschaft Rainer Sturm / PIXELIO Thomas Kölsch / PIXELIO Geringer Zeitunterschied Karin Jung / PIXELIO 19

20 Welche Eigenschaften des aktuellen Nearshore-Partners sind wichtig in der Zusammenarbeit? Deutsch als Projektsprache hat sich insbesondere in der Zusammenarbeit mit den Fachbereichen als gut erwiesen ist auch auf Grund der schwierigen Fachbegriffe wichtig ( Vertragsarztrechtänderungsgesetz ) Qualifikation / Know-how Konzeption und anschließende QS sollten auch Nearshore möglich sein Reisebereitschaft der Mitarbeiter und vertretbare Reisezeiten Langfristige Zusammenarbeit mit dem Partner und v.a. auch geringe Fluktuation im Nearshore-Team Kein Unterschied in der Zeitzone Schnelles Beseitigen von Hindernissen Stefan Recknagel, Matthias Geiß 12. Juli

21 Lessons learned in der KVB IT: Wann sind unsere Projekte Nearshore-geeignet? KVB Dienstleister PO SM Scrum-Team Projektmindestgröße 5 Personen Minimale Größenordnung 500 PT Bei größeren Projekten (ab ca. 10 Personen) kann ein getrenntes Nearshore-Scrum-Team eine günstigere Variante sein Stefan Recknagel, Matthias Geiß 12. Juli

22 Lessons learned in der KVB IT: Wann sind unsere Projekte Nearshore-geeignet? Projektmindestgröße 5 Personen 1 PO mindestens 2 Onshore-Entwickler, die die TSV-Rolle übernehmen mindestens 2 Nearshore-Entwickler, damit auch Nearshore Face-to-Face-Kommunikation stattfinden kann Minimale Größenordnung 500 PT Nach Daumenformel sollte bei 5 Personen das Volumen für mindestens 5 Monate Laufzeit reichen entspricht bei 20PT/Monat ca. 500 PT Bei größeren Projekten (ab ca. 10 Personen) kann ein getrenntes Nearshore-Scrum-Team eine günstigere Variante sein Der Overhead für die standortübergreifende Kommunikation betrifft dann weniger Mitarbeiter Stefan Recknagel, Matthias Geiß 12. Juli

23 Lessons Learned in der KVB IT: Erfolgsfaktoren Partnerschaft Inspect & Adapt Elektronische Wand und WIKI Benjamin Thorn / PIXELIO Treffen vor Ort Kommunikationsinfrastruktur Akzeptanz manwalk / Manfred Walker / PIXELIO Thommy Weiss / PIXELIO Stefan Recknagel, Matthias Geiß 12. Juli

24 Lessons Learned in der KVB IT Erfolgsfaktoren bei der KVB Fester und geeigneter Partner Regelmäßige Zusammenarbeit an einem Ort Verlässliche Kommunikationsinfrastruktur Elektronische Wand und Wiki Akzeptanz im Team Inspect & Adapt ist bei Verteilung noch wichtiger (v.a. für die Kommunikation im Team) Stefan Recknagel, Matthias Geiß 12. Juli

25 Christopher Robin / PIXELIO istockphoto.com Juli 2012