Verhaltensmerkmale eines agilen Entwicklers

Letzten Monat habe ich mir das Buch Lean Software Development von den Lean-Software-Gurus Mary und Tom Poppendieck angesehen und konnte die meisten, wenn nicht sogar alle Prinzipien mit unserer täglichen Arbeit bei Xebia in Verbindung bringen. Es wird wirklich interessant und macht Spaß, über etwas zu lesen, wenn man es bereits praktiziert. Dabei wird man in seinem Glauben an die Prinzipien bestärkt. Obwohl das Buch leicht zu verstehen war und die Beispiele leicht nachvollziehbar waren, konnte ich mir kein klares Bild von dem Begriff 'richtige Leute' machen, der an vielen Stellen im Buch erwähnt wird. Ich habe mich immer gefragt, welche Definition von 'richtig' in den Lean-Prinzipien verwendet wird. Mir ist klar, dass das Erkennen und Einstellen der richtigen Leute eine Entscheidung auf Organisationsebene ist, so dass die Agilen Prinzipien vielleicht nicht darüber sprechen. Außerdem sind es nicht nur agile Unternehmen, die nach den richtigen Mitarbeitern suchen. Das gilt auch für alle anderen nicht-agilen Organisationen. In einer Situation, in der es auf dem Arbeitsmarkt an guten Leuten mangelt, gehen Unternehmen manchmal eine Extra-Meile, um gute Kandidaten zu bekommen. Obwohl die Notwendigkeit, die richtigen Leute zu rekrutieren, universell ist, variiert die Definition von Organisation zu Organisation und von einer Rolle zur anderen. Die Verhaltensmerkmale für eine 'richtige' Person für andere 'Arten' von Industrien sind meist gut definiert und gut bekannt. Ich weiß zum Beispiel, welche Art von Menschen die NDA (National Defense Academy - Indien) sucht, oder welche Einstellung von einer Person erwartet wird, die für die Hotelbranche ausgewählt wird. Aber wenn wir über Agile sprechen, ist es immer noch vage, welche Einstellung bei einer Person dafür sorgt, dass sie gut oder schlecht in ein agiles Team passt. In seinem Artikel 'Der glänzende neue agile Architekt' beschreibt der Autor die Eigenschaften eines Agilen Architekten. Ich glaube, dass sich auch für einen agilen Entwickler einige Merkmale finden lassen.Nachdem ich nun etwa ein Jahr lang in agilen Projekten gearbeitet habe, möchte ich versuchen, eine Liste von Verhaltensmerkmalen zusammenzustellen, die meiner Meinung nach einen guten (potenziellen) agilen Entwickler ausmachen. Hier sind einige von ihnen:

• Inkrementell und adaptiv: Die Grundvoraussetzung für ein agiles Projekt und damit für seine Teammitglieder. Damit ein Softwareprojekt iterativ sein kann, sollten seine Mitarbeiter anpassungsfähig sein und sich ständig verbessern. Wenn eine Person nicht anpassungsfähig ist, würde sie immer zögern, mit einer Aufgabe zu beginnen, bis sie eine klare Vorstellung davon hat, wo sie enden soll. Und das ist bei agilen Projekten in der Regel nicht der Fall, da Sie zu Beginn einer Aufgabe möglicherweise noch kein klares Bild vom Ende haben. Ein anpassungsfähiger Mensch würde mit dem Maximum an Informationen beginnen (oder zumindest versuchen, damit zu beginnen) und dann schrittweise Änderungen vornehmen, indem er mehr und mehr Funktionen hinzufügt, sobald er mehr Informationen erhält.

• Proaktiv und Sinn für Eigenverantwortung: Das ist einer der größten Unterschiede, den ich beim Vergleich der Arbeitsweise in agilen und nicht-agilen Projekten festgestellt habe. Im Wasserfallmodell ist es der technische Leiter, der den Teammitgliedern Aufgaben zuweist, und er entscheidet auch, was und wem er welche Aufgaben zuweist. Um sein Leben noch komplizierter zu machen, wird ihm auch die Verantwortung für alle Aufgaben übertragen, und es gehört zu seinem Aufgabenprofil, den Überblick über die ausgeführten und abgeschlossenen Aufgaben zu behalten.
      In agilen Projekten jedoch holt sich ein Entwickler seine Aufgabe aus dem Sprint Backlog. Niemand, nicht einmal der Scrum-Master, hat ein Auge auf die Aufgaben, die andere erledigen. Es funktioniert nach dem Pull-System (auch bekannt als Kanban-System), bei dem Sie selbst eine Aufgabe aus dem Sprint ziehen und die vollständige Verantwortung dafür übernehmen. Dabei geht es nicht nur darum, die Aufgaben aus dem Sprint Backlog zu übernehmen, sondern auch andere Aufgaben wie die Erhöhung der Testabdeckung, das Refactoring von Code zur Vereinfachung des Designs, die Dokumentation usw. werden proaktiv erledigt. Niemand wartet auf irgendwelche Anweisungen von irgendjemandem, um solche Dinge in Angriff zu nehmen, was in einem nicht-agilen Projekt im Allgemeinen sehr ungewöhnlich ist.

• Mehrsprachig: Dies ist eine Ergänzung zu meinem 1. Punkt 'inkrementell und adaptiv'. Das grundlegende Merkmal der agilen Entwicklung ist, dass sie vom Kunden gesteuert wird. Je vielseitiger und funktionsübergreifender ein Team ist, desto besser ist es in der Lage, die sich ändernden Anforderungen des Kunden zu erfüllen. Abgesehen von den technischen Fähigkeiten muss ein Entwickler manchmal auch nicht-technische Aufgaben übernehmen. Er muss vielleicht mit den Endbenutzern sprechen, um ihr Feedback zu erfahren oder ihre Erfahrungen mit anderen Systemen zu verstehen, er muss mit den Testern auf Kundenseite zusammenarbeiten, er muss mit den Hardwareherstellern zusammenarbeiten, um die rechtzeitige Lieferung der benötigten Hardware sicherzustellen usw.

• Kommunikationsfähigkeit: Auch dieser Punkt kann mit dem^3. Punkt zusammengelegt werden, aber ich wollte ihn nur noch einmal betonen. Manch einer mag einwenden, dass gute Kommunikationsfähigkeiten auch in nicht-agilen Projekten benötigt werden, was ist also so besonders daran. Nun, um es klar zu sagen, sie wird in agilen Projekten mehr benötigt. Im Wasserfallmodell ist die Kommunikation mit dem Kunden eine sekundäre Fähigkeit, die ein Junior- oder Senior-Software-Ingenieur haben sollte, während sie für einen technischen Leiter oder Projektmanager ein Muss ist. Andererseits wird sie angesichts der flachen Hierarchie eines agilen Teams zu einer unverzichtbaren Fähigkeit für einen agilen Entwickler. Alle Aktivitäten, sowohl die Teamaktivitäten als auch die Kommunikation mit dem Kunden, erfordern von einem agilen Entwickler gute zwischenmenschliche Fähigkeiten. Zu den Teamaktivitäten gehören zum Beispiel tägliche Standups, Planungsmeetings, Retrospektiven und Designdiskussionen. Die Kommunikation mit dem Kunden besteht im Allgemeinen aus der Priorisierung des Backlogs, der Umwandlung eines Business Case in eine User Story und Ähnlichem.

Ich stimme zu, dass die obige Liste nicht erschöpfend ist und ich glaube, dass es noch viele andere Verhaltensmerkmale gibt, die man bei einem idealen agilen Entwickler finden kann. Ich freue mich über jeden Beitrag von Ihnen, der weitere Verhaltensmerkmale kennt, die man haben muss.