Laut der Definition von Gartner ist Projektmanagement „die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken auf Projektaktivitäten, um die Projektanforderungen zu erfüllen“.
Projektmanagement ist neben Geschäftsanalyse, Anforderungsspezifikation, Design, Programmierung und Test ein integraler Bestandteil von Softwareentwicklungsprozessen. Es ist seit Jahren ein Thema heftiger Debatten. Selbst heute, wo Projektmanagementpraktiken immer ausgereifter werden, sind sich nur 53 % der Unternehmen der Bedeutung dieser Praktiken vollständig bewusst.
Unabhängig von der Branche ist Projektmanagement ein entscheidender Faktor für die Effizienz eines Unternehmens. Tatsächlich verschwenden Unternehmen, die bewährte Projektmanagementpraktiken anwenden, 28 % weniger Geld und setzen Projekte um, die 2,5-mal erfolgreicher sind .
Projektmanagementexperten definieren ein Projekt nicht nur als erfolgreich, wenn es pünktlich und innerhalb des Budgets abgeschlossen wird, sondern auch als ein Projekt, das den erwarteten Nutzen bringt.
Projektmanagementphasen
Unabhängig vom Umfang sollte jedes Projekt einer Abfolge von Aktionen folgen, die kontrolliert und verwaltet werden müssen. Laut dem Project Management Institute (PMI) umfasst ein typischer Projektmanagementprozess die folgenden Phasen:
- Einleitung
- Planung
- Ausführung
- Leistungsüberwachung
- Projektabschluss
Diese Phasen dienen als Leitfaden zur Erledigung bestimmter Aufgaben und definieren den Lebenszyklus des Projektmanagements.
Diese Struktur ist jedoch zu allgemein. Ein Projekt hat normalerweise innerhalb jeder Phase eine Reihe interner Phasen. Diese können je nach Arbeitsumfang, Team, Branche und Projekt selbst stark variieren.
In dem Bemühen, einen universellen Ansatz für die Verwaltung beliebiger Projekte zu finden, haben Fachleute zahlreiche PM-Techniken und -Methoden entwickelt.
Traditionelle Projektmanagement-Methodik
Traditionelle Methoden basieren auf dem oben beschriebenen klassischen Rahmen und gehen bei der Projektausführung schrittweise vor. Das Projekt durchläuft also in aufeinanderfolgenden Phasen die Initiierung, Planung, Ausführung und Überwachung bis hin zum Abschluss. Dieser
oft als linear bezeichnete Ansatz umfasst eine Reihe interner Phasen, die aufeinander folgen und in chronologischer Reihenfolge ausgeführt werden. Am häufigsten wird das traditionelle Projektmanagement im Bau- oder Fertigungssektor angewandt, wo in jeder Phase nur wenige oder keine Änderungen erforderlich sind. Es hat jedoch auch in der Softwareentwicklung Anwendung gefunden. Das
als Wasserfallmodell bekannte Modell ist seit Anfang der 1970er Jahre eine vorherrschende Methode der Softwareentwicklung. Winston W. Royce beschrieb es folgendermaßen : „ Bei der Entwicklung aller Computerprogramme, unabhängig von Größe oder Komplexität, gibt es zwei grundlegende Schritte. Zuerst gibt es einen Analyseschritt, gefolgt von einem Codierungsschritt … Dieses sehr einfache Implementierungskonzept ist eigentlich alles, was erforderlich ist, wenn der Aufwand gering genug ist und das Endprodukt von denen bedient werden soll, die es erstellt haben – wie dies normalerweise bei Computerprogrammen für den internen Gebrauch der Fall ist. “
Das Wasserfallmodell legt großen Wert auf die Planung und Entwicklung von Spezifikationen, die bis zu 40 Prozent der Projektzeit und des Projektbudgets in Anspruch nehmen . Ein weiteres Grundprinzip dieses Ansatzes ist die strikte Reihenfolge der Projektphasen. Eine neue Projektphase beginnt erst, wenn die vorherige abgeschlossen ist.
Die Methode eignet sich gut für klar definierte Projekte mit einem einzigen Liefergegenstand und einem festen Termin. Der Wasserfallansatz erfordert eine gründliche Planung, ausführliche Projektdokumentation und eine strenge Kontrolle des Entwicklungsprozesses. Theoretisch sollte dies zu einer pünktlichen und budgetgerechten Lieferung, geringen Projektrisiken und vorhersehbaren Endergebnissen führen.
Bei der Anwendung auf den tatsächlichen Softwareentwicklungsprozess ist die Wasserfallmethode jedoch aufgrund zahlreicher Einschränkungen tendenziell langsam, teuer und unflexibel. In vielen Fällen führt die Unfähigkeit, das Produkt an die sich entwickelnden Marktanforderungen anzupassen, häufig zu einer enormen Ressourcenverschwendung und schließlich zum Scheitern des Projekts.
Was ist agile project management
haben Agile in der einen oder anderen Form übernommen. Gleichzeitig bleibt noch viel Arbeit, um diese Praxis ausgereift zu machen. Die Geschichte von Agile lässt sich bis ins Jahr 1957
zurückverfolgen : Damals verwendeten Bernie Dimsdale, John von Neumann, Herb Jacobs und Gerald Weinberg inkrementelle Entwicklungstechniken (die heute als Agile bekannt sind) und entwickelten Software für IBM und Motorola. Sie wussten nicht, wie sie ihren Ansatz einordnen sollten, aber ihnen war klar, dass er sich in vielerlei Hinsicht vom Wasserfall-Prinzip unterschied. Das moderne Agile wurde offiziell im Jahr 2001 eingeführt , als sich eine Gruppe von 17 Softwareentwicklungsexperten traf, um alternative Projektmanagementmethoden zu diskutieren. Sie hatten eine klare Vision des flexiblen, leichtgewichtigen und teamorientierten Softwareentwicklungsansatzes und skizzierten ihn im Manifest für Agile Softwareentwicklung . Mit dem Ziel, „bessere Wege zur Softwareentwicklung aufzudecken“, legt das Manifest die Agile-Grundlagen klar fest: „ Durch diese Arbeit haben wir gelernt, folgende Werte zu schätzen: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Funktionierende Software ist wichtiger als umfassende Dokumentation. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Das Reagieren auf Veränderungen ist wichtiger als das Befolgen eines Plans. “ Ergänzt durch die Zwölf Prinzipien der Agilen Software hat sich diese Philosophie zu einer universellen und effizienten neuen Art des Projektmanagements entwickelt.
Agiler Ansatz und Prozess
Agile Methoden verfolgen einen iterativen Ansatz zur Softwareentwicklung. Im Gegensatz zu einem einfachen linearen Wasserfallmodell bestehen Agile-Projekte aus einer Reihe kleinerer Zyklen. Jeder von ihnen ist ein Miniaturprojekt: Es besteht aus den Phasen Design, Implementierung, Test und Bereitstellung innerhalb des vordefinierten Arbeitsumfangs.
Am Ende jedes Zyklus wird ein potenziell lieferbares Produktinkrement geliefert. Somit werden mit jeder Iteration neue Funktionen zum Produkt hinzugefügt, was zu einem schrittweisen Projektwachstum führt. Wenn die Funktionen früh in der Entwicklung validiert werden, ist die Wahrscheinlichkeit, ein potenziell fehlgeschlagenes Produkt auszuliefern, deutlich geringer.
Schritte zur agilen Softwareentwicklung
Der End-to-End-Prozess des agile project management besteht aus fünf verschiedenen Phasen, die größtenteils den oben genannten allgemeinen PM-Phasen entsprechen.
Visions- oder Initiierungsphase. In der ersten Phase einer agile project management methode geht es darum, die Bedürfnisse der Endkunden zu ermitteln, Geschäftsziele festzulegen und die gewünschten Ergebnisse zu skizzieren. Ein Projektmanager identifiziert die richtigen Stakeholder und weist dem Team Rollen zu.
Spekulations- oder Planungsphase. Diese Phase hat zwei Hauptziele: das Projekt in Meilensteine aufzuteilen und Zeitpläne festzulegen. Um das erste Ziel zu erreichen, benötigen Sie zumindest ein allgemeines Verständnis der funktionalen Projektanforderungen . Das Agile-Team priorisiert Funktionen und schätzt, wie lange es dauern wird, sie zu entwickeln. Diese Phase führt zur Erstellung eines Ausführungsplans, der sich im Gegensatz zum Wasserfall-Szenario weiter an Änderungen anpasst.
Erkundungsphase. Dabei werden verschiedene Möglichkeiten untersucht, um die Projektanforderungen zu erfüllen und gleichzeitig die Zeit- und Budgetbeschränkungen einzuhalten. Sobald die beste Option festgelegt ist, fügt das Team einen Teil der Benutzergeschichten zu einem Iterationsplan hinzu und fährt mit deren Entwicklung und Tests fort. Die Erkundungsphase verläuft parallel zur vierten Anpassungsphase, da das Team Kundenfeedback berücksichtigt und aus den bisherigen Erfahrungen lernt.
Anpassungsphase. Diese Phase ist einzigartig für die agile Softwareentwicklung. Sie ermöglicht es dem Team, die Ergebnisse früherer Iterationen zu überprüfen, die bestehende Situation zu bewerten, Kundenfeedback zu sammeln und die Leistung im Vergleich zum Ausführungsplan zu überprüfen. Anschließend können Sie Ihre Pläne und Ansätze entsprechend anpassen und alle erforderlichen Änderungen und neuen Anforderungen einführen, falls vorhanden.
Abschlussphase. In der letzten Phase stellt das Team sicher, dass das Projekt abgeschlossen ist und alle aktualisierten Anforderungen erfüllt. Die beste Vorgehensweise besteht hier darin, während des Projekts aufgetretene Fehler und Verbesserungsbereiche zu besprechen, um in Zukunft bessere Entscheidungen treffen zu können.
Bewährte Methoden für Agile
Fassen wir die Best Practices zusammen, an denen Agile festhält.
Flexibilität: Der Arbeitsumfang kann sich aufgrund neuer Anforderungen ändern.
Arbeitsaufteilung: Das Projekt besteht aus kleinen Zyklen.
Wert der Teamarbeit: Die Teammitglieder arbeiten eng zusammen und haben eine klare Vorstellung ihrer Verantwortlichkeiten.
Iterative Verbesserungen: Die innerhalb eines Zyklus geleistete Arbeit wird häufig neu bewertet, um das Endprodukt zu verbessern.
Zusammenarbeit mit einem Kunden: Der Kunde ist eng in die Entwicklung eingebunden und kann die Anforderungen ändern oder die Vorschläge des Teams annehmen.
Laut dem 16. Annual State of Agile Report erwähnen die Befragten, die den Agile-Ansatz übernommen haben, die folgenden Vorteile:
- beschleunigte Markteinführungszeit (52 Prozent);
- Vorhersehbarkeit der Lieferung (44 Prozent); und
- geringeres Risiko (31 Prozent).
Unternehmen geben außerdem zu, dass leistungsstarke Agile-Teams über menschenzentrierte Werte, klare Kulturtools und eine Führungskompetenz verfügen, die sich positiv auf die gesamte Organisation auswirken.
agile project management-Frameworks und -Methoden
Agile ist ein Sammelbegriff für eine Vielzahl von Methoden und Techniken, die die oben beschriebenen Prinzipien und Werte teilen. Jede von ihnen hat ihre eigenen Anwendungsbereiche und Besonderheiten. Die beliebtesten Frameworks und Praktiken sind Scrum, Kanban, Hybrid, Lean, Bimodal, XP und Crystal. Bevor wir sie genauer besprechen, untersuchen wir ihre wichtigsten Merkmale.
Scrum: Beliebtestes Framework für die regelmäßige Auslieferung von Releases
Scrum ist eine vorherrschende Methode, die den Prozessablauf in 87 Prozent der Organisationen diktiert, die Agile verwenden. Erstmals 1986 von Hirotaka Takeuchi und Ikujiro Nonaka im New Product Development Game beschrieben , wurde es fast ein Jahrzehnt später formuliert.
1995 stellten Ken Schwaber und Jeff Sutherland, die Autoren von The Scrum Guide , es auf der OOPSLA-Konferenz vor . Die Präsentation basierte auf dem Wissen, das sie in den vorangegangenen Jahren durch die Anwendung der Methode erworben hatten. Obwohl Scrum lange vor dem Agile Manifest eingeführt wurde, basiert es auf Agile-Prinzipien und steht im Einklang mit den in diesem Dokument genannten Werten.
Scrum-Team, Rollen und Verantwortlichkeiten
Scrum zielt darauf ab, eine enge Zusammenarbeit zwischen den Leuten aufrechtzuerhalten, die an komplexen Produkten arbeiten und bei denen Details geändert oder hinzugefügt werden. Es basiert auf den systematischen Interaktionen zwischen den drei Hauptrollen mit festgelegten Verantwortlichkeiten: Scrum Master, Product Owner und Entwicklungsteam. Der
Scrum Master ist eine zentrale Figur innerhalb eines Projekts. Seine Hauptverantwortung besteht darin, alle Hindernisse zu beseitigen, die das Team an einer effizienten Arbeit hindern könnten. Der
Product Owner , normalerweise ein Kunde oder anderer Interessenvertreter , ist während des gesamten Projekts aktiv involviert. Er vermittelt die globale Vision des Produkts und gibt nach jedem Sprint zeitnahes Feedback zur geleisteten Arbeit.
Das Entwicklungsteam besteht aus Softwareentwicklern, QA-Ingenieuren , UI/UX-Designern und anderen Spezialisten. Sie sind selbstorganisiert, was bedeutet, dass sie autonom Entscheidungen darüber treffen können, wie Aufgaben innerhalb des Sprints erledigt werden.
Zusammen bilden diese drei Rollen das Scrum-Team – eine funktionsübergreifende Gruppe von Leuten, die für die Produktimplementierung verantwortlich ist. Es sollte aus bis zu 7 Teammitgliedern bestehen, um flexibel und produktiv zu bleiben.
Sprints und Artefakte
Eine grundlegende Arbeitseinheit in Scrum – Sprint – ist ein kurzer Entwicklungszyklus, der erforderlich ist, um ein lieferbares Produktinkrement zu erstellen. Ein Sprint dauert normalerweise zwischen 1 und 4 Wochen. Längeren Iterationen fehlt die Vorhersehbarkeit und Flexibilität, die die grundlegenden Vorteile von Scrum sind. Da es keine Standarddauer gibt (solange sie weniger als 4 Wochen beträgt), sollten alle Sprints innerhalb eines Projekts eine feste Länge haben. Dies erleichtert die Planung und Nachverfolgung des Fortschritts.
Scrum stützt sich auf drei Hauptartefakte, die zur Verwaltung der Anforderungen und zur Nachverfolgung des Fortschritts verwendet werden – Product Backlog, Sprint Backlog und Sprint Burndown Chart.
Das Product Backlog ist eine geordnete Liste von Backlog-Elementen, die die Anforderungen von Endbenutzern oder Unternehmen beschreiben, die durch ein Endprodukt erfüllt werden müssen. Das Dokument erfasst Projektanforderungen und -ziele. Es wird vom Product Owner gepflegt, der jedes Mal Aktualisierungen vornimmt, wenn neue Informationen erscheinen. Dazu gehören Änderungen der Geschäftsprioritäten, neue Funktionsanforderungen, Feedback von Endbenutzern usw.
Das Sprint Backlog ist eine Liste von Aufgaben, die das Team erledigen muss, um am Ende jedes Sprints ein Inkrement funktionsfähiger Software zu liefern. Mit anderen Worten, die Teammitglieder einigen sich darauf, welche Produktelemente geliefert werden sollen, und definieren einen Plan, wie dies zu tun ist.
Das Sprint Burndown Chart ist eine Darstellung der verbleibenden Arbeit in einem Sprint. Es hilft sowohl dem Team als auch dem Scrum Master, da es den Fortschritt täglich zeigt und vorhersagen kann, ob das Sprintziel termingerecht erreicht wird.
Scrum-Meetings
Der Prozess wird durch eine Reihe wiederkehrender Meetings oder Events formalisiert, wie das Daily Scrum (Standup), das Sprint Planning, das Review und Retrospektiv-Meetings (die Sprint-Retrospektive).
Das Daily Scrum ist ein zeitlich begrenztes Meeting, bei dem das Scrum-Team seine Arbeit koordiniert und einen Plan für die nächsten 24 Stunden festlegt. Das Event dauert 15 Minuten und sollte täglich am gleichen Ort und zur gleichen Zeit stattfinden. Beim Sprint Planning
wird die zu erledigende Arbeit geplant . Alle am Sprint Beteiligten (der Product Owner, der Scrum Master und das Scrum-Team) nehmen an diesem Event teil. Der Product Owner stellt die Backlog-Elemente mit der höchsten Priorität vor. Das Scrum-Team zerlegt sie in überschaubare Aufgaben, legt den Arbeitsumfang für den Sprint fest und erstellt das Sprint Backlog. Das Sprint Planning dauert bei einem Sprint von einem Monat nicht länger als acht Stunden. Bei kürzeren Sprints nimmt das Meeting in der Regel weniger Zeit in Anspruch. Am Ende jedes Sprints treffen sich das Team und der Product Owner beim Sprint Review . Während dieses informellen Meetings präsentiert das Team die geleistete Arbeit und beantwortet Fragen zum Produktinkrement. Alle Teilnehmer arbeiten gemeinsam daran, was als Nächstes zu tun ist, um den Wert des Produkts zu steigern. Das Sprint Review ist ein vierstündiges, zeitlich begrenztes Meeting für einmonatige Sprints. Das gesamte Team nimmt an Retrospektivmeetings teil, um über seine Arbeit während des Sprints nachzudenken. Die Teilnehmer besprechen, was gut oder falsch gelaufen ist, finden Verbesserungsmöglichkeiten und planen, wie diese positiven Änderungen umgesetzt werden können. Die Sprint-Retrospektive findet nach dem Review und vor der nächsten Sprint-Planung statt. Die Dauer der Veranstaltung beträgt für einmonatige Sprints drei Stunden.
Wann Sie Scrum verwenden sollten
Scrum eignet sich gut für langfristige, komplexe Projekte, die Feedback von Stakeholdern erfordern, was die Projektanforderungen stark beeinflussen kann. Wenn also der genaue Arbeitsumfang nicht geschätzt werden kann und der Veröffentlichungstermin nicht feststeht, ist Scrum möglicherweise die beste Wahl. Die Liste der Unternehmen, die diesen Ansatz verwenden, ist beeindruckend. Tatsächlich gibt es eine öffentliche Tabelle mit solchen Organisationen, darunter Microsoft, IBM, Yahoo und Google.
Scrum geht über die IT hinaus. Unternehmen aus den Bereichen Finanzen, Beratung, Bildung, Einzelhandel, Medien und Unterhaltung wählen diesen Ansatz, um ihre Arbeitsprozesse zu organisieren und die Zusammenarbeit mit Kunden zu verbessern.
Kanban: Arbeitsabläufe visualisieren
Kanban ist das zweitbeliebteste Framework, das von 56 Prozent der Unternehmen verwendet wird, die Agile praktizieren. Die Ursprünge dieser einfachen, aber wirkungsvollen Methode gehen auf ein visuelles Kartensystem zurück, das in der Toyota-Produktion als Produktionskontrollmethode eingesetzt wurde.
Arbeitsprinzipien von Kanban
Kanban bedeutet aus dem Japanischen übersetzt „visuelles Signal“ und konzentriert sich auf die Visualisierung des Arbeitsablaufs und priorisiert die laufende Arbeit (WIP) , wobei der Umfang begrenzt wird, um sie effektiv an die Kapazität des Teams anzupassen.
Sobald eine Aufgabe abgeschlossen ist, kann das Team das nächste Element aus der Pipeline nehmen. Somit bietet der Entwicklungsprozess mehr Flexibilität bei der Planung, schnellere Bearbeitungszeiten, klare Ziele und Transparenz.
Im Gegensatz zu Scrum sind bei Kanban keine Standardverfahren und festen Iterationen erforderlich. Die Projektentwicklung basiert auf der Visualisierung des Arbeitsablaufs durch ein Kanban-Board , das normalerweise durch Haftnotizen und Whiteboards oder Projektmanagement-Tools wie Trello dargestellt wird.
Trello automatisiert und digitalisiert Kanban. Dank der prägnanten Informationen zu einem Arbeitselement, die jede Kanban-Karte enthält, weiß jeder im Team, wer für das Element verantwortlich ist, was die Aufgabe jeder Person ist, wann sie fertig sein soll usw. Teammitglieder können auch Kommentare hinterlassen und Screenshots, Dokumente oder Links anhängen, um weitere Details bereitzustellen.
Die Möglichkeit, den Fortschritt zu verfolgen, hilft den Mitarbeitern, den persönlichen Beitrag jedes Einzelnen zum Erreichen des gemeinsamen Ziels zu verstehen, sodass der Fokus darauf liegt, die Aufgabe gut und pünktlich zu erledigen.
Wann Sie Kanban verwenden sollten
Mit Kanban können Teams kleine Releases durchführen und sich an veränderte Prioritäten anpassen. Anders als bei Scrum gibt es keine Sprints mit vordefinierten Zielen. Kanban konzentriert sich darauf, kleine Arbeitsschritte zu erledigen, sobald sie anfallen. Wenn Tester beispielsweise Fehler im Produkt finden, versuchen die Entwickler, diese sofort zu beheben. Kanban funktioniert beispielsweise auch nach der Hauptversion des Produkts gut und eignet sich für Aktualisierungs- und Wartungszwecke.
Unternehmen wie Spotify und Wooga (ein führendes Unternehmen für die Entwicklung von Handyspielen) haben diesen Ansatz im Laufe der Jahre erfolgreich eingesetzt. Dennoch kombinieren 27 Prozent der Organisationen Scrum mit Kanban-Techniken und verwenden das sogenannte Scrumban anstelle der ursprünglichen Frameworks.
Hybrid: Kombination aus Waterfall und Agile für flexible Entwicklung und gründliche Projektplanung
Agile und Waterfall sind zwei verschiedene Visionen des Softwareentwicklungsmanagements. Bei ersterer geht es um iterative Entwicklung und Flexibilität, während letztere eine schrittweise Entwicklung fördert, sorgfältige Planung erfordert und Änderungen im Laufe der Zeit ablehnt.
Viele Unternehmen erkennen, dass die Anwendung beider Ansätze vorteilhafter sein kann, als sich für einen der beiden zu entscheiden. Die Kombination des traditionellen Wasserfall-Projektmanagements und Agile wird als Hybrid bezeichnet.
Funktionsprinzipien des Hybrid-Frameworks
Spezialisten nutzen die Agile-Philosophie für die Softwareentwicklung. Aber wenn es um Budgetierung, Planung und Hardwaredesign geht, funktioniert das Wasserfallmodell normalerweise besser. Sie können also je nach Ihren Aufgaben den am besten geeigneten Ansatz integrieren.
Um das Beste aus beiden Methoden herauszuholen, können Sie Agile-Praktiken auch in traditionelle Wasserfall-Arbeitsprozesse einbetten. Beispielsweise kann die Projektplanung in Sprints erfolgen, wobei regelmäßig Feedback eingeholt wird. Andere Möglichkeiten, das Wasserfallmodell zu modifizieren, sind die Verwendung von Kanban-Boards und die Organisation von Retrospektiven.
Wann wird Hybrid verwendet?
Hybrid ist eine effektive Lösung, wenn die Produktentwicklung sowohl Hardware als auch Software umfasst. Es gibt jedoch noch einen weiteren Grund, sich für Hybrid zu entscheiden. Eine Situation, in der ein Kunde mit einem nicht festgelegten Zeitrahmen und Budget sowie mangelnder Planung unzufrieden ist, kommt nicht selten vor. Eine solche Unsicherheit ist typisch für Agile. In diesem Fall können Planung, Anforderungsspezifikation und Anwendungsdesign im Wasserfall-Verfahren durchgeführt werden, während Agile für die Softwareentwicklung und das Testen eingesetzt wird.
Bimodale IT: Balance zwischen Stabilität und Innovationen
Der Begriff „Bimodale IT“ wurde 2014 von Gartner eingeführt . Er entwickelte sich zu einer der beliebtesten Kombinationen aus Agile und Waterfall und ermöglicht es Unternehmen, zwei IT-Lieferflüsse mit unterschiedlichen Methoden und Zielen abzuwickeln.
Bimodale Wirkprinzipien
Bimodale IT ist die Praxis, zwei separate, aber konsistente Arbeitsstile zu verwalten: einer konzentriert sich auf Vorhersehbarkeit und der andere auf Agilität.
Modus 1 ist traditionell; daher funktioniert er perfekt in gut verstandenen und vorhersehbaren Bereichen. Laut Gartner konzentriert er sich darauf, das Bekannte auszunutzen und gleichzeitig die Legacy-Umgebung in einen Zustand zu verwandeln, der für eine digitale Welt geeignet ist.
Modus 2 beinhaltet eine schnelle Anwendungsentwicklung. Er ist explorativ, nichtlinear und für die Lösung neuer Probleme optimiert. Modus 2 ist besonders nützlich für die Arbeit an Projekten, die so schnell wie möglich abgeschlossen werden müssen.
Beide Modi erfordern unterschiedliche Fähigkeiten, Techniken und Werkzeuge. Daher werden zwei separate Arbeitsgruppen benötigt. Diese Teams haben zwei unterschiedliche Ziele – Stabilität zu gewährleisten und gleichzeitig Innovationen zu übernehmen. Die Teammitglieder konzentrieren sich auf Projekte, die am besten zu ihrem Modus passen.
Das Team für Modus 1 entwickelt und wartet Anwendungen und Kernsysteme, um langfristige Geschäftsanforderungen zu unterstützen. Die technologischen Fähigkeiten eines Unternehmens hängen direkt von der Arbeit ab, die dieses Team leistet.
Das Team für Modus 2 liefert häufig innovative Anwendungen, um neue Kunden zu gewinnen und kurzfristige Geschäftsanforderungen zu erfüllen. Dieses Team kann die Funktionalität des Produkts ändern, nachdem es Feedback erhalten und den Markt analysiert hat.
Die Teams verwenden unterschiedliche Bereitstellungsmechanismen und berichten über unterschiedliche Organisationsstrukturen. Dennoch müssen sie miteinander kommunizieren, um Ideen auszutauschen und Ergebnisse zu teilen.
Wie Sandy Kemsley angibt, verlässt sich Modus 2 auf die von Modus 1 bereitgestellte Informations- und Serviceinfrastruktur, während Modus 1 auf Modus 2 angewiesen ist, um sowohl neue Produktideen als auch neue Entwicklungsmethoden zu testen, die möglicherweise irgendwann wieder in Modus 1 zurückgeführt werden.
Wann wird Bimodal verwendet?
Wenn sich das Unternehmen auf langfristige und kurzfristige Projekte spezialisiert, die unterschiedliche Entwicklungs- und Managementansätze erfordern, ist bimodale IT möglicherweise die richtige Wahl. Bei diesem Rahmen geht es darum, das Gleichgewicht zwischen der Unterstützung einer stabilen IT-Infrastruktur und der Förderung von Innovationen zu wahren. Modus 1 gewährleistet einen vorhersehbaren Fahrplan für die Wartung von Altsystemen und seltene Änderungen. Gleichzeitig ermöglicht Modus 2 effektives Experimentieren, Prototyping und schnelle Entwicklung.
Lean: Verschwendung in der Softwareentwicklung vermeiden
Jüngsten Schätzungen zufolge ist die Einführung von Lean bei Agile-Unternehmen von nur 2 Prozent im Jahr 2015 auf 10 Prozent im Jahr 2022 gestiegen. Der Ansatz hat dieselben Ursprünge wie Kanban und begann als Technik für die physische Fertigung. Er entstammte dem Toyota-Produktionssystem als Managementansatz, der darauf abzielte, „ die von Kunden bestellten Fahrzeuge so schnell und effizient wie möglich herzustellen, um die Fahrzeuge so schnell wie möglich auszuliefern “ .
Schlanke Arbeitsprinzipien
Die Anwendung von Lean-Prinzipien auf die Softwareentwicklung wurde erstmals von Mary und Tom Poppendieck in ihrem Buch Lean Software Development: An Agile Toolkit vorgestellt .
Es umfasst die 7 Grundprinzipien :
- Abfall beseitigen,
- Lernen verstärken und Wissen schaffen,
- so spät wie möglich entscheiden,
- so schnell wie möglich liefern,
- das Team befähigen,
- Integrität/Qualität aufbauen und
- das Ganze sehen.
Sehen wir uns nun jeden einzelnen genauer an.
Verschwendung vermeiden. In der Softwareentwicklung bezieht sich das Wort „Verschwendung“ auf alles, was dem Projekt keinen Mehrwert bringt und daher vermieden werden sollte. Dies können Leerlaufzeiten, unnötige Funktionen oder Mängel sein.
Lernen verstärken und Wissen schaffen. In Lean wird Softwareentwicklung als fortlaufender Lernprozess wahrgenommen. Entwickler schreiben normalerweise nicht beim ersten Versuch klaren Code. Nachdem sie Fehler erkannt und behoben haben, schreiben sie eine verbesserte Variante des vorherigen Codes. Ingenieure gewinnen während der Entwicklung Wissen, indem sie Probleme lösen und Codevarianten erstellen. Der beste Weg, die Softwareentwicklungsumgebung zu verbessern, besteht also darin, das Lernen zu verstärken.
Treffen Sie so spät wie möglich Entscheidungen. Spät getroffene Entscheidungen sind fundierter, da sie auf Fakten basieren. Da Technologien immer schneller veralten, ist es ein kluger Schachzug, eine irreversible Designentscheidung hinauszuzögern. Eine wichtige Strategie für späte Verpflichtungen besteht darin, die Kapazität für die Änderung im System freizuhalten.
Liefern Sie so schnell wie möglich. Das vierte Prinzip betrifft die Vorteile einer schnellen Softwareentwicklung. Kurze Entwicklungszyklen ermöglichen es Entwicklern, durch Feedback mehr zu lernen. Sie ermöglichen es einem Kunden auch, eine endgültige Entscheidung über das Design zu verschieben, bis er mehr weiß. Eine schnelle Lieferung hilft also, Abfall zu vermeiden.
Bestärken Sie das Team. Entwickler sollten das Recht haben, technische Entscheidungen zu treffen, da sie die Details ihrer Arbeit wie kein anderer verstehen. Sie können einen Fahrplan erstellen und ihm folgen.
Integrieren Sie Integrität/Qualität. Die Wahrnehmung der Software durch den Benutzer und ihre Eigenschaften müssen übereinstimmen. Wenn ein Kunde der Meinung ist, dass eine Software alle erforderlichen Funktionen hat und einfach zu verwenden ist, hat dieses System wahrgenommene Integrität. Konzeptionelle Integrität bedeutet, dass die Software eine kohärente Architektur hat und bei Benutzerfreundlichkeit und Zweckmäßigkeit gut abschneidet. Sie kann gewartet, angepasst und erweitert werden.
Sehen Sie das Ganze. Ingenieure sollten die Gesamteffizienz des Systems übernehmen, anstatt sich auf ihren kleinen Teil zu konzentrieren. Wenn Experten dieses Prinzip einhalten, können sie ein System mit Integrität erstellen.
Diese Grundlagen beschreiben die Lean-Philosophie perfekt: Ihr Ziel ist es, mit weniger Aufwand, Investition und Zeit mehr Wert zu liefern.
Lean-Softwareentwicklung ist ein iteratives und inkrementelles Framework . Daher wird das funktionierende Produktinkrement wie bei jedem anderen Agile-Ansatz in den frühen Entwicklungsphasen geliefert. Der weitere Fortschritt hängt weitgehend vom Feedback des Produktbesitzers ab.
Was den Lean-Ansatz unterscheidet, ist, dass das Team nicht auf formale Prozesse wie wiederkehrende Besprechungen oder gründliche Aufgabenpriorisierung beschränkt ist.
Wann Sie Lean verwenden sollten
Lean ermöglicht es Unternehmen, eine Entwicklungstechnik für ein minimal funktionsfähiges Produkt (MVP) zu verfolgen . Dazu gehört die Bereitstellung eines Produkts mit einem minimalen, ausreichenden Satz an Funktionen, um die ersten Benutzer zufriedenzustellen. Die Idee der MVP-Strategie besteht darin, Kundenfeedback zu sammeln und zu analysieren, um herauszufinden, ob ihnen das Produkt gefällt und sie es kaufen möchten. Das Wissen über die Gewohnheiten, Vorlieben und Bedürfnisse der Kunden ist der Schlüssel zur Herstellung kommerziell erfolgreicher Produkte. Entwickler verwenden Feedback, um einen Fahrplan für die zukünftige Entwicklung zu erstellen.
Lean eignet sich aufgrund der kurzen Lebenszyklen gut für kleine, kurzfristige Projekte. Dieser Ansatz ist auch geeignet, wenn der Kunde an der Projektrealisierung teilnehmen kann, da Lean kontinuierliches Feedback erfordert.
Lean-Prinzipien werden von einer großen Anzahl von Fertigungsunternehmen wie Nike, Ford und Intel erfolgreich übernommen und sind in verschiedenen Branchen weit verbreitet. Startups und erfolgreiche Unternehmen wie Corbis, PatientKeeper und Xerox wenden Lean-Softwareentwicklungspraktiken auf ihre Prozesse an.
Extreme Programming: Agile Praktiken zum Schreiben guten Codes
Extreme Programming (XP) unterscheidet sich von den oben genannten Frameworks durch seinen Fokus auf technische Aspekte der Softwareentwicklung, nämlich Qualitätscode. XP wird von 9 Prozent der Unternehmen verwendet.
Es erfordert von Entwicklern, eine kleine Anzahl von Engineering-Praktiken auf dem höchstmöglichen, fast extremen Niveau durchzuführen, daher der Name. Das Framework bietet Agile-Teams Tools zur Optimierung des Engineering-Prozesses und zur Anpassung an sich ändernde Anforderungen.
XP-Arbeitsprinzipien
XP wurde in den 1990er Jahren eingeführt. Kent Beck, einer der ersten Unterzeichner des Agile Manifesto, erfand es, als er an einem Projekt für ein umfassendes Vergütungssystem für Chrysler arbeitete . Sein Ziel war es, Wege zu finden, um anspruchsvolle Aufgaben so schnell wie möglich zu erledigen. 1999 dokumentierte er XP-Techniken in dem Buch Extreme Programming Explained: Embrace Change . Die am häufigsten verwendeten XP-Praktiken sind:
- testgetriebene Entwicklung (TDD),
- Code Refactoring,
- kontinuierliche Integration,
- Paarprogrammierung und
- Kodierungsstandards.
Testgetriebene Entwicklung ist eine fortschrittliche Technik, die automatisierte Unit-Tests verwendet, um Software-Designprozesse voranzutreiben. Im Gegensatz zum regulären Entwicklungszyklus, bei dem die Tests nach dem Code geschrieben werden (oder überhaupt nicht geschrieben werden), verfolgt TDD einen Test-First-Ansatz. Dies bedeutet, dass die Unit-Tests vor dem Code selbst geschrieben werden.
Gemäß diesem Ansatz sollte der Test zuerst fehlschlagen, wenn kein Code vorhanden ist, um die Funktion auszuführen. Danach schreiben die Ingenieure den Code und konzentrieren sich auf die Funktionalität, damit der Test bestanden wird. Sobald dies erledigt ist, sollte der Quellcode verbessert werden, um alle Tests zu bestehen. Diese drei Schritte werden oft als Red Green Refactor-Zyklus bezeichnet .
TDD bietet nachweislich die folgenden Vorteile.
- Die Tests dienen dazu, etwaige Defekte oder Fehler im Code zu erfassen und bieten eine ständige Rückmeldung über den Zustand jeder Softwarekomponente. Dadurch wird die Qualität des Endprodukts immer höher.
- Die Unit-Tests können als stets aktuelle und sich im Verlauf des Projekts verändernde Projektdokumentation genutzt werden.
- Da das Team tief in die Produktentwicklung eingebunden ist, muss es in der Lage sein, diese kritisch zu analysieren und das geplante Ergebnis vorherzusehen, um es angemessen testen zu können. Dadurch bleibt das Team motiviert und engagiert und trägt zur Produktqualität bei.
- Durch gründliche Tests zu Beginn wird die Fehlerbehebungszeit minimiert.
Code-Refactoring ist eine gängige Praxis in der agilen Softwareentwicklung. Im Grunde handelt es sich dabei um einen Prozess der ständigen Codeverbesserung durch Vereinfachung und Verdeutlichung. Es handelt sich dabei um einen rein technischen Prozess, der keine Änderungen im Softwareverhalten erfordert.
Agile-Teams erweitern den Quellcode mit jeder Iteration und nutzen Refactoring als Möglichkeit, Code-Chaos und Duplikate auszumerzen. Dies hilft, Software-Rohlinge zu verhindern und den Code einfach zu warten und zu erweitern.
Continuous Integration (CI) ist eine weitere Praxis, auf die Agile-Teams bei der Verwaltung von gemeinsam genutztem Code und beim Testen von Software zurückgreifen. Wir glauben, dass CI eine evolutionäre Weiterentwicklung agiler Prinzipien ist. Anstatt kurze Iterationen durchzuführen, können Entwickler neu geschriebene Teile eines Codes mehrmals am Tag festschreiben und so den Benutzern kontinuierlich einen Mehrwert bieten. Indem sie mehrmals am Tag kleine und inkrementelle Updates durchführen, können Teams MVPs schneller veröffentlichen.
Um die Qualität der Software – durch Tests – zu überprüfen und ihre Bereitstellung zu automatisieren, verwenden Teams CI/CD-Tools wie CruiseControl, Atlassian Bamboo, TeamCity oder Jenkins.
Darüber hinaus hilft CI bei der Wartung des gemeinsam genutzten Codes und beseitigt die Integrationsprobleme. Somit ist die Hauptlinie des Produkts robust und sauber und kann schnell eingesetzt werden.
Pair Programming oder „Pairing“ gilt als sehr umstrittene agile Methode. Bei dieser Technik müssen zwei Ingenieure zusammenarbeiten. Während einer von ihnen den Code tatsächlich schreibt, ist der andere aktiv als Beobachter beteiligt, macht Vorschläge und führt den ersten durch den Prozess. Da sich
dieses Zweierteam sowohl auf den Code als auch auf abstraktere technische Aufgaben konzentriert, wird erwartet, dass es effizienter ist, ein besseres Softwaredesign erstellt und weniger Fehler macht. Ein weiterer Vorteil dieses Ansatzes besteht darin, dass das Projektwissen auf die Teammitglieder verteilt wird.
Dieser Methode wird jedoch oft vorgeworfen, sich negativ auf die kurzfristige Produktivität des Teams auszuwirken. Eine der Umfragen zeigt, dass die Zusammenarbeit normalerweise 15 Prozent mehr Zeit erfordert als die Einzelarbeit, was ein großer Nachteil dieser Methode ist. Es gibt jedoch einige Meinungen , dass der zusätzliche Zeitaufwand langfristig durch die insgesamt höhere Qualität der Software leicht ausgeglichen wird dora metrics.
Codierungsstandards sind eine der wichtigsten – und doch oft vergessenen – Methoden des Extreme Programming. Sie verpflichten Entwickler, beim Schreiben von Code standardisierte Formate und Stile zu verwenden. Somit können alle Teammitglieder den Code lesen, freigeben und umgestalten sowie nachverfolgen, wer an bestimmten Codeteilen gearbeitet hat.
Wann Sie XP verwenden sollten
XP bietet Tools zur Risikominderung beim Entwurf eines neuen Systems, insbesondere wenn Entwickler Code innerhalb enger Zeitvorgaben schreiben müssen. Es ist wichtig zu wissen, dass XP-Praktiken für kleine Teams mit nicht mehr als 12 Personen gedacht sind. Man sollte dieses Framework wählen, wenn man sicher ist, dass nicht nur Entwickler, sondern auch Kunden und Manager gemeinsam an einem Projekt arbeiten können.
XP schlägt auch Unit-Tests vor. Wenn Programmierer über genügend Erfahrung beim Erstellen von Funktionstests verfügen, kann XP verwendet werden.
Extreme Programming bietet Engineering-Praktiken und Ideen, die Entwicklungsteams dabei helfen, sich an ständig wechselnde Anforderungen anzupassen. Die wichtigsten Merkmale dieses Frameworks sind eine hohe Kundenbindung und kurze iterative Zyklen, die eine Woche nicht überschreiten. Außerdem schlägt XP Entwicklern vor, das Design so einfach wie möglich zu gestalten und Aufgaben zu priorisieren.
Während XP als unabhängiges Framework verwendet werden kann, sind einige seiner technischen Praktiken Teil anderer Agile-Ansätze geworden. Dreizehn Prozent der Unternehmen entscheiden sich für das Scrum/XP-Hybrid- Framework, bei dem XP-Engineering-Praktiken mit Scrum-Management-Ansätzen koexistieren. Beispielsweise umfasst Hybrid Scrum-Ereignisse und -Artefakte. Die Kundenrolle entwickelt sich weiter: Sie definiert ein Product Backlog und arbeitet bis zum Projektende mit einem Scrum-Team im Büro zusammen.
Crystal: Die Teamgröße ist wichtig
Crystal ist einer der anpassungsfähigsten und leichtesten Ansätze zur Verwaltung von Softwareentwicklungsprojekten. Von Natur aus ist Crystal eine Familie agiler Methoden, die sich auf Menschen und ihre Interaktionen statt auf Prozesse konzentriert und dabei Dinge wie Fähigkeiten, Kommunikation und Talent in den Vordergrund stellt. Die Crystal-Methode wurde 1991 von IBM-Mitarbeiter Alistair Cockburn entwickelt und geht davon aus, dass verschiedene Teams je nach Größe und Projektpriorität unterschiedlich funktionieren.
So arbeiten die Mitglieder kleinerer Teams eher synchron miteinander, sodass sie auf ständige Berichterstattung und viel Dokumentation verzichten können. Größere Teams hingegen benötigen einen strukturierteren Kommunikationsansatz, um auf dem gleichen Stand zu sein.
Es gibt einige Varianten des Crystal-Frameworks, die jeweils durch eine andere Farbe dargestellt werden:
- Glasklar – Teams mit bis zu 8 Personen,
- Kristallgelb – Teams von 10 bis 20 Personen,
- Crystal Orange – Teams von 20 bis 50 Personen und
- Crystal Red – große Teams von 50 bis 100 Personen.
Funktionsprinzipien von Kristallen
Ähnlich wie die oben genannten Agile-Praktiken und -Frameworks ermöglicht Crystal die frühe und häufige Auslieferung funktionierender Software und beseitigt gleichzeitig Bürokratie und Ablenkungen. Die Crystal Agile-Methode
besteht aus 7 Schlüsselprinzipien .
Häufige Auslieferung. Teams müssen den Benutzern regelmäßig funktionierende Softwarefunktionen ausliefern und so eine Echtzeitansicht sicherstellen, ob ein Produkt die Anforderungen des Kunden erfüllt.
Reflektierte Verbesserung. Teams nehmen sich Zeit, um über die bereits geleistete Arbeit nachzudenken, um festzustellen, was verbessert werden sollte und warum.
Osmotische Kommunikation. Teams müssen sich im selben physischen Raum befinden, um einen nahtlosen Informationsfluss zwischen allen Mitgliedern zu ermöglichen, wie die Molekülbewegung bei der Osmose.
Persönliche Sicherheit. Alle Mitglieder eines Teams sollten ihre Meinung lautstark äußern, ohne Angst haben zu müssen, in Frage gestellt oder verspottet zu werden. Innerhalb eines Teams sollte ein hohes Maß an Vertrauen herrschen.
Konzentration auf die Arbeit. Führungskräfte sollten Prioritäten festlegen und Entwicklern dedizierte Zeit zur Verfügung stellen, in der sie sich ohne Unterbrechungen, Besprechungen oder Demos auf ihre Arbeit konzentrieren können.
Zugang zu Fachexperten und Benutzern. Teams müssen bei Bedarf direkten Zugang zu Feedback von echten Benutzern erhalten.
Zugang zur technischen Umgebung. Entwicklungsteams sollten über die erforderlichen Tools für kontinuierliche Bereitstellung und automatisierte Tests verfügen, um Fehler und Störungen zu beheben.
Das Crystal Agile-Framework erleichtert die Teamkommunikation und ermöglicht gleichzeitig die Anpassung an die anspruchsvollen Anforderungen. Gleichzeitig kann es aufgrund des Fehlens vordefinierter Pläne und Strukturen zu einem Verlust des Fokus kommen.
Wann wird Crystal verwendet?
Crystal ist der richtige Ansatz für erfahrene Entwicklungsteams, denen es an Entscheidungsautonomie mangelt, da es den Aufbau von Prozessen auf eine Weise ermöglicht, die für jedes Team am besten funktioniert. Für Teams, die remote arbeiten, ist es besser, ein anderes Framework zu wählen, da Crystal direkte Kommunikation erfordert.
Schritte zur Implementierung der Agile-Methodik
Wenn Sie entschieden haben, dass die Agile-Methode für Ihr Unternehmen und Ihre Projekte geeignet ist, müssen Sie wissen, wie Sie sie erfolgreich umsetzen. Obwohl der Prozess von Unternehmen zu Unternehmen unterschiedlich sein kann, gibt es einige allgemeine Schritte, die Sie befolgen sollten.
Schritt 1: Holen Sie sich die Zustimmung Ihres Managers und aller Stakeholder
Bevor Sie mit der Implementierung der neuen Projektdurchführung beginnen, stellen Sie sicher, dass alle auf dem gleichen Stand sind und die Änderung unterstützen. Daher ist es eine gute Idee, mit den wichtigsten Akteuren zu sprechen und ihre Zustimmung zu erhalten, indem Sie ihnen die Vorteile von Agile erklären, auf ihre Bedenken eingehen und Fragen beantworten.
Schritt 2: Fangen Sie klein an
Da inkrementeller Fortschritt der Eckpfeiler von Agile ist, ist es sinnvoll, die Implementierung der Methode mit einem kleinen Projekt zu beginnen, das Feedback auszuwerten und es dann auf andere Projekte in Ihrem Unternehmen anzuwenden.
Schritt 3: Begeistern Sie Ihr Team
Der Erfolg agiler Projekte hängt von der Fähigkeit der verschiedenen Teammitglieder ab, zusammenzuarbeiten und zu kommunizieren. Wenn Ihr Team nicht von der gesamten Idee begeistert ist und/oder Veränderungen nicht unterstützt, wird die Implementierung von Agile eine schwierige Aufgabe sein. Schließlich stellt eines der Hauptprinzipien von Agile Individuen und ihre Interaktionen über Prozesse und Werkzeuge.
Schritt 4: Wählen Sie einen passenden Rahmen und bleiben Sie dabei
Wie Sie sehen, gibt es viele verschiedene Agile-Frameworks und -Praktiken. Jedes davon hat unterschiedliche Anforderungen und Schwerpunkte. Es ist wichtig, ein Agile-Framework auszuwählen, das am besten zu Ihren Prozessen passt, und dabei zu bleiben. Wenn Sie sich beispielsweise für die Implementierung von Scrum entscheiden, stellen Sie sicher, dass Ihr Team für jeden Sprint strikt einem Arbeitsplan folgt und an täglichen Meetings teilnimmt.
Fazit
Der Agile-Ansatz wird oft fälschlicherweise als eine einzige Methode betrachtet. Es gibt jedoch Dutzende von Methoden und bestimmte Praktiken, die in dieser Untersuchung nicht angesprochen wurden.
Unabhängig von den genauen Methoden und Techniken, die sie verwenden, haben Agile-Teams nachweislich ihre Gewinne 37 Prozent schneller gesteigert und 30 Prozent mehr Umsatz erzielt als nicht-agile Unternehmen. Höhere Geschwindigkeit, Flexibilität und Produktivität, die durch solche Ansätze erreicht werden, sind die Haupttreiber, die immer mehr Organisationen dazu motivieren, auf Agile umzusteigen. Die
Softwareentwicklung ist eine extrem schnelllebige Branche und erfordert Flexibilität und Reaktionsfähigkeit in jedem Aspekt der Projektentwicklung. Agile Methoden ermöglichen die Bereitstellung hochmoderner Produkte und die Entwicklung innovativer Erfahrungen, während das Produkt gleichzeitig mit Markttrends und Benutzeranforderungen synchron gehalten wird.
Es gibt jedoch immer einen Platz für Vielfalt. Abhängig von Ihren Geschäftsanforderungen und -zielen können Sie dennoch von der Verwendung des Wasserfallmodells oder der Kombination der beiden profitieren.
Referenzen
1. Puls der Branche 2017 – http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2017.pdf?sc_lang_temp=en
2. Gartner-Glossar: Projektmanagement – https://blogs.gartner.com/it-glossary/project-management/
3. Verwaltung der Entwicklung großer Softwaresysteme – http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
4. 16. jährlicher State of Agile-Bericht – https://info.digital.ai/rs/981-LQX-968/images/SOA16.pdf
5. Das Spiel zur Entwicklung neuer Produkte – https://hbr.org/1986/01/the-new-new-product-development-game
6. Iterative und inkrementelle Entwicklung: Eine kurze Geschichte – https://www.cs.umd.edu/~basili/publications/journals/J90.pdf
7. Manifest für Agile Softwareentwicklung – http://www.agilemanifesto.org/
8.Der Scrum-Leitfaden – http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100
9. Objektorientierte Programmierung, Systeme, Sprachen und Anwendungen – http://www.sigplan.org/Conferences/OOPSLA/
10. Der State of Scrum-Bericht 2017 – https://www.scrumalliance.org/ ScrumRedesignDEVSite/media/
ScrumAllianceMedia/Files%20and%20PDFs/Status%20von%20Scrum/Status0fScrum_2016_FINAL.pdf
11. Toyota-Produktionssystem – http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/
12. Gartner-Glossar: Bimodal – https://www.gartner.com/it-glossary/bimodal/
13. Bimodale IT – https://infotech.report/Resources/Whitepapers/119d385e-41cf-44f3-b518-9b56b277311b_SAG_Bimodal_IT_8PG_WP_Aug16-Web_tcm16-143391.pdf
14. Poppendieck – http://www.poppendieck.com/
15. Lean Software Development: Ein Agile-Toolkit – http://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf
16. Richtlinien für testgetriebene Entwicklung – https://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx
17. Stärkung der Argumente für Paarprogrammierung – http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF
18. Programmieren in Paaren: Erste Schritte – https://www.ibm.com/garage/method/practices/code/remote-pair-programming/
19. Extreme Programming: Eine sanfte Einführung – http://www.extremeprogramming.org/index.html
