Die Mathematik von Microsoft
Ich werde mal versuchen, ein Thema, das mich seit einige Monate beschäftigt, kurz mit Hilfe von Bildern auf den Punkt zu bringen. Ich halte Hyper-V, die Virtualisierungslösung von Microsoft für eine unausgereifte Technologie.
Erstens erlaubt es Hyper-V als Einzige der prominenten Virtualisierungstechnologien (KVM, XEN, VMware) nicht, mehr Speicher an die Clients zuzuweisen, als dem Host insgesamt zur Verfügung steht (sogenanntes Memory Overcommitment). Zum anderen scheint selbst das Zuweisen real existierender Ressourcen lausig implementiert zu sein.
Grundauslastung des Hyper-V Hosts
Will man auf einem mit 24 GB ausgestatteten Windows 2008 Small Business Server (Dell T-710) mit einer Quad Core CPU einer virtuellen Maschine mehr als etwa 10 GB Arbeitsspeicher zuweisen (ein genauer Grenzwert bei dem der Fehler auftritt ist nicht feststellbar. In unseren Versuchen zwischen 8 und ca. 10,5 GB) bekommt man folgende Fehlermeldung.
Fehler beim Start des Hyper-V Clients
Man schaue sich den Fehlernamen in Verbindung mit der Begründung dazu an. Wir wissen nicht was exakt da schief gelaufen ist, aber wir würden Microsoft davon abraten wollen, sich an der Neudefinition mathematischer Grundrechenarten zu beteiligen. Unseren Kunden würden wir vorerst ans Herz legen keine Microsoft Produkte wie Excel oder dergleichen mehr zu verwenden, denn es kann nicht ausgeschlossen werden, dass die offensichtlich fehlerhafte Berechnungsfunktion auch dort zum Einsatz kommt ‘-)
Ü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.
Warum Scrum halt auch nur eine Methode ist?
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:
- Was habe ich gestern getan ?
- Was werde ich heute tun ?
- 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.
DLR veröffentlicht Open Source Library
Während die Welt über den Teich schaut wie die Nasa ein Portal veröffentlicht um ihre Open Source Aktivitäten zu bündeln und zu beschleunigen, stecken in Europa Bestrebungen, die öffentlich finanzierte Forschung und Softwareentwicklung als Open Source veröffentlichen noch in den Kinderschuhen.
Dabei ist klar an sich sonnenklar, Software, die wir durch unsere Steuergelder bezahlt haben, sollten wir auch nutzen können. Auch sollten wir nicht für das selbe Problem nochmal die Entwicklung bezahlen, nur weil die Software von einer anderen Behörde oder öffentlichen Einrichtung genutzt wird. Open Source Software ist unseres Erachtens nicht nur der beste, sondern sogar der einzige Lösungsweg.
Wo wir mit der NASA schon bei der Luft- und Raumfahrt waren, können wir zeigen, das sich dort langsam aber sicher auch etwas bei uns bewegt. Sicherlich ist das nicht das erste Open Source Projekt, aber der Mitarbeiter Roland Winkler vom Institut für Flugführung beim DLR Deutsches Zentrum für Luft- und Raumfahrt e.V. hat seine DataMining Java Library unter einer BSD Lizenz auf Github veröffentlicht.
Auch wenn das DLR selbst nicht zu unseren Kunden zählt, konnten wir im vorliegenden Fall Herrn Winkler -hoffentlich wertvolle- Tipps geben, wie man eine geeignete Open-Source-Lizenz auswählt und welche Rahmenbedingungen dabei zu beachten sind. Des weiteren konnten wir ihn über die Möglichkeiten und Risiken einer umfassenden Open-Source-Strategie beraten. Wir teilen gerne unser Wissen über Open-Source-Strategien. Wenn Sie also wissen wollen, wie Sie ihr Softwareprodukt mit einer Open-Source Strategie erfolgreich machen, melden Sie sich einfach bei uns.
Ü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.
