Umgang mit Fehlern in einer Agile-Umgebung

Größe: px
Ab Seite anzeigen:

Download "Umgang mit Fehlern in einer Agile-Umgebung"

Transkript

1 Umgang mit Fehlern in einer Agile-Umgebung Autor Ron Eringa

2 Umgang mit Fehlern in einer Agile-Umgebung Einführung Teams quälen sich häufig mit der Beantwortung der folgenden Frage: Wie handhaben wir unsere Fehler in einer agilen Umgebung? Sie beginnen Scrum als ein Framework zu benutzen, um ihre Software zu entwickeln. Bei der Implementierung stoßen sie jedoch auf Probleme beim Umgang mit Fehlern, die sie im Verlauf des Prozesses finden/verursachen. Injecting passion, Agility and quality into your organisation. Scrum ist ein Framework, welches nicht direkt vorgibt, wie mit Fehlern umgegangen werden soll. Die direkte Antwort wäre, Fehler als Product Backlog Items zu behandeln, die in den Product Backlog aufgenommen werden sollten. Wenn der Product Owner ihre Priorität als sehr hoch einstuft, dann werden sie vom Entwicklungsteam beim nächsten Sprint mit berücksichtigt. Die Umsetzung ist jedoch etwas komplizierter und sollte deshalb etwas ausführlicher erklärt werden. 1. Was ist ein Fehler? Wikipedia (English version): Software bugs (oder -fehler) sind Abweichungen, Schwachstellen, Fehlfunktionen oder Störungen in einem Computerprogramm oder -system, die ein falsches oder unerwartetes Ergebnis oder ein unbeabsichtigtes Verhalten zeigen. Die meisten Bugs entstehen aus Fehlern und Abweichungen im Quellcode oder in der Architektur der Software oder in von solchen Programmen genutzten Frameworks und Betriebssystemen; einige von ihnen werden von Compilern verursacht, die fehlerhaften Code produzieren. Für den Begriff Fehler gibt es viele Synonyme und Erklärungen. Begriffe wie Bugs, Vorfälle, Störungen werden alle oftmals sogar im selben Kontext verwendet. Die Bedeutung dieser Begriffe RON ERINGA AGILE COACH Nach meinem Studium an der Fontys- Universität in Eindhoven arbeitete ich zehn Jahre lang als Software-Entwickler und Designer. Obwohl ich immer das Technische der Arbeit genossen habe, ist meine besondere Leidenschaft Menschen und Unternehmen dabei zu helfen, gemeinsam hohe Qualität zu erbringen. Für mich liegt der Reiz von Agile in der Zusammenarbeit und der Energie, die freigesetzt wird, wenn die Mitarbeiter sich auf ein gemeinsames Ziel konzentrieren. Ich selbst habe sieben Jahre Erfahrung mit Agile-Practices wie Scrum, Lean, Kanban, TDD und Continuous Integration. In dieser Zeit habe ich als Coach, Trainer, Scrum Master, Product Owner und Agile Project Manager gearbeitet. Darüber hinaus halte ich regelmäßig Vorträge bei Agile-Konferenzen oder Seminaren. 2

3 und ihre Behandlung hinsichtlich ihrer Priorisierung und ihrer Stelle im Product Backlog ist nicht immer klar. Kurz zusammengefasst kann ein Fehler als unerwünschtes Verhalten einer Software beschrieben werden. 2. Warum und wie können agile Methoden zur Verbesserung meines Umgangs mit Fehlern beitragen? Es ist unvermeidbar, dass jede Softwareanwendung irgendwann Fehler aufweist. Unrealistische Teams ignorieren diese Situation und werden dann eines Besseren belehrt. Realistische Teams akzeptieren diese Tatsache und konzentrieren sich auf die Frage, wann der Fehler entstand, wie lange es dauerte, bis sie ihn entdeckten und, noch wichtiger, wann sie ihn gelöst haben. Agile Methoden zielen darauf ab, Fehler so schnell wie möglich nach ihrem Auftreten zu beseitigen. Techniken wie Test Driven Development (TDD), Behavior Driven Development (BDD), Continuous Integration und Pair Programming sind alle auf das Auffinden von Fehlern in einem frühen Stadium des Entwicklungszyklus ausgerichtet. Wenn man die Abschnitte nachverfolgt, in denen ein Fehler gefunden und gelöst wurde, kann man Übersichten erstellen (siehe Grafik unten), die die Auswirkungen der Anwendung agiler Techniken aufzeigen. Kombiniert mit der Grafik der relativen Kosten wird sofort klar, dass ein agiles Vorgehen im Projekt viele Vorteile bringt. Diese Grafiken zeigen, dass ein agiles Vorgehen dabei hilft, Kosten für spät gefundene Fehler zu reduzieren und die Qualität von dem Zeitpunkt an zu steigern, in dem ein neues Stück Software geschrieben wird. Viele Studien belegen, dass die Behebung eines Mangels im Produktionsstatus viel teurer ist (bezogen auf Kosten und Mühen) als wenn sie in einem frühen Stadium des Projekts gefunden werden (NIST study). Die gleichen Studien stellen fest, dass Softwarebugs oder Fehler die amerikanische Wirtschaft schätzungsweise 59 Millionen US-Dollar pro Jahr oder ungefähr 0,6 Prozent des Bruttoinlandsprodukts kosten.eine andere Studie des IBM Systems Sciences Institure legt dar, dass die Kosten für das Auffinden und die Behebung von Fehlern im Wartungsstatus 100mal höher ist als im Entwicklungsstatus. Source: IBM Systems Sciences Institute 3

4 3. Was ist ein Product Backlog Item? Scrum Guide: Im Product Backlog werden alle Features, Funktionen, Anforderungen, Erweiterungen und Fehlerkorrekturen erfasst, um die erforderlichen Veränderungen in zukünftigen Versionen festzustellen. Product Backlog Items bestehen aus den Attributen Beschreibung, Auftrag, Auftragsschätzung und Wert. Themes, Epics, User Stories und Fehler In einem Product Backlog Item werden alle erforderlichen Arbeiten für die Erstellung eines inkrementellen Updates Ihres Produkts definiert. Der Arbeitsaufwand für ein Product Backlog Item kann einige Stunden, aber auch Monate betragen. Ein Product Backlog enthält typischerweise an der Spitze kleine Items mit hoher Priorität und große Aufgaben mit niedriger Priorität ganz unten. Scrum schreibt nicht vor, wie ein Product Backlog Item aussehen sollte, da wir keine Arbeitsweise vorgeben wollen. Aber es gibt einige gute Beispiele im extreme Programming (XP), die die Definition eines Product Backlog Items verdeutlichen. Während Scrum nur über Product Backlog Items spricht, hat die Agile Community (www. mountaingoatsoftware.com/blog/stories-epics-and-themes) eher praktische Anwendungen für ein Product Backlog Item: User Story: User Stories beschreiben eine neue Funktionalität aus der Sicht der Person, die die neue Funktionalität haben möchte. Eine neue User Story sollte vom Umfang her klein genug sein, damit sie in einen Sprint passt. Epic: Ein Epic ist eine große User Story. Diese Bezeichnung macht deutlich, dass die User Story zu groß/komplex ist, um im nächsten Sprint umgesetzt zu werden. Sie muss in kleinere User Stories aufgeteilt werden. Theme: Ein Theme ist eine Gruppe von User Stories. Manchmal ist es hilfreich, über Gruppen von User Stories zu sprechen, zum Beispiel, wenn wir mit Kunden über den Inhalt eines Version reden. Ein Team kann nicht nur Themes, Epics und User Stories (typische Begriffe aus dem XP), sondern auch Fehler in ihren Product Backlog aufnehmen. Das heißt, dass Fehler nur eine andere Anwendung eines Product Backlog Items sein können und bezogen auf Planung, Aufwandsabschätzung und Priorität genauso behandelt werden wie ein Product Backlog Item. 4. Fehler, User Story oder Task? Im Allgemeinen sehen wir vier verschiedene Wege, die zu neuen Aufgaben für das Team führen: 1. Neues Feature Dies ist der üblichste Weg, dem Product Backlog neue Aufgaben hinzuzufügen. Einer der Stakeholder hat den Wunsch nach einer neuen Funktionalität und der Product Owner hat dem Product Backlog ein neues Product Backlog Item hinzugefügt. Oftmals beginnt dies mit einem Epic, das, sofern erforderlich, in kleinere User Stories aufgeteilt wird. Scrum Teams nutzen dafür die Backlog Refinement Meetings. 2. Veränderungen der Funktionalität Die User Story wurde in einem zurückliegenden Sprint von den Stakeholdern und/oder vom Product Owner akzeptiert, aber aus dem einen oder anderen Grund haben sie ihre Meinung geändert. Da es der Stakeholder ist, der seine Meinung ändert (das könnte während des Sprint Reviews erfolgen, wenn der Stakeholder neue Einsichten gewinnt), kann eine solche Veränderung in einer User Story formuliert werden, die dann wiederum im Product Backlog landet. 3. Problem bei der Entwicklung Ein Entwickler arbeitet an einer User Story, aber während der Implementierung der Story verursacht er ein Problem. Im Idealfall wird er das Problem sofort beheben, bevor er die User Story an den Rest des Teams liefert. Mitglieder eines Teams, das Continuous Integration nutzt, liefern ihre Änderungen typischerweise mehrmals am Tag aus. Daher kann es vorkommen, dass nicht der Entwickler, sondern ein anderes Teammitglied den Fehler nach der Lieferung bemerkt. In diesem Fall ist es sinnvoll, das Problem klar zu veranschaulichen, um sicherzustellen, dass es gelöst wird (es wird normalerweise als Task auf dem Scrum Board eingetragen und fällt unter die Done -Kriterien für diese Story). Anders ausgedrückt kann die User Story in diesem Sprint nur dann als Done gekennzeichnet werden (und daher am Ende des Sprints an den Kunden ausgeliefert werden), sobald alle gefundenen Probleme gelöst wurden. Ein Team sollte niemals gezwungen werden, User Stories mit noch offenen Entwicklungsproblemen zu beenden. 4

5 4. Fehler Viele Scrum Teams nutzen den Begriff Fehler für ein Entwicklungsproblem, das nach der Auslieferung eines Arbeitspakets (Product Increment) am Ende des Sprints gefunden wird. Das Team hat am Ende des Sprints augenscheinlich ein Arbeitspaket ausgeliefert, ohne die Abweichung aus welchem Grund auch immer zu bemerken. Diese Arten von Fehlern sind Ausdruck von technischem Versagen und weisen darauf hin, dass das Entwicklungsteam seine Fähigkeiten zur Auslieferung von Arbeitspaketen in höherer Qualität verbessern muss. Dies ist typischerweise ein Hinweis darauf, dass die vom Team verwendete Definition of Done verbessert werden muss. Da nicht immer klar ist, welche User Story die Abweichung genau verursacht hat, ist es sinnvoll, dem Product Backlog ein neues Product Backlog Item hinzuzufügen. Das könnte eine neue User Story sein, aber viele Agile ALM Tools verfügen über die Option, Fehler im Product Backlog zu verwalten. Nachdem der Fehler dem Product Backlog hinzugefügt wurde, muss er mit dem Product Owner und dem Entwicklungsteam diskutiert werden. Entwicklungsteam und Product Owner sollten gemeinsam die Priorität des Fehlers festlegen: Fehler mit niedriger Priorität können auf einfache Art und Weise gehandhabt werden. Sie können während der Backlog Refinement Meetings diskutiert und wie jede andere User Story im Backlog behandelt werden. Fehler mit hoher Priorität sollten so schnell wie möglich behoben werden. Das sind typischerweise die Fehler, die das Entwicklungsteam oder (im schlimmsten Fall) die Stakeholder bei ihren laufenden Aktivitäten behindern. Im Idealfall ist es ein Leichtes, das Problem zu beheben, ohne dass dies den Inhalt des Sprints beeinflusst. In vielen Fällen muss viel Zeit in die Problemlösung investiert werden. Sobald sich herausstellt, dass der Fehler Einfluss auf den Inhalt des Sprints hat, sollte das Entwicklungsteam den Inhalt des Sprints erneut mit dem Product Owner besprechen. 5. Was ist der Unterschied zwischen einem Fehler und einer User Story? Der größte Unterschied zwischen einem Fehler und einer User Story ist, dass es sich bei Fehlern nicht um neue Funktionalitäten handelt. In User Stories geht es üblicherweise um neue, vom Kunden gewünschte Bestandteile (oder gleiche Bestandteile auf eine andere Art). Ein Fehler ist das Ergebnis eines Versehens, das in der Vergangenheit verursacht, aber aus irgendeinem Grund nicht entdeckt wurde. Fehler sind Ausdruck von technischem Versagen und können direkt vom Kunden festgestellt werden. Das heißt, sie haben großen Einfluss auf die Priorität (oftmals bedeutet dies, dass sie umgehend behoben werden müssen). Teams fällt die Aufwandseinschätzung für User Stories im Allgemeinen leichter als die für die Fehlerbehebung. Das hat verschiedene Gründe: Bevor ein Fehler behoben werden kann, müssen wir zunächst die Fehlerquelle finden. Die Fehlerquelle eines Problems zu finden, kann eine sehr zeitraubende Angelegenheit sein. Daher ist es für Teams häufig schwieriger, den Aufwand eines Fehlers verglichen mit dem einer User Story abzuschätzen. Fehler können von einem anderen Team/einer anderen Person verursacht werden als der, die das Problem analysiert (die typische Legacy-Problematik). Das bedeutet, dass ein Fehler häufig von einer Person/einem Team an eine andere Person oder ein anderes Team 5

6 weiter gereicht wird, bis es von der richtigen Person/dem richtigen Team gelöst werden kann. Dieses Verhalten wird häufig dann beobachtet, wenn Scrum Teams nicht von Anfang bis Ende verantwortlich sind, auch wenn wir es von ihnen erwarten (zum Beispiel ist ein Scrum Team verantwortlich für den Prototypen, ein anderes für die Erstellung des Produktes und wieder ein anderes für die Fehlerbehebung). Das ist auch der Grund, aus dem wir den Teams immer die Verantwortung über den gesamten Lebenszyklus der Softwareanwendung übertragen sollten. Wenn der Zeitraum zwischen der Verursachung und der Lösung eines Problems sehr lang ist, ist das Risiko hoch, dass das Wissen über die Ursache fehlt. Das könnte verschiedene Ursachen haben, wie unvollständige Testfälle, Stories, die sich über mehrere Sprints hinziehen, nicht beendete User Stories (unvollständige Definition of Done ) oder über mehrere Teams hin- und her gereichte Tätigkeiten. Es liegt in der Natur eines Fehlers, dass wir andere Informationen benötigen als wir normalerweise für eine User Story erwarten. Aus diesem Grund haben Agile Backlog Management Tools oftmals verschiedene Templates für User Stories und Fehler. Informationen, die wir typischerweise für Fehler benötigen: Wer hat den Fehler gemeldet? Wer hat den Fehler gefunden? Wie sieht das beobachtete unerwünschte Verhalten aus? Welches Szenario war für das Auftreten des Fehlers verantwortlich? Gibt es Logdateien, die Hintergrundinformationen liefern können? Ist das Szenario reproduzierbar? Welche Auswirkungen hat der Fehler und wie schwerwiegend ist er? In welcher Softwareversion/in welchem Sprint wurde der Fehler entdeckt? Kurz zusammengefasst: Das Fehlermanagement wird oftmals als schwieriger als das Management von User Stories wahrgenommen, da Fehler dazu neigen, eine höhere Priorität zu haben und eine Aufwandsabschätzung schwieriger ist. 6. Was passiert, wenn Fehler mit hoher Priorität unserer Sprintziel stören? Unser Team muss während eines Sprints viele Fehler mit hoher Priorität bearbeiten, das erschwert unsere Vorhersagbarkeit. Was können wir dagegen tun? Ich habe diese Frage schon mehrfach gehört, daher möchte ich etwas näher darauf eingehen. In solch einer Situation sollte sich das Team einige Fragen stellen. Fehler priorisieren Aus welchem Grund tritt bei uns die Menge an Fehlern auf? In der Vergangenheit ist scheinbar etwas vorgefallen, was heute diese Fehlermenge verursacht. Viele Teams entwickeln stets neue Funktionalitäten, ohne dieses Problem zu lösen. Wenn während Ihres Sprints zu viele Fehler hochkommen, müssen Sie vermutlich Korrekturen zur Verbesserung der Qualität Ihrer Software vornehmen. Haben alle diese störenden Fehler wirklich eine so hohe Priorität oder können sie bis zum nächsten Sprint warten? Wenn Sie Ihre Fehler in den Product Backlog einfügen, sie im Product Backlog diskutieren und auf dieselbe Weise wie User Stories priorisieren, dann erhält das Problem die Aufmerksamkeit, die es benötigt. Häufig fordern die Teams den Product Owner nicht auf, den Product Backlog als Mechanismus zur Planung der Fehler zu verwenden. Anstatt sie in den Backlog einzufügen, behandeln sie sie während des Sprints und gefährden damit ihre Sprintziele. Aber was ist, wenn wir immer noch Fehler mit hoher Priorität haben, die sofort behoben werden müssen? Das Team muss während eines Sprints immer für ein bestimmtes Gleichgewicht sorgen. Es treten immer wieder unerwartete Überraschungen auf, die das Sprintziel gefährden. Wenn Ihr Team weiß, dass es eine bestimmte Anzahl dieser Fehler mit hoher Priorität bearbeiten kann, ohne das Ziel des Sprints zu gefährden, dann besteht kein wirkliches Problem, solange Sie sicherstellen, dass das Team die Kontrolle über diese Störungen behält. Eine gute Möglichkeit der Sicherstellung ist die Darstellung aller Störungen in Spaltenform auf dem Scrum Board. Wenn Sie die Kanban-Prinzipien für die Begrenzung der Menge an Störungen einsetzen, dann können Sie sicherstellen, dass die Geschwindigkeit des Teams davon nicht beeinflusst wird. Und wenn die Menge an Fehlern mit einer hohen Priorität in einem Sprint steigt, könnte das ein erstes Anzeichen für ein potentielles Problem sein. Das bedeutet, dass Sie Ihre Fehler erneut über Ihren Product Backlog planen sollten. Das Team sollte außerdem eine Grenze für die Menge der akzeptablen Fehler mit hoher Priorität in einem Sprint definieren. 6

7 Fehler veranschaulichen Wenn Teams eine zu hohe technische Schuld entwickeln, könnten sie an einen Punkt gelangen, an dem sie mehr Zeit in einem Sprint darauf verwenden, aufgrund dieses technischen Verschuldens eintretende Fehler zu beheben, anstatt neue Funktionalitäten zu entwickeln. Das ist typischerweise der Zeitpunkt, an dem drastische Maßnahmen ergriffen werden müssen, um wieder zurück in die Spur zu kommen. Solch einem Team könnte es auch helfen, die sich entwickelnde technische Schwäche zu visualisieren, um die Größe des zu lösenden Problems zu erkennen. Beispiel Im nachfolgenden Beispiel finden Sie eine Grafik mit einer Darstellung der Fehlermenge, die wir in einem Team über einen Zeitraum von einem Jahr hatten. Nach diesen Veränderungen haben sie ein weiteres Jahr lang die Fehlermenge überwacht und so sah dieselbe Grafik dann aus: Was Sie deutlich sehen können, ist: Sie haben nur einmal die Grenze überschritten und waren innerhalb eines Sprints (2 Wochen) in der Lage, die Probleme zu bearbeiten. Aufgrund von ständiger Überprüfung und Anpassung, hatten Sie nie wieder diese hohe Menge an Fehlern. Schlussfolgerungen Was Sie deutlich erkennen können ist: Dass das Team mit 50 Fehlern begonnen hat, die kontinuierlich gestiegen sind (Entwicklung von technischer Schuld). Nach fast einem halben Jahr wurden die technische Schuld zu groß und dem Team wurde klar, dass es die Situation klären musste Wir brauchten fast 2 Monate, um die Situation unter Kontrolle zu bekommen. Wir benötigten den Rest des Jahres, um die Schwächen wieder auf ein Minimum zu reduzieren. Sobald das Team seine Qualität und die technisch Schuld wieder unter Kontrolle hatte, haben die Teammitglieder sich hinterfragt und ihre Arbeitsweise angepasst. Das Team unternahm Folgendes: Achten Sie darauf, dass Ihr Team keine technisch Schuld ansammelt, veranschaulichen Sie diese und handeln Sie entsprechend. Haben Sie bereits technische Schuld angesammelt, dann erstellen Sie einen Plan, um dieses Problem zu beheben, denn Ihr Team wird dadurch langsamer. Geben Sie Ihre Fehler in den Product Backlog ein und behandeln Sie diese genauso wie Ihre User Stories. Achten Sie bei hochpriorisierten Fehlern darauf, dass sie Ihr Sprintziel nicht gefährden. Sollte das bereits der Fall sein, dann reagieren Sie darauf und diskutieren Sie dies mit ihrem Product Owner. Achten Sie darauf, dass das Managementtool für Ihren Product Backlog zwischen Fehlern und User Stories unterscheiden kann, um solche Grafiken erstellen zu können. Eine Hürde von 40 Fehlern wurde eingeführt, die nicht überschritten werden durfte. Sobald sie mehr als 40 Fehler registrierten, sprachen sie mit ihrem Product Owner und planten im nächsten Sprint mit mehr Fehlern und weniger User Stories. Sie hatten mehr und bessere automatisierte Tests geschrieben und somit ihre Definition of Done verbessert. Sie hatten eine weitere Person mit Testfachwissen und Ressourcen in ihr Team aufgenommen, sodass sich das Team selbst vermehrt auf Qualität konzentrieren konnte. 7

