Kommunikation, Online- und Micro-Learning am Beispiel der Agilen Softwareentwicklung

Inhaltsverzeichnis

1 Einleitung

2 Merkmale des agilen Paradigmas der Softwareentwicklung

3 Kommunikationsprozesse agiler Softwareentwicklungsteams
3.1 Besonderheiten der Online-Kommunikation

4 Lernprozesse agiler Softwareentwicklungsteams

5 Lernmethoden im Kontext agiler Softwareentwicklung
5.1 Bestandsaufnahme
5.2 Online-Learning
5.3 Micro-Learning
5.3.1 Micro-Learning im Kontext der agilen Applikationsentwicklung

6 Kompetenzentwicklung agiler Softwareentwicklungsteams

7 Fazit und Ausblick

Literatur- und Quellenverzeichnis

Anhang 1: Das agile Manifest

Anhang 2: Das Prozessmodell „Scrum“

Anhang 3: Blogs, Foren und Tools für Softwareentwickler

1 Einleitung

Die vorliegende Arbeit des Moduls Mediale Bildung und Medienkommunika­tion des Lehrgebiets Bildungstheorie und Medienpädagogik setzt sich zum Ziel, Fragestellungen zu Kommunikations- und Lernprozessen in Projekten der Softwareentwicklung zu untersuchen, die unter dem Paradigma der Agilität geführt werden. Dabei wird es zunächst darum gehen, die Relevanz der Modul­inhalte für diesen Anwendungsbereich aufzuzeigen, um im Anschluss daran auf einzelne Inhaltspunkte mit ihren konkreten Anwendungsbezügen einzuge­hen. Ein weiteres Ziel wird darin bestehen, zum einen den potenziellen Nutzen bildungswissenschaftlicher Erkenntnisse aus dem Modul, zugunsten des An­wendungsbereich der Agilen Softwareentwicklung zu identifizieren und umge­kehrt sollen Rückschlüsse gezogen, sowie Fragen und neue Aufgabenstellun­gen aus dem Anwendungsbereich an das Forschungsgebiet gerichtet werden. Der Autor ist seit mehreren Jahren als Softwareingenieur in einem multinatio­nalen Betriebsumfeld berufstätig.

2 Merkmale des Agilen Paradigmas der Softwareentwicklung

Die Geschichte der Softwareentwicklung unter dem Paradigma der Agilität beginnt mit der Formulierung des „Agilen Manifests“ (Anhang 1) am 13. No­vember des Jahres 2001, durch dessen 12 Protagonisten der sog. „Agile Alli­ance“, namentlich Kent Beck, Ken Schwaber, Jeff Sutherland, Alistair Cock- burn, Martin Fowler, und anderen bekannten Methodologen. Aber bereits zwei Jahre zuvor hatte Kent Beck an der Konferenz für objektorientierte Program­mierung in München die etablierten Entwicklungsmethoden für gescheitert erklärt und mit seinem Konzept „eXtreme Programming“ die Forderung ge­stellt, mit den planungs-, dokumentations- und konzeptionslastigen Entwick­lungsmethoden der Neunzigerjahre aufzuräumen (vgl. Coldewey J., 2011). Bedingt durch die zunehmende Komplexität moderner Softwaresysteme wur­den Entwicklungsmethoden erforderlich, die es erlaubten, flexibel auf variable Einflussfaktoren und dynamische Abhängigkeiten innerhalb laufender Projekte zu reagieren und dabei das Interesse des Auftraggebers - nämlich die möglichst zeitnahe Verfügbarkeit lauffähiger Software - nicht aus den Augen zu verlie­ren. So wurde im „Agilen Manifest“ von der „Agile Alliance“ in Worte gefasst, was für viele Softwareingenieure, aus pragmatischen Überlegungen heraus, bereits zur beruflichen Praxis geworden war. Aber nicht nur die technische Komplexität moderner Softwaresysteme hat in den vergangenen zwei Dekaden zugenommen, sondern auch die Komplexität der Geschäftsstrukturen in denen diese entwickelt werden. So werden Grossprojekte multinationaler Konzerne typischerweise von mehreren Teams entwickelt, wobei diese nicht selten - sei es mit der Absicht einer Kostenersparnis oder als Folge von Firmenübernah­men oder aus strategischen Überlegungen heraus - global verteilt operieren. Softwareingenieure stehen daher oftmals vor der Herausforderung, den Prinzi­pien des „Agilen Manifests“ auch über räumliche Distanzen und teilweise über kulturelle Grenzen hinweg, gerecht zu werden.

3 Kommunikationsprozesse agiler Softwareentwicklungsteams

Um auf die Kommunikationsprozesse innerhalb agil geführter Softwareprojek­te eingehen zu können, ist es notwendig hier zumindest eines der üblichen Pro­zessmodelle vorzustellen, in welchen agile Softwareentwicklung in der Praxis stattfindet. Repräsentativ soll hier das weit verbreitete Prozessmodell „Scrum“ zunächst im Überblick dargestellt und in Anhang 2 bezüglich seiner Rollen und Abläufe genauer erklärt werden:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Schematische Darstellung des Prozessmodells „Scrum“

Quelle: [Online, 24.08.2013] http://pmtips.net/adapting-agile-methodology-startup/

Im Sinne von Prinzip 2 und 4 des „Agilen Manifests“ (Anhang 1), gehört es zu den Aufgaben des „Product Owners“, Auftraggebern, Geschäftsleitung und anderen externen Stellen während der gesamten Projektlaufzeit, als Ansprech- partner und Vermittler zur Verfügung zu stehen. Er diskutiert die Machbarkeit von Kundenwünschen mit seinen Entwicklungsteams und stellt eine Liste der Produktfeatures im „Product Backlog“ auf Grundlage der Kundenwünsche („User Stories“) zusammen. Absprachen finden dabei gemäss Prinzip 6 des „Agilen Manifests“ vorzugsweise Face-to-Face, etwa in Form von Meetings oder Präsentationen statt, aber es kommen in der Praxis, zur Überwindung räumlicher Distanzen auch verschiedenste Kommunikationsmedien zum Ein­satz. Entwicklungsteams organisieren sich unter der Moderation des „Scrum Masters“ selbst: Die „User Stories“ werden im Rahmen des „Sprint-Planings“ bezüglich Aufwand geschätzt und in überschaubare Arbeitseinheiten, sog. „Tasks“ aufgeteilt. Ziel des „Sprint-Planings“ ist es, gemeinsam zu entschei­den, welche der „User Stories“ im bevorstehenden „Sprint“ implementiert wer­den können. Dies geschieht in der Regel wiederum Face-to-Face während eines oder mehrerer Meetings oder, sofern auswärtige Entwicklungsteams involviert sind, unter Zuhilfenahme entsprechender Softwaretools, audiovisuell über das Internet, mit Zugriff auf einen gemeinsamen Planungsdesktop (Beispiel s. An­hang 3).

Entwickler kommunizieren mit Kollegen anderer Projektteams zur Klärung technischer Details häufig per E-Mail oder in Echtzeit per Chat. Kollektives Wissen im Sinne Surowiecki‘s „Wisdom of the Crowds“ (vgl. Surowiecki, 2005), hat sich in Form häufig frequentierter online Foren und Blogs der Ent­wicklerszene als ebenso verlässliche wie unerschöpfliche Wissensquelle etab­liert; Es gibt wohl kaum ein Standardproblem der Programmierung, für wel­ches nicht in einem der vielen Expertenblogs (Beispiele s. Anhang 3) Lösungs­varianten diskutiert werden.

Im Rahmen des „Sprint-Reviews“ werden die Arbeitsergebnisse eines „Sprints“ im Sinne von Prinzip 3 des „Agilen Manifests“ an der lauffähigen Software von den Entwicklern demonstriert. Auch hier können bei räumlicher Verteilung der Interessensvertreter und der beteiligten Teams wiederum Soft­waretools zum Einsatz kommen, die es erlauben Bildschirminhalte über das Internet zu teilen. Auf diese Weise können Arbeitsergebnisse interaktiv vorge­führt und hinsichtlich zuvor festgelegter Zielkriterien - den sog. „Definitions of Done“, die einen festen Bestandteil der entsprechenden „User Stories“ bilden - geprüft und von den beteiligten Parteien „live“ kommentiert werden. Im Sinne von Prinzip 2 des „Agilen Manifests“ ist für „Scrum“-Teams dabei gerade die­ses unmittelbare Feedback der Auftraggeber und anderer Stakeholder als Reak­tion auf die Ergebnisse einer Entwicklungsiteration („Sprint“) im agilen Ent­wicklungsprozess für die weitere Projektplanung insofern von besonderer Be­deutung, als dass dadurch Zielvorstellungen und die Machbarkeit der Kunden­wünsche periodisch überprüft und sichergestellt werden können (vgl. Wolf & Bleek, 2011, S. 177).

Zusammenfassend kann festgehalten werden: Agile Softwareentwicklung, wie in obigem Beispiel skizziert und gemäss Prozessmodell „Scrum“ durchgeführt, ist durch vielschichtige, wiederkehrende Kommunikationsprozesse gekenn­zeichnet. Kommunikation findet dabei gemäss Manifesto, wenn immer mög­lich Face-to-Face statt, in der modernen Alltagspraxis global kollaborierender Teams wird sie aber typischerweise unter Zuhilfenahme einer breiten Palette von Kommunikationsmedien bewerkstelligt. Als Medien mit synchronem - das heisst unmittelbarem Informationsaustausch - kommen nebst Handy und Tele­fon moderne Softwaretools zum Einsatz, die es ermöglichen Videokonferenzen und Desktopsessions über das Internet durchzuführen. Zur Gruppe von Medien mit asynchronem - das heisst mit zeitversetztem Informationsaustausch - gehö­ren sowohl E-Mail, wie auch Kommunikationslösungen der Kategorie „Web 2.0“, die u.a. dadurch gekennzeichnet sind, dass sie es Nutzern ermöglichen, eigene Beiträge im Internet persistent zu veröffentlichen. Hierzu zählen Foren und Expertenblogs, in denen Softwareentwickler Fachwissen nicht nur konsu­mieren, sondern dieses ihrerseits in der Rolle „Content Providing Consumers“, oder anders gesagt als sog. „Prosumer“ (vgl. Kalz & Klamma & Specht, 2008, S. 29ff) der online Community zuVerfügung stellen.

3.1 Besonderheiten der Online-Kommunikation

Claudia Bremer verweist in ihrer Arbeit auf Studien, die belegen, dass im cha­rakteristischen Nicht-Vorhandensein körpersprachlicher Hinweisreize textba­sierter Kommunikation, nicht unbedingt ein Nachteil zu sehen ist (Bremer, 2007, S. 5). So veranlasst beispielsweise der erhöhte Kommunikationsaufwand der Schriftform die Kommunikationsteilnehmer im Interesse einer zielführen­den und effizienten Verständigung zu einer präziseren und sachbezogeneren Ausdrucksweise als dies bei einem Face-to-Face Informationsaustausch der

Fall wäre. Dieser Umstand kommt der Fachkommunikation im Kontext der Softwareentwicklung zu Gute, da sich Informationsdichte und Effizienz von Verständigung in Bezug auf komplexe Sachzusammenhänge einerseits durch eine sorgfältig durchdachte Formulierung steigern lässt und sich andererseits, im Zuge der Bemühungen um eine schlüssige Problembeschreibung, Lösungs­ansätze bereits ergeben können. Zudem bleiben gespeicherte Textnachrichten als Referenz sowohl lokal, wie auch auf Mailservern dauerhaft verfügbar. Ins­besondere Softwareentwicklern bietet E-Mail die vorteilhafte Möglichkeit, Problemstellungen unter Bezugnahme auf beigefügte Codefragmente, Screens­hots und Kopien von Fehlermeldungen oder durch im Anhang der E-Mail ver­fügbare, lauffähige Funktionsprototypen und durch Links auf gemeinsam zu­gängliche online Ressourcen, lösungsorientiert zu besprechen. Dabei erweist sich auch die Asynchronizität von E-Mail als hilfreich, da für das Verständnis komplexer Zusammenhänge gewisse Zeitspannen erforderlich sind und vor der Beantwortung von Anfragen oftmals Recherchen durchgeführt werden müssen. Nachteile aus der E-Mail Kommunikation ergeben sich, wenn Problemstellun­gen durch eine Vielzahl von Kommunikationsinteraktionen mit mehreren Teil­nehmern und jeweils nur geringem Informationsgehalt gelöst werden müssen. In solchen Szenarien steigt der Aufwand der Kommunikationskoordination im Verhältnis zur Informationsvermittlung unverhältnismässig an (vgl. Rauten­strauch, 2008, S. 58f). Durch den Einsatz synchroner Medien, wie beispiels­weise durch computervermittelte Videokonferenzen, lassen sich derartige Kommunikationsaufgaben effizienter bewältigen, da die zusätzlichen audiovi­suellen Informationen und körpersprachlichen Signale, sowohl bei der Kom­munikationskoordination wie auch bei der Wahrnehmung von Kopräsenz der Interaktionspartner unterstützend wirken, wodurch die Erarbeitung einer ge­meinsamen Verständnisbasis, sowie Identifikation und Eingrenzung des ge­meinsamen Problemraumes erleichtert wird (ebd., S. 55ff).

4 Lernprozesse agiler Softwareentwicklungsteams

So zentral und unverzichtbar Kommunikation für die agile Softwareentwick­lung auch ist, wäre die Schlussfolgerung, dass ein Bemühen um die perfekte Kommunikation der Weg zu erfolgreichen Softwareprojekten sei, dennoch falsch. Zielführend ist vielmehr die Einsicht, dass es auf Grund der eingangs beschriebenen Komplexität und Variabilität von Softwareentwicklungsprozes- sen, eine lückenlose Information und allumfassende Kommunikation vorab gar nicht geben kann. Der Schlüssel zum Erfolg liegt daher vielmehr in einer grundsätzlichen Lernbereitschaft, die dazu befähigt sich immer wieder neu auf die sich im Projektverlauf unvermeidlich wandelnde Aufgabenstellung und deren Rahmenbedingungen auszurichten und mit unvollkommener Kommuni­kation - und das heisst mit dem Umstand fehlender Information - umzugehen (vgl. Cockburn, 2000).

Die Begründer des „Agilen Manifests“ gehen daher soweit, Softwareentwick­lung per se als Lernprozess aufzufassen (vgl. ebd.). Im Kontext des Prozess­modells „Scrum“ werden Lernprozesse etwa als Reaktion auf das während ei­nes „Sprint-Reviews“ von den Interessensvertretern gegebene Feedback anges- tossen: Drückt ein Auftraggeber Unzufriedenheit in Bezug auf gewisse Eigen­schaften einer Softwarekomponente aus, kann dies von der Problemanalyse über die Beschäftigung mit alternativen Architekturmodellen bis zur Aneig­nung spezifischen Fachwissens - beispielweise zur Nutzung effizienterer Soft­waretechnologien - eine ganze Kette weitreichender Lernprozesse nach sich ziehen. Umgekehrt lernen Auftraggeber bei solchen Gelegenheiten auch die Grenzen und die Kosten des Machbaren kennen, was wiederum einen Einfluss auf künftige Formulierungen gewünschter Produktfeatures hat. Bezogen auf den jeweils spezifischen Projektrahmen, lernen Teams ihre Aufwandschätzun­gen von Iteration zu Iteration, immer wieder neu zu präzisieren. Softwareent­wickler lernen voneinander, insbesondere während gemeinsamer „Code­Reviews“, die während eines laufenden „Sprints“ jederzeit und von jedem Teammitglied einberufen werden können. Hierbei geht es um die gemein­schaftliche Prüfung und Optimierung von Code mit Blick auf dessen qualitati­ve Eigenschaften, wie Performanz und Lesbarkeit oder dessen Ausrichtung an Guidelines und „Best Practices“. Indem Lösungsansätze problematisiert und das Wissen um den optimalen Ansatz, unter Einbezug multipler Perspektiven gemeinschaftlich erarbeitet wird, findet der Lernprozess in diesem Szenario diskursiv statt (vgl. Rautenstrauch, 2008, S. 7ff). Im Rahmen der „Sprint­Retrospektive“ geht es darum, die Zusammenarbeit der Teams zu optimieren und sowohl personelle wie organisatorische Hindernisse zu überwinden. In einer Atmosphäre des gegenseitigen Respekts sollen hier Probleme offen und konstruktiv angesprochen werden können, um wiederum auf der Basis der grundlegenden Lembereitschaft auch in sozialen Belangen, Verbesserungen für den nächsten „Sprint“ herbei zu fuhren (vgl. Wolf & Bleek, 2011, S. 12).

5 Lernmethoden im Kontext der agilen Softwareentwicklung 5.1 Bestandsaufnahme

Folgende drei Paradoxien der allgemeinen Berufsbildung (vgl. Geissler & Kutscha, 1992), treffen insbesondere auch auf das Berufsfeld des Softwareen­gineerings zu:

1. Der Berufsbildungsabschluss entlässt die Absolventen in eine Realität des lebenslangen Lernens und der Weiterbildung. Das Ende des forma­len Bildungsprogramms ist der Beginn eines neuen, eigenverantwortli­chen Lernprozesses der von den Anforderungen des Marktes gesteuert und angetrieben wird.
2. Die „Halbwertzeit“ von Lerninhalten und damit die Zeitspannen zwi­schen Qualifikation und Entwertung von Qualfiktion bezogen auf deren berufliche Verwertbarkeit verkürzen sich zunehmend. Daraus lässt sich implizit ableiten, dass Lernen zu einem Teil auch als ein Verlernen überholter Inhalte aufgefasst werden muss.
3. Weiterbildung im Beruf in Form von formalen Kursen und Trainings stellen unproduktive Pausen im Arbeitsprozess dar, die mit Blick auf die beschleunigte Entwertung von Wissen, tendenziell immer weniger gern in Kauf genommen werden. Folge dieser Entwicklung, ist eine Be­rufspraxis in der immer kürzer werdende, selbst organisierte Lernpha­sen mit Phasen beruflicher Produktivität und Freizeit verschmelzen. Geissler & Kutscha nehmen diese Entwicklungen zum Anlass, die Möglichkeiten einer „Kurzzeitpädagogik“ zu untersuchen (ebd., S. 23).

Nach Thomas Eibl besteht im Zuge der „digitalen Revolution“ für viele Nutzer von Informationstechnologie verschiedenster Berufsgruppen die Notwendig­keit sich periodisch - meist mit dem Erscheinen neuer Versionen ihrer Softwa­retools - in deren neue Programmfeatures einzuarbeiten und an entsprechenden Schulungen und Trainings teilzunehmen (vgl. Eibl, 2007, S. 126). Diese Not­wendigkeit besteht auch für die Produzenten von Software selbst.

[...]