ALM goes Scrum Agile Prozesse verändern die Softwareentwicklung

Größe: px
Ab Seite anzeigen:

Download "ALM goes Scrum Agile Prozesse verändern die Softwareentwicklung"

Transkript

1 IT Research Note ALM goes Scrum Agile Prozesse verändern die Softwareentwicklung Viele Softwareentwicklungsfirmen wechseln derzeit zu agilen Prozessen aus verschiede- nen Gründen vor allem zu Scrum. Der Wechsel betrifft sogar Software- Hersteller, die ihre interne Entwicklung damit steuern. Hierfür gibt es eine ganze Reihe von Gründen, von de- nen einige direkt aus dem Unternehmen stammen (Unternehmensgröße, Geschäftsfeld, Kunden und Ähnliches) und andere sehr allgemein sind. Diese Research Note analysiert die unterschiedlichen Punkte, die für Anwender von Bedeutung sind. Zudem zeigt sie Fall- stricke und Best Practices. Analyst: Ulrich Parthier Datum: 22. April research.net

2 Ein wichtiger Grund Scrum einzusetzen, ist der Wunsch nach Transparenz. Egal, ob Anwender einen Bedarf formulieren, Pro- duktmanager Anforderungen definieren oder das Entwicklungsteam sich verpflich- tet, dies alles zu erfüllen, beginnt ohne über einen passenden Prozess zu verfü- gen, oft erstmals eine Zeit der Unsicher- heit, an deren Ende schlimmstenfalls die Ergebnisse nicht den Erwartungen entspre- chen und möglicherweise sogar die Auslie- ferung, egal ob intern oder extern, ver- schoben werden muss. Mit einem sinnvol- len, angepassten Prozess kann das in jedem Fall vermieden werden. Ein wichtiger Grund Scrum einzusetzen, ist der Wunsch nach Transparenz. Ein weiterer wichtiger Grund für Scrum liegt darin, schnell und flexibel auf Veränderungen aller Art reagieren zu können. Ein weiterer wichtiger Grund für Scrum liegt darin, schnell und flexibel auf Veränderun- gen aller Art reagieren zu können. Moderne Technologien entwickeln sich rasend schnell, so dass es nicht mehr sinnvoll ist, mehrere Jahre in die Zukunft zu planen. Schon in drei Monaten könnte es beispiels- weise eine Open- Source- Komponente ge- ben, die eine wichtige Funktionalität abbil- det und die ohne großen Aufwand in die Anwendung integriert werden könnte. Dies könnte den internen Aufwand effektiv re- duzieren und so eine vorher aufgestellte Planung für die nun von der Open- Source- Komponente übernommene Funktionalität überflüssig machen. Von der Produktseite aus betrachtet, könn- te ein anderer Hersteller ein so überzeu- gendes Feature herausbringen, das es er- forderlich macht, innerhalb kürzester Zeit ein entsprechendes Pendant bereitzustel- len. Dadurch werden Flexibilität im Umgang mit den Prioritäten und eine hohe Bereit- schaft Anforderungen umzuordnen zwin- gend erforderlich. Zudem wird es umso herausfordernder, aus den vorhandenen Informationen ein hohes Maß an verlässli- chen Vorhersagen abzuleiten. Der Wechsel zu einem empirischen und iterativ inkrementellen Prozess Auf der Entwicklerseite geht es darum, von einer (vorab- )definierten voraus bestim- menden (defined and predictive) Entwick- lung zu einem empirischen und iterativ in- krementellen Prozess zu wechseln. Nach der Entscheidung, Scrum einzusetzen, kommt die Frage, wie man die Praktiken konkret umsetzt und lebt hier konzentrie- ren wir uns darauf, wie man Scrum einset- zen und welche Praktiken man in der Praxis hilfreich nutzen kann. Sprint- Planungstreffen als fester Bestandteil des Konzepts. Für Außenstehende scheinen agile Prozesse oft planlos zu sein, da es keine lange Pla- nungsphase zu Projektbeginn gibt. Aber tat- sächlich sind bei der Planung agiler Projekte viel mehr Beteiligte eingebunden, die sich viel häufiger abstimmen. Da Scrum als ite- rativer, inkrementeller Prozess ein Produkt oder eine Anwendung immer wieder be- trachtet und verfeinert (iterativ) und stückweise erweitert (inkrementell), sind regelmäßige Planungstreffen - die Sprint- Planungstreffen - fester Bestandteil des Konzepts. Die Sprints wie die Iterationen, in denen das nächste Inkrement erstellt wird, in Scrum genannt werden sind strategisch darauf ausgerichtet, drei wesentliche Berei- che der Anwendung abzudecken: Copyright it research research.net Seite 2 / 7

3 die Umsetzung neuer Features, Verbesserungen in Performance und Benutzbarkeit und Das Arbeiten in den Bereichen Stabili- tät und Qualität. Die Verantwortung, diese drei Bereiche auszubalancieren und das Product Backlog (die Liste der Anforderungen) entsprechend vorzubereiten, trägt der Product Owner. Für Teams hat sich eine Größe von jeweils drei bis sechs Mitgliedern als optimal her- ausgestellt sowie für eine Sprintlänge ein Zeitraum von zwei Wochen. Parallele Backlog- Entwicklung In einem Entwicklungsumfeld ist es sehr schwer, mit einem einzigen Backlog zu star- ten, da erfahrungsgemäß zu viele Stakehol- der ihre eigenen Anforderungen ganz nach vorne stellen wollen. So hat beispielsweise das Professional Services - Team, das Kun- den vor Ort unterstützt, seine eigene Liste von Anforderungen an die Benutzbarkeit und die Erfahrung bei der Entwicklung glo- baler Software zeigt, dass beispielsweise die Anforderungen an die Benutzbarkeit in Eu- ropa sich mitunter erheblich von denen in den USA unterscheiden, so dass hier eine besondere Aufmerksamkeit bei der Priori- sierung erforderlich ist. Das Support- Team wiederum lenkt die Aufmerksamkeit auf allgemeine Probleme und das obere Management möchte neue und umfangreiche Features, die oft noch nicht exakt beschrieben werden können, sondern eher allgemeinen Charakter haben wie wir benötigen eine Integration mit <YYY>, weil unser Wettbewerb sie auch hat. Anforderungen, wie diese umfangreichen Features, gehen als sogenannte Epics in die Planung ein. Das sind Einträge, die ih- rerseits wiederum mehrere normale Anfor- derungen umfassen, während normale An- forderungen als sogenannte User- Stories geführt werden, also als Beschreibungen des Systemverhaltens aus Sicht eines Be- nutzers. Zusammengefasst werden diese Anforderungen in Scrum normalerweise im schon erwähnten Product Backlog, der ho- mogenisierten Liste über die offenen, be- kannten Anforderungen an das System. Dies ist erforderlich, weil es in vielen Um- gebungen notwendig ist, mit vielen Perso- nen an unterschiedlichen Standorten und mit unterschiedlichen Standpunkten eine einheitliche Meinung zu Product Backlog- Einträgen und dem jeweiligen Business Va- lue dieser Einträge zu erarbeiten. Gerade der Geschäftswert oder Mehrwert kann hier nicht nur von einer einzigen Person festgelegt werden. Hier ist vielmehr die Kommunikation zwischen den unterschied- lichen Stakeholdern notwendig zusam- men mit angemessenen Mitteln, die Infor- mationen abzulegen, wobei die Konsistenz der unterschiedlichen Absprachen unter- einander besonders wichtig ist. Das Zusammenführen die- ser unterschiedlichen Back- logs in das gemeinsame Product Backlog ist die Auf- gabe des Product Owners, der dann im Sprint- Pla- nungstreffen die einzelnen Einträge mit dem Entwick- lungsteam bespricht. Um diese Abstimmungen zu erleichtern, lässt sich das Product Backlog als Zusam- menfassung einzelner Backlogs für die Sta- keholder zu betrachten. Dennoch sollte es jedem Teammitglied erlaubt sein, neue Ein- träge in den Backlogs vorzunehmen. Die Backlogs beinhalten dann grobe Beschrei- Copyright it research research.net Seite 3 / 7

4 bungen sowohl der benötigten Features als auch die Einträge in die Wunschliste. Aufgabenverteilung Das Zusammenführen dieser unterschiedli- chen Backlogs in das gemeinsame Product Backlog ist die Aufgabe des Product Ow- ners, der dann im Sprint- Planungstreffen die einzelnen Einträge mit dem Entwick- lungsteam bespricht und hierzu, wo es sich als notwendig und sinnvoll erweist, die Ei- gentümer der einzelnen Backlogs einlädt. Innerhalb der Planungssitzung werden zu- dem Abhängigkeiten zwischen unterschied- lichen Teams identifiziert, um so viel paral- lele Arbeit wie sinnvoll zu ermöglichen und dennoch den Fokus der Iteration beibehal- ten zu können. Geplant wird dabei auf Ebene der User- Story. Jede User- Story hat einen Kunden und einen Besitzer. Der Kunde hat die Anforderung ursprünglich formuliert. Bei dem Besitzer handelt es sich typischer- weise um einen Seniorentwickler, der die User- Story durch den gesamten Entwick- lungsprozess bis zur Auslieferung begleitet. Der nächste Teil der Planungssitzung ist der Aufteilung der User- Stories in einzelne Ent- wickleraufgaben (Tasks) und anderen Ver- besserungen gewidmet. Diese Sitzung lie- fert in der Regel wichtige Beiträge bei den ersten Schritten der Ableitung der techni- schen Spezifikationen aus den fachlichen textuellen Beschreibungen, bei der Koordi- nation der Arbeit der Qualitätssicherung und dient als wichtige Quelle für das Do- kumentationsteam. Automatische Aufgabenverteilung über ein ALM- Tool Bereits im Vorfeld der Planung sollte bei der Erfassung der Backlog- Einträge intensiv die Fähigkeit eines Application Lifecycle Mana- gement (ALM)- Tools (wie etwa Polarion ALM) genutzt werden, um Aufgaben auto- matisch zuzuweisen. Dazu gibt der Projekt- leiter die Fähigkeiten der einzelnen Senior- entwickler in das Tool ein, sodass nach den vom Manager definierten Kriterien das Sy- stem selbstständig einen geeigneten Ent- wickler nach vorher definierten Regeln für spezielle Aufgaben auswählen kann. Diese Regeln werden zuvor zwischen dem Mana- ger und den Entwicklern abgestimmt. Der Projektleiter trägt die Fähigkeiten der einzelnen Seniorentwickler in das Tool ein, so dass nach den vom Manager definierten Kriterien das System selbst- ständig einen geeigneten Entwickler nach vorher de- finierten Regeln für speziel- le Aufgaben auswählt. Dieses Feature erlaubt es beispielsweise, direkt bei der Erfassung eines Eintrags, ei- nen Seniorentwickler durch das System auswählen zu lassen, der die Implementie- rung leiten könnte. Dieser wird dann per E- Mail informiert und sieht direkt den neuen, ihm zugeordneten Eintrag. So unterstützt man die frühe Diskussion neu erfasster User- Stories und kommt zudem zu vorab bewerteten Beiträgen für die Planungssit- zungen. Das Gewicht oder auch die initiale Schät- zung jeder User- Story ist wichtig, um die Priorisierung zu erleichtern. Die automati- sche Zuordnung hilft dabei, bereits vor der Planungssitzung zu einer initialen Bewer- tung zu kommen und die Kommunikation anzuregen. Die Hochrechnungen und Pro- jektionen erlauben es auch, längerfristig zu planen. Copyright it research research.net Seite 4 / 7

5 Umgang mit User- Stories Das System sollte so konfiguriert sein, dass für sogenannte Epics der noch offene ge- schätzte Aufwand aus den untergeordneten Einträgen ermittelt wird. So ist man in der Lage, den noch offenen Aufwand für das aktuelle Release zu ermitteln und zu erken- nen, ob große Features bereits vollständig umgesetzt wurden. Wie ist mit User- Stories umzugehen, die für einen Sprint zugesagt, aber nicht geliefert wurden? Es erscheint selbstverständlich, diese mit folgender Argumentation einfach in den nächsten Sprint zu übernehmen: Es habe nur ein wenig länger gedauert als ge- plant und die User- Story sei deshalb noch nicht ganz fertig. Oft ist dann die intuitive Erwartung, dass die User- Story mit dem nächsten Sprint, der in den folgenden Ta- gen beginnt, umgesetzt wird. Die Praxis zeichnet allerdings ein anderes Bild. Die Entwickler halten die im vorigen Sprint noch nicht abgeschlossenen User- Stories oft bis zum Ende der Iteration zu- rück. Sie gehen davon aus, dass die Stories einfach zu beenden seien, und glauben ge- nau zu wissen, was zu tun sei. Tatsächlich sind allerdings oft andere Aufgaben inner- halb des aktuellen Sprints aufwendiger als geplant, sodass die zuvor unvollendeten User- Stories erneut nicht abgeschlossen werden können. Eine sehr beliebte Frage auf den Planungssitzungen ist daher Wenn diese User- Story nicht abgeschlossen wur- de, wie können wir sicherstellen, dass unse- re neue Zusage tatsächlich umgesetzt wird? Daily Scrums Nicht nur die Sprints werden im Rahmen der originären Scrum- Konzepte regelmäßig geplant, auch die tägliche Arbeit wird dort in sogenannten Daily Scrums abgestimmt. Diese Daily Scrums sind sogar der eigentli- che Namensgeber der Methodik und ver- danken ihren Namen dem ebenfalls Scrum genannten Gewühle, durch das im Rugby der Ball für einen neuen Spielzug in Bewe- gung gebracht wird. Im Scrum in der Soft- ware sind dies meistens kurze im stehen abgehaltene (und deshalb auch oft Stand- up- Meetings genannte) Treffen, innerhalb derer sich die Teammitglieder synchronisie- ren. Daily Scrums sind der ei- gentliche Namensgeber der Methodik und verdanken ihren Namen dem ebenfalls Scrum genannten Gewüh- le, durch das im Rugby der Ball für einen neuen Spiel- zug in Bewegung gebracht wird. Daily Scrums sind der möglicherweise kom- plizierteste Teil von Scrum, da sie eine Än- derung der inneren Grundhaltung der Be- teiligten erfordern. Zu viele von uns inter- pretieren Sitzungen als ein Mittel, Aufgaben zugewiesen zu bekommen und Bericht zu erstatten. Aber bei Scrum im Allgemeinen und bei den Daily Scrums im Besonderen geht es darum, dem Team zu helfen, die aktuelle Situation richtig zu verstehen und es in die Lage zu versetzen, notwendige Än- derungen vorzunehmen, um die Ziele (des Sprints) zu erreichen. Daily Scrums erlauben es den Teammitglie- dern, sich zu synchronisieren und als eine Einheit zu beurteilen, ob das Sprint- Goal (ein zu Anfang des jeweiligen Sprints defi- niertes, mit dem Product Owner verhandel- tes Ziel) noch erreichbar ist, sie tatsächlich genau im Plan liegen und falls eines da- von nicht der Fall sein sollte, zu entschei- den, an welchen Stellen etwas geändert Copyright it research research.net Seite 5 / 8

6 werden muss. Niemand sollte Berichte über das Meeting einsammeln und der Scrum- Master sollte eine einfache Frage im Fokus haben und sich vergewissern, dass jeder die Antwort darauf weiß: Sind wir sicher, dass wir unsere Sprint- Ziele erreichen werden? Bitte zeigt oder erklärt, wie wir das ma- chen! Regeln für den Entwicklungsprozess Innerhalb eines Sprints integriert das Ent- wicklungsteam kontinuierlich alle Änderun- gen und diese neuen Versionen werden täglich auf den internen Servern installiert, um die Stabilität zu überprüfen und das Produkt gegebenenfalls auch anderen Per- sonen als den Entwicklern zugänglich zu machen wie beispielsweise Testern oder technischen Schreibern, die sich um die Do- kumentation kümmern. Um dies sicherzustellen, sind im Entwick- lungsprozess Regeln zu vereinbaren. Sinn- voll sehen diese beispielsweise so aus: Mindestens einmal am Tag wird ein Integrations- Build (automatisiertes Bauen des gesamten Systems) durch- geführt üblicherweise in der Nacht. Im Falle eines fehlerhaften Builds muss das fehlerverursachende Pro- blem mit höchster Priorität gelöst werden und es wird ein neuer Build ausgelöst. Fehlgeschlagene Unit- Tests werden mit höchster Priorität behandelt und sobald die zugehörigen Fehlerursa- chen beseitigt wurden, soll ein neuer Build ausgelöst werden, um die Feh- lerbeseitigung auch im Gesamtsystem zu bestätigen. 20 % der in jeder Iteration verfügba- ren Entwicklungszeit wird als Puffer für unvorhergesehene Aktivitäten re- serviert, um Dinge wie kritische De- fekte, fehlschlagende Unit- Tests und dringende Unterstützungsanfragen von Kundenseite bedienen zu können. Wenn der Puffer ausgeschöpft ist oder das obere Management die Durchführung ungeplanter Tätigkei- ten einfordert, wird die aktuelle Itera- tion abgebrochen und ein neuer Plan erarbeitet. Assessment- Treffen Die Definition von Scrum spricht davon dass am Ende einer jeden Iteration ein potenzi- ell auslieferungsfähiges Inkrement [des Produkts] vorliegen soll, die tatsächliche Auslieferung aber von verschiedenen ande- ren Faktoren abhängig sein kann. Um fest- zustellen, ob wirklich ein potenziell auslie- ferungsfähiges Inkrement vorliegt, sieht Scrum hier das sogenannte Sprint- Review vor, in dem das Ergebnis des Sprints präsen- tiert wird. Jede Iteration endet mit ei- nem Iteration- Assessment- Treffen, auf dem jedes Teammitglied das Ergebnis seiner Arbeit präsentiert. Als Ergebnis der Treffen muss jedes Team- mitglied das Ergebnis seiner Arbeit präsen- tieren. Sei es in Form eines Dokuments für Aufgaben wie spezifiziere, analysiere oder untersuche oder als Demonstration der entsprechenden Funktionalität, wenn sie im Produkt umgesetzt wurde. Zum Zeitpunkt der Demonstration im As- sessment- Treffen sollten die User- Stories bereits von der Qualitätssicherung (QA) ge- testet und dokumentiert sein. Die Realität zeigt, dass es nicht immer möglich ist, alle Copyright it research research.net Seite 6 / 8

7 Dinge gemeinsam zu dokumentieren, bei- spielsweise dann, wenn die Dokumentation mehrere Features abbilden soll, von denen nur eines bisher in der Entwicklung behan- delt wurde. Hier haben die technischen Au- toren die Möglichkeit, im Assessment- Treffen zu sehen, wie die Funktionalität tat- sächlich aussieht, Termine für Screenshots zu vereinbaren, neue Kapitel für das Benut- zerhandbuch beizusteuern und was sonst nötig sein mag, in die Wege zu leiten. Wir haben als Rahmenbedingung vereinbart, dass alle Features, die in einem Sprint im- plementiert wurden, spätestens am Ende des darauffolgenden Sprints dokumentiert sein müssen. Aus Workflow- Sicht können User- Stories als implemented / implementiert (Programmierung wurde abge- schlossen), done / erledigt (qualitätsgesichert und dokumen- tiert) und veryfied- done / als erledigt bestä- tigt (vom anfordernden Stakeholder als das erkannt, was er angefordert und erwartet hat) rung noch nicht perfekt waren und diese zu bewerten. Darüber hinaus kann man nun zusätzliche Abstimmungsrisiken und Kom- munikationsprobleme besprechen und wei- tere Personen mit einbeziehen, zu denen Abhängigkeiten bestehen, um eben diese deutlich zu machen. Beispiel Polarion ALM Die in dieser Research Note beschriebenen Tipps gelten für alle Unternehmen und werden von Polarion Software selbst so ge- nutzt. Wichtig ist, das es keine starren Vor- gaben gibt, sondern dass eine Wiki- Seite mit einem eingebetteten Script, zur Verfü- gung steht, das diverse Macros nutzt und auf die Polarion API zugreift, um genau die Informationen anzuzeigen, die gerade be- nötigt werden. So kann diese Seite entwe- der so genutzt werden, wie das System ausgeliefert wird (Out- Of- The- Box) oder an lokale Anforderungen angepasst werden, um den aktuellen Prozess abzubilden. Pola- rion ALM wird bereits in der Grundversion mit Projekt- Templates ausgeliefert, die An- wender nutzen können, um das Scrum- Framework in eigenen, vergleichbaren Pro- jekten zu nutzen. gekennzeichnet werden. Für die Assess- ment- Treffen werden nur die Stories aus- gewählt, die als done gekennzeichnet sind. Retrospektive Die Retrospektive ist allgemein der letzte Teil des Assessment- Treffens. In einer idea- len Situation ist dies die Zeit, um zu bespre- chen, wie man den Prozess optimieren kann, um noch mehr Anforderungen inner- halb eines Sprints umsetzen zu können. Häufig nutzt man diese Zeit zudem, um Punkte zu identifizieren, die an einem Pro- zess oder an der Umsetzung einer Anforde- Copyright it research research.net Seite 7 / 8

Am eigenen Leibe Wie Polarion Software Scrum-Tools mit Scrum entwickelt

Am eigenen Leibe Wie Polarion Software Scrum-Tools mit Scrum entwickelt der autor Nikolay Entin (nick.entin@polarion.com) ist Vice President für Forschung & Entwicklung bei Polarion Software. Er verfügt über eine 15-jährige Erfahrung im Software Engineering und ist für alle

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

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

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert. SCRUM-CHECKLISTE Teilen Sie diese Liste an alle Teammitglieder aus. Jeder soll einen Haken an der Stelle setzen, die er für Ihr SCRUM Team als erfüllt ansieht. Anschließend diskutieren Sie über fehlende

Mehr

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

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

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

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

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Scrum in der Praxis (eine mögliche Umsetzung)

Scrum in der Praxis (eine mögliche Umsetzung) Scrum in der Praxis (eine mögliche Umsetzung) ALM Talk, 26. Oktober 2011 Stefan Stettler Ausgangslage Viele Projektbeteiligte Verkauf, Entwickler, PM, Designer, Ergonomen Unterschiedliche Sichten und Vorstellungen,

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

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

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

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

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

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

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

Denn sie wissen nicht was sie tun! Den Überblick über agile Backlogs behalten.

Denn sie wissen nicht was sie tun! Den Überblick über agile Backlogs behalten. 1 Denn sie wissen nicht was sie tun! Den Überblick über agile Backlogs behalten. 2 INHALT Begriffe Backlogmanagement -Board Zusammenfassung 3 BEGRIFFE Backlog Backlog Item Arten von Backlogs 4 BACKLOG

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

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01.

SCRUM. Vertragsgestaltung & Vertragsorientierte Projektdurchführung. Katharina Vierheilig Vorlesung: Juristisches IT-Projektmanagement 08.01. SCRUM Vertragsgestaltung & Vertragsorientierte Projektdurchführung Katharina Vierheilig Vorlesung: Juristisches IT- Agile Softwareentwicklung SCRUM 2 SCRUM Agiles Manifest Individuen und Interaktion Prozesse

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

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

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

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

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

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

Scrum bei der Projektron GmbH

Scrum bei der Projektron GmbH Scrum bei der Projektron GmbH Vor- und Nachteile im Rückblick von 2 Jahren Arbeit mit Scrum Projektron GmbH Softwarehersteller Produkt: Projektron BCS Projektmanagement-Software Gegründet: 2001 Mitarbeiter:

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

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

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

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. 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

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

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand: 23.06.2016 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand: Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben.

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

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

GI Fachgruppentreffen RE 2015

GI Fachgruppentreffen RE 2015 GI Fachgruppentreffen RE 2015 Miteinander reden statt gegeneinander schreiben Lagerfeuer Bundenbach Schmidtburg 2003 von Tiger St.Georg - selbst fotografiert von Tiger St.Georg. Susanne Mühlbauer 1 November

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006

Projektmanager, Scrummaster, SW-Entwickler. Webbasierte Software. Teilweise Medizinprodukt Scrum seit 2006 Überleben mit Scrum Andrea Schulz Hintergrund Projektmanager, Scrummaster, SW-Entwickler Siemens Healthcare Webbasierte Software Produkte (Releases als Projekte) Teilweise Medizinprodukt Scrum seit 2006

Mehr

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003 Agile Software Entwicklung mit Raffael Schweitzer 18. November 2003 Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche Erfolgsfaktoren Fazit Agenda Einleitung Was ist? Wie funktioniert? Einsatzbereiche

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

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

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

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

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

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

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

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

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

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

DevOps in der Praxis. Alexander Pacnik 24.11.2015

DevOps in der Praxis. Alexander Pacnik 24.11.2015 DevOps in der Praxis Alexander Pacnik 24.11.2015 Einführung... DevOps Versuch einer Definition Alexander Pacnik IT Engineering & Operations Project Management inovex GmbH 2 Einführung... DevOps Versuch

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

Softwaretechnik WS 16/17

Softwaretechnik WS 16/17 Softwaretechnik WS 16/17 Übungsblatt 03 Entwicklungsmodelle Scrum-Grundlagen Philipp Wendler 10. November 2016 1 / 30 Aufgabe Das Management des deutschlandweit empfangbaren Fernsehsenders SWT-TV hat erkannt,

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

Planst Du noch oder lebst Du schon (agil)?

Planst Du noch oder lebst Du schon (agil)? Planst Du noch oder lebst Du schon (agil)? IIBA Chapter Summit Salzburg, 11.10.2013 Anton Müller cscakademie.com Copyright CSC Deutschland Akademie GmbH Worum geht es? Gestaltung von Veränderungen in Unternehmen!

Mehr

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm Übersicht Kurze Situationsübersicht Diskussion Prozesse Challenges in der SW-Entwicklung Wie geht Scrum

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

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software SCRUM bei Festo Frank M. Hoyer, House of Software SI-MS/Frank M. Hoyer Scrum bei Festo 15. März 2010 geändert: 16. September 2014, HOY Was ist SCRUM? Scrum ist ein agiles Framework zur Software-Entwicklung.

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

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

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

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014

Meetings in SCRUM. Leitfaden. Stand: 10.11.2014 ^^ Meetings in SCRUM Leitfaden Stand: 10.11.2014 Sitz der Gesellschaften: Cassini Consulting GmbH Bennigsen-Platz 1 40474 Düsseldorf Tel: 0211 / 65 85 4133 Fax: 0211 / 65 85 4134 Sitz der Gesellschaft:

Mehr

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen Thomas Löchte Geschäftsführer Informationsfabrik GmbH Wir produzieren INFORMATION. Konzeption und Architektur Implementierung [ETL,

Mehr

Folie 1. agilemed 2014. Rico Unger 2014 19 Februar. ALM für medizinische Softwareentwicklung WWW.INTLAND.COM

Folie 1. agilemed 2014. Rico Unger 2014 19 Februar. ALM für medizinische Softwareentwicklung WWW.INTLAND.COM Folie 1 agilemed 2014 ALM für medizinische Softwareentwicklung Rico Unger 2014 19 Februar Kurze Vorstellung Folie 2 Rico Unger 10-jährige Erfahrung im MedTech-Bereich Entwickler von Hardware / embedded

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

Software-Dokumentation im agilen Entwicklungsprozess

Software-Dokumentation im agilen Entwicklungsprozess Software-Dokumentation im agilen Entwicklungsprozess Ulrike Müller, Knowledge Manager, SAP AG Monika Pfanner, Knowledge Architect, SAP AG tekom-herbsttagung Wiesbaden, 24. Oktober 2012 SAP und Knowledge

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

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

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

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

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

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

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

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

Lastenheft. Beschreibung des Unternehmens. Ziele der Software-Einführung. Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer

Lastenheft. Beschreibung des Unternehmens. Ziele der Software-Einführung. Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer Lastenheft Einführung einer Software zur Unterstützung eines Scrum-Prozesses in einer Softwareentwicklungsfirma Beschreibung des Unternehmens Allgemeine Daten Name des Unternehmens Softwarentwicklungs

Mehr

barcamp Berthold Barth, Agile Coach Dysfunctional Team Game

barcamp Berthold Barth, Agile Coach Dysfunctional Team Game Berthold Barth, Agile Coach Dysfunctional Team Game Dysfunctional Team Game Scrum Day 2014 07.07.2014 1 Berthold Barth - Agile Coach, Brand Manager, Geek Dad - Certified Scrum Master - Projektleiter -

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

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

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

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

Boosting Requirements Engineering für SCRUM Projekte. Copyright 2010 MaibornWolff et al www.mwea.de

Boosting Requirements Engineering für SCRUM Projekte. Copyright 2010 MaibornWolff et al www.mwea.de Boosting Requirements Engineering für SCRUM Projekte Copyright 2010 MaibornWolff et al www.mwea.de Kennzeichen von SCRUM Projekten Scrum-Projekte werden eingesetzt um schnell und flexibel Projekte umzusetzen.

Mehr

Projekt- Manager. scrum Master Lehrgangsbeschreibung. Verdienst: 72.000 EUR zzgl. Bonus p. a. Ähnliche freie Stellen in Deutschland: ca. 3.000-4.

Projekt- Manager. scrum Master Lehrgangsbeschreibung. Verdienst: 72.000 EUR zzgl. Bonus p. a. Ähnliche freie Stellen in Deutschland: ca. 3.000-4. Projekt- Manager Verdienst: 72.000 EUR zzgl. Bonus p. a. Ähnliche freie Stellen in Deutschland: ca. 3.000-4.000 scrum Master Lehrgangsbeschreibung Stand der Lehrgangsbeschreibung 06.05.16 Seite 1 von 6

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

Testmanagement im agilen Entwicklungsprozess

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

Mehr

Agile Methoden. David Tanzer. Oliver Szymanski

Agile Methoden. David Tanzer. Oliver Szymanski Agile Methoden David Tanzer Oliver Szymanski Ziel von Softwareentwicklung Anforderungen zuverlässig und effizient in lauffähige Software verwandeln. Ziel von Softwareentwicklung Bedürfnisse des Kunden

Mehr

Gelebtes Scrum. Weg vom Management hin zur Führung

Gelebtes Scrum. Weg vom Management hin zur Führung Gelebtes Scrum Weg vom Management hin zur Führung Herausforderungen Was ist Scrum? Wer? Pigs Chicken Bild: http://www.implementingscrum.com/ Nein Danke, ich würde da voll drinstecken, aber du wärest

Mehr

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle IT-Basics 2 DI Gerhard Fließ Vorgehensmodelle Sichtbarkeit Die Sichtbarkeit von Membervariablen und Methoden können durch die folgenden Schlüsselworte geregelt werden: private nur in der eigenen Klasse

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

Agiles ITSM Prozess-Redesign. Dynamik MIT Struktur!

Agiles ITSM Prozess-Redesign. Dynamik MIT Struktur! 12. itsmf Jahreskongress 2012 3./4. Dezember 2012 FUTURE OF ITSM Agiles ITSM Prozess-Redesign Dynamik MIT Struktur! TORSTEN HEUFT MELANIE POPPE-MERFELS QUALITY MANAGER SERVICE MANAGER AGENDA KAPITEL 01_DAS

Mehr

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Agenda 1. Scope, Motivation und Begriffsklärung 2. Modellierung

Mehr

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

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

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt Scrum undprojektmanagement à la GPM Markus Schramm compeople AG Frankfurt GPM scrum ed GPM, Scrum, warum? Projektablauf koordinieren Einheitliches Vorgehen Gemeinsames Verständnis Gemeinsame Sprache Freestyle

Mehr

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN

DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE CHANGE PROCESS DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN DURCHGÄNGIGE SAP CHANGE- UND RELEASE-PROZESSE EINFACH UMSETZEN THEGUARD! SMARTCHANGE I CHANGE PROCESS

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

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

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master,

TFS Customzing. in der Praxis. Thomas Gugler. seit 2005 bei ANECON. .NET seit 2002 (happy bday!) Schwerpunkte: MCPD.Net 4.0, MCTS TFS, Scrum Master, TFS Customzing in der Praxis Thomas Gugler ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com Thomas Gugler seit 2005 bei

Mehr

EFFIZIENTES ENTERPRISE SERVICE MANAGEMENT: FLEXIBEL, ITIL-KONFORM UND OUT OF THE BOX

EFFIZIENTES ENTERPRISE SERVICE MANAGEMENT: FLEXIBEL, ITIL-KONFORM UND OUT OF THE BOX THEGUARD! SERVICEDESK EFFIZIENTES ENTERPRISE SERVICE : FLEXIBEL, ITIL-KONFORM UND OUT OF THE BOX EFFIZIENTES ENTERPRISE SERVICE : FLEXIBEL, ITIL-KONFORM UND OUT OF THE BOX THEGUARD! SERVICEDESK Im Fokus

Mehr

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

Mehr

2 Überblick über den Scrum-Ablauf, die Rollen, Meetings, Artefakte und Prinzipien 17

2 Überblick über den Scrum-Ablauf, die Rollen, Meetings, Artefakte und Prinzipien 17 xiii 1 Historie, Vorteile und Eignung von Scrum 1 1.1 Historie............................................... 1 1.1.1 Scrum-Teams nach Nonaka und Takeuchi.............. 1 1.1.2 Erste Scrum-Projekte in

Mehr