Archiv der Kategorie: Engineering

Die „Power-Week“ als Produktivitätsfaktor

Nach einigen Diskussionen über die nicht änderbaren schlechten Schallschutzmaßnahmen in unserem alten Großraumbüro (Straßenlärm bei geöffneten Fenstern, Drucker die von dem ganzen Stockwerk genutzt wurden,…), und einem neuen Mitglied in unserem Entwicklerteam, entschieden wir uns dem Occupy-Movement zu folgen. Wir besetzten also einen Meetingraum (für eine volle Woche) und begannen dort  mit unserer „Power-Week“.

Regeln für die Power-WeekTony Schwartz‘ Artikel „The Magic of Doing One Thing at a Time“ bestärkte uns in dem Bestreben erstmal zu definieren wann „Ruhezeiten“ sind, und wie diese auszusehen hatten bzw. wann man für Störungen „zur Verfügung“ stehen wollte.

Wichtig war für gemeinsam im Team zu arbeiten, und damit schnell zu hervorragenden Ergebnissen zu gelangen.

Für die Power-Week hatten wir das perfekte Thema – ein technisches und grafisches redesign (JS-Framework, Usability, neue Steuerelemente) der Suchformulare unserer Seite. Um diese Aufgabe in einer Woche bewältigen zu können bestand das Team aus vier Entwicklern, einem UX-Designer und dem ProductOwner, der sich ebenfalls zu dieser Power-Week commitete.

Dienstags (8 Tage später) mussten die Suchformulare testbar sein, da schon Personen für den Usertest eingeladen waren.

Transport der HardwareMit diesen Bedingungen startete die Power-Week.
Montags um 8:00 versammelten wir uns dann im Großraumbüro und besprachen kurz das Vorgehen für den „Umzug“. Als ScrumMaster hatte ich einen Wagen besorgt, um Hardware (Monitore, Telefon, Switches udgl) und Software (Teammitglieder) in unsere neuen Räumlichkeiten transportieren zu können.

Meetingraum Genf - vorherMeetingraum Genf - nachherNachdem alles angeschlossen war und der ProductOwner die einzige Möglichkeit darstellte wie „die Welt“ mit dem Team kommunizieren konnte war eine „sichere“ Umgebung geschaffen.

Thomas bei der arbeit im Raum Genf Auch unser UX-ler fand im „neuen Büro“ seinen Platz und konnte das Team tatkräftig mit seinem Input zu den neuen Steuerelementen unterstützen.

Er stand somit jederzeit zur Verfügung, wenn es Fragen bezüglich der Usability oder des Designs gab, was kürzest mögliche Entscheidungswege bedeutete.

Ich bat unseren PO am Ende der Woche einen Kommentar für den Blog abzugeben, hier sind seine Worte:

„Im täglichen Doing ging es relativ gut von der Hand. Der Sprint war erfolgreich, ich kann die positiven Punkte nochmals stichpunktartig hervorheben:

  • Der größte Pluspunkt: eine ruhige Arbeitsatmosphäre, kein lautes
    Großraumbüro neben der Autobahn. Dadurch musste auch niemand einen Kopfhörer aufsetzen, um sich vor dem Lärm zu schützen, und so bekam jeder mit, was der andere tat und dachte
  • An spontanen Diskussionen/Fragestellungen konnten sich alle sofort beteiligen
  • Es gab ein Thema, nicht viele kleine, was positiv zur Motivation beitrug. Das know-how war im kompletten Team vorhanden, somit konnte auch jeder zum Erfolg beitragen
  • Dadurch, dass wir nur ein Thema bearbeitet haben, war es dann auch der Erfolg aller am Ende des Sprints“

Mit dem heutigen Tag sind die neuen Suchformulare auf unserer wichtigsten Seite (www.holidaycheck.de) verfügbar, nachdem sie die letzten Wochen für einen kleineren Teil unserer Nutzer auf der österreichischen Seite online gegangen waren.

Hier noch ein paar Screenshots der Formularelemente:

Studien: Erfolg agiler Methoden (agile success rate)

Die Bedeutung agiler Methoden und Frameworks ist unbestreitbar: Was früher noch innovativ war dürfte heute als Stand der Technik angesehen werden. Selbst relativ veränderungsresistente Unternehmen der „late Majority“ versuchen sich mittlerweile daran ihre Prozesse zu agilisieren.

So hat nun mittlerweile nahezu jedes Unternehmen in irgendeiner Form Erfahrungen mit agilen Methoden gesammelt. Diese Erfahrungen sind nicht nur positiv, sondern weisen – wie einiger der hier vorgestellten Studien nahelegen – auch auf viele Herausforderungen hin, mit denen Unternehmen bei der Einführung von agilen Methoden zu kämpfen haben.

Ernüchternde Ergebnisse der Studie „Softwaretest in der Praxis“

Durch Diskussionen mit einem meiner Kunden bin ich auf die Studie „Softwaretest in der Praxis“ aufmerksam geworden. Die Studie wurde 2011 durchgeführt und die Ergebnisse (PDF) sind teilweise beunruhigend: Laut der Studie sind klassische Qualitätssicherungsmaßnahmen in der Praxis gleich gut oder besser als die praktizierten Maßnahmen in den meisten agilen Projekten.

Qualität als kritischer Erfolgsfaktor bei agilen Methoden (agile success rate)

In Projekten in denen agile Methoden / Frameworks genutzt werden, spielt die Qualität der erzeugten Artefakte jedoch eine sehr wichtige Rolle. Da häufig Zwischenartefakte / Mittler fehlen, muss sichergestellt sein, dass durchgängig hohe Qualität erzeugt wird.

Kurz: Qualität ist ein kritischer Erfolgsfaktor für agil durchgeführt Vorhaben und für agile Organisationen. Fehlende Qualität wird schnell zu einem Problem.

Die Studie „Softwaretest in der Praxis“ im Detail

Die Umfrage zum „Softwaretest in der Praxis“ hat aufgrund der außerordentlich hohen Beteiligung von Testern, Entwicklern und Managern praktisch repräsentativen Charakter:

  • fast 1100 Projektleiter, Qualitätsbeauftragte, Testmanager und Tester
  • fast 270 Entscheider und Manager
  • ca. 420 Business Analysten, Entwickler, Betriebsverantwortliche und andere
Die Bedeutung agiler Methoden und Frameworks ist unbestreitbar: Was früher noch innovativ war dürfte heute als Stand der Technik angesehen werden. Selbst relativ veränderungsresistente Unternehmen der „late Majority“ versuchen sich mittlerweile daran ihre Prozesse zu agilisieren.

So hat nun mittlerweile nahezu jedes Unternehmen in irgendeiner Form Erfahrungen mit agilen Methoden gesammelt. Diese Erfahrungen sind nicht nur positiv, sondern weisen – wie einiger der hier vorgestellten Studien nahelegen – auch auf viele Herausforderungen hin, mit denen Unternehmen bei der Einführung von agilen Methoden zu kämpfen haben.

Ernüchternde Ergebnisse der Studie „Softwaretest in der Praxis“

Durch Diskussionen mit einem meiner Kunden bin ich auf die Studie „Softwaretest in der Praxis“ aufmerksam geworden. Die Studie wurde 2011 durchgeführt und die Ergebnisse (PDF) sind teilweise beunruhigend: Laut der Studie sind klassische Qualitätssicherungsmaßnahmen in der Praxis gleich gut oder besser als die praktizierten Maßnahmen in den meisten agilen Projekten.

Qualität als kritischer Erfolgsfaktor bei agilen Methoden (agile success rate)

In Projekten in denen agile Methoden / Frameworks genutzt werden, spielt die Qualität der erzeugten Artefakte jedoch eine sehr wichtige Rolle. Da häufig Zwischenartefakte / Mittler fehlen, muss sichergestellt sein, dass durchgängig hohe Qualität erzeugt wird.

Kurz: Qualität ist ein kritischer Erfolgsfaktor für agil durchgeführt Vorhaben und für agile Organisationen. Fehlende Qualität wird schnell zu einem Problem.

Die Studie „Softwaretest in der Praxis“ im Detail

Die Umfrage zum „Softwaretest in der Praxis“ hat aufgrund der außerordentlich hohen Beteiligung von Testern, Entwicklern und Managern praktisch repräsentativen Charakter:

  • fast 1100 Projektleiter, Qualitätsbeauftragte, Testmanager und Tester
  • fast 270 Entscheider und Manager
  • ca. 420 Business Analysten, Entwickler, Betriebsverantwortliche und andere

Agile Architektur

Agilität und Software-Architektur sind immer für eine Diskussion gut. Ich kann mich gut an diverse (hitzige) Diskussionen erinnern, in denen von stark traditionell geprägten Architekten gefordert wurde, dass doch bitte die Architektur detailliert im Vorfeld zu erstellen wäre. Zudem müsse man sich zu Projektstart darauf festlegen, welche Referenzumgebungen genutzt werden sollen, welche Technologien relevant sind und wie die nicht-funktionalen Anforderungen im Detail lauten. Das ergebe sich doch automatisch aus dem Scope und überhaupt müssen die typischen Sichten auf die Architektur detailliert geplant und beschrieben werden, bevor mit der Umsetzung begonnen wird. Eine Freigabe des Ganzen vor Eintritt in die Umsetzungsphase ist natürlich auch noch bei den entsprechende Entscheidungsinstanzen einzuholen.

Eine Ansicht, die in einem Phasenmodell ohne echte inkrementelle Elemente nicht ganz unbegründet ist und auch einen gewissen Wert hinsichtlich Identifikation und Bewertbarkeit von Risiken darstellt.

Die Realität: Architekturbeschreibung meist veraltet

Wie sieht die Realität in vielen Fällen aus? Eine Vielzahl an umfangreichen Modellierungsartefakten, eine Architektur die die Änderungen im Projektverlauf nicht abbilden kann. Kurz: Eine anfangs schöne Architekturvorstellung gleitet in einen „Architektursumpf“ ab. Der Ruf nach großen Re-Design Phasen wird laut (neue Dokumente, Modelle, Reviews, Freigaben). Das eigentliche Ziel, lauffähige Software zu liefern gerät schnell in den Hintergrund.

Agile Architektur weiterlesen