Scrum in der Praxis: Teil 4, a day in the life …Scrum Developer

Unser Tech Talk geht weiter, mit unserer Reihe Scrum in der Praxis. Heute beschreibt Steffi ihren typischen Alltag als Scrum Developer. Nachdem sie im ersten Beitrag zum Thema den Sprintanfang näher beleuchtet hat, entführt sie uns heute in die typischen  Abläufe eines Sprints und erklärt, wo es manchmal Abweichungen geben kann.

ibm-client-innovation-center-scrum-stefanie

Als Softwareentwicklerin in einem Team, das nach SCRUM-Vorgehensmodell arbeitet, ist eine große Kennzahl für mich in unserem Team eine Zehn. Das steht für die zehn Arbeitstage pro Sprint. So lang ist nämlich unser Entwicklungszyklus – immer zwei Wochen, also meist zehn Arbeitstage. Es beginnt mit der Sprintplanung bzw. dem Sprintwechsel und endet mit einer Review vor dem Kunden. Aber das reguläre Ereignis, zu dem wir uns fix jeden Tag treffen, ist das „Daily“. Wir Devs und Scrum Master sitzen zwar alle in einem Raum, aber nicht alle unsere Tester und auch nicht unser PO (Product Owner). Um uns einmal am Tag zu synchronisieren, gibt es das Daily.

In unserem Fall findet es vormittags statt und als Faustregel gilt, dass jeder reihum sagt, was er bisher getan hat, was er gerade tut und was er tun wird. Wer jetzt stöhnt und sagt „jeden Tag mindestens ein Meeting klingt nach Zeitfressern und gar nicht so agil“, den kann ich beruhigen: Es dauert nicht länger als 15 Minuten. Und es ist ein wichtiger Termin. Er gibt uns die Gelegenheit Fragen an den PO zu richten, wenn ein Akzeptanzkriterium nicht mehr so klar ist oder eine Vorgabe fehlt. Und, wenn ein Kollege nicht weiterkommt und Hilfe braucht, ist das spätestens der Moment, in dem man sagen kann „Wer hat Zeit sich das mit mir kurz anzuschauen?“

Abgesehen vom Daily gibt es wenige Sprint-Ereignisse oder –Meetings, die uns vom „arbeiten abhalten“ könnten. Regelmäßig ein Mal im Sprint werden User Storys geschätzt, ansonsten soll der Aufwand gering gehalten werden. Scrum geht davon aus, dass der Entwickler auch wirklich entwickeln darf. Es ist die Aufgabe des Scrum Masters andere Aufwände vom Team abzuhalten. So beispielsweise, wenn es etwas zu diskutieren gibt, wobei der beste Ansprechpartner noch nicht klar ist. Der Scrum Master schirmt das Team quasi vor nicht planmäßigen Aufwänden ab und dient als Sprachrohr nach außen, wenn beispielsweise Hilfe benötigt wird. Natürlich arbeiten die Entwickler aber nicht vollkommen isoliert. Sobald es etwas zu besprechen gibt, sollte jeder Entwickler zum Telefon greifen, zum Kollegen rübergehen oder dem Scrum Master und PO Bescheid geben, dass es einen Blocker gibt.

ibm-client-innovation-center-scrum-in-der-praxis-teil-4

Zwei Ereignisse gibt es im Sprint dann doch, die ein bisschen anders verlaufen als der übliche Sprinttag mit Daily. Das ist zum einen die Review mit dem Kunden und allen Stakeholdern und zum anderen der Sprintwechsel, der in unserem Fall meistens aus Retrospektive und Planning besteht.

In der Review werden allen Stakeholdern, d.h. allen, die Interesse am Arbeitsergebnis haben, die absolvierten Storys und gefixten Defects demonstriert. Meistens live in der Anwendung und unter Einbezug der Stakeholder, die das üblicherweise auch gern annehmen und das Arbeitsergebnis auf Herz und Nieren testen – und es hoffentlich abnicken. 😉

Je nach Projektsetup kann ein Sprint mit der Review enden, wenn im besten Fall alle Storys abgenommen und demonstriert wurden. Anschließend gibt es eine Retro und vielleicht sogar einen Sprintwechsel mit Planning. Manchmal funktioniert das logistisch nicht und wie im Falle meines Teams endet meistens der Sprint mit der Review, lässt aber noch etwas Platz für abschließende Arbeiten. Am  Tag darauf geht es dann weiter mit Retro und Planning.

Die Retro ist das Sprint-Ereignis, das allen Mitgliedern des Scrum-Teams Gelegenheit gibt zu sagen was gut lief und was noch verbessert werden kann. Damit gibt einem das Meeting Raum sich beispielsweise bei hilfsbereiten Kollegen zu bedanken oder auch einfach mal Erfolge zu feiern. Aber auch zu sagen, was nächstes Mal anders laufen sollte oder einen Konflikt neutral anzusprechen und Lösungen für die Zukunft zu finden. Retros sollen kein Sammeltopf für alle Probleme der Menschheit sein oder Jammer-Runden, sondern konstruktiv. Deswegen formulieren wir in der Regel Aktionen, die wir im nächsten Sprint versuchen umzusetzen.

Im Planning wird wiederum der kommende Sprint unter Berücksichtigung vieler Parameter geplant. Wurde im vergangenen Sprint alles absolviert? Wieviel kann laut Prognosen und Velocity-Kennzahlen eingeplant werden? Wie ist die Kapazität des Teams? Der PO stellt in der Regel die Priorisierung vor und die anderen Mitglieder des Scrum-Teams geben eine Einschätzung ab, was erledigt werden kann unter der Einschätzung des Scrum Masters, der beispielsweise die Kapazität kennt. Kommt man auf einen gemeinsamen Nenner, kann der Sprint gestartet werden. Der Sprintwechseltag ist meistens der Meeting-reichste und sorgt dafür, dass sich die Entwickler den Rest der Zeit auf die Umsetzung der Story konzentrieren können mit allem was dazu gehört. Was noch dazu gehört? Automatisierte Tests beispielsweise, PoCs (Proof of Concept) unter Einbeziehen neuer Technologien und was der Sprint eventuell noch so alles hergibt.

Wir haben euer Interesse für Scrum geweckt? Dann schaut doch mal bei unseren anderen Beiträgen aus der Reihe Scrum in der Praxis vorbei.

Scrum in der Praxis: Teil 1, der erste Sprint
Scrum in der Praxis: Teil 2, das Sprintende
Scrum in der Praxis: Teil 3, die Retrospektive oder Lego-Duplo am Arbeitsplatz

 

Advertisements

Scrum in der Praxis: Teil 3, die Retrospektive oder Lego-Duplo am Arbeitsplatz

In unserer Rubrik Tech Talk stellen Thomas und Mandy euch heute wieder eine Situation aus dem agilen Umfeld vor, diesmal die Retrospektive. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

ThomasWolf-0791

Würde man ein Scrum-Lehrbuch aufschlagen, würde man sicher auf den ersten Seiten darüber lesen, dass dieses Rahmenwerk auf der empirischen Prozessteuerung basiert. Das heißt im Grunde, dass Scrum von drei Säulen getragen wird – Transparenz, Anpassung und Überprüfung. Dementsprechend sind auch die verschiedenen Events, die bei Scrum vorgesehen sind, aufgebaut. Eines der wichtigsten Events stellt dabei die Retrospektive dar. Hier werden Themen aus dem Projektalltag des letzten Sprints reflektiert, Problemstellungen identifiziert und Verbesserungen erarbeitet. Oder anders gesagt, man wertet die „Lessons learned“ aus.

Was nicht mehr so genau im Lehrbuch stehen würde, ist der Verlauf der Retro. Da gibt es einige erprobte Methoden um Verbesserungspotentiale zu identifizieren. Die klassische Methode gliedert sich in 5 Phasen:

1. Set the Stage – Rahmenbedingunen schaffen

  • Eine Athmosphäre schaffen, wo sich die Teammitglieder wohl genug fühlen, um offene Punkte zu diskutieren

2. Gather Data – Informationen sammeln

  • Ein Rückblick bei dem man identifiziert, was gut lief und was hätte besser laufen können

3. Generate Insights – Erkentnisse entwickeln

  • Die tatsächliche Ursache erkennen

4. Decide what to do – Entscheiden was zu tun ist

  • Entscheidungen über konkrete Maßnahmen treffen, die im kommenden Sprint umgesetzt werden

5. Close Retrospektive – Abschluss

  • Dokumentation der Ergebnisse und Planung weiterer Schritte

Jetzt stellt euch vor, ihr befindet euch in der Phase „Gather Data“ und euer Scrum Master kommt und kippt einen großen Haufen Duplo-Steine (Kinder-Lego) vor euch aus. Im ersten Moment erscheint das größte Problem zu sein – „Was sollen wir mit diesem Kinderspielzeug anfangen?“ und „Wie soll es behilflich sein damit Themen aus dem letzten Sprint zu sammeln“. Zusätzlich gibt es bei dieser Art der Retro noch ganz andere Herausforderungen. Und zwar sind es die anderen Kollegen, die an dem Meetingraum vorbei laufen und duch die Glastüren neidisch zu schauen beziehungsweise sogar fragen ob sie mitspielen dürfen.

Scrum-Retrospektive

Natürlich ist der Sinn des Ganzen nicht mit den Duplo Steinen zu spielen. Es dient dazu in den unorthodoxen Ecken des Geistes nach Problemen zu suchen – also „Outside of the box“ zu denken. Denn was wir brauchen, und nicht nur in Scrum, sind kreative Mitarbeiter, die eigenständig und mit Freude helfen ihre eigene Arbeit zu verbessern. Dementsprechend soll die eigene Kreativität herausgefordert werden den Verlauf eines normalen Softwareentwicklungs-Zyklus mit Duplo-Steinen darzustellen. Dabei variieren die Ergebnisse von einfachen Würfeln bis hin zu komplexen Freizeitparks. Das Wichtige dabei ist natürlich nicht das eigentliche Bauwerk sondern die Interpretation dahinter und die Thematiken, die sich daraus ableiten lassen.

