Der Kernpunkt des Scrum Prozesses ist das eigenverantwortliche, selbstorganisierte Scrum Team. Dieses übernimmt Entwurfs-, Entwicklungs-, Test- und auch Architektur-Aufgaben. Dem Team wird nur noch das "Was" als Anforderung vorgegeben. "Wie" diese Anforderung realisiert wird obligt ausschliesslich dem Scrum Team.
Soviel zur Theorie....
Aber wie sieht das Ganze aus, wenn die Entwicklung innerhalb einer grösseren IT-Landschaft stattfindet? Wie, wenn es sich nicht mehr um nur ein Scrum Team handelt, sondern um mehrere Teams, die an der selben Software arbeiten? Wer sorgt für den "einheitlichen Guss" und die Einhaltung der unternehmensweiten technischen Vorgaben?
Mein Name ist Nobody und ich arbeite als Architekt in einem grösseren Scrum Projekt... Der Vortrag erzählt meine Geschichte, wie es mir ergangen ist und was ich dabei über Architektur in Scrum gelernt habe.
Werner Eberling
Werner Eberling ist als Principal Consultant und Trainer für die MATHEMA Software GmbH in Erlangen tätig. Seit 1999 beschäftigt er sich mit verteilten Systemen, mit Fokus auf CORBA und der Java EE. Sein aktuelles Steckenpferd ist die Anwendungsentwicklung für mobile Endgeräte bzw. deren Anbindung an Enterprise-Systeme. Zur Zeit ist er als Architekt in einem grösseren Scrum Projekt tätig.
Neben seiner Projekttätigkeit hält er Technologie-Trainings in Deutschland und der Schweiz. Er ist Autor des Buches "Enterprise JavaBeans 3.1 - Das EJB-Praxisbuch für Ein- und Umsteiger" und veröffentlich regelmässig Artikel in Print- und Online-Medien.