agile Sybit Ausgabe 11 Kudo Kasten Jurgen Appelo DevOps - Agilität weiter gedacht Thomas Wilhelm

Größe: px
Ab Seite anzeigen:

Download "agile Sybit Ausgabe 11 Kudo Kasten Jurgen Appelo DevOps - Agilität weiter gedacht Thomas Wilhelm"

Transkript

1 Sybit agile Ausgabe 11 Agile Softwareentwicklung im Fokus Kudo Kasten Jurgen Appelo Seite 3 DevOps - Agilität weiter gedacht Thomas Wilhelm Seite 5 Introducing Continuous Delivery Christoph Lukas und Alexander Birk Seite 8 Agile Innovation Produktmanagement in turbulenten Zeiten Vasco Duarte Seite 12

2 AUSGABE 11 Diese Sybit agile Ausgabe ist in zweierlei Hinsicht speziell: Zum einen ist sie größtenteils nicht in Köpfen von Sybit Mitarbeitern entstanden, sondern wir konnten gleich drei Gastautoren für Artikel gewinnen. Zum anderen erscheint sie begleitend zur ersten Agile Bodensee Konferenz. Beide Aspekte machen uns natürlich ein klein bisschen stolz und ich hoffe, dass sie wertvolle Anregungen aus jedem der Artikel mitnehmen können. Jurgen Appelo hat mit seinem Buch Management 3.0 für Furore in der Szene gesorgt. Ich muss gestehen, dass ich nach der Lektüre aufgrund der Fülle des Stoffs schon etwas erschlagen war. In seinem Artikel Kudo Box beschreibt Jurgen eine ganz konkrete Maßnahme, wie ein Belohnungssystem aussehen kann. Die Kollegen Alexander Birk und Christoph Lukas konnten uns schon in einem Agile Breakfast in Konstanz von Ihrer Idee einer Continuous Delivery Implementierung überzeugen. Wir haben uns gedacht, dass es sich lohnt, dieses Thema einem breiteren Publikum aufzudecken. Gut dazu passt auch der Artikel DevOps meines Kollegen Thomas Wilhelm. Und Vasco Duarte (er ist auch Mitorganisator der Agile Bodensee) bringt uns das Thema Agile Innovation näher spätestens seit Management 3.0 wissen wir, dass Agilität nicht nur in der Projektorganisation Sinn macht, sondern auch Organisation und Strategie/Innovation bereichern und zum Erfolg führen kann. Johannes Hartmannsgruber 2 Sybit agile Ausgabe 11

3 Kudo Kasten Jurgen Appelo, Autor: Management Versprechen Sie Belohnungen nicht im Voraus. len Sie Belohnungen zu einem unerwarteten Zeitpunkt, Ertei- damit die Mitarbeiter nicht ihre Ziele ändern und sich auf die Belohnung konzentrieren. [Pink, Drive l:524]. 2. Halten Sie erwartete Belohnungen klein. Wenn Sie nicht vermeiden können, dass Mitarbeiter eine mögliche Belohnung erwarten, setzen Sie keine zu große Belohnung ein, da der mit der Erwartung verbundene Stress das Arbeitsgedächtnis der Mitarbeiter beeinträchtigt [Fleming]. 3. Erteilen Sie Belohnungen kontinuierlich, nicht nur einmal. Wenn Mitarbeiter täglich gute Arbeit leisten, besteht jeden Tag Gelegenheit zu einer Belohnung [Mc- Crimmon, Celebrating Success ]. 4. Vergeben Sie Belohnungen öffentlich, nicht unter vier Augen. Ziel von Belohnungen ist es, dass gute Arbeit anerkannt wird und auch, dass die Mitarbeiter sich darüber freuen können [Alberg, Celebrate Success ]. 5. Belohnen Sie Verhalten, nicht Ergebnisse. Wenn Sie das Augenmerk auf gutes Verhalten richten, lernen die Mitarbeiter, wie sie sich verhalten sollen. Wenn Sie sich auf gewünschte Ergebnisse konzentrieren, lernen sie möglicherweise zu täuschen [Fleming]. 6. Belohnen Sie gleichgestellte, nicht untergeordnete Mitarbeiter. Gleichgestellte Mitarbeiter wissen oft besser als Führungskräfte, welche ihrer Kollegen ein Kompliment verdienen [Tynan, Reward Employees ]. Für die Belohnung von Mitarbeitern gibt es viele falsche Möglichkeiten. Ein einfacher, aber wirkungsvoller Ansatz ist das Aufstellen eines Kudo-Kastens, mit dem sich die Mitarbeiter gegenseitig kleine Belohnungen zukommen lassen können. Der Kudo-Kasten erfüllt die sechs Regeln für Belohnungen und funktioniert wesentlich besser als jede Art von finanzieller Motivation wurde das amerikanische Energie- und Dienstleis- tungsunternehmen Enron insolvent, weil seinen Managern ihre Boni wichtiger waren als die Wahrheit. Sie motivierten sich selbst dazu, ihre Gehaltskonten zu maximieren, nicht aber den Unternehmenserfolg [Duarte, Resonate, S. 199]. Die Geschichte der Unternehmen ist übersät mit den resten von Organisationen, die es zuließen, dass die Gier und das Ego von Einzelnen größer wurden als die Solvenz Über- des Unternehmens. Extrinsische Motivation Belohnungen gehören zu den schwierigsten und am wenigsten verstandenen Werkzeugen des Managements. Wenn sie aber richtig eingesetzt werden, können sie beeindruckende Ergebnisse bewirken. Leider gehen viele Manager von der Annahme aus, dass Geld die beste Wahl ist, um jemanden härter, länger oder effizienter arbeiten zu lassen. Ebenso wird oft davon ausgegangen, dass eine solche extrinsische Motivation am besten wirkt, wenn sie in Form eines finanziellen Bonus realisiert wird. Beide Annahmen sind falsch. Die wissenschaftliche Forschung hat gezeigt, dass Arbeitsanreize genau umgekehrt funktionieren. Die Erwartung einer Belohnung wirkt kontraproduktiv, da sie die innere Motivation zunichtemacht. Dieser Effekt wird als Überrechtfertigung (overjustification effect) bezeichnet [Kohn, Punished by Rewards, S. 320]. Ein weiteres Problem besteht darin, dass ergebnisabhängige Belohnungen das Risiko von Täuschungsversuchen erhöhen, da sich die Mitarbeiter darauf konzentrieren, eine Belohnung zu erhalten, statt gute Arbeit zu leisten [Fleming]. Intrinsische Motivation Glücklicherweise gibt es aber auch gute Nachrichten: Belohnungen, die die intrinsische Motivation auslösen, sind wirksamer und kosten deutlich weniger. Belohnungen können sich für Ihr Unternehmen auswirken, wenn Sie die folgenden sechs Regeln beachten: Sybit agile Ausgabe 10 3

4 Kudos Paul Klipp, President und Scrum-Trainer bei Lunar Logic Polska in Polen, erzählte mir, dass seine Mitarbeiter die Möglichkeit haben, jedem Kollegen ein Geschenk im Wert von 20 Euro zu machen. Diese Geschenke werden als Kudos bezeichnet und können in Form einer an ein zentrales Postfach oder durch Einwerfen einer Karte in einen Karton überreicht werden. Wenn jemand in der Firma das Gefühl hat, dass jemand anders ein Geschenk verdient hat, dann bekommt diese Person ein Geschenk und alle erfahren davon. Wie Paul berichtet, funktioniert das Ganze hervorragend; und das Vertrauen wurde noch nie missbraucht. Kohn, Alfie. Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes. Boston: Houghton Mifflin Co, Gedruckte Veröffentlichung. Markowitz, Eric. 3 Weird, Game-Changing Ways to Make Employees Happy <http://bit.ly/jqa1fj> Inc.com, 11. Mai Web, 23. Juli McCrimmon, Mitch. Celebrating Success at Work <http://bit.ly/ N1XLrP> Business Suite101, 9. April Web, 23. Juli Pink, Daniel. Drive: The Surprising Truth about What Motivates Us. New York, NY: Riverhead Books, Gedruckte Veröffentlichung. Tynan, Dan. 25 Ways to Reward Employees (Without Spending a Dime) <http://bit.ly/xadfv> HR World, Web, 23. Juli Anerkennungskarten, die bei der Konferenz Agile Lean Europe 2011 zum Einsatz kamen (Foto: Corinna Baldauf, Verwendung mit Genehmigung) Philip Rosedale, ehemaliger CEO von Linden Lab, entwickelte ein ähnliches System namens LoveMachine [Markowitz, Make Employees Happy ] ein Tool, mit dem Mitarbeiter ihren Kollegen kurze Anerkennungen zusenden konnten. Wie Rosedale berichtet, bewirkte die gegenseitige Anerkennung für die geleistete harte Arbeit allgemeine Zufriedenheit; und weil alle Vorgänge transparent abliefen, gewannen die Vorgesetzten wertvolle Einblicke, welche Mitarbeiter gute Leistungen erbrachten und wer nie ein Kompliment erhielt. Literaturverzeichnis Alberg, Amy. How to Celebrate Success throughout Your Projects <http://bit.ly/i94fwz> Making Things Happen, 21. Mai Web, 23. Juli Duarte, Nancy. Resonate: Present Visual Stories that Transform Audiences. Hoboken, NJ: Wiley, Gedruckte Veröffentlichung. Fleming, Nic. The Bonus Myth: How Paying for Results Can Backfire <http://bit.ly/fk7uxj> NewScientist, 12. April Web, 23. Juli ZUM AUTOR Jurgen Appelo ist Verfasser des Buchs Management 3.0, das die Rolle des Managers in agilen Organisationen beschreibt, sowie von How to Change the World, einem Modell für organisatorische Veränderung. Dieser Beitrag wird in das 2013 erscheinende Buch Management Workout einfließen. Jurgen Appelo ist außerdem Verfasser des in Jurgen Appelo vielen Ländern erhältlichen Kurses Management 3.0. Ausführlichere Informationen über die Bücher und den Kurs erhalten Sie unter 4 Sybit agile Ausgabe 11

