Wie viel ist zu viel?

Welchen Ansatz wählt man, um das Business Problem des Kunden zu lösen? Nicht unbedingt eine Frage der agile Vorgehensweise, aber dennoch - immer wieder interessant, welche Weg es gibt und wie die Argumente lauten ...

Momentan arbeite ich gerade an einem grösseren IT Projekt mit einem Partnerunternehmen zusammen. Dieses Unternehmen wurde vor Jahren outgesourced und ist heute der alleinige IT Dienstleister für den Kunden. Mein Aufgabe besteht darin, Know-How in das Projekt zu bringen, damit eine optimale Lösung für die Bedürfnisse des Kunden gefunden wird - technisches Consulting, quasi.

In der Analyse-Phase fallen nun die letzten Vorhänge und die Vorgehensweisen liegen auf dem Tisch - kurzer Eindruck:

- Architektur braucht man nicht zu Beginn, die "findet" sich dann auf dem Weg zum Ziel
- egal was man macht, es muss "jeder" Entwickler verstehen können
- wir machen alles selbst, keine "fremden", externen Abhängigkeiten - Stichwort: open-source
- der Betrieb und das Integrationsteam stellen 80% der Anforderungen an das Entwicklerteam
..... und, wir machen das so, wie wir das immer machen!

Yeah, Right! Wer ist noch mal der Kunde und was sollten wir Lösen?

Die IT - reiner Selbstzweck! Der Kunde legitimiert uns, uns unabkömmlich zu machen.

I'm out ...

Wann sollte man "Nein" sagen? - Teil III

Oft gewinnt man ein Projekt, hat aber nicht gerade die richtigen Resourcen beisammen. Sie, als erfahrener Scrum Master, sollen das Projekt übernehmen und bekommen ein Team zusammengestellt ...

"If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great."
Jim Collins, Unternehmensberater

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil II

Sie haben ein scrum Projekt, bei dem ein Team firmenübergreifend zusammenarbeitet, weil der Kunde da so wünsch?

Der Kunde A möchte, dass Sie als IT Dienstleister B mit der internen IT von A zusammenarbeitet, um ein gemeinsames Projekt zum Erfolg zu bringen...

Sie haben das Gefühl, der Partner im Projekt spricht nicht die gleiche Sprache, komplett andere Vorgehensweise hat, eigentlich nicht mit Ihnen zusammenarbeiten möchte , künstliche Hürden aufbaut, bla, bla, bla

"The team will make or break the project"

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil 1

Aus gegebenem Anlass schnell ein gutes Argument, wenn man vor der Entscheidung steht, einem agilen Projekt zu- oder abzusagen:

" Good trial lawyers don't take bad cases"

Akutell arbeite ich gerade an einem agilen Projekt mit einem Partner-Unternehmen, wo man ausdrücklich agile arbeiten möchte - die Knwo-how-, Methodik und Erfahrungsunterschiede aber so gross sind, dass man besser "Nein" sagt ...

10 Gründe, warum agile Projekte schief gehen

Wenn ein agiles Softwarentwicklungsprojekt schief geht, ist in erster Line immer die Methode schuld, nicht die Personen, die die agile Methode eingeführt bzw. umgesetzt haben. Oft eine falsche Annahme. 10 Gründe, warum agile Projekte scheitern:

#10 Gerüchten glauben, z.B.

• agile ist besonders gut für kleine Projekte
• totale Kostenkontrolle
• Dokumentation ist nicht notwendig
• agile Vorgehensweise braucht keine Analysten und Tester
• "jeder" kann "alles" Grundsatz
  
• wir machen Scrum, wir sind agile!
  

#9 Widersprüchliche Terminologie

Wir sagen - der Kunde versteht/interpretiert:

• extreme - riskant
• agile - ungenau, unbestimmt, locker
• pair programming - doppelte Kosten
• refactor - unnötiger Code
• unit testing - extra Code
  

Wenn man es nicht erwähnt, hat man es nicht gehört - jetzt ist man agile!

# 8 Keine Schlüsselfiguren

man fokussiert auf die Entwicklung von Features, ABER es braucht einen

• Sprint Manger
• (Business) Analysten
• Tester
• Designer
• WAI Experten
  

#7 Übertreibung

Beispiele:

• Sicherstellen, das Dokumente für jemanden bestimmt sind
• Sicherstellen, dass jede Implementierung ein Problem löst
• Alles weglassen, was keinen Business-Value hat
• Kein Micromanagement
• Keine Statusdiagramme oder ähnliches

#6 Spitzfindigkeiten

• Man braucht ne Menge Erfahrung
  
• Entscheidungsträger sind nur involvierte Personen
• "Nach Lehrbuch" Vorgehensweise
• Alles mindestens 3 Interationen ausprobieren
• Jede Änderung min. 3 Interationen verifizieren
• Keine Angst, Änderungen rückgängig zu machen

#5 Mangelnde Disziplin & Schleifen lassen

• Angst Dinge zu ändern oder Änderungen einzufordern
• Tun und Handeln wird unterschieden - ist man wirklich agile?
• Rituale vernachlässigen

#4 Nicht das richtige Team

• es braucht erfahrene Führungspersonen
• es braucht ein erfahrenes Team
  
• es braucht erfahrene Mentoren für jede Rolle
• man braucht mehr als einen "Plan"
• Externe Epertentips einholen - und zuhören!

#3 Zu lange Interationen

• nicht länger als 2 Wochen
• klarer Rythmus ist erwünscht -> Dienstag -> Dienstag
• Schneller Teams sollten kürzere Zyklen haben
• Keine Zeit verliehren

#2 Kein guter "Sponsor"

• der Kunde muss zum agilen Prozess passen
• man braucht jemanden, der genug politischen Einfluss ausüben kann, um agile ein Chance zu geben
• Überzeugung und Begeisterung für agile schaffen
• Aus Fehlern lernen

#1 Dem Team keine Erholen lassen

• das Team gewinnt oder verliehrt das Projekt
• die Führungsperson ist ein wunder Punkt
  
• die Umgebung/Arbeitsumfeld ist ein wunder Punkt
• die (externe) Unterstütztung ist ein wunder Punkt
• Personalfluktion ist ein wunder Punkt
  

Stub vs. Mock

In einem anderen Post habe ich die vier Test Doubles beschrieben und deren Verwendung abgegrenzt. Da Mocks und Stubs immer wieder verwechselt werden, hier ein Beispiel, um deren unterschiedliche Verwendung aufzuzeigen:

Nehmen wir an, es gibt eine Funktion um das Password zu ändern. Wenn man diese aufruft, soll automatisch ein re-login mit den neuen Credentials durchgeführt werden.


public interface LoginService {
   public boolean login (String login, String password);
}


public class LoginServiceStub implements LoginService {
   private Map currentSessions = new HashMap();
   public boolean login (String login, String password) {
      currentSessions.put(login, password);
      return true;
   }
   public int numberOfCurrentSessions() {
      return currentSessions.size();
   }
}


Beim ChangePassword kann man wie folgt testen, ob login aufgerufen wird (state verification):

class ChangePasswordStateTester...
   public void testReLoginAfterPasswordChanged() {
      LoginService loginService = new LoginServiceStub();
      ChangePasswordService systemUnderTest = new ChangePasswordServiceImpl(loginService);
      systemUnderTest.changePassword("accountId", "oldPassword", "newPassword");
      assertEquals(1, loginService.numberOfCurrentSessions());
   }


Der Mock Test dazu sieht folgendermassen aus:

class ChangePasswordInteractionTester...
   public void testReLoginAfterPasswordChanged() {
      Mock loginService = mock(LoginService.class);
      ChangePasswordService systemUnderTest = new ChangePasswordServiceImpl(
         (LoginService) loginService.proxy());

      loginService.expects(once()).method("login")
         .withAnyArguments()
         .will(returnValue(true));

      systemUnderTest.changePassword("accountId",
         "oldPassword", "newPassword");
   }
}


Bei beiden Beispielen wurden Test Doubles verwendet, nicht der "echte" Login Service, wobei der Stub ein state verfication und der Mock eine behaviour verfication durchführt.

Man muss sich bewusst sein, dass man bei Stubs in aller Regel zusätzliche Methoden hinzufügen muss, um den Status zu prüfen. Das bedeutet, dass die Code Basis wächst und dieser Code wird zunehmens anfälliger und muss gewartet werden. Nicht zuletzt eine Frage der Kosten.

Was sind Test Doubles?

Oft fällt im Zusammenhang mit agiler Software Entwicklung der Begriff Test Driven Development (TDD). Möchte man TDD einsetzten, sollte man wissen, was mit Test Doubles gemeint ist. Dieser Term wird immer wieder in der Literatur im Zusammenhang mit TDD verwendet.

Als Test Doubles bezeichnet man bestimmte Objekte, die beim Testen einen Systems eingesetzt werden, um Zustand und Verhalten zu verfizieren. Es gibt vier unterschiedliche Typen, die jeweils für ein anderes Bedürfniss beim Testen verwendet werden:

Dummy
Ein Dummy Objekt wird nur durch das Sytem gereicht und niemals wirklich verwendet. Dummies werden oft nur zum Füllen von Parameterlisten verwendet.

Fake
Ein Fake Objekt hat eine echte, funktionierende Implementierung, die aber meistens ein abgekürztes Verfahren darstellt. Eine in-memory-database ist ein gutes Beispiel dafür.

Stub
Ein Stub gibt vorgespeicherte Antworten bei Aufrufen während eine Testlaufs, die in keinem Zusammenhang mit dem geschriebenen Test und damit mit dem Caller stehen. Stubs können zusätzlich Informationen über den Aufruf aufzeichnen, z.B. ein Email Gateway, wie viele Emails er verschickt hat und was deren Inhalt war.

Mock
Mock Objekte haben einen definierten Satz von vorprogrammierten Erwartungen (expectations) über die genaue Abfolge von Aufrufen, die erwartet werden, wenn das Mock Objekt verwendet wird.

Wichtig!
Nur Mocks dienem dem Testen von Verhalten (behaviour verfication) eines "System Under Test" (SUT). Alle anderen können nur beim Testen von Zuständen (state verification) verwendet werden.

Ich werde später noch genauer auf Mocks und Stubs eingehen und ein Beipspiel zeigen, da Mocks und Stubs immer wieder verwechselt werden.