SCRUM.de

Inhalt abgleichen
Scrum Wiki für Agile Professsionals
Aktualisiert: vor 50 Minuten 22 Sekunden

Desired State Configuration – Elemente der Konfiguration

21. November 2014 - 13:56

DSC ist ein Feature, welches im Windows Betriebssystem verbaut ist. Es basiert auf CIMS und WS-Management Remote Management  Standards, welche durch das Betriebssystem angeboten werden. Mit DSC sind Sie auf dem Weg zu einem Konfigurations-Management, in dem Sie ein Script kreieren können, welches definiert, wie der Zustand des Servers sein sollte, anstatt zu definieren wie man den Server im gewünschten Zustand herstellen kann. Das bedeutet, dass DSC mehr eine deklarative Syntax als eine imperative ist. Das macht DSC Scripts/Konfigurationen leicht verständlich und wartbar.

 

Ein Beispiel der DSC-Konfiguration für das Konfigurieren der Web Applicationen einer SharePoint Farm schaut wie folgt aus:

 

Configuration SPSiteCollectionConfig {

param($nodes)

 

Import-DscResource -ModuleName xDSC_SPSiteCollection

Import-DscResource -ModuleName xDSC_SPWebApplication

Node ($nodes) {

 

xSPWebApplication WebApplication{

WebApplication = “WebApplication MYWebApp”

Ensure = “On”

}

 

 

SPSiteCollection SiteCollection {

SiteUrl = ‘http://MYWEBAPP.com/newSite’

SiteName = ‘New Site’

SiteTemplate = ‘BLANKINTERNET#2′

ContentDatabaseName = ‘CONTENT_NEWSite’

Language = ‘1033’

Ensure = ‘Present’

DependsOn “[xSPWebApplication]WebApplication”

 

}

}

}

SPSiteCollectionConfig

 

Das Konfigurationsskript beginnt mit einem Konfigurationsblock, welches verwendet wird, um der Konfiguration einen aussagekräftigen Namen zu geben. Das Konfigurationsschlüsselwort ist der Kernbestandteil von DSC, der die gewünschte Konfiguration eines Zielsystems definiert. Im Anschluss an das Konfigurationsschlüsselwort, wird das Node Schlüsselwort verwendet, um das Zielsystem/die Zielsysteme zu spezifizieren, auf denen die Konfiguration durch das LCM angewendet werden sollte. Sie können ebenfalls die Werte parametrisieren, die in das Node Schlüsselwort übergeben werden, wenn Sie die Entscheidung über das Zielsystem zu einem späteren Zeitpunkt entscheiden wollen. Später können Sie die Zielsystemwerte zu der Konfiguration übergeben, wenn Sie eine MOF Datei aus der Konfiguration kreieren wollen.

 

Innerhalb des Node ist ein Status von einer DSC-Ressource. Das DSC Ressourcenmodul stellt den „Wie“-Part vom Konfigurationsmanagement sicher. Die DSC Ressourcenmodule werden imperativ geschrieben und implementiert geschrieben, was bedeutet, dass das Ressourcenmodul alle essenziellen Details durchführt, um das Konfigurationsszenario auf einer Entität durchzuführen. Jedoch macht die DSC Konfiguration es möglich, unter Verwendung eines deklarativen Konfigurationsskripts diese imperativen Details vom Endbenutzer zu lösen.

 

Jetzt müssen wir das in ein Format übersetzen, dass vom DSC Local Configuration Manager oder der DSC Engine verstanden wird. Dies ist die Managed Object Format (MOF) Darstellung des Konfigurationsscriptes. Wir können die MOF-Darstellung des Konfigurationsskripes durch das einfache Laden der Konfiguration in den Speicher und das anschließende Abrufen generieren.

In unserem Beispiel fügen wir den Namen der Konfiguration an das Ende des Scripts ein. Dies stellt sicher, dass das Script, wenn durchgeführt, die MOF-Dateien für jedes Node generiert und in den Ordnern speichert, die den gleichen Namen wie die Konfiguration haben.

 

Sobald Sie die MOF Dateien generiert haben, können Sie diese mit Hilfe des PUSH Modus ausführen, indem Sie die Start-DSCConfiguration cmdlet abrufen.

The post Desired State Configuration – Elemente der Konfiguration appeared first on Scrum.de.

Kategorien: Rugby News

Läufst du noch hinterher oder „Scrumst“ du schon?

20. November 2014 - 14:08

Was ist das primäre Ziel eines jeden Unternehmens? Profit! Profit um jeden Preis.  Rentabilität geht einher mit Wettbewerbsfähig. Wettbewerbsfähigkeit im nationalen und internationalen Jungel der rivalisierenden Marktteilnehmer bedeutet um Ressourcen, Absätze und Marktanteile zu konkurrieren  und sich letztendlich durchsetzen zu können.

Aus diesem Grunde, ist die langfristige Existenzsicherung und Konkurrenzfähigkeit von Unternehmen abhängig davon, sich ständig umzuschauen, zu Vergleichen und neue Strategien zu entwickeln und diese zu implementieren.

Während meines Studiums der Betriebswirtschaft, habe mich grundsätzlich mit Kennzahlen und standardisierten Markt,- Portfolio,- und Wettbewerbsstrategien auseinandergesetzt. Insbesondere die Wasserfallstrategie mit ihrem rigidem „Anforderung-Entwurf-Implementation-Überprüfung-Wartung“  Ansatz kam häufig theoretisch in Klausuren und Praktisch in Projekten zur Anwendung. Eingehend, habe ich vom Primären Ziel eines Unternehmens der Wettbewerbsfähigkeit gesprochen. Allerdings wurde noch nicht erwähnt wie dieses oberste, überlebenswichtige Ziel erreicht werden kann.

Märkte bewegen sich, Anforderungen ändern sich, Kunden erwarten Flexibilität und Unternehmen müssen diesen Erwartungen gerecht werden. Betrachte ich mir erneut die Vorgehensweise im Wasserfallmodell, aber auch in anderen Ansätzen, frage ich mich, wie die Eingehens genannten Anforderungen erfüllt werden können?

Schluss mit veralteten, verrosteten und überholten Vorgehensweisen. Eine zeitgemäße, den Ansprüchen der Kunden und Märkte gerechte Strategie muss angewendet werden. Zunächst habe ich mich gefragt, welches Charakteristikum muss ein Unternehmen mitbringen, um auf dem gegenwärtigem Kriegsschauplatz der nationalen und internationalen Märkten langfristig bestehen zu können? Die Antwort darauf lieferte mir ein Niederländisches Unternehmen: Agilität!

Komplexe Strukturen entschlacken („Lean-machen“), Flexibilität und die Anforderungen des Kunden als höchste Priorität ansetzen, gelten als die Zentralen Charakteristika von agile Methoden. Produktionsprozesse sollen auf eine möglichst hohe effiziente und effektive Stufe gehievt werden um auf diese Weise Qualität eine optimale Kosten-Nutzen-Relation zu schaffen.

Scrum ist ein Weg unter dem „Schirm“ der agilen Methoden um diese Ziele zu erreichen. In den nächsten Wochen, möchte ich meine Erfahrungen vertiefen und teilen, ob Scrum ein adäquates Werkzeug ist, um Unternehmen auf Ihrem Weg zur Wettbewerbsfähigkeit und mehr Produktivität zu unterstützen, und wie dieser Ansatz genau dies schafft.

