Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

|
//

Agile Testing Days – Keynote mit Stuart Reid – Investing in individuals and interactions

13.10.2009 | 5 Minuten Lesezeit

Die Key Note startet mit dem recht bekannten „Chicken & Pigs“ Beispiel. Dabei sind die Pigs, die sich dem Projekt absolut verpflichtet fühlen – alle anderen sind Chickens. Mit einem Blick auf den Titel der Session es wird sich viel um das Tehma der benötigten Fähigkeiten und Motivation drehen. Klingt vielversprechend 🙂

Was zeichnet agile Teams aus?
Sie haben die Befugnisse Entscheidungen zu treffen, organisieren sich von Innen, teilen die Verantwortung und (interessanterweise!) können zwei Mitglieder des Teams bereits Änderungen am Produkt, dem Prozess oder den Tests vornehmen. Dies bestätigt die Aussage von Borig Gloger, dass jedes Teammitglied fähig sein sollte 90% der benötigten Arbeiten auszuführen, aber hier sollten zwei Mitglieder des Teams bereits 100% aller Tätigkeiten ausführen können. (Ich muss unbedingt unseren Mathematiker Dr. Snatzke fragen, wie die Fähigkeiten im Team verteilt sein müssen, um dies beide Aussagen zur selben Zeit zu erfüllen.) Reid führt aus, dass es zwei Mitglieder braucht, um sich auf eine Änderung zu einigen. Ich nehme mal an, dass dann diese zwei auch die eigentlichen Änderungen durchführen können.

Stimmt es dan agile Teams hochmotiviert sind, extrem gut ausgebildet sind und übergreifend arbeiten? Im Prinzip die Leute in agilen und traditionellen Teams sind dieselben. Mit einer Skill-Matrix lässt sich visualisieren welche Fähigkeiten im Team fehlen, in diesem Beispiel Datenbankexperten und Experten für den Handel mit Anleihen.

Welche Fähigkeiten dinden sich in einer solchen Matrix? Wir unterscheiden zwischen speziellem/langfristigem Wissen (Testen, Datenbanken) und allgemeinerem/kurzfristigerem Wissen (Java, Swing, FitNesse, Anleihenhandel). Hat man z.B. einmal die Grundlagen des Programmierens verstanden, ist es nicht so schwer von einer Programmiersprache auf eine andere zu wechseln. D.h. in agilen Teams ist es wirklich wichtig das Spezialwissen zu haben.

Allgemeine Fähigkeiten sind projektspezifisch und können schneller erlernt werden.

Fähigkeiten lassen sich wie folgt kategorisieren:

  • Development: Design, Programmierung, Build, Integration, Testing, Technisch (Middleware, Database)
  • Management: Planen, Durchsetzen des Prozesses, Konflikte managen/auflösen
  • Customer / User: Requirements (Stories), Akkzeptanz-Tests, Domain-Wissen, Geschäftslogik, Kundendokumentation
  • All diese überlappen sich in einigen Bereichen.
  • Dies wir unterstützt durch Zusammenarbeit und Kommunikation.

Wo befinden sich diese Fähigkeiten in meiner Organisation? Wir haben Management und agile Teams, aber es muss auch einen Platz geben für Expertenwissen (z.B. Sicherheit). Es ist auch offensichtlich, das wir auch Testexperten ausserhalb des Teams brauchen. Dies erinnert mich sehr stark an unsere aktuelle Organisationsstruktur bei codecentric mit agilen Teams und Compentence Centers (eins davon mit Agilität und Agilem Testen als Schwerpunkt).

Die benötigten Test-Skills in einem Team sind vergleichbar in agilen und traditionellen Teams: Test Design, Exploratives Testing, Test-Werkzeuge, TDD, usw.

Wie sind dies Fähigkeiten auf die Rollen verteilt? Es mag immer noch funktionieren, wenn Du in einem Team nur Entwickler hast, da diese oft auch die anderen Rollen ausfüllen können. Schwierig wird es aber in einem Team, welches z.B. nur aus Testern und Analysten besteht (persönlicher Kommentar: Gibt es wirklich solche Teams?!).

  • Management: SCrum Master, Lead Engineer
  • Development: Designer, Programmer, Tester
  • Customer: Analyst, Tester

Testers können nicht immer programmieren (sagt Reid), daher mag ein Team aus Testern funktionieren oder auch nicht, abhängig vom Hintergrund der Tester. Was passiert, wenn es keinen Scrum Master gibt, da es einen Projektmanager gibt, der dem Team nicht vertraut? Laut Reid ist ein Teammitglied, das „cross-functional“ arbeiten kann eher ein Mythos, aber für ihn eine große Vision auf die es sich lohnt hin zu arbeiten.

Welche Begabung (nicht Fähigkeit) braucht ein Scrum Team? Man sollte mit zumindest zwei oder drei Teammitgliedern starten, die bereits Wissen und Erfahrung in agilen Methoden haben, um ihr Wissen an das Team weiterzugeben. Es wird ein guter Mix benötigt zwischen Erfahrungen und Fähigkeiten. In agilen Teams die passenden Aufgaben werden automatisch der passenden Person zugeordnet werden (self-optimization). Agile Teams werden „nice but dim“ Teammitglieder automatisch vor dem Management „verstecken“, aber Teams werden es nicht tolerieren, wenn es Leute gibt, die clever aber egoistisch sind. Am Ende kann sich niemand vor den anderen „Pigs“ in einem agilen Team verstecken, im Gegensatz zu traditionellen Teams.

Wie sind Scrum-Teams organisiert? Definitiv nicht hierarchisch, aber z.B. in „Pairs“. Dabei gibt es die Rollen des „Fahrers“ und des „Navigators“. Der Fahrer lernt und ist derjenige der an der Tastatur sitzt, wohingegen der Navigator mehr Erfahrung hat und versucht sein Wissen zu vermitteln. Eine anderes Modell ist Mentor/Schüler (z.B. Dumbledore/Harry). Beispiele für „Pairs“ sind: Analyst/Tester, Tester/Entwickler, Analyst/Entwickler. Dabei empfiehlt Reid die Paare nur dann zu rotieren, wenn es dafür einen wirklich guten Grund gibt, weil bestimmtes Wissen gebraucht wird. Ansonsten arbeiten am Ende ggf. Leute zusammen, bei denen die Chemie nicht stimmt. Ich bin mir nicht sicher, ob ich hier wirklich zustimme, denn das Team sollte so aufgesetzt werden, dass jeder mit jedem arbeiten kann, es ist nicht genug nur auf die Fähigkeiten zu schauen.

Was sollte man tun, wenn eine Fähigkeit im Team benötigt wird, aber nicht vorhanden ist? Einige Ideen: Neue Mitarbeiter, Contractor Training, Coaching. Teams sollten die Möglichkeit haben dies selbstständig zu lösen. Es sollten keine Contractor langfristig im Team gehalten werden, sondern durch eigene Mitarbeiter ersetzt werden, sobald die entsprechenden Kompetenzen transferiert wurden. Geschieht dies nicht, sind diese Contractor teurer als eigene Mitarbeiter, da sie lediglich die gleiche Arbeit tun, aber kein weiteres Wissen mehr vermitteln können.

Es folgt eine schnelle Umfrage we ISTQB -zertifiziert ist – recht viele Konferenzteilnehmer sind sogar auf „Advanced

Wie können die Teammitglieder motiviert werden? Sicherlich nicht durch die Bezahlung (so wahr!). Motivation kommt durch das passende Design des Jobs, z.B. unter Berücksichtigung der Faktoren, die in Motivational Potential Score identifiziert wurden. Jeder Wert unter 60 sollte nicht von einem Menschen ausgeführt werden. Was sind dann die wirklich motivierenden Jobs im Testumfeld? Es zeigt sich, dass die Werte in agilen Teams generell höher sind mit der Ausnahme der Analysten, die ihre Rolle extrem wichtig nehmen in traditionellen Projekten und are nun „nur“ Teil eines Teams. Die Verbesserung des Wertes liegt bei ca. 25%. (Ich werde demnächst noch mehr über Motivation und Scrum bloggen, also stay tuned).

Reid schliesst mit der Schlussfolgerung, dass es sich gut anfühlt in einem agilen Team/Projekt zu arbeiten. Dem kann ich mich nur von ganzem Herzen anschliessen.

|

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.