Anforderungsmanagement meets Software Test: Erfolgsfaktoren

von Alexander Weichselberger

… idealer geht’s kaum: Man sitzt mal da (Systemanalyse 1) und mal dort (Software Test) – und jetzt gilt es einen Artikel zu verfassen, der beide Disziplinen gegenüberstellt. Der geneigte Leser erwartet sich selbstredend – wie es der Artikeltitel ankündigt – Erfolgsfaktoren.

1 Systemanalyse, genau gesagt Systemanalyse 3.0 beinhaltet für mich Business Analyse (-> http://www.iiba.org/babok-guide.aspx), Requirements Engineering (-> https://www.ireb.org/de) und noch ein bisschen mehr

Ring

Quelle: SEQIS Software Testing GmbH

 

Mehr von diesem Beitrag lesen

Advertisements

Agile Projekte – potentiell gesünder als andere!

Passend zum Jahresstart kommen Vorsätze immer wieder gerne ins Gespräch: „Na, wie gehst du 2015 an? Was hast du dir vorgenommen?“ An dieser Stelle trennen sich die Feedbacks leider selten in Streu und Weizen. Üblicherweise erfährt man Begeisterung für eine Sache („Ich werde mehr Sport machen.“, „Ich werde endlich das Rauchen aufgeben.“) oder Resignation („Macht eh alles keinen Sinn – die Projektleitung plant ohnehin was sie will!“). Ob erstere Vorhaben wirklich nachhaltig sind, sieht man üblicherweise nach 3 Wochen bis 6 Monaten. Was gibt es über die „Macht-eh alles- keinen-Sinn“-Seite zu sagen? Die meisten Neujahrs-Vorsätze haben etwas mit Zeit zu tun – Zeit für sich (Sport, Ausbildung, Hobbies,…), Zeit für die Familie oder einfach weniger Stress im Sinne von weniger Arbeiten.

Lösen wir die Frage, wie wir besser mit unserer Zeit umgehen, so lösen wir diesen Knackpunkt und haben gute Aussichten auf ein wirklich gutes, neues Jahr!

Schauen wir uns also den Aspekt eines nachhaltigen Arbeitstempos an. Ein nachhaltiges Arbeitstempo für die IT entspricht mindestens folgenden Kriterien:

  1. Die 40h-Woche als Ausgangsbasis
  2. Gezielter Einsatz von Überstunden
  3. Vermeiden von Task-Switching und „schnell mal was einschieben“
  4. Verstehen, dass Softwareentwicklung kein Sprint, sondern ein Marathon ist. Die Teams müssen durch entsprechende Planungen geschützt werden

Die 40h-Woche für die Planung des Arbeitstempos/-umfangs sollte als Ausgangsbasis ausreichend sein. Dies entspricht u.a. auch der Forderung der agile Community im Jahre 2002. [Beck2000] Natürlich gibt es immer wieder Aussagen dazu, dass diese Arbeitseinstellung in Europa lächerlich wäre: „[…] erfolgreiche Unternehmer in China arbeiten 80 oder 100 Stunden pro Woche.“ [Meyer-2012] Diese Aussagen kommen zumeist von Personen, die auch wissen: „[…] Zugegeben: Auch ich sähe besser aus, wenn ich weniger arbeiten, mehr Sport treiben und mehr schlafen würde.“ [Meyer-2012] Wie weit man gehen will/kann, sollte jeder für sich selbst entscheiden. Für andere zu planen bedeutet jedoch Verantwortung zu übernehmen und darf nichts mit übertriebener Geltungssucht zu tun haben. Nachhaltiges Arbeitstempo bedeutet nicht, dass die Teams kontinuierlich auf gleichem Arbeitsniveau weiter arbeiten – kurz vor der Ziellinie muss auch mal, im wahrsten Sinnes des Wortes, ein Sprint hingelegt werden können. Werden für die eine Woche Überstunden angeordnet, sollten sie auf keinen Fall für die folgende Woche wieder angeordnet werden müssen.

Agile Prinzipien für Optimierungen: Gerade im agilen Methodenstack werden durch eine Reihe von Grundprinzipien Werkzeuge etabliert, die ernsthafte Optimierungen zulassen:

  • Pull, statt Push: Ich hole mir Arbeit, wenn ich wieder frei bin
  • Team-Commitment: Wir stimmen Zielen zu und laufen gemeinsam dafür
  • Eigenverantwortung im Team: Wir wissen, was wir wie können und machen müssen, damit der Plan, den wir kennen, halten kann
  • Forderung nach ausschließlicher Belastung der Teams mit Entwicklungen, die „Business-Value“ schaffen
  • Flexibel für späte/kurzfristige Änderungen durch „Late-Commitment“
  • Analyse und Reduktion von Engpässen (Retrospektiven)
  • Realisierung in Inkrementen – Reduktion von Skalierungsrisiken und die Möglichkeit, kontinuierlich zu lernen

Sonst liegt ein Problem vor, dass allgemein nicht durch Leisten von Überstunden zu lösen ist. [Beck/Andres-2004] Ein weiterer Irrglaube in der heutigen Be- und Auslastung von IT-Ressourcen liegt in der Überlegung, Personen mit vielen und oft unterschiedlichen Arbeiten gleichzeitig (!) zu belasten und dabei implizit Task-Switching zu verlangen. (Hintergrund der Überlegung: Durch „schnell mal was einschieben“ Ziele erreichen). Der Blick in John Medina’s Buch „Gehirn und Erfolg“ macht’s klar: Multitasking bedeutet 50% mehr Zeit bei 50% geringerer Qualität (im Sinne von mehr Fehler!). Die gleichen Basisüberlegungen finden wir auch bei flussbasierten Sys temen, wie z.B. Kanban, wieder. Dort spricht man von „Stop starting, start finishing“ und meint, dass Begonnenes zu beenden ist, bevor man etwas Neues beginnt. Natürlich durch sogenannte Work-in-Progress-Limits („WiP-Limit“) optimiert für die jeweilige Tätigkeit oder Person.

Verfolgt man David Andersons Suche nach dem nachhaltigen Arbeitstempo, so kommt bei ihm sehr rasch die Empfehlung, Teams vor „verrückten Zeitplänen und absurden Verpflichtungen“ zu schützen. Mehr Features oder weitere Produkte zu verlangen, obwohl die Entwicklungskapazität bereits voll ausgelastet ist, ist Unsinn. [Anderson-2012] 40h-Woche, überlegte Überstunden, Multitasking vermeiden und Teams vor Übermenschlichem schützen – ist das realistisch? Nun, ich meine ja. Wir müssen verstehen, dass ein 18-Monate Projekt mehr einem Marathon als einem 100m-Lauf entspricht. Ob und wie diese und andere (agile) Aspekte zum Wohl des Teams und zu ordentlicher Wirtschaftlichkeit im Projekt oder der Abteilung führen, hängt vom Willen zur (Prozess-) Optimierung, einem klaren methodischen Vorgehen zur Analyse der Situation und einem fundierten Change-Management der Organisationen ab.

Referenzen:

[Beck/Andres-2004] – Kent Beck, Cynthia Andres, „Extreme Programming Explained“, 2004

[MEYER-2012] – http://www.welt.de/finanzen/article13863020/Unsere-40-Stunden-Woche-in-Europa-ist-laecherlich.html, 17.1.2015, 07:55

[Anderson-2012] – David Anderson, „Kanban – Evolutionäres Change Management für IT-Organisationen“, 2012

Agile Testing Days 2011 – About testers and garbage men by Stefaan Luckermans

Credits gehen an DI Reinhard Salomon, der diesen Artikel verfasst hat:

Einen sehr interessanten Vortrag hielt Stefaan Luckermans: “About testers and garbage men”.

Schon sein Auftritt – er kam verkleidet als Oliver Hardy vom legendärem Komiker-Duo „Laurel und Hardy“ – erzeugte Neugier auf seine Ausführungen. Begleitet von alten Stummfilmen und  in Zusammenhang mit der Filmbranche brachte Stefaan auf diese unkonventionelle Art seine Überlegungen, wo im Testumfeld die Quellen von Verschwendung/Müll liegen. Auch japanische Klassifizierungen wurden herangezogen. DIe 7 Quellen von MUDA (=Verschwendung)  sind hier

Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Keynote: Five key challenges for agile testers tomorrow by Gojko Adzic

Am Vorabend wurde Gojko Adzic von der Community zum Ritter geschlagen. Als Erfinder der Specification by Example, Buchautor und wie wir erleben durften, hervorragender Vortragender ist er derzeit die Person, die das agile Testen am intensivsten beeinflusst und prägt, so das Votum der Community.

Das hat natürlich die Spannung vor seiner Keynote ebenfalls stark erhöht, der Titel mit der Frage der 5 wichtigsten Herausforderungen für agile Tester in den nächsten 5 Jahren ist natürlich auch sehr verheissungsvoll. Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Keynote: People and Patterns by Esther Derby

Esther Derby kommt aus dem Managementconsulting und das merkt man im Zuge ihrer Keynote. Sie hat sich ausführlich mit der Fragestellung der Schuldzuweisungen in agilen Teams beschäftigt und macht in ihrem Vortrag auf die Hintergründe aufmerksam.

Grundproblem ist: Systemprobleme werden meist Personen zugeordnet und Probleme mit Personen auf Systeme zurückgeführt.

Um dies aufzulösen und zu einem besseren agilen Team zu gelangen schlägt Esther vor die Strukturen herauszufinden, die die Dinge zusammenhalten. Dies kann z. B. gleiches technisches Wissen, gleiche Sprache, gleiche Rolle, etc. sein, in einem Team gibt es viele Gruppen, das Team ist eine übergeordnete Gruppe, quasi unsichtbare Strukturen. Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Keynote Appendix A: Lessons Learned since Agile Testing Was Published by Lisa Crispin & Janet Gregory

Lisa Crispin und Janet Gregory sind Vorreiter in der Publikation erster Arbeiten zum agilen Testen. Letztendlich haben die beiden das erste Buch zum Thema geschrieben und damit eine erste ausgereifte Diskussionsgrundlage vorgestellt.

Seit der Vorstellung des Buches sind nunmehr 2 Jahre vergangen, wie angekündigt haben die beiden dann abwechselnd ihre Lessons Learned zu unterschiedlichen Punkten vorgestellt.

Ein paar habe ich hier herausgepickt: Mehr von diesem Beitrag lesen

Agile Testing Days 2011 – Session Based Testing to Meet Agile Deadlines by Mason Womack

nicht ganz live, dieser Vortrag war schon gestern, aufgrund des interessanten Inhaltes hier die nachgereichte deutsche Zusammenfassung.

Mason Womack arbeitet bei ImmobilienScout24.de, eines der größten Immobilienportale Deutschlands, als Leiter der QA-Abteilung. Seit 2005 befindet sich das Team und damit auch das Testteam im agilen Wandel und den damit verbundenen Herausforderungen.

Interessant war der Zugang, den Mason zum Session Based Testing gefunden hat: bei den letzten Agile Testing Days hat er erstmals davon gehört und dann kam es zu einer schwierigen Situation, bei der sehr kurzfristig eine Änderung im Coresystem der ImmobilienScout24-Anwendung vorgenommen werden musste. Die Änderung erfolgte im Sessionhandling, was für ein komplexes Portal wirklich mission critical ist. Leider musste der Fix innerhalb kürzester Zeit rausgehen, wodurch nur sehr kurze Zeit zur Verfügung stand. An diesem Punkt hat sich Masons Testteam an die Technik des Session Based Testing erinnert.

Nach einem kurzen Ausflug in das Session Based Testing, die dahinterliegende Theorie des explorativen Testens und den Credits an Michael Bolton skizzierte Mason, wie mit der kritischen Situation umgegangen wurde. Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: