Einleitung

Wiederholt haben wir in der jüngeren Vergangenheit in Projekten mitgewirkt, in denen unter Verwendung der SCRUM Methodik Software entwickelt wird. Doch was sich erst mal wie eine gute Idee anhört, entpuppt sich vielerorts als ein mehr oder weniger große Farce.

Aus nüchterner Perspektive betrachtet stellt SCRUM den Versuch dar, einige Probleme klassischer Softwareentwicklungmethoden zu lösen. Zum Beispiel wird das Schreiben umfangreicher Spezifikationen zu Gunsten kürzerer Entwicklungszyklen aufgegeben. Kürzere Entwicklungszyklen erzeugen eine besser Sichtbarkeit von Teilergebnissen. Nicht mehr das große Ganze in all seiner Komplexität steht bei SCRUM im Vordergrund, sondern die iterative Erbringung von Kundennutzen. Deshalb ist ein Kunden oder Zwischenkunde auch meistens Teil des SCRUM Teams.

Beschreibung der Methode

SCRUM-Entwicklungsteams haben typischerweise 7-10 Mitglieder von denen ein Teammitglied die Rolle des SCRUM Master und ein weiteres Mitglied die Rolle des Product Owner inne haben. Der SCRUM Master ist als “primus inter pares” zu verstehen. Er steht in keinem hierarchischen Weisungsverhältnis zum Rest des Teams, sondern hat eine Problemlöserfunktion innerhalb des Teams inne. Der Product Owner fungiert in der Role eines fiktiven (oder auch echten) Kunden. Daher wird die SCRUM Methode auch gerne dort genutzt, wo die Entwickler mit den End- oder Zwischenkunden zusammen Software entwickeln sollen und die Erbringung eines Kundennutzen im Vordergrund steht.

Die Entwicklungszyklen in SCRUM heißen Sprints. Sie sind typischerweise 3 Tage bis zu 4 Wochen lang und sind Iterationen an deren Ende eine stabile und funktionsfähige Version des zu entwickelnden Produkts steht. Idealerweise werden die Länge der Sprints und die Inhaber der Rollen zu Beginn eine Projekts festgelegt und während des Projekts nur bei vorliegen zwingender Gründe gewechselt. Ein solcher liegt jedoch NICHT vor, wenn die Sprintziele einmal oder widerholt nicht erreicht worden sind.

Weitere wichtige methodische Elemente von SCRUM sind eine Liste unbedingt umzusetzender Eigenschaften eine Produkts. Diese Liste nennt sich Work Backlog. Zu Beginn eines jeden Sprints gibt es das Sprint Planning. Dieses Meeting dient zunächst dazu die Tasks, die im nächsten Sprint umgesetzt werden sollen, vom Work Backlog auszuwählen und zu bewerten. Die Aufwandsbewertung erfolgt im ganzen SCRUM Team. Danach werden die Tasks vom Product Owner priorisiert. Anschließend werden alle Tasks, die in der insgesamt zur Verfügung stehenden Entwicklungsszeit entwickelt werden können auf die einzelnen Teammitglieder aufgeteilt.

Hierbei ist darauf zu achten, dass alle Teammitglieder eine etwa gleiche Auslastung während des Sprint haben. Jeden Tag findet ein kurzes Meeting im Team statt, an welchem der Product Owner jedoch nicht teilnimmt. Im Rahmen dieses Meetings hat jedes Teammitglied typischerweise 3 Fragen zu beantworten:

1. Was habe ich gestern getan ?
2. Was werde ich heute tun ?
3. Welche Probleme sind aufgetreten / Was hat mich behindert ?

Die Probleme sind im Anschluss an jedes “Daily Scrum” möglichst zeitnah vom SCRUM Master zu beseitigen bzw. abzustellen. Er ist daher gewissermaßen der Winston Wolf des SCRUM Teams und sorgt mit seiner Arbeit dafür, dass das Team möglichst reibungsarm arbeiten kann. Am Ende des Sprints findet das “Review Meeting” statt. In diesem Meeting nimmt der Product Owner wiederum teil und es werden die Arbeitsergebnisse des letzten Sprints besprochen. Typischerweise findet deshalb auch nach dem Review Meeting das “Sprint Planning” für den nächsten Iterationszyklus statt.

Eine der wichtigsten Regeln des Sprint ist, dass as Sprintziel nur dann erreicht ist, wenn ALLE geplanten Arbeitspakete im Rahmen des Sprint abgearbeitet wurden.
Einen Teilerfolg gibt es also bei Anwendung der SCRUM Methode nicht. Dies impliziert, dass ebenfalls bereits zu Projektbeginn eine sehr klare Definition für die Frage, wann etwas wirklich erledigt ist, erfolgen muss. Ken Schwaber, einer der Erfinder von SCRUM nennt dies “The definition of done”. Wer unter den geneigten Lesern dieses Blogs sicht nicht vorstellen kann, dass das Wort “erledigt” verschiedentlich interpretierbar ist, dem seien die drei Youtube Videos vom Ken Schwaber selbst persönlich ans Herz gelegt.

Kritische Diskussion

SCRUM ist eine sehr durchdachte Methode. Mich persönlich fasziniert immer wieder, wie häufig es amerikanischen Wissenschaftlern und Pratikern gelingt, komplexe Sachverhalte in überschaubare Methoden herunterzubrechen. Neben der SCRUM Methode ist zum Beispiel die Portfolioanalyse ein sehr effektive Methode, um komplizierte, multidimensionale Sachverhalte in einfache, nachvollziehbare Visualisierungen zu transformieren. SCRUM führt jedoch nicht ohne Einsatz zu guten oder besseren Ergebnissen als die klassischen Entwicklungsmethoden wie z.B. Wasserfall oder das V-Modell.

Eine akribische Beachtung der methodischen Grundsätze (Daily Scrum, Scrum Review Meeting), Einhaltung der Rollenzuordnungen (SCRUM Master, Product Owner) und eine klare a-priori Festlegung der “definition of done” sind wesentliche Grundsätze der Methode, die gelebt und verstanden werden müssen. Zwar setzt SCRUM Agilität durch kleine, überschaubare Teams, kürzere Entwicklungszyklen und Kundenpartizipation methodisch um, ob am Ende aber eine gutes und für das Team und den Kunden zufriedenstellendes Ergebnis steht, hängt wesentlich von der Einhaltung des Methodenfundaments ab. Jede Abweichung von der radikalen Vereinfachung des Entwicklungsprozesses nach SCRUM birgt die Gefahr am Ende mit schlechteren und vor allem teureren Ergebnissen konfrontiert zu werden, als sie klassische Methoden hervorgebracht hätten.

Auch wenn SCRUM das Lernen und Problemlösen im Team und damit das Gruppenziel in den Vordergrund stellt, ist es absolut notwendig ein SCRUM Team so zu besetzen, dass die Chance des Niveausausgleichs grudsätzlich gegeben ist bzw. das notwendige Spezialkenntnisse durch entsprechende Kompetenzträger abgedeckt werden. Teammitglieder die nachhaltig die Schätzwerte hinsichtlich des Zeitaufwandes für die Ihnen zugeteilten Aufgaben überreizen sind langfristig demotivierend und eine Belastung für den Rest des Teams sowie eine Gefahr für den Projekterfolg. SCRUM nur als Modewort zu verstehen und zu einer leeren Hülle verkommen zu lassen, weil die grundlegenden Regeln keine Beachtung mehr finden, ist jedenfalls keine gute Idee.

Über Frederik Kramer

Technischer Geschäftführer der initOS GmbH & Co. KG und Doktorand am Magdeburg Research and Competence Cluster (MRCC) der Otto-von-Guericke-Universität Magdeburg ist Ihr Experte im Bereich der Strategischer Nutzung von Open Source Software im Unternehmen.

• 
• 
• 

Frage des Tages:

“Wie kann man in einem TYPO3 Fluid Template die Inhalte sauber darstellen, die folgende Anforderungen erfüllen ?”.

Im Extbase basierten Backend soll es Multiple Checkboxen geben, die auf ein Integer gemapped werden. In unserem Fall sind dies z.B. Organisationseinheiten.

In der TCA von TYPO3 lässt sich das mit ‘type’ = ‘check’ umsetzen, doch wie ließt man selbiges wieder aus, wenn die Anwendungslogik von TYPO3 meint, es in einer Binärdarstellung in der Datenbank halten zu müssen ?

Nach einem Tipp für die richtige PHP-Funktion, haben wir einen kleinen ViewHelper gebaut. Den Code wollen wir euch nicht vorenthalten.

Vielleicht kann ihn der eine oder andere in seinen Projekten auch gebrauchen.

class Tx_Initos_ViewHelpers_CheckViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
        /**
         * ViewHelper to get state of check
         * @param int $int
         * @param int $pos
         */
  public function render($int = 0, $pos = 0) {
    $s = decbin($int);
    if(strlen($s) > ($pos+1))
      return false;
    return substr($s, -($pos+1), 1);
  }
}

Im Fluid Template kann man dies dann mit der folgenden Inline-Syntax abfragen:

{namespace initos = Tx_Initos_ViewHelpers}
<f:if condition="{initos:check(int: '{person.position}', pos: '{type}')}">
<f:then>
	Checkbox 1 gesetzt
</f:then>
</f:if>

Die ViewHelper in Fluid sind das Schweizer Taschenmesser, um erfolgreich und effizient das passende Template für die Extbase Extention von TYPO3 zu bauen.

Wir werden deshalb gerne unser Wissen teilen und stehen für Fragen natürlich wie immer gerne zur Verfügung.

Über Markus Schneider

Markus Schneider ist Experte für Shop- und ERP-Systeme. Er betreut mehrere eCommerce Kunden welche Magento oder Oxid eSales einsetzten. Dabei integriert er nicht nur CMS Systeme wie Joomla, TYPO3 oder WordPress in ihren Shop, sondern beschäftigt sich auch mit dem Einsatz von Warenwirtschaft und deren Prozesse, dabei greift er auf gesammelte Erfahrung von unterschiedlichen System von OpenERP, über Sage bis hin zu SAP zurück.

• 
• 
• 
• 

Wenn man mal bei Magento schnell in der Datenbank nachschauen will, dann ist das sehr umständlich durch die EAV Datenbankstruktur. Ab und zu tauchen ein paar fertige SQL-Querys auf, die aber nicht auf jeden Shop passen. Da es ziemlich aufwändig ist, sich immer per Hand die entsprechenden Statements zusammenzubauen, haben wir ein kleines Tool geschrieben, mit dem man sich die SQL-Querys bauen lassen kann. Dafür braucht man nur PHP + Verbindung zur Datenbank.

Dieses Tool findet ihr auf GitHub:

https://github.com/OSguard/Magento-Query-Builder

Das Beispiel:

https://github.com/OSguard/Magento-Query-Builder/blob/master/example_export_all_products.php

erklärt im Wesentlichen, wie man das Script benutzen kann. Man erzeugt sich ein Objekt, auf das man zugreifen will und lädt die Attribute:

$builder = new QueryBuilder('catalog/product', array(0,1));
$builder->loadAllAttributes();

Danach wählt man aus, welche Attribute man ausgeben will:

$attr = array(
    "entity_id",
    "sku",
    "name",
    "price",
    "url_path",
    "url_key",
    "attribute_set",
    "status",
    "created_at",
    "updated_at"
    );
 
 
$builder->selectAttributes( $attr );

Man kann z.B. noch die Bedienung einschränken, damit eine WHERE-Klausel gebaut wird:

$builder->setCond( 'type_id', '=', '"simple"');

Dann kann man sich das Query ausgeben lassen:

$builder->getQuery();

In unserem Beispiel wird dann folgender SQL-Befehl erzeugt:

SELECT a.entity_id AS entity_id,
 a.sku AS sku,
 t0.VALUE AS name ,
 t1.VALUE AS price ,
 t2.VALUE AS url_path ,
 t3.VALUE AS url_key ,
 b.attribute_set_name AS attribute_set,
 t4.VALUE AS STATUS ,
 a.created_at AS created_at,
 a.updated_at AS updated_at
	FROM
	(
	SELECT
		entity.*
	FROM 
		catalog_product_entity entity 
        WHERE 
                entity.type_id = "simple"   ) a
		    LEFT JOIN
			eav_attribute_set b
		    ON
			b.attribute_set_id=a.attribute_set_id
		    LEFT JOIN 
                        catalog_product_entity_varchar t0
                        ON 
                        t0.attribute_id= 96 AND
                        t0.entity_id=a.entity_id AND
                        t0.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_decimal t1
                        ON 
                        t1.attribute_id= 99 AND
                        t1.entity_id=a.entity_id AND
                        t1.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_varchar t2
                        ON 
                        t2.attribute_id= 570 AND
                        t2.entity_id=a.entity_id AND
                        t2.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_varchar t3
                        ON 
                        t3.attribute_id= 481 AND
                        t3.entity_id=a.entity_id AND
                        t3.store_id = 0 
LEFT JOIN 
                        catalog_product_entity_int t4
                        ON 
                        t4.attribute_id= 273 AND
                        t4.entity_id=a.entity_id AND
                        t4.store_id = 0

Das ist keine fertige Bibliothek, die man in ein Modul einbauen kann. Aber mann kann damit z.B. Export-Scripte bauen, die auch sehr viele Produkte in Sekunden exportieren, da hier der Magento-Weg sehr langsam ist. Oder es erleichtert das Arbeiten auf der Datenbank-Konsole. Zur Zeit ist das noch eine Rohfassung, vielleicht findet sich ja der ein oder andere, der bei der Entwicklung hilft. Der Code steht unter BSD-Lizenz.

Über Markus Schneider

Markus Schneider ist Experte für Shop- und ERP-Systeme. Er betreut mehrere eCommerce Kunden welche Magento oder Oxid eSales einsetzten. Dabei integriert er nicht nur CMS Systeme wie Joomla, TYPO3 oder WordPress in ihren Shop, sondern beschäftigt sich auch mit dem Einsatz von Warenwirtschaft und deren Prozesse, dabei greift er auf gesammelte Erfahrung von unterschiedlichen System von OpenERP, über Sage bis hin zu SAP zurück.

• 
• 
• 
•