Agile Sofwareentwicklung mit XP

Größe: px
Ab Seite anzeigen:

Download "Agile Sofwareentwicklung mit XP"

Transkript

1 Agile Sofwareentwicklung mit XP Lukas Feuz und Marc Bettler Fachhochschule Technik und Informatik CH-2501 Biel, Schweiz Abstract: Bei Softwareentwicklungsprojekten sind die Anforderungen an das Endprodukt häufigen Änderungen unterworfen. Da bei Sequentiellen Prozessen wie dem Wasserfallmodell nur sehr schlecht auf diese Änderungen reagiert werden kann, entstehen vielfach erhebliche Probleme. Aus dieser Problematik heraus entstanden die Grundprinzipien der agilen Softwareentwicklung. Diese Prinzipien wurden im sog. agilen Manifest zusammengefasst und sollten die Softwareentwicklung im Allgemeinen verbessern. Schliesslich entstanden agile Softwareentwicklungsprozesse, welche auf dem agilen Manifest aufbauen. XP ist ein solcher agiler Entwicklungsprozess. Bei der Entwicklung mit XP wird bewusst auf aufwändige Dokumentationsarbeit verzichtet, stattdessen werden täglich kurze Meetings abgehalten. Die Produktivitätssteigerung wird vor allem durch mehr Freude an der Arbeit und weiteren psychologischen Effekten erzielt. Zusätzlich wird versucht durch Praktiken wie Pair-Programming die Qualität des Endproduktes zu steigern.

2 2 Lukas Feuz und Marc Bettler Agile Sofwareentwicklung Das agile Vorgehen in der Softwareentwicklung ist eine Alternative zu den traditionellen Softwareentwicklungsprozessen, wie z. B. das Wasserfallmodell oder dem V-Modell, die immer mehr als zu schwergewichtig, zu dokumentenlastig und zu bürokratisch angesehen werden. Agile Prozesse verfolgen einen anderen Ansatz. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Ziel der agilen Softwareentwicklung ist es, den Softwareentwicklungsprozess zu optimieren. Grundsätzlich soll dies durch die Verschlankung des gesamten Prozesses erfolgen. Dafür rückt die agile Softwareentwicklung die Projektziele, den Kunden, sowie die Werte, Prinzipien und Methoden für die Zielerreichung in den Mittelpunkt. Wichtigstes Ziel im gesamten Prozess ist eine funktionierende Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese Software. Diesem Ziel ist alles andere untergeordnet, wie eine möglichst detaillierte Planung, vollständige Spezifikationen, umfassende Dokumentationen oder eine ausgereifte, technisch einwandfreie Architektur. Ein agiler Prozess ist sehr kommunikationsintensiv, soll leicht umzusetzen und flexibel anzupassen sein, er soll leichtgewichtig und dynamisch ablaufen. Um mehr über die agile Softwareentwicklung an sich zu erfahren, möchten wir auf die Arbeit von Fabian Chanton und Sven Schumacher über Agile Sofwareentwicklung mit Scrum verweisen.

3 Agile Sofwareentwicklung mit XP 3 extreme Programming Bestandteile XP besteht aus Werten, Prinzipien und Praktiken. Die Zusammenstellung dieser Bestandteile orientiert sich an Kent Beck. Es existiert keine eindeutige Definition von XP, wobei allerdings die Diskussionen und Ausführungen der Originalverfasser XP am stärksten prägen. Werte XP definiert vier Werte die von zentraler Bedeutung sind: Kommunikation, Einfachheit, Feedback und Mut. Laut XP ist es, ohne stetige Beachtung dieser Werte, nicht möglich erfolgreich Software zu entwickeln. Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess der Softwareentwicklung selbst fordert ein hohes Mass an Kommunikation. Ein stetiger Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden wird vorausgesetzt. Die Tatsache, dass auch Personen zu Wort kommen, die bei der gerade diskutierten Sache keine Spezialisten sind, bringt mehr Feedback und Verantwortungsgefühl gegenüber dem Produkt mit sich. Stetige Kommunikation mit dem Kunden, Aufnahme seines Feedbacks und Erfüllung seiner Wünsche ist Wichtiger als formale Preisverhandlungen. XP sucht die möglichst einfache und schnelle Lösung von Problemen. Dies wird in erster Linie dadurch erreicht, dass während einer Iteration das Problem den Fokus des gesamten Teams geniesst und so mögliche Fehlerquellen schneller ans Licht kommen. Des Weiteren werden Fehler auch vermieden, wenn stets die einfachste Lösung realisiert wird. Wichtig bei der Kommunikation ist, dass sich jeder zu Wort meldet. Auch Entwickler sollen die Kommunikation offener gestalten und darauf hinweisen, wenn eine Anforderung nicht in einer Iteration umgesetzt werden kann. Mit diesen Kommunikationsmitteln sollen herkömmliche Störfaktoren, wie etwa den natürlichen Konkurrenzkampf innerhalb des Teams, minimiert und die Qualität des Endproduktes gesteigert werden. Prinzipien Die Brücke zwischen den abstrakten Werten und konkret anwendbaren Praktiken bilden die Prinzipien von XP. In der ersten Auflage wurden diese mit den fünf Grundprinzipien deklariert: Unmittelbares Feedback Ein Feedback sollte so schnell wie möglich eingeholt werden. Aus der Lernpsychologie weiss man, dass der zeitliche Abstand zwischen Aktion und

4 4 Lukas Feuz und Marc Bettler Feedback eine entscheidende Rolle für den Lernerfolg spielt. Je kürzer die Differenz, desto grösser der Lernerfolg. Gleichzeitig wird durch unmittelbares Feedback verhindert, dass unnötig lange in die falsche Richtung gedacht oder gearbeitet wird. Einfachheit anstreben Einfache Lösungen haben etliche Vorteile gegenüber komplizierten Lösungen. Sie sind schneller zu erarbeiten, so dass schneller ein Feedback zurückkommt. Einfache Lösungen sind einfacher zu verstehen und damit leichter zu kommunizieren. Desweiteren sind einfache Lösungen schneller änderbar, wodurch flexibler auf geänderte Gegebenheiten reagiert werden kann. Inkrementelle Veränderungen Auch wenn Einfachheit angestrebt wird, werden Softwaresysteme im Laufe der Entwicklung so komplex, dass Änderungen unerwartete Seiteneffekte verursachen können. Wenn aber immer nur kleine Veränderungen vorgenommen werden, bleiben diese Seiteneffekte überschaubar. Veränderungen wollen Fortschritt bedeutet Veränderung. Nur, wer Veränderungen will, wird mit Fortschritt belohnt. Man muss neue Dinge wagen und Fehlschläge riskieren, immer in dem Bewusstsein, dass man aus Fehlern lernt. Qualitätsarbeit Kein Softwareentwickler programmiert gerne schlechte Software. Softwareentwickler liefern gerne Qualitätsarbeit. Das erhöht die Arbeitszufriedenheit und damit wiederum die Produktivität. In einem Projekt muss daher die Möglichkeit geschaffen werden, Qualitätsarbeit abzuliefern. Allerdings muss klar definiert sein, wer bestimmt, ob eine hohe oder niedrige Qualität vorliegt. Softwareentwickler haben ihre eigenen Qualitätsmassstäbe, welche nicht mit denen der Anwender verwechselt werden dürfen. Letztlich geht es darum, für die Anwender hochqualitative Software zu entwickeln. Unmittelbares Feedback durch die Anwender hilft, möglichst häufig die Gebrauchsqualität bewerten zu lassen und Erfolgserlebnisse zu produzieren. Traditionelle XP-Praktiken Einfaches Design Es soll die einfachste Lösung angestrebt werden. Also diejenige, die genau das Gewünschte oder Geforderte erreicht und nicht mehr. Allgemeine, generische Lösungen oder vorbereitende Massnahmen für spätere Erweiterungen werden bewusst vermieden. Hierbei sind die Akronyme KISS ( Keep it small and simple ) und YAGNI ( You ain t gonna need it ) vorbereitet.

5 Agile Sofwareentwicklung mit XP 5 Pair-Programming XP setzt auf das Vier-Augen-Prinzip und setzt zwei Programmierer vor einen Computer. Der eine codiert (der Driver), der andere plant und denkt mit (der Partner). Die Rollen werden regelmässig vertauscht und die Partner gewechselt. Diese Methode steigert den Wissenstransfer und fördert bei Anfängern das Lernen von Spezialisten. Zugleich mindert dieses Vorgehen die Gefahr, dass das Projekt abhängig von einem einzelnen ist. Durch ständiges Codereview wird die Qualität des Codes optimiert und Fehler werden schneller gefunden. Testgetriebene Entwicklung Bei der testgetriebenen Entwicklung werden zuerst die Modultests geschrieben und erst dann wird die eigentliche Funktionalität programmiert. Dadurch befasst sich der Entwickler früh mit dem Design und erkennt Fehlerquellen schon bevor sie existieren. Die Tests werden nach jedem Zwischenschritt durchgeführt und liefern Feedback über den Entwicklungsstand. Es wird zwischen Regressionstest und Modultest unterschieden. Während Modultests einzelne Module testen, prüft ein Regressionstest die kollektive Funktionalität aller, also auch von alten, unveränderten Modulen einer der früheren Iterationen. Ebenfalls sind Performancetests üblich, die Leistungs- und Geschwindigkeitsmerkmale gegenüber den geforderten Werten prüfen. Refractoring Ständige Architektur-, Design- und Codeverbesserungen fördert die Qualität des Codes und ebenfalls das frühzeitige Erkennen von Anti-Patterns. XP befürwortet die Existenz von noch nicht perfektem Code. Stattdessen sind alle Teile einem stetigen Review unterworfen und die Behebung von Fehlern wird sofort durchgeführt. Alternativ kann ein Fehler auch als Bug definiert werden, um ihn in einer späteren Iteration zu beheben. Planning Game Hinter dem Begriff Planning Game versteckt sich eine Diskussionsrunde mit Entwicklungsmannschaft und Kunden. Hier werde neue Versionen spezifiziert und der Aufwand deren Umsetzung abgeschätzt. Gemeinschaftliches Code Eigentum Aktivitäten und Aufgaben werden zunächst nicht an Einzelpersonen verteilt, sondern an das ganze Team. Laut Methodik existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Pair-Programming und wechselnde Entwicklergruppen sollen entgegenwirken, sodass einzelne Personen Teile als ihr Eigentum betrachten. Fortlaufende Code Integration Das Zusammenführen einzelner Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen. Laut XP wird die Routine immer höher, je öfter Integriert wird. Dies hat zur Folge, dass Fehler früher aufgedeckt werden und die

6 6 Lukas Feuz und Marc Bettler mit der Integration verbundenen Kosten beinahe auf Null reduziert werden, da die Integration zu einem täglichen Schritt gehört. Kundeneinbeziehung XP versucht den Kunden vollständig in den Entwicklungsprozess zu integrieren und möglichst eng mit einzubeziehen. Der Kunde gibt die Iterationsziele mit einer Auswahl der zu realisierenden User-Stories vor und hat kurz danach die Möglichkeit Akzeptanztests durchzuführen. Story-Cards dienen als Medium, um die kurzen Anwendungsfälle in Form von User-Stories aufzunehmen. Der Kunde muss immer anwesend oder erreichbar sein. Alternativ können anstatt User-Stories und Story- Cards auch CRC-Modelle und CRC-Cards verwendet werden. Keine Überstunden (40 Stundenwoche) Um die Freude an der Arbeit, die Konzentration der Entwickler und vor allem die Qualität des Produkts nicht zu gefährden, werden Überstunden bei XP nicht geduldet. Nachweislich sinkt die Produktivität eines Entwicklers durch Überstunden. Arbeit ausserhalb der regulären Arbeitszeit wird im Einzelfall zwar geduldet, keinesfalls aber besonders entlohnt oder erwartet. Überstunden zeugen normalerweise von Planungsfehlern. Kurze Releasezyklen (Iterationen) Um Fehler zu vermeiden und vor allem regelmässige Feedbacks vom Kunden zu erhalten baut XP auf kurze Iterationen. Eine Iteration wird in XP als eine zeitlich und fachlich in sich abgeschlossene Einheit definiert. Metapher Da in Softwareprojekten Missverständnisse zwischen Kunde und Entwicklungsmannschaft ein häufig gesehenes Problem darstellen, versucht XP mit der Metapher entgegen zu wirken. Das Hauptproblem besteht hier darin, dass der Entwickler Mühe mit der Fachsprache des Kunden hat und umgekehrt. XP sucht also eine inhaltlich ähnliche Alltagsgeschichte, eine sog. Metapher, die von beiden Seiten verstanden wird. Ein zusätzliches Glossar kann dieses Problem beinahe beseitigen. Coding Standards Das Team hält sich bei der Programmierarbeit an Standards, die in einer Programming Guideline definiert werden. Es geht um die Prinzipien, wie Variable, Klassen und Methoden benannt werden und um allgemeine Coding Standards. Laut XP ist es nur mit solchen Standards möglich, dass jeder Programmierer in allen Bereichen der zu entwickelnden Software arbeiten kann.

7 Agile Sofwareentwicklung mit XP 7 extreme Programming, die zweite Auflage Kent Beck hat Ende 2004 die zweite Auflage des XP Manifests extreme Programming explained veröffentlicht. Während die XP Werte nur mit dem Wert Respekt ergänzt wurden, sind die Prinzipien und die Praktiken deutlich verändert worden. Für die Änderungen gibt es vier Ursachen: Präzisierungen: So ist nicht mehr von kurzen Releasezyklen die Rede, sondern die Zeiträume für Zyklen werden genau definiert (Wochenzyklus und Quartalszyklus) Vereinfachungen: Die XP Technik der Metapher haben nur wenige verstanden, geschweige denn angewendet. Daher gibt es die Metapher nicht mehr als eigenständige Technik. Erfahrungen: Es ist deutlich geworden, dass XP keinen Freiraum für Weiterbildung und Reflexionen lässt. Es haben sich dazu einige XP Erweiterungen herausgebildet, die sich nun in der Technik Freiraum wiederfinden. Neue Herausforderungen: Auch für die Teams, die XP bereits erfolgreich und komplett einsetzen, hat sich Kent Beck einige neue Herausforderungen ausgedacht. Um die zweite Auflage von XP zu verstehen, ist ein grundlegendes Verständnis von XP vorausgesetzt. Wer XP bereits kennt, muss nicht komplett umlernen, um die XP Neuerungen anwenden zu können. Die grundsätzlichen Ideen sind gleich geblieben. Sie kommen teilweise nur in anderen Verpackungen daher. Bestandteile Werte Die vier Werte Kommunikation, Feedback, Einfachheit, und Mut wurden um den Wert Respekt ergänzt. Jeder Projektbeteiligte respektiert die anderen Projektbeteiligten. Keiner ist mehr oder weniger wert als andere. Ausserdem verweist Kent Beck explizit darauf, dass die fünf Werte um projektspezifische Werte ergänzt werden können. Prinzipien Die Prinzipien wurden fast vollständig neu formuliert. Es gibt nun 14 Prinzipien, die eine Brücke bilden zwischen den abstrakten Werten und den konkret anwendbaren Praktiken. Diese Prinzipien sollten immer Berücksichtigung finden.

8 8 Lukas Feuz und Marc Bettler Menschlichkeit Softwareentwicklung ist eine menschliche Aktivität, bei der die sozialen Beziehungen der Projektbeteiligten eine entscheidende Rolle spielen. Die Projektorganisation darf nicht nur auf geschäftlichen Interessen ausgerichtet sein. Die geschäftlichen Interessen müssen ausbalanciert werden mit den Bedürfnissen der Projektmitglieder. Wirtschaftlichkeit Softwareprojekte müssen wirtschaftlich sein, indem sie mehr Geld einbringen, als sie kosten, die Kundenbindung erhöhen und neue Marktsegmente erschliessen. Softwareprojekte, die sich nicht rechnen, sind niemals ein Erfolg. Beidseitiger Vorteil Kent Beck nennt den gegenseitigen Vorteil als das wichtigste Prinzip in XP. Jede Aktion soll jedem Betroffenen einen Vorteil verschaffen (Win-Win-Situation). Es ist leicht, Probleme zu lösen, wenn dabei Nachteile für die Betroffenen akzeptiert werden. Allerdings beeinträchtigen solche Lösungen die Arbeitsleistung der Betroffenen. Selbstgleichheit Lösungen, die an einer Stelle funktionieren, lassen sich häufig auf andere Kontexte übertragen, auch auf ganz andere Grössenordnungen. Verbesserung Nichts ist perfekt. Alles kann und muss ständig verbessert werden. Insbesondere sollte man sich nicht dadurch von der Arbeit abhalten lassen, dass man nicht weiss, wie die Lösung aussieht. Durch das Umsetzen von nicht perfekten Lösungen lernt man viel, und dadurch kommt ein kontinuierlicher Verbesserungsprozess in Gang. Vielfältigkeit Menschen sind sehr verschieden. Die Vielfältigkeit ist manchmal unangenehm, aber sie birgt auch grosse Potenziale. XP anerkennt die Vielfältigkeit der Projektmitglieder und versucht, diese in bessere Lösungen einfliessen zu lassen. Wenn es zwei unterschiedliche Entwurfsvorschläge gibt, ist das kein Problem, sondern eine Chance. Reflexion Gute Teams machen nicht nur gute Arbeit, sie reflektieren auch über ihre Arbeit. Sie denken darüber nach, wie und warum sie ihre Arbeit machen, und können so ihre Lösungen verbessern.

9 Agile Sofwareentwicklung mit XP 9 Fluss Die Aktivitäten in einem XP Projekt liefern einen ständigen Fluss an Software, die immer ein Stückchen besser wird. Dieser Fluss steht im Gegensatz zu Phasenmodellen, in denen grosse Ergebnisbrocken in langen Zeitabständen geliefert werden. Gelegenheiten wahrnehmen Klassisch werden Probleme gelöst, um zu überleben. In XP werden Probleme als Chancen für Veränderung aufgefasst. Redundanzen Es soll keine Redundanzen im Quellcode geben, aber im Entwicklungsprozess. Relevante Probleme sollen nicht nur durch einen Mechanismus überwacht werden, sondern durch mehrere. So ist sichergestellt, dass ein Problem auch dann gelöst wird, wenn einzelne Mechanismen ausfallen. In XP wird beispielsweise das Problem von Programmfehlern durch Komponententests, Akzeptanztests und Programmieren in Paaren minimiert. Fehlschläge hinnehmen Fehlschläge lassen sich nicht vermeiden und sind sogar hilfreich, wenn man etwas daraus lernt. Insbesondere ist es besser, etwas auszuprobieren, als lange Diskussionen zu führen. Qualität Man kann die Qualität nicht senken, um Kosten zu sparen oder einen frühen Termin zu halten. Qualitätsarbeit ist die Voraussetzung dafür, stolz auf seine Arbeit zu sein. Nur Entwickler, die stolz auf ihre Arbeit sind, sind mit vollem Engagement dabei. Kleine Schritte Jede Veränderung wird in kleinen Schritten vorgenommen, um Risiken zu reduzieren. Die Schritte erfolgen in schneller Folge, so dass trotzdem eine hohe Entwicklungsgeschwindigkeit resultiert. Akzeptierte Verantwortung Verantwortung kann nicht zugewiesen werden, sie muss akzeptiert werden. Zusammen mit der Verantwortung kommt die Autorität. Ein Entwickler, der sich eine User Story nimmt, akzeptiert die Verantwortung für das Design, die Programmierung und das Testen dieser Story. Damit hat er die Autorität, über das Design für die Story zu entscheiden.

10 10 Lukas Feuz und Marc Bettler Praktiken In der zweiten Auflage von XP unterscheidet Kent Beck zwischen Primärpraktiken und Folgepraktiken. Die Folgepraktiken setzen die Primärpraktiken voraus. Der Einsatz der Folgepraktiken, ohne dass die Primärpraktiken funktionieren, kann sogar gefährlich sein. Primärpraktiken Beieinander sitzen Alle Projektbeteiligten sollen möglichst nah beieinander sitzen, idealerweise in einem Raum. Das erleichtert die direkte Kommunikation und reduziert damit Reibungsverluste. Komplettes Team Das XP-Team soll alle Qualifikationen enthalten, die für das Projekt erforderlich sind. Damit sind technische aber auch fachliche Qualifikationen gemeint. Dadurch kann das Team schnell voranschreiten, ohne auf die Verfügbarkeit von externen Ressourcen warten zu müssen. Informative Arbeitsumgebung Die Arbeitsumgebung des Teams soll über den aktuellen Projektstand informieren. Das betrifft die noch offenen Aufgaben und den Zustand des Systems. Pair-Programming Das Programmieren in Paaren ist schon immer eine der auffälligsten XP-Techniken gewesen. Sie bleibt unverändert in der zweiten Auflage von Kent Beck. Stories Die Anforderungen werden in einem XP-Projekt als informelle Geschichten (Stories) aufgeschrieben. Während XP in der ersten Auflage forderte, dass die Anforderungen immer vom Kunden zu schreiben seien, lässt XP jetzt mehr Flexibilität zu. Zunächst ist nur wichtig, dass Stories existieren. Dass diese von einem Kunden stammen sollten, wird erst mit der Folgetechnik "Echte Kundenbeteiligung" gefordert. Zyklen Eine Iteration dauert eine Woche, ein Release ein Quartal (3 Monate).

11 Agile Sofwareentwicklung mit XP 11 Freiraum Entwickler brauchen zwischendurch Zeit, um sich mit den Neuerungen ausserhalb des Projekts vertraut zu machen. Ansonsten werden sie schnell vom technologischen Geschehen abgehängt. Sie sind dann im nächsten Projekt weniger gut einsetzbar. Zehn-Minuten-Build Es darf maximal zehn Minuten dauern, das Projekt zu übersetzen und die Tests auszuführen. Diese Forderung mag in grossen Projekten unerfüllbar scheinen. Mit einer geschickten Aufteilung in Komponenten kann man der Forderung aber auch in grossen Projekten sehr nahe kommen. Dann wendet man die Forderung auf jede Komponente an. Das Zusammenbauen der Gesamtanwendung kann dann wieder länger dauern. Kontinuierliche Integration Diese Technik bleibt unverändert. Testgetriebene Entwicklung Das Testen lag immer schon im Zentrum von XP. Kent Beck präzisiert diese Technik noch. Tests werden vor dem zu testenden Code geschrieben, und die Tests müssen automatisiert ausführbar sein. Inkrementeller Entwurf Der Softwareentwurf soll inkrementell erfolgen, also schrittweise entlang der Anforderungen. Der Entwurf soll immer nur die nächsten, konkret bekannten Anforderungen berücksichtigen. Folgepraktiken Echte Kundenbeteiligung Wenn das Team die Arbeit der Stories und den inkrementellen Entwurf beherrscht, sollte ein echter Kunde integriert werden. Team-Kontinuität Es ist in vielen Organisationen gängige Praxis, dass Entwickler parallel in mehreren Projekten arbeiten. Das erhöht die Kommunikationsaufwände, und die Entwickler müssen häufig einen Kontextwechsel vollziehen. Beides reduziert ihre Produktivität deutlich. Alle Projektmitglieder sollen 100% ihrer Arbeitszeit im Projekt verbringen. Die personelle Fluktuation im Projekt sollte minimiert werden. Häufiger Personalwechsel bringt hohen Kommunikations- und Einarbeitungsaufwand mit sich.

12 12 Lukas Feuz und Marc Bettler Schrumpfende Teams Hier geht es darum, die Produktivität von XP-Projekten zu erhöhen mit dem Ziel, einen Entwickler freizusetzen. Dieser Entwickler kann dann in einem anderen Team mitarbeiten und seine Erfahrungen aus dem XP-Projekt in das andere Projekt transferieren. Ursprungsursachen-Analyse Dabei geht man einem Problem systematisch auf den Grund, um die Ursache des Problems zu identifizieren und zu beseitigen. Die Ursprungsursachen-Analyse kann man nur durchführen, wenn man sehr wenige Probleme hat oder nur ausgesuchte Probleme analysiert. Gemeinsamer Code Jeder Entwickler darf den kompletten Quellcode verändern. Diese Technik ist eine Folgetechnik, weil sie durchaus Gefahren birgt. Wenn sich das Team nicht gemeinsam verantwortlich fühlt, führt gemeinsamer Code schnell zur Verwilderung der Systemstruktur. Code und Tests Ausser dem Quellcode und den Tests werden keine weiteren Dokumentationen erstellt oder gepflegt. Der Code soll seinen Zweck kommunizieren. Was dann noch an Dokumentation fehlt, wird durch den Test bereitgestellt. Eine Codebasis Es gibt nur eine Codebasis. Branches sind nur kurzzeitig erlaubt. Auch diese Technik birgt Gefahren. Nur wenn die Fehlerzahl sehr gering ist, kann man auf Branches verzichten. Bei hoher Fehlerzahl auf Branches zu verzichten, führt zu instabilen Releases. Tägliche Ausbreitung Der aktuelle Systemstand soll täglich an die Anwender verteilt werden. Diese Technik muss bei der Projektplanung berücksichtigt werden. Wenn die Anwender jeden Tag ein System vorfinden, das ganz anders zu benutzen ist als das vom Vortag, werden sie schnell auf die Barrikaden gehen. Neue Anforderungen müssen so eingeplant werden, dass die Anwender nicht bei ihrer Arbeit behindert werden. Vertrag mit verhandelbarem Umfang Es wird kein klassischer Festpreisvertrag vereinbart, sondern ein Vertrag mit festem Budget und verhandelbarem Funktionsumfang.

13 Agile Sofwareentwicklung mit XP 13 Bezahlung pro Benutzung Der Kunde zahlt das System nicht pro Release, sondern zahlt Funktionen pro Benutzung. Dadurch ziehen Kunde und Softwareentwickler bei der Entwicklung an einem Strang. Der Kunde kann seinen Geschäftswert an Einzelfunktionen binden. Eine häufige Benutzung der Funktionen generiert für den Kunden hohen Geschäftswert. Gleichzeitig werden Umsätze für die Softwareentwickler generiert. Die Entwickler versuchen also, das System so zu verbessern, dass die geschäftswertgenerierenden Funktionen häufiger verwendet werden. Rollen Damit das Funktionsprinzip von XP auch problemlos funktioniert müssen bestimmte Rollen im Team besetzt sein. Die 4 wichtigsten sind hier sehr kurz beschrieben: Der Programmierer Im Gegensatz zu herkömmlichen Softwareentwicklungsprogrammen besteht seine Arbeit nicht nur darin, dem Computer zu verstehen zu geben, was er will, sondern muss auch mit anderen kommunizieren können. Normalerweise sind Programmierfreaks nicht sehr kommunikativ, beim Extreme Programming ist die Kommunikation nur schon aufgrund des Programmierens in Paaren das A und O. Der Kunde Ein Kunde muss die UserStorys schreiben und bei Fragen der Programmierer gewisse Geschäftsentscheidungen treffen. Er muss genau wissen was für ihn oberste Priorität hat, aber, und das ist fast wichtiger, er muss auch Meinungen der Programmierer annehmen können. Dies bedeutet bei einem engen Terminplan, nachzugeben und unwichtige Systemanforderungen nach hinten verschieben zu können. Der Kunde muss ausserdem in der Lage sein, je nach dem auch mit Hilfe des Teams, Funktionstests zu schreiben. Bei einem fehlenden Tester wird diese Rolle dem Kunden zugeschrieben. Der Terminmanager Der Terminmanager verhilft auf Grund seiner Erfahrung zu genauen Aufwandabschätzungen. Es liegt ausserdem an ihm zu entscheiden, ob das Team den Liefertermin einhalten kann, oder ob etwas geändert werden sollte. Er führt Protokoll über die Funktionstests und soll die Teammitglieder hin und wieder daran erinnern, wie lange sie bereits an einer Aufgabe arbeiten. Der Coach Der Coach ist das Mitglied mit der meisten Erfahrung im Team. Es liegt an ihm dafür zu sorgen, dass das Team nicht eine falsche Richtung einschlägt. Ein guter Coach zeigt dem Team allerdings nicht, was es falsch gemacht hat, sondern bringt das Team darauf, es selbst zu sehen. Es ist nicht unbedingt notwendig, dass der Coach ein

14 14 Lukas Feuz und Marc Bettler Technikfreak ist, soziales Verständnis ist als Coach wichtiger. Je reifer das Team, umso weniger Arbeit hat ein Coach. Anwendungsszenario Nachdem die für XP relevanten Begriffe geklärt sind und ein Überblick über die Prinzipien und Praktiken gegeben wurde, wird in diesem Abschnitt das Vorgehen von XP anhand eines Anwendungsbeispiels verdeutlicht. Zu Begin des Projekts treffen sich Programmierer, der Coach, der Terminmanager und der Kunde zu einem ersten Planning Meeting. Hier werden die User Storys erstellt und es wird im Kollektiv entschieden, welche in der nächsten Iteration implementiert werden sollen. Bei der Entscheidung werden Faktoren wie die Wichtigkeit, Aufwand und andere Prioritäten miteinbezogen. Sobald klar ist, was zu tun ist, werden die Programmierer in Zweierteams aufgeteilt. Nun beginnt die eigentliche Arbeit. Wichtig ist hier, dass sich jedes Teammitglied an die Prinzipien und Praktiken von XP hält. Der Coach behält sich das Recht vor, Teammitglieder auf Verstosse hinzuweisen. Jeden Tag trifft sich die gesamte Entwicklermannschaft zu einem Daily Meeting. Ein solches dauert ca. 15Min. und soll helfen Probleme zu lösen, Absprachen mit dem Kunden zu treffen und natürlich den aktuellen Projektstand abzuklären. Je nach Vorgabe werden hier auch gleich die Programmiererteams, die ja nach XP möglichst oft ändern, gewechselt. Ist eine Iteration abgeschlossen (normalerweise 1 Monat), so wird ein Build erstellt und die Entwicklermannschaft trifft sich wieder zu einem Planning Meeting. Die Userstorys werden ausgewählt und der Entwicklungsprozess schreitet wie oben voran. Sind keine unbearbeiteten Userstorys vorhanden, so gilt das Projekt als abgeschlossen. Für die erfolgreiche Entwicklung steht im Vordergrund, dass die von XP definierten Werte, Praktiken und Prinzipien stets eingehalten werden. So müssen Interventionen durch den Coach, den Kunden oder den Terminplaner immer in den dafür vorgesehenen Meetings vollzogen werden. Laut XP ist die Wirkung einer Intervention so am grössten. Wann XP nicht eingesetzt werden kann XP eignet sich nicht für die folgenden Fälle in einer Unternehmenskultur, bei der die Teams genaue Vorgaben zum Vorgehensmodell bekommen, z.b. wenn zuerst eine ausführliche Spezifikation erstellt werden muss wenn ein zu hoher Erfolgsdruck herrscht, oder nicht erfüllbare Aufgaben gestellt werden bei Teams mit mehr als 10 Mitgliedern wenn Technologien im Einsatz sind, die die flache Kostenkurve für spätere Änderungen nicht ermöglichen, z.b. Entwicklung von Hardware wenn Build und Test nicht innerhalb kurzer Zeit durchgeführt werden können, z.b. bei langen Compilierzeiten

15 Agile Sofwareentwicklung mit XP 15 falls kein Kunde vor Ort zur Verfügung steht wenn die räumlichen Gegebenheiten ungünstig sind, z.b. bei vielen kleinen weit voneinander entfernten Räumen Fazit XP stellt ein Software-Entwicklungsprozess dar, welcher sich auf einfachen, klaren Prinzipien, Methoden und Werten abstützt. Im Vordergrund stehen Prinzipien und Methoden für die Zielerreichung in den Mittelpunkt. Wichtigstes Ziel im gesamten Prozess ist eine funktionierende Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese Software. In der zweiten Auflage vom 2004 hat Kent Beck die Prinzipien und Methoden stark neuen Erkenntnissen angepasst. XP mit einigen Anpassungen könnte sich gut für studentische Projekte eignen.

16 16 Lukas Feuz und Marc Bettler Glossar Akzeptanztest Ein Abnahmetest, Akzeptanztest oder auch User Acceptance Test (UAT) ist ein Test der gelieferten Software durch den Kunden. Oft sind Akzeptanztests Voraussetzung für die Rechnungsstellung. Dieser Test kann bereits auf der Produktivumgebung mit Echtdaten durchgeführt werden. Bei einem solchen Test wird das Blackbox Verfahren angewendet, d. h. der Kunde betrachtet nicht den Code der Software, sondern nur das Verhalten der Software bei spezifizierten Handlungen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung, etc.). Eine Abnahme kann aber auch aus einem Review der Testprotokolle des Systemtests bestehen. Anti-Pattern Ein Anti-Pattern bezeichnet in der Softwareentwicklung ein häufig anzutreffender schlechter Lösungsansatz eines Problems. Es ist das Gegenstück zum Entwurfsmuster (Pattern). Integrationstest Integrationstest bzw. Interaktionstests testet die Zusammenarbeit voneinander abhängiger Komponenten. Komponententest Der Komponententest, Modultest oder Unit Test ist ein Test auf der tiefsten Ebene. Dabei werden einzelne Komponenten auf korrekte Funktionalität getestet. Häufig wird der Modultest durch den Softwareentwickler durchgeführt. Die Testobjekte sind Module, Units oder Klassen. Systemtest Der Systemtest ist die Testphase, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht funktionale Anforderungen) getestet wird. gewöhnlicherweise findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt. User Story Eine User Story ist eine in Alltagssprache formulierte Softwareanforderung. Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze.

17 Agile Sofwareentwicklung mit XP 17 Quellennachweis extreme Programming, 2., überarbeitete und erweiterte Auflage von Henning Wolf, Stefan Roock und Martin Lippert

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design

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

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

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

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

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

Mehr

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

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825

Extreme Programming. Universität Karlsruhe (TH) Fakultät für Informatik Lehrstuhl für Programmiersysteme. Forschungsuniversität gegründet 1825 Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Extreme Programming Agiles Manifest Individuen und Interaktion wichtiger als Prozesse und Werkzeuge Laufende Software wichtiger als vollständige

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

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

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

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

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

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert

extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis dpunkt.verlag Henning Wolf Stefan Roock Martin Lippert Henning Wolf Stefan Roock Martin Lippert extreme Programming Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis 2., überarbeitete und erweiterte Auflage dpunkt.verlag 1 Einleitung 1 1.1 Die

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

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

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

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

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Agile Softwareentwicklung Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger Inhalt 1. Klassische Entwicklungstechnik 2. Agile Entwicklungstechnik - Allgemeines 3. Agiles Manifest

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

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

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

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

Mehr

Test-Driven Developement Eine Einführung

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

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

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

Mehr

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung

Seminar: Softwareentwicklung in der Wissenschaft. Agile Softwareentwicklung Seminar: Softwareentwicklung in der Wissenschaft Agile Softwareentwicklung Benjamin Pöpel Fakultät für Mathematik, Informatik und Naturwissenschaften Fachbereich Informatik Betreuer: Christian Hovy 23.

Mehr

3. Vorgehensmethoden/Prozessmodelle

3. Vorgehensmethoden/Prozessmodelle 3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen

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

Karlsruher Entwicklertag 2013. Coding Dojos im Unternehmen

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

Mehr

Testen im Software- Entwicklungsprozess

Testen im Software- Entwicklungsprozess Technologie-Event 2006 Testen im Software- Entwicklungsprozess W.Lukas, INGTES AG Was nicht getestet wurde, funktioniert nicht. -- R.Güdel (ca. 1998) Seite 2 Was sollen wir tun? Anomalien & Defekte von

Mehr

MSP: Methoden des Software-Entwicklungsprozesses

MSP: Methoden des Software-Entwicklungsprozesses WS 2005/06 Mastermodul CS 5002 MSP: Methoden des Software-Entwicklungsprozesses Teamentwicklung extreme Programming Projekttagebuch Prof. Dr. Klaus Quibeldey-Cirkel Fachhochschule Gießen-Friedberg Forming

Mehr

Ganzheitliches IT-Projektmanagement

Ganzheitliches IT-Projektmanagement Ganzheitliches IT-Projektmanagement Kapitel 2 nach dem Buch: Ruf, Walter; Fittkau, Thomas: "Ganzheitliches IT-Projektmanagement" Wissen - Praxis - Anwendungen R. Oldenbourg Verlag München - Wien 2008;

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Grundprinzipien der agilen Softwareentwicklung

Grundprinzipien der agilen Softwareentwicklung Grundprinzipien der agilen Softwareentwicklung Marie Claire Dzukou 38539 Natali Brozmann 40464 Wintersemester 14/15 1 Inhaltsverzeichnis 1 Agile Softwareentwicklung 3 2 Entstehung der agilen Softwareentwicklung

Mehr

Übungen zur Softwaretechnik

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

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Software entwickeln mit extreme Programming

Software entwickeln mit extreme Programming Martin Lippert Stefan Roock Henning Wolf Software entwickeln mit extreme Programming Erfahrungen aus der Praxis dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1 Die XP-Werte 4 1.2 Die XP-Prinzipien

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

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann

Mehr

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

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

Mehr

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

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

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 Methoden ohne Hype

Agile Methoden ohne Hype Agile Methoden ohne Hype Bastian Helfert Torsten Fink akquinet AG Microsoft/.NET 650T EK akquinet AG 1,5 Mio. EK Outsourcing 400T EK Java 400T EK SAP 100T EK International 140T EK Die präagile Zeit Dominanz

Mehr

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik

Softwaretechnik II. Sommersemester 2014. Software-Qualität. Stefan Berlik 1 / 43 Softwaretechnik II Sommersemester 2014 Software-Qualität Stefan Berlik Fachgruppe Praktische Informatik Fakultät IV, Department Elektrotechnik und Informatik Universität Siegen 8. Mai 2014 Gliederung

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

XP, Scrum, Crystal, FDD:

XP, Scrum, Crystal, FDD: XP, Scrum, Crystal, FDD: Welche agile Methode passt zu uns? Henning Wolf Christoph Kemp Was ist Agilität? Teil 1: Das agile Manifest We are uncovering better ways of developing software by doing it and

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

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

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

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

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

Mehr

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

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

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

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

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Agile Softwareentwicklung

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

Mehr

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

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 30.August 2011 Embedded Computing Conference 2011 Urs Böhm Übersicht Entwicklungsprozess Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall

Mehr

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014 Programmierprojekt Anne0e Bieniusa Sommersemester 2014 Phasen der So;ware- Entwicklung Planungsphase DefiniConsphase Entwurfsphase ImplemenCerungsphase Testphase Wasserfall- Modell Einführungs- und Wartungsphase

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Softwaretechnikpraktikum Gruppe: swp15.aae SS 2015 Betreuer: Prof. Gräbe Datum: 15.06.2015 Tutor: Klemens Schölhorn Qualitätssicherungskonzept Projektteam: Felix Albroscheit Dorian Dahms Paul Eisenhuth

Mehr

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung

Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Vorgehensmodelle Seite 1/6 Die praktische Bedeutung der verschiedenen Vorgehensmodelle in der Software-Entwicklung Große Softwareprojekte erwecken oft den Eindruck, dass diese chaotische verlaufen. Und

Mehr

Extreme Programming (XP)

Extreme Programming (XP) (XP) Ausarbeitung zum Referat vom 20.11.2006 im Rahmen der Veranstaltung Softwareengineering-Projekt an der TU Berlin im WS 2006/07 Vorgelegt von: Matrikelnummer: 178256 Betreuer: Marco Mosconi Inhaltsverzeichnis

Mehr

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs

IT-Projektmanagement bei basecom. Manuel Wortmann, Patrick Rolefs IT-Projektmanagement bei basecom Manuel Wortmann, Patrick Rolefs Vorstellrunde Mein Name ist, ich bin Jahre alt und mache meine Ausbildung bei. Übersicht wir sprechen internet Wasserfall - schön linear

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

Extreme Programming. Lutz Kirchner. www.exedio.com

Extreme Programming. Lutz Kirchner. www.exedio.com Extreme Programming Lutz Kirchner www.exedio.com 2 Blaues Wunder: eine bewunderte Ingenieursleistung Ein Bedürfnis wird elegant erfüllt Die Technologie ist neuartig Das Design ist hochmodern und rekordhaltig

Mehr

Agile Entwicklungspraktiken mit Scrum

Agile Entwicklungspraktiken mit Scrum Agile Entwicklungspraktiken mit Scrum von Roman Pichler, Stefan Roock 1. Auflage Agile Entwicklungspraktiken mit Scrum Pichler / Roock schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

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

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

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

Agile Softwareentwicklung mit SCRUM

Agile Softwareentwicklung mit SCRUM Agile Softwareentwicklung mit SCRUM PMI MUC 01. März 2010 Referent: Gerhard Held mehr als 35 Berufsjahre in der Softwareentwicklung im Projektmanagement und verwandten Themen... Gründe für das Scheitern

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

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben

Einführung von Testautomatisierung reflektiert. Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Einführung von Testautomatisierung reflektiert Erkenntnisse eines Linienmanagers zu Herausforderungen und Fallgruben Matt Young Leiter Test Acquiring Inhaltsverzeichnis Einleitung Testautomatisierung PostFinance

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

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

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

Mehr

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

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

Zielvereinbarung. Team JAMT.

Zielvereinbarung. Team JAMT. Ziele des Projektes. Wer benötigt das Ergebnis des Softwareprojektes? Gruppenprozessleiter, welche keine Expertise auf dem Gebiet der Gruppenprozesserstellung haben Teams, die computergestützte Gruppenarbeit

Mehr

extreme Programming Was ist xp Wie wird heute gearbeitet? eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland

extreme Programming Was ist xp Wie wird heute gearbeitet? eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland extreme Programming eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Was ist xp Wie wird heute gearbeitet? Ein durchgehend geplanter

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

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

Dysfunctional Team Game

Dysfunctional Team Game Dysfunctional Team Game Eine Einführung Zusammenfassung Autor: Berthold Barth communicode AG Agile Coach & Scrum Master Brand Manager Geek Dad Skype: bertholdbarth mail@berthold-barth.de http://www.berthold-barth.de

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

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

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

1/4. Team-Feedback zur Leistung des Scrum-Masters. Der Scrum-Master

1/4. Team-Feedback zur Leistung des Scrum-Masters. Der Scrum-Master 1/4 Der Scrum-Master "Der Scrum Master sorgt für eine nachhaltig hohe Produktivität und Qualität des Teams, indem er alle das Team tangierenden Vorhaben und Prozesse, die Aufteilung der Rollen und Rechte,

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

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Software Expedition. Seminar Systems Engineering extreme Programming

Software Expedition. Seminar Systems Engineering extreme Programming Software Expedition Seminar Systems Engineering extreme Programming Übersicht (1) Einleitung Von der klassischen Expedition zur Software-Expedition Software-Expedition als Vorgehensweise in einem instabilen

Mehr

agil entwickeln CSD Certified Scrum Developer Schulungen in Deutschland

agil entwickeln CSD Certified Scrum Developer Schulungen in Deutschland agil entwickeln CSD Certified Scrum Developer Schulungen in Deutschland Mein CSD-Kurs ERFAHRUNGSBERICHT Ich betrete den Kursraum. Es erwarten mich zwei Trainer und ein gutes Dutzend weitere Teilnehmer.

Mehr

Agile Software-Entwicklung: Vom Hype zum Daily Business

Agile Software-Entwicklung: Vom Hype zum Daily Business Agile Software-Entwicklung: Vom Hype zum Daily Business Prof. Dr. Sven Overhage Lehrstuhl für Wirtschaftsinformatik, insb. Industrielle Informationssysteme Otto-Friedrich-Universität Bamberg sven.overhage@uni-bamberg.de

Mehr