Im klassischen Projektumfeld und/oder auch im Unternehmensumfeld kommt es oft vor, dass Regelmeetings, welche zum Statusaustausch dienen sollen, in zu großen Gruppen und in einem zu großen Zeitrahmen abgehalten werden. Auch bei Scrum gibt es Events, welche vom Framework empfohlen werden, diese sind jedoch alle mit einer Timebox versehen, ebenso wird ein Teilnehmerkreis empfohlen. Existieren derartige Meetigs nicht, schlägt auch Kanban geregelte Termine zum Austausch vor. Die Ideen von Scrum und Kanban zeige ich in der aktuellen Kolumne auf. Events in Scrum und Kanban

Softwareprojekte sind vielschichtig und komplex. Komplexität hat die Herausforderung, das Best Practice Ansätze nicht helfen, sie zu durchdringen. Eine Beratung, ein Coaching oder ein Training kann dabei nur Ideen liefern, Inspiration, wie Dritte mit dem Thema Komplexität im Unternehmen und z.B. in der Softwareentwicklung umgegangen sind. Für jedes Unternehmen ist die Lösung individuell und immer ganzheitlich zu betrachten. Eine lokale Optimierung für nur einen Bereich (meist die Softwareentwicklung) ist zu kurz gegriffen. Wie es gelingen kann, eine Transformation erfolgreich zu gestalten erfahrt ihr im Interview.

Auf der Ebene lenken finden jene Tätigkeiten statt, welche im Prozess „Lenken eines Projektes“ dargelegt werden, dazu zählen „Initiierung freigeben“, „Projekt freigeben“, „Phasen- oder Ausnahmeplan freigeben“, „Ad-hoc Anweisungen geben“ und „Projektabschluss freigeben“. Diese Tätigkeiten werden von Lenkungsausschuss über den gesamten Projektlebenszyklus durchgeführt. Alle weiteren Tätigkeiten hat der Lenkungsausschuss an den Projektmanager oder weitere Beteiligte delegiert. Der Lenkungsausschuss stellt sicher, dass er das erwartete Projektergebnis definiert hat, für die Projektdurchführung die Ressourcen bereitgestellt hat und etwaige Risiken auf der Lenkungsebene erkennt und behandelt. Ein PRINCE2® Projekte lenken

Agile Prozesse wie Scrum und der Changeprozess Kanban spielen Ihre Stärken dadurch aus, das geregelt im Team kommuniziert wird, die Abstände zwischen den Regelkommunikationen gering sind und jeder im und außerhalb des bzw. der Entwicklungsteams weiß, wie die Kommunikation zu erfolgen hat. Ebenso müssen Regelprozesse und Vereinbarung eingehalten werden, um die Stärken der  Prozesse nicht zu gefährden. Die Arbeit in Kanban kann mittels Tickets ((Product) Backlog Items), welche auf Story Cards festgehalten werden, visualisiert werden. Wann die Tickets abgearbeitet werden und in die Input Queue kommen, wird in einem Meeting, dem Queue Replenishment Meeting, entschieden. Zur Planung in Scrum und Kanban

Der erste – „Vorbereiten eines Projektes“ – der sieben Prozesse, welche PRINCE2® enthält, um ein Projekt erfolgreich durchzuführen, wurde in der letzten Kolumne umfänglich erläutert. Im jetzigen Teil der Kolumne möchte ich den nächsten Prozess „Initiieren eines Projektes“ beleuchten, welcher dazu dient, alle nötigen Aktivitäten durchzuführen, welche für das dann folgende Projekt benötigt werden. Am Ende steht eine Projektleitdokumentation zur Verfügung, welche dem Lenkungsauschuss als Entscheidungsvorlage dient, um das Projekt freizugeben oder abzulehnen. Ein PRINCE2® Projekte initiieren

Agile Prinzipien und Methoden bilden die Basis für agile Softwareentwicklung, und die hier exemplarisch erörterten Praktiken finden sich in agilen Prozessen wie z.B. Scrum oder eXtreme Programming wieder. Dennoch ist eine Verwendung in klassischen Wasserfall- oder V-Modell-Projekten denkbar, um die Vorteile, wie eine verbesserte Kommunikation, auch in diese Modelle zu transportieren. Agile Methoden wie Pair Programming, Code-Reviews, testgetriebene Entwicklung, Refactoring und User Storys finden entweder Anwendung in nicht agilen Prozessen wie dem V-Modell, um sie punktuell zu verbessern, oder in agilen Prozessen wie Scrum oder eXtreme Programming. Agile Prozesse und mehr

PRINCE2® beinhaltet sieben Prozesse, welche Aktivitäten beschreiben, die für ein erfolgreiches Projektmanagement nötigt sind und im letzten Teil der Kolumne kurz angerissen wurden. In den folgenden Teilen meiner Kolumne gehe ich im Detail auf die verschiedenen Prozesse und die damit in Beziehung stehenden Aktivitäten ein. Diese Aktivitäten finden auf den drei beschriebenen Managementebenen statt, der Ebene Lenken, der Ebene Managen und der Ebene Liefern. Im Folgenden werden die Aktivitäten des Prozesses „Vorbereiten eines Projektes“ vorgestellt, welche auf den Ebenen Lenken und Managen angesiedelt ist. Ein PRINCE2® Projekte vorbereiten

In den Anfängen wurde Software oft nach klassischen Methoden, wie zum Beispiel mit dem Wasserfall- oder V-Modell entwickelt.  Im Jahr 2001 trafen sich siebzehn Personen – größtenteils mit Software Entwicklungshintergrund –, um eine einheitliche Grundlage wie Software zukünftig entwickelt werden kann, herauszuarbeiten. Dabei  entstand das Agile Manifest. So sind zum Beispiel die Selbstorganisation und die Selbstreflexion der Teams essenziell für die agile Softwareentwicklung. Agile Methoden im Überblick

Neben den sieben Grundprinzipien und sieben Themen, beinhaltet PRINCE2® sieben Prozesse, welche Aktivitäten beschreiben, die für ein erfolgreiches Projektmanagement nötigt sind. Diese Aktivitäten finden auf verschiedenen Managementebenen statt. Innerhalb einer PRINCE2® Projektorganisation gibt es drei dieser Managementebenen, die Ebene Lenken, die Ebene Managen und die Ebene Liefern. Die meisten Prozesse in PRINCE2® beschreiben Aktivitäten auf der Ebene Managen, nur zwei Prozesse entfallen auf die Ebene Lenken und nur einer auf die Ebene Liefern. Zum Artikel Prozesse in PRINCE2®

Einem schon recht erfahrenen Entwicklungsteam, welches Scrum verwendete, um ein monolithisches System zu pflegen und weiterzuentwickeln, gaben wir noch zusätzliche Werkzeuge an die Hand, um nicht-monolithische Produkte in einem systematischen Prozess entwickeln zu können. Dies ist uns in den ersten drei Monaten erfolgreich gelungen. Der Hauptfocus lag im ersten Schritt darauf, aus einem ProcessOwner einen ProductOwner zu formen und diesen als Teil des Scrumteams zu etablieren, um nützliche (den Sprint Goals entsprechend) bzw. benutzerzentrierte Produkt Inkremente entwickeln zu können. Autoren: Thomas Kerschis & René Schröder Agile Transformation II

PRINCE2® und PRINCE2® Agile bieten einen Ansatz, den Fortschritt in einem Projekt zu messen und entsprechend zu überwachen. Die Fortschrittsmessung gestaltet sich in unterschiedlichen Projekten auf verschiedenste Art und Weise, im Scrum Umfeld kann der Burn Down Chart als Fortschrittsindikator im aktuellen Sprint gesehen werden. PRINCE2® beschreibt die Fortschrittsmessung im Thema (zur Erinnerung, PRINCE2® befasst sich mit insgesamt sieben Themen ) ‚Fortschritt‘. Zum Artikel Fortschritt in PRINCE2®

Im Thema ‚Pläne‘ wurden bereits sämtliche Planungsebenen und Planarten aufgezeigt. Ebenso die Notwendigkeit eines Ausnahmeplanes wurde vermittelt. Der eigentliche Planungsprozess wurde bis dato noch ausgespart, dies wird im jetzigen Teil nachgeholt und ausführlich dargelegt. PRINCE2® teilt den Prozess Erstellen eines Planes in sechs verschiedene Aktivitäten auf. Es ist in PRINCE2® nicht die alleinige Aufgabe des Projektmanagers, einen Plan zu erstellen, er greift hierfür auf die Fachleute in den Teams zurück. PRINCE2® Planungsprozess

Unternehmen mit differenzierten Konzernstrukturen tun sich teilweise schwer, sich auf neue Anforderungen seitens des Marktes einzustellen. Vielfach gelangen aktuelle Projektvorgehen in eine Sackgasse, da die Strukturen und Systeme solcher Projekte maßgeblich durch unflexible und starre Mechanismen gesteuert und eingebunden sind. Daraus ergab sich die Notwendigkeit, vorhandene und geplante Projekte im Digital-Bereich neu zu bewerten. Es galt diese Projekte in Bezug auf Flexibilität, Time-2-Market, Nachhaltigkeit, Disruption und Effizienz zu betrachten. Autoren: Thomas Kerschis & René Schröder Agile Transformation I

Agile Projektmethoden sind aus mehreren Gründen erfolgreich, ein Grund hierfür ist, kürzere Releasezyklen, was die Möglichkeiten für Feedback und daraus resultierende Änderungen ermöglicht. Eines der PRINCE2® Themen ‚Änderungen‘ beleuchtet, wie Änderungen geordnet in ein Projekt implementiert werden können. Änderungen gehören zum Tagesgeschäft in vielen Projekten, sei es durch geänderte Kundenwünsche oder oft auch durch sich ändernde Marktbedingungen. PRINCE2® Thema Änderungen

Die sieben Prinzipien, die sieben Themen und die sieben Prozesse bilden das Rückgrat von PRINCE2®. Qualität, Pläne, Business Case und Organisation wurden in den vergangenen Teilen bereits behandelt, bleiben noch Risiko, Änderungen und Fortschritt. In der jetzigen Kolumne wird die Risikobetrachtung von PRINCE2® betrachtet. Sämtliche Prinzipien, Themen und Prozesse dienen PRINCE2® Agile als Grundlage, welche entsprechend an einen agilen Kontext angepasst werden. PRINCE2® Thema Risiko

Akteptanztests mit CodeCeption erinnern schon sehr stark an BDD Test, zumindest was die Ausgabe, die Lesbarkeit der Testergebnisse anbelangt. Einen Nachteil hat CodeCeption, die Tests müssen noch in beschriebener Art und Weise programmiert werden. Cucumber und die entsprechende PHP Implementierung davon – Behat – gehen einen Schritt weiter. Cucumber/Behat verstehen Gherkin, eine Domain spezifische Sprache welche die Fachseite versteht und die es ermöglicht, gewünschtes Software Verhalten zu beschreiben, ohne wissen zu müssen, wie dieses konkret implementiert wurde. BDD und Behat

PRINCE2® teilt ein Projekt bewusst in überschaubare Managementphasen auf, eine vollumfängliche Planung des gesamten Projektes findet nicht statt. Agile Iterationen, technische Phasen können mit den Managementphasen korrespondieren, vorausgesetzt wird dies allerdings nicht, auch ist dies nicht in allen Anwendungsfällen möglich oder sinnvoll. Software Qualität ist eine Motivation agiler Softwareentwicklung, auch in PRINCE2® wird der Qualität eine wichtige Bedeutung zugemessen, damit ein Projekt erfolgreich sein kann, daher widmet sich PRINCE2®, in einem seiner sieben Themen der Qualität. Qualität und Pläne

Jenkins wurde in den vergangenen Artikeln so aufgesetzt, dass es Teile der Continuous Integration und Continous Delivery Chain automatisiert abbilden kann. Continuous Integration bildet den Anfang der Continous Delivery Chain und kann für sich allein stehen. Sie dient dazu dem Developer Team Qualitätssicherungsmaßnahmen automatisiert abzunehmen, um die Software Qualität langfristig zu sichern und aufrecht zu halten. Teilaufgaben von gängigen Continuous Integration Systemen sind Unit Test, statische Code Analyse, Erstellung einer Quellcodedokumentation und schlussendlich die Bereitstellung und Versionierung der Build Artefakte. BDD und DevOps DevOps Infografik

Jene in PRINCE2® aufgezeigten Prinzipien bilden die Grundlage für die sieben Themen und die sieben Prozessschritte. PRINCE2® erlaubt bei den Prinzipien keine Anpassung, bei den Themen und Prozessen jedoch sehr wohl. Ein Merkmal von Projekten ist die Einzigartigkeit, Projekte unterscheiden sich vom Daily Business, daher wäre es vermessen zu behaupten, jedes einzigartige Projekt kann mit den gleichen Methoden bearbeitet werden. Jedes Projekt bedarf einer sinnvollen Anpassung, mal mehr mal weniger. Den Ursprung hat auch PRINCE2® im klassischen Projektmanagement. Agile Entwicklung wird einige Anpassungen nötig machen, ein Schritt welcher bereits erkannt wurde und in PRINCE2® Agile mündet. PRINCE2® Themen

Neben Scrum und Kanban beherrschen in vielen Unternehmen noch das Wasserfall oder das V-Modell die Projektplanung, auch PRINCE2® wird oft und gern verwendet. Sind diese Prozesse ein Widerspruch zu Scrum/Kanban, zu agilen Prozessen, ich denke nein. Es muss ein Weg gefunden werden, das Beste aus allen Ansätzen zu filtern und im jeweiligen Projektkontext anzuwenden. PRINCE2® bietet sich für ein derartiges Vorhaben besonders an, da diese Projektmanagement Methode die Anwendung agiler Prozesse gezielt unterstützen kann. PRINCE2® Grundprinzipien

CodeCeption ist ein Testframework, mit welchem Acceptance Tests, Functional Tests, API Tests und Unittest komfortabel implementiert werden können. Hierfür greift CodeCeption unter anderem auf PHPUnit zurück. Eine Wissensbasis in PHPUnit ist dennoch nicht nötig, ist aber von Vorteil, sobald der Funktionsumfang von CodeCeption – zum Beispiel mittels Helper – erweitert werden soll. Akzeptanzkriterien sind Abnahmebedingungen von Stakeholdern an ein Feature bzw. eine umgesetzte Anforderung. Diese Kriterien sind unabhängig vom Framework, der Datenbank, der Programmiersprache, also allen technischen Feinheiten. Jenkins und Codeception

Shopsysteme sind in den letzten Jahren immer wichtiger geworden. Viele Unternehmen, welche traditionell eher stationär aufgestellt sind, folgen dem Trend, über verschiedene Kanäle ihre Kunden erreichen zu wollen. Kleine Unternehmen setzen hier klassisch auf Baukastensysteme, um ihre Produkte online anbieten zu können, Mittelstand und große Unternehmen greifen auf Magento, OXID oder Shopware zurück. Hybris spielt hier auch eine gewichtige Rolle, jedoch ist dabei der Gesamtaufwand im Unternehmen nicht zu vernachlässigen, um ein Shopsystem mit Hybris aufzusetzen und zu betreiben. Für schnelle Time to Market Projekte eignet es sich daher nur bedingt. Unternehmen welche Hybris erfolgreich einsetzen, bedienen sich in vielen Fällen Shopware, welches die letzten Jahre einen großen technischen Sprung gemacht hat und daher für immer mehr auch große Unternehmen zu einer echten Alternative geworden ist. Shopware im Konzernumfeld

Um den Teams eine bessere Kommunikation und Auswertung zu ermöglichen, bieten Scrum und Kanban verschiedene Metriken an, welche den Prozess bzw. einzelne Prozessschritte entsprechend verschiedener Messgrößen abbilden. Erst diese Metriken befähigen die Teams, ihre Arbeit und ihre Arbeitsqualität zu bewerten bzw. zu visualisieren. Mit Hilfe dieser Visualisierung können Verbesserungen gezielt herausgearbeitet und angewendet werden. Neben der Grundlage für Verbesserungen dienen diese Metriken auch als wichtige Erfahrungsgrundlage für Sprint oder Release Planungen. Metriken in Scrum & Kanban

Die Arbeit in Scrum und Kanban Teams wird wie in der letzten Kolumne anfänglich aufgezeigt durch geregelte Kommunikation entscheidend unterstützt und zu Teilen auch erst ermöglicht. Um Iterationen effektiv planen zu können, bedienen sich Scrum und Kanban – wie aufgezeigt – am Sprint Planungsmeeting (Scrum) bzw. am Queue Replenishment Meeting (Kanban). Dieses forcieren der Kommunikation wird durch weitere Meetings innerhalb eines Iterationszyklus und auch im Anschluss weiter ausgebaut. Sämtliche Meetings verfolgen ein bestimmtes Ziel und dienen nicht dem Selbstzweck. Ein konsequentes Hinterfragen im gelebten Prozess ist sinnvoll, um festzustellen, ob die folgenden aufgezeigten Meetings dieses Ziel auch erfüllen. Scrum Meetings Kanban Meetings

In vorangegangenen Artikeln im PHP Magazin wurde Jenkins bereits für dynamische Softwaretests, für statische Softwaretests und zur Erstellung einer Dokumentation vorbereitet. Ein weiterer wichtiger Schritt, um die Continuous Delivery Chain zu vervollständigen sind Behavior Driven Development (BDD) Test, Akzeptanz Tests. Behavior Driven Development, zu Deutsch verhaltensgetriebene Softwareentwicklung wird vornehmlich in der agilen Softwareentwicklung eingesetzt. Hier verbessert es sehr stark die Zusammenarbeit zwischen Qualitätsmanagement und Business-Analyse. In regelmäßigen Projektreviews, zum Beispiel nach jedem Sprint in Scrum, kann diese Zusammenarbeit immer weiter verbessert bzw. ausgebaut werden. Jenkins und BDD

Projekte, egal mit welchen Werkzeugen sie geleitet werden, scheitern oft an mangelnder oder fehl gerichteter Kommunikation. Bleibt eine geordnete Kommunikation in den Teams oder vom Team Richtung der Stakeholder aus, entstehen Missverständnisse, was dazu führt, dass falsche Requirements oder Requirements falsch umgesetzt werden. Beide Fälle sind unnötig und ärgerlich, Scrum oder Kanban hat hierfür keine Patentlösung. Strukturierte und wiederkehrende Meetings minimieren sowohl in Scrum, wie auch in Kanban, jene Missverständnisse, wie dieser Teil der Kolumne A² aufzeigen wird. Kommunikation in Scrum & Kanban

Continuous-Integration-Systeme sind auch in der PHP-Welt zu einem wichtigen Standard geworden, um Softwarequalität zu gewährleisten. Dieses eBook liefert eine Anleitung zum Aufsetzen von CI-Systemen. Vorkenntnisse zu Versionsmanagementsystemen, wie Git oder SVN, und Grundlagenwissen in Linux sind von Vorteil. Ich zeige auf, welche Schritte zur Vorbereitung eines Jenkins-Servers notwendig sind. Anschließend werden sowohl statische als auch dynamische Tests implementiert. Zum Abschluss geht es um den Feinschliff der Konfiguration des Jenkins-Servers und die automatische Erstellung einer aussagekräftigen Dokumentation für das Entwicklerteam. Softwarequalität in PHP-Prozessen

In den folgenden Kolumnen möchte ich die Unterschiede zwischen Scrum und Kanban aufzeigen. Meine Erfahrung der letzten Jahre hat gezeigt, dass Scrum und Kanban oft in einen Topf geworfen wird. Um hier ein wenig Licht ins Dunkel zu bringen, erläutere ich für welche Anwendungsfälle sich Scrum eignet und für welche eher Kanban. Scrum vs. Kanban

Continuous Intergration unterstützt insbesondere die Prozesse in der agilen Softwareentwicklung und ist zu einem wichtigen Defacto Standard in den letzten Jahren geworden. Die konsequente Weiterentwicklung von Continuous Intergration zu Continuous Delivery ist der nächste wichtige Verbesserungsschritt. Continuous Intergration findet zu grossen Teilen in den Developer Teams selbst statt, hier wird das Feedback der Continuous Intergration Systeme zeitnah benötigt. Continuous Delivery erfordert nicht nur eine Weiterentwicklung des Continuous Intergration Prozesses, es erfordert darüberhinaus eine Weiterentwicklung in der Zusammenarbeit von Developern und Operations. Von Continuous Intergration zu Continuous Delivery

Im letzten Teil der Artikelserie ‘Qualitätssicherung in PHP Projekten mittels Jenkins’ schliessen wir die Konfiguration des Servers ab. Jenkins ist im Anschluss in der Lage, neben dynamischen und statischen Softwaretests, auch die Codequalität gegen einen Styleguide zu überprüfen und eine Dokumentation zu erstellen. Der abschliessende Feinschliff an der ANT Konfiguration rundet den Build Prozess im Jenkins Server ab. Feinschliff zum regelmässigen Build Prozess