5 DevOps - Agilität weiter gedacht Thomas Wilhelm, Product Owner, Sybit GmbH Viel hat man in letzter Zeit über "DevOps" lesen können. Die noch recht junge Bewegung fand ihren Namen mit den ersten "DevOpsDays", die Patrick Debois [1] 2009 in Belgien organisierte. Seither hat sich der Begriff "DevOps" rasant verbreitet und seinen festen Platz in der agilen Bewegung gesichert. Doch was verbirgt sich hinter dem Begriff? Woher kommen seine Anhänger und was bedeutet "DevOps" für die tägliche Arbeit in der Softwareentwicklung? Schaut man zurück auf die ersten DevOpsDays, so finden sich Themen wie "Cucumber-nagios rethinking monitoring for the cloud", "Non-Functional Requirements: do user stories help?", "Introducing Kanban in operations", "Continuous Integration, Pipelines and Deployment" Diese wurden mehrheitlich von Sprechern aus dem IT- Operations-Umfeld präsentiert. Es ging also um die Frage, wie sich agile Methoden und Ideen auf IT-Betrieb und Qualitätssicherung der entwickelten Software auswirken. Das Problem Allzu oft wurde und wird dem Betrieb der Software während der Entwicklungsphase immer noch zu wenig oder keine Aufmerksamkeit geschenkt. Nichtfunktionale Anforderungen an Sicherheit, Skalierbarkeit, Monitoring und Rollout der entwickelten Lösung werden vom Entwicklungsteam ignoriert und auf den IT-Betrieb abgeschoben. Das Team liefert zwar mit jedem Release neue funktionale Features, bis diese aber tatsächlich produktiv genutzt werden können, ist häufig schon der nächste Sprint beendet. An der Schnittstelle zwischen Entwicklung und Betrieb herrscht oft gegenseitiges Unverständnis für die Probleme und Prioritäten der Gegenseite. Auf der einen Seite ist das agile Entwicklungsteam stetig bemüht, die Anzahl der gelieferten Features, d.h. auch die Anzahl der Änderungen am Softwareprodukt zu erhöhen. Auf der anderen Seite hat der IT-Betrieb, der letztendlich die Verantwortung für Stabilität und Sicherheit der Anwendung trägt, das Bestreben, möglichst wenige Änderungen zuzulassen, um einen stabilen Betrieb der Anwendung zu gewährleisten. Zusätzlich ergeben sich aus dem anhaltenden Trend zur Virtualisierung und dem verteilten Deployment von Anwendungen neue Herausforderungen für den Betrieb von Software. Cloud-Deployments und Verteilung in virtuellen Sybit agile Ausgabe 11 5

6 Maschinen können und sollten nicht erst beim Rollout der Software Beachtung finden, sondern müssen von Anfang an bei der Architektur der Anwendung berücksichtig und getestet werden. Hier genau setzen die Ideen der DevOps-Bewegung an, indem sie zum einen versucht, agile Methoden ins Lager der IT-Operations zu tragen, sowie andererseits Entwickler für Betriebsthemen zu sensibilisieren. Die vielbeschriebene Time-To-Market kann letztendlich nur dann erfolgreich verkürzt werden, wenn entwickelte Features kontinuierlich ausgerollt werden können, ohne dabei die Sicherheit, Stabilität und Qualität der Lösung zu gefährden. Drei Ziele Zusammenarbeit Die enge Zusammenarbeit zwischen Entwicklung und IT- Betrieb ist also ein zentrales Anliegen der DevOps Bewegung. Nicht zuletzt sollen Veranstaltungen wie die DevOps- Days neben dem gegenseitigen Verständnis auch dazu dienen, den Austausch zwischen Dev und Ops zu fördern. Für die Projektarbeit bedeutet dies nicht zwangsläufig, dass jedes Entwicklungsteam einen Betriebsexperten in seinen Reihen braucht. Vielmehr ist es wichtig, die aus Betriebssicht wichtigen Anforderungen von Anfang an bei der Planung der Stories zu beachten und schon mit der ersten Iteration auch den Rollout bis zum Produktionssystem als Teil der erfolgreichen Umsetzung anzusehen. Spätestens hier wird das Entwicklungsteam zumindest punktuell einen erfahrenen "Betriebsmann" brauchen, der einerseits ein grundlegendes Verständnis für den Betrieb der Software, andererseits aber auch ein Verständnis für die Methoden und Werte der agilen Softwareentwicklung mitbringt. Automatisierung Der komplette Rolloutprozess wird somit als Teil des Entwicklungsprozesses etabliert und kontinuierlich aufgebaut und verbessert. Von der "Continuous Integration", die mittlerweile zum Grundsetup eines Softwareprojektes zählt, bewegen wir uns zur "Continuous Delivery". Dabei ist das Ziel die vollständige Automatisierung des Rollout, ohne jedoch Stabilität und Qualität der Software zu gefährden. Mittlerweile hat sich eine ganze Reihe von Tools etabliert, die bei der Automatisierung des Rollout und den Regressionstests unterstützen und diese nahtlos in den Softwareentwicklungsprozess einbinden. Im Idealfall können neue Features somit direkt nach der Fertigstellung und Freigabe ohne manuellen Aufwand im produktiven System ausgerollt werden. Regelmäßige "große" Releases, welchen mehrwöchige Optimierungs- und Testphasen vorausgehen, werden durch den automatisierten Rollout einzelner Features ersetzt. Natürlich ist dies nicht in jedem Kontext ohne weitere qualitätssichernde Maßnahmen möglich. Prozesse Die Diskussion über diese wichtigen Prozesse zu führen und daraus Best-Practices und Empfehlungen abzuleiten, ist ein weiteres Anliegen der DevOps-Bewegung. Schaut man sich die Vielzahl der heute eingesetzten Entwicklungsplattformen und Anwendungsbereiche von Software an, so ist es nicht verwunderlich, dass hier die Vorstellungen und Ideen noch weit auseinandergehen. Von einer einheitlichen Sicht auf typische DevOps-Prozesse und deren Einführung sind wir daher sicher noch weit entfernt. Alleine die Tatsache, dass die Diskussion geführt wird 6 Sybit agile Ausgabe 11

7 und das Thema in den Fokus agiler Softwareentwicklung gerückt ist, ist jedoch ein großer Erfolg der DevOps-Bewegung. Einen interessanten Ansatz zur Strukturierung von DevOps-Praktiken stellt Patric Debois auf seinem Blog zur Diskussion [2]. Er schlägt darin ein Vorgehen zur strukturierten Erfassung von gängigen DevOps-Praktiken vor. DevOps in der Praxis Motiviert durch den Wunsch entwickelte Software schneller auszuliefern, stellen sich die typischen Fragen und Problemstellung, welche die DevOps-Bewegung versucht zu adressieren. Zum Beispiel: Wie kann eine Continous Delivery Pipeline eingeführt werden? Um das Ziel der vollautomatischen Auslieferung von Softwarepaketen zu erreichen, ist - wie oben aufgezeigt - eine enge Zusammenarbeit zwischen Entwicklung und Betrieb unabdingbar. Für das Setup von Systemen und den Rollout sind mittlerweile sehr gute Tools vorhanden und es gibt viele Projekte die Continuous Delivery erfolgreich umgesetzt haben [3]. Scheut man den initialen Aufwand zum Aufsetzen der Continuous Delivery Pipeline und die Anschaffung der nötigen Rechenpower nicht, so steht dem vollautomatischen Rollout technisch nichts im Wege. Die Herausforderungen liegen in der Praxis im Zwischenmenschlichen und Organisatorischen. In der Abstimmung zwischen Entwicklung und Betrieb muss ein Umdenken vollzogen werden: weg von "Das ist aber in der Verantwortung des Betriebs" hin zu "Wie bekommen wir als EIN Team unsere Software schneller vom Entwickler zum Kunden". Dabei hilft auch keine noch so gute Prozessbeschreibung sondern nur, sich an einen Tisch zu setzen, und eine für beide Seiten gute Lösung gemeinsam zu erarbeiten. häufig nicht unerhebliche Aufwände für die Erstellung und vor allem Wartung der Tests. Alle vom System benötigten Daten und externen Schnittstellen müssen außerdem für die Tests absolut stabil sein. Dies bedeutet in der Praxis, dass man das System für die Tests mit geeigneten Testdaten initialisieren und diese nach jedem Test auch zurücksetzen muss. Externe Schnittstellen müssen in den meisten Fällen durch eigene Mock -Implementierung ersetzen werden, um die Reproduzierbarkeit der Tests zu gewährleisten. Für die eigene Umsetzung empfiehlt sich in der Praxis ein pragmatisches Vorgehen getreu dem Motto Teste so viel wie nötig aber so wenig wie möglich. Hier ist Fingerspitzengefühl gefragt, um einerseits ein schnelles und aussagekräftiges Feedback zur Qualität des Systems zu generieren und andererseits die Aufwände für die Pflege der automatischen Tests im Rahmen zu halten. Zukunft Neben der konkreten Anwendung von DevOps-Praktiken und -Tools wird das Thema von einigen seiner Protagonisten mittlerweile in einem weit größeren Kontext diskutiert. So plädiert Patrice Debois auf seinem Blog [4] dafür, die Ziele und Ideen neben Entwicklung und Betrieb auch auf andere Unternehmensbereiche zu übertragen. Auch Damon Edwards zielt mit seinem Blogbeitrag "DevOps is not a technology problem. DevOps is a business problem." [5] in die gleiche Richtung. Geht es bei DevOps also doch um mehr als die optimale Integration von Entwicklungs- und Betriebsprozessen? Man darf gespannt sein, welche Richtung die Diskussion hier in Zukunft noch nehmen wird. Im Moment haben wir im Projektalltag sicher genügend zu tun, um Continuous Delivery Realität werden zulassen und dabei gleichzeitig Qualität und Budget im Zaum zu halten. Quellenverzeichnis [1] [2] [3] [4] [5] ZUM AUTOR Ein Thema, das in der Diskussion zu DevOps oft stiefmütterlich behandelt wird, ist die Qualitätssicherung der ausgelieferten Software. Denn allein mit der vollautomatischen Auslieferung von Artefakten ist es natürlich nicht getan. Das Vorhandensein von Unit-Tests sollte mittlerweile selbstverständlich sein. Darüber hinaus müssen aber möglichst vollständige System- und ggf. Lasttests automatisch durchgeführt werden, um dem Entwickler eine aussagekräftige Rückmeldung zur Qualität seiner Änderungen zu geben. Gerade für den Test komplexer Webanwendungen entstehen hier erfahrungsgemäß Thomas Wilhelm Thomas Wilhelm ist Projektleiter und Product Owner bei der Sybit GmbH. Als Certified Scrum Product Owner hat er Erfahrung in Softwarearchitekturen und Entwicklung von webbasierten und verteilten Anwendungen. Mit agilen Methoden bringt er die Kundenprojekte zuverlässig in Time und in Budget ans Ziel. Sybit agile Ausgabe 11 7

