Tag Archives: entwicklertag

KADEV09: Entwicklertag: Zusammenfassung Agile Day

Posted on by

Nach dem VKSI Day und dem Conference Day war der Agile Day der dritte Tag mit interessanten Veranstaltungen.

Anmerkung: Jetzt ist es schon August und es sind immer noch keine Fotos online ;-(

Getting done your non-functional Requirements


Thomas Starz von IBM stellte in seinem Vortrag (Folien) vor, wie sich Scrum, XP und GTD kombinieren lassen.
Das Problem, dass ständig irgendwas dazwischen kommt, kennt wohl jeder. So kommt es schnell dazu, dass obwohl das Team viel arbeitet keine sichtbaren Ergebnisse erzeugt werden.
Kurze Diskussionen gab es um die Definition von “Nicht-funktionalen Anforderungen” (NFA), Thomas bezeichnete abhängige Anforderungen als NFAs:

  • neue Entwicklungsumgebung
  • neue Server
  • Performance
  • Usability

Nicht jeder im Publikum wollte diese Definition teilen.

Nach Meinung von Thomas legt der Product Owner (PO) seinen Fokus auf die Funktionen, dem sollte als Gegenüber ein Architekt auf die NFAs achten.

Für die Planung im Rahmen von Scrum gab es folgende Tipps:

  • Puffer für unvorhergesehene Arbeiten
  • NFA als Story im Backlog
  • PO (Funktion) soll sich intensiv abstimmen mit Architekt (NFA)
  • alles erfassen, was erledigt werden muss -> wirklich ALLES ins Backlog
  • Backlog ist Grundlage für Entscheidung

Hierbei sollte die Erfahrung berücksichtigt werden, dass viele POs zu häufig NFA nicht ausreichend berücksichtigen. Zudem wird man früher oder später wohl immer mit einem Verweis auf das Vorgehen nach Wasserfall bekommen: “Wir hätten nur die Spezifikation (besser) schreiben müssen!”

Scrum bei der BASF IT Services

Irene Kuhn von der BASI IT Services und Fahd Al-Fatish von andrena objects stellten ein Einführungsprojekt von Scrum bei der BASF IT vor.

Folien

Ziel des Projektes war der Relaunch des Internetauftritts (www.basf.com) von BASF.

Für dieses Projekt wurde ein erfahrenes Kernteam von sechs Entwickler um sechs weitere Mitarbeiter aufgestockt. Das Kernteam hatte in dem Bereich bereits viel Erfahrung mit Intra- und Internetauftritten (Portale, CMS, Redaktionssysteme)

Neben dem Relaunch von basf.com war ein weiteres Ziel die Vorgehensweise nach Scrum zu etablieren und Know-how-Träger als Scrum Master auszubilden.

Herausforderungen und Vorbehalte

Wie in Großunternehmen nicht unüblich stoßen Veränderungen schnell auf Vorbehalte. Gerade die Transparenz, die mit Scrum möglich ist, wird nicht immer nur positiv gesehen. Zudem wird bei der Einführung von Scrum auch oft kritisiert, dass die Methode zu viele Meetings mit sich bringt. Angesprochen wurde auch die Herausforderung, die sich daraus ergibt, dass trotzdem noch das klassische Reporting befriedigt werden muss. Weiterer Punkt war die Definition der Rolle des Projektleiters. Im konkreten Fall wurde der PL zum Scrum Master ernannt.

Vorbereitung

Um das Projekt richtig aufzusetzen und das Team auf Scrum vorzubereiten wurde in eine gute Vorbereitung investiert. Zuerst wurde mittels Einzelgespräche und Teambefragung der Ist-Zustand analysiert (Retrospektive). Es wurde geklärt, welche Probleme existieren und wo die Stärken des Teams liegen. Im nächsten Schritt wurde über Ziele gesprochen und diskutiert, was beibehalten werden kann und was sich ändern soll.

Durch diese Vorbereitungsphase war klar, auf was während der Einführungsphase geachtet werden musste.

Einführungsphase

Um das Team zu stärken (Teamfindung) und Vertrauen in Scrum zu schaffen wurden vier Sprints als “Probezeit” angesetzt. In diesen vier Sprints wurden die Mechanismen und Rollen eingeführt sowie ein erstes Product Backlog (PBL) geschrieben. Durch die Abarbeitung des Stories aus dem PBL war es möglich, eine Team-Velocity zu ermitteln.

Planung

Die Vorplanung für die Sprints erfolgte in mehreren Schritten: Zunächst eine Vorausplanung in einer kleinen Gruppe (Anmerkung: IMHO wichtige Methode, nicht bei jedem Estimation muss 90% des Teams anwesend sein!), gefolgt durch das Planungsmeeting mit dem gesamten Team am Folgetag.

Für die Vorausplanung wurde die Sprint-Kapazität abnehmend festgelegt: 1. Sprint 100%, 2. Sprint 80%, 3. Sprint: 75%. Durch die abnehmende Kapazität wurde der Unsicherheit Rechnung getragen.

Das PBL wurde durch ein “Product Owner-Team” bestehend aus PO & Chief Architect & Technical Architect geschrieben. Damit wurden sichergestellt, dass sowohl Funktionen als auch NFAs berücksichtigt werden. Die Schätzung des Aufwands erfolgte in Ideal-Tagen, zur Ermittlung kam die Planning-Poker Methode zum Einsatz.

Herausforderungen und Zusammenfassung

Im Rahmen des Projektes war es nötig eine Brücke von Scrum zum klassisches Reporting zu etablieren. Der klassische Projektleiter war jedoch eher als übergeordneten Stakeholder eingebunden. Hierbei spielt es eine Rolle, dass Projektleiter häufig zu viele Projekte gleichzeitig betreuen, deshalb beschränkte sich das “Management” hauptsächlich auf die Review-Meetings.

Sehr gut funktioniert hat das Team-Building und sehr effektiv war auch, dass der ProductOwner aus dem Team (!!) verantwortlich für das Management des PBLs war.

Auf die Einführung von komplexen Softwarelösungen wurde bewusst verzichtet. Als Tools kamen lediglich Excel und ein Task-Board zu Einsatz.

Durch die Restschätzung des PBL und Abgleich mit der Restschätzung Budget wurde eine sehr  gute Transparenz erreicht.

Fazit: Das Projekt war ein Erfolg und Scrum wird bei BASF IT Services immer häufiger eingesetzt.

Making Scrum stick – Transforming the Enterprise

Christoph Mathis (ScrumCenter) beschäftigte sich in seinem Vortrag (Folien) damit, wie Scrum nachhaltig im Unternehmen verankert werden kann.

Jeder von uns kennt es – unter Druck fallen wir schnell zurück in alte Verhaltensweisen und vergessen das neue. Hierbei spielt es oft auch eine Rolle, dass konservative Kollegen nichts mit den neuen Ansätzen anfangen können und dagegen opponieren. Auch Manager, die zu viel Transparenz fürchten, sorgen oft für einen gewissen Druck, wieder zurück zur alten Vorgehensweise zu wechseln. Ein kritischer Moment ist dann gekommen, wenn der Sponsor von Scrum die Firma verlässt.

Wie lassen sich solche Rückschläge vermeiden?

Christoph schlägt als erfolgsversprechendes Herangehen vor, dass Scrum vollständig praktiziert werden soll und damit letztendlich Scrum in der DNA der Firma verankert wird.

Er bezieht sich auf grundlegene Praktikern und Ideen von Scrum:

  • ask the team
  • inspect & adapt
  • deliver every 30 days
  • treat people as adults

Ergänzt werden sollen diese durch den konsequenten Einsatz von Engineering Praktiken.

Immer wieder soll die Frage gestellt werden, was getan werden muss, damit Scrum maximale Produktivität bringt?

Sein Vorschlag ist der Einsatz eines Verbesserungs-Backlog. Dieses wird in der Diskussion in Gruppen zu 2-3 Teilnehmern erstellt. Zentrale Fragestellung hierbei: Was braucht es, damit unsere Scrum-Praxis wirklich exzellent wird?

Um Scrum in der DNA des Unternehmens verankern zu können, muss die Kultur des Unternehmen berücksichtigt werden. Beispiele für die Kultur in einem Unternehmen sind:

Geschichten (worüber geredet wird)

  • welche Geschichten im Unternehmen (Held, Armleuchter, Erfolge, Misserfolge)
  • welche Geschichten sollen erzählt werden?
  • Was soll nächstes Jahr über das Projekt und das Team erzählt werden?

Symbole

  • wer hat welches Büro und welchen Dienstwagen?
  • wie ist die Kleiderordnung?
  • wer ist “Anzugträger”?

Organisationsstrukturen

  • wie ist die Organisation?
  • formal / informell

Kontrolle

  • wer fördert wen?
  • was bedeutet es Scrum Master zu sein für die Karriere?

Rituale & Routine

  • was für Veranstaltungen werden gemacht?
  • wie tut man Dinge?
  • wie initiiert man einen Vorschlag bei seinem Chef?
  • “das macht man bei uns so!” – nicht rational

Macht (Beeinflussung)

  • wer kann welche Vorgaben machen?
  • Methodenabteilung – hat diese Macht?
  • wer hört auf wen?

Durch sorgfältige Analyse können die einflussreichen Personen identifiziert und überzeugt werden. Nur mit der Unterstützung der Schlüsselpersonen, kann es gelingen Scrum dauerhaft im Unternehmen zu verankern.

Wichtig ist es, dass nach Identifikation des bzw. der Sponsoren Hilfe von außen geholt wird.

Hilfe von außen holen:

  • Hilfe von außen
  • Leuchtfeuer
  • Professionalisierung (Kompetenzzentrum)
  • Fördern
  • Diversifizieren
  • Etablieren
  • Konsolidieren
  • Integrieren

1) Scrum gut machen: Verbesserungs-Backlog
2) Scrum in Unternehmens-DNA einbauen: Transition-Backlog

Insgesamt wurden einige wichtige Hinweise gegeben, wie eine Einführung und Verankerung von Scrum im Unternehmen gelingen kann. Aus den Hinweis, dass es wichtig ist, Hilfe von außen zu holen durfte natürlich nicht verzichtet werden ;-)

Fazit Agile Day

Jetzt hat es doch wirklich mehr als einen Monat gedauert bis ich meine Notizen endlich überarbeitet habe. Nunja, zumindest bin ich mit der Zusammenfassung fertig bevor Fotos erscheinen ;-)

Insgesamt war der Agile Day sehr interessant – nicht nur wegen den Vorträgen! Die sehr spannende Podiumsdiskussion zum Thema “Clash of Cultures – Agilität und hergebrachte Arbeitsmodelle – Beobachtungen aus USA, Europa, Naher Osten und Asien – Unterschiede und Gemeinsamkeiten.” bekomme ich jetzt nicht mehr zusammen, dazu sind meine Notizen einfach zu wirr ;-)

Nun, es scheint ich tauge nicht zum Konferenz-Blogger. Na, wieder einmal etwas gelernt ;-)

KADEV09: Entwicklertag: Zusammenfassung des Conference Day

Posted on by

Nach den detaillierten Berichten zu Vorträgen wie “Agile Nearshoring” und “Agil & PMBOK-konform” hier noch die Zusammenfassung des “Conference Day” des diesjährigen 3-tägigen Entwicklertags. Ist schon die erste interessante Sache: Drei Tage == Entwicklertag. Scheinbar hat jemand eine Marke auf “Entwicklertage” oder ähnliches …

Nachdem ich etwas später eingetroffen bin, konnte ich der interessanten Keynote

KEYNOTE: Bereit für die Multikern-Revolution?

von Walter Tichy (Professor am Lehrstuhl für Informatik in Karlsruhe) folgen.

Da sich die Taktfrequenz einer CPU nicht beliebig erhöhen lässt, wird in Zukunft immer stärker parallelisiert werden: Immer mehr Prozessoren bei etwa gleich bleibender Taktfrequenz. Gesucht werden Anwendungen, die hunderte von Prozessoren sinnvoll einsetzen.
Vorgestellt wurden Beispiele dafür, wo auf Parallelität optimierte Algorithmen zu erstaunlichen Leistungsverbesserungen geführt haben. Es folgte der Hinweis auf die Probleme in der Praxis: Die heutigen Werkzeuge sind noch nicht darauf ausgelegt, den Programmierer bei der Erstellung von Programmen zu unterstützen, die massiv auf Parallelität setzen. Zudem lässt die Ausbildung der Programmierer oft zu wünschen übrig. Programme müssen auf Nutzung von Parallelität vorbereitet werden.
Schluss: Viele Grundlagen der Informatik müssen neu überdacht werden.

Wie entwickelt Microsoft in der Developer Division, Formal oder Agil?

Christian Binder (Microsoft), PDF Dokument

Uahh, da musste man sich festhalten. Christian hat ziemlich viel Gas gegeben und mit einer Mischsprache aus Englisch und Deutsch gearbeitet. Also nur mal so unter uns: Meine Frau kritisiert mich immer, wenn ich versuche ihr zu erklären, an was ich gerade arbeite und dabei auf bekannte englische Begriffe zurück greife. Manche Dinge kann ich nicht sinnvoll übersetzen sage ich dann – aber irgendwann wird es mir auch zu bunt. Christians Sprache war sehr farbig, also kunterbunt sozusagen ;-)

Inhaltlich hat er viele interessante Punkte angesprochen. Gerade die Größenordnungen in denen bei Microsoft gedacht und gearbeitet wird, sind schon beachtlich. Entwicklungsteams mit 2000 Entwicklern, die am gleichen Produkt entwickeln und damit letztendlich auch in die gleiche Quellcodeverwaltung schreiben. Bei Microsoft sind die Teams teilweise über die ganze Welt zerstreut und intessanter Weise habe ich es so verstanden, dass es den einzelnen Feature Groups frei steht ihre Entwicklungsmethodik selbst zu wählen.

Um das alles dann wieder einzufangen wird mit Quality Gates gearbeitet, für die umfangreiche Überprüfungen durchgeführt werden müssen:
Sicherheit, statische Quellcodeanalyse, Testabdeckung, Laufzeituntersuchungen, Internationalisierung, API Reviews, keine Fehler mehr

Features werden in den Feature Crews entwickelt und müssen diese umfangreiche Tests bestehen. Sie werden erst in den Trunk committet nachdem sie vollständig fertig sind (“completely done”).

Im Scrum-Speak ist die Feature Crew wohl vergleichbar mit einem Entwicklungsteam.
Pillars = Investment Themes
Value Propositions = Epics
Features // Deliverables = Stories & Tasks

Insgesamt eine sehr interessante Präsentation, die allerdings unter ihren vielen Details litt.

BTW: Ich frage mich gerade, wo die Bilder bleiben (vgl. Entwicklertag 2008). Die ganze Zeit wurden Fotos gemacht aber bisher konnte ich nichts auf der Webseite finden.

KADEV09: Entwicklertag: Juristisch Aktuelles vom Software Engineering – Projektmanagement-Recht

Posted on by

Von offenen Quellen und Wasserfällen – juristisch Aktuelles vom Software Engineering

RA Prof. Dr. Rupert Vogel

PDF Dokument
Ein sehr interessanter und unterhaltsamer Vortrag über rechtliche Aspekte des Urheberrechts und des IT-Projektmanagement wurde von RA Prof. Dr. Rupert Vogel gehalten. Nicht alles habe ich im Detail verstanden, aber dies ist schließlich auch die Aufgabe eines Juristen ;-)

Teil2: Projektmanagement-Recht

Leistungsbeschreibung

Eine wichtige Fragestellung in der Praxis ist: Wer muss definieren, was die Software tun muss? Grundsätzlich muss dies der Kunde/Auftraggeber tun, es besteht jedoch Beratungspflicht des Auftragnehmers. Hier bei ist das Wissensgefälle zwischen Kunde und Softwarehaus maßgeblich.

Hinsichtlich Qualität der zu erbringenden Leistung gilt, dass (falls nichts anderes vereinbart wurde), eine ist mittlere Art & Qualität (Stand der Technik) zu erbringen ist. Es gibt drei grundlegende Qualitätsstufen:

  • gering: Regeln der Technik
  • mittel: Stand der Technik
  • sehr hoch: Stand von Wissenschaft und Technik

TIPP: Verfahrenstandards konkretisiert undVertragsbedingungen prüfen hinsichtlich geforderter Qualitätsstandards

Beweis und Dokumentation

Es wurde hervorgehoben, dass die Dokumentation eine der Hauptpflichten des Softwareherstellers ist. Ein Softwarehaus hat bis zur Abnahme die Beweislast, dass die gelieferte Software dem vereinbarten Qualitätsstandard entspricht. Falls es zu Verzögerungen kommt, sollte man vor Behinderungsanzeigen nicht zurückschrecken: Hier gilt es eine Aktenlage zu schaffen! Gerade bei kritischen Projekten ist es wichtig, eine Claim-Liste zu führen. Bei Verhandlungen im späteren Projektverlauf kann der Projektleiter dann “seinen Stapel” mitbringen. Viele große Auftragnehmer haben eigene Claim-Manager, deren Hauptaufgabe es ist etwaige Mängel zu finden. Damit soll der Preis gedrückt werden.

TIPP: Stärkerer Position durch Protokollierung von Besprechungen, Redaktion von Verträgen, durchgängige Dokumentation der Softwareerstellung und des Projektverlaufs. Etwaige Beweismittel im Prozess (z.B. Mails) frühzeitig und konsequent sammeln.

Abnahme

Eine Abnahme erfolgt nur bei einer Individualentwicklung, markiert rechtlich den Beginn der Gewährleistung und führt zur Zahlungspflicht des Kunden.Laut BGH liegt eine stillschweigende Abnahme nach 6 Monate produktiver Nutzung vor, jedoch nur wenn keine Mängelrügen erhoben wurden.

TIPP: Teilabnahmen anstreben, die Testmodalitäten frühzeitig klären (Vorschlag: Teil Angebot) und hierbeidie Fehlerklassen definieren.

Gewährleistung und Haftung

Ein Softwarehaus muss im Rahmen der Gewährleistung etwaige Mängel in seiner Sotfwarebeseitigen. Ohne individuelle Regelung gilt eine Gewährleistungsfrist von zwei Jahren nach Abnahme. Ein Softwarehaus muss für Schäden haften, ohne individuelle Regelung ist die Haftung unbeschränkt. Produkthaftung und Haftung für Körperschäden können nicht ausgeschlossen werden.

TIPP: Ein Hersteller/Dienstleister sollte die Frist verkürzen auf ein Jahr (per AGB) bzw. wenn möglich noch kürzer im Rahmen individueller Absprachen regeln. Es ist sinnvoll individuelle Haftungsbeschränkung/Ausschluss  im Rahmen eines Individualvertrags festzulegen. Haftungsbegrenzung in AGBs sind kaum wirksam, deshalb muss dies in individuellen Verträgen geschehen.

SW-Hinterlegung

Idee: Die Hinterlegung von Software soll im Falle der Insolvenz des Auftragnehmers den Schaden für den Auftraggeber begrenzen.Das Probleme für Kunden in der Praxis ist meist, dass sie die Vollständigkeit der Sourcen/Artefake nicht einschätzen können. Zudem ist die Insolvenzfestigkeit nicht geklärt. Probleme für SWH ergeben sich aus der Regelung des Herausgabegrundes und -verfahren.

TIPP: Genaue Regelungen, indivduelle Vertragsgestaltung

Fazit

Insgesamt ein sehr spannendender und lehrreicher Vortrag. Viele der angesprochenen Aspekte werden im Projektalltag häufig nicht ausreichend bedacht.

Wer mit agilen Methoden und den damit verbundenen Wertvorstellungen arbeitet, muss jedoch an der einen oder anderen Stelle schlucken. “So” möchte man nicht arbeiten, wird sich der eine oder andere wohl gedacht haben….