The post Läufst du noch hinterher oder „Scrumst“ du schon? appeared first on Scrum.de.

Kategorien: Rugby News

Desired State Configuration – Einführung in CIM

17. November 2014 - 17:22

PowerShell 4.0 führt in Desired State Configuration (DSC) ein – ein leistungsstarkes neues Feature, welches es einfacher denn je macht, ihre Windows Infrastruktur, ob Vorort oder in der Cloud, zu handhaben. DSC basiert auf dem von der Desktop Management Task Force (DMTF) entwickelten Common Information Model (CIM) und verwendet die Windows Remote Management (WinRM) Technologie als Kommunikationsmechanismus. In diesem Post möchten wir darauf schauen, was ein Windows Remote Management ist und wie es in der Windows OS Welt genutzt wird, damit es ein auf Standards basiertes Management ermöglicht. In dem nachstehenden Post möchte ich erläutern, wie CIM cmdlets in PowerShell WinRM verwendet, um mit Management Daten von Remote Systemen zu arbeiten und die Rolle von DSC beim Managen von Remote Maschinen.

 

Windows Remote Management ist die Microsoft Umsetzung des WS-Management Protokols. Es nutzt SOAP (Simple Object Access Protocol), um Kontrollinformationen und Daten zwischen Geräten über http und https auszutauschen. Das Hauptziel der WS-Management-basierten Durchführung ist die Bereitstellung eines gemeinsamen Weges für diese Systeme oder Komponenten um auf Informationen zuzugreifen und auszutauschen. Der WinRM Service ermöglicht die Fernwartung von Windows Systemen. Sie können das unten aufgeführte cmdlet verwenden, um den Status auf dem Computer zu überprüfen.

 

Get-Service -ComputerName ‘MyComputerXXX’ -Name WinRM

Wenn der Service nicht auf dem Computer aktiviert ist, können Sie einen empfängerbasierten Service auf HTTP oder HTTPS Protokoll basierend auf dem gewünschten Port erstellen. Um einen WinRam-Empfänger aufzubauen, können Sie das Set-WSManQuickConfig cmdlet verwenden. Sobald der WinRM-Empfänger erstellt und aktiv ist, können Sie die Infrastruktur verwenden, um auf Managementinformationen über entfernte Server zuzugreifen.

Das eingeführte CIM cmdlets als Teil von PowerShell 3.0 macht es leichter, mit Windows Management Instrumenten zu arbeiten. CIM – Common Information Model ist die DMTF-Norm für das Beschreiben der Struktur und der Reaktion auf Management Ressourcen wie Speicherung, Netzwerk oder Softwarekomponenten. Der CIM Standard definiert zwei Teile:

 

  1. Darstellung: Liefert die tatsächlichen Modelbeschreibungen
  2. Infrastruktur: Definiert den Standard für die Integration von vielfältigen Managementmodellen mit Hilfe von OOPS Konstrukten und Design.

 

Das CIM cmdlets unterstützt mehrere Arten um WMI zu erkunden. Sie funktionieren gut, wenn Sie in einer interaktiven Art arbeiten. Zum Beispiel, Tab Erweiterung weitet die Namespace aus, wenn Sie CIM cmdlets benutzen; dadurch könnte es sein, dass Namespaces erkundet werden, die anderweitig nicht feststellbar wären. Sie können diese Technik sogar verwenden, um tief in Namesspaces zu gehen. Beispielsweisen, wenn Sie alle Klassen aus dem Root/Microsoft Namespaces finden wollen, verwenden Sie cmdlet. Sie können Tab-Vervollständigung ausprobieren, nachdem Sie es in die –Namespace Option für das cmdlet- eingegeben haben.

 

Get-CimClass –Namespace root/Microsoft

Um eine Instanz einer Klasse zu schaffen, können Sie das Get-CimInstance cmdlet verwenden. Zum Beispiel, der unten gegebene Befehl legt alle Eigenschaften für die Klasse MSFT_WmiError frei.

 

Get-CimClass-ClassName MSFT_WmiError | ForEach-Object {$_.CimClassProperties}

Sie können ebenfalls den –ComputerName oder –CimSession Parameter verwenden, um entfernte Maschinen zu verwalten. Empfohlen wird, die CimSession zu benutzen und die Session wiederzuverwenden, wenn Sie versuchen ein breites Set an Optionen an entfernten Servern durchzuführen.

 

Beispielsweise können Sie unten angegebenen Befehl verwenden, um Details zu bekommen, wie die Prozesse auf den entfernten Servern laufen:

 

$session = New-CimSession –ComupterName XXX

Get-CimInstance –ClassName Win32_Process –CimSession $session

Sobald wir die CIM Session hergestellt haben und die Befehlsdurchführung vollständig ist, können wir die vorhandenen CIM Sessions entfernen, indem wir den Remove-CimSession cmdlet verwenden.

 

The post Desired State Configuration – Einführung in CIM appeared first on Scrum.de.

Kategorien: Rugby News

TEAM DYNAMICS

11. November 2014 - 13:41

Teil 1 – Die Kraft von Unschuld und Vision

Teams sind wirklich etwas Mysteriöses, oder etwa nicht? In unseren Schulungen und Trainings erzählen wir immer wieder vom Phasenmodell nach Tuckman. Wir machen aufmerksam darauf wie wichtig es ist, diese zu kennen und je nachdem entgegenzusteuern oder unterstützend einzugreifen, um Teamleistungen zu steigern.

Doch was passiert eigentlich in diesen Teams, unabhängig davon ob das Umfeld agil ist oder nicht? In einer kleinen und kompakten Blogserie möchte ich auf einige Punkte aufmerksam machen, welche mir immer wieder begegnen und so eine Art Awareness im Alltag dafür schaffen.

Machen wir uns nichts vor, wir als Menschen sind eine mehr oder minder egoistische Spezies, welche für Überzeugungen und Verletzungen ihrer selbstgewählten Grenzen kämpft. Wir sehen dies in unserem gesamten Alltag – Familie, Gewerkschaften gegen Arbeitnehmerverbände, Marketing gegen Finanzen – die Beispiele sind endlos und dieser Instinkt in uns ist auch essenziell wichtig. Doch wie schafft ein Team die richtige Balance zwischen Kooperation und internem Wettbewerb? Die Antwort darauf klingt auf den ersten Blick vielleicht etwas verwunderlich, aber sie liegt in der Unschuld. Unschuld? Nun, um das zu verstehen muss man den Unterschied von Unschuld zu Naivität kennen. Naivität bedeutet für mich die Gefahr für einen selbst nicht sehen zu können. Solche Menschen und Teammitglieder wechseln oftmals von einem Extrem ins andere, nämlich in ein egoistisches Denken, welches reine Kalkulation nach sich zieht und dem Einsatz vorangeht. Unschuld wie hier gemeint bedeutet, dass man diese Gefahr für sich selbst zwar erkennt, und dennoch versteht, dass jeder Einzelne im Team seinen Platz hat, auch wenn die Stärken des anderen den eigenen ähneln. Es bedeutet in die Fähigkeiten eines Teams vollkommen zu

