Der Faktor Mensch in der Software-Entwicklung

Der Faktor Mensch in der

Software-Entwicklung

Von Arno Hütter

2 / 23

Führen von SW-Entwicklungsteams / Der Faktor Mensch

“Die Hauptprobleme unseres Fachgebiets sind nicht so sehr technologischer, als vielmehr soziologischer Natur.“

(DeMarco, Lister in: „Peopleware“)

3 / 23


Eckpfeiler des Führungsverhaltens (1)

§ “Leadership, like software, is built upon a foundation. For software, the foundation is the architecture. For leadership, it‘s your character.“ [4]

§ Verstehen: Kampf um Marktanteile wird durch Führungspersönlichkeiten gewonnen, die Natur und Methoden der Softwareentwicklung genauso kennen wie die Anforderungen ihrer Kunden. “See the forest and the trees” [4].

§ Kommunizieren: “Evangelist” sein, Begeisterung vermitteln, Wissen weitergeben. Gute Kommunikatoren sind auch gute Lehrer. Vorsicht bei unvorbereiteten, beiläufigen Bemerkungen.

§ Delegieren: Die richtigen Leute für die richtigen Aufgaben auswählen. “You can delegate tasks, but not speed” [4]. Eine effektive Form der Delegation: Senior/Junior Pair Programming.

4 / 23


Eckpfeiler des Führungsverhaltens (2)

§ Inspektion: “Keine Erwartung ohne Kontrolle” [4]. Daily Builds. Automatisierte Tests. Feedback von Mitarbeitern einholen. Codeüberprüfung. Wöchentliche Projektstatusmeetings. Vier-Augen Prinzip. Dokumentation.

§ Mitwirken: Mitarbeit der Führungskräfte auch bei Programmierung und bei Tests (zeitlich begrenzt). Die besten Führungskräfte sind nicht nur Trainer an der Seitenlinie, sondern auch Mitspieler. Wichtiges Signal für Mitarbeiter.

5 / 23


Führungsaktivitäten

§ Mentoring: Problemlösungskompetenz der Mitarbeiter erhöhen. Zukünftige Führungspersönlichkeiten heranbilden. Multiplikatorwirkung für die eigenen Bemühungen. Wille zur Wissensweitergabe ist nötig.

§ Belohnen: Honorierung außerordentlicher Leistungen. Faire, leistungsgerechte und zeitgemäße Vergabe. Verschiedenste Formen möglich (finanzieller Bonus, Abendessen, Eintrittskarten, etc).

§ Korrigieren: Schlampigen Code und inadäquate Lösungen verhindern. Code Reviews. Form der Behebung vorschlagen, bei der Umsetzung unterstützen, Lerneffekt erzielen. Keine Schuldzuweisungen, aber problematische Mitarbeiter erkennen und ggfs. ersetzen. Vorbild sein -eigene Nachlässigkeit beschädigt allgemeines Qualitätsbewusstsein.

§ Vorhersehen: Über das Tagesgeschäft hinausblicken, ein Bild der Zukunft erschaffen und damit Mitarbeiter inspirieren und motivieren.

§ Anpassen: Verhaltensweisen an die jeweiligen Problemstellungen adaptieren, Herausforderungen annehmen, neue Fähigkeiten aneignen. Kein Festhalten an starren Vorgaben.

6 / 23


Gefolgsleute gewinnen

§ Pflichtbewusststein: Loyalität zu Team und Produkt. Lässt sich z.B. durch “Stolz auf das bisher Erreichte” steigern. Teil einer Sieger-Mannschaft sein.

§ Bewunderung: Menschen folgen Persönlichkeiten, die sie respektieren oder sogar bewundern. Konsistenz in Managementstil, Führungseffektivität und der richtige Umgang mit den Mitarbeitern.

§ Belohnung: Den Mitarbeitern ein Arbeitsumfeld schaffen, das allein für sich schon eine Belohnung ist.

§ Wissen: Wissen ist Macht, speziell in der SW-Entwicklung. Experte sein und bleiben, Wissen teilen. Mitarbeiter die davon profitieren werden somit zu Gefolgsleuten.

§ Andere Kräfte: Markt- und Konkurrenzsituation, Bezahlung. Normalerweise alleine nichtausreichend, aber ein Anfang.

7 / 23


Kategorien von SW-Entwicklern („The Good“)

§ Der Architekt: Befasst sich mit Gesamtstruktur von Systemen, Problemlösung durch Abstraktion. Gefahr: Konnex zu den “Umsetzern” und deren Bedürfnissen kann verlorengehen.

§ Der Konstrukteur: Arbeitet intuitiv, Probleme werden durch Code gelöst. Gefahr: Dokumentation kann zu kurz kommen.

§ Der Künstler: Gestalterisches Arbeiten im Vordergrund, aus Anforderungen SW-Konstrukte und intuitive Benutzerschnittstellen bauen. Gefahr: Ineffizienz und fehlendes Design.

§ Der Ingenieur: Entschärft Komplexität durch Zielreduktion. Gefahr: Mangelnde Flexibilität bei geänderten Anforderungen.

§ Der Wissenschaftler: Problemlösung gem. den Grundprinzipien der theoretischen Informatik, Puristen. Gefahr: Unpraktikable Lösungen.

§ Der Geschwindigkeitsdämon: Rasche Umsetzung, Einhaltung des Zeitplans um jeden Preis. Gefahr: Versteckte Fehler.

8 / 23


Kategorien von SW-Entwicklern („The Bad“)

§ Der Schlampige: Umsetzung schlampig, fehlerhafter Code, mangelhafte Struktur, Verletzung von Kodierkonventionen, keine Tests.

§ Der Eingeschüchterte: Keine Eigeninitiative, weiß nicht wie zu beginnen ist, kann mit unvollständigen Informationen nicht umgehen.

§ Der Amateur: Mangelnde Ausbildung und Erfahrung, Überschätzung der eigenen Fähigkeiten.

§ Der Ignorant: Verschlossen gegenüber technologischen Neuerungen, verweigert Fortbildung oder Änderung der Arbeitsweise.

§ Der Salatkoch: Schlecht proportionierte Mischung aus Ingenieur, Schlampigem und untalentiertem Künstler.

9 / 23


Erfolgreiche Entwicklungsteams

§ Qualität zum Kult machen: Qualitätsbewusstsein ist ein starker Teambildungs-Katalysator, weil dieses gemeinsame Ziel verbindend wirkt. Funktioniert nur bei unternehmerisch-langfristiger Denkweise.

§ Ein Hauch von Elitedenken: Menschen brauchen das Gefühl, in gewisser Weise einzigartig zu sein. Aufgestülpte unternehmensweite Einheitlichkeit wird auf Managementebene oft als wünschenswert betrachtet, wirkt hier aber mitunter kontraproduktiv.

§ Heterogenität zulassen und unterstützen: Signalwirkung: Es ist OK kein „Corporate Clone“ zu sein. Wertvolle Ergänzung, z.B. Frauen in ansonsten Männer-dominierten Entwicklungsteams.

§ Erfolgreiche Teams zusammenhalten und beschützen: Nach erfolgreichem Projektabschluss Momentum für das nächste Projekt mitnehmen.

§ Marschrichtung auf strategischer Ebene vorgeben, nicht auf operativer: Schlüssel-Mitarbeiter identifizieren und mit entsprechenden Freiheiten ausstatten. „Flow of free electrons“[1].

10 / 23


Entwicklungsteams / Zerstörerische Kräfte

§ Defensives Management: Entscheidungsfindung ohne Rücksprache mit den Mitarbeitern, fehlendes Vertrauen.

§ Bürokratie: Sinnloses Produzieren von Papier, eigentliche Arbeit kommt zu kurz.

§ Physische Trennung: Verteilung des Projektteams. Telefon statt direkter Interaktion.

§ Fragmentierung der Arbeitszeit: Zuteilung zu mehreren Projekten.

§ Qualitätsverzicht: Argument der Kostenreduktion, geringe Identifikation der Mitarbeiter.

§ Künstliche Endtermine: Werden mit großer Wahrscheinlichkeit ohnehin nicht ernst genommen.

§ Inspirationsslogans: Triumph der äußeren Form über die innere Substanz.

§ Ständige Überstunden: Kann nicht von jedem in gleichem Ausmaß mitgetragen werden.

11 / 23


Motivationsfaktoren für SW-Entwickler (1)

§ Zwei-Faktoren-Theorie (nach Frederick Herzberg): – Hygienefaktoren: Verhindern Entstehung von Unzufriedenheit, z.B. Einkommen, Sicherheit,

zwischenmenschliche Beziehungen.– Motivationsfaktoren: Motivation zur Leistung, z.B. Arbeitsinhalt, Anerkennung, Verantwortung.

§ Motivationsfaktoren sind von besonderer Bedeutung für SW-Entwickler, die sich voll und ganz mit ihrer Profession identifizieren. Üblicherweise sind das auch jene Mitarbeiter, die für eine erfolgreiche Abwicklung von SW-Projekte entscheidend sind.

§ Aufgestellt für den Erfolg: Viele Software-Projekte sind Fehlschläge, gute Entwickler scheitern nicht gerne und suchen daher nach einem erfolgversprechenden Umfeld. Professionelles Projektmanagement, kompetente Entwicklungspartner und Qualitätsbewusstsein sind daher besonders wichtig.

§ Exzellentes Management: Betrifft sowohl Projektmanagement als auch Personalführung. Kenntnis der Besonderheiten von SW-Projekten, rasche Entscheidungsprozesse, Verbundenheit den Mitarbeitern gegenüber – und man wird im Gegenzug vollen Arbeitseinsatz erhalten.

12 / 23



§ Abwechslung und ständiges Lernen: Hochqualifizierte SW-Entwickler haben sich ihre Profession mit hoher Wahrscheinlichkeit genau aus diesen Gründen ausgesucht.

§ Herausforderung Problemlösung: Programmierer lieben Herausforderungen. Nächtliche Kodier-Sitzungen bis ein Problem gelöst ist sind keine Seltenheit, auch wenn es nicht verlangt wurde oder extra vergütet wird. Unterforderung hingegen kann sich fatal auswirken.

§ Gehör finden: Entwickler sitzen - plakativ gesprochen - in den vorderen Schützengräben, und registrieren sich abzeichnende Probleme mitunter zuerst. Wenn sie sich dazu äußern (v.a. wenn mehrere Entwickler in ihrer Einschätzung übereinstimmen) sollte man ihnen zuhören.

§ Anerkennung: Ein erfolgreiches Produkt ist eine Hauptmotivation, die noch gesteigert werden kann wenn man dafür auch Anerkennung erntet.

13 / 23



§ An etwas teilhaben das einen Unterschied macht: Das ist auch bei Software-Produkten möglich, z.B. Entlastung der Anwender von manueller Routinearbeit, Effizienzsteigerungen, verbesserte Kommunikation, breiter Produkteinsatz. Negativ wirken sich hingegen sinnlos erscheinende Projektarbeiten aus.

§ Unbürokratische Entscheidungsfindung: Autorität zu eigener Entscheidungsfindung ohne jedes Mal ein eigenes Komitee einberufen zu müssen.

§ Umgang mit Altlasten: Mit der Wartung von qualitativ problematischen Altprodukten betraut zu sein, oder gravierende Einschränkung durch die Charakteristika bestehender Legacy-Systeme in Kauf nehmen zu müssen, wird hochqualifizierte SW-Entwickler auf Dauer nicht zufriedenstellen.

14 / 23


Mitarbeiterauswahl: Variabilität individueller Leistungsfähigkeit

§ “The most important practical finding involves the striking individual differences in programmerperformance” [2]

§ “Within a group of programmers, there may be an order of magnitude difference in capability” [2]

§ “A few good people are better than many less skilled people” [2]

§ “The best performers are clustering in some organizations, while the worst are clustering in others” [1]

§ Aber: Große Schwankungsbreite auch innerhalb einer Ausbildungsgruppe, z.B. unter Absolventen ein- und desselben Universitätsstudiums. Formale Qualifikationskriterien sind daher nicht ausreichend.

15 / 23


Mitarbeiterauswahl: „Smart & Gets Things Done“ [6]

16 / 23


Mitarbeiterauswahl: Interviewtechniken für SW-Entwickler

§ Mehrere Interview-Runden, darunter auch ein Test in praktischer Programmierung.

§ Keine Vorurteile (z.B. aufgrund formaler Ausbildung oder der Meinung anderer).

§ Einleitung: Vorstellung, Situation entspannen.

§ Offene Frage nach Projektarbeit des Kandidaten. Kann er komplexere Zusammenhänge einfach erklären? Ist er begeisterungsfähig? Hat er Schwierigkeiten aus eigener Initiative überwunden?

§ Lösung eines einfachen Programmierproblems: Spreu vom Weizen trennen. Wir schnell wurde das Problem gelöst, wie elegant?

§ Lösung eines schwierigen Programmierproblems: “Understanding pointers is not a skill, it’s an aptitude” [6]. Wichtiger als die Lösung ist der Lösungsweg. Diskussion entfachen.

§ Fragen des Bewerbers

17 / 23


Mitarbeiterauswahl: Und umgekehrt? „The Joel Test“ [6]

1. Do you use source control?2. Can you make a build in one step?3. Do you make daily builds?4. Do you have a bug database?5. Do you fix bugs before writing new code?6. Do you have an up-to-date schedule?7. Do you have a spec?8. Do programmers have quiet working conditions?9. Do you use the best tools money can buy?10. Do you have testers?11. Do new candidates write code during their interview?12. Do you do hallway usability testing?

18 / 23


Arbeitsumgebung und Produktivität (1)

19 / 23


Arbeitsumgebung und Produktivität (2)

§ Getrennte Büros statt „Cubicle Offices“: Zwei bis vier Personen je Büro. Ausreichend Platz. Bei der Planung sollten Menschen und ihre Bedürfnisse im Vordergrund stehen, nicht Verkabelungspläne oder dgl. Kosten der Arbeitsplatz-Ausstattung sind gering im Vergleich zu Personalkosten.

§ Gestaltungsfreiheit statt Uniformität: Menschen brauchen Individualität, auch am Arbeitsplatz (zumindest in gewissem Rahmen).

§ Ruhe, telefonfreie Zeiten, Unterbrechungen vermeiden: „You never get anything done aroundhere between 5 and 9“ [1].

§ Flow: Tief-Konzentriertes Arbeiten, höchste Effektivität (Hauch von Euphorie), erst nach einem gewissen Zeitraum des „Eintauchens“ in die Materie.

20 / 23


Software Craftsmanship (1)

§ Software-Entwicklung arbeitsintensiver als je zuvor

§ Menschen als teuerste Ressource

§ Steigende Nachfrage nach Software-Entwicklern– Gegenmaßnahme 1: Kurze Einschulungsprogramme: Fehlgeschlagen. Software-Entwicklung verlangt

mehr als die reine Kenntnis der Syntax einer Programmiersprache.– Gegenmaßnahme 2: CASE Tools: Fehlgeschlagen. Arbeits-, Modellierungs- und Codierweise wurden

den Entwicklern aufgezwungen. Code für viele Problemstellungen weiterhin das richtige Abstraktionsmodell.– De-Qualifikation und Industrialisierung sind die falschen Ansätze. Automatisierung ist sinnvoll, hat aber

Grenzen.

21 / 23


Software Craftsmanship (2)

§ Software-Entwicklung als „Handwerk“.

§ Gesamtheitliche Beherrschung eines Handwerks nur nach Jahren des Lernens und Praktizierens erreichbar.

§ Sobald Handwerk nicht mehr aktiv ausgeübt wird schwindet das Können.

§ Lehrzeit: Situatives Lernen. Selbständige Ausführung einfacher Aufgaben, komplexere Aufgaben unter Aufsicht des Lehrmeisters, Lernen „am Beispiel“.

22 / 23


Quellen (1)

§ [1] DeMarco, Lister: “Peopleware”

§ [2] Glass, Robert L.: “Facts and Fallacies of Software Engineering”

§ [3] McBreen, Pete: “Software Craftsmanship”

§ [4] Rainwater, J. Hank: “Herding Cats: A Primer for Programmers Who Lead Programmers”

§ [5] Spolsky, Joel: “Joel on Software”

§ [6] Spolsky, Joel: “Smart & Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent”

§ [7] Walling, Rob: "Nine Things Developers Want More Than Money“, http://www.softwarebyrob.com/articles/Nine_Things_Developers_Want_More_Than_Money.aspx

23 / 23


Quellen (2)

§ [8] Weinberg, Gerald M.: “Becoming a Technical Leader – An Organic Problem-Solving Approach”

§ [9] Weinberg, Gerald M.: “The Psychology of Computer Programming”

Documents

Der Faktor Mensch in der Software-Entwicklung