Kommentierte Links
Einer dieser Fälle bei denen klar wird welche weitreichenden Folgen es haben kann, wenn bei der Qualitätssicherung von Software etwas übersehen wird. Gleichzeitig aber auch eine Erinnerung daran, wo heute überall Software drinsteckt (an praktisch jeder Stelle). Ein Flugzeug ist heute nicht mehr bloß eine fliegende Maschine sondern auch ein fliegender Computer (bzw. eine fliegender Schwarm miteinander vernetzter Computer und Maschinen).
Boris Gloger schreibt, dass Kay Grebenstein meint, dass alle Aufgaben eines Testmanagers in Scrum genau so gut von dem Entwicklungsteam wahrgenommen werden können. Der Artikel enthält auch ein schönes Mapping von ISTQB-Testmanager-Aufgaben mit den Aufgaben eines Scrumteams, wodurch tatsächlich alle Testmanagement-Tätigkeiten abgedeckt werden. Ich glaube ja, dass da ein entscheidender Punkt fehlt, nämlich der, dass ein Testmanager in Scrum andere Aufgaben haben sollte (vereinfacht gesagt eine Art Scrum Master für die Tester der Teams). Aber vielleicht hat Gloger das auch einfach nicht erwähnt, er schreibt selbst, dass er einiges weggelassen hat.
Ein Thema das mir in letzter Zeit mehrfach untergekomen ist (u.a. in Gesprächen auf der Arbeit, in diesem Blog, auf dem
Scrumtisch Essen). Bei manchen Scrum Mastern kann sich mit der Zeit ein verstecktes Minderwertigkeitsgefühl ausbreiten, weil ihnen das technische Verständnis für die Arbeit ihres Teams fehlt. Wie Watts es ausdrückt:
"I was not a technical person, yet I was project managing a technical project full of technical people." Tatsächlich wären viele Scrum Master nicht in der Lage mitzuprogrammieren, entweder weil sie aus dem Projektmanager-Bereich kommen oder weil sie zwar mal Programmierer waren, aber seit langem aus der Übung sind. Ich halte das nicht für schlimm, wir leben nun mal in einer arbeitsteiligen Gesellschaft. Und auch unter den Entwicklern gibt es ja Spezialisierungen die dazu führen, dass nicht mehr alle überall mitarbeiten können.
Anik Subhan von Lean Software Delivery hat recht wenn er schreibt, dass in seiner Firma Estimations nicht funktionieren. Das liegt aber nicht daran, dass Estimations schlecht sind, sondern daran dass sie dort falsch durchgeführt wurden. Es wurde nämlich nicht die Komplexität sondern der Zeitaufwand geschätzt, was man in Scrum grundsätzlich nicht tun sollte. In Folge dessen sind genau die Probleme aufgetreten die zu erwarten waren: Unrealistische Planungen, falsche Erwartungen, Hektik bei zeitlichem Verzug. Die Lösung die man dort gefunden hat halte ich allerdings ebenfalls für wirr: Man hat angefangen Timeboxing einzuführen (für bestimmte Arbeiten steht nur eine bestimmte Zeit zur Verfügung). Abgesehen davon, dass man auch dafür Zeitschätzungen braucht - was passiert wenn die Zeit um ist aber die Arbeit noch nicht fertig - hört man dann einfach auf?
Eine bessere Idee hatte ich
vor drei Wochen aufgeschrieben.