8 Introducing Continuous Delivery Christoph Lukas & Alexander Birk, pingworks In Zeiten immer kürzerer Produktzyklen sollen neue Features nicht mehr im Zeitrahmen von Monaten sondern innerhalb weniger Wochen oder Tage beim Kunden ankommen. Gleichzeitig darf man sich keine Abstriche in der gelieferten Qualität leisten und muß die Software vor jedem Release ausgiebig testen. Diesen scheinbaren Widerspruch zwischen 'wir wollen alle zwei Wochen live gehen' und 'wir brauchen eine umfangreichere Testphase' kann man nur mit Techniken wie Continuous Delivery auflösen. Introducing Continuous Delivery Softwareentwicklung in klassischen Releasezyklen folgt häufig dem folgenden Schema: Nach einer intensiven Planungsphase wird die Software isoliert im stillen Kämmerlein entwickelt, sporadisch integriert und nach Abschluss der Entwicklung in einer länglichen Testphase geprüft. Die gefundenen Bugs werden gefixt um schlussendlich irgendwann ein Release zu erhalten. Dieses Release wird dann kurz vor geplantem Projektende zum ersten Mal ernsthaft auf der Produktionsumgebung deployed. Bei diesem Vorgehen liegt ein hohes Risiko gerade in der seltenen Integration und dem späten Deployment. Daher ist die grundsätzliche Idee hinter Continuous Delivery: Jeder Commit produziert ein potentielles Release der Software. Alle Schritte, die oben beschrieben sind, werden dabei voll automatisiert mit jedem Commit durchgeführt. Technisch baut man dazu eine sogenannte Build Pipeline aus mehreren Stufen auf: 8 Sybit agile Ausgabe 11

9 Jeder Commit triggert einen kompletten Build-Prozess und läuft schrittweise von links nach rechts durch die oben abgebildete Pipeline. 1st Stage In der sogenannten 1st Stage oder Commit Stage werden die Komponenten der Anwendung kompiliert und alle Unittests ausgeführt. Ist beides erfolgreich, werden die Binärartefakte der Anwendung paketiert. Für den weiteren Durchlauf durch die Pipeline und alle weiteren Tests werden jetzt diese Pakete genutzt. Waren diese Schritte erfolgreich, werden die Binärpakete der 2nd Stage übergeben. 2nd Stage In der 2nd Stage werden die Pakete Integrationstests unterzogen. Hier findet also bereits die Integration der Komponenten der Anwendung statt. Seiteneffekte sollten eigentlich spätestens hier auffallen. Und diese Integration passiert nicht einmal pro Sprint, nicht einmal am Tag, sondern mit jedem einzelnen Commit, so dass man solche Seiteneffekte einem einzelnen Commit zuordnen kann. Sind auch die Integrationstests erfolgreich, werden die Binärpakete zur 3rd Stage weitergereicht. Tests durchgeführt werden, immer produktionsnäher, so dass man mit dem Durchlauf der Pakete durch die Pipeline auch ein immer realistischeres Deployment und einen immer realistischeren Betrieb der Software testet. Feedback Während die Pakete durch die Pipeline laufen, bekommt der Entwickler kontinuierlich Feedback über die Qualität seines Commits. Die Ergebnisse aus der 1st Stage sollten dabei bereits in unter 10 min vorliegen, da sonst die Gefahr besteht, dass die Entwickler sich längst anderen Aufgaben zugewandt haben, bevor die Unittests fertig sind. Buildpipeline im Detail Will man eine solche Buildpipeline umsetzen, so kann man dazu einen Continuous Integration Server wie z.b. Jenkins einsetzen. Mit einem solchen Server können viele verschiedene Build Schritte vom einfachen Bau der Software bis hin zum Aufruf von externen Programmen abgebildet werden. 3rd Stage In der 3rd Stage werden die Systemtests mit den Paketen durchgeführt. Dies können bei Webanwendungen z.b. Seleniumtests sein. Haben die Pakete auch diese dritte automatische Teststufe passiert, können weitere manuelle Testschritte folgen und bei Erfolg die Pakete zu einem echten Release werden. Vertrauen in die Qualität des Builds Die aus einem Commit erzeugten Pakete werden jeweils nur dann in die nächste Stage weitergereicht, wenn die jeweiligen Tests erfolgreich waren. Je weiter also die Pakete aus einem Commit in der Pipeline gekommen sind, desto höher wird das Vertrauen in die Qualität dieser Pakete. Produktionsnahe Umgebungen Zugleich werden die Systeme, auf denen die jeweiligen Das obige Bild zeigt die Pipeline noch einmal mit etwas mehr Detailtiefe: Die Entwickler committen eine Änderung in das zentrale Source-Code-Repository, von dort wird automatisch die Build Pipeline getriggert. In der 1st Stage aktualisiert Jenkins den Softwarestand aus dem Sourcecode Repository, kompiliert die Komponenten und führt alle Unittests aus. Bei erfolgreicher 1st Stage wird die Anwendung paketiert, Sybit agile Ausgabe 11 9

10 die Binärpakete werden dann in einem zentralen Repository abgelegt. Von dort bedienen sich alle folgenden Schritte in der Pipeline und nutzen exakt diese in der 1st Stage erstellen Binärpakete für die weiteren Tests. Wird nach erfolgreicher 1st Stage für einen Commit die 2nd Stage getriggert, so werden die Binärpakete vom Jenkins aus dem Repository geholt, auf eine Testumgebung deployed, die Anwendung dort konfiguriert und danach auf dieser Umgebung die Integrationstests gestartet. Sind auch die Tests der 2nd Stage erfolgreich, so wird das gleich Prozedere für die 3rd Stage durchgeführt. Der Jenkins holt die entsprechenden Binärpakete aus dem Repository, deployed diese auf eine Umgebung für Systemtests, konfiguriert die Anwendung und lässt dort die Systemtests laufen. Aus diesem Repository können beliebige Stände der Anwendung manuell auch auf weitere Testumgebungen (Staging, ) oder Entwicklersysteme deployed werden. Bevor es losgeht Damit man eine Build Pipeline für Continuous Delivery Umsetzen kann, müssen ein paar Voraussetzungen erfüllt sein. Testsystemen deployed werden. Aber die wenigsten Anwendungen werden dann ohne Eingriff in die Konfiguration gleich funktionieren. Dazu ist zwingend ein entsprechendes Tooling notwendig, um automatisch eine passende Konfiguration für die Anwendung generieren zu können. Womöglich unterschiedlich, je nachdem, welche Komponente man gerade testen will. Continuous Delivery braucht DevOps Thinking Der Gedanke von Everybody is responsible for delivery muss letztlich bei allen Entwicklern ankommen, wenn man Continuous Delivery implementieren möchte. Das Deployment der Anwendung rückt durch Continuous Delivery sehr nah an die eigentliche Entwicklungstätigkeit heran. Nehmen die Entwickler diese Verantwortung nicht an, kann Continuous Delivery nicht funktionieren. Eine ausführlichere Betrachtung dazu liefert Thomas Wilhelm in 'DevOps - Agilität weiter gedacht' in dieser Ausgabe. Konkrete Implementationsschritte Bei der eigentlichen Implementierung von Continuous Delivery sind häufig die folgenden konkreten Aufgaben zu lösen: Standardisierung der Testumgebungen Standardisierung des Deployments Standardisierung der Konfiguration Aufbau der Build Pipeline Diese Schritte kann man allerdings nicht sequentiell abarbeiten, sondern eher in vielen Iterationen gleichzeitig. Testumgebungen Für Continuous Delivery benötigt man eine flexible Zahl von Testumgebungen. Hier ist der Einsatz von Virtualisierung unumgänglich, da man mit physikalischen Maschinen schlicht zu unflexibel und zu langsam ist. Continuous Delivery braucht Continuous Integration Ohne kontinuierliche Integration der Anwendung macht Continuous Delivery nicht viel Sinn. Elementare Idee hinter Continuous Delivery ist, alle Komponenten der Anwendung bereits mit jedem Commit zu testen und zu integrieren. Dazu gehören nicht nur Unittests sondern eben auch Integrations- und Systemtests. Continuous Delivery braucht automatisierte Tests Eigentlich klar, oder? Alle Tests müssen automatisch mit jedem Commit ausgeführt werden können. Das schließt allerdings auch Dinge wie die Vorbereitung der Testdaten mit ein! Continuous Delivery braucht Configuration Management Die Anwendung muss schon in der 2nd Stage mit jedem Commit unter Umständen mehrfach automatisch auf Alle Testumgebungen müssen aus Sicht der Anwendung (nahezu) identisch ausssehen. So vereinfacht es das Deployment beispielsweise erheblich, wenn z.b. die REST- Schnittstelle der Businesslogik immer unter dem gleichen Hostnamen erreichbar ist. Testumgebungen müssen sich schnell und unkompliziert erzeugen lassen. Um das zu erreichen, sollte man Techniken wie gescriptetes Cloning und Setup der Umgebungen einsetzen. Deployment Auf die so standardisierten Testumgebungen kann man dann in immer der gleichen Art und Weise die Anwendung deployen. Dazu sollte die Anwendung einen einfachen Installer erhalten, der die immer wiederkehrenden Aufgaben beim 10 Sybit agile Ausgabe 11

11 Deployment (Installation, Konfiguration, Restart von Komponenten) auf die immer gleiche Weise durchführen kann. Infrastructure as Code Grundsätzlich sollten alle für den Betrieb der Anwendung nötigen Infrastrukturen, wie z.b. Definition von Testsystemen, Installer, Konfigurationstooling auch als Code aufgefasst und genauso behandelt werden. Hürden bei der Implementation Bei der Umsetzung von Continuous Delivery sind allerdings auch einige Hürden zu überwinden. Spätestens wenn man automatisiert Testumgebungen clonen und konfigurieren will und damit z.b. vollen Zugriff auf einen firmeneigenen Virtualisierungs-Server braucht, wird man damit konfrontiert, den Graben zwischen Development und Operations zuschütten zu müssen. Man muss auf beiden Seiten für die Interessen der Anderen werben, damit man solche Techniken einsetzen kann. Die Software hat insgesamt deutlich weniger Fehler. Decken die Tests einen wesentlichen Teil der Funktionalität ab und testen sie nicht immer nur den einfachsten Positivfall, kommt dies der Qualität der Software deutlich zu Gute. Den Entwicklern bleibt mehr Zeit für die Entwicklung von Features, da der manuelle Build, das Deployment und die Konfiguration der Software entfällt. Ausblick Leider ist Continuous Delivery kein Produkt, das man zu der Entwicklung einfach so dazu kaufen kann. Die Implementation von Continuous Delivery ist sehr projektspezifisch und erfordert vor allem und in vielerlei Hinsicht ein Umdenken aller Beteiligten. Aber jeder, der den Schritt von Softwareentwicklung ohne Tests zu Continuous Integration schonmal gemacht hat, kennt den Effekt: Einmal gemacht will man nie mehr ohne. Wenn man die Vorteile von Continuous Delivery dauerhaft nutzen will, kann das nur dann gehen, wenn sich alle Entwickler auch für die Delivery verantwortlich fühlen. Die beste Build-Pipeline kann nur dann wertvolles Feadback liefern, wenn fehlschlagende Tests oder fehlschlagende Deployments auch von den Entwicklern zeitnah angegangen werden. Leider gibt es Continuous Delivery auch nicht ganz umsonst. Die Entwickler lassen sich schnell von der Vorteilen überzeugen: Wer erstellt schon gerne Testprotokolle von Hand oder verbringt Stunden mit der Konfiguration des Testsystems. Beim Management ist die Hürde etwas höher. Wenn man allerdings den Aufwand für das manuelle Testen, Deployment und die Delivery ehrlich aufrechnet und dazu die messbar höhere Qualität der Software ins Feld führt, wird sehr schnell ersichtlich, dass das Geld hier gut investiert ist. Gewinn Und ist es jetzt auch wirklich die Sache wert? Was lässt sich damit gewinnen? Die Software wird tagtäglich zig mal deployed. Das Deployment wird also kontinuierlich mit getestet. Überraschungen beim Deployment der Software in der Produktivumgebung sollten damit der Vergangenheit angehören. Die Konfiguration der Software ist unter Kontrolle, auch auf dem Produktivsystem. Damit sollte sich das hässliche Ping-Pong zwischen Entwicklern und Operations wegen fehlerhafter Konfiguration vermeiden lassen. ZU DEN AUTOREN Unter dem Namen pingworks beschäftigen sich Christoph Lukas und Alexander Birk bereits seit 1998 mit der Entwicklung von Webapplikationen. Getrieben durch Ihre technische Neugier, vor allem für offene Standards, Frameworks und Betriebssysteme, haben sie in vielen Projekten Christoph Lukas als Entwickler, Architekten und zuletzt immer auch als agile Mentoren mitgearbeitet. Insofern wundert es nicht, dass sie derzeit die Herausforderung Continuous Delivery besonders spannend finden: Lean/Agile Mindset, übergreifende Kommunikation und breites technisches Knowhow werden hier gleichermaßen gefordert. Alexander Birk Sybit agile Ausgabe 11 11

12 Agile Innovation Produktmanagement in turbulenten Zeiten Vasco Duarte, Agile Coach, Avira Ständig hören wir heute, dass uns der Wettbewerb auf den Fersen sitzt, dass der Markt und das Umfeld sich verändern und dass auch wir uns entsprechend verändern müssen. Vor allem aber wird uns gesagt, dass wir auf unsere Kunden hören müssen, um ihnen die richtigen Produkte liefern zu können. Wir als Produktmanager müssen über die grundlegenden Produktentscheidungen (z. B. Erweitern wir Funktion A oder Funktion B? ) hinausblicken können. Wir müssen weiter denken als bis zum Tellerrand unserer Aufgabe. Das Problem dabei ist: Wir müssen wissen, was als Nächstes geschieht, damit wir besser als unsere Wettbewerber sein können; erkennen, welche Prozesse zu langsam ablaufen, damit wir sie beschleunigen und uns am Markt gegen die Konkurrenz durchsetzen können; sondieren, was praktikabel ist, damit wir das richtige Produkt und den richtigen Produktmix für unsere Kunden finden können. All dies wäre möglich, wenn wir schnell lernen und uns anpassen könnten unter anderem mithilfe von Kundenfeedback und schnelleren Prozessen. Die Frage, die wir uns stellen müssen, lautet also: Wie können wir das erreichen? Wie können wir lernen, zu lernen? Wie können wir als Produktmanager zur Fortentwicklung unserer Organisation beitragen, um durch Lernen und Anpassung an neue Bedingungen zu verbessern? Nur durch diese Fähigkeit zum Lernen und zur schnellen Anpassung können wir schneller werden, indem wir unsere Prozesse verschlanken und nur die Arbeit leisten, die wirklich nötig ist. Auf diese Probleme möchte ich in meinem Beitrag eingehen. Wie können wir uns diesen Herausforderungen stellen? Langsame Prozesse schaden der Wettbewerbsfähigkeit und Wir könnten vermutlich schneller sein deutlich schneller als heute. Wenn Experten die Arbeitsweise in einem durchschnittlichen Unternehmen untersuchen, werden sie in der Regel feststellen, dass ein großer, sogar ein sehr großer Teil der in diesen Unternehmen geleisteten Arbeit schlichtweg verschwendet ist. Diese Arbeit leisten wir zwar, aber sie erbringt keinerlei Wert für unsere Kunden. Das ist ein ernstes Problem, denn alles, was wir tun, erhöht die Kosten unserer Produkte und Dienstleistungen. Wenn unsere Arbeit keinen Mehrwert erbringt, so geben wir im Prinzip Geld aus, das wir niemals zurückbekommen können. Kein Mehrwert! Viele Beratungsfirmen beziffern das Verhältnis zwischen wertschöpfender und verschwendeter Zeit mit ca. 1 5 %. Das heißt, % werden verschwendet! Ein weiteres wichtiges Ergebnis besteht darin, dass langsame Prozesse in der Regel mit niedrigerer Qualität verbunden sind. Das leuchtet ein, denn je kürzer ein Prozess ist, desto weniger Fehler können wir uns dabei leisten. Wenn wir viele Fehler machen, wird der Prozess langsamer, beispielsweise weil eine umfangreiche Prüf- und Testphase am Ende des Projekts erforderlich ist. Es gibt aber auch gute Nachrichten. Wenn langsame Prozesse verschwendete Zeit enthalten, dann tragen wir, indem wir uns um eine Beschleunigung dieser Prozesse bemühen, zwangsläufig zur Qualitätsverbesserung und Kostenreduzierung bei. Niedrigere Kosten sind also eine Konsequenz schnellerer, hochwertigerer Prozesse. Fall I: Auftragsabwicklungsprozess einer Softwarefirma Das folgende Beispiel ist eine Wertstromanalyse (Value 12 Sybit agile Ausgabe 11

13 Stream Map) [1], die bei der Analyse einer Auftragsabwicklung in einer Softwarefirma erstellt wurde. Vorgang Partner erteilt einen Auftrag (100 CDs) Auftrag wird in das hausinterne System eingetragen Auftrag wird in der Fabrik registriert Auftrag ruht bis zum Erreichen der Mindestlosgröße (z. B. 1000) Auftragskarton wird angefertigt Versandpaket für den Auftrag wird angefertigt Versandpakete für alle Aufträge werden angefertigt Wertschöpfende Zeit (in Min.) 5 Min. 0 Min. 1 Min. 10 Min. 0 Min. 5 Min. Verschwendete Zeit (in Min.) 0 Min. ~2 Tage (2880 Min.) 1 Min. x Anzahl CDs = 100 Min. 0 Min. 10 Min. 5 Min. x Anzahl CDs = 500 Min. 5 Min. 50 Min. (im Mittel jeder 10. Auftrag) Paketversand 5 Min. 50 Min. (im Mittel jeder 10. Auftrag) Aus Sicht des Kunden hat sich dieses Unternehmen 6385 Minuten lang mit Aufgaben beschäftigt, die keinen Mehrwert für das Endprodukt geschaffen haben, und dagegen nur 116 Minuten lang Arbeiten geleistet, für die der Kunde zu zahlen bereit war. Das Verhältnis von wertschöpfender zu verschwendeter Zeit betrug bei diesem Vorgang insgesamt 1,8 %; das heißt, aus Kundensicht waren 98,2 % der aufgewendeten Zeit verschwendet. Der entscheidende Aspekt ist hier, dass ein Prozess immer nur mit einer begrenzten Menge von Wert ausgestattet werden kann, dass aber die mögliche Menge der verschwendeten Zeit unbegrenzt ist. Mehr verschwendete Zeit steigert die Kosten des Produkts, ohne seinen Wert zu erhöhen, und bewirkt für unsere Unternehmen einen erheblichen Wettbewerbsnachteil gegenüber der Konkurrenz. Wir konnten zwar nicht die gesamte bei dieser Analyse ermittelte Zeitverschwendung eliminieren, aber einen Teil davon durchaus. Außerdem wussten wir, welche langfristigen Veränderungen erforderlich waren, um einen deutlich schlankeren Prozess mit weniger Verschwendung zu erreichen. Dieses Verfahren wird als Wertstromanalyse (Value Stream Mapping) [1] bezeichnet und lässt sich auf jeden Prozess anwenden. Dabei ist jedoch Folgendes zu beachten: Eine Wertstromanalyse muss den kompletten Prozess (von der Idee bis zum Produkt) abdecken. Wenn wir die entscheidenden Schritte nicht in den Prozess einbeziehen, laufen wir Gefahr, einen Teil des Prozesses zu optimieren, der nicht zur Verbesserung unserer Organisation beiträgt. Als Produktmanager befinden wir uns in einer Schlüsselposition zur Verbesserung der Prozesse unseres Unternehmens. Wenn wir unser F&E-Portfolio immer nur durch neue Projekte erweitern, aber keine Zeit für Verbesserungen reservieren, sind immer langsamere Prozesse das einzige Ergebnis (Littles Gesetz [2] ). Die Beschleunigung unserer Prozesse und die Reduzierung der noch nicht abgeschlossenen Arbeit ist SCHRITT 1 unserer Bemühungen, unsere Wettbewerbsfähigkeit zu verbessern. Arbeiten Sie mit dem Kunden zusammen, um Ihre Produkte besser kennenzulernen Die Ermittlung und Eliminierung von Verschwendung ist eines der wichtigsten Hilfsmittel des Verschlankungsansatzes (Lean approach) für kontinuierliche Verbesserung. Durch gute Ergebnisse bei der Eliminierung von Verschwendung können wir allerdings nur schneller werden. Darüber hinaus müssen wir noch herausfinden, wie wir das Richtige tun und unsere Kunden durch eindrucksvolle Leistungen oder Services überzeugen können. Einer der Eckpfeiler der agilen Softwareentwicklung [3] ist Feedback, und zwar insbesondere Kundenfeedback. Auch hier befinden sich die Produktmanager wieder in einer Schlüsselposition, um ihren Unternehmen zu helfen, sich zu verbessern. Unser erstes Augenmerk sollte darauf gerichtet sein, nicht mehr mit langfristigen Roadmaps zu arbeiten, die keinen Verhandlungsspielraum lassen. Es ist eine Tatsache, die wir akzeptieren müssen: Wir können nicht vorhersagen, was in ein, zwei oder drei Jahren von Bedeutung sein wird; und wenn wir versuchen, solche Voraussagen zu machen und unsere Roadmaps entsprechend langfristig festzulegen, ist die Wahrscheinlichkeit groß, dass ein wendigerer Mitbewerber unseren Innovationsprozess überholt und uns insgesamt aus dem Geschäft verdrängt. Erinnern wir uns: Giganten wie Yahoo! folgen mittlerweile in großem Abstand hinter den Wettbewerbern, denen es gelungen ist, die Innovationsgeschwindigkeit ihrer Produkte deutlich zu erhöhen (z. B. Facebook, Google usw.) Wenn wir akzeptiert haben, dass langfristige Roadmaps ohne Verhandlungsspielraum keine kluge Wahl sind, dann lautet die nächste Frage: Wie kann das funktionieren? Was sagen wir dem Kunden in der Besprechung über ein kommendes Produkt, wenn wir keine Roadmap haben? Das sind wichtige Einwände; zunächst müssen wir uns aber eingestehen, dass wir den zukünftigen Bedarf schlichtweg nicht kennen. Wenn uns ein Kunde fragt: Welche Releases/Produkte/Services bekomme ich nächstes Jahr?, verschafft uns das eine hervorragende Gelegenheit, Informationen von diesem Kunden zu erhalten. Fragen wir doch einfach zurück: Was wäre denn aus Ihrer Sicht in einem Jahr für Ihr Geschäft wichtig? Auf diese Weise entsteht ein dringend erforderlicher Dialog mit dem Kunden, der uns einen entscheidenden Vertriebsvorteil verschafft: Wir haben unseren Kunden nämlich soeben dazu gebracht, sich schon teilweise auf unser Produkt festzulegen, indem er uns mitgeteilt hat, was er in einem Jahr benötigen wird! Unsere Herausforderung besteht also darin zu verstehen, wie wir die langfristige Entwicklung unserer Produkte handhaben können, ohne die langfristigen Roadmaps zu strikt festzuschreiben. Als Produktmanager müssen wir uns überlegen, was für unser Geschäft von Bedeutung ist, und wir benötigen eine Sybit agile Ausgabe 11 13

14 Vorstellung davon, was unser Geschäft seinen Kunden bieten soll; wenn wir uns aber durch langfristige Roadmaps ohne Verhandlungsspielraum selbst die Hände binden, ist das offenbar nicht die beste Vorgehensweise. Fall II: Flexible Anforderungen bei großen Softwareprogrammen Bei einem unserer größten Programme haben wir eine Technik eingesetzt, mit der wir unsere Anforderungen flexibel gestalten konnten, obwohl wir unseren Entwicklungsteams sehr genaue Langzeitvorgaben machten (die sie z. B. für Qualifizierungszwecke benötigten). Wie war das möglich? Wir verwendeten bei der Festlegung der Anforderungen einen Drei-Ebenen-Ansatz, wobei jede Anforderungsebene im Zuständigkeitsbereich einer anderen Rolle innerhalb der Organisation lag und eine jeweils unterschiedliche Abstraktionsstufe aufwies. Auf diese Weise konnten wir umfangreiche Funktionalitätsbereiche (Epics) diskutieren, ohne uns auf eine konkrete Umsetzungsstrategie (Features / User Stories) festzulegen. Ein zweiter Ansatz, den wir bei der Gestaltung eines Portfolios verfolgen können, ist die Methode des flexiblen Portfolios, bei der wir als Produktmanager unser Portfolio entlang zweier Achsen analysieren: Breite (wie viele neue Funktionen wollen wir bereitstellen?) und Tiefe (wie viel technologische Entwicklung sollten wir in jede Funktionalitätsgruppe einbringen?). Ein tiefes Portfolio sollte in einem anderen Geschäftsumfeld eingesetzt werden als ein breites Portfolio; auch eine Kombination dieser beiden Ansätze ist möglich. Während wir eine langfristige Roadmap erarbeiten, können wir Feedback zu den Zwischenreleases sammeln und diese Ergebnisse in unser Portfolio einfließen lassen, indem wir entscheiden, wo wir eine tiefere Funktionalität implementieren möchten und wo wir das Portfolio verbreitern wollen. Der Vorteil dieses Konzepts besteht darin, dass es das Feedback über einen Rückkopplungskreis direkt in den Portfoliomanagement-Prozess einfließen lässt und uns die Möglichkeit bietet, die Tiefe jedes Epic an die verfügbare Zeit anzupassen (Innovation und Wettbewerbsfähigkeit). Dieses Verfahren können Sie gleich morgen einsetzen: Zeichnen Sie die beiden Dimensionen für Ihr Portfolio auf. Überlegen Sie sich, was für Sie wichtiger ist: wenige tiefe Epics oder viele flache Epics. Agile Produktentwicklung. Lernfähige Prozesse Der oben beschriebene Fall ist nur ein Beispiel dafür, wie wir einen Rückkopplungskreis herstellen können, mit dessen Hilfe unser Unternehmen lernen und sich an die jeweiligen Entwicklungen des realen Umfelds anpassen kann. Agil beschränkt sich aber nicht nur auf das Portfolio- Management. Wir müssen in der Lage sein, Prozesse zu gestalten, die unser Unternehmen lern- und anpassungsfähig machen. In einem agilen Produktentwicklungsprozess beziehen wir das Produktentwicklungsteam von Anfang an mit ein. Dadurch erhalten wir einen sehr reaktionsschnellen Rückkopplungskreis für das Feedback zu dem Produkt, während wir es konzipieren und gestalten. Dieser Rückkopplungskreis ist wichtig, um 1. ein Produkt zu gestalten, das aus technischer Sicht machbar ist 2. den F&E-Teams zu ermöglichen, ihr fundiertes technisches Know-how anzuwenden und technische Innovationen in das Produkt einzubringen, die uns anderen eventuell nicht bewusst sind. Fall III: Der zyklische unternehmensweite Prozess Hier sehen wir eine völlig andere Vorgehensweise beim Entwurf eines unternehmensweiten Prozesses. Das vorherrschende Bild hier sind Zyklen (Cycles): Zyklen, die im Unternehmen unterschiedliche Aufgaben erfüllen, aber miteinander interagieren müssen, damit wir den in jedem Zyklus geschaffenen Wert nutzen können. Die folgende Abbildung zeigt, wie Sie Ihr Portfolio entlang dieser beiden Achsen visualisieren können: Man sieht, dass bei dem oben dargestellten Ansatz für die Prozessgestaltung die Erkenntnisse, die aus einem monat- 14 Sybit agile Ausgabe 11

15 lichen Release des Produkts gewonnen werden, schnell in den Produktmanagementprozess zurückgespeist und dort zur Anpassung an die neuen realen Sachverhalte genutzt werden können. Schnelle Lern- und Anpassungsfähigkeit kann einen entscheidenden Wettbewerbsvorteil für unsere Unternehmen und Produkte darstellen. Umsetzung in die Praxis Da wir uns in einem zunehmend wettbewerbsorientierten Umfeld befinden, in dem Innovationsgeschwindigkeit der entscheidende Faktor ist, benötigen wir neue Konzepte für unsere Arbeitsweise. Einfach immer wieder das Gleiche zu tun und doch ein anderes Ergebnis zu erwarten, ist keine Option. Mit den folgenden Maßnahmen können Sie gleich morgen anfangen: 1. Analysieren Sie Ihre momentane Arbeitsweise und eliminieren Sie unnötige Arbeit. Bei GE wurden Ausarbeitungs-Meetings abgehalten, in denen langsame Prozesse analysiert und Prozessschritte, die keinen Mehrwert zu den betreffenden Produkten oder Dienstleistungen beitrugen, tatsächlich abgeschafft wurden. Sie können eine Wertstromanalyse (Value Stream Mapping) [1] als Methode zur Visualisierung und Überprüfung Ihrer Prozesse einsetzen. 2. Arbeiten Sie mit Ihren Kunden zusammen. Verwenden Sie die oben beschriebene Flexible Scope -Technik, um den Dialog mit dem Kunden zu erleichtern, beispielsweise indem Sie den Kunden in die Auswahl der Epics mit einbeziehen, aber den Teams die Festlegung der Features und Stories überlassen. Verwenden Sie die Flexible Scope -Technik, um die flexible Integration neuer Ideen später im Projekt zu ermöglichen; legen Sie sich beispielsweise gemeinsam mit dem Kunden auf die Epics fest, aber lassen Sie Spielraum für spätere Änderungen auf der Feature- und Story-Ebene in Abhängigkeit von den während des Projekts gewonnenen Erkenntnissen. 3. Welche Zyklen gibt es in Ihrer Organisation bereits? Werten Sie sie aus und nutzen Sie sie anschließend zur Entwicklung einer Rückkopplungskette, sodass Ihre im Feld gewonnenen Erkenntnisse nicht verloren gehen, sondern schnell in den Produktentwicklungsprozess einfließen können. 4. Und schließlich: Nehmen Sie keine neuen Projekte in Angriff, bevor die laufenden abgeschlossen sind. Akzeptieren Sie die Ergebnisse der Mathematik (Littles Gesetz [2] ). Hören Sie auf anzufangen und fangen Sie an aufzuhören! Weitere Informationen über diese und weitere Experimente erhalten Sie auf den Veranstaltungen von Agile Finland (www.agilefinland.com). Agile Finland organisiert jährlich mehrere Veranstaltungen; die Hauptveranstaltung zu Agile findet jährlich in Helsinki statt: Falls Sie Unterstützung bei der Umsetzung der oben beschriebenen Verfahren wünschen oder an weiteren Agile - oder Lean -Ansätzen für die Produktentwicklung interessiert sind, können Sie mich gerne kontaktieren. Quellenverzeichnis [1] Wertstromanalyse: Weitere Lektüre: Toyota Way, Liker: co.ukbook/ /the-toyota-way Learning to See, Shook et al.: Details.cfm?SelectedProductId=9 [2] Littles Gesetz: Weitere Lektüre: Agile Software Development, An Agile Toolkit, Poppendieck: Lean-Software-Development [3] Agile Software Development, Cockburn: co.uk/book/ /agile-software-development ZUM AUTOR Vasco Duarte Derzeit ist Vasco Duarte, ein erfahrener Produkt- und Projektmanager, Agile Coach bei Avira. Seit 1997 arbeitet Vasco in der Software-Industrie und ist seit 2004 auch ein agiler Praktiker seit Als einer der Leader und Katalysatoren von agilen Methoden und Adaption von agilen Kulturen arbeitet er bei Avira und zuvor bei Nokia und F-Secure. Vascos Beiträge zur Entwicklung der Software-Industrie können in seinem Blog gelesen werden: Sybit agile Ausgabe 11 15

16 Agile Breakfast In losen Abständen von rund zwei Monaten treffen sich agil Interessierte der Scrum User Group Lake Constance (SUGLC) zum Erfahrungsaustausch. Beim Agile Breakfast im Wasserturm Stromeyersdorf in Konstanz hält nach einem kleinen Frühstück ein Teilnehmer oder ein geladener Speaker einen Vortrag zu einem agilen Thema. Daran schließt sich eine Diskussion an (Dauer: Uhr). Die Teilnahme ist kostenlos, die Veranstaltung wird von Sybit gesponsert. Informationen zu den aktuellen Veranstaltungen: Sybit GmbH Alle Rechte vorbehalten Fotos: Tobias Link - Sybit & Stephan Strittmatter - Sybit IMMER UP-TO-DATE: Holen Sie sich die kostenlose ipad-app mit allen Ausgaben von Sybit agile im itunes-store. Sybit GmbH Sankt-Johannis-Str. 1 5 D Radolfzell Tel. +49 (0)

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL.

RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. RELEASE AUF KNOPFDRUCK: MIT CONTINUOUS DELIVERY KOMMEN SIE SCHNELLER ANS ZIEL. Die Erwartungen Ihrer Businesskunden an ihre IT steigen. Mehr denn je kommt es darauf an, die Software optimal am Kunden auszurichten

Mehr

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG

CONTINUOUS DELIVERY. Entmystifiziert. codecentric AG CONTINUOUS DELIVERY Entmystifiziert WIE SOFTWARE LIEFERN? 01.07.2014 2 WAS IST CONTINUOUS DELIVERY? Robust Wiederholbar Effektiv 01.07.2014 3 LANDSCHAFTEN Continuous Integration Public / Private Hybrid

Mehr

DevOps. Einführung und Umsetzung am Beispiel ProSiebenSat.1 und dm-drogerie markt. Alexander Pacnik Karlsruhe, 25.06.2015

DevOps. Einführung und Umsetzung am Beispiel ProSiebenSat.1 und dm-drogerie markt. Alexander Pacnik Karlsruhe, 25.06.2015 DevOps Einführung und Umsetzung am Beispiel ProSiebenSat.1 und dm-drogerie markt Alexander Pacnik Karlsruhe, 25.06.2015 Alexander Pacnik IT Engineering & Operations Project Management inovex GmbH Fabian

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin

Agiles Testen. Gedankensammlung. 17. November 2013 - Patrick Koglin Agiles Testen Gedankensammlung 17. November 2013 - Patrick Koglin Inhalt Reflektion: Agilität notwendig? Wo? Eigenschaften agiler Entwicklung Quality is everyone s responsibility Qualität möglich machen

Mehr

Agile Qualitätssicherung. Holger Schmeisky, 17.10.2013

Agile Qualitätssicherung. Holger Schmeisky, 17.10.2013 Agile Qualitätssicherung Holger Schmeisky, 17.10.2013 Agile Qualitätssicherung Studie SoundCloud Team Payment Entwicklungsprozess Qualitätssicherung Analyse / Diskussion 17.10.2013 Holger Schmeisky - Agile

Mehr

Kompetenz in Enterprise Software Engineering

Kompetenz in Enterprise Software Engineering Kompetenz in Enterprise Software Engineering 02 Getting ideas done Die conplement AG als Technologiepartner renommierter Unternehmen erarbeitet zukunftsfähige Enterprise Software Lösungen auf Basis neuester

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

ES GIBT EIN LEBEN NACHCI!

ES GIBT EIN LEBEN NACHCI! ES GIBT EIN LEBEN NACHCI! DEVOPS, CONTINUOUSDELIVERY& CO RUDOLFE. GROETZ, HEAD OFQA, JUMIOINC RUDOLF@JUMIO.COM 1 Wer zum Teufel ist Jumio? 2 Kennen sie diese Fragen? - Ist der neue Build schon getestet?

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen Firmenportrait open4business GmbH open4business Softwareentwicklung für Unternehmen Wer sind Wer wir sind Kurzprofil Die open4business GmbH ist ein mittelständisches IT-Dienstleistungsunternehmen mit Firmensitz

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

SharePoint Continuous Integration mit TFS Online & Azure VMs Torsten Mandelkow Christian Pappert Microsoft

SharePoint Continuous Integration mit TFS Online & Azure VMs Torsten Mandelkow Christian Pappert Microsoft SharePoint Continuous Integration mit TFS Online & Azure VMs Torsten Mandelkow Christian Pappert Microsoft Agenda SharePoint Continuous Integration mit TFS Online & Azure VMs Fehlende Hardware oder mangelnde

Mehr

Von SAFe v2.5 zu SAFe v3.0

Von SAFe v2.5 zu SAFe v3.0 Von SAFe v2.5 zu SAFe v3.0 Neuerungen im Big Picture Juli 2014 Felix Rüssel, KEGON AG 1 Webinar Etiquette Das Webinar wird aufgezeichnet und später zusammen mit der Präsentation veröffentlicht Teilnehmer

Mehr

Qualität. Referenzbericht Privatmolkerei Bauer. statt Durchschnitt. Webdevelopment Responsive Design Webdesign

Qualität. Referenzbericht Privatmolkerei Bauer. statt Durchschnitt. Webdevelopment Responsive Design Webdesign Qualität statt Durchschnitt Referenzbericht Privatmolkerei Bauer Webdevelopment Responsive Design Webdesign Redakteur: Herr Fischer, Sie kamen mit dem Wunsch einer neuen Internetpräsenz zu uns. An welchen

Mehr

DevOps bei den ID Build-Automatisierung statt Silo-Betrieb

DevOps bei den ID Build-Automatisierung statt Silo-Betrieb DevOps bei den ID Build-Automatisierung statt Silo-Betrieb SWS Entwicklertreffen vom 1.10.2015 Benno Luthiger 1.10.2015 1 Ausgangslage Kundenwunsch: Stabiles System, das schnell reagiert ( Betrieb) Neue

Mehr

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Softwareentwicklung

Mehr

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig

Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig Stand: 11.06.2007 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und

Mehr

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at

End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at End-to-End Agility Sind Sie schon agil genug? Mag. Christoph Leithner c.leithner@celix.at www.celix.at September 2015 celix Solutions GmbH Spezialist für Team Collaboration und IT Prozess Management Agile

Mehr

Continuous Delivery. Der pragmatische Einstieg. von Eberhard Wolff. 1. Auflage. dpunkt.verlag 2014

Continuous Delivery. Der pragmatische Einstieg. von Eberhard Wolff. 1. Auflage. dpunkt.verlag 2014 Continuous Delivery Der pragmatische Einstieg von Eberhard Wolff 1. Auflage dpunkt.verlag 2014 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 86490 208 6 Zu Leseprobe schnell und portofrei erhältlich

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Build-Pipeline mit Jenkins

Build-Pipeline mit Jenkins JUG Augsburg 24.10.2013 Seite 1 Wer sind wir? Agiler Architekt und Entwickler Eigenes Produkt mit kompletter Pipeline / CD aktuell: Architekt / Entwickler in einem großen Entwicklungsprojekt im Automotiv

Mehr

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Mit Offshore-Teams arbeiten ist ein Kinderspiel. Von Vikram Kapoor

Mit Offshore-Teams arbeiten ist ein Kinderspiel. Von Vikram Kapoor Mit Offshore-Teams arbeiten ist ein Kinderspiel Von Vikram Kapoor Einführung Offshoring also Auslagern von Softwareentwicklung nach Indien ist nicht mehr einzigartig. Es ist ein übliches Geschäftsmodell

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

Damit Ihr digitales Projekt zuverlässig, sicher und performant läuft

Damit Ihr digitales Projekt zuverlässig, sicher und performant läuft Damit Ihr digitales Projekt zuverlässig, sicher und performant läuft Wir sorgen für den Betrieb Ihrer Software und Web-Anwendung. Dabei liefern wir Ihnen Service aus einer Hand - individuell auf Ihre Bedürfnisse

Mehr

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013

Agiler Healthcheck. Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Agiler Healthcheck Dieter Bertsch & Sabine Canditt Agile Center Allianz Deutschland München / Januar 2013 Inhalt 1 2 3 Motivation Existierende Healthchecks Agiler Healthcheck der Allianz "Der Glaube an

Mehr

AGILES QUALITÄTSMANAGEMENT

AGILES QUALITÄTSMANAGEMENT AGILES QUALITÄTSMANAGEMENT Manfred Rätzmann Head of Department Quality Assurance Deutsche Post E-Post Development GmbH Manfred.Raetzmann@epost-dev.de http://www.epost.de/ Klassische Ziele des Qualitätsmanagements:

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

Mehr

Verzweigungen im Versionsmanagement beherrschen

Verzweigungen im Versionsmanagement beherrschen Embedded Computing Conference 2014 Verzweigungen im Versionsmanagement beherrschen 1. Juli 2014 Winterthur / ZH Ralf Gronkowski, Perforce Software www.perforce.com Ihr lokaler Perforce Partner EVOCEAN

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Value Delivery and Customer Feedback

Value Delivery and Customer Feedback Value Delivery and Customer Feedback Managing Continuous Flow of Value Michael Reisinger Microsoft & ANECON Praxisupdate 2014 ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

Softwareentwicklung bei eevolution

Softwareentwicklung bei eevolution Softwareentwicklung bei eevolution Darstellung der Prozesse mit dem agilen Entwicklungsansatz Jan Freitag, COMPRA GmbH Jan Freitag Studium: IMIT Bachelor: 2005-2008 IMIT Master: 2008-2010 eevolution: Mitarbeit

Mehr

mimacom path Ihr Nutzen www.mimacom.com

mimacom path Ihr Nutzen www.mimacom.com ist ein Lösungspaket, mit dem sich das ganze Application Lifecycle Management abdecken lässt: Vom Requirements Engineering über die agile Abwicklung von Projekten bis hin zum Service Management. Der ganzheitliche

Mehr

Planung in agilen Projekten

Planung in agilen Projekten Planung in agilen Projekten Angelika Drach DeutscheScrum 2012 improuv GmbH Agile Leadership. h7p://improuv.com Über mich Lange Jahre Erfahrung in der Bauplanung Planung und Agiles Vorgehen sind ein Widerspruch?

Mehr

Permanente Integration Einstellung und Prozess versus Werkzeuge

Permanente Integration Einstellung und Prozess versus Werkzeuge Consulting Guild AG Methodenberatung für Projekte im 21. Jahrhundert Permanente Integration Einstellung und Prozess versus Werkzeuge Inhalt: Einleitung 1 Worum geht's hier überhaupt? 2 Überblick 2 Permanente

Mehr

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte

Stefan Toth. Befehl von unten: Softwarearchitektur für dynamische Projekte Stefan Toth Befehl von unten: Softwarearchitektur für dynamische Projekte [ ] Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche

Mehr

Agilität auf Unternehmensebene - Was hält uns davon ab?

Agilität auf Unternehmensebene - Was hält uns davon ab? Agilität auf Unternehmensebene - Was hält uns davon ab? Alexander Birke, Juli 2015 Copyright 2015 Accenture All rights reserved. Wie stellt sich Agilität heute dar? Das Scrum Framework: einfach und mittlerweile

Mehr

Feindliche Gewässer: Warum agile Ideen an Kulturklippen zerschellen

Feindliche Gewässer: Warum agile Ideen an Kulturklippen zerschellen Feindliche Gewässer: Warum agile Ideen an Kulturklippen zerschellen Scrum Day 2013 Berlin, 12.06.2013 Dominik Maximini NovaTec Consulting GmbH Leinfelden-Echterdingen, München, Frankfurt am Main, Berlin,

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Crossover: Vom klassischen zum agilen Tester. Manfred Schützhofer, BSc SEQIS Consultant

Crossover: Vom klassischen zum agilen Tester. Manfred Schützhofer, BSc SEQIS Consultant Crossover: Vom klassischen zum agilen Tester Manfred Schützhofer, BSc SEQIS Consultant Taskboard User Story To Do In Progress Done 1.1 Als Besucher möchte ich die Grundlagen von Agile übermittelt bekommen,

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

Mehr

Deploy von PHP-Applikationen

Deploy von PHP-Applikationen Deploy von PHP-Applikationen Jan Burkl System Engineer Zend Technologies Wer bin ich? Jan Burkl jan.burkl@zend.com PHP Entwickler seit 2001 Projektarbeit Bei Zend seit 2006 System Engineer Zend Certified

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Schneller zu Ergebnissen unser erstes Agile Project

Schneller zu Ergebnissen unser erstes Agile Project Schneller zu Ergebnissen unser erstes Agile Project Thomas Schmidt Juni 2014 Agenda Das Project Projektstruktur und der Projektplan Theorie vs Realität Releases und Sprints Executable Code Angst vor dem

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

!"#$%&'()*+),-%(.,"&/0(& %#,&1,*%(,%23%, )3&4%#56#%$&-%(&78$#-)9:2%;<&!'

!#$%&'()*+),-%(.,&/0(& %#,&1,*%(,%23%, )3&4%#56#%$&-%(&78$#-)9:2%;<&!' 1 @LeanAgileScrum #LASZH!"#$%&'()*)'+)$,-., #/&'0&*)'!"#$%&'()*+),-%(.,"&/0(& %#,&1,*%(,%23%, )3&4%#56#%$&-%(&78$#-)9:2%;

Mehr

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de

Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Was funktioniert und was nicht? Agile Softwareentwicklung in der Praxis Martin Lippert, martin.lippert@akquinet.de Über mich Martin Lippert Senior IT-Berater bei akquinet it-agile GmbH martin.lippert@akquinet.de

Mehr

Agile Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de

Agile Entwicklung àla The Eclipse Way. Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Agile Entwicklung àla The Eclipse Way Dipl.-Inform. Martin Lippert Senior IT-Berater martin.lippert@akquinet.de Über mich Martin Lippert Senior-IT-Berater bei Akquinet Agile GmbH martin.lippert@akquinet.de

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

Vorstellung Sybit (Bereiche SAP CRM und Media) Warum ist Architektur für Sybit so wichtig? z.b. Zulieferung für Sotschi - Große

Vorstellung Sybit (Bereiche SAP CRM und Media) Warum ist Architektur für Sybit so wichtig? z.b. Zulieferung für Sotschi - Große Architekturarbeit ist und bleibt ein wichtiger Aspekt in Software-Projekten, sowohl in klassisch aufgestellten als auch in agilen Teams. Dies macht Mitarbeiter mit entsprechendem Knowhow erforderlich,

Mehr

Wie funktioniert agile Software-

Wie funktioniert agile Software- Wie funktioniert agile Software- Entwicklung mit SCRUM Zürich, 8. Mai 008 Jean-Pierre König, namics ag Software Engineer Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich www.namics.com Agenda»

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Continuous Delivery. für Java Anwendungen. Axel Fontaine 28.10.2010. Software Development Expert

Continuous Delivery. für Java Anwendungen. Axel Fontaine 28.10.2010. Software Development Expert 28.10.2010 Continuous Delivery für Java Anwendungen Axel Fontaine Software Development Expert twitter.com/axelfontaine blog.axelfontaine.eu business@axelfontaine.eu Ceci n est pas une build tool. Ceci

Mehr

Wie agil kann Business Analyse sein?

Wie agil kann Business Analyse sein? Wie agil kann Business Analyse sein? Chapter Meeting Michael Leber 2012-01-24 ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr

Continuous Delivery in der Realität eines Großunternehmens

Continuous Delivery in der Realität eines Großunternehmens Continuous Delivery in der Realität eines Großunternehmens Agile World, 28. Juni 2013 Christian Weber 01 Continuous Delivery Das Versprechen Das Versprechen Sch Entspanntes Release Time To Market 3 02

Mehr

Crowdsourced Software Testing Alternative oder Ergänzung?

Crowdsourced Software Testing Alternative oder Ergänzung? Crowdsourced Software Testing Alternative oder Ergänzung? Was ist Crowdtesting? Vergleich klassische QA und Crowdtesting Anwendungsfelder und Beispiele Georg Hansbauer Geschäftsführer g.hansbauer@testbirds.de

Mehr

Qualitätserlebnis statt Qualitätssicherung. Eine Mehrfachfallstudie agiler Teams

Qualitätserlebnis statt Qualitätssicherung. Eine Mehrfachfallstudie agiler Teams Qualitätserlebnis statt Qualitätssicherung. Eine Mehrfachfallstudie agiler Teams 12.06.2014, Abschlussvortrag Masterarbeit Holger Schmeisky Die Forschungsfrage Wie und unter welchen Bedingungen funktioniert

Mehr

Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick

Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick 1 Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick 2 Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick 3 Des Pudels Kern 4 Silo-isierung 5 Release-Termine

Mehr

Management in agilen Transitionen Impedimentoder Erfolgsfaktor?

Management in agilen Transitionen Impedimentoder Erfolgsfaktor? Management in agilen Transitionen Impedimentoder Erfolgsfaktor? Jürgen Dittmar 28.06.2013, München Who is talking? Jürgen Dittmar > 20 Jahre IT, 10 Jahre Manager Organisationspsychologe (Master) Selbstständiger

Mehr

Special Day OOP 2012 25.01.2012. Continuous Delivery Wettbewerbsvorteil auch für Versicherungen.

Special Day OOP 2012 25.01.2012. Continuous Delivery Wettbewerbsvorteil auch für Versicherungen. Special Day OOP 2012 25.01.2012 Continuous Delivery Wettbewerbsvorteil auch für Versicherungen. Agile Methoden sind derzeit in aller Munde und werden zunehmend als die Zukunft der Softwareentwicklung anerkannt.

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Das Agile Team. Skills, Arbeitsweise, Umgebung

Das Agile Team. Skills, Arbeitsweise, Umgebung Das Agile Team Skills, Arbeitsweise, Umgebung Das Team handelt Das Team Verwandelt Anforderungen in potentially shippable product increment Der handelnde Agent Selbstorganisiert - was heisst das Gemeinsam

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

WordPress SEO von Yoast für Redakteure

WordPress SEO von Yoast für Redakteure SEITE AUTOR 1 von 7 Tim Meyer-Pfauder WordPress SEO von Yoast für Redakteure Inhaltsverzeichnis SEO für Redakteure... 2 a. WordPress SEO Box... 2 b. Generell... 3 c. Seiten-Analyse... 4 d. Erweitert...

Mehr

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013!

Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Agilität selbst erfahren. Agile Softwareentwicklung in der Praxis: Jetzt bewerben für das erste Agile Code Camp 2013! Sie wollen alles über agile Softwareentwicklung wissen? Wie können Sie agile Methoden

Mehr

Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer?

Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer? OOP 2012 Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer? André Köhler Softwareforen Leipzig GmbH Geschäftsführer 1 Das Bild kann nicht angezeigt werden. Dieser Computer

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

WENDIA ITSM EXPERT TALK

WENDIA ITSM EXPERT TALK WENDIA ITSM EXPERT TALK WENDIA ITSM WHITEPAPER IT SERVICE MANAGEMENT BASISWISSEN: IN EINFACHEN SCHRITTEN ZUR CMDB Wer, Wie, Was: Die CMDB als Herzstück eines funktionierenden IT Service Management Die

Mehr

abas evaluieren Leitfaden zur ERP-Auswahl in 7 Schritten

abas evaluieren Leitfaden zur ERP-Auswahl in 7 Schritten abas evaluieren Leitfaden zur ERP-Auswahl in 7 Schritten > Zuverlässig testen, welche die beste ERP-Lösung für Ihr Unternehmen ist! > Wie Sie Ihre Termine mit Anbietern am effizientesten gestalten können!

Mehr

Internet Briefing Agile SW-Entwicklung

Internet Briefing Agile SW-Entwicklung 1 www.namics.com Internet Briefing Agile SW-Entwicklung 6. Februar 2007 Peter Stevens, Principal Consultant Bern, Frankfurt, Hamburg, München, St. Gallen, Zug, Zürich Agenda 2 www.namics.com 3 www.namics.com

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/12 3.11.2011 Dana Wroblewski 1. Was heißt Agil 2. Scrum? Grundbegriffe 3. Wer benutzt Scrum 4. Vorteile & Nachteile von

Mehr

PRIMEING IHR PARTNER FÜR MSP IN ENGINEERING UND IT

PRIMEING IHR PARTNER FÜR MSP IN ENGINEERING UND IT PRIMEING IHR PARTNER FÜR MSP IN ENGINEERING UND IT Eckhardt Maier Geschäftsführer der primeing GmbH 02 Als Tochterunternehmen der ABLE GROUP, Deutschlands führenden Konzerns für Engineering- und IT-Dienstleistungen,

Mehr

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Testen mobiler Anwendungen

Testen mobiler Anwendungen Testen mobiler Anwendungen Wie können Sie sich den Herausforderungen stellen? www.softwareforen.de/mobile-testing Mobiles Testen wird zum kritischen Erfolgsfaktor 2007 begann mit der Markteinführung des

Mehr

IT-Development & Consulting

IT-Development & Consulting IT-Development & Consulting it-people it-solutions Wir sind seit 1988 führender IT-Dienstleister im Großraum München und unterstützen Sie in den Bereichen IT-Resourcing, IT-Consulting, IT-Development und

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Wieso Kollaboration? Wir haben doch schon ein Wiki! Über die Digitale Vernetzung in Unternehmen

Wieso Kollaboration? Wir haben doch schon ein Wiki! Über die Digitale Vernetzung in Unternehmen Wieso Kollaboration? Wir haben doch schon ein Wiki! Über die Digitale Vernetzung in Unternehmen Wiki ist eine schöne Insel. Aber einsam. {{Begriffsklärungshinweis}} Ein '''Wiki''' ([[Hawaiische Sprache

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

Mehr

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen

Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Qualitätssicherung leicht gemacht: Open Source Tools sinnvoll einsetzen und verzahnen Tutorium auf der KSFE 2015 in Hannover, 25.03.2015 Qualität kommt von Qual. Wissen aus Daten gewusst wie ist IT-Dienstleister

Mehr

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen.

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen. Philosophie & Tätigkeiten Wir sind ein Unternehmen, welches sich mit der Umsetzung kundenspezifischer Softwareprodukte und IT-Lösungen beschäftigt. Wir unterstützen unsere Kunde während des gesamten Projektprozesses,

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr