Teamarbeit bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #188

Um Teamarbeit bei der Softwareentwicklung geht es im Interview mit Christian Kranert in der einhundertachtundachzigsten Episode des IT-Berufe-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

Vorstellung Christian Kranert

Christian hat sich schon in Episode 164 des Podcasts über Softwarequalität ausführlich vorgestellt, aber hier noch einmal die wichtigsten Eckdaten.

  • Christian Kranert
  • seit 17 Jahren in der IT und Softwareentwicklung tätig
  • angefangen mit Visual Basic 6 auf Windows 95
  • Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert
  • viel im SAP-Umfeld mit ABAP entwickelt
  • inzwischen hauptsächlich mit C# unterwegs
  • lebt und arbeitet in Nürnberg bei Head On Solutions GmbH
  • entwickelt dort Cloud-Software für lokale Geschäfte wie Friseur-Studios zum Planen von Terminen, Kassieren, Buchhaltung usw.
  • ist Abteilungsleiter mit eigenem Team

Teamarbeit in der Softwareentwicklung

Warum brauchen wir Teamarbeit bei der Softwareentwicklung?

  • bei der Komplexität heutiger Software ist es fast undenkbar, diese alleine zu entwickeln
  • heutige Webanwendungen enthalten z.B. sehr viel UI-Entwicklung und sind im Backend und Frontend sehr komplex, Stichwort: Full Stack
  • Christians Unternehmen hat ein eigenes Team ausgelagert nur für VueJS im Frontend
  • durch das Team entsteht auch bessere Software
  • wir wollen doch die „echte Welt“ übersetzen in Code und dort gibt es auch mehr als einen Benutzer
  • gemeinsam zu entwickeln macht mehr Spaß, ist sozial, man kann voneinander lernen, man kann sich weiterentwickeln
  • die interdisziplinäre Zusammenarbeit mit dem Fachbereich bzw. Kunden ist auch extrem wichtig

Wie sieht erfolgreiche interdisziplinäre Zusammenarbeiten zwischen dem IT-/Entwicklungs-Team und anderen Abteilungen aus?

  • der Fachbereich erklärt den Entwickler:innen die Fachlichkeit
  • Entwickler:innen dürfen/müssen das aber auch hinterfragen und ggfs. bessere Lösungen vorschlagen
  • man sollte erst über das Problem reden und nicht schon über Lösung
  • es muss die generelle Bereitschaft zur Teamarbeit vorhanden sein und eine entsprechende Kultur

Welche Prozessmodelle (z.B. Wasserfall, Scrum) unterstützen/behindern die Teamarbeit?

  • das klassische Wasserfallmodell ist eher hierarchisch aufgebaut mit Lasten-/Pflichtenheft und passt nicht so gut zur Teamarbeit
  • Scrum ist aber auch kein Allheilmittel
  • das Daily ist sehr wichtig, denn Kommunikation ist der Schlüssel zu erfolgreicher Teamarbeit

Wie sieht richtig gute Teamarbeit in der Softwareentwicklung aus?

  • Kommunikation ist das A und O, z.B. wenn ein Feature fertig ist, damit die Kolleg:innen darauf aufsetzen können
  • alle Teammitglieder:innen sollten auch aktiv Hilfe anbieten und einfordern
  • die gesamte Softwareentwicklung ist Teamarbeit und die geht schon mit der Produktidee los
  • dabei kann es helfen, verschiedene Perspektiven einzunehmen, um ein besseres Bild der Anforderungen zu bekommen
  • auch weitere Aufgaben lassen sich besser im Team lösen: Risiken abschätzen, Prioritäten ableiten, Product Backlog füllen
  • wenn das Verhältnis von Kosten und Nutzen passt, startet die Implementierung und Aufgaben werden im Team verteilt
  • in Christians Team werden Konzepte z.B. gemeinsam erarbeitet, ganz einfach in OneNote*
  • das Team startet mit einem Datenmodell als Diskussionsgrundlage und legt dann die Datentypen fest
  • außerdem werden Mockups erstellt, um darüber gemeinsam zu diskutieren
  • sehr wichtig ist auch das gemeinsame Festlegen von Namen im Team, denn viele Köpfe haben mehr (fachliches) Wissen als einer alleine
  • der große Vorteil bei dieser Vorgehensweise ist, dass früh erkannte Fehler bei Anpassungen wenig kosten im Vergleich zu späteren Projektphasen, wenn alles schon umgesetzt ist

Warum ist die Teamkultur nicht nur beim Code Review wichtig und wie sieht sie aus?

  • Christians Team entwickelt oft im Pair Programming zusammen und führt danach noch Code Reviews durch
  • hier war oft insb. beim Testen die Einstellung, dass das doch jemand anders macht und nicht die Aufgabe der Softwareentwickler:innen sei
  • aber gerade beim Testen ist die Abstimmung mit den Tester:innen wichtig, damit man nicht den kompletten Code umschreiben muss, wenn man am Test vorbei entwickelt hat

Wie stellt man sicher, dass alle Teammitglieder:innen sich aktiv einbringen und wie kann eine Führungskraft Teamarbeit fördern/behindern?

  • die Führungskraft ist sehr wichtig, denn ihre zentrale Aufgabe ist die Pflege der Teamkultur
  • die häufig anzutreffene Skepsis bei Entwickler:innen gegenüber Meetings muss von der Führungskraft abgebaut werden
  • Meetings müssen aber natürlich auch einen Mehrwert für alle Teilnehmer:innen bieten und müssen vernünftig geplant und vorbereitet werden
  • auch für Entwickler:innen sind Meetings wichtig, da sie helfen, offene Fragen zu klären und Entscheidungen herbeizuführen
  • Teamarbeit kann die Teammitglieder:innen motivieren, wenn man gemeinsam eine gute Lösung findet und z.B. eine „harte Nuss“ knackt

Braucht ein Team eine Leitung?

  • das kommt stark auf das Team an

Storming, Forming, Norming, Performing: gibt es das wirklich in der Praxis?

  • Christian hat das mal in einem Buch gelesen, aber nur dunkel in Erinnerung
  • in der Praxis durchlaufen die Teams diese Phasen wohl tatsächlich, aber intuitiv verhalten sich die Mitglieder:innen meist den Phasen entsprechend

Wie sieht häufig die (negative) Realität in Sachen Teamarbeit aus bzw. an welchen Fehlern scheitert Teamarbeit häufig?

  • Juniors werden vernachlässigt und bekommen keine oder zu wenig Unterstützung
  • Hierarchiedenken, gerade wenn Softwareentwicklung nicht das Kerngeschäft des Unternehmens ist
  • Introvertiertheit der Teammitglieder:innen
  • aber auch Extrovertiertheit bzw. Egozentrik bei Teammitglieder:innen
  • Mangel an Diversität im Team

Wie wird man als Entwickler:in „teamfähig“?

  • Persönlichkeitsentwicklung! dazu gibt es viele gute Bücher
  • eine fördernde und fordernde Führungskraft ist wichtig für das Empowerment der Teammitglieder:innen
  • die Führungskraft sollte z.B. One-on-Ones mit Mitarbeitenden führen, immer wieder nachfragen und auch die eigene Entwicklung aufzeigen
  • loben und wertschätzen sollten bei jeder Führungskraft dazu gehören
  • Empathie ist auch wichtig
  • Konflikte sollten schnell gelöst werden

Wie wichtig ist eine gute Fehlerkultur?

  • sehr wichtig
  • Fehler müssen erlaubt sein und dürfen nicht „geahndet“ werden
  • aber was ist eigentlich ein Fehler? Schludrigkeit ist sicherlich kein Fehler
  • Checklisten können helfen, eine gewisse Basisqualität sicherzustellen

Wie können schon Azubis in die Teamarbeit integriert werden?

  • einfach mal loslegen und sie an die Hand nehmen
  • Azubis direkt in echte Projekte einbinden, aber ohne harten Deadlines oder großes Fehlerpotential
  • viel loben
  • Checklisten helfen auch hier beim Einstieg

Was sind die Folgen, wenn nicht im Team gearbeitet wird?

  • Christian hat noch nie jemanden kennengelernt, der/die sich aktiv gewehrt hat gegen Teamarbeit
  • eher haben die Kolleg:innen evtl. Angst mitzumachen
  • den berühmten „10x-Develover“ gibt es nicht, aber Seniors können als Multiplikatoren im Team wirken und Juniors voranbringen und damit das gesamte Team

Wie/wo kann man dich erreichen?

Links

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax