We have a Vision - Let's start Lean Agile Scrum Conference 2012

Größe: px
Ab Seite anzeigen:

Download "We have a Vision - Let's start Lean Agile Scrum Conference 2012"

Transkript

1 We have a Vision - Let's start Lean Agile Scrum Conference 2012 Daniel Tobler, Peter Schmid September 2012 Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren (Zürich) Schweiz Telefon Telefax zuehlke.com

2 Inhaltsverzeichnis 1. Einleitung 2 2. Scrum does not work for such Systems 7 3. These 1: Industrial Software is different 8 4. These 2: No Standard Architectures for Embedded Realtime Applications These 3: Scrum does not work for HW Development nor Mechanical Design months later ein Erfahrungsbericht Zusammenfassung Einleitung Scrum lebt vom Feedback der Anwender. Was ist, wenn dieses Feedback zu Beginn der Entwicklung ausbleibt? Ausbleibt, weil gar noch kein konkretes, lauffähiges Produktinkrement erstellt werden kann. Weil zuerst die ganze Systemarchitektur definiert werden muss. Was in Produkten mit einem hohen Anteil an User Interface eine kurze Phase ist, dauert in der industriellen Software Entwicklung lange. Zu lange, um als Initialsprint oder Sprint 0 abgetan zu werden. Der Vortrag geht auf diese wichtige und prägende Phase ein: Wie entsteht eine Architektur? Wie viel davon muss man zu Beginn definieren, wie viel Architektur kann während der Entwicklung hinzugefügt werden? Wie viele und welche Anforderungen nimmt man trotz Agilität vor dem Entwicklungsstart auf? Wie viele Stories enthält ein initialer Backlog und in welcher Form? Was macht der Product Owner, während die Entwickler sich mit der Entwicklungsumgebung herumschlagen? Wie lange darf diese Findungsphase dauern? Während dieser Phase wird vielfach auch Scrum eingeführt. Dabei gilt es bei Scrum einige Dinge zu beachten, die in dieser Phase anders sind. Ansonsten entsteht der falsche Eindruck von dieser Methode Seite 2 von 34

3 #LASZH LAS Conference 2012 Sponsoren We have a Vision - Let s start Peter Schmid Daniel Tobler 16:15 H37.1 Organisationsteam Patrick Baumgartner (Swiftmind GmbH) Andreas Buzzi (Credit Suisse) Reto Maduz (SwissQ AG) Mischa Ramseyer (pragmatic solutions gmbh) Die erwähnten Erfahrungen stammen nicht aus einem konkreten Projekt, sondern aus mehreren. Daher keine konkreten Projektnamen Seite 3 von 34

4 Einleitung LAS Conference 2012 Daniel Tobler Embedded RT C# / C++ / C Scrum.org Trainer PSD Course Stewart Peter Schmid Embedded RT C++ / Python Linux Scrum.org PSM II P: NEIN, Scrum geht nicht für unser Projekt. Wir bauen eine neue Maschine zusammen mit Hardware und Mechanik! D: DOCH, das geht, sogar sehr gut. Habe ich schon gemacht. P: Aber industrielle SW ist anders. D: Ja, das ist sie. Aber wenn du weißt warum, weißt du auch was mit Scrum zu beachten ist. P: Wir müssen doch eine umfangreiche Architektur erstellen und können nicht einfach loslegen D: Ist das wirklich in diesem Umfang nötig? Vielleicht macht ihr auch zu viel. P: Und für HW und Mechanik bringt Scrum nichts. D: Warte, ich stelle dir was zusammen und erkläre dir, wie es geht. Sagen wir um 16:15? P: Ja gerne, ich komme! P: (wendet sich zum Publikum) Aber was machen all die Zuhörer, die nicht aus der Industrie sind? D: Das ist auch für sie interessant: Big Design Upfront, Interaktion mit Nicht-Scrum Projektteilen gibt es überall. Und habt ihr nicht auch das Gefühl, bei euch ist es anders? PSD: Professional Scrum Developer Training, siehe Scrum-Developer Seite 4 von 34

5 Einleitung Picture of Webpage, simple technology Diese Webseite macht etwas Neues. Aber sie setzt auf Standard-Technologien, die schon 1000fach eingesetzt wurden. Wenn man mal eine Website gemacht hat, weiss man, wie es technisch geht. Die grosse Frage: Setzen es die Kunden ein, lieben sie es?! Link: Seite 5 von 34

6 Einleitung Embedded (realtime) Produkte basieren nicht auf Standard-Technologien. Die Software läuft auf spezifischer Hardware und steuert spezielle Mechanik an um einen besonderen physikalischen Prozess zu bedienen. Dieses Produkt ein WireBonder der Firma ESEC/BESI - macht etwas Bewährtes anders, neu, besser. Dafür kann es nicht auf Standard-Technologien setzen, sondern baut auf einer neuen HW und neuer Mechanik auf, die noch nie so dagewesen ist. Die grosse Frage: Kriegen wir den physikalischen Prozess, die HW/Mechanik in den Griff, kann die SW schnell genug reagieren. Aber nichts desto trotz: Auch hier gibt es ein umfangreichen User Interface, das der Benutzer lieben muss Seite 6 von 34

7 Scrum does not work for such Systems 2. Scrum does not work for such Systems Industrial Software is different Investment in up front architecture Interaction with mechanics and hardware We have a Vision - let's start Peter Schmid, Daniel Tobler 1. Slide August THESEN: 1. Industrial SW is different Wir bewegen Physik, keine Daten! 2. Investment in up front architecture required Keine Standard-Architekturen, wie bei Business-Applikationen oder Websites. 3. Interaction with mechanics and hardware. Hardware und Mechanik kann nicht mit Scrum entwickelt werden. Wir können nicht pro Sprints 3 Transistoren zur Schaltung hinzufügen Geht Scrum wirklich nicht für die Entwicklung solcher Systeme? Betrachten wir die 3 Thesen einmal genauer Seite 7 von 34

8 These 1: Industrial Software is different 3. These 1: Industrial Software is different Business Apps Scrum Rocks Here Embedded Realtime Comple x Software Stacey Matrix. Source: Stacey RD. Strategic management and organizational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, Source: Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, Wirklich unterschiedlich: Technology less known, always an adventure Dedicated HW/Mech RE better known. Old system. UI Interactions Customer/System LESS RISK We are not fighting the same amount of changing requirements, but facing new technology every time Nevertheless, Scrum applies! But different! Sobald wir die Technologie im Griff haben, wird aus unserem Projekt ein kompliziertes oder vielleicht sogar einfaches Vorhaben Seite 8 von 34

9 These 1: Industrial Software is different Embedded Realtime Software Comple x aber das Product Management macht daraus wieder ein komplexes Vorhaben: Jetzt kommen neue Anforderungen zum Vorschein. Baut einfach ein schnelleres Altsystem mit neuer Technologie nach wir zu einem Bitte unbedingt anders als die alte, schlechte Bedienung. Jetzt finden wir uns wieder im gleichen Bereich, wie Business Applikationen wieder. Reales Feedback ermöglich das! Seite 9 von 34

10 These 1: Industrial Software is different System-Development With real feedback Scrum System-Elaboration Without real feedback Comple Elements of Scrum x Business Applikationen haben nur System-Development. System-Elaboration ist kaum spürbar. Das ist bei Systementwicklungen anders! Was ist speziell am der System-Elaboration-Block?: Es ist nicht Scrum oder angepasstes Scrum. Es sind Elemente aus Scrum entlehnt. Wir wollen auch kein System-Scrum erfinden. Da braucht es mehr als nur 2 Köpfe. Kleines Team, interdisziplinär. Enge Zusammenarbeit. Dieses System Architecture Team bildet den Kern der SW-, HW-, und Mechanikteams im System-Development. Kurze Sprints, 1 Woche, keine Schätzungen der Aktivitäten, dafür viele Absprachen. Sprint Review, Retrospektive und Sprint Planning an einem Tag oder Halbtag jede Woche. Risikogetrieben. Der Businessvalue einer Story spielt (noch) keine Rolle Seite 10 von 34

11 These 1: Industrial Software is different Risklist Product Backlog Plan System Architecture Team (~4 members) SW HW Mech 1st real Feedback Aufgaben des System Architecture Teams während der System-Elaboration: Definieren der Systemarchitektur, Risikoanalyse und die Risiken bewerten, rangieren Plant, wie es die 2..3 höchsten Risiken minimieren kann, indem es die entsprechende(n) Funktionen auf einem System laufend zeigt, das dem schlussendlichen System so nahe wie möglich kommt. Wie es schnellstmöglich realem Feedback ermöglichen kann. Anmerkung 1: Schon mancher Prototyp hat bewiesen, dass das Risiko in den Griff zu bekommen ist. Die Wirklichkeit hat danach etwas anderes gezeigt. Anmerkung 2: Viele Risiken wurden übersehen, weil immer nur Prototypen isoliert ein Problem betrachtet haben. Füllt den Product Backlog, so dass das Enddatum der Entwicklung grob abgeschätzt werden kann. Diese Schätzung wird danach in einem Release Burndown Sprint für Sprint verfeinert Seite 11 von 34

12 These 1: Industrial Software is different RUP XP Scrum Scrum Daniel Tobler 18. Slide March Wer kennt den Rational Unified Process? RUP hat einen viel grösseren Fokus als Scrum. Aber Scrum ist im Bereich des Project Management richtig gelebt effektiver. Allerdings deckt Scrum nicht alle Phasen des RUP ab. Diese Lücke wird genau mit der System- Elaboration ausgefüllt. Es gibt hier starke Gemeinsamkeiten zur Inception und vor allem der Elaboration. Aber es gibt auch Unterschiede: Der RUP wird vielfach implementiert, dass sehr viel Papier zu einem Phasenende produziert werden muss. Die System-Elaboration aber will nur einen Plan, um möglichst schnell reales Feedback zu ermöglichen Seite 12 von 34

13 These 2: No Standard Architectures for Embedded Realtime Applications 4. These 2: No Standard Architectures for Embedded Realtime Applications Wir haben also gesehen, dass eine Systemarchitektur vorgängig definiert werden muss. Nur, wie weit geht das? Was ist überhaupt eine Architektur? Was ist eine Architektur überhaupt? Eine gute Definition einer Architektur: Grady Booch: All architecture is design, but not all design is architecture. Architecture represents the significant decisions, where significance is measured by cost of change. To change the Architecture is expensive To change the Design is cheap Eine einfache Definition von Architektur, aber eine die den Nagel auf den Kopf trifft. Teuer sind: HW Änderungen. Änderungen an mechanischen Teilen, vor allem wenn Produktionswerkzeuge betroffen sind. Timings die nicht eingehalten werden können. Sind Softwareänderungen teuer? Ja, wenn der Code nicht wartbar ist Sollte aber nicht sein. Siehe später Seite 13 von 34

14 These 2: No Standard Architectures for Embedded Realtime Applications Money spent on Architectural Changes, Evalboards, Prototypes, Throw Away Hardware, Wir wollen immer auf der sicheren Seite sein: Wir wollen keine mechanischem Teile oder Computerplatinen wegwerfen. Aber solche Sicherheit ist nicht gratis: Wir verzichten dafür auf schnellen Fortschritt. Wir zeigen für eine gewissen Zeit keinen realen Fortschritt. Einher geht damit Verlust von Vertrauen seitens des Managements. Dieses fehlende Vertrauen in die Entwicklung führt zu fatalen Resultaten, wie Mikromanagement und genauste Kontrolle der Tätigkeiten über viele Dokumente und Reporte. Dies verlangsamt den Fortschritt noch mehr. Projektabbrüche sind das Resultat. Und diese sind um einiges teurer, als eine fortgeworfene Computerplatine. Wir müssen die Balance zwischen real zeigbarem Fortschritt und Kosten für dafür notwendige Prototypen halten Seite 14 von 34

15 These 2: No Standard Architectures for Embedded Realtime Applications Plan Focus on highest risks SW HW Mech 1st real Feedback Next highest risks Real Feedback next Function Vielfach starten Mechanik und Hardware nach der System-Elaboration gleich damit, die ganze Maschine, alle Elektronik auf einmal zu entwickeln. Die Software wartet dann lange, bis sie ihr schlecht funktionierendes und aufwändiges Prototypenequipment ersetzen kann. Zudem muss die Software-Entwicklung auch warten und derweil völlig risikolose Dinge, wie In-Field-Upgrade, Detektion von ausgetauschten Modulen, Installation, etc. machen. Die Integration dieser Software auf die endlich verfügbare Hardware wird dann dafür zum endlos langen Trauerspiel. Anstatt dessen sollten auch Mechanik und Hardware sich nur auf die grössten Risiken konzentrieren. Dies auf die Gefahr hin, dass gewisse Teile weggeworfen werden müssen (Siehe Folie zuvor mit der Waage). Sobald diese Risiken auf dem System minimiert werden konnten, geht es an die nächsten Risiken. Dafür kommt das System Architecture Team wieder zusammen Seite 15 von 34

16 These 2: No Standard Architectures for Embedded Realtime Applications The myth of SW Architecture Works: Emergent SW Architecture! Delays: BDUF! Maintainability Refactoring Automatic Tests BDUF: Big Design Upfront Software ist nicht teuer zum Ändern, weil Software-Architektur teuer zu ändern ist. Änderungen sind teuer, weil der Code schlecht wartbar ist. Anstatt massiv in Upfront SW Architekturdesign (BDUF) zu investieren, investiert man besser in gute Testbarkeit auf Integrationslevel; in sogenannte Acceptancetests. Die SW Architektur entsteht im Gegensatz zur Systemarchitektur Sprint für Sprint. Die Erfahrung im Development Team hilft sicher. Aber auch unerfahrene Teams sollen lieber ihre Erfahrungen mit codieren machen, anstatt lange Dokumente schreiben. Im Detail: Damit Code wartbar ist, muss er stetig Refactored werden. Zudem ist Refactoring notwendig, weil Sprint für Sprint neue Anforderungen in den Code eingebaut werden müssen. Damit Refactoring nicht zum Albtraum wird, braucht es automatische Tests. Automatische Test auf Klassenlevel sind zwar gut, aber es gibt was Besseres: Automatische Tests, die knapp unter dem UI die Testvektoren eingeben und die Reaktion der Software darauf knapp oberhalb der HW testen. Dies nennt man Acceptance Tests. Vorteil: Da Anforderungen damit getestet werden, müssen die Tests bei einem Refactoring seltener angepasst werden Seite 16 von 34

17 These 3: Scrum does not work for HW Development nor Mechanical Design 5. These 3: Scrum does not work for HW Development nor Mechanical Design Focus on highest risks SW HW Mech Next highest risks Schauen wir uns mal das System-Development genauer an Seite 17 von 34

18 These 3: Scrum does not work for HW Development nor Mechanical Design Why should the young discipline of Software Development dictate the Process for the more mature disciplines of Hardware and Mechanics Die Prozesse für Hardware- und Mechanikentwicklung sind sehr ausgereift. Wieso soll nun die relativ junge Disziplin der Software-Entwicklung den Prozess vorgeben? Photo: Seite 18 von 34

19 These 3: Scrum does not work for HW Development nor Mechanical Design Hardware and Mechanical Development would not be happy with Scrum! Wieso?: Sprint Timebox: Wie kann die Hardware in einem Sprint 3 Transistoren zu einer existierenden Schaltung hinzufügen und im nächsten den Flash-Speicher um 5MB erhöhen? Auch ist es nicht wirklich erfüllend, für 3 Sprints auf eine Schaltung zu warten, die in China gefertigt wird. Photo: Seite 19 von 34

20 These 3: Scrum does not work for HW Development nor Mechanical Design Hardware and Mechanical Development do not profit from full Scrum but they need to work together with Software Development using Scrum and they can profit from certain elements of Scrum Photo: No common sense how Scrum for Hardware/Mechanics should look like the products are too diverse Seite 20 von 34

21 These 3: Scrum does not work for HW Development nor Mechanical Design Jedes meiner interdisziplinären Projekte hatte unterschiedliche Probleme, die unterschiedliche Lösungen benötigten. Noch schlimmer wird es, wenn ich mit weiteren Experten darüber diskutieren Mein Schluss daraus: Es gibt nicht den einen Prozess für interdisziplinäre Projekte,... Photo: Conclusion Find you own way Start with regular Retrospectives Increase collaboration between HW, Mech and SW AND Sondern jedes Projekt muss seinen eigenen Weg finden und sein eigenes, für sich optimiertes Vorgehen entwerfen. Dies geht am besten mit regelmässigen Retrospektiven zwischen Hardware, Mechanik und Software. Wenn Scrum nicht für Hardware und Software befriedigt, etwas aus der agilen Ecke passt auch zu diesen beiden Disziplinen: (siehe nächste Folien) Photo: istockphoto Seite 21 von 34

22 These 3: Scrum does not work for HW Development nor Mechanical Design Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan We have a Vision - let's start Peter Schmid, Daniel Tobler 1. Slide August Und immer gilt das Agile Manifest: Individuals and interactions - HW/Mechanik/SW müssen eng zusammen arbeiten - Kleines Startteam, das zu 100% am neuen Produkt arbeitet anstatt ein grosses Team, das immer wieder unterbrochen wird. Working software over comprehensive documentation - Lieber einmal einen Prototypen anstatt lange am Schema/der Detailzeichnung herumstudieren Customer collaboration over contract negotiation - Wir brauchen keine langen Spezifikationen, sondern kurze, griffige Visionen Responding to change over following a plan - Wenn es mal nicht geht, haben wir etwas gelernt Seite 22 von 34

23 These 3: Scrum does not work for HW Development nor Mechanical Design <= 9 Developers > 9 Developers > 9 SW Developers SW HW Mech SW HW Mech SW HW Mech Team System Architecture Team member Scrum limitiert die Teams auf maximal 9 Mitglieder (6 plus/minus 3). Diese Grenze macht Sinn, weil ein Team über 9 Mitgliedern automatisch in zwei, drei Teile zerfällt. Wie sollen nun aber die Entwickler auf die Teams aufgeteilt werden? Bei <=9 Entwickler ist es ziemlich klar: HW, SW und Mechanik bilden ein Team und arbeiten sehr eng zusammen. Das System Architecture Team wird aus je einem Vertreter der 3 Disziplinen gebildet. Bei > 9 Entwicklern wird es spannender. Es macht keinen Sinn, zwei oder drei Teams zu bilden, die je HW, SW und Mechanik-Entwickler beinhalten. Je ein Team pro Disziplin ist besser, weil die Interaktionen innerhalb der Disziplinen viel enger sind. Interessant ist die Schnittstelle zwischen HW und SW. Anstatt ein langes Dokument über die HW-Schnittstelle zu schreiben, die SW-Entwickler mit mangelhaften HW-Kenntnissen verstehen müssen, wird ein SW-Entwickler dem HW-Team zugeteilt. Dieser Entwickler muss beide Welten verstehen und entwickelt die Low-Level-Software, den Hardware-Abstraction-Layer und Treiber. Anstelle einer dokumentierten Schnittstelle gibt es eine «belebte» Schnittstelle. Bei > 9 SW-Entwicklern wird das SW-Team unterteilt. Aber die Unterteilung sollte nicht entlang der SW-Layern stattfinden. Es ist eine schlechte Idee, ein Team das User Interface, ein anderes die Steuerungslogik und das dritte Team Framework machen zu lassen. Dies gilt umso mehr, wenn die Layers auf verschiedenen Rechnern oder Geräten laufen Seite 23 von 34

24 These 3: Scrum does not work for HW Development nor Mechanical Design Die Teams arbeiten viel effizienter, wenn Experten aus allen Schichten dabei sind und zusammen ein komplettes Feature entwickeln können. Dies nennt man Feature-Teams. BTW: Es ist auch nicht nur von Vorteil, die Teams anhand der geographischen Verteilung zu organisieren. Sehr schnell gibt es Standort-Wettkämpfe: «Die am anderen Standort haben keine Ahnung». Aus persönlicher Erfahrung weiss ich, dass verteilte Teams sehr gut funktionieren Seite 24 von 34

25 9 months later ein Erfahrungsbericht 6. 9 months later ein Erfahrungsbericht D: Hoi Pesche! Wow, seit 9 Monaten nicht mehr gesehen. Wie läuft es denn so? P: Gut. Wir haben unser Projekt mit Scrum umgesetzt und jetzt läuft die Nullserie vom Stapel. D: Interessant, erzähl P: Industrial Software is different Differ between System-Elaboration and System-Development Timebox System-Elaboration System-Elaboration is Risk Driven We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 33 Differ between System-Elaboration and System-Development P: Wir haben uns deinen Vorschlag der System-Elaboration zu Herzen genommen und konnten uns tatsächlich daran halten. Time box System Elaboration Risk Driven D: Wie habt ihr das konkret gemacht? P: Wir haben uns für die System-Elaboration eine Timebox von 3 Monaten gesetzt (Sonst läuft man Gefahr, dass die Elaboration ewig dauert). Dass war eine ziemlich hektische Zeit. Der Systemarchitekt wollte so viel Risken wie möglich aus dem Weg räumen. Photos: istockphoto Seite 25 von 34

26 9 months later ein Erfahrungsbericht Industrial Software is different Small, interdisciplinary team Get feedback from a real System as fast as possible Keep quality high Good testing environment We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 34 Small, interdisciplinary team Get feedback from a real System as fast as possible D: Wer war an der System-Elaboration beteiligt? P: Mit einem kleinen interdisziplinären Team (2SW, 1Mech, 1HW, 1SysArch, 1PO) haben wir die grössten Risiken adressiert. Dazu haben wir Teile einer bestehenden Maschine zu einem Funktionsmodell zusammen gebaut. Damit konnten wir schon viel Erfahrung sammeln und waren schneller als wenn wir auf die richtige HW gewartet hätten. Keep quality high Good testing environment D: Wie konntet ihr in dieser hektischen Zeit die Qualität hochhalten? P: Wir haben trotz Zeitdruck die Qualität hoch gehalten. Die automatischen Tests haben uns sehr geholfen, das System zu refactorn und so das Design immer gerade zu ziehen. D: Habt ihr jede Klasse getestet? P: Nein, wir haben auf Integrationslevel getestet. Wie du gezeigt hast. Photos: istockphoto Seite 26 von 34

27 9 months later ein Erfahrungsbericht Industrial Software is different System Architect fills the Backlog for System-Elaboration Ridge Hiking We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 35 System Architect fills the Backlog in System-Elaboration D: Du hast vorhin gesagt, der Systemarchitekt wollte die Risiken aus dem Weg haben. Hat nicht der PO gesagt wo es lang geht? P: Nein, der PO war damit beschäftigt die Stories für das nachfolgende System-Development zu erstellen. In der System Elaboration hat der Systemarchitekt das Backlog gefüllt; natürlich in Absprache mit dem PO. Ridge Hiking D: Das klingt mir nach einer ziemlich turbulenten Zeit. P: Ja, die Elaboration ist eine Gratwanderung: P: Jeden Moment konnten wir nach links oder rechts nach unten abstürzen: - Links: Analysis Paralysis: Dass wir nie konkret wurden, sondern immer nur in der Analyse verharrt wären. - Rechts: Wir haben eine architektonisch relevante Anforderung übersehen und dies hätte das Projekt später massiv verzögert oder eingeschränkt. Das war nicht einfach, aber ist uns mehr oder weniger gelungen. Dies dank intensiver Zusammenarbeit und vielen Diskussionen. Photo: Seite 27 von 34

28 9 months later ein Erfahrungsbericht Standard Architecture Mix Software Engineers and Computer Scientist Pull from company-wide Platform Estimations difficult What cannot be estimated, must be timeboxed Therefore short Sprints We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 36 Mix Software Engineers and Computer Scientist D: Wie seid ihr auf die Software-Architektur gekommen? P: Innert zwei Wochen haben zwei Entwickler einen ersten Entwurf zusammen gebaut. D: War der dann fertig? P: Nein, noch lange nicht. Aber die beiden haben wirklich gewusst, was sie tun: Ein erfahrener Entwickler und ein junger, talentierter Informatiker. Der hatte vor allem Erfahrung mit PC-Software und gab uns viele Inputs, z.b. RESTful Webservices und Data Transfer Objects oder zur Persistierung. Wir haben viel Standartprodukte verwendet und versucht das Rad nicht immer neu zu erfinden. Pull from company-wide Platform P: Und da war noch die Plattform, die unsere zentrale Forschungsstelle entwickelt hat. D: Ach ja, konntet ihr die brauchen? P: Am Anfang kaum. Sie war eher theoretisch und an unseren Anforderungen vorbei. Aber wir haben ihnen gesagt, was wir brauchen und die Plattform wurde immer brauchbarer. D: Ihr habt also gezogen, anstatt dass die Plattform gestossen wurde? P: Du sagst es P: Und ziemlich schnell ist das Plattform-Team in unsere Nähe gesessen und haben auch auf der Maschine gearbeitet. Das Framework wurde durch den konkreten Einsatz besser Seite 28 von 34

29 9 months later ein Erfahrungsbericht Estimations difficult What can t be estimated, must be time boxed Therefore short Sprints D: Scrum verlangt doch, dass jedes Item im Product Backlog geschätzt wird. Wie habt ihr den Architekturentwurf geschätzt P: Gar nicht! D: Gar nicht? Wie habt ihr dann in der System-Elaboration geplant? P: Na, zuerst waren mal die 3 Monate. Diese haben wir in 1 Wochensprints unterteilt. Anstatt dass wir geplant haben, haben wir jeweils am Montagmorgen eine gemeinsame Sitzung gehabt, wo wir uns gegenseitig ausgetauscht und koordiniert haben. Darin enthalten waren Sprint Review, Retrospektive und Planung dieser Woche. Photos: istockphoto Initial Backlog at end of System-Elaboration Top ranked stories detailed only Not detailed stories (or epics) for all functionality All stories estimated Few stories Regular Grooming 8 SP 3 SP 5 SP 60 SP 30 SP 40 SP 50 SP 30 SP Folie 37 Top ranked stories detailed only Not detailed stories (or epics) for all functionality D: Erzähl mal genauer über den Product Owner. Was hat der gemacht? P: Zusammen mit dem Team den initialen Backlog erstellt. D: Was heisst das denn konkret? P: Er hat die Funktionalitäten grob in Stories eingeteilt. Da war aber nicht viel mehr dahinter, als ein, zwei Sätze Seite 29 von 34

30 9 months later ein Erfahrungsbericht D: Da gab es doch sicher Doppelspurigkeiten und Lücken! P: Ja, aber wir hatten eine Struktur der Funktionen, an der wir uns orientieren konnten. So eine Story haben wir, sobald sie genügend Priorität hatte, besprochen, detailliert und unterteilt. All stories estimated D: Wie habt ihr dann diese groben Stories geschätzt? Das war sicher nicht einfach! P: Gar nicht so schwer. Jeder war sich bewusst, dass dies sehr grobe Schätzungen waren. Wir haben sicher einen halben Sprint mit dem Product Owner zusammen die einzelnen Funktionalitäten diskutiert und dann mit Planning Poker Story für Story geschätzt. P: Und ganz wichtig: Zu Beginn des ersten System-Development-Blocks sind mehr Entwickler zum Team gestossen. Diese wären beim Schätzen auch dabei und haben uns ganz viele Fragen gestellt. So konnten sie von unserem Wissen lernen. Few stories Regular Grooming D: Wieviele Stories hattet ihr dann im Backlog? P: Nicht so viele. Etwa 50 Stories, davon 8 detailliert. D: Und wenn diese 8 implementiert waren? P: Da hatten wir schon wieder 10 weitere Stories detailliert: Wir haben jede Woche ein Backlog Grooming durchgeführt. Das hat eine Stunde gedauert. Darin haben wir neue Stories geschätzt, Schätzungen korrigiert und nicht detaillierte Stories besprochen Seite 30 von 34

31 9 months later ein Erfahrungsbericht Interaktion Hardware / Mechanics / Software in System-Development Only the Software stories are in the Backlog PO only cares about Software Additional PL does the orchestration of the disciplines HW, Mechanic and Software are all together in one Backlog, Combined! PO looks after all disciplines We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 38 D: Wie habt ihr die Schnittstallen zu den anderen Disziplinen während dem System-Development gemacht? Habt ihr bei der Konstruktion und der HW auch Scrum eingeführt? P: Nein, das haben wir uns nicht getraut. Meiner Ansicht nach hätte das etwas viel Unruhe gebracht. Wir haben Scrum nur in der Software eingeführt und mal vorgelebt. Früher war der Flaschenhals immer in der SW. Mit der Einführung von Scrum ist der dann in die anderen Disziplinen gewandert (wie bei der Autobahn, wenn man bei einem Nadelöhr auf 3-Spurig wechselt, wandert der Stau auch an eine andere Stelle und somit auch die Baustelle ;-). Diese Verschiebung hat dann die wasserfallgetriebenen Disziplinen diverse Änderungen gefordert. D: Wieso ist das passiert? P: Wir haben viel mit unseren Acceptance Tests entwickelt und waren so schneller auf der Hardware, wenn sie einmal hier war. Zudem haben wir viel früher mitgekriegt, wann die Mechanik eine Änderung macht und konnten die Software schon vorher anpassen. Dies dank der engeren und direkten Zusammenarbeit mit den Mechanikern. D: Dann war der PO nicht für sämtliche Disziplinen zuständig? P: Genau, wir hatten nur die SW Storys im Backlog. Die disziplinenübergreifenden Anliegen wurden vom Projektleiter koordiniert. Wobei er nur die Zusammenarbeit anstösst, die Teams organisieren sich dann selber Seite 31 von 34

32 9 months later ein Erfahrungsbericht Interaktion Hardware / Mechanics / Software in System-Development Inform all involved disciplines about Scrum and the fundamental values Small Teams: Daily Scrum with all disciplines Big Teams: Overall Daily Scrum less frequent (but still frequent!) Make Retrospective over all disciplines We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 39 Inform all involved disciplines about Scrum and the fundamental values Small Teams: Daily with all disciplines Big Teams: Overall Daily less frequent (but still frequent!) D: Wie habt ihr dann die anderen Disziplinen in Scrum integriert? P: Einmal in der Woche hatten wir alle Disziplinen am Daily Scrum. Das war dann halt etwas ausführlicher und dauerte länger als die vorgegebenen 15min. Tendenziell hat man dann eher die Sachen herausgestrichen welche die anderen Disziplinen betreffen könnten. Make Retrospective over all disciplines D: Und beim Sprint Review und der Retrospektive? P: Beim Review waren die anderen Disziplinen optional und kamen je nach Interesse und ob sie etwas zu zeigen hatten. Die Retrospektive haben wir aber immer gemeinsam gemacht. Das war zu Beginn etwas Fremdes für die Mechanik und Hardware. Eine Kurzschulung über Scrum und den darunterliegenden Werten hat dann das aber verbessert. Etwas schwieriger wird es, wenn die anderen Disziplinen Spezialisierungen einsetzen. Dann kommt einmal der einer der Verschalungen, dann einer der macht Speisungen und keiner hat vom Gesamten eine Ahnung (»Ja ich habe nicht gewusst, dass unter die Verschalung noch eine zusätzliche Speisung muss!») Da haben wir versucht sämtliche Beteiligten so lang wie möglich auf dem Projekt zu lassen Seite 32 von 34

33 9 months later ein Erfahrungsbericht Scrum Introduction Top Down: Counter fear with transparency Bottom Up: Do not forget Management! We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Folie 40 D: Gibt es etwas was du anders machen würdest? P: Ja, wir haben Scrum Bottom Up eingeführt. Dabei fühlte sich ein Gruppenleiter rechts überholt und mutierte zum Scrum-Verhinderer. Im Nachhinein würde ich ihn früher versuchen ins Boot zu holen und vielleicht als offiziellen Scrum-Kritiker an die Reviews und Retrospektiven einladen Seite 33 von 34

34 Zusammenfassung 7. Zusammenfassung Summary Industrial Software is different Yes, it is System-Elaboration, System Development Investment in up front architecture Reduce risks iteratively Several System-Elaborations System-Architecture not equal SW Architecture Interaction with mechanics and hardware HW and Mechanics do not need to do Scrum But they need to work together with SW doing Scrum Start with regular Retrospectives We have a Vision - let's start Peter Schmid, Daniel Tobler 1. August 2012 Slide Seite 34 von 34

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

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

Mehr

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

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

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

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

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

Mehr

Das Who s Who der agilen Methoden Golo Roden

Das Who s Who der agilen Methoden Golo Roden Das Who s Who der agilen Methoden Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher

Mehr

Agile Methoden vs. Testen

Agile Methoden vs. Testen Agile Methoden vs. Testen cc gmbh Bernhard Moritz CC GmbH TAV 27, AK Testmanagement, 6.6.2008 Bernhard Moritz Flachstraße 13 65197 Wiesbaden Telefon 0611 94204-0 Telefax 0611 94204-44 Bernhard.Moritz@cc-gmbh.de

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

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

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

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

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

Scrum @FH Biel. Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012. Folie 1 12. Januar 2012. Frank Buchli

Scrum @FH Biel. Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012. Folie 1 12. Januar 2012. Frank Buchli Scrum @FH Biel Scrum Einführung mit «Electronical Newsletter» FH Biel, 12. Januar 2012 Folie 1 12. Januar 2012 Frank Buchli Zu meiner Person Frank Buchli MS in Computer Science, Uni Bern 2003 3 Jahre IT

Mehr

Scrum E I N F Ü H R U N G

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

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

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

Wie agil kann Business Analyse sein?

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

Mehr

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

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

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

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

Projektmanagement 14/ 15 Agiles Management - Scrum (1) Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement 14/ 15 Agiles Management - Scrum (1) Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement 14/ 15 Agiles Management - Scrum (1) Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller Inhalte Agile Modelle Manifesto Übersicht

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

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

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

Mehr

Agile 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

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

Critical Chain and Scrum

Critical Chain and Scrum Critical Chain and Scrum classic meets avant-garde (but who is who?) TOC4U 24.03.2012 Darmstadt Photo: Dan Nernay @ YachtPals.com TOC4U 24.03.2012 Darmstadt Wolfram Müller 20 Jahre Erfahrung aus 530 Projekten

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis Der Vortrag zeigt anhand von Fallbeispielen auf, wie sich SOA durch die Kombination

Mehr

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen?

Are you Agile. SAQ Zug um Zug, 27. November 2008. Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? ? SAQ Zug um Zug, Agilität: Was bringen Sie mit? Was wissen Sie schon? Was wollen Sie heute Abend mitnehmen? Folie 1 hat sich als Projektleiter während acht Jahren dafür eingesetzt, Ende Iteration lauffähige

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

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6

Lean, Agile & Scrum. Josef Scherer. Sponsoren. Agilität Scrum Grundlagen Erfahrungsaustausch. 10:30 12:00, ETH Zürich, E6 Lean, Agile & Scrum Conference Sponsoren Josef Scherer Scrum für Einsteiger Agilität Scrum Grundlagen Erfahrungsaustausch 10:30 12:00, ETH Zürich, E6 Vorstellung Erfahrung fh mit Scrum? Agile Kultur Agiles

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

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

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

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

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

Mehr

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

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

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

Mehr

Agiles Anforderungsmanagement mit SCRUM im regulierten Umfeld

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

Mehr

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de

Scrum. Golo Roden. www.goloroden.de www.des-eisbaeren-blog.de Scrum Golo Roden www.goloroden.de www.des-eisbaeren-blog.de Über mich > Wissensvermittler und Technologieberater >.NET, Codequalität und agile Methoden > MVP für C#, zweifacher MCP und CCD > Autor, Sprecher

Mehr

DER AGILE ENTWICKLER, VERSION 1.2

DER AGILE ENTWICKLER, VERSION 1.2 DER AGILE ENTWICKLER, VERSION 1.2 OBJEKTspektrum Information Days, 27. 29. April 2010 SCRUM ÜBERBLICK VORHIN AUF TWITTER 30.06.2010 3 FLACCID SCRUM There's a mess about a few projects recently. It works

Mehr

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

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

Mehr

Henrik Kniberg. Lean from the Trenches Managing Large-Scale Projects with Kanban

Henrik Kniberg. Lean from the Trenches Managing Large-Scale Projects with Kanban Henrik Kniberg Lean from the Trenches Managing Large-Scale Projects with Kanban Preface: The Project PUST (Polisens mobila Utrednings STöd) 2 Jahre 10 60+ Mitarbeiter 3 Feature Teams 1 Requirements Analyst

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

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

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

Train. Scrum Kompakt. Angelika Drach, Christoph Mathis

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

Mehr

Stefan Mieth, AIT GmbH & Co. KG

Stefan Mieth, AIT GmbH & Co. KG Stefan Mieth, AIT GmbH & Co KG As a requirements engineer I want to use the TFS 12032015; 16:30 17:30 Requirements Engineering ist neben Testing wohl der Dauerbrenner, wenn es um gerne vernachlässigte

Mehr

ZuuL - Entwicklung eines Adventures

ZuuL - Entwicklung eines Adventures ZuuL - Entwicklung eines Adventures im Rahmen der Uni-Tage 2009 Team 120 Universität Hamburg 16./17. November 2009 Team 120 (Universität Hamburg) ZuuL - Entwicklung eines Adventures 16.11.09 1 / 21 Übersicht

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

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

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

Mehr

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

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

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

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

It s all about shipping software!

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

Mehr

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

Prediction Market, 28th July 2012 Information and Instructions. Prognosemärkte Lehrstuhl für Betriebswirtschaftslehre insbes.

Prediction Market, 28th July 2012 Information and Instructions. Prognosemärkte Lehrstuhl für Betriebswirtschaftslehre insbes. Prediction Market, 28th July 2012 Information and Instructions S. 1 Welcome, and thanks for your participation Sensational prices are waiting for you 1000 Euro in amazon vouchers: The winner has the chance

Mehr

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

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

Mehr

Das Agile Team. Skills, Arbeitsweise, Umgebung

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

Mehr

Welche agilen Prozesse führen zum Ziel?

Welche agilen Prozesse führen zum Ziel? Welche agilen Prozesse führen zum Ziel? Andreas Lechner, hotel.de AG Dr. Florian Irmert, hotel.de AG 24.10.2012 PM Forum Nürnberg Seite 1 Andreas Lechner Jahrgang 1974 Studium der Informatik mit Nebenfach

Mehr

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.

Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile. Festpreisvertrag und agil nützt nicht viel? Stefan Roock, stefan.roock@akquinet.de Henning Wolf, henning.wolf@akquinet.de http://www.it-agile.de Unser Hintergrund Agile Softwareentwicklung/Schulung/Beratung

Mehr

Algorithms for graph visualization

Algorithms for graph visualization Algorithms for graph visualization Project - Orthogonal Grid Layout with Small Area W INTER SEMESTER 2013/2014 Martin No llenburg KIT Universita t des Landes Baden-Wu rttemberg und nationales Forschungszentrum

Mehr

Einführung agiler Vorgehen in Unternehmen

Einführung agiler Vorgehen in Unternehmen Einführung agiler Vorgehen in Unternehmen 27. Oktober 2011, VDE München Armin Oppitz, Dipl Inf, PMP, CSM Armin.oppitz@liongate.de 2011 LionGate AG www.liongate.de Backlog To-Do Doing Done Grundlagen und

Mehr

Agile Software-Entwicklung: Überblick

Agile Software-Entwicklung: Überblick Agile Software-Entwicklung: Überblick Stefan Diener / Apr 18, 2007 / Page 1 Inhalt Historie Agiles Manifest Agile Prinzipien Agile Methoden Agile SW-Entwicklungsprozesse Stefan Diener / Apr 18, 2007 /

Mehr

Wie funktioniert agile Software-

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

Mehr

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

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

Mehr

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

Frontend Migration from JSP to Eclipse Scout

Frontend Migration from JSP to Eclipse Scout Frontend Migration from JSP to Eclipse Scout Peter Nüdling Raiffeisen Schweiz Jérémie Bresson, Peter Barthazy BSI Business Systems Integration AG Eclipse Finance Day, Zürich, 31. Oktober 2014 Seite 1 WebKat:

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

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG Michael Palotas 7. April 2015 1 GRIDFUSION IHR REFERENT Gridfusion Software Solutions Kontakt: Michael Palotas Gerbiweg

Mehr

Trends in der Agilität Dr. Martin Geier

Trends in der Agilität Dr. Martin Geier Projektmanagement Agil Trends in der Agilität Dr. Martin Geier Zahlen und Fakten Fakten Gründung 2001 Standorte: Deutschland: Erlangen, München USA: Detroit, Miami Auszeichnungen 2004 2008 2011 2006, 2007,

Mehr

Wie bekommt man zusätzliche TOEFL-Zertifikate? Wie kann man weitere Empfänger von TOEFL- Zertifikaten angeben?

Wie bekommt man zusätzliche TOEFL-Zertifikate? Wie kann man weitere Empfänger von TOEFL- Zertifikaten angeben? Wie bekommt man zusätzliche TOEFL-Zertifikate? Wie kann man weitere Empfänger von TOEFL- Zertifikaten angeben? How do I get additional TOEFL certificates? How can I add further recipients for TOEFL certificates?

Mehr

Leuchtfeuer. Hinter den Kulissen der Scrum Transformierung der Allianz Deutschland

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

Mehr

ERFOLGREICH SPRINTEN TROTZ MAINTENANCE

ERFOLGREICH SPRINTEN TROTZ MAINTENANCE BITKOM SOFTWARE SUMMIT» Erfolgreich Sprinten trotz Maintenance «ERFOLGREICH SPRINTEN TROTZ MAINTENANCE» «Präsentation Frederic Ebelshäuser frederic.ebelshaeuser@yatta.de twitter.com/febelshaeuser Yatta

Mehr

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

Mehr

Project Community Retrospectives. Agile Organisationen lernen Lernen

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

Mehr

Herausforderungen bei agiler Entwicklung und agilem Testen

Herausforderungen bei agiler Entwicklung und agilem Testen Herausforderungen bei agiler Entwicklung und agilem Testen Dr. Andreas Birk, Gerald Heller Vivit Deutschland Jahrestreffen, Bad Honnef 14. September 2010 Inhalt Was ist agile Entwicklung? Wie unterstützt

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

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

Mehr

In welcher Projektgröße haben Sie agiles Vorgehen eingesetzt?

In welcher Projektgröße haben Sie agiles Vorgehen eingesetzt? Das kleine 1x1 von Scrum im Großen Alexander Birke, Accenture Martin Bengl, Improuv 1 In welcher Projektgröße haben Sie agiles Vorgehen eingesetzt? 2 1 Agenda 1. Frameworks 2. Prinzipien und Patterns 3.

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

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren

MatchPoint. Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint Wirtschaftlichkeit von SharePoint Plattformen optimieren MatchPoint at a Glance Build Solutions in Less Time Provide a Better User Experience Maintain Your Platform at Lower Cost 2 MatchPoint

Mehr

Agile Software Development

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

Mehr

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena http://www.im.uni-jena.de Contents I. Learning Objectives II. III. IV. Recap

Mehr

Social Media als Hilfsmittel für agile Projekt-Teams

Social Media als Hilfsmittel für agile Projekt-Teams Social Media als Hilfsmittel für agile Projekt-Teams 14. Sept. 2010, Zürich Dr. Hans-Peter Korn www.korn.ch "Agiles" Management: Wozu? Resultat > Konzept / Plan Planen - Reisen - Ankommen voraussehbar,

Mehr

Internet Briefing Agile SW-Entwicklung

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

Mehr

Orbit Zoom Days: Seminar c-15 Rapid Development

Orbit Zoom Days: Seminar c-15 Rapid Development Orbit Zoom Days: Seminar c-15 Rapid Development Zürich, 14. Mai 2009 Jean-Pierre König, Senior Software Engineer David Nydegger, Consultant 1 www.namics.com Die Ausgangslage Wir haben ein fixes Budget.

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

Agiles Projektmanagement mit Scrum

Agiles Projektmanagement mit Scrum Agiles Projektmanagement mit Scrum Josef Scherer CSM, CSP Lösungsfokussierter Berater josef.scherer@gmail.com 2009, Josef Scherer Scherer IT Consulting Freiberuflicher Scrum Coach Lösungsfokussierter Berater

Mehr

Stop Making Sense. Über Sinn und Unsinn von Schätzungen

Stop Making Sense. Über Sinn und Unsinn von Schätzungen Stop Making Sense Über Sinn und Unsinn von Schätzungen Agenda Agenda Was sind Schätzungen? Agenda Was sind Schätzungen? Geht es auch einfacher? Agenda Was sind Schätzungen? Geht es auch einfacher? Wie

Mehr

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

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

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

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

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

Mehr

Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT

Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT Malte Foegen, Mareike Solbach, Claudia Raak Agile Verbesserung der Arbeit Der richtige Weg zur professionellen IT IT Maturity S e r v i c e s 1 Der falsche Weg 2 Der richtige Weg -2- Copyright 2007 wibas

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

on Software Development Design

on Software Development Design Werner Mellis A Systematic on Software Development Design Folie 1 von 22 How to describe software development? dimensions of software development organizational division of labor coordination process formalization

Mehr