8 7. Welche Auswirkungen haben Fehler auf die Geschwindigkeit des Teams? Ihre Geschwindigkeit sollte von der Fehlermenge, die Ihr Team produziert, nicht betroffen werden, sofern die Fehler in den Product Backlog eingegeben werden. Teams, die neben dem Product Backlog noch gesonderte Fehlerlisten führen, denken oftmals, dass ihre Geschwindigkeit darunter leidet. Was hier tatsächlich passiert, ist dass die Geschwindigkeit des Teams gleich bleibt, aber die Fähigkeit zur Entwicklung neuer Features von der zu lösenden Menge an Fehlern berührt wird. Eine stabile Geschwindigkeit ist in einer solchen Situation ein hilfreiches Maß, da man für jeden Sprint das Gleichgewicht zwischen Ihren Fehlern und anderen Product Backlog Items vorhersagen kann. Eine andere Metrik, das Ihrem Entwicklungsteam und Product Owner in einer solchen Situation helfen könnte, ist die Visualisierung der aufgewendeten Zeit für neue Features, Funktionsänderungen, Entwicklungsprobleme und Fehler. Die Grafik zeigt die Geschwindigkeit eines neuen Teams über einige Sprints: Die Geschwindigkeit stabilisierte sich nach fünf oder sechs Sprints. Die Fähigkeit des Teams, in jedem Sprint an neuen Funktionalitäten zu arbeiten, ist sehr stabil. Trotzdem arbeitet das Team in jedem Sprint mehr und mehr an Fehlern. Obwohl die Geschwindigkeit sich stabilisierte, könnte dies ein Anzeichen für den Aufbau von technischschuld sein, da sich das Gleichgewicht zwischen Fehlern und den anderen Tätigkeiten verschiebt. 8. Wir haben bereits ein Trackingsystem für Fehler und möchten ein Product Backlog aufsetzen. Was jetzt? Viele Unternehmen nutzen bereits ein Fehlertrackingsystem, wenn Sie anfangen, mit Scrum zu arbeiten. Häufig wird für den Product Backlog ein anderes Tool verwendet, da das Fehlertrackingsystem nur für Fehler ausgelegt ist. Trotzdem, wenn man sich die Art der Tätigkeiten bei Fehlern und für User Stories ansieht, so sollten beide zum Product Backlog hinzugefügt werden und beide sollten Thema in den Backlog Refinement Meetings sein. Die Nutzung verschiedener Systeme ist aus naheliegenden Gründen sinnvoll, aber der größte Fehler den viele Teams machen ist, dass sie ein anderes Vorgehen bei der Fehlerpriorisierung und -planung haben. Sie nutzen also Scrum für Neue Features und Änderungen in der Funktionalität, haben daneben allerdings noch viele andere Meetings, um die Fehler abzuschätzen, zu planen und zu priorisieren. Der Trick hierbei ist, eine einzige Herangehensweise für Fehler und für User Stories zu verwenden (die Herangehensweise bei Scrum ist die Durchführung von Backlog Refinements), sodass das Team sich konzentrieren kann und sich nicht mit zwei verschiedenen Prozessen befassen muss, trotzdem verschiedene Tools verwenden kann, wenn dies erforderlich ist. Die Nutzung von zwei Tools für das Management eines Backlogs mit User Stories und Fehlern hat den Nachteil, dass diese schwieriger zu warten sind und diese Vorgehensweise fehleranfälliger ist. Eine andere Lösung könnte sein, das alte Fehlertrackingsystem für das Management des kompletten Backlogs zu nutzen. Das könnte eine Option sein, wenn das alte Fehlertrackingsystem das Team bei seinen täglichen Scrum-Aktivitäten unterstützt. War der Artikel für Sie interessant und möchten Sie gern mehr über das Thema erfahren? Senden Sie eine an: 8

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen Wer bin ich Kurse und Vorträge mit Jeff Sutherland und Ken Schwaber Verschiedene Kurse der Scrum.org Professional

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

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

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

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

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

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

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration Markus Stollenwerk, Noser Engineering AG Agile Softwareentwicklung Crash-Kurs Markus Stollenwerk, 27.9.2013

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

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

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

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

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

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Silvio Simone, Bison Group Susanne Mühlbauer, HOOD GmbH Scrum Day 2012 Bison Schweiz AG Surentalstrasse 10 CH-6210 Sursee www.bison-group.com HOOD GmbH

Mehr

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest?

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest? Scrum Rollen Product Owner (PO) Der PO ist klar definiert Der PO übersetzt Anforderungen in klare Backlog Items Der PO ist ermächtigt, Backlog Items zu priorisieren Der PO verfügt über das Fachwissen,

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

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

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

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Einfach losgesprintet: Ein Praxisbericht. Henning Pautsch, Stefan Kirch. 2. Oktober 2014. Einfach losgesprintet:

Einfach losgesprintet: Ein Praxisbericht. Henning Pautsch, Stefan Kirch. 2. Oktober 2014. Einfach losgesprintet: Einfach losgesprintet: Sebastian Mary / flickr.com Ein Praxisbericht Henning Pautsch, Stefan Kirch Einfach losgesprintet: Henning Pautsch Ein Praxisbericht 2. Oktober 2014 Agil ist derzeit in aller Munde.

Mehr

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ein modellbasierter Prozess für die Anforderungsanalyse im Vorfeld agiler Produktentwicklung

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

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Checkliste für Scrum-Meetings

Checkliste für Scrum-Meetings Checkliste für Scrum-Meetings Gesamtdarstellung 2 Produktvision teilen 3 Estimating 4 Planning 1 - Das WAS 5 Planning 2 - Das WIE 6 Daily Scrum 7 Das Review 8 Die Retrospektive 9 Artefakte 10 GOagile!

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

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

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

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

READY-STEADY-DONE! Der Product Owner are you READY for agile?! READY-STEADY-DONE! Der Product Owner are you READY for agile?! Susanne Mühlbauer HOOD GmbH Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Neue Ideen sind

Mehr

Train. Scrum Kompakt. Angelika Drach, Christoph Mathis

Train. Scrum Kompakt. Angelika Drach, Christoph Mathis Train Scrum Kompakt Angelika Drach, Christoph Mathis !! Inhalt! Inhalt' Inhalt!!1! 1! Agile!Grundlagen!..!3! 1.1! Das!Agile!Manifest!..!3! 1.2! Softwareentwicklung!ist!empirisch!.!4! 2! ScrumGKonzepte!!6!

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Agile Software Development with Scrum

Agile Software Development with Scrum Agile Software Development with Scrum (Schwaber/Beedle, Prentice Hall, 2002) Ein Lesebericht von Robert Hagedorn und Dr. Juho Mäkiö Was ist eigentlich Scrum und wie kann es erfolgreich in der Systementwicklung

Mehr

Agile Softwareentwicklung

Agile Softwareentwicklung Agile Softwareentwicklung Werte, Konzepte und Methoden von Wolf-Gideon Bleek, Henning Wolf 2., aktualisierte und erweiterte Auflage Agile Softwareentwicklung Bleek / Wolf schnell und portofrei erhältlich

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

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik

Scrum Einführung. SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik SWP: Spieleprogrammierung Fachbereich Mathematik und Informatik Scrum Einführung Do, Hoang Viet(do@mi.fu-berlin.de) Freie Universität Berlin, SoSe 2013 Rollen Product Owner Definiert die Ziele Product

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

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680

Compact Scrum Guide. Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Compact Scrum Guide Inhalt 1. Was ist Scrum und wofür wird es

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Leuchtfeuer Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland Gliederung Über die Allianz Wie führen wir Scrum ein? Wie haben wir begonnen? Techniken und Praktiken Change-Management

Mehr

Iterativ. Inkrementell

Iterativ. Inkrementell Iterativ Inkrementell Build Release Test Qualität Architektur & Documentation Distributed Version Control Continuous Integration TDD Design Agile Architektur Dependency Feature Branches Mocks

Mehr

Scrum - Von Schweinchen und Hühnchen

Scrum - Von Schweinchen und Hühnchen 4. November 2009 - Actinet IT-Services 1986 erster Computer 1990 Erstes Programm (Kleinster Gemeinsamer Teiler - Basic) 2000 Informatik Studium + Firmengründung 2007 Umorientierung - Software Development

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

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Susanne Muehlbauer 29. November 2011

Susanne Muehlbauer 29. November 2011 Machen Sie noch Modellierung Anforderungsmanagement oder sind Sie schon READY for SCRUM? Susanne Muehlbauer 29. Wer ist HOOD unser Geschäftsfeld Der Einsatz von Requirements Engineering und kontinuierliche

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

Mehr

Agile Vorgehensweisen im IT-Projekt- und Prozess-Management (Chancen und Offene Fragen)

Agile Vorgehensweisen im IT-Projekt- und Prozess-Management (Chancen und Offene Fragen) Prof. Dr. Ayelt Komus Struktur Technologie Mensch Agile Vorgehensweisen im IT-Projekt- und Prozess-Management (Chancen und Offene Fragen) Hagen, 25.11.2011 Prof. Dr. Ayelt Komus Certified Scrum Master

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

It s all about shipping software!

It s all about shipping software! 1 Shipping Software Raiffeisen Bausparkasse V-ARC, 21.12.2011 Gerhard H. Leonhartsberger It s all about shipping software! Seite 2 2 How fast do you ship quality software? Seite 3 Software Entwicklung

Mehr

Extreme Programming: Überblick

Extreme Programming: Überblick Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2 Prinzipien

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

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

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

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

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Einführung in Scrum Agiles Projektmanagement Martin Krüger 27.04.2011 Entwicklung von Workflowanwendungen Warum Agiles Projektmanagement? Scrum Empfehlungen Das Seminar Planbarkeit Warum Agiles Projektmanagement?

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

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Navigator Scrum 1.0. IT-Projektmanagement bei Symposionline

Navigator Scrum 1.0. IT-Projektmanagement bei Symposionline Navigator Scrum 1.0 IT-Projektmanagement bei Symposionline Was ist scrum? Scrum (engl. für Gedränge) ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln

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

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

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Priorisierung Im Product Backlog

Priorisierung Im Product Backlog Priorisierung Im Product Backlog Praktische Tipps zur sofortigen Anwendung Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Priorisierung

Mehr

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 Sabotage in Scrum dem Prozess erfolglos ins Knie schiessen Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007 1 Überblick Sabotage? Wer kann sabotieren? Was kann sabotiert werden? Wieviel

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

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

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

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

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Innovative Prozessansätze im regulativen Umfeld Unrestricted Siemens AG 2014. All rights reserved

Innovative Prozessansätze im regulativen Umfeld Unrestricted Siemens AG 2014. All rights reserved VMEA 2014 Innovative Prozessansätze im regulativen Umfeld Agenda Regulatives Umfeld Einführung in Kanban Kombination von Scrum und Kanban im regulativen Umfeld Zusammenfassung Page 2 Regulatives Umfeld

Mehr

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung?

Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? @LeanAgileScrum #LASZH LAS Conference 2012 Sponsoren Wie viel Geschäftsprozess verträgt agile Softwareentwicklung? Marcus Winteroll 16:15 Auditorium Organisationsteam Patrick Baumgartner (Swiftmind GmbH)

Mehr

Produktmanagement vom Kundenticket zum Release

Produktmanagement vom Kundenticket zum Release Produktmanagement vom Kundenticket zum Erfahrungen aus vier Jahren Entwicklung nach SCRUM, Geschäftsführer, Scrum Master 7 von 58 9 von 58 Bekannte Kunden 10 von 58 17 von 58 20 von 58 Ziele der Einführung

Mehr

Kanban und Scrum mit JIRA und dem neuen Greenhopper Plugin

Kanban und Scrum mit JIRA und dem neuen Greenhopper Plugin Kanban und Scrum mit JIRA und dem neuen Greenhopper Plugin Atlassian User Group München, 17. Oktober 2012 Gerhard Müller, Leo von Klenze, TNG Technology Consulting GmbH Source: Henrik Kniberg, http://www.crisp.se/henrik.kniberg/presentations/scrum-intro-brief-henrik-kniberg.pdf

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

Mehr

ISBN 978-3-8273-3232-5 (Print); 978-3-86324-685-3 (PDF); 978-3-86324-250-3 (epub)

ISBN 978-3-8273-3232-5 (Print); 978-3-86324-685-3 (PDF); 978-3-86324-250-3 (epub) Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage Wirdemann Scrum mit User Stories vbleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos

Mehr

Stoppt Scrum! conplement AG 2011. All Rights Reserved. Freitag, 1. Juli 2011

Stoppt Scrum! conplement AG 2011. All Rights Reserved. Freitag, 1. Juli 2011 Stoppt Scrum! 2 conplement AG 2011. All Rights Reserved. Anleitung zum Ruinieren eines Scrum-Teams 28.06.2011 Udo Wiegärtner Bereichsleiter Software Engineering Scrum Master, Scrum Developer Trainer conplement

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

Seminar Softwareentwicklung in der Wissenschaft

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

Mehr

#LASZH @LeanAgileScrum @chrishassa. Story Maps. Liefern was wirklich zählt. Christian Hassa. 10:30 Conference Room 2

#LASZH @LeanAgileScrum @chrishassa. Story Maps. Liefern was wirklich zählt. Christian Hassa. 10:30 Conference Room 2 #LASZH @LeanAgileScrum @chrishassa Story Maps Liefern was wirklich zählt Christian Hassa 10:30 Conference Room 2 Lean, Agile & Scrum Konferenz 2013 Warum agile Software Entwicklung? Product Backlog Satisfy

Mehr

Karlsruher Entwicklertag 2013. Coding Dojos im Unternehmen

Karlsruher Entwicklertag 2013. Coding Dojos im Unternehmen Karlsruher Entwicklertag 2013 Coding Dojos im Unternehmen...und es lohnt sich doch 05.06.2013 1 Agenda Vorstellung Vorgeschichte Basics Beginn Clean Code & TDD Fazit 2 Ralf Schoch Zur Person Freiberuflicher

Mehr

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

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

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen? Andrea Grass & Dr. Marcus Winteroll oose GmbH Geschäftsprozessmanagement und Agilität geht das zusammen? Agenda I. Wozu eigentlich BPM? II. Vorgehen und Rollen im abpm III. Methoden und Techniken IV. Resümee

Mehr

Teamaufstellung - Zwischen Dream und Nightmare

Teamaufstellung - Zwischen Dream und Nightmare Teamaufstellung - Zwischen Dream und Nightmare Vom Versuch aus einem Referat ein Scrum-Team zu machen Michael Schäfer Unterföhring, September 2011 Inhalt 1 2 3 4 5 6 Warum Scrum? So haben wir begonnen

Mehr

DIE HERAUSFORDERUNG. Warum es doch auf die Grösse ankommt

DIE HERAUSFORDERUNG. Warum es doch auf die Grösse ankommt DIE HERAUSFORDERUNG Seite 2 - Sep 2014 - Warum es doch auf die Grösse ankommt IHRE SOFTWARE IST ETWAS UMFANGREICHER Seite 3 - Sep 2014 - Warum es doch auf die Grösse ankommt ES GIBT EIN PAAR ABHÄNGIGKEITEN

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Scrum-Einführung bei der Projektron GmbH

Scrum-Einführung bei der Projektron GmbH Business Coordination Software Kosten sparen. Termine einhalten. Ziele erreichen. Scrum-Einführung bei der Projektron GmbH Matthias Fleschütz Projektron GmbH Jens Wilke headissue GmbH Projektron GmbH Softwarehersteller

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

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

Melanie König 5Minds IT- Solu5ons GmbH & Co. KG. Agile Aufwandsschätzungen

Melanie König 5Minds IT- Solu5ons GmbH & Co. KG. Agile Aufwandsschätzungen Melanie König 5Minds IT- Solu5ons GmbH & Co. KG Agile Aufwandsschätzungen Inhalt (1) Warum sind vernün6ige Aufwandsschätzungen so wich5g? Wie unterscheiden sich agile von klassischen Aufwandsschätzungen?

Mehr

FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL?

FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL? FALLSTRICKE IM AGILEN ANFORDERUNGSMANAGEMENT ODER WIE BEKOMME ICH MIT USER STORIES VON DEN GEEKS WAS ICH WILL? Steffen Thols - REConf 2012 07.03.2012 2 ÜBER MICH Name : Steffen Thols Berufserfahrung: Einige

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr