Oktober 2011 27. Jahrgang CV Computern-Verlags GmbH Postfach 150605 München h t t p : / / w w w. h a e 10 2011 B 31417 ISSN 0931-4679 f a c h m a g a z i n f ü r d a s b a u h a u p t - u n d b a u n e b e n g e w e r b e handwerke.de Neue LIFEBOOK-Modelle und vieles mehr...... Fujitsu Forum 9./10. November in München www.fujitsu.de i n t e r n e t z Schnelle Netze, Teil 19: News z Online-Shops im Handwerk: Teil 13 s pecial z Agiles Projektmanagement: mit SCRUM h a r dwa r e z Praxistests: Vom Projektor bis zum Drucker t echniken & handwerk z Praxistest: Laser-Entfernungsmesser z Serie: Fahrzeugeinrichtungen, Teil 2 s o f t wa r e z Schreinerei: Jede Menge Holz sparen MARKTSPIEGEL: Thermografie- Kameras
Konzeptionell individuell gestaltete Homepage mit kleinem angeschlossenen Online-Shop. Die weiße Malerfarbe als Hintergrund auf jeder Seite macht sich gut. www.elektroschneider-freiburg.de Unsere Firma wurde von Hermann Schneider am 01.09.1968 gegründet... Seit dieser Zeit sind in unserer Firma 17 Lehrlinge (später Auszubildende) zu Elektroinstallateuren ausgebildet worden... Momentan sind wir 2 Elektromeister, 1 Obermonteur mit technischem Fachwirt, ein Monteur und ein Auszubildender. Rubrik Service: Service wird bei uns Groß geschrieben. Wenn irgend möglich, sind wir in der Lage, fast jeden Auftrag im Bereich Sanierung und Erweiterung Ihrer Wohnungsinstallation im Rahmen von drei Werktagen zu beginnen. Im Ernstfall sind wir auch in der Lage, sofort zu reagieren, wenn der elektrische Notstand ausbricht. Da aber auch wir irgendwann eine Pause einlegen müssen, sind wir wie andere Innungsbetriebe der Notdienstgruppe beigetreten. Das heißt 2-3mal im Jahr sind wir für eine Woche nicht nur für unsere Kunden 24Std. in Bereitschaft. In den restlichen Zeiten, wenn Sie uns nicht erreichen, hilft dann auch unseren Kunden der Notdienst der Elektroinnung Freiburg. Zum Online-Shop: Hinweis für alle Neukunden wir sind ein kleiner, familiär geführter Handwerksbetrieb und legen größten Wert auf zufriedene Kundschaft. Wenn Sie mit einem Arikel aus unserem Sortiment Probleme haben sollten, oder mit unserem Service nicht zufrieden waren, teilen Sie mir das bitte umgehend mit. Ich werden sicher für jedes Problem eine Lösung finden. Es gibt in der heutigen Zeit nichts schlimmeres als schlechte Bewertungen auf Suchmaschinen oder Bewertungsportalen. Vielen Dank! Als Kleinstbetrieb haben wir die meisten Artikel natürlich nicht auf Lager, werden aber bis zu 2mal täglich von unseren Großhändlern angefahren. Wenn Sie jetzt einen Artikel auswählen, der als Auslaufartikel bekannt ist, hat eine Bestellung gar keinen Wert, da wir ihn dann auch nicht mehr erhalten. Der Shop ist in fünf Rubriken unterteilt: n Aktions-Sortiment n Licht-Lampen-Leuchten n Installations-Baumaterial n Heizung-Lüftung-Klima n Leitun gen und Kabel Rubrik Liefer- und Versandkosten ( A u s z u g ) : I n n e r h a l b Deutschlands l i e f e r n w i r Waren, die in ein Paket von 120x60x60cm verpackt werden können, deren Gewicht unter 10kg wiegt und deren Bestellwert über 55,00 EUR beträgt, versandkostenfrei... Solider Shop mit umfangreichem Sortiment von Antenne bis Ventilator. Z ur Butte Montmartre in Paris gehört seit dem 19. Jh. das Kabarett Le Lapin Agile. Das Schild des renommierten Hauses zeigt ein Bild von André Gill: Ein mützetragendes Kaninchen, mit der rechten Pfote eine Flasche Wein servierend, entflieht flink der ihm zugedachten Pfanne eine gelungene, weil sofort vorstellbare Beschreibung des Begriffes agil Handwerke.de Heute ist die Eigenschaft der Agilität längst zur erstrebenswerten Herausforderung geworden, weil damit Erfolgspotentiale verbunden sind, die für die Schnelllebigkeit der Gesellschaft und des Marktes relevant sind. Unternehmen müssen agil sein, wenn sie im globalen Zeitalter fähig sein wollen, der Dynamik der Märkte zu entsprechen. Business Intelligence wird dank mobiler Technologien agil und ist damit in der Lage, analytische Informationen in Echtzeit zu liefern und über in der Zukunft zu erwartende Entwicklungen Auskunft zu geben. Agiles Management für IT-Projekte muß dazu beitragen, die verhängnisvolle Lücke zwischen realen Geschäftsprozeßen und ihrer nachhinkenden Widerspiegelung in den IT-Applikationen möglichst schnell zu überwinden. Verschärfte Konkurrenz, Einbindung als Zulieferer in Justin-Time-Ketten, Sicherung der Kundenloyalität in einem globalen Umfeld und steigender Zeitdruck für laufende und vorgesehene IT-Projekte sind nur Agiles Projektmanagement mit SCRUM Prof. Dr. Klaus Kruczynski, Hochschule für Technik, Wirtschaft und Kultur Leipzig * einige der Herausforderungen, denen das IT-Projektmanagement Rechnung tragen muß. Die eingeübten Methoden und Techniken des klassischen Vorgehens reichen nicht mehr aus, den modernen Anforderungen gerecht zu werden. Mit Hilfe des agilen Projektmanagements, das seit zehn Jahren immer breitere Anwendungsfelder erschließt, öffnen sich neue Wege. Dabei verdient Scrum eine besondere Beachtung, weil trotz der steigenden Komplexität der Projektinhalte mit erheblichen Zeit- und Kosteneinsparungen 11
i 12 H a ni S n d p t w e ec r ri n ak e le t Agiles Projektmanagement mit SCRUM im Projektierungsprozess gerechnet werden kann. Im Folgenden soll, ausgehend vom klassischen Projektmanagement, aufgezeigt werden, wie Scrum funktioniert, welche Chancen sich daraus ergeben und welche Einsatzfelder geeignet erscheinen. Klassisches 1. Projektmanagement Nach DIN 69901 umfaßt das Projektmanagement die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluß von Projekten. Wird das Projektmanagement auf den IT-Bereich bezogen, versteht man darunter nach Wieczorrek/ Mertens die spezielle Führungskonzeption für die Abwicklung von IT-Projekten. Im Kern ist nahezu jedes IT-Projekt Gegenstand der System- bzw. Softwareentwicklung, zu deren Aufgaben es gehört, den Lebenszyklus eines Software-Produkts zu beschreiben und zu optimieren. Seit den 1970er Jahren hat sich eine Vielzahl von Ansätzen für das Management von IT-Projekten herausgebildet, die in einem Klassifikationsschema systematisiert werden. Da die Entwicklung der Ansätze im Jahre 1970 mit dem Wasserfallmodell eingeleitet wurde und alle weiteren Modelltypen von dieser Basis mehr oder weniger ausgehen, soll an dieser Stelle eine kurze Erläuterung erfolgen, die in einem Bild dokumentiert ist. Das Wasserfallmodell ist ein eindimensionales Phasenkonzept des Software-Lebenszyklus in Top-down- Anordnung; es läßt keine Rücksprünge zu. Die nächste Phase kann erst dann begonnen werden, wenn die vorherige abgeschlossen ist. Jede Phase wird in Aktivitäten zerlegt und dokumentiert. Die im Bild des sprudelnden Wasserfalls in weißer Farbe angegebenen Phasen wurden aus einschlägigen Lehrbüchern der Wirtschaftsinformatik kombiniert [Sommerville; Lehner/Wildner/Scholz; Alpar/ Grob/Weimann/Winter]. Wichtig ist, daß bereits in dieser frühen Epoche der Systementwicklung der Bezug auf Fachkonzept und DV-Konzept gegeben ist, der für die Methoden des Software Engineering, die heute noch einer ständigen Verfeinerung unterliegen, unerläßlich ist. Bei einer Wertung des Wasserfallmodells sind Vor- und Nachteile gleichermaßen zu bedenken. Als Vorzug erweist sich die klare Abgrenzung der Phasen, die als Meilensteine interpretiert werden können. Damit wird es möglich, Kontrollen problemlos durchzuführen und jeweils eine präzise Dokumentation anzufertigen, die zum Beispiel in Projekten öffentlicher Auftraggeber vorgeschrieben ist. Von Nachteil ist die Tatsache, daß starre Phasen der Projektierungspraxis zumeist widersprechen. Ebenso ist es nicht haltbar, auf Rückkopplungen zu verzichten. Diese Einschränkungen führen häufig dazu, daß Fehler im Projekt viel zu spät erkannt werden. Der erneut notwendige Phasendurchlauf führt zu beträchtlichen Erhöhungen von Projektierungskosten und -zeiten. Die geschilderten Nachteile konnten durch die Erweiterungen und Verbesserungen des Wasserfallmodells in Gestalt von Spiral- und V-Modell nur partiell beseitigt werden. Darauf verweisen zum Beispiel die Untersuchungen von Hagen, die er in seinem Blog [pm-blog.com] diskutiert. Danach scheitern über 70% der Projekte aufgrund unzureichender Kommunikation sowie über 50% wegen unvollständiger Anforderungen sowie unflexiblen Arbeitsweisen und fehlendem User-Input. Weitere Ursachen für erfolglose Projekte liegen vor allem in einer unrealistischen Projektvorbereitung und -planung, verbunden mit einer ungenauen Zielsetzung, die einen zu großen Spielraum für die Interpretation des Projektes und seiner Ergebnisse zuläßt. Aber auch in Kompetenzstreitigkeiten, unklaren Rollenverteilungen und unterschiedlichen Interessen des Managements können Gründe für unproduktive, fehlerhafte Projekte liegen. Agiles Projektmanagement greift diese Problemfelder auf und bietet in Bezug auf die Einbindung der Nutzer, Planung und Kompetenzverteilung eine Reihe von Optimierungspotentialen an, die sich sowohl auf der Seite des Projektteams, als auch auf der Kundenseite niederschlagen. 2. Agiles Projektmanagement Agile Methoden vereinen in sich eine alte Weisheit: Die einzige Konstante im Leben ist die Veränderung. Agil zu sein, bedeutet nach Pichler, flexibel und kundennah zu arbeiten sowie die Anforderungen der Neuheiten und Innovationen zu bewältigen, um komplexen Situationen gerecht zu werden. Cockburn sieht in Agilität eine auf das Team und auf die Kommunikation konzentrierte Methode, die leicht anwendbar und erfolgreich ist. Eine treffende Beschreibung für den Begriff der Agilität im Business-Umfeld stammt von Goldman (1997): Agilität ist dynamisch und kontextspezifisch, bringt inhärent starken Wandel mit sich und ist wachstumsorientiert. Agilität beschreibt weder, wie die Effizienz verbessert noch
Kosten gesenkt werden, geschweige denn, wie man sich abschottet, um Konkurrenzstürme zu überstehen. Agilität beschreibt den Erfolg und den Gewinn: den Erfolg bei aufkommender Konkurrenz und den Gewinn in Bezug auf Profit, Marktanteil und Kunden im Zentrum der Konkurrenzstürme, vor denen sich viele Unternehmen heute fürchten. Aus dem Klassifikationsschema sind agile Ansätze für das Projektmanagement sichtbar: z Extreme Programming (XP) Beck et al. 2000, z Rapid Application Development (RAD) Boehm et al. seit den 1980er Jahren, z SCRUM Schwaber et al. 1991. Das Ziel von XP besteht darin, kleinere Teams durch effiziente Arbeitstechniken bei der Softwareentwicklung zu unterstützen. Beck und weitere XP-Vertreter plädieren u. a. für die unmittelbare Einbeziehung des Kunden in den Projektierungsprozeß, für die Synchronisation der Arbeitszeiten, für permanente Tests und die sukzessive Integration von Entwicklungsergebnissen in das Gesamtsystem. RAD setzt beim Spiralmodell der klassischen Software- Entwicklung an, indem es das zyklische Prototyping bewußt für den Entwicklungsprozeß verwendet. Auf diesem Wege werden Anforderungen des Auftraggebers frühzeitig in ausführbaren Code umgesetzt und anschließend diskutiert, um die häufig beobachteten Mißverständnisse im Projektierungsprozeß zu vermeiden. Damit ist es möglich, die Entwicklung komplexer Anwendungssysteme zu beschleunigen. Scrum soll im nächsten Abschnitt vorgestellt werden. Ein Zusammentreffen von Experten der agilen Softwareentwicklung in Utah im Jahre 2001 gipfelte in der Formulierung des Agilen Manifests in vier markanten Thesen [vgl. dazu http://agilemanifesto.org]: 1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. 2. Funktionierende Software ist wichtiger als umfangreiche Dokumentation. 3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. 4. Reaktion auf Veränderungen ist wichtiger als das Festhalten an einem Plan. Wie werden diese programmatischen Leitsätze in Scrum verwirklicht? 3. Einführung in SCRUM Das Wort Scrum (deutsch: Gedränge ) kommt aus dem Rugbyspiel: Beim Scrum kämpfen je 8 Spieler von zwei Mannschaften darum, durch Wegschieben des Gegners Spielvorteile zu gewinnen. Wird diese Situation auf das Projektmanagement übertragen, bedeutet Scrum, daß ein Team im Interesse des zu erringenden Erfolgs um Zusammenhalt ringt, wobei nur wenige Regeln zu beachten sind. Scrum als Vorgehensmodell des agilen Projektmanagements wurde 1991 von Schwaber, Sutherland und Beedle eingeführt. Die Quellen von Scrum sind einerseits die Theorie der selbstorganisierenden Systeme, die Stafford Beer in den späten 1950er Jahren in seiner Managementkybernetik zur Entfaltung brachte, andererseits die Arbeiten von Nonaka/ Takeuchi zur Produktentwicklung. Der Scrum-Prozeß, der analog zur Erläuterung des Wasserfall-Modells in einem Bild [in Anlehnung an Schwaber] im Überblick dargestellt wird, setzt die kluge Besetzung von drei wesentlichen Rollen voraus, die nicht wie beim klassischen Projektmanagement an einzelne Personen (zum Beispiel Rolle Product Owner Team Scrum Master Funktion Projektleiter) gebunden ist. Die Tabelle vermittelt die von den Rollen auszuführenden Funktionen. Das zentrale Element im Scrum-Prozeß ist der Sprint, dessen Dauer in den Scrum-Empfehlungen mit bis zu 30 Tagen angesetzt wird. Voraussetzung für die Durchführung eines Sprints ist ein Sprint Backlog, der die vom Team umzusetzenden Aufgaben enthält. Das Team entscheidet selbst über die Aufgabenlösung. Wenn der Auftraggeber mit dem Sprintergebnis noch unzufrieden ist, erfolgt ein weiterer H a n I S nd p tw e e cr r in ak e le t Durchlauf. Das Sprintergebnis c o m p u tist e rimmer n eine lauffähige Software, die getestet ist und gegenüber der Ausgangssituation I n t e r n e tver- bessert wurde. Sie hat die Eigenschaft eines Inkrements, beinhaltet also eine positive Änderung, einen Fortschritt gegenüber der letzten Beginnsituation. H a e Der Scrum-Prozeß beginnt mit einem Meeting, in dem der Product Owner alle im Product Backlog enthaltenen Items erläutert. Zusammen mit dem Team erfolgt die Priorisierung der Teilaufgaben und die Festlegung des übergreifenden Sprint-Ziels. In einem Folge-Meeting werden die Arbeitsaufgaben an die Teammitglieder verteilt und daraus der Sprint Backlog abgeleitet. Jeden Tag finden Daily Scrum Meetings statt, die ca. 15 Minuten dauern. In diesen Meetings wird abgestimmt, wer welche Aufgaben übernehmen wird; der Product Backlog ist daraufhin zu aktualisieren. Am Ende des Sprints werden die erzielten Ergebnisse in einem Sprint Review präsentiert, in dem auch Fehler und Schwachstellen diskutiert werden. In jedem Falle muß das Team ein Der Product Owner ist verantwortlich für die Planung und Durchführung der Produktentwicklung. Er erfaßt die Anforderungen des Kunden an das Projekt und beschreibt sie in Form eines Product Backlog, der sich aus Teilaufgaben (Tasks/Items) zusammensetzt. Ein Backlog kennzeichnet einen zu bewältigenden Arbeitsauftrag. Es ist die Hauptaufgabe des Product Owner, diesen Product Backlog in Zusammenarbeit mit dem Team kontinuierlich zu optimieren. In großen Projekten kann der Product Owner mehrere Teams betreuen. Ein Scrum-Team besteht idealerweise aus 7 bis 9 Mitgliedern. Es kann selbst entscheiden, wie viele Items des Backlog bis zum nächsten Prozeßabschnitt (Sprint) zu realisieren sind. Der Scrum Master ist der Prozeßverantwortliche. Er unterstützt das Team in allen Belangen der Arbeitsorganisation und sorgt dafür, daß das Team erfolgreich ist. Ihm obliegt es auch, den Product Owner zu unterstützen. Product Inkrement nachweisen. Welche Chancen bietet Scrum? Vor allem ist die unmittelbare Einbindung des Kunden in den Prozeß zu nennen. In der Regel hat ein Kunde frühzeitig klare Vorstellungen vom Ergebnis eines Projekts. In der Realität ist aber häufig die Änderung der Kundenwünsche während der Projektdurchführung zu beobachten. Um das Projekt in die gewünschte Richtung steuern zu können, muß man flexibel reagieren können. Im Falle des klassischen Projektmanagements müßte man zurück in die Anforderungsphase gehen, um eine neue Strategie zu 13
H a n S d p w e e c r i ka e l Agiles Projektmanagement mit SCRUM entwickeln. Dadurch entstehen Zeitverluste und zusätzliche Kosten. In einigen Fällen ist der Projektabbruch unumgänglich. Scrum dagegen bietet Flexibilität. Ein laufendes Projekt kann durch Änderung der Priorisierung ohne Unterbrechung und zusätzliche Kosten in die gewünschte Richtung gesteuert werden. Wirtschaftlichkeitsanalyse 4. für ein Scrum-Projekt Um einen Eindruck davon zu bekommen, mit welchen Chancen bei der Scrum- Projektierung gerechnet werden kann, wird im Folgenden am Beispiel der Angebotskalkulation für ein reales IT-Projekt, das ein IT-Dienstleister für einen Kunden erstellt hat, eine vergleichende Wirtschaftlichkeitsanalyse durchgeführt. Die folgende Tabelle widerspiegelt das Projektangebot bei klassischem Vorgehen. Die Erhebung in der Tabelle zeigt, daß das Angebot von Projektphase/ Meilenstein Projektinhalt 1 Update von Windows 2003 auf Windows 2008 R2 2 Grundinstallation Exchange 2010 48 3 Optional: Aufbau Exchange 2010 Edge Server 4 Anpassung BlackBerry Struktur 16 5 Projektkoordination 8 Scrum-Projekt transformiert auf Details der Transformation wird an dieser Stelle nicht eingegangen, ergibt sich ein Scrum- Projektstrukturplan nach dem im folgenden Screenshot dokumentierten Muster. Nach der Aufstellung des Scrum-Projektstrukturplans kann die Projektzeit für die Projektphasen, die als Meilensteine interpretiert werden können, berechnet werden. Am Ende wird sie mit insgesamt 98 Stunden ausgewiesen. Wird ein Bearbeiter mit einem 8-Stunden-Arbeitstag angenommen, kann das Projekt bei klassischem Projektmanagement nach 15 Tagen abgeschlossen werden, während Scrum das Projektende bereits nach 12,25 Tagen erreicht. Scrum ist somit um ca. 20 Prozent schneller. Eine kompakte Vergleichsaussage zwischen klassischem und agilem Projektmanagement in Gestalt von Scrum wird über ein sogenanntes Burndown-Diagramm vermittelt. Das Diagramm zeigt an, welche Zeit bis zum Projektende noch verbleibt. Es wird deutlich, daß Scrum mit fortschreitender Projektdauer immer effektiver wird und damit nicht in die Gefahr erhöhten Zeitdrucks kommt. Zeit (in h) Summe 120 34 16 Eine gewichtige Ursache für die Überlegenheit von Scrum gegenüber dem klassischen Projektvorgehen ist zum Beispiel die Einsparung umfangreicher Dokumentationsaufgaben. Die eingesparte Zeit kann für operative Tests verwendet werden, die am Ende / Umsatz * 100) aufgenommen. Bei gegebenen Kosten/Tag wird beim klassischen Projektansatz ein Wert von 25,89 erzielt; die Scrum-Bilanz für die Umsatzrentabilität erzielt den Wert 39,48. Mit Scrum würde der IT-Dienstleister in Bezug auf einen Euro Umsatz 39 Cent Gewinn erwirtschaften, das sind 13 Cent mehr als mit der klassischen Methode. Diese positive Entwicklung ist eine Konsequenz aus der Zeitersparnis, die den Personalaufwand und die Projektkosten vermindert. Durch die angebotsbasierte Wirtschaftlichkeitsanalyse konnte klar herausgestellt werden, daß der IT-Dienstleister bei Einsatz von Scrum durch Zeit- und Rentabilitätsvorteile profitiert. Aus Sicht des Kunden liegen die Vorteile neben der Zeit- und Kostenökonomie vor allem in der Transparenz der Projektrealisierung und der Einflußmöglichkeit während des Projektgeschehens. Auch wenn öffentliche Auftraggeber wegen einzuhaltender Dokumentationsvorschriften noch zögerlich mit agilen Projektvorschlägen umgehen, wird das agile Projektmanagement unaufhaltsam seinen Weg gehen. Dazu zwingen steigende Projektkomplexität und erhöhte Aufmerksamkeit gegenüber der Kundenloyalität. Ausdruck dieser Tendenz ist zum Beispiel, daß SAP im Frühjahr 2011 seine praxiserprobte Projekteinführungs- und Update-Methodik ASAP durch das Agile Business Add-On to ASAP für Scrum geöffnet hat. Ein Zwischenschritt in der Ausweitung agiler Projektmethoden auch auf den öffentlichen Sektor wird darin bestehen, Scrum in das V- Modell der aktuellen Ausbaustufe XT zu integrieren, was nicht nur zulässig, sondern empfehlenswert ist. einer Projektzeit in Höhe von 120 Stunden ausgeht. Wird der Projektinhalt unter Einbeziehung von OpenProject für die Datenerfassung und -auswertung in ein aufwendige Nachbearbeitungen vermeidet und schließlich zum Zeitvorteil führt. In die Wirtschaftlichkeitsanalyse wird auch die Berechnung der Umsatzrentabilität (Gewinn * unter Nutzung einer Hausarbeit aus dem Jahre 2011 von Lydia Koschig und Iglika Mateeva im Lehrgebiet Wirtschaftsinformatik an der Fakultät Wirtschaftswissenschaften der HTWK Leipzig 14