vertrauen und davon überzeugt zu sein, dass das eigene Einbringen sich positiv auf einen selbst auswirken wird. Natürlich werden Menschen auf diesem Weg immer wieder durch Personen und Organisationen ausgenutzt, doch ich bin überzeugt das konsequente Gehen dieses Weges wird sich dennoch auszahlen, denn Unschuld ist eine Art Samen, alles muss stimmen, und es benötigt Zeit und Erfahrung um diese auszubilden. Ein Beispiel, welches dies verdeutlicht ist die Entstehungsgeschichte des ersten Toyota Werkes in den USA. Die Fabrik in Fremont, CA war zuvor in Besitz von GM und eine der unproduktivsten in den USA. Es herrschte ein ständiger Kampf zwischen dem Management und der Gewerkschaft, welche durch Streiks, Abschottung des eigenen Standpunktes und gekränkten Egos die Produktivität weiter senkte und so letztendlich zur Schließung führte. Als Toyota dann das Werk übernahm, unterzeichnete man ein gegenseitiges Abkommen. Im Gegensatz zum vorhergehenden 300 Seiten dicken Dokument, bestand dieses Abkommen aus lediglich 15 Seiten, welches u.a. eine Verschlankung der Berufsbezeichnungen und Prozesse, kleinere Teamgrößen, ein faires Verhältnis bei Entlassungen zwischen Management und Belegschaft und eine gemeinsame Vision vorsah. Das Ergebnis war, dass das vormals so unproduktive und schlecht koordinierte Werk eines der besten im Land wurde. Um das zu erreichen mussten viele Menschen ihre Komfortzone verlassen, gemeinsam auf ein Ziel hinarbeiten und ineinander und in das Ergebnis vertrauen. Diese Werte gelten auch im agilen Umfeld, vielleicht viel mehr als in anderen, aber sie benötigen einen Anstoß.

Dieses Beispiel zeigt drei Erkenntnisse deutlich:

Teammitglieder sind bereit zu einer Transformation, wenn die Situation aussichtslos erscheint und Folgendes eintritt:

– vorheriger Erfolg oftmals ausblieb

– der Überlebensinstinkt wichtiger wird als der territoriale Instinkt des Einzelnen

– Teil eines Erfolgs und einer Vision zu sein höher angesehen wird als das persönliche Ego

– die gemeinsame Energie und Enthusiasmus eines Teams durch Einsatz, Mut und Instinkt ein Eigenleben bilden

– unerwartet hohe Ergebnisse eintreten

Ein Team das diese Transformation beginnt wird die freigesetzte Energie schnell fühlen und so interne Wettkämpfe und egoistisches Verhalten beiseite legen (können). Die in SCRUM eingesetzten Methoden machen Erfolge sofort sichtbar und unterstützen das Team in diesem Prozess.

Im nächsten Teil geht es um Fallen, die ein Team erwarten, sobald erste Erfolge eintreten.

Anastasios Psarros ist in Lübeck geboren und hat einen Abschluss als Versicherungskaufmann und einen Master in International Information Management in Deutschland und in San Francisco, USA. Er hilft Unternehmen auf den agilen Weg.

The post TEAM DYNAMICS appeared first on Scrum.de.

Kategorien: Rugby News

Wir können nicht mit Continuous Delivery arbeiten, weil wir –Produkt/Technologie XY– einsetzen

5. November 2014 - 15:06

Oft höre ich Leute sagen, dass sie mit Continuous Delivery arbeiten  wollen, aber es unmöglich ist, weil sie ein bestimmtes Produkt oder eine bestimmte Technologie einsetzen. Zum Beispiel: Anstelle einer maßgeschneiderten Java- oder NET-Anwendung nutzen diese ein Produkt von der Stange, für das sie alle x Monate ein Update erhalten und nur konfigurieren müssen. Es stimmt zwar, dass die meisten Beispiele, die man für Continuous Delivery findet , unter Nutzung einer maßgeschneiderten Lösung von Java oder NET oder anderen Programmen funktionieren, aber das heißt nicht, dass man CD nicht auch mit anderen  Technologien nutzen kann. Sogar mit einer Software von der Stange, die nur alle paar Monate aktualisiert wird, kann man Continuous Delivery einsetzen und seinen Nutzen daraus ziehen.

Mit Continuous Delivery stellen wir sicher, dass die Anwendung immer im Status „bereit zur Produktionfreigabe“ ist. Dies schaffen wir durch automatisches Erstellen, Einsetzen und Durchführen aller Arten von Tests und Prüfungen, sobald eine Änderung an der Anwendung stattfand. Ist etwas nicht in Ordnung, bekommen wir das zeitnah mit und können entsprechendeMaßnahmen ergreifen (Fail Fast Prinzip). Aber wie funktioniert das, wenn Sie einen externen Lieferanten haben, der Software nur alle paar Monate herausgibt?

Eine Anwendung besteht aus mehr als nur Binärprogrammen, sie enthält auch Konfigurationen und Daten, um die Anwendung zu kontrollieren.  Eine Änderung der Anwendung kann eine Änderung der Binärprogramme (ein neues Release vom Lieferanten) bedeuten, aber auch eine Änderung in der Konfiguration oder den Daten. Die beiden letzteren werden meistens ‚Inhouse‘ durchgeführt und finden viel häufiger statt. Um die Anwendung in einem Status der Einsatzbereitschaft zu erhalten, wollen wir den gesamten Mix an Binärprogrammen, Konfigurationen und Daten testen, sobald eine Änderung an einer der Komponenten erfolgt. Der einzige Unterschied zu einer kundenspezifischen Software ist der, dass wir nicht den  anfänglichen Build-Schritt in unserer  Entwicklungslinie haben, da dieser beim Lieferanten erfolgt.

Auch wenn Sie kein Produkt konfigurieren oder Daten ändern müssen, bietet Continuous Delivery einige Vorteile, wie die automatische Entwicklung der Anwendung in einer Umgebung, kurzer Feedback-Prozess (Fail Fast) und automatische Tests. Und um einen Schritt zu automatisieren, muss er erst einmal betriebssicher und wiederholbar sein, was einen großen Einfluss auf die Qualität des Implementierungsprozesses hat. Praxis führt zu Perfektion und das trifft auch auf Continuous Delivery zu.

Continuous Delivery ist komplett unabhängig von der Technologie der Anwendung. Änderungen der Binärprogramme sind nicht die einzigen Auslöser für das Starten der Pipeline, sondern auch Änderungen  von Konfigurationen oder Daten sollten Auslöser dafür sein. Wenn Sie also mit Software eines externen Lieferanten arbeiten, bedeutet es nicht, dass Sie kein Continuous Delivery mehr durchführen können. Tun Sie es einfach, Schritt für Schritt!

The post Wir können nicht mit Continuous Delivery arbeiten, weil wir –Produkt/Technologie XY– einsetzen appeared first on Scrum.de.

Kategorien: Rugby News

Backlog Priorisierungs Quadrant

5. November 2014 - 14:36

Eine der Hauptaufgaben des Product Owners ist das Verwalten des Produkt-Backlogs. Es ist eine Teamleistung, das Backlog zu verfeinern, aber der Product Owner trägt die Verantwortung für die Priorisierung des Backlogs. Dies ist eine herausfordernde Aufgabe. Product Owner, die neu in ihrer Rolle sind, denken, dass das Backlog nur User Stories für neue Merkmale enthält.  Aber schnell finden sie heraus, dass dies nur ein Teil des Backlogs ist. Aber was sind die anderen Teile? Und wie kann man das richtige Gleichgewicht zwischen ihnen finden? In diesem Moment zeigt der ‚Backlog prioritisation quadrant‘ seinen Nutzen.

Der Backlog Priorisierungs Quadrant wird in folgender Abbildung dargestellt.

Der Backlog Priorisierungs Quadrant teilt das Backlog in neue Features, architektonische Innovation, Support und technische Schuld.

Der offensichtlichste Teil eines Backlogs sind die neuen Features (Geschäftsfokus, Zukunftsorientierung). Diese sind auch für den Kunden und dem Product Owner der Hauptfokus. Nach deren Meinung kann ein wirklicher Geschäftswert nur mit neuen Merkmalen geliefert werden. Alles andere ist weniger wichtig und sollte nicht vom Budget finanziert werden.

Dennoch kann das Arbeiten an architektonischen Innovationen (technischer Fokus, Zukunftsorientiert) ebenso den Geschäftswert steigern und das Kundenvermögen sparen, welches wieder in neue Features investiert werden kann. Zum Beispiel die Benutzung eines neuen Tools zur Testautomatisierung, um Testabdeckung oder eine neuen Entwicklungsrahmen zu verbessern bevor es überflüssig wird. Ein gutes Entwicklungsteam stellt sicher, dass immer Zeit für architektonische Innovationen bleibt und die Fähigkeit hat dem Product Owner den Wert der nichttechnischen Bedingungen zu erklären.

Der zweite Bereich, Support und technische Schuld, sind in der Vergangenheit angesetzt. Support hat den Geschäftsfokus und wird verwendet, um den Kunden die Unterstützung anzubieten bevor ein Produkt gebaut wird. Beispiele sind Fehlerbehebung, geringfügige Verbesserung von vorhandenen Features oder Instandhaltungsarbeiten. Dies scheint nicht die aufregendste Arbeit zu sein, aber sie sollten immer Zeit im Backlog dafür einplanen. Dies wird auf jeden Fall einen positiven Effekt auf die Kundenzufriedenheit haben.

Am schwersten zu erklären ist der Bereich technische Schuld, weil es in der Vergangenheit angesiedelt ist und einen technischen Focus hat. Technische Schuld wird hauptsächlich als Problem des Entwicklungsteams angesehen und sie sollten es selber beheben. Selbst wenn schlecht geschriebene Codes eine Form von technischer Schuld sind, bedeutet dies nicht, das dies absichtlich geschieht. Neue Erkenntnisse oder gewonnenes Wissen können die Gründe für das abändern eines vorhandenen Codes sein. Der Product Owner sollte ebenso verantwortlich für technische Schuld sein, indem er das Team ermutigt, technische Abkürzungen zu nehmen, um die Deadline einzuhalten. Technische Abkürzungen können wiederum der Grund für technische Schuld sein. Am Ende spart es dem Kunden Geld, wenn man Zeit in die Verringerung von technischer Schuld investiert. Ein Produkt mit vielen technischen Fehlern wird gravierenden Einfluss auf die Schnelligkeit des Entwicklerteams haben und das Team daran hindern, an neuen Features zu arbeiten.

Ich empfinde den Backlog Priorisierungs Quadrant als ein mächtiges Werkzeug, welches viele Möglichkeiten bietet:

  • Durch die Aufteilung aller User Stories Ihres aktuellen Backlogs können Sie sehen wie sie sich genau verteilt.

Haben wir viel technische Schuld? Benötigen wir mehr Zeit für technische Innovationen? Wie viel Zeit haben wir tatsächlich, um neue Features zu kreieren.

  • Durch prozentuales Aufführen der Ist- und Soll-Situation können Sie mit dem Team und/oder der Interessensgruppe diskutieren, wie sie dies erreichen.
  • Es zeigt dem Product Owner und der Interessengruppe, dass nichts über neue Features geht, aber es sollten auf keinen Fall die anderen drei Bereiche außer Acht gelassen werden. Es kann während des Sprint reviews oder als Diskussionsgrundlage zur Verfeinerung der nächsten Perioden benutzt werden.

Ich bekam die Idee des Backlog Priorisierungs Quadrant als Agilität wuchs. Es bietet wertvolles Material, welches die Inspiration anderer Agile/Scrum Trainer antreiben soll. Fühlen Sie sich frei, den Quadranten zu verwenden und teilen Sie Ihre Erfahrungen in Kommentaren zu diesem Blogpost. Ich bin sehr gespannt zu erfahren, ob diese Technik Ihnen weitere Vorteile zu den oben beschriebenen bietet.

The post Backlog Priorisierungs Quadrant appeared first on Scrum.de.

Kategorien: Rugby News

Continuous Delivery Definitionen

4. November 2014 - 14:49
Continuous Delivery 

Continuous Delivery ist die Methode mit der wir  eine Umgebung schaffen (wollen), in der jede Version jederzeit in die Produktion überführt werden kann! Dies beginnt mit Continuous Integration. Continuous Integrations liefert eine Softwareversion, die erfolgreich erstellt wurde und alle automatisierten (Unit) Tests durchlaufen hat. Um zu gewährleisten, dass die Anwendung der gewünschten Qualität entspricht, sollte anschließend in der  Testumgebung(en) entwickelt werden wo die  Anwendung weiter getestet wird. Sobald dieser Prozess abgeschlossen ist, sollte es möglich sein die Version in die Produktion zu installieren. Dieser gesamte Prozess, inklusive der Installation in die Produktion, sollte weitestgehend automatisch ablaufen, so dass er wiederholbar ist und mehrmals am Tag durchlaufen werden kann. Dies ermöglicht dem Unternehmen die Entscheidung über die Auslieferung neuer Versionen. Mit dem Einsatz von Continuous Delivery ist die IT nicht länger ein Engpassfaktor bei geschäftlichen Entscheidungen.

 

Continuous Deployment

Continuous Deployment könnte als eine Erweiterung von Continuous Delivery angesehen werden. Continuous Delivery bedeutet, dass wir Software erstellt haben, die jederzeit in Produktion gehen kann. Mit Continuous Deployment wollen wir dem Anwender die Software bei gleichzeitiger Integration in die Produktivumgebung ausliefern. Das bedeutet, dass jede Veränderung in die Produktion einfließt. Dafür müssen Ihre Veränderungen einen eigenen Mehrwert darstellen. Kombiniert mit AB-Tests ist dies ein Ansatz, in dem Sie Ihre Vermutungen bei Anwendern testen können. Sie erhalten Feedback und bringen Veränderungen zur weiteren Verbesserung Ihres Produktes an.

 

Continuous Integration 

Continuous Integration ist das Verfahren, mit dem wir den Code so weit wie möglich integrieren wollen, um zu gewährleisten, dass alle Komponenten weiterhin miteinander funktionieren. Entwickler sind dabei verpflichtet, ihren Code in einer gemeinsamen Kontrollumgebung einzuchecken. Mit jedem Check-in wird eine neue Softwareversion erstellt. Spätestens einmal am Tag wird die aktuelle Version erstellt und mit automatischen (Unit-) Tests getestet, um sicherzugehen, dass die Veränderungen nichts zerstört. Falls Störungen auftreten, informieren wir die Entwickler, sodass diese das Problem beheben können. Eigentlich geht es nur darum, die Feedbackschleife zu verkürzen und Integrationsprobleme schnell zu finden. Auf diese Weise können Probleme leichter behoben werden als zu einem späteren Zeitpunkt im Projekt. Die Erstellung und das Testen sollten bei jedem Check-in stattfinden, damit die Entwickler die Probleme schneller und leichter finden und um möglichst kleine Check-ins zu haben. Dies erleichtert die Lokalisierung des Problems.

 

DevOps

Bei DevOps geht es darum, die Mauern zwischen Entwicklung (Development) und des operativen Managements (Operation) zu beseitigen, indem ihnen gemeinsam die Verantwortung für das Endergebnis (funktionierende und getestete Software in der Produktion) übertragen wird. In traditionellen Organisationen beobachten wir, dass sich die Entwicklerteams zwar für die Erstellung der Software verantwortlich fühlen, aber weniger dafür das die Software in Produktion gehen kann. Dies ist die Verantwortung des operativen Managements. Durch den Einsatz von DevOps-Verfahren bringt man beide zusammen, sodass sie gemeinsam an der schnellen Erstellung hochwertiger Software arbeiten können.

 

TDD

Test Driven Development ist ein Verfahren, in dem der Entwickler zunächst einen Test schreibt, bevor der tatsächliche Code für die Funktionalität implementiert wird. Nach dem Schreiben des Tests, wird der Programmcode mit möglichst wenig Aufwand geschrieben. Dieser Code muss den Test bestehen. Sofern erforderlich wird der Code angepasst, um die Lösung möglichst schlank zu halten (das nennen wir Refactoring). Nach dem Refactoring schreiben die Entwickler einen neuen Test für die nächste Funktionalität, die sie implementieren wollen. Es ist wichtig, möglichst kleine Veränderungen vorzunehmen, so dass sie nur kleine spezifische Einheiten (Klassen) betreffen (und testen). Damit wird eine  Unit-Tests Suite geschaffen, um sicherzustellen, dass die aktuellen Veränderungen auf Unit-Ebene keine Störungen verursachen. Darüber hinaus gibt es Entwicklern mehr Sicherheit bei der Implementierung der Software. Als Nebeneffekt testen Sie auch die Dokumentation über die Funktionsweise des Codes. Meistens ist das Ergebnis auch eine Codebasis, die besser zu testen und zu warten ist. Die Einführung von TDD heißt nicht, dass Sie die Software nicht darüber hinaus noch testen sollten. Unit-tTests sind Entwickler-Checks, die prüfen, ob die Software so, wie sie geschrieben wurde, auch funktioniert. Das heißt nicht, dass die Software so funktioniert, wie der Anwender sie benötigt. Dies erreicht man mit der Anwendung von Acceptance Test Driven Development ATTD.

The post Continuous Delivery Definitionen appeared first on Scrum.de.

Kategorien: Rugby News

Scrum Definitionen

4. November 2014 - 14:01
Burndown chart

Der Burndown ist eine Grafik, die den Fortschritt während des Sprints darstellt. Diese Grafik enthält zwei Linien, die verfügbare Kapazität und die benötigte Kapazität. Beide Linien werden gegen eine Zeitschiene gesetzt. Solange die verfügbare und die benötigte Kapazität gleich verlaufen, weiß das Team, dass der Sprint plangemäß verläuft. Der Burndown wird täglich aktualisiert und ist für jeden einsehbar. Daily Scrum

Jeden Tag hält das Team ein kurzes Meeting von 15 Minuten, das Daily Scrum oder Daily Standup genannt wird. Ziel dieses Meetings ist dafür zu sorgen, dass jeder so effektiv wie möglich beschäftigt ist. Um das Meeting kurz und effektiv zu halten, bleiben alle stehen und jeder beantwortet die folgenden 3 Fragen: Definition of Done

Die Definition of Done beschreibt, welche Anforderungen das Ergebnis eines Sprints erfüllen muss. Es ist ein Hilfsmittel für das Team, um eine gleichbleibende Qualität zu gewährleisten. Die Definition of Done wird vom Team selbst erstellt und beschreibt Dinge wie Testing, Modultests, Dokumentation usw. Planning Poker

Das gesamte Team muss eine zuverlässige Schätzung abgeben. Pokerplanning ist die Art und Weise, wie mit dem ganzen Team eine Schätzung aufgestellt werden kann. Jeder gibt mit Karten an, wie viel Arbeit mit einem Backlog Item verbunden ist. Unterschiede in der Schätzung werden besprochen, die Anzeige mit den Karten wird wiederholt, bis Übereinstimmung erreicht wird. Die durch diese Schätzmethode angeregte Diskussion gewährleistet, dass nichts vergessen und jeder einbezogen wird. Dadurch wird gemeinsam eine zuverlässige Schätzung erreicht. Product Backlog

Der Product Backlog ist eine Liste mit verbleibenden Tätigkeiten für das Produkt. Die Product Backlog Items werden auch User Stories genannt. Alle Product Backlog Items werden mit einem Business Value versehen. Dieser gibt an, wie viel Wert ein Item für den Kunden oder den Benutzer hat. Die Items werden vom Team mit einer Schätzung versehen. Auf der Grundlage des erwarteten Werts und des erforderlichen Einsatzes kann der Return On Investment (ROI) berechnet werden. Die Priorisierung im Product Backlog erfolgt auf Basis des ROI. Dadurch wird die verfügbare Kapazität immer optimal eingesetzt. Product Owner

Der Product Owner vertritt die Interessen des Kunden und anderer Stakeholder. Er sorgt dafür, dass sich das Team mit den richtigen Themen beschäftigt. Zu diesem Zweck führt der Product Owner eine Liste (Product Backlog) mit Items, die dem Produkt noch hinzugefügt werden müssen. Die wichtigste Aufgabe des Product Owners ist die Festlegung von Prioritäten, so dass die im Sprint festgelegten Tätigkeiten einen maximalen Wert für den Kunden erbringen. Der Product Owner übernimmt auch die Abstimmung der Prioritäten mit den verschiedenen Stakeholdern. Retrospective

Der Sprint wird mit der Retrospective beendet. Während dieses Meetings blickt das Team auf den Arbeitsprozess im vergangenen Sprint zurück. Was gut lief, muss in jedem Fall beibehalten oder verbessert werden. Was nicht gut lief, muss aufgegriffen werden, damit in den folgenden Sprints nicht dieselben Fehler gemacht werden. Rollen

In der Scrum-Methode gibt es 3 Rollen: den Product Owner, der die Interessen des Kunden vertritt den Scrum Master, der den Prozess unterstützt und das Team, das in einer kurzen Zeit funktionierende Software liefern kann. Scrum

Die Scrum-Methode ist ein Framework für agiles Projektmanagement. Die Scrum-Methode ist in der Softwareentwicklung beliebt, da sie einfach und flexibel ist und schnell brauchbare Ergebnisse liefert. Bei der Scrum-Methode wird mit multidisziplinären Teams gearbeitet, die in kurzen Iterationen (Sprints) funktionierende Software erstellen. Eine enge Kommunikation mit dem Kunden, Feedback und Teamgeist sorgen für einen effektiven Arbeitsprozess. Obwohl Scrum für die Softwareentwicklung entwickelt wurde, wird die Methode auch in der Systemadministration, in Sales, im Marketing und in anderen Fachgebieten eingesetzt. Scrum Board

Das Task Board oder Scrum Board ist eine Tafel, an der alle Sprint Backlog Items hängen. Die Aufgaben an der Tafel sind auf 3 Spalten verteilt: To Do, In Progress und Done. Die wichtigsten Aufgaben hängen oben an der Tafel, der Sprint Backlog ist damit nach Priorität sortiert. Gemeinsam mit dem Burndown hat man mit dieser Tafel einen Überblick über den aktuellen Status. Das Scrum Board ist für das Team der zentrale Ort, um die verbleibenden Tätigkeiten und die Maßnahmen abzustimmen. Scrum Master

Der Scrum Master ist der Coach des Teams. Er achtet darauf, dass sich das Team an die Scrum-Spielregeln hält. Er schützt das Team während des Sprints, so dass das Team sich auf die vereinbarten Ziele konzentriert. Der Scrum Master hilft dem Team, sich selbst zu verbessern, schneller zu werden und eine höhere Qualität zu liefern, in dem er dem Team Hindernisse (Impediments) aus dem Weg räumt. Sprint

Die Scrum-Methode ist iterativ. Jede Iteration wird „Sprint” genannt. Ein Sprint dauert 2 bis maximal 4 Wochen. Innerhalb dieser Zeit bearbeitet das Team eine im Vorfeld ausgewählte Menge an Aufgaben, die vollständig abgearbeitet werden. Ergebnis jedes Sprints ist ein Stück funktionierende Software. Dadurch ist das Produkt schnell einsetzbar und das Team erhält schnell Feedback zum Produkt und zum Prozess. Sprint Backlog

Der Sprint Backlog ist eine Aufgabenliste, die das Team während des Sprints abarbeiten muss. Items des Product Backlog werden während des Sprint Planning Meetings vom Team in Aufgaben aufgeteilt. Die Aufgaben des Sprint Backlog werden nicht zugewiesen, die Teammitglieder nehmen sich selbst die Aufgaben, die wichtig sind und die zu ihrem Wissen und ihrer Erfahrung passen. Sprint planning meeting

Jeder Sprint beginnt mit einem Sprint Planning Meeting. In diesem Meeting bespricht der Product Owner die Tätigkeiten, die er vom Team gern erledigt haben möchte. Anschließend wählt das Team die Items aus dem Backlog aus, die in einem einzigen Sprint bearbeitet werden können. Diese Items werden vom Team in Aufgaben aufgeteilt, die wiederum mit einer Schätzung versehen werden. Das Ergebnis ist ein Sprintplan, der in der kurzen Zeit von 1 oder 2 Wochen umgesetzt werden kann und bei dem das Ergebnis gesichert ist. Sprint Review

Im Sprint Review oder in der Sprint Demo am Ende des Sprints wird das Ergebnis des Sprints vorgestellt. Das Team zeigt mit einer Demo, dass das Produkt wirklich funktioniert und der Definition of Done entspricht. Ziel dieses Meeting ist die Darstellung der erzielten Fortschritte. Dies ist für den Product Owner ein wichtiger Moment, um Feedback von anderen Stakeholdern zu bekommen. Team

Das Team ist multidisziplinär und selbststeuernd. Das heißt, dass das Team selbständig in der Lage ist, alle Aufgaben vom Entwurf, der Umsetzung, dem Testing bis hin zur Auslieferung zu übernehmen. Das Team besteht aus 5 bis 9 Mitgliedern. Das Team ist sowohl für die Planung als auch die Durchführung der Tätigkeiten während des Sprints verantwortlich. Das Besondere an der Scrum-Methode ist die eigene Verantwortung des Teams für den Arbeitsprozess. Da jeder Sprint mit einer Evaluation endet, wird kontinuierlich an einer Verbesserung dieses Prozesses gearbeitet. Team Velocity

Die Velocity ist die Arbeitsmenge, die das Team in einem einzigen Sprint bearbeiten kann. Die Arbeitsmenge jedes Sprints wird notiert. Auf der Grundlage dieser Velocity kann das Team einschätzen, wie viel Arbeit es pro Sprint übernehmen kann. User Stories

User Stories sind Items, die im Product Backlog stehen. Diese beschreiben Anforderungen zum Beispiel von Kunden, die noch realisiert werden müssen. Der große Unterschied zu klassischen Requirements besteht darin, dass die User Stories beschreiben, warum etwas getan werden muss. Der Grund oder der Anlass ist für das Team wichtig, um eine passende Lösung zu entwickeln. Darüber hinaus können Akzeptanzbedingungen oder ein Demoskript in die User Story aufgenommen werden. Wie die Lösung genau aussehen muss, wird vom Team während des Sprints festgelegt.

The post Scrum Definitionen appeared first on Scrum.de.

Kategorien: Rugby News

Umgang mit Fehlern in einer Agile-Umgebung

1. November 2014 - 16:27

Teams quälen sich häufig mit der Beantwortung der folgenden Frage: „Wie handhaben wir unsere Fehler in einer agilen Umgebung?” Sie beginnen Scrum als ein Framework zu benutzen, um ihre Software zu entwickeln. Bei der Implementierung stoßen sie jedoch auf Probleme beim Umgang mit Fehlern, die sie im Verlauf des Prozesses finden/verursachen.

Scrum ist ein Framework, welches nicht direkt vorgibt, wie mit Fehlern umgegangen werden soll. Die direkte Antwort wäre, Fehler als Product Backlog Items zu behandeln, die in den Product Backlog aufgenommen werden sollten. Wenn der Product Owner ihre Priorität als sehr hoch einstuft, dann werden sie vom Entwicklungsteam beim nächsten Sprint mit berücksichtigt. Die Umsetzung ist jedoch etwas komplizierter und sollte deshalb etwas ausführlicher erklärt werden.

Download Whitepaper Umgang mit Fehlern in einer Agile-Umgebung

The post Umgang mit Fehlern in einer Agile-Umgebung appeared first on Scrum.de.

Kategorien: Rugby News

Agile Verträge – 6 Best Practices, um Ihr Scrum Team zu gründen

28. Oktober 2014 - 14:46

Agile Aufträge sind ein breit gefächertes Thema, welches von mehreren Perspektiven mit  verschiedenen Arten von Verträgen angegangen werden kann. Dieser Blogeintrag wurde aufgrund meiner eigenen Erfahrung aus der Mitarbeit als Lieferant bei einer Netzagentur geschrieben. Dies ist die Perspektive die ich verwendete. Der Kunde ist ein externer Kunde, der unsere Unterstützung für ein Softwareentwicklungsprojekt ersuchte..

Einer der Werte des agilen Manifests ist „Kundenzusammenarbeit über Vertragsverhandlungen“.  Es legt fest, dass das Kunden-Lieferanten-Verhältnis eine wirksame Partnerschaft sein sollte, wo der Vertrag lediglich unterstützend wirken sollte. Die Anpassung an neue Einblicke und wachsende Prozesskenntnisse sollte nach einer gesunden Diskussion mit der Interessensgruppe möglich sein. Auf Änderungen zu reagieren, wird mit einem einfachen Vertrag, der nur die notwendigsten Vereinbarungen über die Kooperation zwischen dem Kunden und Lieferanten enthält, unterstützt.

In der Realität sind Vertragsverhandlungen jedoch schwieriger. Der Kunde will seine gute Idee umsetzen, ist hoch enthusiastisch und die Möglichkeiten sind endlos. Und einzig muss sich auf den Vertrag geeinigt werden…

Die Schwierigkeit bei Verträgen ist, dass alles über Vertrauen abläuft. Wenn ein gutes Vertrauen zu den gegenseitigen Fähigkeiten und Ansätzen vorherrscht, wird ein Vertrag aufzusetzen nicht allzu schwierig werden. Aber meistens haben Kunde und Lieferant vorher noch nicht zusammen gearbeitet, sodass keine Vertrauensgrundlage vorhanden ist. Der Kunde möchte ‚Sicherheit‘ und die vollständige Kontrolle über Budget, Zeit, Qualität und Umfang. Ein ordentlicher Change-Controll-Prozess weißt immer Mängel auf. Nach einigen zähen Verhandlungen beginnt zwar das Entwicklungsteam, aber nicht wirklich in Zusammenarbeit mit dem Kunden und mit veralteten Anforderungen. Ein suboptimales Produkt wird dann das Ergebnis sein, was die Beziehung und das Vertrauen tief beschädigt.

Aber wie kann man Vertrauen schaffen, wenn man vorher noch nicht zusammen gearbeitet hat? Wie kann man einen Vertrag gestalten, welcher dem Kunden genug Kontrolle und gleichzeitig dem Team genug Flexibilität z. B. beim Umfang gibt?

Um diese Fragen zu beantworten, möchte ich einige meiner eigenen Best Practicen mit Ihnen teilen.

  1. Entwerfen Sie gemeinsam die Produktvision & das Produkt-Backlog

Oftmals hat der Kunde eine genaue Vorstellung über das Produkt und deren Möglichkeiten, aber ein Produkt-Backlog fehlt immer noch.  Dies liegt entweder daran, dass die Erfordernisse nicht bereit sind, oder dass keine Erfahrung vorhanden ist, ein Produkt-Backlog zu erstellen. Ein gute Methode ist es, gemeinsam mit dem Kunden das Produkt-Backlog zu erstellen, bevor ein Vertrag erstellt wird. Denn zum Verstehen der Kundenbedürfnisse sind einige Einblicke erforderlich. Organisieren Sie einen Workshop mit Kunden und Entwicklungsteam (einschließlich eines Business Analysten) und lassen Sie diese gemeinsam das Produkt-Backlog erstellen. Idealerweise wir so auch eine Produktversion (mit Hilfe von Roman Pichler’s Produktvisionstafel), um ein gegenseitiges Verständnis sicherzustellen.  Durch das gemeinsame Schaffen der Produktvision und das Produkt-Backlogs lernen sich Kunde und Lieferant wirklich kennen. Noch wichtiger: der Kunde trifft das tatsächliche Entwicklerteam. Denn sie sind diejenigen, die seinen Traum realisieren. Sie sind die, denen er vertrauen muss.

  1. Beurteilen Sie gemeinsam das Produkt-Backlog

Nachdem das Produkt-Backlog gemeinsam erstellt wurde, ist es genauso möglich, es im Beisein des Kunden zu beurteilen. Der Vorteil ist, der Kunde hört direkt, worüber Diskutiert wird und wo Fragen auftreten und kann direkt drauf reagieren. Mögliche Komplexitäten werden ebenso wahrgenommen und gemeinsam erörtert und somit gegenseitiges Verständnis über die Einschätzungen sichergestellt.

  1. Beginnen Sie klein

Selbst wenn der Kunde ein großes Budget für sein Projekt zur Verfügung hat, einigen sie sich darauf nur einen Sprint zu machen. Nachdem Sie die Produktvision und das Produkt-Backlog in einem kooperativen Workshop erstellt haben, machen Sie nur den ersten Sprint mit dem Ziel eine ‚Working Software‘ zu liefern.

  1. Laden Sie den Kunden zu den Scrum Sitzungen ein

Laden Sie den Kunden zu allen Scrum Sitzungen ein (Voraussetzung Scrum wird genutzt). Lassen Sie den Kunden erfahren, wie der ‚Daily Scrum‘ abgelaufen ist, welche Diskussionen während des ‚Sprint Plannings‘ aufgetreten sind und teilen alle Erkenntnisse des ‚Sprint Reviews‘. Am wichtigsten ist selbstverständlich das Sammeln von Feedback über das gelieferte Produkt und der Beurteilungen der Zusammenarbeit.

  1. Verkaufen Sie das komplette ‚Scrum Team‘

Feste Scrum Teams, die für einen längeren Zeitraum zusammen gearbeitet haben, haben zusammen „up‘s & down‘s“ erlebt und wissen, dass Schnelligkeit Gold wert ist. Eine üblicher Fehler ist es, dass ‚goldene Team‘ zu trennen, wenn ein neues Projekt anfängt. Tun Sie das nicht. Halten Sie das Team um jeden Preis zusammen. Der Kunde bekommt das komplette Team, einschließlich Testern, Analysten Designern, Scrum Master, Entwickler usw.

  1. Verkaufe Sprints