Grundsätzlich stellt diese Methode eine gute Möglichkeit dar, den Prozess aufzulockern und frischen Wind in das Team zu bringen. Die Atmosphäre wird positiv beeinflusst, das Team hat Spaß und wird auf eine neue Art und Weise gefordert. Außerdem können durch diese Vorgehensweise am Ende Themen hervortreten, die im normalen Prozess nicht aufgetaucht wären. Trotzdem sei abschließend zu bemerken, dass bei dieser Variante auch eine gewisse Gefahr mitschwinkt. Sie sollte eher bei erfahrenen Teams, die mit den Scrum-Prozessen bereits sehr vertraut sind, Anwendung finden als bei Teams, die gerade erst frisch mit Scrum anfangen. Denn durch den Spielcharakter, kann die Konzentration schnell abschweifen und das gesamte Vorgehen verliert an Sinnhaftigkeit und wird nicht ernst genommen. Deswegen lieber als Highlight in den altbekannten Standard-Retrospektiven-Rhythmus einbauen und das Team aus seiner Komfortzone locken.

IBM Watsons Oscar-Gewinner-Vorhersage im Realitätscheck

Wie ihr vermutlich mitbekommen habt, werden sich die Größen des amerikanischen Filmgeschäfts am 4. März 2018 wieder zur Prämierung ihrer Besten treffen. Jährlich wird den besten Schauspielern, Filmen, Regisseuren und Vertretern der Filmtechnik die berühmte Oscar-Trophäe für ihre herausragenden Leistungen verliehen.

Die Verleihung findet jetzt schon seit 90 Jahren statt und erfreut sich großer Beliebtheit. Doch kann man nicht die Vermutung anstellen, dass sich langsam ein gewisses Muster abzeichnet? Sind die Gewinner der „Academy Awards“ vielleicht sogar vorhersehbar?

Genau diese Frage stellten sich IoT-Kollegen auch. Kann „IBM’s Watson Personality Insights“ dabei helfen den Gewinner des „Best Picture“-Oscars zu bestimmen? 2017 wagten sie den Versuch den Ausgang der Verleihung mithilfe von IBM Watsons Analysefähigkeiten vorherzusehen. Doch wie gingen sie vor?

Sie ließen ihn die Skripte der letzten 10 „Best Picture“-Gewinner analysieren und verglichen sie mit den 9 aktuell nominierten Filmen. Die Ergebnisse, in Form einer „Sunburst-Visualisierung“ (Beispiel siehe Bild unten), sollten gemeinsame Merkmale der Gewinner-Filme aufzeigen und ein Muster erkennen lassen.

IBMWatson-TheBossBaby-Analysis

Als aktuelles Beispiel, die Analyse des Films „The Boss Baby“ mittels „IBM’s Watson Personality Insights“.

Nach den Analysen und Interpretationen bedeuten die Werte folgendes für den Gewinnerfilm. Er nutzt Fantasie, um eine reichere und interessantere Welt zu erschaffen. Er würde die intellektuelle Neugier mit Symbolik herausfordern und sich den Hochs und Tiefs des Lebens stellen können. Außerdem würde er Traditionen achten und damit ein Gefühl von Stabilität vermitteln, aber auch Mitgefühl erzeugen aufgrund des hohen Sympathie-Levels.

Nachdem also alle Visualisierungen auf die besagten Faktoren analysiert wurden, konnte eine Annahme getroffen werden. Die Trophäe für die Kategorie „Best Picture“ hätte somit an den Film „Hacksaw Ridge“ vergeben werden müssen. Sein stärkster Konkurrent war „Arrival“, dessen Werte nur um ein paar Prozente daneben lagen.

Doch kommen wir nun zum Realitätscheck. Der 89. Academy-Award in der Kategorie „Best Picture“ ging an „Moonlight“, einem Film, der nach Watsons „Sunburst-Visualisierung“ eher eine Außenseiter-Chance hatte. Schade, da lagen wir mit unserer Interpretation der Gewinner-Muster etwas daneben. Es scheinen also noch mehr Faktoren eine Rolle zu spielen, die wir mit IBM Watson nicht analysieren können. Beispielsweise beeinflussen die aktuelle, politische Lage, die Rollenbesetzung oder auch die visuelle Umsetzung das Ergebnis.

Doch eigentlich ist es auch beruhigend zu wissen, dass wir immer noch überrascht werden können und noch nicht jedes Ereignis vorhersehen. Dementsprechend müssen wir uns auch keine Gedanken machen, dass die  Filmemacher im letzten Jahr nur einem bestimmten Algorithmus gefolgt sind, in der Hoffnung dadurch die begehrte Trophäe zu gewinnen. Sondern nach wie vor Kreativität im Vordergrund steht und man seine Ideen frei entfalten kann.

Wir wünschen euch auf jeden Fall viel Spaß bei der 90. Oscarverleihung und hoffen, dass ihr Dank flexibler Arbeitszeiten am nächsten Tag etwas später erscheinen könnt. 😉 Und abschließend eure Vorhersage – was glaubt ihr welcher Film dieses Jahr den „Best Picture“-Award gewinnen wird?

Informatik: Im Wechselbad der Gefühle

Das MINTLOOK-Projekt wird an der Technischen Hochschule Brandenburg angeboten und ist ein duales Probestudium. Jungs und Mädchen haben die Möglichkeit innerhalb von 9 Monaten drei Praktika in den Fachrichtungen Mathematik, Informatik, Naturwissenschaft und Technik zu besuchen. Darüber hinaus können sie an den Veranstaltungen der TH Brandenburg in den MINT Fachbereichen teilnehmen.

IBMClientInnovationCenter_Mintlook3Wir, Niklas und Natalie, konnten ab Dezember drei Mal pro Woche einen Einblick in die Softwareentwicklung im IBM Client Innovation Center gewinnen. Die anderen zwei Tage besuchten wir Vorlesungen an der TH-Brandenburg.

Wie wurden wir auf das MINT-Projekt aufmerksam?

Da wir uns nach dem Abitur noch unsicher waren mit unserer Studienwahl, haben wir uns nach einer Möglichkeit umgesehen verschiedene Berufsfelder und Studienrichtungen kennenzulernen. Durch die stadteigene Homepage von Brandenburg an der Havel und durch die Studien- und Ausbildungsmesse in Berlin, sind wir letztendlich auf das Projekt MINTLOOK gestoßen.

Was sind unsere Aufgaben im CIC?

Da wir beide keinen Informatikunterricht in der Schule hatten, kamen wir ohne Vorkenntnisse ins CIC. Die ersten zwei Woche bestanden darin, dass wir uns mit einigen Tutorials auf die bevorstehenden Wochen vorbereitet haben. Außerdem erhielten wir einen Überblick vom CIC und über verschiedene Projekte. Nachdem wir in den Webtechnologien, wie JavaScript, HTML und CSS, theoretisch fit waren, konnten wir mit unserem ersten eigenen Projekt durchstarten. Nun brauchten wir nur noch eine Idee. Nach einigen Tagen Brainstorming entschlossen wir uns für das Gefühlstagebuch VIBES. Über die Feiertage entwickelten wir dazu erste Designentwürfe, sodass wir mit dem Jahresstart endlich mit der Umsetzung loslegen konnten. Nach viel Spaß, aber auch Schweiß und Tränen sind wir nun stolz unser Emotionstagebuch erfolgreich umgesetzt zu haben und unseren Betreuern vorstellen zu können.IBMClientInnovationCenter_Mintlook2

Was gefällt uns besonders gut im CIC?

Sobald wir ein Problem haben, können wir hier jeden Kollegen fragen. Wir werden wie echte Mitarbeiter behandelt und können uns und unsere Ideen jederzeit einbringen.

Das Arbeitsklima ist sehr angenehm und wir fühlen uns hier wirklich willkommen. Ein weiterer Punkt ist, dass wir sehr selbstständig arbeiten und uns sehr viel Vertrauen entgegen gebracht wird, sodass wir flexible Arbeitszeiten und Homeoffice nutzen konnten.

Was nehmen wir generell aus der Erfahrung im CIC mit?

In den letzten drei Monaten, haben wir gelernt selbstbewusster durch das Leben zu gehen. Es ist besser, Fragen zu stellen anstatt ewig über ein Problem zu grübeln. Außerdem haben wir hier gelernt, dass ein gutes Arbeitsumfeld eine Menge ausmacht. Da wir freundlich empfangen und auch weiterhin super aufgenommen wurden, haben wir uns auf unsere Tage im CIC gefreut, trotz der 8-Stunden-Tage.  Vor Allem aber haben wir erkannt, dass Informatik weit mehr ist, als nur monotones Programmieren und sogar richtig Spaß macht.

Haben uns die Erfahrungen im CIC bei der Studienwahl geholfen?

Wir haben viele Einblicke in Projekte, Projektarbeit und die Softwareentwicklung gewinnen können. Das eigenständige Arbeiten ließ uns dabei in verschiedene Rollen schlüpfen, zum Beispiel Projektkoordination, Design und Entwicklung.

Niklas sieht die Programmierung später eher als Hobby. Ich, Natalie, war mir ursprünglich sicher, dass mein Weg nicht in die Informatik geht. Allerdings macht es mir inzwischen so viel Spaß, dass ich es mir für meine berufliche Zukunft vorstellen kann.

IBMClientInnovationCenter_Mintlook5

 

 

Scrum in der Praxis: Teil 2, das Sprintende

In unserer Rubrik Tech Talk stellen wir euch heute wieder Situationen aus dem agilen Umfeld vor. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Agile Softwareentwicklung ist der neuste Schrei. Nicht selten kommt es in der Industrie vor, dass sich Unternehmen mit dem Label „Agile Softwareentwicklung“ schmücken wollen. Gerade im Bereich Scrum wird viel Schindluder getrieben. Ob dies nun aus Unkenntnis oder Täuschung gemacht wird, möchte ich an dieser Stelle nicht bewerten.

Daher verwundert es auch nicht, dass man auf Portalen, wie http://thedailywtf.com oder https://www.reddit.com/ oder auch den zahlreichen kleinen Blogs viele negative Erfahrungsberichte zum Thema Agile Entwicklung liest. Agiles Entwickeln ist eine Idee. Scrum ist ein konkretes Rahmenwerk, dass der agilen Idee folgt und Scrum wird in diesem Beitrag auch im Zentrum stehen.

Dieser Beitrag wird exemplarisch ein Review am Ende eines Entwicklungszyklus (Sprint) beschreiben. Alle Elemente darin habe ich persönlich regelmäßig in Projekten erlebt und stufe sie als ganz normale Ereignisse im Leben eines Scrum-Teams ein. Dieses konkrete Meeting ist jedoch fiktiv.


Alex, Barbara, Carlo, Diana: Softwareentwickler
Masami: Scrum-Master
Polly: Product Owner


 

Im Büro.

Masami: Alex, kommst du, das Review fängt gleich an. Wir sind heute im Raum 2.02.

Alex: Ich habe gerade noch einen Bug gefunden, der sich bei unseren Tests versteckt hatte. Wenn ich das jetzt nicht noch schnell behebe, können wir diese Anforderung nicht abgeben.

Masami: Das ist ärgerlich. Komm jetzt aber ruhig trotzdem mit ins Meeting. Polly soll dann entscheiden, ob sie die Story annimmt oder nicht. In zwei Minuten geht es schon los.

Alex: So ein blöder Fehler! Ja, ich komme.

Im Meetingraum, zum Sprint Review.

Masami: Willkommen beim Review von Sprint 15. Die letzten zwei Wochen haben wir an einigen neuen Features und Bugfixes gearbeitet. Alex, würdest du gleich anfangen?

Alex: *nickt* Ich habe die Story NPE-1232 bearbeitet. Dafür sollten wir einen Loginbildschirm für die Applikation schreiben. Aktuell kann jeder die Applikation benutzen. In Zukunft muss man sich mit Nutzer und Passwort einloggen um den Zugriff mit der steigenden Mitarbeiterzahl besser kontrollieren zu können. Ich demonstriere das mal kurz auf dem Beamer. Leider ist uns aber noch ein Sonderfall erst kurz vor dem Review aufgefallen. Wenn im Nutzernamen oder Passwort ein Sonderzeichen ist, wird es in einer falschen Kodierung ans Backend geschickt und der Loginversuch schlägt fehl. Das kann im schlimmsten Fall zur Accountsperrung führen.

Polly: Dass wir den Login ändern, ist sehr zeitkritisch. Eigentlich wollten wir die Änderungen kommende Woche schon ausrollen. Bis zum Ende des kommenden Sprints können wir nicht warten.

Alex: Das Problem zu beheben ist kein großer Aufwand. Ich gehe davon aus, dass ich das bis zum Ende des Tages abgeschlossen habe.

Polly: Sehr gut, so lange du die Version bis Freitag auslieferst, reicht mir das.

Masami: Einen Moment, lasst uns das lieber nachher im Planning besprechen. Wenn das Team dem zustimmt, schieben wir gerne noch eine Zwischenlieferung ein. Wir sollten uns jetzt aber erst einmal auf die Stories des vergangenen Sprints konzentrieren.

Polly: Das ist in Ordnung. Da die Anforderungen nicht vollständig umgesetzt sind, nehme ich die Story nicht ab und wir schauen dann nachher beim Planning weiter.

Barbara: Dann mache ich einmal weiter. Ich habe die Story NPE-1233 bearbeitet. Da ging es darum, einen Report von allen Nutzern zu erzeugen, die aktuell Zugriff auf die Applikation haben und ein Datenbankscript anzulegen, welches all diesen Nutzern Accounts für das neue Login anlegt. Ich habe das Script auch schon an das Betriebsteam übergeben und sie waren zufrieden. Ich hatte dich bei der Mail auch in den CC gesetzt, Polly.

Polly: Ja, die Mail hatte ich gesehen. Die Story ist abgenommen.

Carlo: Dann mache ich direkt weiter. In NPE-1256 ging es darum, den Bug im Detailreiter zu beheben, dass lange Titel rechts aus dem Bildschirm rausragen und somit abgeschnitten sind. Auf dem Beamer ist gerade unsere alte Version zu sehen. Ich gehe mal zur Detailseite. Hier sieht man den abgeschnittenen Titel. Jetzt öffne ich die neue Version und gehe zur gleichen Detailseite. Hier sieht man jetzt, dass der Titel umgebrochen ist.

Polly: Hmm, aktuell ist der Titel mitten im Satz umgebrochen. Kann man das nicht so machen, dass zuerst versucht wird nur bei einem Satzende umzubrechen? Das würde es etwas lesbarer machen.

Carlo: Das war in diesem Sprint nicht Teil der Anforderungen. Das können wir aber gerne mit einer neuen Story noch umsetzen.

Polly: Gut, dann lege ich dafür einen neuen Eintrag im Ticketsystem an.

Masami: Da die Anforderungen für diese Story umgesetzt sind, nimmst du die Story ab, Polly?

Polly: Ja, ist abgenommen.

Diana: Ich stelle NPE-1244 vor. Ich hatte dir ja gestern schon geschrieben, dass wir den Aufwand leider unterschätzt hatten und daher nicht fertig geworden sind. Hier sind auch noch größere Restaufwände zu leisten.

Polly: Woran hing es denn?

Diana: Ich kann ja mal kurz den Code an die Wand werfen. Die Klasse ist unglaublich lang und allein die Methode „perform“…

Masami: Ich glaube das führt jetzt gerade etwas zu weit. Kannst du das Problem kurz zusammenfassen? Polly, falls du darüber hinaus noch mehr Details möchtest, kannst du im Nachgang noch mit den Leuten reden, die an der Story gearbeitet haben. Dann kann der Rest des Teams schon weiterarbeiten.

Diana: Die Komponente, die wir dafür anfassen mussten, ist sehr fragiler Legacy-Code. Wir haben ein paar kleine Änderungen gemacht und plötzlich ging die halbe Applikation nicht mehr. Umbaumaßnamen und Tests sind fertig aber die eigentliche Arbeit haben wir noch nicht begonnen.

Polly: Hättet ihr es nicht ohne die Umbaumaßnamen geschafft?

Carlo: Das war uns zu riskant. Ich habe auch mit draufgeguckt und der Umbau war längst überfällig.

Polly: Na gut, zumindest ist mir dieses Szenario lieber, als wenn die Probleme erst in der Produktion auftauchen.

Masami: Gut, die halbe Stunde für unser Meeting ist auch gleich rum. Falls es keine weiteren Punkt gibt, gehen wir jetzt etwas früher in die Mittagspause und treffen uns anschließend zur Retrospektive um 13:30 Uhr wieder hier.


 

Maximiere die Arbeit, die nicht getan wird, ist Teil des agilen Manifests. Das bedeutet, überflüssige Meetings und Arbeiten, die dem Projekt keinen Mehrwert bringen zu streichen. Das bedeutet auch, dass bei den notwendigen Meetings nur die Personen anwesend sind, die benötigt werden. Bei agiler Entwicklung dreht sich daher viel um die Eigenverantwortlichkeit des Teams und seiner einzelnen Mitglieder. In der Konsequenz bedeutet das, dass das ganze Team engen Kontakt zu Polly hat, die selbst zur Organisation des Kunden gehört. Spätestens alle zwei Wochen sieht Polly also live die Arbeitsergebnisse des Teams. So kann sie frühzeitig erkennen, ob der Umbruch des Titels passt oder ob in den Anforderungen, die sie geschrieben hat, noch ein Detail fehlte. Als Product Owner kann sie sich jetzt überlegen, wie hoch sie die Änderung priorisiert um den Mehrwert der Applikation zu maximieren. Von der Priorität hängt dann ab, ob die neuen Anforderungen in den kommenden zwei Wochen umgesetzt werden, oder erst in einem späteren Zyklus – oder ob sich bis dahin vielleicht zeigt, dass diese Umsetzung sich nicht lohnt.

Sie hat die Finger am Puls des Projekts und da sie selbst zum Kunden gehört, sind keine überschweifenden Reports notwendig was den Fortschritt des Teams angeht. Mit jeder abgenommenen Story ist messbar wieviel näher man dem nächsten Meilenstein gekommen ist. Scrum ist dabei jedoch keine Anarchie. Wir als Entwickler übernehmen Verantwortung für die Anforderungen, die wir einmal in einen Sprint aufgenommen haben. Wie wir diese Anforderungen konkret umsetzen, entscheiden wir dann jedoch eigenständig. Diese Freiheit weiß ich sehr zu schätzen. Die Meetings im Rahmen von Scrum sind überschaubar und Masami achtet darauf, dass der Prozess nicht ausartet und hält externe Störungen und Produktivitätskiller fern.

Wenige, kurze, sinnstiftende Meetings, viel Eigenverantwortlichkeit, häufig Feedback zur eigenen Arbeit und kontrollierte, kleine Kurskorrekturen seitens des Kunden sind es, die für mich Scrum ausmachen und mir einen angenehmen Arbeitsalltag verschaffen.

Scrum in der Praxis: Teil 1, der erste Sprint

In unserer Rubrik Tech Talk stellen wir euch heute und in weiteren Beiträgen eines der bekanntesten agilen Frameworks vor – Scrum. Damit wollen wir euch einen Einblick in den Projektalltag vieler unserer Kollegen geben und die unterschiedlichen Phasen dieser Entwicklung erklären. Ihr habt noch nie in der agilen Entwicklung gearbeitet? Dann folgt aufmerksam unserer Reihe „Scrum in der Praxis“.

Viele von uns waren bereits Teil von Scrum-Teams und in der agilen Entwicklung beschäftigt. Wir haben in Retrospektiven, Refinements, Plannings und im Sprint-Verlauf allgemein Sicherheit gewonnen. Trotzdem gibt es Ausnahmesituationen, die selbst im strukturierten, agilen Vorgehen Unsicherheit auslösen und wie Corner Cases eines ansonsten klaren Ablaufs wirken. Am Anfang war der Anfang und die Frage: Wie fängt man eigentlich an? Wenn nichts da ist, Boards und Diagramme noch leer? Wir kennen das Schätzen und Schneiden innerhalb unseres Backlogs, das Verfeinern. Und dank unserer Velocity haben wir eine Maßgabe wieviel wir in den nächsten Sprint einplanen. Aber wie geht man vor, wenn es keinen vorhergehenden Sprint und keine Velocity gibt? Wir reden von einem Fabelwesen, dem man nicht oft beiwohnen darf: dem ersten Sprint.

Antipattern und agiler Mythos: Sprint 0

Aber ja, es gibt sie, die ersten Sprints. Nur der Mythos vom Sprint 0 sollte besser ein Mythos bleiben. Nach Lehrbuch ist kein Sprint 0 vorgesehen, trotzdem poppt er immer mal wieder auf. Inzwischen wird der Sprint 0 sogar oftmals als Anti-Pattern bezeichnet. Unter der Annahme, dass man in einem Sprint 0 vorbereitende Aufgaben erledigt, schleichen sich meistens die ersten Verfälschungen einer Schätzung ein. Was sind solche vorbereitenden Aufgaben? Erste Meetings aufsetzen und daran teilnehmen, eine Entwicklungsumgebung einrichten? Meetings und Setups oder sonstige technische Checks sind Aufgaben, die in jedem Sprint auftreten (können) und womit man immer rechnen darf. Jeder Sprint soll Mehrwert für den Kunden erzeugen. Tut es das nicht, dann ist es kein Sprint. Daher ist es laut Lehrbuch nicht richtig von Sprint 0 zu sprechen, wenn man in diesem rein administrative und planerische Aufgaben übernimmt, bei denen kein Deliverable für deinen Kunden entsteht. Gibt es Aufgaben für das Team: dann ist es ein regulärer Sprint, eben Sprint 1. Unser Deliverable, unser Ergebnis, ist beispielsweise die funktionierende Entwicklungsumgebung, ein Teil der Dokumentation und wahrscheinlich erste kleine Tasks, die einen sichtbaren Mehrwert für den Kunden erzeugen. Wer seinen ersten Sprint aber gerne bei null anfangen möchte zu zählen, kann das tun, solange ein Deliverable entsteht. Wir Informatiker sind es ja gewöhnt bei null anzufangen zu zählen ;). Trotzdem bleiben die Unsicherheiten: wieviel gehört in so einen ersten Sprint? Die Antwort klingt fast zu einfach: das was nötig ist und das was möglich ist.

Der erste Sprint

Ohne eine Velocity oder die Erfahrung vorhergehender Sprints und was man sich zutrauen kann, muss man quasi zurück zu den Wurzeln und überlegen: was brauche ich, um zu starten und wieviel Zeit kostet mich das? Ein Beispiel: Alle Entwickler setzen beispielsweise einen Tag lang ihre Entwicklungsumgebung auf, werden x Tage eingewiesen in das Programmiermodell und -vorgehen (Know your tools, Server, wie delivern, Definition of Done, Definition of Ready und wie läuft die Code Review ab? Was sind die Programmierrichtlinien und wie sieht die Qualitätssicherung und Test aus?) und je nach Länge des Sprints: welche ersten Aufgaben können zeitlich dann noch absolviert werden? Im ersten Sprint ist es valide nicht zu viel einzuplanen, sondern erstmal tief zu stapeln. Eine Story nachzunominieren und nach Start des Sprints noch nachträglich mit einzufügen, ist zwar für „Scrum nach Lehrbuch“-Fans nicht valide, aber im ersten Sprint sicherlich verkraftbar. Wer beim ersten Schätzen unsicher ist, kann sich bei erfahreneren Entwicklern Hilfe suchen und sehr transparent schätzen. Also „laut denken“. Hilfreich kann es sein zusammenzutragen, wieviel unterschiedliche Technik dafür angefasst werden muss. Habe ich Änderungen in der Datenbank bzw. der Persistenz allgemein? Oder ist es nur Businesslogik? Muss ich nur Tests schreiben oder ein ganzes Test-Framework aufbauen (schließlich sind wir am Anfang). Falls erfahrene Entwickler nicht da sind oder die Schätzung zu unscharf wirkt, kann sogar erstmal eine ganz andere Schätzmethode mit weniger Kategorien verwendet werden wie T-Shirt-Sizes (Story-Größen S, M, L, XL). Generell gilt aber: was die Schätzgrößen bedeuten (also wie komplex beispielsweise 5 Story Points sind), bestimmt das Team. Dafür gibt es keine allgemeingültige Antwort, weswegen im ersten Sprint auch manchmal einfach das berühmte Bauchgefühl reicht. Bei so viel Unschärfe ist klar: in Sprint 1 kann man daneben liegen. Die Korrektur erfolgt mit der Erfahrung ab dem zweiten Sprint und hilft für die Zukunft.

Tipps für den zweiten Sprint

Die Story und die jeweilige Schätzung des ersten Sprints, sollte als Referenz herangezogen werden. Best Practice ist, sich eine Liste sortiert nach Story Points anzulegen, die als Referenz-Storys dienen. So bekommen alle in Zukunft ein Gefühl dafür, was beispielsweise 5 Story Points bedeuten, wie komplex sie sind und wie solche Storys ungefähr aussehen. Lag man daneben und hat länger als erwartet gebraucht, war die Aufgabe also komplexer, dann kann das bei der Erstellung der Referenz berücksichtigt und korrigiert werden.

Falls du noch mehr über den ersten Sprint erfahren möchtest, kannst du hier weiterlesen:
Official Scrum Guide (scrum.org)
Your first agile sprint: A survival guide (TechBeacon)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (scrum.org Blog)

 

Von Null auf IoT mit Bluemix

„Von Null auf IoT mit Bluemix.“ – So könnte man den zweiten Watson-IoT-Workshop bestens zusammenfassen. Der fünftägige Kurs fand Ende März zusammen mit Studenten aus Sachsen-Anhalt und einigen Mitarbeitern des CIC Magdeburg statt. Da der nächste Workshop schon auf der Agenda steht, werden wir an dieser Stelle ein wenig aus dem Nähkästchen plaudern, damit sich künftige Interessenten bzw. Teilnehmer ein gutes Bild vom Inhalt machen können.

Nachdem wir im Vorfeld auf den Workshop aufmerksam gemacht haben, konnten wir insgesamt 14 Teilnehmer begrüßen. Um zunächst das Eis zu brechen, stand als Erstes eine Vorstellungsrunde auf der Agenda. Im Anschluss daran wurde das Thema „IoT – Internet of Things“ anhand vieler Beispiele eingeführt. Damit die Teilnehmer ihre Ideen innerhalb dieser Woche umsetzen können, wurde im Verlauf des ersten Tages zum einen die Cloud Plattform „Bluemix“ die zu nutzenden Services „Watson-IoT-Platform“, „Node-Red“ und diverse „Watson-Services“ und zum anderen verschiedene Hardware, beispielsweise Rasberry Pi  (RasPi) und der passende Sense Hat, vorgestellt sowie eingerichtet. Mit diesem Know-how war es im Laufe des Nachmittags möglich einen Datenfluss vom Device (Datenerzeugung) über die Watson-IoT-Platform (Registrierung) und Node-Red (Verarbeitung) bis hin zur Outputkanal der Wahl (z.B. Twitter, RasPi) zu erstellen.

Wem sich das nach viel Programmierkenntnissen anhört, dem sei versichert, dass für die Umsetzung mit diesen Mitteln lediglich etwas JavaScript benötigt wird. Da bei so viel Theorie und neuen Sachen der Kopf ordentlich raucht, haben wir in diesem Kontext auch für kleine Übungen gesorgt, sodass zum Beispiel einige Lacher beim Anbinden und herumspielen mit den RasPi’s garantiert waren.

Mit dem Wissen aus dem Einführungstag ging es am nächsten Morgen in die Ideenfindung, sodass die verschiedenen Gruppen im Anschluss ihre Ideen in einer Präsentation vorstellten. Diese waren:

  • Swarm Tracker: Innerhalb einer Gruppe erhält der Gruppenleiter eine Warnung auf die Hand, wenn sich ein Mitglied zu weit von der Gruppe entfernt.
  • Blumen Bernd: Auf Grundlage der Wettervorhersage werden Pflanzen, bei entsprechender Notwendigkeit, bewässert.
  • Der smarte Einkaufwagen: Dieser liefert während des Einkaufs Informationen über die Produkte, die in den Korb gelegt wurden. Dies können neben Menge, Preis, Summe auch Informationen über diverse Allergene sein. Darüber hinaus ist auch bargeldloses Zahlen mit dieser Anwendung möglich.

Nachfolgend starteten die Teams in die Umsetzung ihrer eigenen kleinen Projekte und wir, die Kursleiter, waren unterstützend tätig, halfen bei Fragen, Recherchen zu diversen Schnittstellen etc.

Der fünfte und letzte Tag stand ganz im Zeichen der Abschlusspräsentationen. Neben Bugfixing am Morgen wurden Folien und die Präsentationen vorbereitet, sodass am Nachmittag jedes Team ihre Idee, Architektur und Demo vorgestellt hat. Im Anschluss daran konnten die Teilnehmer ihre Zertifikate in Empfang nehmen.

Alles in allem war es aus unserer Sicht ein erfolgreicher Workshop. Ohne übermäßig viel Vorwissen auf dem Gebiet waren alle Teilnehmer in der Lage innerhalb von wenigen Tagen eine eigene IoT-Idee erfolgreich zu entwickeln. Wir freuen uns auf den dritten Workshop. 🙂