Wenn Scrum oder andere Prozesse in einem Unternehmen eingeführt werden, dann ist es sehr hilfreich, wenn die Rollen klar definiert werden. Es muss klar herausgestellt werden, wer für was verantwortlich ist und zu wem jemand gehen muss, um eine(n) Lösung/Antwort/Denkanstoß zu erhalten. In Scrum gibt es im Wesentlichen drei Rollen: Scrum Team (oder auch Scrum Developer genannt), Product Owner und Scrum Master.
Hier eine kurze Auflistung der Aufgaben von Scrum Master und Product Owner, die typischerweise von diesen Rollen übernommen werden.

Product Owner:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budger-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Scrum Master:

  • sorgt dafür, dass Scrum funktioniert
  • setzt sich für die Organisationsentwicklung ein
  • hilft bei der Organisation im Team
  • führt eine kontinuierliche Prozess-Optimierung durch
  • stimmt sich mit anderen Scrum Mastern ab
  • sorgt für die Abstimmung mit anderen Teams
  • pocht auf Regeln und Meetings
  • unterstützt den Product Owner bei Bedarf
  • moderiert Meetings
  • Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)
  • Bindeglied zum Product Owner
  • das gute Herz des Teams
  • fordert Dokumentation ein und erstellt ggf. Meeting Minutes
  • beseitigt Hindernisse (und deckt sie ggf. auf)
  • beschafft Informationen/Räume/Material

IMG_20141117_103351-300x405

Nachdem der Kurs Agiles Projektmanagement am Beispiel von Scrum bereits 2014 erfolgreich stattgefunden hat, wird es auch in diesem Jahr wieder ein Seminar zum Thema agiles Projektmanagement an der VHS Wiesbaden geben.

Mo. 04.05.2015 – Fr. 08.05.2015 und
Mo. 12.10.2015 – Fr. 16.10.2015 (jeweils von 09:00 bis 16:00 Uhr)

Weitere Informationen zu den beiden Lehrveranstaltungen gibt es unter:

Sie werden in diesem Kurs unter Anderem erfahren, was es mit folgendem Konstrukt auf sich hat:
IMG_20141117_103351

 

 

Beim Verbindungsaufbau zu einem WebService, bin ich über ein Problem gestolpert, dass der Zugriff auf den WebService nicht mehr möglich war. Obwohl bei der Generierung des Services (javax.xml.ws.Service) die URL zur WSDL-Datei angegeben wurde und in dieser Datei die Endpoint-URL definiert war, funktionierte der Aufruf jeweils nur einmal nach dem Deployment im jBoss Application Server. Warum? Keine Ahnung. Zunächst wurde die Verbindung wie folgt aufgebaut:

String plainUrl = "http://mywebserivce:9999/call.php?wsdl";
Url url = new Url(plainUrl);
PrintManagerService service = new PrintManagerService(url);	
soap = service.getPrintManagerPort();

In der lokalen Testumgebung (Windows) funktionierte das einwandfrei. Erst im Produktionssystem (Linux; vermutlich spielt das BS hier keine Rolle) kam es zu folgender Fehlermeldung:


javax.xml.ws.WebServiceException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
...
Caused by: java.io.IOException: IOException invoking http://localhost:8080/call.php: HTTP response '404: Not Found'

Der Host wurde offensichtlich von mywebservice:9999 auf localhost:8080 geändert. Im Code konnte ich keine Stelle finden, an dem vom localhost auf Port 8080 die Rede war. Durch Ergänzung von

((BindingProvider)soap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, plainUrl);

konnte das Problem gelöst werden. Nun wird einmal die URL übergeben und direkt danach der Endpoint ein weiteres Mal gesetzt:

String plainUrl = "http://mywebserivce:9999/call.php?wsdl";
Url url = new Url(plainUrl);
PrintManagerService service = new PrintManagerService(url);	
soap = service.getPrintManagerPort();
((BindingProvider)soap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, plainUrl);

Das folgende Beispiel zeigt die Verwendung der Plentymarkets SOAP Api Version 110. Die SOAP-Klassen wurden mittels dem in Eclipse eingebauten Tool zur Erstellung von Java-Klassen anhand einer WSDL-Datei generiert.

public class PlentyConnector {
	private Logger logger = Logger.getLogger(PlentyConnector.class);
	private String TOKEN = "";
	private int USERID = -1;
	private PlentySoapApiFunctionContainerServiceStub service = null;

// die weiteren Methoden werden separat gezeigt

}

In der folgenden Methoden wird ein Token geladen, sofern dies noch nicht geschehen ist.

   private void createService(String accountUser, String accountPassword, String portAddress) throws Exception {
		try {
			service = new PlentySoapApiFunctionContainerServiceStub(portAddress);
			if (this.TOKEN.equals("") || USERID == -1) {
                                //request a new token
				GetAuthentificationToken req = new GetAuthentificationToken();
				req.setOLogin(new PlentySoapRequest_GetAuthentificationToken());
				req.getOLogin().setUsername(accountUser);
				req.getOLogin().setUserpass(accountPassword);
				GetAuthentificationTokenResponse resp = service.getAuthentificationToken(req);
				this.TOKEN = resp.get_return().getToken();
				this.USERID = resp.get_return().getUserID();
			}
                        //modify the service and set the userid and token as a header element
			SOAPFactory factory = OMAbstractFactory.getSOAP12Factory();
		    SOAPHeaderBlock header = factory.createSOAPHeaderBlock("verifyingToken", null);
		    OMFactory omFactory = OMAbstractFactory.getOMFactory();
		    OMNode userNameNode = omFactory.createOMElement(new QName("UserID"));
		    ((OMElement) userNameNode).setText(""+USERID);
		    header.addChild(userNameNode);
		    OMNode passwordNode = omFactory.createOMElement(new QName("Token"));
		    ((OMElement) passwordNode).setText(TOKEN);
		    header.addChild(passwordNode);
		    service._getServiceClient().addHeader(header);
			System.out.println("token: " + this.TOKEN + " userid: " + this.USERID);
		}
		catch(Exception e) {
			logger.error("Authentification token not loaded correctly!");
			throw e;
		}
	}

Die nächste Methode zeigt am Beispiel der Serverzeit, wie weitere Aufrufe erfolgen können:

	private void getServerTime() {
		try {
	    	PlentySoapResponse_GetServerTime resp = service.getServerTime(new GetServerTime()).get_return();
	    	System.out.println("Servertime : "+resp.getTimestamp());
	   }   
	   catch(Exception e) {
		   logger.error("Server time not loaded correctly: " + e.getMessage(), e);
	   }
	}

In der nachfolgenden Methode wird ein Aufruf mit ein paar Testdaten durchgeführt, um die Funktionsweise zu veranschaulichen:

	public void executePlentyCall() throws Exception {
		System.out.println("login");
		createService("MyUserName", "MyPassword", "http://my.plenty.installation.de/soap/version110/");
		getServerTime();
}

Die SOAP-Klassen zum Verbindungsaufbau wurden mit Hilfe des axis2-Tools wsdl2java.bat erstellt.

IMG_20141117_103351-300x405

Scrum spielerisch erlernen

Um Scrum spielerisch zu erlernen und zu erleben, bieten sich eine Reihe von Methoden an, die unterschiedliche Ziele verfolgen. Besonders im Hinblick auf die Einarbeitung von neuen Mitarbeitern, die ggf. selbst nicht mit Scrum arbeiten, aber im Kontakt mit den Scrum-Teams stehen werden (z.B. ein neuer Mitarbeiter in der Marketing-Abteilung), bietet sich die Duplo-Bausteinen-Variante an, um einen schnellen Überblick über Scrum zu geben.
Dabei wird zunächst in kurzen Sätzen erklärt, um was es in Scrum geht, wieso Scrum im Unternehmen eingesetzt wird und was die Ziele von Scrum im Unternehmen sind. Bei vielen Teilnehmern, werden mehrere Gruppen gebildet, so dass eine Gruppe aus ca. 5 Personen besteht. Die Gruppen bekommen diverse Aufgaben gestellt, die mit Hilfe von Duplo-Bausteinen zu bewältigen sind. Der Moderator kann die Rolle des Product Owners oder die des Kunden einnehmen und liefert bei Fragen zur Umsetzung Hinweise. Jede Gruppe stellt einen Scrum Master und ggf. einen Product Owner (sofern diese Rolle nicht durch den Moderator eingenommen wird), die für das Beseitigen von Hindernissen und das Beschaffen von Informationen zuständig sind. Die einzelnen Rollen in Scrum müssen den Teams nicht bekannt sein. Die Aufgaben von Team, Scrum Master und Product Owner müssen dann allerdings vorm Start der Umsetzung beschrieben werden.

Die Aufgabe

Die Aufgaben, die die Teams erhalten, enthalten zum Teil nicht alle Informationen oder können mit den zur Verfügung gestellten Duplo-Bausteinen nicht gelöst werden. Der Moderator beobachtet das Verhalten der Teams während der Umsetzung und diskutiert anschließend die Herangehensweise zur Umsetzung der jeweiligen Aufgaben. Dabei soll zum einen vermittelt werden, dass die Kommunikation im Team wichtig ist, um eine Aufgabe gemeinsam zu lösen. Zum anderen soll diese Form des spielerischen Erlebens von Scrum dazu beitragen, dass die Beteiligten verstehen, dass nur klare Absprachen und die Kommunikation über Abteilungsgrenzen hinweg zum Ziel führen.

Spieldauer

Die Spieldauer sollte abhängig von den gestellten Aufgaben, der Firmenkultur (ist „spielen“ gern gesehen?) und der Teilnehmermenge gewählt werden. Eine mögliche Zeiteinteilung ist:

  • 15 Minuten Erklärungen zu Scrum im Unternehmen zum Ablauf und zu den Rollen
  • 20 Minuten Spiel-Durchführung
  • 10 Minuten Diskussion um Sinn und Zweck des Spiels oder zur Retrospektive

Aufgabenbeispiel

Eine mögliche Aufgabe ist das Bauen einer Garage. Je nachdem, welches Ziel mit der Aufgabe verfolgt wird, können beliebig viele Informationen fehlen, um die Teilnehmer auf eine falsche Fährte zu führen. So kann zum Beispiel eine Garage für das Unterstellen des Sportflugzeuges gewünscht sein. Die Teilnehmer werden beim Wort Garage sicherlich an eine Garage für Autos denken und diesen Punkt erst gar nicht nachragen…



Die Bausteine können z.B. im Lego Shop Deutschland erworben werden.