Wenn Sie mit festen Teams arbeiten, die ihre Geschwindigkeit kennen, dann ist der Verkauf der Sprints für das Team leichter. Selbstverständlich ist Geschwindigkeit etwas vom Team und kann mit jedem Produkt was sie herstellen variieren. Ein festes, erfahrendes Team weiß wozu es fähig ist und kann ein Produkt-Backlog schätzen und angeben, wie viele Sprints es für die Realisierung voraussichtlich benötigt. Zum Beispiel: zwischen 5 – 7 Sprints. Weil das Team fest ist, wissen Sie auch was die Kosten pro Sprint sind. Zum Beispiel: 40.000,-. Das bedeutet, dass das notwendige Budget für dieses Projekt zwischen 200.000,- und 280.000,- liegen wird. Zudem bietet der Verkauf von Sprints dem Kunden den Vorteil nach Möglichkeit den Vertrag frühzeitig zu beenden. Wenn die Kosten für die Fortsetzung des Projekts höher sind, als erwartet, dann gibt es die Möglichkeit keine weiteren Sprints zu kaufen. (http://jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html).

Am Ende geht es einzig und allein um Vertrauen. Erstellen Sie die Produktvision und das Produkt-Backlog zusammen, schätzen Sie das Produkt-Backlog zusammen, beginnen Sie klein und laden Sie den Kunden zu den Scrum Sitzungen ein, sind alles die Methoden, um die notwendige Basis für  Vertrauen zu generieren. Wenn eine Vertrauensbasis vorherrscht, wird es für Sie einfacher das komplette Scrum Team

The post Agile Verträge – 6 Best Practices, um Ihr Scrum Team zu gründen appeared first on Scrum.de.

Kategorien: Rugby News

Priorisierung im Product Backlog

8. Oktober 2014 - 16:37

Eines der wichtigsten Artefakte in Scrum ist das Product Backlog. Das Product Backlog gehört dem Product Owner und enthält eine geordnete Auflistung von allem, das für das Produkt benötigt wird. Es ist dynamisch und verändert sich fortlaufend, um Anforderungen zu identifizieren, mit denen ein Produkt realisiert und optimiert werden kann, um wettbewerbsfähig und nützlich zu sein.

Der Scrum Guide von scrum.org sagt einiges dazu, WAS ein Scrum Team mit dem Product Backlog tun sollte, um sicherzustellen, dass mit jedem Sprint die wertvollsten Features geliefert werden. Was er uns nicht verrät, sind Details über das WIE ein solches Backlog strukturiert und priorisiert wird, damit es in der täglichen Arbeit übersichtlich, transparent und für jeden verständlich bleibt. Steht einmal eine durchdachte Backlog Struktur, kommt der Priorisierung aller Einträge im Product Backlog eine zentrale Bedeutung zu.

Dieses Whitepaper enthält einige Tipps und Beispiele, wie die Einträge eines Product Backlogs priorisiert werden können. Es ist nützlich für alle, die ein Product Backlog anlegen und pflegen sowie Anregungen suchen, um sich die Arbeit leichter zu machen.

Was ist ein Product Backlog?

„Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die Änderungen an dem Produkt in zukünftigen Releases ausmachen.“ (aus dem Scrum Guide)

Download Whitepaper Priorisierung im Product Backlog

The post Priorisierung im Product Backlog appeared first on Scrum.de.

Kategorien: Rugby News

(Mis) Kommunikation

8. Oktober 2014 - 16:06

Die meisten Projekte scheitern nicht an knappen Budgets oder Ressourcen: sie scheitern aufgrund mangelhafter Kommunikation der Beteiligten. In agilen Projekten nehmen daher Kollaboration, Kommunikation und regelmäßiges Feedback einen enorm hohen Stellenwert ein.

„People and their Interaction more than processes and tools“  aus dem Agile Manifesto

Zielführende, verständliche Kommunikation ist in komplexen Umgebungen mit regelmäßigen Änderungen und Abhängigkeiten essentiell. Wie sollen Anforderungen und Wünsche der Kunden verstanden werden, wenn man sich innerhalb der Organisation bereits missversteht? Wie sollen agile Teams effektiv und transparent Information und Wissen transferieren, wenn Basis-Prinzipien nicht beherrscht werden?

Es ist mir ein Anliegen, Ihre Aufmerksamkeit für Soft- Skills und eine Verbesserung der Kommunikation auf allen Ebenen zu wecken. In diesem Whitepaper gehe ich auf Prinzipien und Modelle der Kommunikation ein und transferiere diese an Beispielen in die Arbeitsumgebung agiler Teams. Download Whitepaper (Mis)Kommunikation

The post (Mis) Kommunikation appeared first on Scrum.de.

Kategorien: Rugby News

FedEx Days

6. Oktober 2014 - 16:47

Ein FedEx-Tag ist ein 24-Stunden-Ereignis, während dessen die Mitarbeiter Innovatives für ihr Unternehmen erbringen. Es wird FedEx-Tag genannt, weil man über Nacht etwas
Fertiges abgeben muss, genau wie der Paketdienstleister. Ein FedEx-Tag ist ein festgesetzter Zeitraum, während dessen die Leute nicht von der regulären Arbeit gestört werden dürfen. Innerhalb dieses Zeitraums haben die Mitarbeiter absolute Autonomie über das Projekt, das sie begeistert. Sie entscheiden für sich selbst, an was sie arbeiten, mit wem sie arbeiten und wie sie es tun werden. Es gilt nur eine Regel:

Jeder der hier mitmacht, zeigt am Ende des FedEx-Tages das Ergebnis der Firma.

Im Kern geht es bei einem FedEx-Tag also darum, Motivation und Kreativität anzuspornen, indem man über Nacht etwas zustande bringt.

Download Whitepaper FedEx Days

The post FedEx Days appeared first on Scrum.de.

Kategorien: Rugby News

RC Mainz: Fünf Punkte gegen Düsseldorf erkämpfen

24. September 2014 - 19:43
Vor dem fünften Spieltag der 2. Rugby-Bundesliga West steht der Rugby Club Mainz (RCM) mit nur zwei Punkten auf dem 5. Platz der Tabelle. Das ist trotz aller Widrigkeiten viel zu wenig für den Mainzer Trainer Alexis Vitrey: „Wir haben seit dem Saisonstart viele Chancen liegen lassen. Das wird sich nun ändern.“ Der Stimmungswandel in […]
Kategorien: Rugby News

Erste Niederlage für die SG SC Siemensstadt/RC Berlin Grizzlies

24. September 2014 - 19:32
Der Spitzenreiter kam und siegte: Im ersten Heimspiel der noch jungen Saison in der 1. Bundesliga Ost musste die Rugby-Spielgemeinschaft SC Siemensstadt/RC Berlin Grizzlies nach zwei Auswärtssiegen die erste Niederlage einstecken. Auf dem Platz im Willi-Sänger-Stadion in Köpenick gab es ein 8:33 (5:19) gegen den Berliner RC, der mit seinem vierten Sieg im vierten Spiel […]
Kategorien: Rugby News

DRV VII schließt zu den europäischen Top-Nationen auf

24. September 2014 - 19:27
Mit der besten Platzierung einer deutschen 7er-Nationalmannschaft in der Grand Prix Series (GPS) beschließt die DRV VII die diesjährige EM-Saison. In Bukarest sprang für die Mannschaft von Nationaltrainer Rainer Kumm der siebte Platz heraus. Damit belegt die DRV-Auswahl im EM-Gesamtklassement den zehnten Rang unter zwölf Nationen. Zwar verpasste die deutsche Mannschaft damit den angestrebten achten […]
Kategorien: Rugby News

Aus SCRUM.de wird Rugby-News.de

19. September 2014 - 17:59
Diesen Monat feiert SCRUM.de sein 15. Jubiläum! Als eine der ersten (wenn nicht die erste) Rugbyseiten in Deutschland für Ergebnisse und Nachrichten schaue ich ein wenig stolz auf die Vergangenheit zurück. Über 6.200 (!) Beiträge wurden veröffentlicht. Dazu haben ganz viele Mitglieder aus der Community beigetragen. Vielen Dank dafür! Einen besonderen Dank geht an Werner Cromm, der […]
Kategorien: Rugby News

DRV VII schaut im EM-Gesamtklassement nur nach oben

19. September 2014 - 17:24
Während im 15er-Rugby die Saison erst langsam beginnt, neigt sich der Kampf um Punkte für die DRV VII dem Ende entgegen. In Bukarest steht für die deutsche 7er-Nationalmannschaft am Wochenende (20./21. September) das letzte von vier Turnieren in der Grand Prix Series um den EM-Titel an. Für die DRV-Auswahl die letzte Chance, sich vom zehnten […]
Kategorien: Rugby News