loading

IT-Blog

27
Feb
Blockchain, Smart Contracts und ihre anwendung

Blockchain und die Anwendungsbereiche

Generell lässt sich sagen: Wenn Transaktionen für einen Personenkreis sicher und nachvollziehbar abgelegt werden sollen, ist die Blockchain eine gute Wahl.

Hierzu zählen Fahrzeugbriefe genauso wie die interne Leistungsverrechung in Konzernen und der Garantieschein für ein gekauftes Elektrogerät.

blockchain_Fotolia_132389717_M

Blockchain, Smart Contracts und ihre Anwendung | © Akarat Phasura/Fotolia

Durch Smart Contracts sind die Anwendungsgebiete der Blockchain schier explodiert: Smart Contracs eignen sich überall dort, wo Eingangs- oder Ausgangsparameter eines Vertrags durch ein elektronisches Systems verarbeitet werden. Beispiele sind:

  • Ausstellen von Tickets (z. B. Nahverkehr, Flugtickets)
  • Auftragsmanagement mit Dienstleistern, die ihre Ergebnisse (Fotos, Texte, Source-Code, Übersetzungen, Gutachten, Mess-Ergebnisse, …) in digitaler Form liefern
  • Jede Art von Makler-Dienstleistungen (Wohnungsmarkt, Gebrauchtwagen, Job-Börsen, Taxi-Dienste, Programmatic Advertising, …)

Darüber hinaus werden Smart Contracs zunehmend Bedeutung im Bereich der IoT erreichen. Beispiele hierfür sind:

  • Mietwagen, die den Motor nur starten, wenn die Kreditkarte des Fahrers belastet werden kann
  • Hotelzimmertüren, die sich nur für den bezahlenden Gast öffnen, ohne Check-In, ohne Keycard
  • WLANs, die für sehr geringes Entgelt von Fremden mitgenutzt werden können
27
Feb
Die Blockchain-Technologie und Industriezweige

In welchen Industriezweigen wird Blockchain-Technologie bereits angewendet?

Der erste Anwendungsfall für die Blockchain-Technologie  war Bitcoin. Dieses Netzwerk hat mittlerweile eine Marktkapitalisierung von ca. 20.000.000.000 US$ und kann damit als stabil und langlebig bezeichnet werden. Tatsächlich ist es seit dem Start der Blockchain niemandem gelungen einen Block oder ein Bitcoin zu fälschen. In Regionen ohne stabile Währungen löst Bitcoin langsam den US$ als Leitwährung ab. Das liegt zum Teil auch daran, dass Bitcoin-Überweisungen weltweit für sehr geringe Gebühren und in Sekundenschnelle möglich sind.

blockchain_Fotolia_123598726_S

Die Blockchain-Technologie und Industriezweige | © zapp2photo/Fotolia

Die Möglichkeit, ohne Intermediäre, Geldsummen zu transferieren hat dann zu den ersten industriellen Anwendungen der Blockchain geführt: Banken wickeln heute bereits sogenannte Inter-Bank-Transfers, also das Verschieben großer Geldsummen über private Blockchain Netzwerke ab.

Im öffentlichen Bereich werden Blockchains heute insbesondere da verwendet, wo Sachverhalte über eine lange Zeit, öffentlich zugänglich und absolut fälschungssicher dokumentiert werden müssen. So haben beispielsweise Schweden und Honduras ihre Katasterämter auf Blockchain umgestellt. Damit konnte sicher gestellt werden, dass Land-Titel nicht nur für jeden Bürger einsehbar wurden, sondern auch jeder Besitzwechsel lückenlos und sicher nachvollzogen werden kann.

Weitere Anwendungen der Blockchain finden sich heute in der Kreditwirtschaft und in der Crowd-Funding Industrie. Auch ist zu beobachten, dass insbesondere in der Softwareindustrie, freie Mitarbeiter über Smart Contracts gebunden werden: Sie erhalten eine Aufgabe (Entwicklung einer bestimmten Funktionalität) und beweisen dem Smart Contract gegenüber, dass sie diese Aufgabe erfüllt haben. Der Vertrag selbst schüttet dann den vereinbarten Betrag an den Mitarbeiter aus, ohne dass eine Buchhaltung involviert wird. Dieses Einsparpotenzial bei der Buchhaltung wird derzeit ebenfalls von Unternehmen gesehen, die vornehmlich mit digitalen Gütern handeln. Beispiele hierfür sind Fotoagenturen und Content Netzwerke.

26
Okt
PMO und Project Office in der Organisation

Das Project Management Office – PMO – in IT Projekten

Das Project Management Office – PMO umfasst sowohl

  • die Definition von Methoden und Prozessen für ein durchgängiges einheitliches Projektvorgehen,
  • die einheitliche Steuerung und
  • das Reporting,
  • als auch die operative Unterstützung des Projektmanagements.

In größeren Unternehmen besteht das PMO aus einer eigenen Abteilung, die eine zentralisierte Rolle im Unternehmen hat. In kleineren Unternehmen besteht ein PMO häufig aus einer Einzelperson oder einem kleinen Team. Das PMO ist dann meist nur für einzelne Projekte zuständig und sorgt für die Entlastung der Projektleitung. In diesem Fall handelt es sich hier eher um Project Office (Projektbüro) als um PMO. Das Projekt Office besteht so lange wie das Projekt selbst, d. h., es besteht nicht auf Unternehmens-, sondern auf Projektebene.

PMO und Project Office in der Organisation

PMO in größeren Unternehmen als eigene Abteilung. In kleineren Unternehmen ist das PMO nur für einzelne Projekte zuständig und heisst Project Office (Projektbüro).

Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können PMO als allgemeiner Koordinator und PO als spezifische Einheit betrachtet werden.

Das Project Office (Projektbüro) arbeitet als operative Unterstützung des Projektleiters direkt in den Projekten und wird oftmals ad hoc, während das Projekt bereits läuft berufen. Pos sind für die Projektdokumentation, das Projektreporting, sowie für administrative Aufgaben innerhalb des Projektteams zuständig.

Das PMO arbeitet an Standards, Richtlinien, Prozessen und Methoden für den Einsatz in Projekten. Das PMO ist generell projektübergreifend tätig, kann aber bei Bedarf auch einzelne Projekte direkt unterstützen.

Der Einsatz des PMO verbessert die Zielerreichung einzelner Projekte, und optimiert gleichzeitig die Prozesse für einheitliches Projektportfoliomanagement.

Der Einsatz des Project Office führt zu einer Entlastung des Projektmanagers und des Projektteams, was wiederum zur Erhöhung der Effektivität in der Projektarbeit führt.

Beide Rollen bzw. Einheiten können gleichzeitig bestehen, es gibt doch Unterschiede bezüglich der Einsatzdauer und des Aufgabenbereichs. Grundsätzlich können das PMO als allgemeiner Koordinator und das PO als spezifische Einheit betrachtet werden. Beide können helfen, ein Projekt kontinuierlich am Laufen zu halten, und dadurch Nutzen stiften, dass Projekte schneller umgesetzt werden, geringere Kosten entstehen und durch Prozesssicherheit höhere Qualität erzielt wird.

Ist in einem Unternehmen ein PMO vorhanden, so wird dieses Vorgehensmodelle für Projekte erarbeiten. Solche Vorgehensmodelle beschreiben die beispielsweise die Art und Frequenz des Berichtswesens, die Projektdokumentation und eine einheitliche Projektstruktur. Die Projektleiter in solchen Unternehmen sind gehalten, diese Regeln anzuwenden, auch wenn projektbezogene Ausnahmen im Rahmen pragmatischer Arbeit immer erlaubt sein müssen.

Anders verhält es sich in Unternehmen ohne PMO: hier wird das Vorgehensmodell üblicherweise innerhalb des Projekts erarbeitet und festgelegt. Der Projektleiter ist damit letztlich für das Vorgehensmodell verantwortlich, während der PO es lediglich anwendet und bestenfalls optimiert.

Aufgaben des Project Office (Projektbüro) in IT Projekten

  • Erstellen von Standards und Templates für
    • die Projektdokumentation
    • das Reporting
  • Unterstützung des operativen Projektmanagements bei
    • der Planung,
    • dem Reporting und
    • dem Controlling.
  • Unterstützung des Projektteams bei administrativen Aufgaben: In einem Projekt fallen zahlreiche administrative Tätigkeiten – wie z. B. Dokumentation-, Berichts- und Bestellwesen – an. Ein PO kann diese Aufgaben vom Produktivteam fernhalten. So kann das PO des Teams von administrativen Aufgaben entlasten, was wiederum zur Erhöhung der Effektivität der Projektarbeit führt.

Aufgaben des Projekt Management Office – PMO

In IT Projekten hat das PMO, zusätzlich zu den eben beschriebenen Aktivitäten desProject Office (Projektbüro) folgende Aufgaben:

  • Definition einer unternehmensweiten Projektmanagement Kultur mit
    • geeigneten Tools und
    • Infrastruktur-Unterstützung, um das Wissen aus und in den Projekten transparent zur Verfügung zu stellen.
  • Sicherstellen des Einklangs der Projekte mit der Unternehmensstrategie: Das PMO sorgt dafür, dass die durchgeführten Projekte an der Unternehmensstrategie ausgerichtet sind. Diese Aufgabe beinhaltet unter anderem die Vorbereitung von Entscheidungsgrundlagen zur Projektauswahl und zur Priorisierung von Projekten.
  • Erstellen von projekteinheitlichen Regeln für
    • Projektmanagementmethoden,
    • Prozesse und Workflows für Projektkalkulation, Risiko- und Problemkontrolle, Anforderungskontrolle.
  • Unterstützung bei der Multi-Projektplanung mit
    • Koordination der unterschiedlichen Projekte und
    • Priorisierung.

Das Project Management Office – PMO nach PMI

Nach der Definition im Project Management Body of Knowledge (PMBOK Guide) des Project Management Institute (PMI), das PMO ist eine organisatorische Einheit, die das Management von Projekten, die zu seinem Bereich gehören, zentralisiert und koordiniert. Ein PMO wird auch als ‚Programm Management Office‘, ‚Projektoffice‘, oder ‚Programmoffice‘ bezeichnet.“

http://www.pmi.org/Learning/knowledge-shelf/project-management-offices.aspx

09
Okt
Risikomanagement in IT und Software Projekte

Risikomanagement in IT und Software-Projekten

Das Risikomanagement in IT und Software-Projekten ist der wichtigste Faktor für die Absicherung, die Schadenminimierung und schließlich für den erfolgreichen Abschluss der Projekte. Unter Risikomanagement werden alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung zusammengefasst.

Risikomanagement in IT und Software Projekte

Die wichtigsten Schritte in Risikomanagement

IT und Software Projekte erweisen in ihr Laufzeit eine Vielzahl von Risiken. Die Risikohöhe nimmt mit der Größe und Komplexität der geplanten Software und mit der Anzahl der Schnittstellen zu anderen Systemen überproportional zu. Deshalb ist es wichtig, dass alle Risikofaktoren in die Vorphase und in die Planung und Überwachung des Projekts mit einbezogen werden.

Zu den Risikofaktoren eines IT Projekts zählen sowohl Allgemeine als auch Spezielle Risikofaktoren.

Allgemeine Risikofaktoren, relevant für das Risikomanagement in IT und Software-Projekten

  • unzureichende Unterstützung durch die Geschäftsführung
  • Spannungen und Konflikte im Projektteam
  • Fehlende Motivation im Projektteam
  • Fehlende Benutzerakzeptanz
  • mangelhafte Informations- und Kommunikationsstrategie
  • unzureichende Fachkompetenz der Teammitglieder

Spezielle Risikofaktoren(fachliche und methodische Risiken)

  • fehlende und unklare Zielsetzung des Projekts
  • unrealistische Terminvorgaben
  • fehlende Planung, Termin- und Kostenüberwachung
  • mangelhafter Überblick des Projektstands und Fortschritts
  • Schnittstellenprobleme (Fehlende Dokumentation, Inkompatibilitätsprobleme)
  • unzureichende Tests und fehlende Qualitätskontrolle

Das Vorgehen beim Risikomanagement in IT und Software-Projekten besteht aus folgenden Schritten

  • Identifikation der Ursachen
  • Analyse
  • Risikobewertung
  • Priorisierung anhand der Auswirkungen und der Eintrittswahrscheinlichkeit
  • Einleitung von Maßnahmen
  • Konsequente Verfolgung der Risiken (Monitoring)

 

Risikobewertung

Die Risikobewertung dient der Priorisierung und anschließend der kontinuierlichen Überwachung. Sie ist die Grundvoraussetzung für eine gezielte Steuerung und Behebung oder Minimierung des Risikos durch Maßnahmen. Die Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit und Auswirkung bewertet und priorisiert.

Risikobewertung in IT und Software-Projekten

Priorisierung nach Risikobewertung in IT und Software-Projekten

1. Niedrige Priorität: Das Risiko ist definitiv nicht Projektgefährdend, muss doch überwacht werden.

2. Mittlere Priorität: Das Risiko ist wahrscheinlich nicht Projektgefährdend, muss doch intensiv überwacht werden.

3. Hohe Priorität: Das Risiko gefährdet das Projekt. Die Maßnahmen zur schrittweisen Behebung oder Reduzierung des Risikos, müssen geplant und Zeitnah eingeleitet werden.

4. Höchste Priorität: Sofortige Maßnahmen müssen in diesem Fall eingeleitet werden. Das Risiko kann große Projekt- oder sogar Unternehmensweite Schaden verursachen.

Voraussetzungen für erfolgreiches Risikomanagement in IT und Software Projekte

Kontinuität

Die Risiken müssen identifiziert und intensiv verfolgt werden. Potenzielle neue Risiken müssen immer wieder überprüft und erkannt werden.

Offene Kommunikationskultur

Im Unternehmen muss eine offene Kommunikationskultur gelebt werden, damit im Rahmen des Risikomanagements die Maßnahmen in unterschiedlichen Bereichen des Unternehmens ausweiten zu können. In diesem Zusammenhang jemand, der Risiken meldet, darf auf keinem Fall vor beruflichen Konsequenzen fürchten.

Vollständige Integration im Entwicklungsprozess

In der gesamten Laufzeit eines Projekts muss Risikomanagement fester Bestandteil der Prozesse sein.

28
Sep
Tester und Testmanager in Scrum

Tester und Testmanager in Scrum

Tester und Testmanager gibt es zwar als Rollen in Scrum Prozess nicht, allerdings ist Scrum nur ein Softwareentwicklung-Framework, das keine technischen Praktiken diktiert. Nun, da Scrum Teams übergreifende Teams sind, gehören Tester bzw. Testmanager dazu.  So wird beim agilen Prozess die Unabhängigkeit zwischen Entwicklungs- und Testmannschaft, die bei den klassischen Methoden die Regel ist, aufgegeben.
Tester und Testmanager sind hier Teile des Scrum Teams. Statt auf freigegebene Anforderungs- und Designdokumente zu warten, sind sie im agilen Team zu Kommunikation, Interaktion und aktiver Mitarbeit aufgerufen. Auch wenn sie keinen Code schreiben, müssen Tester bei der Automatisierung von Regressionstests und anderen Automatisierungstests sehr eng mit den Programmierern zusammenarbeiten.

Sobald ein Programmierer eine User Story implementiert, sollte der Tester bereits die Testfälle anhand der Akzeptanzkriterien vorbereitet haben, um mit den Tests der Story beginnen zu können.

Tester, Testmanager, Produckt Owner und Entwickler in Scrum

Abbildung der Testing Aufgaben im Scrum Prozess

Erst wenn alle User Stories implementiert und die Tests erfolgreich abgeschlossen sind, kann ein Sprint als erfolgreich abgeschlossen betrachtet werden. Hier ist natürlich die Continuous Integration Umgebung sehr wichtig, um die Änderungen der Entwicklung sofort dem Testing zur Verfügung zu stellen.

Aufgaben der Tester und Testmanager in einem Scrum Team

  • Analysieren der User Stories auf ihre Qualität und Vollständigkeit
  • Mitdefinieren der Akzeptanzkriterien
  • Prüfen der Akzeptanzkriterien auf Testbarkeit
  • Sicherstellen von Testdaten
  • Sicherstellen der Rückverfolgung zwischen User Story und Test
  • Beteiligung an der Sprint-Planung und den Daily Scrum Meetings
  • Funktionales Testen der User Stories
  • Usability Tests
  • Explorarives Testing
  • Mitarbeit mit den Programmierern bei der Implementierung von Unittests
  • Ausführung einer Kombination von Unitests und explorativen Tests. So werden schnell Fehler gefunden, die allen von Unitests nicht gefunden werden können.
  • Performance und Security Tests

Damit die Sprints erfolgreich getestet werden, ist der Betrieb einer Continuous Integration Umgebung, in der automatisierte Unit-, Integrations- und Systemtests die Implementierung der User Stories begleiten, notwendig.

Entwickler, Tester und Testmanager in Scrum

Abbildung von Testing mit Scrum

Die Implementierung von den Unit-, Integrations- und Systemtests übernehmen die Entwickler, Tester arbeiten mit. Um diese Tätigkeiten qualitativ auszuführen bedarf es  guter Kommunikation, analytischer Kenntnisse und methodisches Vorgehen.

Und selbstverständig … Agiles Testen, Tester und Testmanager folgen den Prinzipien des agilen Manifests und wenden die agilen Prinzipien auf das Testen an.

Siehe das Agile Manifest.

21
Sep
Kanban Board (Aktivitäten, Entwickeln, Testen, Relaese, Aufgaben,Bug, Feature)

Scrum oder Kanban

Beide Projektmanagement-Frameworks dienen dem agilen Softwareentwicklungsprozess und unterstützen die Philosophie, dass sich Prozesse und Tools den Individuen und deren Interaktionen unterordnen müssen.

Es sind beides Frameworks zur Ablaufplanung, die auf dem “Just-in-Time”-Prinzip aus der Lagerverwaltung des Leankonzepts basieren. Das Team als zentrale Instanz sagt, wann und wie viel Arbeit in einem bestimmten Zeitraum zu schaffen ist und verpflichtet sich auf die Fertigung. Die Teammitglieder “ziehen” Arbeit heran, wenn sie bereit sind, und bekommen sie nicht von außen „zugeschoben“, wie bei den klassischen Methoden.

Der kontinuierliche und erfahrungsgestützte Verbesserungsprozess, wie es das Kaizen-Prinzip aus dem Leankonzept vorgibt, ist ein wichtiger Bestandteil beider Frameworks.

Scrum oder Kanban?

Scrum hat seine Vorzüge dort, wo es darum geht, sehr flexibel und agil auf geänderte Anforderungen einzugehen.

Kanban stellt das Ziel in den Vordergrund, Probleme im Projekt transparent zu machen und zeitnah effizient zu lösen.

Ähnlichkeiten von Scrum und Kanban

  • beide Frameworks haben ihre Wurzeln in dem Leankonzept und sind agil
  • Beide haben als Basis das Pull-Prinzip (Hol-Prinzip): Die anfallende Arbeit verteilt nicht ein „Supervisor“, sondern die Teammitglieder holen sich ihre Arbeit, um den Produktionsfluss möglichst fließend zu halten
  • Im Brennpunkt stehen bei beiden Flexibilität und maximaler Kundennutzen: schnell und oft ausführbare Software liefern
  • Beide bemühen sich auf kontinuierliche Prozessverbesserung durch Transparenz
  • Die Teams sind selbstorganisierte Teams

Unterschiede

  • Bei Scrum gibt es 3 Rollen(Product-Owner/Scrum Master/Team), und Spielregeln(Dailyscrum, Sprints, Produktbacklog). Kanban Schreibt keine Rollen vor
  • Während es bei Scrum Iterationen mit festem Zeitschema, die sogenannten Sprints gibt, sind bei Kanban die Iterationen mit festem Zeitschema optional
  • Der Prozess ist bei Scrum zeitgetrieben, während es bei Kanban ereignisgetrieben ist
  • Das Team gibt bei Scrum, in der Sprintplanung, sein Commmitment für die Abarbeitung eines bestimmten Arbeitpakets innerlalb des Sprints, während bei Kanban keine bestimmte Arbeitspaketgröße vorgeschrieben ist und das Commitment optional ist
  • Das Schätzen des Aufwands ist bei Scrum vorgeschrieben, während bei Kanban das Schätzen optional ist
  • Bei Scrum gibt es ein priorisiertes Produktbacklog, bei Kanban ist die Priorisierung der Tasks optional
  • In Scrum gehört das Sprintbacklog einem bestimmten Team, ein Kanbanboard kann von mehreren Teams bearbeitet werden
  • Ein Scrumboard wird für jeden Sprint neu eingesetzt, ein Kanbanboard bleibt durchgehend bestehen

Ein Beispiel des KanbanBoards

kanbanboard

Das Kanbanboard besteht aus einem einfachen Whiteboard und Haftnotizen. Jeder Notiz auf dem Board repräsentiert eine Aufgabe und das Stadium der Abarbeitung.

 

Kanban entstammt dem Japanischen. Dort heißt かんばん (看板) so viel wie „Karte“, „Tafel“ oder „Beleg“. Alternative Namen für Kanban sind Hol-, Zuruf- oder Pull-Prinzip. Quelle: Wikipedia

14
Sep
Scrum Grafik (Scrum Master, Product Owner, Product Backlog, Sprint Backlog, Sprint, Daily Scrum)

Klassisches Projektmanagement und Scrum

Klassisches Projektmanagement basiert sich auf Wasserfall Methoden und die Rolle „Projektmanager“ trägt die Verantwortung für den Erfolg des Projekts. Der klassische Projektmanager ist derjenige, der ein Projekt inhaltlich und zeitlich plant und vorantreibt, das Projektbudget verwaltet, die Umsetzung leitet, mit den Stakeholdern kommuniziert und alle erfolgsrelevanten Rahmenbedienungen des Projekts berücksichtigt.

Rollen bei Scrum

Bei Scrum gibt es die Rolle „Projektmanager“ nicht mehr. Dafür gibt es die Rollen „Product Owner“ und „Scrum Master“. Die Aufgaben des klassischen Projektmanagers werden auf diese beiden Rollen verteilt.

Der „Product Owner“ ist für die Vision, die inhaltliche Beschreibung der Anforderungen, die Planung in enger Zusammenarbeit mit dem Team, die Steuerung der Umsetzung und das Budget verantwortlich.

Der „Scrum Master“ sorgt für optimale Arbeitsbedienungen, räumt Hindernisse und Störer aus dem Weg und unterstützt das Team bei fachlichen Problemen.

Klassisches Projektmanagement und Scrum

Die Rolle „Team“ ist bei Scrum sehr wichtig, da es für die Einhaltung der Planung und die Umsetzung, durch das Commitement verantwortlich ist.

Die Verantwortung für den Erfolg eines Projekts tragen bei Scrum alle drei Rollen zussammen.

Der klassische Projektmanager ist durch seine Kenntnisse fähig, beide Rollen zu erfüllen. Man sollte hier prüfen, welcher Teil der Rollen einem am besten liegt:

Treibt man ein Projekt gerne inhaltlich voran, hat kreative Ideen für neue Produkte und kann gut die Budgets verwalten, dann sollte man die „Product Owner“-Rolle wählen. Ist man hingegen eher der „Kümmerer“ und versteht die Technik gut, dann sollte man am besten die „Scrum Master“-Rolle einnehmen.

Es gibt jedoch größere Projekte, die zusätzlich zu den Rollen „Product Owner“ und „Scrum Master“ auf klassisches Projektmanagement angewiesen sind. Ein Projektmanager ist bei größeren Vorhaben eine Notwendigkeit, da es hier nicht nur um die Umsetzung eines Produkts, sondern mehrerer Produkte mit mehreren Schnittstellen geht.

Diese Person sollte dann die Gesamtplanung des Projekts verantworten, die Stakeholder steuern, die Schnittstellen zu anderen Produkten oder Projekten berücksichtigen, Maßnahmen zur Infrastruktur und den erfolgreichen Betriebsübergang treffen, um das Projekt erfolgreich abschließen zu können.

14
Sep
Das magische Dreieck des Projektmanagements - unterschiede zwischen Scrum und der klassischen Methode. Umfang - Kosten - Zeit

Scrum oder klassische Methoden für das Projektmanagement?

Scrum oder klassische Methoden für das Projektmanagement? In vielen Unternehmen wird über den Einsatz Agiler Methoden in IT-Projekten nachgedacht.

Klassische Methoden

Die klassischen Methoden der Softwareentwicklung basieren auf einer sequenziellen, schrittweisen Entwicklung, die in mehrere Phasen unterteilt ist. Die Phasen bauen in einer festgelegten Reihenfolge aufeinander auf.

Das bekannteste Modell ist hier das Wasserfallmodell.

Die typischen Phasen des Wasserfallmodells sind:

  • die Konzeption (Anforderungsanalyse und -spezifikation),
  • das Design (Systemdesign und -spezifikation),
  • die technische Umsetzung (Programmierung und Modultests),
  • die Integrationstests (Integrations- und Systemtest) und
  • der Roll-out und Support (Auslieferung, Einsatz und Wartung).

Die klassische Methoden verlangen die konsequente Durchführung der vorher geplanten Phasen. Dadurch können große und umfangreiche Projekte präzise und mit hoher Planungssicherheit durchgeführt werden.

Der größte Vorteil des Wasserfallmodells ist die hohe Planungssicherheit. Durch die geordnete Struktur können auch umfangreiche Projekte präzise geplant und zuverlässig durchgeführt werden. (Steht schon so im Absatz hier drüber)

Allerdings können Entscheidungen in einer abgeschlossenen Phase – ohne einen aufwändigen Change Request-Prozess – nicht mehr geändert werden. Das wiederum kann zu Gefährdung der Planung (des Projektes?) führen.

Der Fokus bei den klassischen Methoden liegt auf Strukturen, langfristige Planung und detaillierte Spezifikation.

Bezogen auf das Dreieck des Projektmanagements sind die Kosten und der Umfang des Projekts festgelegt, während die Dauer in Gefahr ist.

Das magische Dreieck des Projektmanagements - unterschiede zwischen Scrum und der klassischen Methode. Umfang - Kosten - Zeit

Projektmanagement klassisch oder nach Scrum

Agil

Bei den agilen Methoden liegt der Focus auf Werte und Prinzipien. Der Mensch und das Team haben hier eine sehr hohe Bedeutung. Es wird ein produktives Arbeitsumfeld mit Wert auf schnelle Veränderungen, Kommunikation und Eigenverantwortlichkeit gefordert/geschaffen?.

Das agile Manifest legt die wesentlichen Prioritäten fest:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein“

Bezogen wiederum auf das Dreieck des Projektmanagements sind bei Scrum die Kosten und die Dauer des Projekts festgelegt, während der Umfang flexibel und veränderbar ist.

Ziel der Entwicklung bei Scrum ist es, eine lauffähige und akzeptable Software zu entwickeln.

Dafür wird die komplexe und umfangreiche Entwicklung in kleine Teilprojekte zerteilt. Diese werden nacheinander in sog. Sprints, die in der Regel zwei bis vier Wochen dauern, umgesetzt. Das Ziel jedes Sprints ist die Auslieferung von funktionsfähiger und qualitativ hochwertiger Software.

Im Verlauf der Entwicklung können sich die Anforderungen und Randbedingungen ändern. Auf diese Änderungen muss das Team schnell reagieren können. Änderungswünsche werden während der Entwicklung aufgenommen und nach Priorität im nächsten Sprint realisiert.

Allerdings läuft man Gefahr – durch den schnellen Änderungsprozess – nur kurzfristige (und fehleranfällige?) Lösungen zu schaffen. Durch die Teilung in Sprints kann man den Überblick über das Ganze verlieren.

Fazit Scrum oder klassische Methoden:

Scrum ist bei Entwicklungsprojekten mit hohem Termindruck geeignet, bei dem die Anforderungen an das zu entwickelnde Produkt zu Beginn des Projekts noch unklar sind.

Scrum erfordert jedoch häufig einen Wandel des existierenden Verständnisses von Führung und Verantwortungsbereichen, um die für agile Projekte maßgeblichen Freiräume für Selbstorganisation, Selbstverantwortung und Entscheidungskompetenz der operativen Teams zu schaffen.

Die Auswahl der Methodik sollte sich immer zwingend an der Unternehmenskultur und an der aktuellen Situation orientieren. Sowohl Scrum als auch klassische Methoden haben ihre Vor- und Nachteile. Jedoch beide Verfahren fordern die richtigen Rahmenbedinungen, um ein Projekt zum Erfolg zu bringen.

Zu diesen Rahmenbedienungen zählen neben der Bereitstellung der notwendigen Ressourcen, sowohl die Wertschätzung des Teams, als auch die richtige Planung, Motivation und Kommunikationsstrategie.

Sogenannte hybride Ansätze kombinieren klassische und agile Methoden miteinander. Je nach Projektphase oder Vorgang kann auch nach dem Werkzeugkastenprinzip der jeweils geeignete Ansatz gewählt werden.

 

Copyright © 2017 galaniprojects GmbH | Anastasia Galani - Business Consulting. All rights reserved.