Behavior-Driven Development – Problemlos einsetzbar in agilen Bestandsprojekten?

Im Jahr 2012 wurde das Expenditionary Combat Support System der US Air Force nach sieben Jahren und mit Entwicklungskosten von über einer Milliarde Dollar abgeschafft. Als Grund wird angegeben, dass das System trotz siebenjähriger Entwicklungszeit keine nennenswerten, militärischen Fähigkeiten erbracht hat [1]. Und dieses Projekt stellt kein Einzelfall dar. Rund die Hälfte aller Softwareprojekte liefert keine wesentlichen Ergebnisse [2]. Hinzu kommt, dass viele Projekte abgebrochen oder nicht rechtzeitig fertig werden. Gründe hierfür gibt es mehrere. Zum einen kann es vorkommen, dass die Software nicht fehlerfrei funktioniert. Zum anderen wird oft nicht das umgesetzt, was ursprünglich von Kunden angefragt wurde. Mehr

Oerlikon Hackathon powered by doubleSlash Experten

Am Wochenende des 08.11.2019 bis 10.11.2019 hat doubleSlash eine tolle Veranstaltung als Experten begleiten dürfen: Den ersten Hackathon der Oerlikon Group in toller Atmosphäre des Oerlikon Digital Hub. Neben Workshop Räumen und sogar einem Kino ist das technische Setup exzellent und erleichterte allen Teilnehmern die Arbeit.

Hackathon? Pures Wissen in agiler Lösungskompetenz

Pragmatisch und agil in einem: Ziel ist es, innerhalb der Dauer einer Hackathon Veranstaltung gemeinsam nützliche, kreative oder unterhaltsame IT – oder Software Produkte oder –Anwendungen herzustellen und so Lösungen für bestehende Probleme zu finden.

Ein breiter Mix an talentierten Personen

Die Zielgruppe des Events war ein sehr breiter Mix an talentierten Personen: von Softwareentwicklern über Data Scientists bis hin zu Spezialisten der Industrie. Die rund 80 Teilnehmer setzten sich zusammen aus Studenten, Softwareentwicklern bis hin zu Data Scientists und Oerlikon Mitarbeiter.

Die Challenges waren in 4 Kategorien aufgeteilt: IoT, Computer Vision, Data Science und Waste Reduction – wobei die letzte Kategorie sich wohl auch in die Data Science Aufgaben einsortieren lässt. Unter diesen Kategorien gab es je bis zu zwei Challenges – in Summe 7 Challenges. Für jede Challenge konnten sich nur eine definierte Zahl Teams anmelden, um sicher zu stellen, dass alle Challenges angegangen wurden.

Fünf doubleSlash IoT und KI Experten vor Ort

Auf Anfrage von Oerlikon beschloss doubleSlash das Event als Sponsor in Form von fünf Experten zur Unterstützung der Teilnehmer zu stärken: Vincenzo Crimi, Nico Mutter, Andreas Nuber, Timo Demler und Ralf Richter. Wir gaben Hilfestellung in den Bereichen Consulting, Coding, Architektur, technischer Spezialisierung mit PTC und Microsoft Azure, aber auch im Bereich Organisation und Strukturierung. Unsere Experten standen den Teams zur Seite, indem sie sie berieten und bei der Entwicklung weiterhalfen, ohne dabei Einfluss auf den Lösungsweg zu nehmen.

Gemeinsam mit unserem Partner PTC beschlossen wir bereits zu Beginn des Hackathons, unsere gewohnte enge Zusammenarbeit für den Support an den Teams zu leisten. Neben dem Mentoring für die Teams lieferten wir zwei tolle Workshops in den Bereichen Ideation und Pitch Training. Beide Workshops wurden ein toller Erfolg und leisteten einen wertvollen Beitrag für das Gelingen des Hackathon.

 

 

 

 

 

Fazit

Das Engagement unserer Experten für die Teams war beachtlich und ging über die Grenzen eines normalen Arbeitstages hinaus. Alle Teilnehmerteams schätzten diesen Support  spürbar, auch während der Pitches kam positives Feedback. Wir haben auch in anderen Formaten sehr positive Erfahrungen mit diesem agilen Veranstaltungsformat gemacht und sehen hier den deutlichen Mehrwert: Schwarmintelligenz in agiler Atmosphäre schafft gemeinsam innovative Lösungen zu konkreten Problemen.
Besonders stolz sind wir darauf, dass alle Teams, die von der doubleSlash Hilfe aktiv Gebrauch machten, in die Finals kamen. Besonders freuen wir uns über den Erfolg unseres doubleSlash-Studenten-Teams: Sie haben von 17 Teams einen sehr guten Platz 4 erarbeitet. Wir freuen uns auf kommende Events, die wir als doubleSlash begleiten können oder sogar selbst ausrichten werden.

 


Mehr zur KI und IoT Kompetenz von doubleSlash

Mehr zum Oerlikon Digital Hub

Agiles Anforderungsmanagement: die wesentlichen Kernelemente für erfolgreiche IT-Projekte

Immer häufiger werden IT-Lösungen nach dem Lean-Start-Up Prinzip realisiert. Beginnend mit der initialen Entwicklung eines, auf die Kernfunktionen fokussierten Produktes zum Markteinstieg („Minimal Viable Product – MVP“), wird das Produkt nach dem Go-Live durch direktes Marktfeedback, weiterentwickelt und optimiert.

Das erfordert ein entsprechendes Umdenken, auch im Anforderungsmanagement. Was sind die wesentlichen Kernelemente, die beim agilen Anforderungsmanagement über Erfolg und Misserfolg eines Softwareprojektes entscheiden?

Eine Frage auf die es vermutlich viele verschiedene Antworten gibt. In folgendem Blogbeitrag wollen wir uns dem Thema auf den drei Ebenen „Prozess“, „Tooling“ und „Mindset“ annähern und praxisnah darauf eingehen, wie agiles Anforderungsmanagement in diesen Bereichen jeweils Beachtung finden kann. Die Inhalte stammen größtenteils aus unserem Vortrag, den wir auf der ModernRE 2019 in Berlin gehalten haben.

Der Prozess: Von der Idee zur spezifizierten Anforderung

In einem Projekt liegt die thematische Verantwortung beim Fachbereich. Daher erstellt und aktualisiert dieser regelmäßig die Vision des Produkts – das Zielbild. Anhand dieser Vision werden viele Ideen abgeleitet um dieses Zielbild zu erreichen.

Die technische Verantwortung liegt wiederum beim IT Team. Das IT Team hat eine etwas andere Perspektive auf das Produkt und daher auch andere Ideen, als der Fachbereich, Im besten Falle ergänzen sich die Sichtweisen der IT mit der des Fachbereiches.

Von der Idee zur spezifizierten Anforderung
Abbildung: Von der Idee zur spezifizierten Anforderung

Eine Besonderheit ist es, dass alle Teammitglieder dazu aufgerufen sind ihre Ideen an einen eigens hierfür eingerichteten Bereich, dem sogenannten Ideen-Backlog, einzutragen und zu detaillieren. Ideen kommen dabei von einzelnen Teammitgliedern, die Verbesserungs- und Optimierungspotenziale erkannt haben, von externen Studien, in Form von direktem Feedback von Kunden, oder Dritten aus dem Markt.

In regelmäßigen Abständen findet durch den Fachbereich eine Begutachtung aller neuer Ideen aus dem Ideen-Backlog statt. Bei der inhaltlichen Prüfung der Ideen wird der bereits priorisierte Backlog betrachtet, sodass neue Ideen, die weiterverfolgt werden sollen, direkt priorisiert werden können. Auf diese Weise ist sichergestellt, dass immer die Idee als nächstes im Detail spezifiziert wird, die den größten Nutzen für Dritte und Kunden stiftet oder die größte Relevanz für das Produkt hat.

In der Spezifikation werden die Themen detailliert und im Sinne des Anforderungsmanagements spezifiziert. Es müssen beispielsweise Stakeholder ermittelt werden, die in einem Kick-off-Termin in das Vorhaben eingeweiht werden. Erste Erkenntnisse und Anforderungen werden notiert und grafisch in Form von Wireframes, Mockups oder mittels eines passenden Diagrammtyps aufbereitet. Ein Spezifikationstemplate hilft, wiederkehrende Fragen und Sachverhalte standardisiert zu betrachten und so keine wichtigen Aspekte zu vergessen. Klassische Ansätze kommen an dieser Stelle ebenfalls zum Tragen. Anforderungen müssen erhoben, analysiert, spezifiziert und validiert werden.

Nach jeder Spezifiaktionsphase steht das Review der fertigen Spezifikation an. Für das Review wird ein Teilnehmerkreis, bestehend aus dem Fachbereich und einem dedizierten IT-Ansprechpartner, dazu eingeladen, Feedback zur Spezifikation abzugeben. Um technische Risiken und die Umsetzbarkeit zu prüfen, sollte eng mit dem IT Team zusammen gearbeitet werden. Zusätzlich nehmen Kollegen aus der IT einen anderen Betrachtungswinkel ein und decken so zum Beispiel häufig noch nicht betrachtete Randfälle auf. Am Ende eines definierten Zeitraums ist es die Aufgabe des Autors, das Feedback zu konsolidieren, zu sichten und in die Spezifikation einzuarbeiten.

Am Ende steht eine finale Version der Spezifikation (v1.0), die sowohl vom Fachbereich, als auch vom IT Team gleichermaßen mitgetragen wird. Prozessual wird die fertige Fachspezifikation im IT-Refinement vom Fachbereich an das IT Team übergeben, Letzte Zusammenhänge werden betrachtet und ein einheitliches Verständnis hergestellt. Anschließend werden aus der Spezifikation User Stories für das Product Backlog der Software Entwicklung abgeleitet, definiert, priorisiert und detailliert.

Tooling in einer kollaborativen & verteilten Arbeitswelt

Ein toller Prozess allein reicht nicht aus! Es sind Tools notwendig, die diesen kollaborativen Ansatz ermöglichen und unterstützen. Zumeist werden zwei Tools in Kombination, beispielthaft JIRA und Confluence aus der Atlassian Suite, eingesetzt, um diesen Prozess abbilden zu können.

In einem Ticketingtool (Abbildung: Requirements Board im Ticketingtool) wird ein Kanban Board erstellt. Dort werden sämtliche Prozessschritte abgebildet, um den Überblick über alle Themen im Prozess zu behalten. Die Tickets im Status „Ready for Specification“ stellen den bereits priorisierten Backlog dar, der aus dem Ideen-Backlog gespeist wird. Ideen, die keine Relevanz für das Produkt liefern, werden hier schon gar nicht mehr berücksichtigt. Themen, die sich momentan in der Bearbeitung befinden – sei es in der Erstellung der Spezifikation („In Specification„) oder im Review („In Review„) – werden per Drag-and-Drop in den entsprechenden Status gezogen. Durch die Verlinkung des Tickets zur Spezifikation besteht die Möglichkeit, in einem Klick vom Ticketingtool zum Kollaborationstool (Erklärung im nachfolgenden Absatz) zu springen. In die entgegengesetzte Richtung ist dies ebenso möglich. Auf diese Weise werden unnötige Tool- und Systembrüche vermieden und Arbeitsabläufe effizienter gestaltet. Aus Fachbereichssicht ist eine Spezifikation, nach dem das Review beendet wurde, mit der Übergabe an das IT Team („Handover to IT„) fertiggestellt. Um eine vollständige Dokumentation zu gewährleisten, ist es notwendig, dass diese um die umgesetzten Funktionserweiterungen ergänzt wird („Documentation done„). Erst jetzt ist der Zeitpunkt erreicht, an dem man guten Gewissens von einer umgesetzten Anforderung sprechen kann.

Requirements Board im Ticketingtool
Abbildung: Requirements Board im Ticketingtool

In einem Kollaborationstool findet die Dokumentation der Spezifikation und das Review statt. Zwischen den beiden Tools sind Verlinkungen der entsprechen Tickets und Spezifikationen möglich, um so direkt vom einen in den anderen Bereich springen zu können. Zusätzlich lassen sich Workshops ebenfalls im Kollaborationstool dokumentieren und als Entscheidungsprotokolle direkt in die Spezifikation verlinken. Durch zahlreiche Add-ons kann der Funktionsumfang eines Kollaborationstools sehr individuell auf die Bedürfnisse im Projekt und Prozess angepasst werden. So können beispielsweise Wireframes direkt im Kollaborationstool selbst erstellt und bearbeitet werden.

Der wohl größte Vorteil durch den Einsatz eines Kollaborationstools ergibt sich bei der Durchführung des Reviews einer Spezifikation. Vor dem Umzug in der Spezifikation in das Kollaborationstool wurde das Review anhand eines Word-Dokuments durchgeführt, wodurch je Review-Teilnehmer eine Version des Dokuments auf dem Fileserver abgelegt wurde. Die Aufgabe des Requirements Engineers bestand daraus, das Feedback zu konsolidieren und in die Spezifikation einzuarbeiten. Bei doppelten oder gar widersprüchlichen Kommentaren in den unterschiedlichen Review-Dokumenten führte das zu erhöhtem Abstimmungs- und Klärungsaufwand mit den entsprechenden Review-Teilnehmern. Durch den Umzug in das Kollaborationstool kann nun auf die vollen Funktionsumfänge zur Unterstützung und Verbesserung der Kollaboration unter den Review-Teilnehmern und des Requirements Engineers zurückgegriffen werden. Die Inline-Kommentarfunktion (Abbildung: Spezifikation und Review im Kollaborationstool) bietet die Möglichkeit, dass jeder Review-Teilnehmer durch Markieren einer Textstelle einen Kommentar platzieren kann, welcher für alle anderen Review-Teilnehmer sichtbar ist. Auf diese Weise werden Dopplungen vermieden, es entstehen Diskussionen, die neue Themen aufwerfen oder etwaige Rückfragen direkt klären. Für den Requirements Engineer verringert sich der Konsolidierungsaufwand des Review-Feedbacks signifikant, da nun mehr alle Kommentare in einem Dokument zu finden sind, Dopplungen und Widersprüche leichter zu identifizieren und aufzulösen sind.

Spezifikation und Review im Kollaborationstool

Abbildung: Spezifikation und Review im Kollaborationstool

Am Ende eines jeden Reviews sind alle Teilnehmer dazu aufgefordert, zu bestätigen, dass das Review beendet wurde und anzugeben, ob eine weitere Abstimmung mit dem Autor der Spezifikation gewünscht wird.

Review Log am Ende jeder Spezifikation

Abbildung: Review Log am Ende jeder Spezifikation

Mindset

Damit ein Projekt erfolgreich abgeschlossen werden kann, benötigt es mehr als funktionierende Prozesse und moderne Tools. Häufig wird ein wichtiges Kernelement übersehen: Das Mindset. Nur wenn die Menschen im Projekt kooperativ und auf das Projektziel ausgerichtet arbeiten, greifen die Prozesse und Tools effektiv ineinander. Heutzutage stoßen wir in Projekten jedoch häufig auf sogenannte Silos (z.B. bei verschiedenen Abteilungen innerhalb eines Konzerns), die das Zusammenarbeiten erschweren können. Silos verfolgen im schlechtesten Falle eigene Ziele, welche auf den ersten Blick nicht immer mit den Zielen des aktuellen Projekts übereinstimmen.

Georg Jocham, Coach für Projektmanager und Führungskräfte, greift in einem seiner Podcasts zum Thema „Silos“, auf eine im Jahre 2005 durchgeführte Studie zurück. Hier zeigte der Sozialpsychologe Mark Levin, welchen negativen Einfluss Silodenken auf das Kooperationsverhalten über die eigene Gruppe hinaus haben kann. Dazu werden Fußballfans von Manchester United zu Beginn des Versuchs Fragen im Themenumfeld rund um ihren Verein gestellt. Anschließend kann beobachtet werden, dass die Hilfsbereitschaft unter den Teilnehmern gegenüber anderen Manchester Fans um ein Vielfaches höher ist, als gegenüber Fans eines rivalisierenden Vereins. Beim zweiten Teil der Studie werden weitere Manchester United Fans eingeladen. Nun wird mit Hilfe einer anfänglichen Umfrage jedoch der Fokus nicht auf den Verein gelegt, sondern auf die gesamte englische Liga. Interessanterweise ist die im Anschluss beobachtete Hilfsbereitschaft gegenüber Menschen, die dem rivalisierenden Verein angehören massiv gestiegen ist. Sie erreicht dabei fast dasselbe Niveau wie die Kooperation den eigenen Vereinskollegen gegenüber.

Die Studie zeigt wie eklatant sich das Kooperationsverhalten unterscheidet: Je nachdem welcher Gruppe sich Menschen zum aktuellen Zeitpunkt zugehörig fühlen und ob deren Gegenüber ebenfalls Teil dieser Gruppe ist oder nicht. Die Studie zeigt neben den Gefahren die Silos bergen können, bereits eine mögliche Lösung, um aus dem Dilemma zu entkommen. Menschen, die in einem Projekt über verschiedene Abteilungen oder Firmen zusammenarbeiten, benötigen eine gemeinsame Projektidentität. Diese muss möglichst früh im Projekt etabliert werden, z. B. durch Vermittelung des gemeinsamen Projektziels im gemeinsamen Kick-off zu Beginn des Projekts.
Ist eine Projektidentität geschaffen muss sichergestellt werden, dass diese Bestand hat. Innerhalb dieses Projektteams haben sich zwei grundlegende Werte herausgeprägt die für den Zusammenhalt und eine funktionierende Zusammenarbeit innerhalb der Gruppe von großer Bedeutung sind: Wertschätzung und Vertrauen.

Ein wertschätzender Umgang im Projekt kann sich auf vielseitige Art und Weise äußern. So ist es zum Beispiel wertschätzend, andere nach Ihrer Meinung zu fragen oder sich für geleistete Arbeit zu bedanken. Eine hohe Wertschätzung im Projekt kann dazu führen, dass das Team eine höhere Loyalität dem Projekterfolg gegenüber zeigt.
Auch ein hohes Maß an Vertrauen spielt eine nicht unwesentliche Rolle, ob ein Team die gemeinsam etablierten Prozesse und Tools optimal nutzen kann. Dazu muss sichergestellt werden, dass jeder Beteiligte sich darauf verlassen kann, dass das gesamte Team auf den Projekterfolg ausgerichtet ist und somit auch das Ansprechen von Risiken, Fehlern und auch das Einbringen der eigenen Meinung als einen Beitrag zu diesem angesehen werden. In Projekten in denen ein hohes Maß an Vertrauen herrscht, steigt die Transparenz und die Berührungsängste in fachlichen Diskussionen und im schriftlichen Austausch nehmen stark ab. Es geht wieder mehr um die Sache. Insbesondere Transparenz ist in agilen Frameworks, wie zum Beispiel Scrum, eine wesentliche Grundvoraussetzung.

Wertschätzung und Vertrauen im Projekt

Abbildung: Wertschätzung und Vertrauen im Projekt

Fazit

Jedes der drei obigen Themen würde mehr als einen eigenen Vortrag füllen. Das hat sich unter anderem auch in der Agenda der diesjährigen ModernRE 2019 gezeigt. So wurden auf der Konferenz eigene Vorträge zum Einsatz einzelner Tools im Anforderungsprozess und zum Zusammenspiel von Ticketing- und Kollaborationstools gehalten. Auch auf das Thema Mindset wurde in einem spannenden Vortrag mit dem Titel „Wie Teams wirklich Stark werden“ eingegangen.
Auch wenn die Rahmenbedingungen in IT-Projekten sehr unterschiedlich sind, so lohnt es sich doch von Zeit zu Zeit den eigenen agilen Anforderungsprozess unter die Lupe zu nehmen und bei Bedarf zu Überarbeiten. Besonders leicht fällt das, wenn man mit Tools arbeitet, die hier die notwendige Flexibilität mitbringen.

Wovon mit Sicherheit alle Projekte profitieren, unabhängig der Rahmenbedingung, ist ein wertschätzender und vertrauensvoller Umgang innerhalb eines gemeinsamen Projektziels.

Co-Autor Findan Eisenhut

 


Weiterführende Links

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Kundenzufriedenheit durch Erfüllung von Anforderungen – das Kano-Modell

 

Mehr zur Anforderungsanalyse für Softwareprojekte gibt’s hier

 

Agile Mixperience – die prickelnde Alternative zu Scrum Cooking

Mit Cocktails vermitteln, wie Scrum funktioniert

Nach jahrelanger Erfahrung mit dem Erfolgskonzept „Scrum Cooking“ inklusive optimierter Rezepte, zahlreichen neuen Koch-Skills und Kunden, die leckere Menüs genießen durften, wird es Zeit für ein wenig Abwechslung. Also warum die Methodik Scrum nicht bei einer Agile Mixperience erlernen? Statt 3-Gänge-Menüs werden hier Cocktails gemixt.

Es gibt zahlreiche Zertifizierungen, die sich mit den theoretischen Grundlagen der Projektmanagement-Methode Scrum beschäftigen. Wirklich nachhaltig lernt man am besten mit Praxisbezug und Spaß. Mit dem Workshop „Agile Mixperience“ vermitteln unsere Agile Coaches wie auch bei „Scrum Cooking“ die spezifischen Rollen, Prozesse und Artefakte der Methodik. Der eintägige Workshop wird entweder beim Kunden vor Ort oder in einer Location aus unserem Netzwerk durchgeführt. Die Teilnehmer lernen spielerisch die Grundprinzipien kennen, werden selbst aktiv und erleben unmittelbar die Effekte agiler Arbeitsmethoden. Sie schildern aus eigener Erfahrung:

„Es geht nur mit Kooperation.“
Für die Bearbeitung unserer strategischen und organisatorischen Aufgaben haben wir im Management Team agile Methoden schätzen gelernt. Die „Agile Mixperience“ hat uns ganz schnell wieder vor Augen geführt, dass eine reibungslose Kooperation im Team das A und O für den Erfolg des agilen Ansatzes ist.

 

„Raus aus der Falle „definition of (almost) done“
Seit Monaten arbeiten wir Product Owner mit unserem Entwicklungsteam agil zusammen und freuen uns über jede erfolgreiche Zwischenlieferung. Mit der Agile Mixperience wollten wir das Team nach einem Wechsel in verschiedenen Rollen neu zusammenschweißen. Wir haben aber noch mehr gelernt. Denn richtig lecker ist ein Cocktail erst, wenn er auch wirklich fertig ist und alle ihn genießen können.

 

„Agiles Arbeiten kann auch abseits der Software-Entwicklung sinnvoll sein.“
Wir standen vor der Frage, ob eine agile Arbeitsweise auch in unserem Vertriebsteam anwendbar ist. Nach dem Workshop steht fest: Wir werden nur gewisse Elemente aus dem Scrum Framework umsetzen können, diese jedoch konsequent bei uns etablieren. Nach der praktischen Anwendung zwischen Stößel, Shaker und Cocktails werden unsere Mitarbeiter jedenfalls nie wieder vergessen, was ein Scrum Master und ein Product Owner machen.

So funktioniert die Agile Mixperience:

  • Theoretische Einführung in das Scrum Framework, um bei den Teilnehmern ein gemeinsames Verständnis zu schaffen.
  • Team-Building und Verteilung der Rollen des Scrum Masters, Product Owners und der Teammitglieder.
  • Vorbereitung der Produktvision und des Product Backlog. Ziel ist es, dem „Kunden“ ansprechend dekorierte leckere Cocktails anbieten zu können – je nach Wunsch vom Virgin Cocktail bis zum Classic Cocktail.
  • Praktische Durchführung von drei Iterationen inklusive Sprint Planning, Sprint Review und Sprint Retrospektive, um das Erlernte zu festigen.
  • Gemeinsame Reflexion und Übertragung des Erlebten in die eigene Arbeitswelt.

 

Zusätzliche Herausforderungen entstehen durch Aktionskarten und veranschaulichen immer wieder, dass eine gute Planung, Transparenz und klare Kommunikation das A und O bei einer agilen Vorgehensweise sind. Auch die Zeit wird anfangs häufig unterschätzt. „Eine halbe Stunde für einen Cocktail? Das ist doch keine Herausforderung!“ Und doch geraten die Teams zu Beginn in Hektik. Mit jedem Sprint wird die zuvor besprochene Theorie verständlicher und besser angewendet – das Team schwingt sich ein, es lernt dazu und arbeitet in der nächsten Iteration produktiver.

doubleSlash Agile Mixperience Cocktails
Abbildung 1: Hanami-Cocktail bei einer Agile Mixperience mit doubleSlash im September 2019 in München

Während des gesamten Tages werden die Teilnehmer durch erfahrene Agile Coaches begleitet, die alle selbst in unterschiedlichen Rollen in agilen Projekten arbeiten.

Fazit: Agile Mixperience – für jedes agile Level und individuell nutzbar

Agile Mixperience schafft ein gemeinsames Verständnis im Projektteam und ist ideal für:

  • den Kick-off von anlaufenden agilen Projekten.
  • neue Projektmitglieder, die in laufende agile Projekte integriert werden.
  • erfahrene Projektmitglieder, die einen frischen Blick auf Ihre Scrum-Praxis werfen möchten.
  • Unternehmen, die sich eine Einführung von agilen Arbeits- und Entwicklungsmethoden überlegen.

 

Gemeinsam mit verschiedenen Kunden haben wir den Workshop „Agile Mixperience“ bereits erfolgreich verprobt. In lockerer Atmosphäre holen wir die Teilnehmer mit unterschiedlichsten Wissensständen ab – von Scrum Anfängern bis zum erfahrenen Scrum Master. Unser Ziel ist es, die Methodik verständlich zu vermitteln, den Teilnehmern die Scheu vor der praktischen Anwendung zu nehmen und die Essenz für die eigene Arbeitswelt mitzugeben.

Mehr Agile Workshops gibt es hier

 

Spring Boot: Webservice Integrationstest

Spring Boot bietet mit MockMvc einen Zwischenweg zwischen einem echten Integrationstest und einem Unit-Test und ermöglicht es, einfach Integrationsaspekte zu testen. So können sich Entwickler auf die Businesslogik konzentrieren und schnell Ergebnisse liefern. Der Artikel zeigt ein vollständiges Beispiel, wie man mit Spring MockMvc eine geschützte Webschnittstelle getestet werden kann.Mehr

Die fünf wichtigsten IT-Trends 2018

vernetzte TechnologienNein, die Blockchain gehört nicht zu den IT-Trends 2018, da wird sich vermutlich im kommenden Jahr erstmal – wie bei jeder Trendtechnologie – Ernüchterung einstellen. Zwar gibt es ohne Zweifel sinnvolle Szenarien für die Blockchain. Aber sie löst kein ernsthaftes Problem, sie erzeugt nicht den ganz großen Nutzen, den man sich erwartet. Unsere Infrastruktur, unsere etablierten Prozesse, unser ganzes Gemeinwesen basiert auf Vertrauen, auch wenn es zum Beispiel durch die Finanzkrise erschüttert worden ist. Hätten wir eine echte, weit reichende Vertrauenskrise, dann würde sich die Blockchain als Lösung anbieten. So aber glaube ich nicht, dass sich die Blockchain-Technologie die nächsten Jahre auf breiter Basis durchsetzen wird.

Mehr

DevOps, Microservices & Big Data: Drei Top IT-Themen, die Automobilhersteller künftig beschäftigen werden

Für einen fachlichen Austausch zwischen Mitarbeitern und ausgewählten Dienstleitern veranstaltete die BMW Group auch in diesem Jahr wieder ihre BMW IT Messe in der Münchner Zenith Halle. Im Fokus waren aktuelle Projekte und Innovationsthemen aus Business- und Fahrzeug-IT. Für das Fachpublikum gab es Informationen zu den aktuellen Trends in den IT-Projekten. Als langjähriger Partner der BMW AG waren wir mit dem 7er Pool [1] vor Ort und haben rückblickend drei Top IT-Themen identifiziert, die auf der Messe allgegenwärtig waren.

Mehr