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?
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?
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.
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.
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?
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?
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?
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.
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.
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?
Folien vom Lean-Startup-Meetup in Hamburg am 27.05.2013.
Die Präsentation stellt Scrum und Lean-Startup gegenüber, diskutiert, wie sich beide gegenseitig befruchten können und warum Scrum auch für Startups relevant ist.
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
Experimente zur Team- und Organisationsentwicklung (CeBit, Heise Developer Wo...Stefan ROOCK
Der Vortrag argumentiert, dass Veränderungen in Teams und Organisationen nicht linear verlaufen. Veränderungsmaßnahmen haben immer das Potenzial überraschender Ergebnisse. Daher benötigt man einen iterativen Prozess für Veränderungen und die Einsicht, dass ein relevanter Anteil von vermeintlichen Verbesserungen tatsächlich schlechte Ideen sind. Das Arbeiten mit Experimenten macht diese Sichtweise explizit und fokussiert darauf, wie Lernen bei Veränderungsprozessen maximiert werden kann.
Safe-to-Fail-Experimente, der PDCA-Zyklus und die A3-Technik sind gute Hilfsmittel, um Teams und Organisationen mit Experimenten erfolgreich zu verändern.
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.
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.
Unsere Anti-Pattern Karten sind aus unserer jahrelangen Arbeit mit Kunden, und den daraus gewonnenen Erfahrungen entstanden. Sie sollen euch dabei helfen, selbst Fettnäpfchen zu erkennen, die wir schon von außen erlebt haben, oder in die wir sogar teilweise selbst schon getreten sind. Wenn ihr noch andere Anti-Patterns kennt, dann schickt sie uns unter https://mayflower.de/agile-antipattern.
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)
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgStefan ROOCK
Der Vortrag zeigt verschiedene Facetten von Scrum und verdeutlicht, dass es nicht die eine richtige Anwendung von Scrum gibt. Die Product Owner-Rolle muss ganz unterschiedlich ausgestaltet werden, abhängig vom Innovationsgrad der Entwicklung. Der Scrum Master muss seinen Führungsstil an die Reife des Teams anpassen. Und die Zusammensetzung des Teams hängt vom Unsicherheitsprofil des Projektes ab.
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.
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!Matthias Bohlen
"Chef, Sie wollen schon wieder Doku von mir? Warum sollte ich die schreiben? Meine Teamkollegen und ich wissen schließlich auch ohne Doku, wie das System funktioniert und wo wir etwas ändern müssen. Doku hält mich nur vom Arbeiten ab! Und ... seien Sie mal ehrlich: Sie ist noch jedesmal runterpriorisiert worden, wenn es zeitlich eng wurde, also kann sie ja wohl nicht wichtig sein." -- Wollten Sie schon einmal solch einen Brief an Ihren Chef schreiben? Und haben dann doch zähneknirschend Ihr Word geöffnet? Lassen Sie sich in dieser praxisorientierten Session zeigen, wie Sie Architekturdokumentation mit Lust und minimalem Aufwand gestalten können (Gerüchte besagen, dass Markdown darin eine Rolle spielen wird).
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.
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?
Im Vortrag werden verschiedene Teamentwicklungs-Modelle vorgestellt und diskutiert. Enthalten sind die Modelle von Tuckman, Belbin und Hackman. Die Modelle werden jeweils einem kurzen Praxis-Check unterzogen. Soll heißen ich stelle mir die Frage: "Wie hilft mir dieses Modell in meiner täglichen Arbeit weiter?"
Folien vom Lean-Startup-Meetup in Hamburg am 27.05.2013.
Die Präsentation stellt Scrum und Lean-Startup gegenüber, diskutiert, wie sich beide gegenseitig befruchten können und warum Scrum auch für Startups relevant ist.
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
Experimente zur Team- und Organisationsentwicklung (CeBit, Heise Developer Wo...Stefan ROOCK
Der Vortrag argumentiert, dass Veränderungen in Teams und Organisationen nicht linear verlaufen. Veränderungsmaßnahmen haben immer das Potenzial überraschender Ergebnisse. Daher benötigt man einen iterativen Prozess für Veränderungen und die Einsicht, dass ein relevanter Anteil von vermeintlichen Verbesserungen tatsächlich schlechte Ideen sind. Das Arbeiten mit Experimenten macht diese Sichtweise explizit und fokussiert darauf, wie Lernen bei Veränderungsprozessen maximiert werden kann.
Safe-to-Fail-Experimente, der PDCA-Zyklus und die A3-Technik sind gute Hilfsmittel, um Teams und Organisationen mit Experimenten erfolgreich zu verändern.
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.
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.
Unsere Anti-Pattern Karten sind aus unserer jahrelangen Arbeit mit Kunden, und den daraus gewonnenen Erfahrungen entstanden. Sie sollen euch dabei helfen, selbst Fettnäpfchen zu erkennen, die wir schon von außen erlebt haben, oder in die wir sogar teilweise selbst schon getreten sind. Wenn ihr noch andere Anti-Patterns kennt, dann schickt sie uns unter https://mayflower.de/agile-antipattern.
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)
Shades of Scrum (Urs Reupke, Stefan Roock), SEACON 2015 in HamburgStefan ROOCK
Der Vortrag zeigt verschiedene Facetten von Scrum und verdeutlicht, dass es nicht die eine richtige Anwendung von Scrum gibt. Die Product Owner-Rolle muss ganz unterschiedlich ausgestaltet werden, abhängig vom Innovationsgrad der Entwicklung. Der Scrum Master muss seinen Führungsstil an die Reife des Teams anpassen. Und die Zusammensetzung des Teams hängt vom Unsicherheitsprofil des Projektes ab.
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.
WJAX 2014: Pah, ArchitekturDoku, darauf habe ich keine Lust!Matthias Bohlen
"Chef, Sie wollen schon wieder Doku von mir? Warum sollte ich die schreiben? Meine Teamkollegen und ich wissen schließlich auch ohne Doku, wie das System funktioniert und wo wir etwas ändern müssen. Doku hält mich nur vom Arbeiten ab! Und ... seien Sie mal ehrlich: Sie ist noch jedesmal runterpriorisiert worden, wenn es zeitlich eng wurde, also kann sie ja wohl nicht wichtig sein." -- Wollten Sie schon einmal solch einen Brief an Ihren Chef schreiben? Und haben dann doch zähneknirschend Ihr Word geöffnet? Lassen Sie sich in dieser praxisorientierten Session zeigen, wie Sie Architekturdokumentation mit Lust und minimalem Aufwand gestalten können (Gerüchte besagen, dass Markdown darin eine Rolle spielen wird).
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.
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?
Im Vortrag werden verschiedene Teamentwicklungs-Modelle vorgestellt und diskutiert. Enthalten sind die Modelle von Tuckman, Belbin und Hackman. Die Modelle werden jeweils einem kurzen Praxis-Check unterzogen. Soll heißen ich stelle mir die Frage: "Wie hilft mir dieses Modell in meiner täglichen Arbeit weiter?"
Die Grenzen und Potenziale Ihres Kartenmanagementsystems entscheiden mit über Ihren Erfolg im Markt. Der Veränderungsdruck ist hoch. Die Regulierung steigt, klassische Erlösmodelle werden attackiert, Produkte müssen häufiger optimiert und schneller angepasst werden. Ein veraltetes System wird hier zum Hindernis. Es bietet nicht die erforderliche Flexibilität und verursacht hohe Kosten bei Hosting und Wartung. Wir checken es für Sie durch und geben Handlungsempfehlungen. Auf Wunsch übernehmen wir die Optimierung. Damit Ihr Markterfolg dauerhaft gesichert bleibt.
Diese Präsentation leitet ein Coding-Dojo ein.
Die Folien dienen der Motivation und der Einordnung der Bedeutung des Testens in der Softwareentwicklung.
Agile Softwareentwicklung ohne Agiles Denken ist zum Scheitern verurteiltAllFacebook.de
Vortrag "Agile Softwareentwicklung ohne Agiles Denken ist zum Scheitern verurteilt" von Nhan Trí Vũ auf der AllFacebook Marketing Conference 2013 in Berlin.
Mehr Informationen zur Konferenz und zum Slot:
http://conference.allfacebook.de/devcon/berlin2013/programm/#12
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Stephan Volmer
Ein bekanntes Szenario in IT-Abteilungen größerer Unternehmen ist die Entwicklung vieler fachlich unterschiedlicher Applikationen auf einer gemeinsamen technischen Basis. Im Lebenszyklus dieser Applikationen sind oft unterschiedliche Teams für Entwicklung und Wartung zuständig. Um dennoch eine effiziente Arbeit gewährleisten zu können, werden die Applikationen gerne auf ein Framework aufgesetzt, das vor Beginn der eigentlichen Applikationsentwicklung in einem eigenen Projekt erstellt wird. Solche Projekte sind teuer und zeitaufwändig. Sie erzeugen keinen direkten Mehrwert für das Geschäft des Unternehmens. Außerdem besteht die Gefahr, dass sie den tatsächlichen Anforderungen bei der Entwicklung der eigentlichen Applikationen nicht gerecht werden.
Ein anderer Ansatz ist es, aus der Entwicklung einer oder mehrerer Geschäftsapplikationen inkrementell-iterativ wiederverwendbare Artefakte in Form eines Architektur-Baukastens zu erzeugen. Der Vortrag zeigt, wie sich mit dieser Vorgehensweise die Ramp-Up-Zeit für neue Projekte von fünf Monaten auf fünf Minuten verkürzen lässt. Sie wissen nach dem Vortrag wie das geht!
Presentation given at the ASpB Conference in Karlsruhe, Germany (in German) ASpB = Arbeitsgemeinschaft der Spezial-Bibliotheken (Workinggroup for special libraries)
Design Pattern Libraries, Aufzucht und PflegeWolf Brüning
Die Präsentation als Artikel: http://www.produktbezogen.de/bauanleitung-pattern-library-1/
An english version is available here: http://de.slideshare.net/WolfBruening/how-to-build-the-perfect-pattern-libraryy
Lean Development = Überdrehter Motor in der Entwicklung?Matthias Bohlen
In letzter Zeit schwappt die “Lean”-Welle aus der Fertigung in die Softwareentwicklung herüber. Begriffe wie Kanban, WIP-Limit, Lead Time, Varianz, Durchsatz kommen auch bei uns Entwicklern und unseren Managern in Mode. Heißt das, wir messen, kontrollieren und takten unsere Arbeit wie im Zeitraffer? Es wird Zeit, sich von gängigen Missverständnissen zu trennen und auf dem Teppich zu bleiben.
Ketzerischer Vortrag zur Agilen Entwicklung Thomas Arends
Agile wurde nur entwickelt weil man das V-Modell nicht verstanden hat.
Vortrag um sich Feinde zu machen.
Youtube Video dazu hier https://youtu.be/W8TpeWBctKQ
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
FMK2015: Strukturierte Namensgebung als Basis für komplexe Programmierung by ...Verein FM Konferenz
Strategien und Best-Practise für die Namensgebung von Feldern, Beziehungen und Layouts.
Ziele sind:
- Teamkollegen und nachfolgende Programmierer sollen die Programmierung gut nachvollziehen können.
- der Überblick soll auch bei wachsenden Anwendungen und steigender Komplexität bestehen bleiben.
- Wie wird eine Historie der Veränderungen erstellt? Wie arbeitet man effizient im Team?
- Schrittweise Entwicklung der Regeln, deren Optimierung
- Beispiel
- Anwendungs Beispiele
- Grenzen der Regeln
- Fallen und Fehlerquellen
- Diskussion / Fragen
Vortrag erklärt die Vorraussetzungen für 2. Teil: Aufbau von eigener FrameWorks in FileMaker
Dieser Vortrag wurde von mir im Mai 2018 im Rahmen der German Dev Days in Frankfurt gehalten. Er beschäftigt sich damit, wie man sich als Developer vor (vermeintlicher) Publisher-Wilkür schützen kann.
In diesem Vortrag stelle ich meine Sicht auf die derzeitige Verbreitung von Perl in Hamburg dar. Diese Sicht ist geprägt von mehreren Versuchen, Hamburg.pm wieder Leben einzuhauchen, neue Mitglieder für ein Team zu finden, das sich um ein altehrwürdiges Produkt kümmert, und der (Un-)Sichtbarkeit von Firmen, die Perl einsetzen.
Diesen Vortrag habe ich anlässlich des 19. Deutschen Perl Workshops am 27. Juni 2017 in Hamburg gehalten.
Das Web Wird Mobil - Geolocation und Location Based ServicesStephan Schmidt
Vortrag auf der International PHP Conference 2012 Spring Edition zu Geolocation im Browser und Location Based Services wie Google Places und Foursquare
1. 23 Dinge,
die Sie über Entwicklung in Teams wissen sollten
Stephan Schmidt
1&1 Internet AG
2. Stephan Schmidt
• Software-Entwickler und "Beinahe Pädagoge"
• Kombiniert gerne beides im Beruf
• Head of Web Sales Development bei der
1&1 Internet AG
• Autor, Redner und die ganzen anderen
Sachen
• (außer Consultant)
3. "Yogi" Berra
• Bürgerlicher Name Lawrence Peter Berra
• Spielte von 1946 bis 1964 professionellen
Baseball in der Major League
• Kein anderer hat die World Series so oft
erreicht und gewonnen
• Bekannt für seine Yogiisms
• Auch kein Consultant
• Eventuell auch Namensgeber für
Yogi-Bear
4. "In theory there is no
difference between theory
and practice.
In practice there is."
Yogi Berra
5. Theorie vs Praxis
• Die Präsentation beruht auf meiner
Erfahrung.
• Die Regeln funktionieren in meinen Teams.
• Einige funktionieren in allen Teams, andere
abgewandelt oder auch gar nicht.
• Versuchen Sie, das heute theoretisch
vermittelte Wissen in Ihrer Praxis
anzuwenden.
9. Collective Code Ownership
• Aus dem Extreme Programming.
• Der gesamte Code gehört allen Entwicklern.
• Alle Entwickler sind dazu aufgefordert an
allen Stellen Bugs zu fixen, Refactorings
durchzuführen oder neue Ideen einzubringen.
• Vermeidet Flaschenhälse in ihrem Team.
• Macht den Code besser.
• Sie profitieren von den Stärken aller
Teammitglieder.
11. Revisionskontrolle
• Nur dadurch werden parallel Änderungen
an einem Projekt möglich.
• Es ist egal, welches System Sie einsetzen,
aber tun Sie's.
• CVS
• Subversion
• GIT
• Team Foundation Server
• etc.
14. Standardisierung
• Spart Zeit, wenn eine neue Instanz benötigt
wird.
• Idealerweise installiert die EDV-Abteilung
nur noch ein Image für PHP Entwickler
• In vielen Unternehmen schwer einzuführen,
da das Thema religiöse Sprengkraft hat.
• Ist den Stress der Diskussion jedoch trotzdem
wert.
• In unserem Team noch 1 Stunde statt
2 Tagen
16. Coding Standards
• Spart Zeit, da sich jeder Entwickler im Code
der anderen Entwickler zurecht findet.
• Hier gilt wieder: Es ist egal, welchen Standard
Sie einsetzen, aber tun Sie's.
• PEAR Coding Standards
• Zend PHP Coding Standards
• Eigene Coding Standards
18. Standards forcieren
• Coding Standards sind nur sinnvoll, wenn
sie eingehalten werden.
• Statische Code-Analyse mit PHP_CodeSniffer
überprüft den gesamten Code auf Regel-
verletzungen.
• Sinnvoll: Integration in den Build-Prozess und
die IDE.
• Umstritten: Integration in SVN Pre-Commit-
Hooks oder Deployment.
20. Code Reviews
• Sind nicht einfach einzuführen, Entwickler
sind sensible Geschöpfe.
•Sie schlagen zwei Fliegen mit einer Klappe:
• Ihr Code wird besser.
• Sie lernen voneinander.
• Ihr Team hält besser zusammen.
OK, das waren drei.
22. Reproduzierbare Builds
• Spart Ihnen Zeit (ja, schon wieder).
• Spart Ihnen Ärger.
• Bei jedem neuen Mitarbeiter müssen diese
Schritte ausreichen:
$ svn co http://example.com/svn/trunk project
$ cd project
$ phing || ant || make
$ // evtl. Apache Config einbinden
$ ./start.sh
24. #8
Tests erlauben Ihrem
Team die Freiheit, Code zu
ändern.
25. Testen des Codes
• Im Team wird der Code von verschiedenen
Entwicklern erstellt oder modifiziert.
• Tests ermöglichen Entwicklern zu prüfen
ob die Änderungen negative Auswirkungen
hatten.
• Tests nehmen dem Team die Angst,
Änderungen durchzuführen.
• Tests sind außerdem eine gute
Dokumentation.
• Mit "Tests" meine ich nicht manuelle Tests.
28. Continuous Integration
• Build wird in regelmäßigen Abständen oder
nach jedem Commit angestoßen.
• Dabei wird immer ein vollständiger Build
erzeugt und alle Unit- und Integrationstests
ausgeführt.
• Fehler werden dadurch sofort entdeckt und
nicht verschleppt.
• Verhindert das Auftreten des "Broken
Window" Phänomens.
• Bereits einige Lösungen für PHP vorhanden.
37. #12
Kommunikation
entscheidet in den
meisten Projekten über
Erfolg und Niederlage.
38. Kommunikation
• Verstehen die Entwickler, was der Kunde
möchte?
• Versteht der Kunde, was der Entwickler
liefern kann?
• Verstehen die Entwickler gegenseitig
wirklich, wie die Schnittstellen aussehen?
• Verstehen die Entwickler, was die
Qualitätssicherung braucht?
39. "It was hard to have a
conversation with anyone;
there were so many people
talking. " Yogi Berra
40. #13
Sorgen Sie dafür, dass
genug Möglichkeiten zur
Kommunikation
geschaffen werden.
41. Kommunikationsmittel
• Treffen von Angesicht zu Angesicht
• Treffen von Angesicht zu Angesicht
• Treffen von Angesicht zu Angesicht
• E-Mails und Instant Messenger
• Projekt-Blogs
• Microblogging / Twitter
• Telefonkonferenzen
• Videokonferenzen
45. Teambildung
• Gemeinsame private Erlebnisse stärken
das Teamgefühl und fördern die
Zusammenarbeit.
• Das gilt nicht nur für gemeinsame Essen,
jedoch ist der Effekt dabei besonders groß.
• Schaffen Sie Rituale.
51. Prozessmodelle
• Wasserfall-Modell
• Hat in meinen Projekten noch nie
funktioniert.
• Agile Prozesse
• Versprechen deutlich höhere Erfolgs-
chancen.
• Bitte nicht sklavisch einhalten.
• Sprechen Sie nicht nur von Chickens,
Scrum-Master, etc.
53. Verschiedene Prozesse
• Der offizielle Prozess
• entspricht so gut wie nie der Realität.
• Der wahrgenommene Prozess
• ist meist Kombination aus
Wunschdenken und Fehlinterpretation.
• Der tatsächliche Prozess
Machen Sie den Prozess,
der dafür sorgt, dass Sie zu
Lösungen kommen explizit.
54. "If you don't know where
you're going, you'll wind
up somewhere else."
Yogi Berra
55. #18
Sitzen Sie nicht dem
Irrtum auf, dass "agil" mit
"ungeplant" gleich-
zusetzen ist.
60. #20
Nur Teams, die sich an
Veränderungen anpassen,
sind erfolgreich.
61. Embrace Change
• Die Welt ist im Wandel
• Anforderungen werden sich immer
ändern.
• Technologien und Methodiken auch.
• Nehmen Sie Änderungen freudig an.
• Agile Methoden stellen Ihnen dafür
Werkzeuge zur Verfügung.
62. #21
Hinterfragen Sie
regelmäßig den Status
Quo.
63. Der Status Quo
• Wenn sich sowieso alles ändert, dann
sollten Sie die Änderungen möglichst
früh feststellen.
• Oder besser noch: Stoßen Sie die
Änderungen an.
• Erfinden Sie die Sprache, die PHP im Web
ablöst.
• Die Geschichte "Who moved my cheese?"
von Spencer Johnson hilft Ihnen dabei.
66. Kultur der Angst
"Was wären wir sündigen Kreaturen dann
ohne die Angst, diese vielleicht wohltätigste
und gnädigste Gabe Gottes?"
Umberto Eco, "Der Name der Rose"
67. Kultur der Angst
Sie leben in einer Kultur der Angst, wenn…
• …es gefährlich ist, bestimmte Dinge
auszusprechen.
• …Zielvorgaben so aggressiv sind, dass
diese unmöglich erreicht werden können.
• …Macht über gesunden Menschen-
verstand triumphieren darf.
• …die Leute, die gehen müssen, sind im
Durchschnitt kompetenter als die, die
bleiben.
Aus "Spielräume" von Tom DeMarco
68. " I want to thank you for
making this day
necessary."
Yogi Berra
69. #23
Hören Sie auf Tom
DeMarco, Spencer Johnson
und das Agile Manifest.
70. " I never said most of the
things I said. "
Yogi Berra