agile Sybit Ausgabe 12 Was macht ein agiler Softwarearchitekt so den ganzen Tag Urs Enzler To ASSUME makes an A** out of U and ME Thomas van Aken

Größe: px
Ab Seite anzeigen:

Download "agile Sybit Ausgabe 12 Was macht ein agiler Softwarearchitekt so den ganzen Tag Urs Enzler To ASSUME makes an A** out of U and ME Thomas van Aken"

Transkript

1 Sybit agile Ausgabe 12 Agile Softwareentwicklung im Fokus Was macht ein agiler Softwarearchitekt so den ganzen Tag Urs Enzler Seite 3 To ASSUME makes an A** out of U and ME Thomas van Aken Seite 7 Hypothetische Retrospektiven Marc Löffler Seite 10 Wie Hermann den Kunden glücklich machte Sven Schnee Seite 13

2 Spannungsbogen Die zwölfte Ausgabe unseres Magazins spannt einen weiten Bogen, an dem hoffentlich nicht nur Naturliebhaber ihre Freude haben. Zunächst betrachtet Urs Enzler die Rolle des Softwarearchitekten in agilen Projekten und gibt seine Erfahrungen und Empfehlungen weiter. Thomas van Aken nimmt sich den Annahmen, die auf allen Ebenen der Projekte getroffen werden, an und zeigt, wie man auf einen gemeinsamen Nenner kommen kann. Machen Sie noch eine Retro nach Ihren Sprints? Marc Löffler zeigt, wie die Retrospektiven wieder gewinnbringend für das Team und das Projekt eingesetzt werden können. Schließlich beschreibt Sven Schnee, wie eine agile Organisation aufgebaut werden kann - über das reine agile Entwicklungsteam hinaus, um so den Kunden glücklich zu machen. Wie Sie sehen, ein wirklich weiter Themenbogen. Das alles bekommen wir natürlich nur mit der tatkräftigen Hilfe unserer Gastautoren zustande, die uns ihre Gedanken zu den sehr vielschichtigen Themen agiler Softwareentwicklung und agiler Organisationen näher bringen. Wir treffen in dieser Ausgabe auf alte Bekannte wie Marc Löffler oder Urs Enzler, die auch auf der Agile Bodensee 2012 einen Vortrag hielten. Über die neuen Gesichter, wie Sven Schnee aus der Avira-Connection und unseren Kollegen Thomas van Aken, der für die Sybit vor Ort beim Kunden als Agile Coach seinen Mann steht, freuen wir uns besonders. Schreiben Sie doch auch einen Beitrag, der Bogen ist doch noch lange nicht überspannt! Nachdem wir das Dutzend vollgemacht haben, was kommt als Nächstes? Sollen wir doch aufhören, weil eh alles laaangweilig ist? Oder sollen wir weiter knallhart an den Themen dranbleiben? Schreiben Sie uns eine Mail, diskutieren Sie mit uns in unserem Blog oder besuchen Sie uns beim nächsten Agile Breakfast: Johannes Hartmannsgruber IMPRESSUM Sybit GmbH Sankt-Johannis-Str Radolfzell, Deutschland Fon: +49 (0) Fax: +49 (0) Internet: Chefredaktion (V.i.S.d.P.): Johannes Hartmannsgruber Redaktion: Stephan Strittmatter Autoren-Service: Sie möchten einen Artikel in einer der folgenden Ausgaben beisteuern? Sprechen Sie uns an: Stephan Strittmatter Sybit agile Ausgabe 12

3 Was macht ein agiler Softwarearchitekt so den ganzen Tag? Urs Enzler Die Zeiten sind vorbei, als der Softwarearchitekt in seinem dunklen Raum saß und aus den Anforderungen, welcher der Anforderungsingenieur vorab erstellt hatte, eine Architektur zauberte und diese dann an die Entwickler zur Umsetzung weitergab. In der heutigen Welt dauert der sequentielle Ablauf dieser Phasen schlicht zu lange und ist zu träge um am Markt bestehen zu können. Das Bedürfnis zu schnelleren Entwicklungszyklen und mehr Flexibilität bei Veränderungen der Anforderungen hat in den letzten Jahren den agilen Entwicklungsmethoden zu deren Siegeszug verholfen. Doch braucht es bei all den selbst organisierten und cross-funktionalen Teams überhaupt noch einen Architekten? Ich meine: Ja! Aber was sind dann seine Aufgaben? Sybit agile Ausgabe 12 3

4 Drei Aufgaben für den agilen Softwarearchitekten 1) Technologische Führung Technologieevangelist Der Softwarearchitekt ist der Technologieevangelist des Teams. Er kennt die Trends und weiß, welche Technologien in Zukunft wichtig für das Produkt und Team sind und hat Argumente um das Team und dessen Umfeld zu überzeugen, wann und warum neue Technologien eingeführt werden müssen. Software Engineering Praktiken In der agilen Welt ist es unerlässlich, dass die Architektur veränderbar bleibt, um den sich verändernden Anforderungen folgen zu können. Damit eine Architektur flexibel bleibt sind gute Engineering Praktiken gefordert. Der Softwarearchitekt übernimmt hier eine Führungsrolle und fördert den Einsatz von Testgetriebener Entwicklung, Akzeptanztest-getriebener Entwicklung und Konzepten wie Clean Code. Ein Spike ist ein minimaler Prototyp der sämtliche Schichten des Systems durchsticht. Spikes Ein Spike ist ein minimaler Prototyp der sämtliche Schichten des Systems durchsticht. Er dient als Grundlage für Aufwandschätzungen, Risikoabwägungen und zur Erhöhung des Wissensstands. Der Softwarearchitekt nutzt Spikes um architektonische Vorarbeit für das Team zu leisten, damit dieses anschließend effizient und effektiv vorwärts arbeiten kann. Nicht-funktionale Tests Ein Hauptaspekt der Architektur ist es, die gewünschten funktionalen Anforderungen mit den geforderten nicht-funktionalen Anforderungen in Einklang zu bringen. Darum ist es die Aufgabe des Architekten dafür zu sorgen, dass auch die nicht-funktionalen Anforderungen eingehalten sind. Am besten geschieht dies durch das Schreiben von automatisierten Tests. So kann jederzeit überprüft werden ob das System die Anforderungen erfüllt. Code schreiben Als agiler Softwarearchitekt ist selber programmieren ein großer Anteil der Arbeit. Nur so versteht der Architekt die Probleme des Teams und kann konkrete Lösungen erarbeiten. Und nicht zuletzt bestimmt der Code wie die Architektur ist und nicht das Diagramm an der Wand. 2) Stakeholder verstehen Big Picture Der Architekt ist die Person, welche das Big Picture verstehen muss. Alle Aspekte wie Funktionalität, nicht-funktionale Eigenschaften, technische Risiken, Wartbarkeit der Lösung müssen berücksichtigt werden. Während der Entwicklung verlieren sich Entwickler schnell in Details und müssen ans Ganze erinnert werden. Der Architekt ist die Person, welche das Big Picture verstehen muss. Mit allen Stakeholdern sprechen Um die Stakeholder zu verstehen, muss der Architekt mit allen sprechen: Sponsor: was will er für sein Geld Endbenutzer: was sind Lösungen für die Probleme Betrieb: was unterstützt den Betrieb des Produkts Entwickler: wie kann die Entwicklung vereinfacht werden Im Gegensatz zum Product Owner oder Anforderungsingenieur stehen beim Softwarearchitekten die technische Lösung im Vordergrund und nicht die Anforderung als solche. Alle Standpunkte kennen lernen Der agile Softwarearchitekt spricht aber nicht nur mit den Stakeholdern, sondern er begleitet sie bei ihrer Arbeit um besser verstehen zu lernen wie eine Lösung für alle angestrebt werden kann. Den Benutzer verstehen Besonders wichtig ist es die Endbenutzer zu verstehen. Usability Tests und Benutzerakzeptanztests sind die Grundlage für Entscheide wie die Anforderungen umgesetzt werden sollen. Der Architekt begleitet diese Arbeiten um Auswirkungen auf die Architektur mitzukriegen. Unterstützung des Product Owners Mit seinem technischen Wissen und dem Verständnis für die Bedürfnisse der Stakeholder unterstützt der agile Softwarearchitekt den Product Owner bei seiner Arbeit. Er hilft Anforderungen zu erkennen (vor allem nicht-funktionale Anforderungen gehen gerne vergessen), das Produkt-Backlog zu konsolidieren und zu priorisieren (Risikoüberlegungen). 4 Sybit agile Ausgabe 12

5 3) Teamcoach Architektur ist Teamarbeit Der agile Softwarearchitekt erstellt die Architektur nicht alleine. Vielmehr überlässt er dies dem Team und coacht dieses bei der Erstellung. Bei einem agilen Vorgehen werden jeden Tag dutzende design- und architekturrelevante Entscheide getroffen. Alle Teammitglieder müssen in der Lage sein, korrekte Entscheide selbständig zu treffen. Koordinieren Um die Architektur und das Design einheitlich zu halten, ist es die Aufgabe des Architekten zwischen allen Teammitgliedern zu koordinieren. Pair Programming Ein gutes Mittel um diese Koordination im Alltag umzusetzen ist Pair Programming. Der Softwarearchitekt kann durch häufiges Pair Programming mit allen Teammitgliedern dafür sorgen, dass einheitliche Lösungen umgesetzt werden und so ein gemeinsames Häufiges Pair Programming Teamverständnis mit allen entsteht, wie wiederkehrende Aufgaben gelöst werden sollen. Teammitgliedern sorgt für gemeinsames Ausbildung des Teams Teamverständnis. Bei kritischen Design- und Architekturentscheiden kann der Softwarearchitekt zusätzlich zum Pair Programming konkrete Workshops durchführen um das Team auf diese Themen zu sensibilisieren und gemeinsame Lösungen zu finden. Ebenfalls können Teamregeln bezüglich Architektur und Design zusammen erarbeitet werden. Sybit agile Ausgabe 12 5

6 Unterstützung des Scrum Masters Der agile Softwarearchitekt unterstützt den Scrum Master dabei, effizientere und effektivere Wege zu finden, wie Software entwickelt wird. Dies ist besonders wichtig, wenn der Scrum Master keinen großen technischen Hintergrund hat. Sie wollen ein agiler Softwarearchitekt sein? Dann zeichnen Sie sich durch folgende Eigenschaften aus: Kommunizieren Der agile Softwarearchitekt kommuniziert mit allen Beteiligten, den Endbenutzern, dem Sponsor, dem Betrieb und den Entwicklern. Anders als in traditionellen Projekten findet diese Kommunikation Gesicht zu Gesicht statt und nicht über Dokumente wie Anforderungen und Software-architekturdokument. Effektive Tools einsetzen Anstelle von UML Werkzeugen und Dokumenten treten Whiteboard, Sketches, Prototypen, Stift und Papier. Diese Werkzeuge eignen sich wesentlich besser zur Kommunikation und zur Vermittlung Der agile Softwarearchitekt von Ideen. sitzt nicht in seinem Teil des Teams Elfenbeinturm Der agile Softwarearchitekt sitzt sondern nicht in seinem Elfenbeinturm mitten im Team. sondern mitten im Team. Er ist Teil des Teams, er ist involviert bei Planung, Schätzung, Umsetzung und Wartung des Produkts. Lernen Als technologischer Anführer muss sich der agile Softwarearchitekt kontinuierlich weiterbilden. Nur durch das Verständnis der neuen Technologien und durch State-of-the-art Designfähigkeiten kann eine Architektur entstehen, welche Risiken minimiert und Flexibilität maximiert. Entscheiden Zu guter Letzt ist die Hauptaufgabe des agilen Softwarearchitekten zu entscheiden. In einem agilen Vorgehen sind die Entwicklungszyklen so kurz, dass das Verzögern von Entscheiden das ganze Team zum Stillstand zwingen kann. Der Architekt bringt die Beteiligten dazu, dass Entscheide gefällt werden, auch wenn diese eventuell in Zukunft wieder abgeändert werden müssen. Doch dies ist das kleinere Problem, denn eine agile Architektur erlaubt Änderungen auch spät im Projekt. Rolle oder Person? Ob der agile Softwarearchitekt eine Rolle, welche durch mehrere Personen wahrgenommen wird, oder eine einzelne Person ist, hängt vom Team ab. In sehr erfahrenen Teams bringt die Verteilung der Architektenrolle auf mehrere Personen große Vorteile bezüglich Verfügbarkeit und Wissensverteilung. In Teams mit vielen unerfahrenen Mitgliedern kann die Fokussierung auf eine Einzelperson zu einfacheren Strukturen und einer klareren Linie führen oder es ist schlicht und einfach nur eine Person mit den geforderten technischen und sozialen Fähigkeiten vorhanden. Zum Autor Urs Enzler hat an der ETH Zürich Informatik studiert. Neben seiner Haupttätigkeit als Softwarearchitekt bei bbv Software Services AG (http:// unterstützt er Unternehmen bei der Einführung agiler Entwicklungsmethoden wie Scrum oder Urs Enzler Test Driven Development. Er referiert auf Konferenzen und Tagungen in der Schweiz und in Deutschland über agile Softwareentwicklung und -architektur. Er bloggt auf 6 Sybit agile Ausgabe 12

7 To ASSUME makes an A** out of U and ME Thomas van Aken Sie finden das ist ein hartes Statement? Finde ich auch. Ein ehemaliger Kollege von mir hat dies auf einer Fortbildung als Denkanstoß in die Runde geworfen. Was er damit meinte, kennen wir alle: die Situation, in der sich zwei Kollegen gegenüberstehen und ihre unterschiedlichen Annahmen offenbaren: Ich dachte, Du!?. Mich hat diese provokante These eine ganze Zeit lang verfolgt. Dabei habe ich mich ganz allgemein gefragt, wie oft wir eigentlich Annahmen in unserer täglichen agilen Projektarbeit treffen, die in ähnlicher Weise schief gehen können? Es hat mich dann doch ein wenig überrascht, auf wie vielen Ebenen wir die unterschiedlichsten Arten von Annahmen treffen. Man kann sagen, Annahmen zu treffen, ist unser tägliches Brot! Aber macht uns das zwangsläufig zu? Ich glaube nicht. Beginnen wir die Reise durch die vielfältige Welt der Annahmen in der agilen Software-Entwicklung [1]. Los geht s auf der Ebene mit dem höchsten Detailgrad: Erste Ebene: Einen technischen Task erstellen Verantwortlich: Das Team Folgende Annahmen werden hier getroffen: a. Der Task ist im Zusammenspiel mit den anderen Task die richtige technische Maßnahme, um die gewünschte User Story / das gewünschte Feature [2] zu erfüllen. b. Auch wenn der Task erst am Ende des Sprints umgesetzt werden sollte, so ist er dann noch immer die richtige technische Maßnahme. c. Der Task dauert nicht länger als einen Tag. Die gute Nachricht zuerst: Alle diese Annahmen werden vom gesamten Entwicklungs-Team getroffen. Dabei ist die Reduzierung des Planungshorizonts auf einen Sprint eine gute Voraussetzung dafür, dass sich diese Annahmen durch die Umsetzung der ersten Tasks im Laufe des Sprints nicht überholen und dadurch falsch werden. Sollte dies dennoch vorkommen, so hat das Team durch das Sprint-Board alle Tasks Die Reduzierung im Blick und kann diese ändern des Planungshorizonts auf oder anders ausgedrückt: die im Sprint-Planungs-Meeting getroffenen Annahmen aufgrund der ge- einen Sprint ist eine gute machten Erfahrungen anpassen. Voraussetzung Ist das Team bei der Sprint-Planung nicht ausreichend sicher, dass eine technische Annahme die richtige ist, so kann es mit einem sogenannten Spike [3] experimentell versuchen, die Qualität der Annahme zu erhöhen. Zweite Ebene: Eine User Story dem Team vorstellen Verantwortlich: Der Product Owner Folgende Annahmen trifft hier der Product Owner: Das Team hat die Anforderung verstanden und plant eine Umsetzung, die der User Story entspricht. Eine Grundvoraussetzung dafür, dass diese Annahme zutrifft, ist die klare Formulierung der User Sybit agile Ausgabe 12 7

8 Story inklusive Akzeptanzkriterien. Manchmal macht es auch Die klare Formulierung Sinn, Wireframes oder Skribbles der User Story einer Story hinzuzufügen. Unverzichtbar sind jedoch die verbale inklusive Akzeptanzkriterien Vorstellung der Story im Team sowie die gemeinsame Diskussion darüber im Rahmen der ersten Sprint Planung. Erst hierdurch wird ein erstes gemeinsames Grundverständnis der Story erzielt. Darüber hinaus ist es wichtig, dass der Product Owner auch bei der Sprint Planung 2 anwesend ist. Hier geht es um technischen Lösungen, die - wie wir in 1a) gesehen haben - immer Annahmen darstellen, einer User Story gerecht zu werden. Meistens geht es um Detail-Diskussion wie Drop-Down-Liste oder Radiobuttons?, die das gemeinsame Verständnis der Story und Ihrer technischen Umsetzung vertiefen. Manchmal kommt im Rahmen dieser gemeinsamen Feinspezifikation jedoch auch heraus, dass die Story doch nicht komplett verstanden wurde: An dieser Stelle sollen die Benutzerdaten noch gar nicht gegen den Webservice validiert werden. Das soll erst nach dem letzten Schritt der Eingabe geschehen. Dritte Ebene: User Stories definieren und ins Product Backlog aufnehmen Verantwortlich: Der Product Owner Folgende Annahmen trifft hier der Product Owner: a. Die User Stories treffen den Bedarf aller relevanten User. b. Die User Stories entsprechen den Vorstellungen des Kunden. Die Maßnahmen, um die Annahmen aus Punkt 1 und 2 zu verbessern, sind durch das Sprint Planungs-Meeting weitgehend formalisiert. Auf dieser dritten Ebene liegt die Verantwortung, die richtigen Maßnahmen zu treffen, allein beim Product Owner. Hier muss er seine eigenen Annahmen, die des Kunden sowie der Endnutzer unter einen Hut bringen. Was kann man also tun? Gehen wir der Reihe nach die oben genannten Punkte durch: a. Die User Stories treffen den Bedarf aller relevanten User: Der Erfolg steht und fällt mit den Usern. Zwei zentrale Fragen gibt es in diesem Zusammenhang: I. Wer sind die relevanten User? Ist die weiter zu entwickelnde Software bereits im Einsatz oder ist für den internen Gebrauch bestimmt, so kann der Kunde oft klare Aussagen hierüber treffen. Ansonsten helfen Instrumente der Marktforschung weiter (Webseiten-Tracking, Nutzerumfragen auf Webseiten, Markt-Analysen, etc.). Ist die Nutzergruppe nicht klar definiert, so sollte sich der Product Owner mit dem Kunden auf klare gemeinsame Annahmen verständigen. Ein gutes und griffiges Hilfsmittel hierzu sind Personas [4]. II. Was ist der Bedarf der User? Der Aufbau von User Stories ist bekannt: Als User X möchte ich Y so dass ich Z. Dabei steht X für das entsprechende Feature und Z für das Warum oder den Bedarf. Für den Product Owner ist es noch wichtiger, den Bedarf als das konkret gewünschte Feature zu kennen. Denn die Aussage eines Nutzers, dass er ein gewisses Feature braucht, ist auch nur eine Annahme. Er trifft diese, da er denkt, dass genau dieses Feature seinem Bedarf am nächsten kommt ( Als Online-Banking Nutzer möchte ich meine Kontonummer und meine PIN eingeben, so dass ich möglichst sicher auf mein Konto zugreifen kann ). Vielleicht kennt der Product Owner aber noch andere Features, die seinem Bedarf besser gerecht werden ( Als Online-Banking-Nutzer möchte ich mich über einen Chipkartenleser anmelden, so dass ich möglichst sicher auf mein Konto zugreifen kann ). Der Product Owner als Anwalt des Nutzers sollte also Experte für dessen Bedarf sein. Falsche Annahmen können auf dieser Ebene schon recht teuer werden. Der b. Die User Stories entsprechen den Vorstellungen des Product Owner als Anwalt Kunden: Manchmal hat der des Nutzers Kunde recht genaue Vorstellungen, was er möchte. sollte also Experte für dessen Bedarf sein. In einem anderen Fall sind dies jedoch nur vage Ideen. Hat der Product Owner - wie gerade beschrieben - die Möglichkeit, sich intensiv mit den Bedarfen der User auseinander zu setzen, dann ist er so oder so in einer guten Position, den Kunden dahingehend zu beraten, die richtigen Annahmen über die zu schaffenden Funktionalitäten zu treffen. Unabhängig davon ist es für ihn essentiell, diese Annahmen so intensiv wie möglich mit dem Kunden zu teilen. Zumindest auf Epic- Ebene sollten diese gemeinsam formuliert und abgesprochen werden. Je weniger dies möglich ist, desto mehr begibt sich der Product Owner als Dienstleister auf glattes Geläuf. 8 Sybit agile Ausgabe 12

9 Vierte Ebene: Die User Stories im Backlog priorisieren Verantwortung: Der Product Owner Zwei wesentliche Aspekte gibt es hierbei zu beachten: 1. Die Reihenfolge der Stories im Backlog weist den Weg durch das Projekt. Die Frage ist nur, wohin soll er führen? Ohne eine genaue Zieldefinition (hierzu später mehr) können keine auch nur halbwegs fundierten Annahmen über die richtige Reihenfolge der Stories getroffen werden. Klingt einfach, wird aber oft einfach übersehen. 2. Liegt eine Zieldefinition vor, so sollte der Product Owner diese bei der Priorisierung der Stories immer präsent haben. Es bleibt jedoch auch hier immer bei einer Annahme, dass diese Reihenfolge den größten Mehrwert für den User zuerst liefern wird. So kann jeder Product Owner froh sein, wenn er auch für den Priorisierungsprozess Endnutzer zur Hand hat, die er zu Rate ziehen kann. Am Ende sollte das Ergebnis immer auch dem Kunden vorgestellt werden. Er sollte den Weg durch das Projekt nicht nur kennen sondern als Sponsor die Annahmen über den richtigen Weg mit tragen. Fünfte Ebene: Die Zieldefinition oder Vision Verantwortung: Der Kunde Eine gute Zieldefinition oder Vision für ein Projekt zu erstellen, ist gar nicht so einfach. Dabei hilft sie nicht nur bei der Planung, sie ist auch ein nicht zu überschätzendes Mittel der Teammotivation. Roman Pichler bezeichnet die Vision als True North eines Projektes und gibt Tipps zur Erstellung [5]. Dabei ist die Vision oft auch wichtig, um ein Projekt-Budget zu legitimieren. Falsche Annahmen auf dieser Ebene sind somit die teuersten im Projekt, da hier nicht nur einzelne Features keinen Mehrwert liefern können, sondern im schlechtesten Fall ein ganzes Projekt am Ziel vorbei schießen kann. Wege, die Annahmen auf dieser Ebene zu verbessern, sind wiederum Elemente der Marktforschung und damit eine enge Orientierung am Kauf- und Nutzungsverhalten der Endnutzer. Darüber hinaus ist es wünschenswert, die Annahmen auf dieser Ebene schnell überprüfen zu können, um Investitionen in die falsche Richtung zu minimieren. Fast-to-Market ist das Zauberwort. Agile Projekte, die nach wenigen Sprints bereits lauffähige Software ausliefern, bringen hier einen klaren Mehrwert im Sinne der Risikominimierung für den Kunden. Fazit Annahmen zu treffen und damit Risiken einzugehen, ist auf den Agile Methoden verschiedensten Ebenen der fördern Software-Entwicklung Alltagsgeschäft. Sich dessen bewusst qualitativ hochwertige - weil gemeinschaftlich getroffene - zu sein, ist oft schon hilfreich. So haben Annahmen nicht immer Annahmen das fatale Ergebnis, wie im Titel beschrieben. Vielleicht kann man ein wenig abgemildert formulieren, dass Annahmen das Glatteis in der Software-Entwicklung darstellen. Sie sind jedoch nicht nur ein notwendiges Übel, das es im Griff zu halten gilt - sie sind auch die kleinen und großen Wegweiser, die uns durch unbekanntes Terrain führen. Agile Methoden fördern qualitativ hochwertige - weil gemeinschaftlich getroffene - Annahmen und helfen, diese schnell und kontinuierlich zu überprüfen. Weitere Disziplinen, wie Marktforschung, User Centered Design, etc. sind gute Begleiter auf dem Weg. Für das unvermeidbare Restrisiko hilft jedoch nur ein gutes Händchen sowie das berühmte Quäntchen Glück. Dass beides ihren Weg dauerhaft begleitet, dafür drücke ich Ihnen die Daumen! Quellenverzeichnis [1] Ich möchte mich hier auf die agile Art, Annahmen zu treffen, beschränken. Dabei ist es sicherlich auch absolut interessant zu schauen, wie dies in anderen Formen des Projektmanagements geschieht. Dies würde hier allerdings den Rahmen sprengen. [2] Eine User Story ist für mich die klarste Form der Beschreibung einer fachlichen Anforderung und damit einer funktionalen Annahme. Daher verwende ich im weiteren Verlauf überwiegend diesen Begriff. [3] [4] [5] Zum Autor Thomas van Aken Thomas van Aken ist Agile Coach bei der Sybit GmbH. Er unterstützt unsere Projekt- Teams und unsere Kunden, um agile Vorgehensmodelle wie Scrum und Kanban zu etablieren bzw. zu verbessern. Sybit agile Ausgabe 12 9

10 Hypothetische Retrospektiven Marc Löffler Retrospektiven gibt es schon eine ganze Weile. Speziell in agilen Teams sind diese Meetings mittlerweile Standard. Aber genauso viele Teams stellen nach ein paar Monaten fest, dass ihre Retrospektiven keinen Effekt mehr zu haben scheinen. Die Retrospektive wird zu einer leeren Hülle mit sich wiederholenden Mustern, immer den gleichen Ergebnissen und einer Menge Langeweile. Einer der Gründe hierfür ist, dass all die schönen low hanging fruits geerntet wurden, die meist direkt im Einflussbereich des Teams und somit einfach zu beheben sind. Im Laufe der Zeit muss man sich aber auch um die Umgebung, also das System rund um ein Team beschäftigen, wenn man mit seiner agilen Transition erfolgreich sein will. Dieses größere System ist aber viel schwieriger zu beeinflussen und der mögliche Effekt einer beschlossenen Maßnahme daher schlecht vorhersehbar. Man braucht also eine Methode, um mit dieser Unsicherheit umzugehen und wieder zu effektiveren Retrospektiven zu kommen. Eine Variante ist die gezielte Verwendung von Hypothesen. 10 Sybit agile Ausgabe 12

11 Die 5 Phasen einer Retrospektive Die meisten Leute, die mit Retrospektiven zu tun haben, kennen die fünf Phasen, die eine Retrospektive durchlaufen sollte. Diese fünf Phasen wurden erstmals im Buch Agile Retrospectives Making Good Teams Great [1] von Esther Derby und Diana Larsen beschrieben. Set the Stage Die erste Phase einer Retrospektive sollte den Boden für den Rest der Retrospektive bereiten. Sie dient dazu alle Teilnehmer der Retrospektive abzuholen und auf die Retrospektive einzustimmen. Diese Phase ist deshalb so wichtig, weil jeder Teilnehmer von einem anderen Ort geistig abgeholt werden muss. Würde man direkt mit der 2. Phase anfangen, hätten die meisten Teilnehmer noch ihre letzte Aufgabe im Kopf, die sie gerade noch an ihrem Arbeitsplatz bearbeitet haben und wären noch nicht bereit sich auf diesen Workshop zu konzentrieren. Aus meiner Sicht ist es gut, wenn diese Phase mit Spaß verbunden ist, das macht den Kopf am besten frei. Gather Data Ziel der nächsten Phase ist es Daten zu einem vergangenen, klar definierten Zeitraum zu sammeln. Dies kann ein Sprint bei einem Scrum Team sein, der Zeitraum eines gesamten Projekts oder auch nur der letzte Arbeitstag. Meiner Meinung nach sollte man die Zeitspanne zwischen einem Ereignis und einer Retrospektive so kurz wie möglich halten. Es soll dabei helfen einen Überblick über die Geschehnisse dieses Abschnitts zu bekommen, damit alle die gleiche Basis haben. Dies sollte sowohl positive als auch negative Ereignisse umfassen. denn die tatsächlichen Ursachen sind. Das führt dazu, dass man nur an der Oberfläche kratzt und somit keine vernünftigen Tatsachen definieren kann. Man könnte es mit einem Krebskranken vergleichen, der sich einfach ein paar Schmerztabletten einwirft um seine Schmerzen zu lindern, anstatt den eigentlichen Tumor zu beseitigen. Man arbeitet nur an den Symptomen und nicht an der Ursache. Keine gute Idee. Eine gut durchgeführte Ursachenforschung bereitet die Basis für die zweitwichtigste Phase, die Definition der nächsten Schritte. Decide What To Do Nachdem wir jetzt die möglichen Ursachen kennen, geht es in dieser Phase darum die entsprechenden Maßnahmen zu definieren, natürlich auf der Basis der gefunden Ursachen. Ohne diesen Schritt würde es bei einem Rückblick bleiben und das wollen wir schließlich nicht. Am Ende dieser Phase sollte man sich auf einige wenige Maßnahmen beschränken, am besten maximal drei. Wenn es mehr sind, wird es oft schwer diese umzusetzen. Closing Nachdem man die nächsten Schritte definiert hat, sollte man nicht einfach alle davon rennen lassen. Man sollte ein paar Minuten darauf verwenden, eine kurze Nachbereitung zu machen und die Ergebnisse zu feiern. Das...sollte man auch eine kurze Retrospektive der Retro selbst machen. Team hat schließlich einiges an Blut, Schweiß und Tränen in die letzte Iteration und auch in die Retrospektive selbst gesteckt. Natürlich sollte man auch eine kurze Retrospektive der Retro selbst machen. Schließlich will man auch hier immer und immer besser werden. >> Generate Insight Neben der ersten Phase ist es die Ursachenforschung, die am häufigsten vergessen wird. Viele Teams stürzen sich darauf die nächsten Schritte zu definieren, ohne sich vorher Gedanken gemacht zu haben, was Sybit agile Ausgabe 12 11

12 Nutzung der Hypothese in Retrospektiven Die fünf Phasen sind prima und es gibt immer noch genug Teams da draußen, die diese nicht kennen oder ignorieren. Blöderweise fehlt in diesem Ablauf allerdings die Berücksichtigung der Hypothese. Deshalb habe ich den Ablauf folgendermaßen abgeändert (siehe Bild). Die ersten beiden Schritte werden wie bisher durchgeführt. Anstatt danach direkt in die Phase Generate Insight einzutauchen, schauen wir uns zuerst einmal an, ob unsere Hypothesen vom letzten Mal korrekt waren und unsere Maßnahmen den erhofften Effekt hatten. Man prüft also nicht nur, ob die Maßnahme durchgeführt wurde, man prüft auch die damit verbundene Hypothese. In den meisten Fällen wird man herausfinden, dass der erhoffte Effekt doch nicht so eingetreten ist, wie erwartet. Wenn dem so ist, sollte man nicht den Kopf in den Sand stecken, sondern das Ganze statt dessen als Anstoß nehmen um zu prüfen, warum es anders gelaufen ist, als erwartet. Dafür gibt es den altbekannten Schritt Generate Insight. Hier kann man jetzt nach der Ursache für das beobachtete Verhalten suchen und dabei vielleicht sogar herausfinden, dass die aufgestellte Hypothese totaler Nonsens war. Die zweite Veränderung im Ablauf habe ich am Schritt Decide What To Do vorgenommen. Zusätzlich zu den Maßnahmen selbst, sollte man für jede Maßnahme eine Hypothese definieren. Nur so kann ich später überprüfen, ob die Maßnahme den ge- Zusätzlich zu den wünschten Effekt hatte oder ob Maßnahmen selbst, sie anpasst werden muss. Eine sollte man für jede gute Hypothese muss testbar Maßnahme sein sonst lässt sie sich später nicht überprüfen. Die letzte eine Hypothese definieren. Phase bleibt wie gehabt. Fazit Durch die gezielte Nutzung von Hypothesen in Retrospektiven Die Hypothesen versetzt man sein Team in die helfen Lage fokussiert und iterativ den Retrospektiven die Veränderungen anzugehen. wieder einen Sinn Anstatt immer wieder auf den zu geben. gleichen Dingen herumzukauen, kann ich mich solange mit einem Thema beschäftigen, bis es wirklich gelöst wurde. Die Hypothesen helfen mir auch dabei, den Retrospektiven wieder einen Sinn zu geben. Jedem ist klar, an was gearbeitet werden soll und was das Ergebnis der getroffenen Maßnahmen ist. So verliert eine Retrospektive nicht ihren Sinn und läuft nicht Gefahr aus dem Kalender gestrichen zu werden. Dieser Artikel enthält Auszüge aus dem Buch Die Retrospektiven Fibel an welchem der Autor gerade schreibt: https://leanpub.com/retrospektivenfibel Quellenverzeichnis [1] Programmers/dp/ / Zum Autor Marc Löffler ist Functional Manager und Agile Coach bei der Storz Endoskop Produktions GmbH. Marc Löffler 12 Sybit agile Ausgabe 12

13 Wie Hermann den Kunden glücklich machte Sven Schnee Die IT oder Software Industrie ist in ständigem Fluss. Es werden neue Technologien entwickelt, neue Märkte erschlossen und meist dauert es nicht wirklich lange bis sich neue Produkte und Entwicklungen durchgesetzt haben. Diese sich schnell verändernde Landschaft erfordert neue Methoden. Ein Grundsatz in der Arbeit mit agilen Methoden wird relativ schnell für viele Neueinsteiger deutlich: Die Bereitschaft zu lernen und sich zu verändern sollte vorhanden sein. In eben dieser Landschaft bewegt sich in unserer Geschichte die Firma SuperSoft und Hermann, der als agiler Coach versucht Firmen zu helfen, mit diesen äußeren Einflüssen besser zurecht zu kommen, indem er ihnen agile Methoden aufzeigt. Um Hermann zu schützen, sind alle Namen in der folgenden Geschichte verändert so dass keine Ähnlichkeit zu lebenden Personen oder Firmen mehr besteht. Die Firma SuperSoft hatte für sich selber schon entschieden, dass Anpassungen nötig sind, um den schnelllebigen Anforderungen der neuen Märkte gerecht zu werden. Hierfür hatte die Firma schon erste Umstrukturierungen durchgeführt. Eine Umstellung auf eine Matrix-Struktur hat die bisherigen harten Unterteilungen in Entwicklung, QA, Produktion etc. aufgelöst und eine stärkere Bindung zwischen einzelnen Teilen erreicht. Sybit agile Ausgabe 12 13

14 Als zusätzlicher Schritt wurden Feature Teams sogenannte Feature Teams ins konnten schon Leben gerufen, die nicht mehr einen deutlichen nur Entwickler sondern auch Effizienzsprung GUI-Skills sowie Test-Skills erzielen. enthielten. Damit konnte schon ein deutlicher Effizienzsprung erzielt werden. Alles was sehr nah an der Entwicklung war konnte deutlich schneller und mit besserer Qualität abgewickelt werden. Auch SuperSoft hatte Ideen für neue durchschlagende Produkte. Es bot sich an, diese neuen Produkte mit agilen Methoden umzusetzen, so dass es schnell möglich ist, durch Änderung der Prioritäten im Backlog auf sich ändernde Anforderungen oder Marktsituationen einzugehen. Deshalb hatte SuperSoft Hermann damit beauftragt, sich die Situation anzusehen und einen Vorschlag herauszuarbeiten wie eine solche Umsetzung aussehen könnte. Hermann sah sich als erstes die Zusammenarbeit aller Kollegen an, die nicht in Feature Teams organisiert waren. Dort wurde ihm deutlich, dass diese in funktionalen Einheiten strukturiert waren. Diese Einheiten waren voneinander unabhängig und verfolgten ihre eigenen Ziele, die natürlich für größere Releases mit den Zielen anderer übereinstimmen mussten. Diese neue Produkt-Idee von SuperSoft erforderte jetzt aber eine Zusammenarbeit von allen funktionalen Einheiten an einem übergeordneten Produkt. Zuerst probierte Hermann aus ob es möglich ist alle Einheiten lose zusammenarbeiten zu lassen. Er organisierte regelmäßige Planungsmeetings und Retrospektiven. Dadurch war es ihm möglich in relativ kurzen Zeitabständen zu prüfen ob alles funktioniert. Sehr schnell wurde aber deutlich, dass durch die Abhängigkeiten untereinander die Ziele nicht erreicht wurden. Von 12 Zielen, die gesetzt wurden konnten nur 2 am Ende von 2 Monaten umgesetzt werden. Aus diesem Ergebnis zog Hermann folgende Schlüsse: Es ist weder effektiv noch effizient viele Ziele parallel Es ist weder zu starten, um möglichst effektiv jeden Mitarbeiter an etwas noch effizient arbeiten zu lassen. viele Ziele parallel zu Wichtig war die Umsetzung starten... der Ziele, die dann an den Kunden weitergeben werden können. Also beschloss er in Absprache mit allen Einheiten die Anzahl der Ziele so zu reduzieren, dass nicht mehr Ziele als Einheiten gleichzeitig bearbeitet wurden. Im nächsten Schritt schaute sich Hermann die Zusammenarbeit zwischen den einzelnen Einheiten genauer an. Meistens war es so, dass nur ein einzelner Mitarbeiter aus einer Einheit für ein bestimmtes Projekt abgestellt war, mit Ausnahme der Kern Feature Teams. Aus allen Kollegen, die an einem einzelnen Ziel arbeiteten formte Hermann ein Feature Squad, dessen Kern ein Feature Team war, angereichert mit allen weiteren Skills, die für das neue Produkt nötig war. Dieses Feature Squad verhielt sich wie ein normales agiles Team: Daily Standup, Planungsmeeting, Demo und Retrospektive. 14 Sybit agile Ausgabe 12

15 Nach dieser Umstellung und mit der reduzierten Anzahl an Zielen war es jetzt möglich 4 von 6 Zielen umzusetzen. Wenn man das mit den 2 von 12 vergleicht eine enorme Steigerung. Hermann war sehr zufrieden mit sich, aber alles im Leben hat seinen Preis. Durch die Fokussierung auf weniger Ziele und die Festlegung auf Feature Squads ergaben sich einige Nachteile: Nicht alle Squad-Mitglieder waren immer zu 100% ausgelastet Innerhalb des Squads mussten von den Mitarbeitern, die sich im Leerlauf befunden haben Aufgaben übernommen werden, die nicht notwendigerweise vorher in ihrem Aufgabenbereich lagen Für manche Mitarbeiter war es ungewohnt und schwierig sich im neuen Umfeld und Team zurechtzufinden Durch den starken Fokus auf das Ziel des Squads hatte jeder Einzelne nicht mehr so viel Freiheit wie vorher seine Arbeitsabläufe selber zu gestalten Aus den Squads selber bekam Hermann aber auch sehr positives Feedback: Es entwickelte sich ein starkes Team-Gefühl und Stolz, wenn die Ziele erreicht werden konnten Die Bindung zwischen den Squad-Mitgliedern wurde deutlich stärker, wie sie vorher in den verteilten Funktionseinheiten war Durch den engen Kontakt in Dailies und die häufigen Retrospektiven konnten Probleme schnell aufgedeckt und mit gemeinsamen Aufwand aufgelöst oder abgeschwächt werden Fazit Die Weiterentwicklung von Feature Teams zu Feature Squads und die damit einhergehende Anpassung der Organisation an die Anforderungen der Welt da draußen lässt den agilen Grundsatz Individuals and interactions over processes and tools hoch leben. In einem Feature Squad werden alle notwendigen Organisationsbereiche zusammengefasst, die es braucht, um den Kunden glücklich zu machen - dazu können auch Produktmanagement, Marketing oder Vertrieb gehören. Hoffen wir, dass Hermann, In einem Feature Squad werden alle notwendigen Organisationsbereiche zusammengefasst... der Coach weiterhin erfolgreich seine Ideen realisieren kann. Zum Autor Sven Schnee Sven Schnee war zuletzt Agiler Projekt Manager bei Avira und wird ab als Senior Consultant bei Valtech arbeiten. Sybit agile Ausgabe 12 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)

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

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

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

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

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

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

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

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

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

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

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

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

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

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

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

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

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

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

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

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

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Bison hat ein agiles Führungsteam und dieses möchten wir euch vorstellen in der nächsten Stunde

Bison hat ein agiles Führungsteam und dieses möchten wir euch vorstellen in der nächsten Stunde 1 2 Bison hat ein agiles Führungsteam und dieses möchten wir euch vorstellen in der nächsten Stunde 3 - Seit Einführung von Scrum vor 3 Jahren hat sich die Führung verändert zu einem agilen Managementteam

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

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

Zuckerbrot oder Peitsche

Zuckerbrot oder Peitsche Zuckerbrot oder Peitsche Rendite Wie man ein Projekt aus der Klemme holt 1. Juli 2008 Peter Stevens, Sierra-Charlie Consulting www.scrum-breakfast.com Idee 1 Projektsanierung der König ist tot... 2 Projektsanierung

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

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

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

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

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

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG Über uns... Carsten Sahling Leitung GeschäGsfeld Agil Cer3fied Scrum Professional Projektmanagement- Fachmann Level

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

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

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

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

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-42524-8 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42524-8 sowie im Buchhandel.

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

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

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1

Inhaltsverzeichnis. Boris Gloger. Scrum. Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 sverzeichnis Boris Gloger Scrum Produkte zuverlässig und schnell entwickeln ISBN: 978-3-446-41913-1 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41913-1 sowie im Buchhandel.

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

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

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

Höchst elastisch Scrum und das Wasserfallmodell

Höchst elastisch Scrum und das Wasserfallmodell Höchst elastisch Scrum und das Wasserfallmodell Kraus Wolfgang www.sourceconomy.com 1 Abstract Das Projekt bietet zwar alle Voraussetzungen für ein agiles Vorgehen, doch der Auftraggeber und das Kunden-Management

Mehr

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm

Agile Embedded Projekte mit Scrum & Kanban. Embedded Computing Conference 2012 Urs Böhm Agile Embedded Projekte mit Scrum & Kanban Embedded Computing Conference 2012 Urs Böhm Der Ingenieur Urs Böhm Dipl.-Ingenieur Elektrotechnik Projektingenieur VDI Certified ScrumMaster urs.boehm@noser.com

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

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

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld Bernhard Fischer Fischer Consulting GmbH MedConf 2011 Luzern Folie 1 Wozu brauchen wir Requirements? MedConf 2011 Luzern Folie 2 Der Anforderungszoo

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

Agile Management Einführung in agiles Management

Agile Management Einführung in agiles Management Agile Management Einführung in agiles Management Agile Management Agile Management-Methoden Einführung Agile Management PQRST e.u. - Ing. Erich Freitag Version 25.06.2013 Lernziele Den Unterschied zwischen

Mehr

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung?

Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Grundlegende Veränderungen in der Software-Dokumentation durch agile Entwicklung? Marlis Friedl Christina Wirth Comet Computer GmbH tekom-jahrestagung 2010 5. November, UA 17 Überblick Die agile Software-Entwicklung

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

Project Community Retrospectives. Agile Organisationen lernen Lernen

Project Community Retrospectives. Agile Organisationen lernen Lernen Project Community Retrospectives Agile Organisationen lernen Lernen Andreas Schliep Scrum Coach & Trainer DasScrumTeam! as@dasscrumteam.com! @andreasschliep Ein paar Retrospektiven Referenzen Q&A auf Scrum

Mehr

impulse Strategie Innovation

impulse Strategie Innovation Strategie Innovation Mit kreativen Methoden und einer inspirierenden Moderation helfen wir Ihnen, neue Impulse für Ihre Unternehmensstrategie zu gewinnen sowie dazu passende Maßnahmen zu planen und umzusetzen.

Mehr

Scrum E I N F Ü H R U N G

Scrum E I N F Ü H R U N G Scrum EINFÜHRUNG Was ist Scrum? Agiles Vorgehensmodell Grundüberzeugungen Erste Tendenzen Mitte der 80er Jahre Grundidee: Entwickeln in Inkrementen Parallelen zur Lean Production Agiles Manifest Jeff Sutherland

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

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

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

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

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

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

Scrum in Marketingsales

Scrum in Marketingsales Scrum in Marketingsales Eine Reise im Themenfeld Scrum beyond Software. Kommst du mit? @BjoernSchotte bjoern.schotte@mayflower.de björn schotte. Geschäftsführer MAYFLOWER CSM + CSPO berate Kunden im Umfeld

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

ScrumDay 2014. User (Experience) Stories. Entstehung, Entwicklung, praktische Anwendung und Bedeutung der kleinstmöglichen Einheit agiler Konzeption.

ScrumDay 2014. User (Experience) Stories. Entstehung, Entwicklung, praktische Anwendung und Bedeutung der kleinstmöglichen Einheit agiler Konzeption. Veranstaltung ScrumDay 2014 Thema User (Experience) Stories Autor Mathias Wrba Datum Entstehung, Entwicklung, praktische Anwendung und Bedeutung der kleinstmöglichen Einheit agiler Konzeption. Page 2 Wo

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

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

Scrum und professionelles Requirements Engineering

Scrum und professionelles Requirements Engineering Scrum und professionelles Requirements Engineering Dr. Martin Mandischer (Prokurist, Professional Scrum Trainer) Jens Trompeter (Vorstand, Certified Scrum Professional) Gründung im Jahr 2003 Mehr als 160

Mehr

Scrum in Unternehmen einführen

Scrum in Unternehmen einführen Scrum in Unternehmen einführen Vom ersten Start bis zur Scrum Transition Author: Oliver Mann, Role: Agile Coach / Business Consultant @ Prowareness Contact: o.mann@prowareness.de, 0176-52845680 Scrum machen

Mehr

1 Einleitung 1 1.1 Wie Sie dieses Buch verstehen sollten... 1 1.2 Die Projektberichte... 1 1.3 Der Anhang... 3

1 Einleitung 1 1.1 Wie Sie dieses Buch verstehen sollten... 1 1.2 Die Projektberichte... 1 1.3 Der Anhang... 3 ix 1 Einleitung 1 1.1 Wie Sie dieses Buch verstehen sollten......................... 1 1.2 Die Projektberichte....................................... 1 1.3 Der Anhang............................................

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

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA PM WBS Sprint Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA Über den Vortragenden IT-Leiter der Austrian Gaming Industries (Novomatic Group of Companies) MBA in

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

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

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

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

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

REZA NAZARIAN. Berater für digitale Projekte PROFIL. Schwerpunkt. Zusammenfassung. Kernkompetenzen

REZA NAZARIAN. Berater für digitale Projekte PROFIL. Schwerpunkt. Zusammenfassung. Kernkompetenzen PROFIL REZA NAZARIAN Telefon: 0163 54 90 761 Email: consulting@reza-nazarian.de Schwerpunkt Zusammenfassung Kernkompetenzen Strukturierte agile Produktentwicklung für sinnvolle technische Lösungen. Als

Mehr