Ein Widerspruch? Nein kein Widerspruch! Nur die Fokussierung auf das Wesentliche unter Berücksichtigung der Herausforderungen des Schätzens. Von der Produktplanung über die Release- / Ressourcenplanung und die Sprintplanung werden die verschiedenen agilen Verfahren zur Schätzung und Planung erörtert und mit den klassischen Verfahren verglichen. Weiterhin werden die notwendigen Grundlagen eines validen Schätzens diskutiert. Brauchen wir überhaupt einen Plan? Welchen Nutzen bringt der uns? Sind agile Schätzverfahren wirklich schneller? Ist agiles Planen genauer als klassische Verfahren? Was ist empirisches Management? Und … wo bleibt mein Gantt?
GPM Vortrag: Modernes Management von SoftwareprojektenFrank Düsterbeck
Softwareprojekte werden immer komplexer. Die Ursachen hierfür sind zum einen in der immer höheren IT-technischen Abdeckung der Geschäftsprozesse, bei steigender Anforderungsdynamik zu suchen. Zum anderen werden die Softwareproduktionsumgebungen, Technologien und Infrastrukturen und somit auch die Anforderungen an die Qualifikation aller Projektbeteiligter immer umfassender.
Das Management von Projekten muss der Komplexität gerecht werden. Dies bedeutet, Komplexität zu minimieren und über geeignete Prozessrahmen, Praktiken, Methoden und Technologien beherrschbarer zu machen. Dies bedeutet aber auch Risiken zu reduzieren durch Fokussierung auf das Wesentliche, insbesondere im Bereich der Planung, des Anforderungs- und Qualitätsmanagements.
Dieser Vortrag stellt die Herausforderungen der modernen Softwareentwicklung dar und gibt Antworten auf die Fragen, wie Komplexität z.B. durch agile Prozessrahmen und Methoden beherrschbarer gemacht werden kann und mit welchen Mitteln und Wegen eine hohe Qualität, sowohl in den Prozessen als auch im Produkt, trotz der Risiken, erreicht werden kann.
Anforderungen haben immer Schuld! Schuld an schlechten Tests, Schuld an schlechter Entwicklung, Schuld für viele Änderungen, Schuld an einfach allem. Wie macht man also gutes Anforderungsmanagement und schafft es dadurch noch Komplexität zu reduzieren und so Softwareprojekte einfacher zu gestalten? Wie kriegt man den Kunden dazu seine 1000-seitigen Lastenhefte zu entsorgen und durch etwas Geeigneteres zu ersetzen? Mittels moderner agiler Verfahren und Praktiken. Wie diese genau aussehen, welche Hindernisse auftauchen können und wie diese aus dem Weg geschafft werden können zeigt dieser Vortrag – immer mit dem Fokus auf Einfachheit und Praktikabilität. Der Vortrag ist gerichtet an Projektleiter, Entwickler, Abteilungs-, Team und Bereichsleiter, Scrum Master, Product Owner, Business Analysten.
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...Mayflower GmbH
Soll ich Entwickler pro Stunde einkaufen? Lohnt es sich für mich, spontan ein Team zu staffen? Brauche ich einen Rockstar-Developer im Team, um die Deadline zu retten?
Woher kommt die Performance von Development-Teams? Ist es wirklich eine magische Eigenschaft von bestimmten Entwicklern, die Produkte erfolgreich macht? Oder kommt herausragende Performance von einer ganz anderer Seite?
Keiner glaubt mehr an die Versprechen aus der IT, weder Druck, Motivation noch ein grösseres Team bringen auch nur etwas Performance. Es gibt viele Fehler in der Software und die Fluktuation geht nach oben. Wie fängt man so ein Projekt ein? Eine Geschichte von den offensichtlichen und nicht so offensichtlichen Dingen, die man dabei berücksichtigen muss - aus dem echten Leben erzählt.
Tools wie JMeter, ab2, WebLOAD oder httperf kennt und nutzt jeder, aber man will nicht die Hand dafür ins Feuer halten, dass es dann auch mit den angestrebten Nutzern produktiv so funktioniert. Mit ein paar Tricks, clever gewählten Use Cases, etwas JMeter und etwas Excel kann man nicht nur eine Aussage über die Performance liefern, sondern auch dafür garantieren, dass es zu 99,99 Prozent so passieren wird.
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
Mit Aufwandsschätzungen machen es sich Software-Entwicklungsteams zurecht schwer: Der Kunde will vorweg wissen, was ein neues Feature in seiner Software kostet. Selbst wenn wir den genannten Betrag (Aufwand) explizit als Schätzung deklarieren, wissen wir doch, was passieren wird: Im Nachhinein nagelt uns der Kunde darauf fest. Das versucht man in der agilen Software-Entwicklung zu umgehen und beschätzt deshalb keine Aufwände, sondern die Komplexität eines Features in Relation zu den anderen. Dieser Artikel beschreibt, wie agile Teams schnell zu solchen Schätzungen kommen.
iele Applikationen sind über Jahre erfolgreich gewesen und haben jede Änderung mitgemacht - und sind in Folge unwartbar geworden, und entsprechen längst nicht mehr aktuellen Standards. Doch um weiter am Markt zu bestehen muss man schnell agieren können, also braucht es einen Rewrite auf ein modernes Framework. Aber Rewrites schlagen häufig durch jede Deadline oder ganz fehl, und während des Rewrites muss man auf die Konkurrenz reagieren können. Die Lösung ist ein Continuous Rewrite, der mit der alten Lösung beginnt und bei kontinuierlicher Nutzung mit der neuen Lösung endet. Wir stellen Methoden und Praxiserfahrungen vor.
GPM Vortrag: Modernes Management von SoftwareprojektenFrank Düsterbeck
Softwareprojekte werden immer komplexer. Die Ursachen hierfür sind zum einen in der immer höheren IT-technischen Abdeckung der Geschäftsprozesse, bei steigender Anforderungsdynamik zu suchen. Zum anderen werden die Softwareproduktionsumgebungen, Technologien und Infrastrukturen und somit auch die Anforderungen an die Qualifikation aller Projektbeteiligter immer umfassender.
Das Management von Projekten muss der Komplexität gerecht werden. Dies bedeutet, Komplexität zu minimieren und über geeignete Prozessrahmen, Praktiken, Methoden und Technologien beherrschbarer zu machen. Dies bedeutet aber auch Risiken zu reduzieren durch Fokussierung auf das Wesentliche, insbesondere im Bereich der Planung, des Anforderungs- und Qualitätsmanagements.
Dieser Vortrag stellt die Herausforderungen der modernen Softwareentwicklung dar und gibt Antworten auf die Fragen, wie Komplexität z.B. durch agile Prozessrahmen und Methoden beherrschbarer gemacht werden kann und mit welchen Mitteln und Wegen eine hohe Qualität, sowohl in den Prozessen als auch im Produkt, trotz der Risiken, erreicht werden kann.
Anforderungen haben immer Schuld! Schuld an schlechten Tests, Schuld an schlechter Entwicklung, Schuld für viele Änderungen, Schuld an einfach allem. Wie macht man also gutes Anforderungsmanagement und schafft es dadurch noch Komplexität zu reduzieren und so Softwareprojekte einfacher zu gestalten? Wie kriegt man den Kunden dazu seine 1000-seitigen Lastenhefte zu entsorgen und durch etwas Geeigneteres zu ersetzen? Mittels moderner agiler Verfahren und Praktiken. Wie diese genau aussehen, welche Hindernisse auftauchen können und wie diese aus dem Weg geschafft werden können zeigt dieser Vortrag – immer mit dem Fokus auf Einfachheit und Praktikabilität. Der Vortrag ist gerichtet an Projektleiter, Entwickler, Abteilungs-, Team und Bereichsleiter, Scrum Master, Product Owner, Business Analysten.
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...Mayflower GmbH
Soll ich Entwickler pro Stunde einkaufen? Lohnt es sich für mich, spontan ein Team zu staffen? Brauche ich einen Rockstar-Developer im Team, um die Deadline zu retten?
Woher kommt die Performance von Development-Teams? Ist es wirklich eine magische Eigenschaft von bestimmten Entwicklern, die Produkte erfolgreich macht? Oder kommt herausragende Performance von einer ganz anderer Seite?
Keiner glaubt mehr an die Versprechen aus der IT, weder Druck, Motivation noch ein grösseres Team bringen auch nur etwas Performance. Es gibt viele Fehler in der Software und die Fluktuation geht nach oben. Wie fängt man so ein Projekt ein? Eine Geschichte von den offensichtlichen und nicht so offensichtlichen Dingen, die man dabei berücksichtigen muss - aus dem echten Leben erzählt.
Tools wie JMeter, ab2, WebLOAD oder httperf kennt und nutzt jeder, aber man will nicht die Hand dafür ins Feuer halten, dass es dann auch mit den angestrebten Nutzern produktiv so funktioniert. Mit ein paar Tricks, clever gewählten Use Cases, etwas JMeter und etwas Excel kann man nicht nur eine Aussage über die Performance liefern, sondern auch dafür garantieren, dass es zu 99,99 Prozent so passieren wird.
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
Mit Aufwandsschätzungen machen es sich Software-Entwicklungsteams zurecht schwer: Der Kunde will vorweg wissen, was ein neues Feature in seiner Software kostet. Selbst wenn wir den genannten Betrag (Aufwand) explizit als Schätzung deklarieren, wissen wir doch, was passieren wird: Im Nachhinein nagelt uns der Kunde darauf fest. Das versucht man in der agilen Software-Entwicklung zu umgehen und beschätzt deshalb keine Aufwände, sondern die Komplexität eines Features in Relation zu den anderen. Dieser Artikel beschreibt, wie agile Teams schnell zu solchen Schätzungen kommen.
iele Applikationen sind über Jahre erfolgreich gewesen und haben jede Änderung mitgemacht - und sind in Folge unwartbar geworden, und entsprechen längst nicht mehr aktuellen Standards. Doch um weiter am Markt zu bestehen muss man schnell agieren können, also braucht es einen Rewrite auf ein modernes Framework. Aber Rewrites schlagen häufig durch jede Deadline oder ganz fehl, und während des Rewrites muss man auf die Konkurrenz reagieren können. Die Lösung ist ein Continuous Rewrite, der mit der alten Lösung beginnt und bei kontinuierlicher Nutzung mit der neuen Lösung endet. Wir stellen Methoden und Praxiserfahrungen vor.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Wie erkläre ich einem klassischen Manager, warum Programmierer effizienter werden, wenn sie mit zwei Leuten an der gleichen Aufgabe sitzen? Warum ein Programmierer in 14 Stunden täglich nicht mehr schafft als in 8, warum ein Team schneller wird, wenn man das Programmiergenie entfernt. Warum man effizienter wird, wenn man Low-Prio-Tasks vor High-Prio-Tasks macht und nur 6 von 8 Stunden planen will.
Meine! Deine! Keine! Verantwortung in agilen TeamsFrank Düsterbeck
In dieser Session übernehmen wir Verantwortung. Verantwortung dafür, intensive praktische Impulse zu geben.
Wir nehmen Bezug auf die Theorie und klären, unter welchen Voraussetzungen Menschen Verantwortung annehmen / ablehnen und ob Verantwortung teilbar ist.
Wir ergründen, welche Verantwortung in agilen Teams liegt.
Wir machen deutlich, welche Auswirkungen diese Erkenntnisse auf Führung hat.
Mit anderen Worten: Wir schaffen Klarheit darüber, was geschehen muss, damit Verantwortung von allen Menschen angenommen werden kann.
Liquide Rollen statt fixer Positionen
- Warum klassische Positionen –inklusive Führungspositionen – Schaden anrichten
- Wie eine liquide Rollenverteilung in der Praxis aussieht
- Welche Vorrausetzungen braucht es, wie organisiert man Führung und Karriere
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
In dieser Session wird mit verbreiteten Irrtümern, falschen Versprechen und falsch verstandenen Philosophien aufgeräumt.
Es geht um die freie Zeit, die ein ScrumMaster hat. Um den Unterschied zwischen Agilität und inkrementellem Arbeiten.
Es geht um feste Preise und Termine. Darum, was Velocity wirklich bedeutet.
Warum Aufwand eine Rolle spielt und wer mit wem darüber reden darf.
Es geht um glückliche Entwickler, Kunden und Manager. Glückliche Manager, die skalieren. Und wozu man Manager benötigt.
Es geht um Kultur.
Darum, was geschätzt wird und warum KPIs Projekte töten.
Es geht um Business Value und warum Agilität gerade erst anfängt.
Wenn ITler Verträge machen steht der Schutz des eigenen Hinterteils im Vordergrund, und in Wahrheit versteht keiner die Konsequenzen des geschriebenen. Am Ende wird er ohnehin nichtig und durch einen Vergleich ersetzt, bei dem Anwälte das Bauchgefühl der Mandanten verhandeln, um nicht bei einem vollständig sachfremden Richter ein blaues Wunder zu erleben. Aber was hilft dann, wenn der Inhalt eines Projektes erst am Ende wirklich feststeht, und die meisten schwierigen Fragen sich erst im Verlauf ergeben?
Vortrag am 20.09.2012 bei Immobilien-Scout in Berlin zum Thema "Portfolio-Kanban".
Wie kann ich mehrere Teams im Überblick behalten und synchronisieren mit Kanban?
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Wer als Entwickler Führungskraft werden möchte - oder noch schlimmer - von anderen zu erklärt wird, hat einen langen und schmerzhaften Weg vor sich. Und die Erfolgsquote, das belegen die eigenen Vorgesetzten jeden Tag, ist nicht hoch. Viele gute Pläne und logische Schlussfolgerungen funktionieren in der Praxis nicht mehr, und die kollegiale Unterstützung wird durch Politik ersetzt. Die schönsten instinktiven Fehler, die besten Katastrophen nach Lehrbuch und Methode werden von jemanden vorgestellt, der sie schon alle gemacht hat.
Die modernisierte Fassung der "Management Brainfucks": Warum wehren sich Manager gegen agile Methoden, obwohl diese zu ihrem Vorteil wären? Warum behindern sie uns Entwickler bei der Arbeit mit Formalien, Blaming, naiven Lösungsvorschlägen und Kontrollillusion? Der Talk zeigt die Wurzeln dieses Missverständnisses und wie man sich darausbewegt.
keynote beim TECHNOLOG im ars electronica center, 21.5.2012
some quotes are used without reference; most of them come from bill buxton. this was made clear during the talk.
Der 10 Minute Story Profiler! Das beste Storytelling Framework der Welt!PatrickKappeler
Der ultimative Profiler, mit dem Sie in 10 Minuten relevante Geschichten schmieden. Das beste Storytelling Framework nach der P+ Methode, das Sie im Netz finden werden.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Wie erkläre ich einem klassischen Manager, warum Programmierer effizienter werden, wenn sie mit zwei Leuten an der gleichen Aufgabe sitzen? Warum ein Programmierer in 14 Stunden täglich nicht mehr schafft als in 8, warum ein Team schneller wird, wenn man das Programmiergenie entfernt. Warum man effizienter wird, wenn man Low-Prio-Tasks vor High-Prio-Tasks macht und nur 6 von 8 Stunden planen will.
Meine! Deine! Keine! Verantwortung in agilen TeamsFrank Düsterbeck
In dieser Session übernehmen wir Verantwortung. Verantwortung dafür, intensive praktische Impulse zu geben.
Wir nehmen Bezug auf die Theorie und klären, unter welchen Voraussetzungen Menschen Verantwortung annehmen / ablehnen und ob Verantwortung teilbar ist.
Wir ergründen, welche Verantwortung in agilen Teams liegt.
Wir machen deutlich, welche Auswirkungen diese Erkenntnisse auf Führung hat.
Mit anderen Worten: Wir schaffen Klarheit darüber, was geschehen muss, damit Verantwortung von allen Menschen angenommen werden kann.
Liquide Rollen statt fixer Positionen
- Warum klassische Positionen –inklusive Führungspositionen – Schaden anrichten
- Wie eine liquide Rollenverteilung in der Praxis aussieht
- Welche Vorrausetzungen braucht es, wie organisiert man Führung und Karriere
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
In dieser Session wird mit verbreiteten Irrtümern, falschen Versprechen und falsch verstandenen Philosophien aufgeräumt.
Es geht um die freie Zeit, die ein ScrumMaster hat. Um den Unterschied zwischen Agilität und inkrementellem Arbeiten.
Es geht um feste Preise und Termine. Darum, was Velocity wirklich bedeutet.
Warum Aufwand eine Rolle spielt und wer mit wem darüber reden darf.
Es geht um glückliche Entwickler, Kunden und Manager. Glückliche Manager, die skalieren. Und wozu man Manager benötigt.
Es geht um Kultur.
Darum, was geschätzt wird und warum KPIs Projekte töten.
Es geht um Business Value und warum Agilität gerade erst anfängt.
Wenn ITler Verträge machen steht der Schutz des eigenen Hinterteils im Vordergrund, und in Wahrheit versteht keiner die Konsequenzen des geschriebenen. Am Ende wird er ohnehin nichtig und durch einen Vergleich ersetzt, bei dem Anwälte das Bauchgefühl der Mandanten verhandeln, um nicht bei einem vollständig sachfremden Richter ein blaues Wunder zu erleben. Aber was hilft dann, wenn der Inhalt eines Projektes erst am Ende wirklich feststeht, und die meisten schwierigen Fragen sich erst im Verlauf ergeben?
Vortrag am 20.09.2012 bei Immobilien-Scout in Berlin zum Thema "Portfolio-Kanban".
Wie kann ich mehrere Teams im Überblick behalten und synchronisieren mit Kanban?
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Wer als Entwickler Führungskraft werden möchte - oder noch schlimmer - von anderen zu erklärt wird, hat einen langen und schmerzhaften Weg vor sich. Und die Erfolgsquote, das belegen die eigenen Vorgesetzten jeden Tag, ist nicht hoch. Viele gute Pläne und logische Schlussfolgerungen funktionieren in der Praxis nicht mehr, und die kollegiale Unterstützung wird durch Politik ersetzt. Die schönsten instinktiven Fehler, die besten Katastrophen nach Lehrbuch und Methode werden von jemanden vorgestellt, der sie schon alle gemacht hat.
Die modernisierte Fassung der "Management Brainfucks": Warum wehren sich Manager gegen agile Methoden, obwohl diese zu ihrem Vorteil wären? Warum behindern sie uns Entwickler bei der Arbeit mit Formalien, Blaming, naiven Lösungsvorschlägen und Kontrollillusion? Der Talk zeigt die Wurzeln dieses Missverständnisses und wie man sich darausbewegt.
keynote beim TECHNOLOG im ars electronica center, 21.5.2012
some quotes are used without reference; most of them come from bill buxton. this was made clear during the talk.
Der 10 Minute Story Profiler! Das beste Storytelling Framework der Welt!PatrickKappeler
Der ultimative Profiler, mit dem Sie in 10 Minuten relevante Geschichten schmieden. Das beste Storytelling Framework nach der P+ Methode, das Sie im Netz finden werden.
1960 brachte Milton Bradley “Das Spiel des Lebens” heraus: Ein feuchter Kapitalistentraum von Brettspiel, bei dem der gewann, der mit viel Glück als Reichster den Ruhestand erreichte. Heute machen “Gamification”-Anbieter Ernst mit dem Lebens-Spiel: Vom Abnehmen bis zur Rettung von Afrika, vom TV-Show-Gucken bis zum DNA-Sequenzabgleich: Keine Tätigkeit, die nicht durch Punkte, Abzeichen und andere Elemente aus Computerspielen spaßiger und motivierender gestaltet werden könnte – so ihr Versprechen.
Dabei ist die Debatte über “Gamification” tief gespalten: Auf der einen Seite stehen feuchte Vermarkter-Träume von der perfekten Kundenbindung, auf der anderen Game Designer, die vor Schlangenölverkäufern und flacher “Punktifzierung” warnen. Wie gestaltet man eine spielerische Erfahrung, die für Nutzer wirklich relevant ist – statt nur flüchtige Neuigkeitsreize zu schaffen? Welche Lektionen halten Spiele für andere Produkte und Anwendungen tatsächlich bereit? Welche Kritik ist gerechtfertigt? Und wie können Designer, die an der “Gamifizierung” einer Anwendung interessiert sind, die gefährlichsten Untiefen umschiffen? Der Vortrag gibt eine Übersicht über die aktuelle “Gamification”-Bewegung und zeigt Potenziale und Prinzipien ebenso wie blinde Flecken und Gefahren auf.
Entitäten basierte Suche Teil 2: Alles was Du zum Knowledge Graph, Indexierun...Olaf Kopp
Philip Ehring und Olaf Kopp nehmen Euch in diesem Deep Dive mit auf die Reise in die Welt moderner Suchmaschinen.
Auf der Basis wissenschaftlicher Theorien und Google-Patenten wird erklärt wie Google heute funktionieren kann und zukünftig immer mehr funktionieren wird.
Zudem gibt Euch Philip aus der Data Science Perspektive Einblicke zum Thema moderner Text-Embeddings (z.B. BERT) und wie entsprechende Systeme in der Praxis innerhalb der Otto-Gruppe eingesetzt werden.
Typische Lügen im Projektmanagement | Ralf C. AdamRalf C. Adam
Dieser Vortrag wurde im August 2006 im Rahmen der GCDC Game Developer’s Conference in Leipzig/GERMANY gehalten (Übersetzung des "7 Lies my Project Manager told me" Vortrags)
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
DoPI – endlich Projekte vernünftig starten mit der Definition of Project Init...Frank Düsterbeck
Keine Lust mehr auf schlecht initialisierte Projekte? Keine Lust mehr, Fehler mühsam auszubügeln, die beim Projektstart gemacht wurden? Keine Lust mehr auf unnützen Stress? DoPI richtet sich an alle, die Projekte initialisieren oder unter einer schlechten Initialisierung leiden (also an alle). DoPI zeigt, wie man sich mittels ihrer gut auf die Unsicherheiten der Produktherstellung vorbereitet und gibt Impulse, wie man Unwissen zu Wissen, Ungewissheit zu Gewissheit und Risiko zu Chance werden lässt. Das Wissen um komplexe Systeme hilft dabei, ein tiefes Verständnis für die Projektinitialisierung zu gewinnen.
Agil ist klasse. Agile Praktiken, agile Prozesse, agile Organisationen, agile Menschen. Aber was bedeutet Agilität wirklich? Was soll denn eine agile Organisation sein, wenn sich das Manifest doch nur auf Softwareentwicklung bezieht? Kann man Agil uminterpretieren/erweitern oder gibt es da etwas, was zur lernenden Organisation führt? Diese Keynote gibt Impulse, was Agilität bedeutet und zeigt, das Agilität leider nicht genug ist.
„Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams“. Dieses Prinzip aus dem Manifest für agile Softwareentwicklung basiert auf Erkenntnissen des menschlichen Zusammenwirkens, die uralt sind. Selbstorganisation eignet sich als Organisationsform hervorragend, um den Herausforderungen einer komplexen und dynamischen Umwelt gerecht zu werden. Durch Selbstorganisation entstehen aber auch Probleme. Probleme, die dazu führen können, dass Selbstorganisation ins Chaos führt und Menschen darunter leiden. Was Selbstorganisation bedeutet, welche Voraussetzungen gegeben sein müssen, welche neuen Herausforderungen entstehen und wie ein Team dorthin kommt, beleuchtet diese Session am konkreten Beispiel diverser Teams.
Den Begriff Digitalisierung kann schon keiner mehr hören. Agil ist auch verbrannt und Macht und Management darf man gar nicht mehr sagen. Na gut, dann eben anders aber besser. Was ist denn die Grundlage für den Hype dieser Buzzwords – sie scheinen ja nicht ganz unberechtigt zu existieren. Und wie geht es besser? Genau das wird in diesem Talk behandelt.
Es wird gezeigt was hinter dem ganzen steht und so ein tiefes Verständnis und Bewusstsein erzeugt. Basierend hierauf werden Antworten gegeben, wie den Herausforderungen der Postmoderne und des Innovationswettbewerbs entgegen getreten werden kann. Hierzu wird auf Organisation á la Heterarchie, Führung zur Selbstführung, Macht und Verantwortung eingegangen und am Beispiel der HEC gezeigt, mit welchen Schmerzen und Freuden dieses Unternehmen in der Postmoderne angekommen und adaptionsfähig geworden ist.
Agil ist klasse. Agile Praktiken, agile Prozesse, agile Organisation, agile Menschen. Aber was bedeutet Agilität wirklich? Wie wird man agil, oder geht das gar nicht, weil der Rahmen nicht passt? Diese Session klärt auf, was Agilität auf welcher Ebene bedeutet. Sie gibt Rat, wie sich ein Team und/oder eine Organisation entwickeln kann und wie bei der Führung oder den Mitarbeitern Bewusstsein geschaffen wird. Besonderes Augenmerk wird auf Hürden und Hindernisse gelegt und wie das Tal der Tränen (das kommen wird) überwunden werden kann.
Willkommen in der Postmoderne - Organisation und Führung im Innovationswettbe...Frank Düsterbeck
Den Begriff Digitalisierung kann schon keiner mehr hören. Agil ist auch verbrannt und Macht und Management darf man gar nicht mehr sagen. Na gut, dann eben anders aber besser. Was ist denn die Grundlage für den Hype dieser Buzzwords – sie scheinen ja nicht ganz unberechtigt zu existieren. Und wie geht es besser? Genau das wird in diesem Talk behandelt.
Es wird gezeigt was hinter dem ganzen steht und so ein tiefes Verständnis und Bewusstsein erzeugt. Basierend hierauf werden Antworten gegeben, wie den Herausforderungen der Postmoderne und des Innovationswettbewerbs entgegen getreten werden kann. Hierzu wird auf Organisation á la Heterarchie, Führung zur Selbstführung, Macht und Verantwortung eingegangen und am Beispiel der HEC gezeigt, mit welchen Schmerzen und Freuden dieses Unternehmen in der Postmoderne angekommen und adaptionsfähig geworden ist.
Die Zusammenarbeit des Scrum-Teams – Soziale Herausforderungen als Chance und...Frank Düsterbeck
Scrum stellt hohe Anforderungen an die sozialen Fähigkeiten von allen am Prozess beteiligten Personen. Gemeinsam als Team sind Tester, Entwickler etc. für die Produktion verantwortlich. Für den einen ist das spannend, für den anderen ist es bedrohlich. Auf jeden Fall müssen Menschen in einem Scrum-Team aus ihrer Komfortzone raus, und das schafft Raum für alte und neue Konflikte. Der Vortrag beleuchtet die notwendigen Veränderungen immer mit Blick auf die betroffenen Menschen und stellt Herausforderungen, Chancen und Risiken gegenüber.
Scrum ist gelebtes Qualitätsmanagement und zum Qualitätsmanagement gehört das Testen. Wie genau spielt das Testen in Scrum mit? Welche Arten und Stufen von Tests gibt es und wie können diese den Scrum Prozess unterstützen oder sogar behindern? Was machen Teams hierbei gerne falsch und können klassische Testverfahren behilflich sein die Qualität zu verbessern? Diese Fragen werden in dem Vortrag diskutiert, beantwortet und bewertet.
4. Was muss ich wann tun?
1. Handlungsschritt
2. Handlungsschritt
3. Handlungsschritt
4. …
Was brauch ich?
1. Mittel
2. Menschen
3. Geld
4. …
Was will ich erreichen?
Vision Produkt
E N T S C H E I D U N G S G R U N D L A G E
14. Komplexitätstreiber
Anforderungen ändern sich
Neue Technologien
Neue Prozesse und Methoden
Team kennt sich nicht
Wechselnde Teammitglieder
Stakeholder Interessen
Echtzeit Chancen und Risiken
Gelerntes nicht 1:1 anwendbar
Alter Code
Infrastruktur
20. DAS AGILE QUIZ
Auf komplexe Sachverhalte mit komplexen
Methoden zu reagieren ist falsch, weil...
DAS
AGILE
QUIZ
???...sich dadurch die Komplexität
weiter erhöht!
27. VisionZiel des Projektes
Erstellung eines Produktes
Ergebnis des Produktes
Welche Veränderung soll erzielt werden?
Nutzen des Produktes
Welche Verbesserung soll aus dem
Ergebnis resultieren?
Zielgruppe
Wer soll mit dem Produkt arbeiten?
Business
Case
28. Ein Satz zu
meiner Vision
Meine
neuen Stärken
Wer möchte
was und wozu
Die
„messbaren“
Ziele
Meine
Stakeholder
Risiken und
Chancen
Als wer
Möchte ich was
ganz großes
Damit wozu
Als wer
Möchte ich was
ganz großes
Damit wozu
DAS SUPER
PRODUKT
VISION
POSTER
31. Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7
Epos 2
User Story 4 User Story 33
User Story 14User Story 13User Story 3
User Story 1
User Story 6
User Story 2
User Story 5
Status Ready
K O M P L E X I TÄT R E D U Z I E R E N
35. “Value is created
with every Sprint”
“The product increment at
the end of a Sprint is
potentially usable”
Und wie geht dann die
Releaseplanung?
Warum dann überhaupt ein
Release?
Weil ein Release auch immer
eine Klammer für Prototypen,
Installation, Migration,
Schulung, Change Management,
usw. ist
40. Das ist mir viel zu
unsicher. Dann müssen
wir genauer schätzen.
Gib mir mal einen
Daumen.
Wir haben grob geschätzt!
Das Projekt hat nen
Aufwand von 15 bis 240
Tagen.
47. Cyril Parkinson: „Arbeit dehnt
sich in genau dem Maß aus,
wie Zeit für ihre Erledigung zur
Verfügung steht.“
Douglas Hofstadter: „Es
dauert immer länger als man
erwartet, selbst wenn man
Hofstadters Gesetz
berücksichtigt.“
48. Bin ich schlecht!
1. Ich schätz nur meine
idealen Nettozeiten.
2. Große Mengen kann ich gar
nicht und komplexe Dinge
krieg ich auch nicht auf die
Reihe.
3. Und eigentlich kann ich eh
nur vergleichen.
54. Toll – und wie sieht die
Releaseplanung jetzt
genau aus?
55. User Story 8
1
2
3
5
8
13
20
40
Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7Epos 2
User Story 4
User Story 33
User Story 14
User Story 13
User Story 3
User Story 5
User Story 6
User Story 2
User Story 1
K O M P L E X I TÄT R E D U Z I E R E N
User Story 25
User Story 14 User Story 15
TEAM ESTIMATION GAME
59. Muss die Summe der
Schätzung von
zerlegten Stories
eigentlich gleich der
original Story sein?
60. Als wer
Möchte ich was
großes
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu
Als wer
Möchte ich was
Damit wozu≠∑
61. …
OK und weiter? Wie geht jetzt
die Releaseplanung?
Wir gehen erstmal davon
aus, dass wir so 12 Story
Points pro Sprint schaffen
und messen was wir
wirklich hinkriegen.
77. Und was soll das kosten?
𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑃 =
𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑝𝑟𝑖𝑛𝑡
𝑉𝑒𝑙𝑜𝑐𝑖𝑡𝑦
78. Projektbudget und -dauer (Soll)
Wartungsbudget (Soll)
Projektbudget und -dauer mit Puffer (Soll)
Zeit
Kosten
Anforderungen
Entwurf
Programmierung
Test
87. DAS AGILE QUIZ
“Wer A sagt, der muss ...
???...nicht B sagen. Er kann auch erkennen,
dass A falsch war.“ (Bertolt Brecht)
DAS
AGILE
QUIZ
Responding to change
over following a plan