Gerrit Beine http://gerritbeine.com Software-Architektur & Agile Methoden Tue, 30 Jun 2015 19:52:40 +0000 de-DE hourly 1 Doch, das geht schon so. Eine Lanze für agile Job-Titel. http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/ http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/#comments Fri, 26 Jun 2015 11:07:48 +0000 https://gerritbeine.com/?p=394 Weiterlesen ]]> Im Laufe der Woche kam ein Artikel von Patrick Koglin in meinem Newsreader reingeflogen. Patrick beschreibt die Verwendung von Bezeichnungen wie Senior Scrum Master oder Junior Scrum Master als schlimm. Ich lese Patricks Artikel gern und teile seine Meinung häufig, aber in diesem Fall muss ich vehement mein Veto einlegen.

Zunächst der Aspekt, in dem ich dem Artikel zustimme: Nur, weil ein Board im Raum steht, bin ich nicht agil. Agil ist eben nicht Cargo Cult, sondern eine echte Kultur, ein Mindset. Ebenso denke ich, dass in einem agilen Team einem jungen Entwickler ebenso zugehört werden muss, wie der erfahrenen Kollegin und beide auf Augenhöhe zusammenarbeiten sollten. Gleiches gilt für Scrum Master, Product Owner und jeden Manager. Sowohl innerhalb eines Teams als auch in der Umwelt.

Dafür muss ich aber nicht agil sein, das ist schlicht und einfach der Respekt vor anderen Menschen, der diese Sichtweise gebietet.

Der Aspekt, bei dem ich grundlegend anderer Meinung bin, ist, dass es keine Senior oder Junior Scrum Master als Job-Bezeichnung geben darf. Ich bin der Meinung, dass so etwas völlig ok ist und viele Organisationen es sogar unbedingt benötigen. Ich zitiere gerne Tucholsky mit  „Erfahrung bedeutet nichts, man kann eine Sache auch dreißig Jahre lang schlecht machen.“ Für mich bedeutet das, dass Bezeichnungen wie Senior nicht an das Dienstalter gekoppelt sein dürfen.

Menschen orientieren sich an solchen Bezeichnungen, sie sind Teil der Struktur einer Organisation. Wenn ich dieses Argument aus dem Hut ziehe, kommt meistens das Gegenargument, dass in solchen Organisationen die Kultur kaputt sei. Und das ist  in meinen Augen schlimm.

Ich finde es völlig ok, zwischen Junior und Senior Scrum Mastern zu unterscheiden. Der Junior Scrum Master ist einer, dem ich helfe, großartig zu werden. Der Mensch ist es schon, der Scrum Master muss einiges erleben. Und damit der Scrum Master das kann, bekommt er Unterstützung von einem Senior, der schon war, wo der Junior noch hin will. So einfach ist das.

Und ja, ich finde es absolut gerechtfertigt, wenn jemand stolz darauf ist, ein Senior Scrum Master zu sein und sich diese Bezeichnung verdient hat, indem er ganz viele Teams großartig gemacht hat und jede Menge unerfahrene Scrum Master an seinem Wissen und Können hat teilhaben lassen. Das ist Agilität.
Die Ablehnung von Job-Titeln aus Prinzip ist hingegen Cargo Cult.

]]>
http://gerritbeine.com/2015/06/doch-das-geht-schon-so-eine-lanze-fuer-agile-job-titel/feed/ 2
User Experience – ein cooles Thema http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/ http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/#comments Mon, 01 Jun 2015 18:09:49 +0000 https://gerritbeine.com/?p=389 Weiterlesen ]]> Ein Geschichte, wie sie jeden Tag passieren kann, wenn man als Consultant unterwegs ist: Mitten in der Nacht kommt man von einer langen Zugfahrt müde in sein Hotel. Vorher noch zehn Minuten durch den Regen gelaufen, ist man pitschnass. Der Checkin verläuft zäh wie üblich und dann erreicht man schlussendlich doch sein Zimmer.

Nur, dass es da tierisch kalt ist. Zum Zähneklappern kalt. Aber es ist zu spät, um mit der Rezeption zu diskutieren, also ab ins Bett, die zweite Decke drüber gezogen und Augen zu.

Nächster Tag. Nachfragen an der Rezeption, es ist kalt im Zimmer. Die Antwort ist nicht sonderlich befriedigend. Das sei normal, sagt man dort, denn die Heizung heizt nicht mehr sondern kühlt. Da es um diese Jahreszeit eigentlich warm sei, wäre das auch in Ordnung so. Und es ist kompliziert die Heizung umzustellen.

Was hat das mit User Experience zu tun? Ganz einfach: diese Heizungsanlage ist ein Beispiel für eine miserable User Experience. Vermutlich, weil hier der zentrale User bei der Erstellung gar keine Rolle gespielt hat. Der wichtigste User einer Heizung in einem Hotel ist der Gast. Und als Gast wünscht man sich, dass die Heizung heizt, wenn es draußen kalt ist. Und dass sie kühlt, wenn es draußen warm ist. Warmes und kaltes Wetter richten sich aber nicht nach dem Kalender. Wetter passiert einfach.
Der Hausmeister ist, auch wenn das vielleicht naheliegend ist, nicht der zentrale User der Heizungsanlage. Er bedient sie, aber das macht nur einen geringen Teil der Nutzung aus. Für ihn ist es bequem, dass die Heizung sich nach dem Kalender richtet, da muss er sich nicht darum kümmern. Für die Gäste ist es unbequem.

Was kann man aus dieser Erfahrung lernen? Ganz einfach: Es ist wichtig, die zentralen User eines Systems zu erkennen, auch wenn sie auf den ersten Blick nur passive Rollen spielen. Wenn deren User Experience miserabel ist, führt das zu Ablehnung des gesamten Systems. So auch heute früh an der Rezeption. Es haben sich viele Gäste beschwert.Man hätte auch eine Heizung mit Temperatursensor einbauen können. Aber davon hätte der Hausmeister nix gehabt.

]]>
http://gerritbeine.com/2015/06/user-experience-ein-cooles-thema/feed/ 1
Artikel über Antifragilität in der Softwareentwicklung http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/ http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/#comments Wed, 20 May 2015 14:34:06 +0000 https://gerritbeine.com/?p=377 Weiterlesen ]]> Im Business Technology Magazin 1.15 ist ein Artikel von mir zum Thema Antifragilität und deren Bedeutung für die Softwareentwicklung erschienen. Der gleiche Artikel steht seit gestern auf jaxenter.de zur Verfügung.

Die wissenschaftlichere Version davon, die Prof. Wolfgang Golubski und ich auf der Multikonferenz Software Engineering & Management vorgestellt hatten, ist ebenfalls online in der Electronic Library of Mathematics verfügbar.

Ich freue mich natürlich über Feedback!

]]>
http://gerritbeine.com/2015/05/artikel-ueber-antifragilitaet-in-der-softwareentwicklung/feed/ 0
Bertrand Meyer: Agile! The Good, the Hype and the Ugly http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/ http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/#comments Sun, 26 Apr 2015 08:54:00 +0000 https://gerritbeine.com/?p=321 Weiterlesen ]]> Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Das erste Buch, dass sich objektiv und neutral mit Agilität auseinandersetzt, ist mir natürlich eine ebenso objektive und neutrale Rezension wert – und ich werde sie inkrementell verfassen.

Nachdem ich in einem Kommentar zu einem infoQ-Artikel geschrieben habe, dass ich eine Rezension verfassen würde, bin ich gerade dabei das Buch zu lesen.

Eigentlich habe ich Bertrand Meyer immer geschätzt, seine Bücher über Objektorientierte Softwareentwicklung haben mich im Studium begleitet. Er gehörte zu den Großen.

Jetzt habe ich das erste Kapitel gelesen und muss feststellen: Meyer demontiert sich in unerhörtem Ausmaß selbst. Nicht nur, dass schon in der Einleitung deutlich wird, dass er die Grundlagen agiler Methoden nicht verstanden hat, er definiert vielmehr in einer Auflistung diverser Praktiken aus dem agilen Umfeld alles als „gut“, das seiner Meinung nach nicht aus der agilen Community entstammt und alles als „schlecht“, das seiner Meinung eben aus dieser Community kommt.

Dabei interessiert ihn nicht, ob die betreffende Praktik sich irgendwo bewährt hat (User Story) oder tatsächlich von Agilisten zuerst beschrieben wurde (Continuous Integration). Ersteres ist schlecht, weil das eben so ist, letzteres ist nicht neu, weil es gut ist und es damit nicht agile sein kann.

Ich bin jetzt erst mit dem ersten Kapitel durch und über alle Maßen enttäuscht. Ich lese in diesem Buch vor allem Frust, aber wenig Sachlichkeit.

Kapitel 2: Dekonstruktion agiler Texte

Weil es so spannend war, habe ich gestern auch noch das zweite Kapitel gelesen. Hier beschäftigt sich Meyer mit der Dekonstruktion von Texten aus dem Umfeld der agilen Community.

Und er macht den gleichen Fehler, den viele Dekonstruktivisten machen: Er verzirkelt sich. Um zu zeigen, dass solche Texte nicht aussagefähig sind, zieht er ein Zitat aus „Succeeding with Agile“ von Mike Cohn heran, in dem eine Anekdote zur Diskussion gesprochenes vs. geschriebenes Wort berichtet wird.
Meyer meint nun, das Cohn mit dieser Anekdote “beweisen“ wolle, dass das gesprochene dem geschriebenen Wort überlegen ist und folgert daraus, dass in der agilen Community anekdotische Evidenz als Beweismittel betrachtet wird. Das lustige hieran ist, dass Meyer selbst eine Anekdote (ich habe bei Mike Cohn gelesen…) als Grundlage einer Generalisierung heranzieht (…deshalb ist das in allen Texten von Agilisten so). Gänzlich lächerlich wird Meyers zynische Dekonstruktion aber, wenn man weiß, das Cohn gerade mit diesem Zitat nichts beweisen wollte, sondern genau das Gegenteil: einen vermeintlich bereits erbrachten Beweis (Geschriebenes ist klar und eindeutig) widerlegen wollte. Und dazu reicht eine einzige Anekdote eben aus. Das sollte Meyer als Wissenschaftler wissen.

Als Meyer dann noch meint, dass „in den meisten seriösen Projekten“ irgendwann alle Leute mal danach schreien, man möge „es“ doch aufschreiben, damit „alle“ die Chance hätten, „es“ zu verstehen und nachzuvollziehen, konnte ich nur noch den Kopf schütteln. In den seriösen Projekten, in denen ich war, erlebte ich, nach dem Dinge aufgeschrieben waren, sehr oft die Situation, dass Leute nach der Lektüre über einen Text sprechen wollten, um ihn richtig zu verstehen.

Für Meyer ist es jedenfalls keine Frage: Weniger reden, mehr schreiben. Das ist eindeutiger und sicherer. Mit eigenen Erfahrungen kann ich das nicht bestätigen. Ich habe das differenzierter erlebt: Schreibe so viel, dass man mit einem kurzen Gespräch Verstehen bei allen Beteiligten erreichen kann.

Ach, und eines hat Meyer auch nicht verstanden: In agilen Projekten brauchen wir deshalb keine Feinspezifikation, weil wir automatisierte Tests haben. Die sind zwar zwangsläufig immer nur Beispiele für Anwendungsszenarien, helfen aber Entwicklern beim Verstehen viel mehr als abstrakte und generische Anforderungen, wie Meyer sie favorisiert.

Meine Meinung zu dem Buch ist auch nach dem zweiten Kapitel nicht besser geworden. Das sind jetzt immerhin 28% – ich bin total auf den Rest gespannt.

Kapitel 3: Big Upfront Anything

Meyers Buch zu lesen wird nicht leichter. Im dritten Kapitel lässt er sich über die These aus, dass Agilisten ein Feindbild im Big Upfront Anything haben.

Er greift erneut auf das Mittel der Dekonstruktion agiler Texte zurück, diesmal mit dem Beispiel des ‚Slander by Association‘. Einige Seiten lang hält sich Meyer daran auf, zu dass Agilisten ‚Wasserfall‘ mit ‚Vorhersagend‘ gleichsetzen – er hat das in einem(!) Buch von Sutherland gelesen.

Neben der Notwendigkeit von Requirements, Architektur und CMMI, die Meyer vor allem mit ihrer Notwendigkeit begründet (Zirkelschlüsse hat er Agilisten bis zum dritten Kapitel noch nicht vorgeworfen), gibt es inhaltlich kaum Neues. Bemerkenswert sind seine Sprünge in der Abstraktionsebene. Einmal zeigt er anhand eines Code-Beispiels, wie wichtig es ist, dass das verwendete Pattern erkennbar (Meyer sagt: dokumentiert) ist – etwas, dem kein agiler Entwickler jemals widersprechen würde. An einer anderen Stelle wird deutlich, dass er das Konzept des Backlogs in Kombination mit schnellem Feedback nicht verstanden hat: In Meyers Welt werden im klassischen Requirements Engineering unnötige Anforderungen vor der Analyse aussortiert, wohingegen seiner Meinung nach im Agilen auf eine Analyse verzichtet wird und unnötige Requirements nach der Implementierung(!) wieder ausgebaut werden. Aus welchem Projekt auch immer er diese Erfahrung zieht: Es war nicht agil, so arbeiten wir nicht. Ein anderer Punkt, den Meyer kritisiert, ist das vermeintliche Verzichten auf Architekturarbeit vor der Implementierung. Auch hier folgt er seinem Prinzip: er beschreibt ein Extrem wo in der Realität Pragmatismus herrscht. Er verwechselt den Verzicht auf Unnötiges mit einem generellen Verzicht und verstrickt sich in der weiteren Argumentation in der selbst geschaffenen Konfusion.

Auch im dritten Kapitel tappt Meyer wieder in die methodische Falle, die er sich im zweiten Kapitel gebaut hat: Er kritisiert ein in seiner Wahrnehmung nach typisches Verhalten von Agilisten und zeigt selbst das gleiche Verhalten: Er argumentiert immer wieder, dass in Büchern und Veröffentlichungen über Software-Engineering niemand behauptete, Big Upfront Anything wäre eine Lösung. Niemand aus der Agilen Community kritisiert Bücher über Software Engineering. Agilität kritisiert den realen Projektalltag. Und der ist ganz häufig Plan-Driven Waterfall mit viel Big Upfront Anything, obwohl das kein Buch so empfiehlt.

Kapitel 4: Agile Prinzipien

Die agilen Prinzipien dekonstruiert Meyer indem er zeigt, dass sie einer allgemeinen Definition von Prinzip nicht genügen. Woher er seine Definition eines Prinzips nimmt, ist nicht referenziert, aber sie ist in seinem Sinne zweckmäßig. Wikipedia beschreibt ein Prinzip als Ursprung bzw. als Gesetzmäßigkeit, die anderen Gesetzmäßigkeiten übergeordnet ist und weißt explizit darauf hin, dass eine Gesetzmäßigkeit im Sinne eines Prinzips auch eine Regel sein kann. Im Folgenden nimmt er die Prinzipien auseinander und zeigt, inwiefern sie seiner Definition eines Prinzips widersprechen. Auch hier lässt er sich wieder auf diesen unsauberen Stil ein, der den Leser schon durch die ersten drei Kapitel begleitete.

Da die agilen Prinzipien seiner Definition nicht genügen, formuliert er eigene, die in organisatorische und technische Prinzipien aufgeteilt sind. In einigen Aspekten treffen Meyers Prinzipien den Kern der agilen Werte sogar besser als die des agilen Manifests, aber im Wesentlichen sind sie als Strohmann-Argumente angelegt, so dass sie in seinem Sinne widerlegt werden können. Hier alle wiederzugeben würde den Rahmen sprengen.

An einer Stelle zitiert Meyer ein Paper aus dem Jahr 1993, in dem gezeigt wird, dass ein großer Teil der Fehler in einer Software auf das Verständnis der Anforderungen zurückzuführen sind. Die agile Lösung für dieses Dilemma stellt schnelles Feedback durch Anwender dar, Meyer favorisiert eine intensivere Analysephase vor dem Projekt. Sein primäres Argument gegen schnelles Feedback durch Customer Collaboration ist, dass die wesentlichen Stakeholder zu viel beschäftigt sind und deshalb weniger fähige als Vertreter entsendet würden.

Später begründet er, dass auch in agilen Organisationen Manager benötigt würden. Gute Gründe dafür hat Jurgen Appelo mit Management 3.0 geliefert und diese sind in der agilen Community auch anerkannt. Meyer referenziert Appelo nicht, sondern schreibt stattdessen „The need for managers remains, of course, because this is how companies work…“ Ich konnte leider nicht herausfinden, wie ein Manager in Meyers Sichtweise definiert ist, bin mir aber sicher, dass es Leute gibt, die diese Aussage widerlegen können.

Erwähnenswert finde ich noch, dass Meyer in Kent Becks Äußerung, ein Architekt würde auch programmieren eine Provokation sieht. Als jemand der einmal Architekt gewesen ist, glaube ich, kein Programmierer würde mich in dieser Rolle ernst nehmen, würde ich nicht hin und wieder selbst Code schreiben.

Gegen Ende des Kapitels lässt sich Meyer darüber aus, dass Scrum als agiles Projektmanagement Framework Änderungen nicht willkommen heißt, wie es das Agile Manifest fordert. Hier verwechselt er die definierte Arbeit im Sprint mit Änderungen im Backlog. Für die Gründe der Unveränderlichkeit von Anforderungen während eines Sprints interessiert er sich nur marginal – immerhin findet er diese Regel akzeptabel.

Während er im Kapitel verteilt relativ viel zu additiver und multiplikativer Komplexität schreibt, beachtet er leider nicht, dass Softwareentwicklung ein komplexes System ist und viele Dinge voneinander abhängen und miteinander wirken. Daher ist sein lineares Vorgehen zur Dekonstruktion der agilen Prinzipien nur von begrenztem Nutzen, wenn es darum geht, Agilität zu untersuchen.

Mittlerweile habe ich die Hälfte des Buches gelesen und kann nur den Kopf schütteln. Warum schreibt jemand wie Meyer, der eigentlich eine Instanz ist, so unreflektiert und unsauber über ein so wichtiges Thema?

Kapitel 5: Agile Rollen

Das Kapitel über die Rollen in agilen Organisationen ist recht kurz.

Meyer beschreibt, dass die agile Community Manager vor allem negativ betrachtet und über Verbote definiert. Steve Jobs benennt er als ein Beispiel für einen Manager, der sich nicht bewerben bräuchte – ich nenne ihn immer als ein Beispiel für einen Product Owner. Diesen beschreibt Meyer dann auch viel zu kurz – er reduziert ihn darauf, Storys zu Beginn eines Sprints auszuwählen und am Ende des Sprints abzunehmen. Diese Aufgaben gehören natürlich dazu, sind aber nur ein Bruchteil dessen, was ein Product Owner leisten muss. Insbesondere ignoriert Meyer komplett die ökonomische Verantwortung eines Product Owners.

Weiter schreibt Meyer über agile Teams, dass sie viele Management-Aufgaben wahrnehmen „…including the critical one of deciding, step after step, what tasks to implement“. Man könnte jetzt den Versuch unternehmen, Meyers Text dahingehend auseinander zu nehmen, dass ein Manager, der sich tatsächlich um einzelne Implementierungsaufgaben kümmern muss, zu wenig Energie in das Big Design Upfront investiert hat. Die Zeit spare ich mir aber. Wenn Meyer nicht zu den Managern gehört, die ihren Entwicklern vertrauen, sind agile Projekte mit ihm nicht möglich.

Spannend wird die Sache, wenn er zum Thema Kunden und Repräsentanten gelangt. Meyer meint, dass relevante Anwender so stark in Organisationen eingebunden sind, dass sie für die Teilnahme an einem Projekt nicht zur Verfügung stehen. Stattdessen würden an ihrer Statt zweitklassige Mitarbeiter entsandt, die man auf Anwenderseite los werden wollte. Abgesehen davon, dass das auch seine Idee der Vorab-Anforderungsaufnahme unmöglich machen würde, halte ich diese These für gewagt – denn sie sagt nichts anderes, als dass das betreffende Projekt für das Management nicht wichtig genug war, um den relevanten Leuten entsprechende Zeit einzuräumen.

Von Scrum Mastern hat Meyer keine gute Meinung. Zum Einen, weil es Zertifizierungsprogramme gibt und zum Anderen, weil Scrum Master nicht an der Entwicklung beteiligt sein sollen. Ersteres ist in meinen Augen für eine Bewertung der Rolle des Scrum Master irrelevant. Zweites kann man durchaus diskutieren – und kommt meistens zu einem Ergebnis, das Meyer vermutlich ablehnen würde, weil es ein typischer Ausspruch seiner so verhassten Consultants ist: Es kommt darauf an. Ich kenne Teams, bei denen es hilfreich ist, als Scrum Master mit zu entwickeln. Und ich kenne Teams, bei denen das extrem behindert hat. Ich selbst hatte als Scrum Master nie Zeit, mit Hand an den Code zu legen, weil ich damit beschäftigt war, mein Team großartig zu machen. Das können in Meyers Welt aber nur Manager, in denen er die besseren Scrum Master sieht. Auch hier denke ich: es kommt darauf an.

Gegen Ende des Kapitels schlägt Meyer endlich etwas versöhnlichere Töne an: „Every project must examine that tradeoff in light of its own circumstances; there is no universal, dogmatic answer.“ Dem kann ich nur zustimmen, genau das ist das, was ich immer aus der agilen Community höre.

Kapitel 6: Management-Praktiken

Auch dieses Kapitel ist kurz – so kurz wie es von der Praxis weit entfernt ist. Meyer bringt hier viel durcheinander. Er verwechselt die Aufgabenliste im Sprint mit dem Backlog: „It is the rule that during a sprint, the task list does not grow.“ – Die Task List darf wachsen, nur die User Storys dürfen sich nicht ändern. Oder er schreibt das Abbrechen des Sprints dem Product Owner zu: „terminating the sprint early — a decision that, as we have seen, is the privilege of the product owner.“ Nun, meines Wissens nach ist das nirgendwo definiert und wird in der Community aufs Heftigste diskutiert.

In Zusammenhang mit der Closed-Window Rule bringt Meyer auch die Änderung am Inhalt des Sprints mit Änderungen am Product Backlog durcheinander. Änderungen sind willkommen, am Product Backlog dürfen jederzeit Änderungen vorgenommen werden. Aber nicht am Inhalt des Sprints.

Bedauerlich finde ich Meyers ablehnende Haltung gegenüber dem Daily Standup. Er bringt die üblichen Argumente wie Zeitzonen bei verteilten Teams, Meeting-Inflation und unterschiedliche Anwesenheiten bei flexiblen Arbeitszeiten. Alles typische Fälle, in denen die Teams mit denen ich bisher gearbeitet habe, Lösungen gefunden haben.

Das Planning Game und Planning Poker beschreibt Meyer ebenfalls anders, als ich es kennengelernt habe und mit meinen Teams praktiziere. Ich kann aber durchaus verstehen, dass insbesondere das Planning Poker nach Meyers Vorlage nicht funktioniert. Hier stimme ich ihm absolut zu.

Es geht weiter im Kapitel mit Iteration Planning, Code Ownership, den Scrum-Meetings und anderen Dingen, die Meyer als Management-Praktiken einstuft. Einiges davon erklärt er falsch (Iteration Planning) oder erkennt nicht an, dass es neben seinem zentralistischen Weltbild durchaus erfolgreiche Projekte gibt, die multiplikative Komplexität mit einem Scrum-of-Scrums beherrschen.

Deprimierend finde ich seinen Standpunkt zur Code Ownership. Als jemand, der lange Zeit in Open Source Projekten mitgearbeitet hat und auch in dem ein oder anderen großen Industrie-Projekt dabei war, weiß ich wie kritisch ein hoher Truck-Faktor – der geht nämlich mit Fürstentümer im Code einher – ist.

Kapitel 7: Technische Praktiken

Das Kapitel funktioniert ähnlich wie Kapitel 6. Meyer stellt etliche Praktiken aus der agilen Community vor – das bedeutet: er beschreibt, wie er sie versteht – und nimmt sie dann auseinander. Das gelingt mal besser und mal schlechter, scheitert aber in der Regel an praktischer Erfahrung in realen agilen Projekten (das behaupte ich hier einfach mal, anders kann ich mir vieles in diesem Buch nicht erklären – wer es widerlegen mag: Kommentare sind offen). Wenn Meyer Refactoring kritisiert mit den Worten „refactored junk is still junk“ dann fehlt mir ehrlich gesagt eine Idee, was ich dazu schreiben könnte.

Im Wesentlichen geht es um Pair Programming, Coding Standard, Continuous Integration, Refactoring und Test Driven Development. Mir fehlen zu einer ernsthaften, kritischen Auseinandersetzung die Studien, die zeigen, dass TDD und Pair Programming die Produktivität erhöhen. Vielleicht hat Meyer die einfach nicht finden können.

Meyers Ton wird versöhnlicher. Zwar ist die Grundstimmung im Buch noch sehr aggressiv, aber es kommen öfter zähneknirschend Zwischentöne, die konstatieren, dass doch nicht alles so schlecht ist – auch wenn Meyer nicht müde wird, zu betonen, dass Design by Contract Unit Tests selbstverständlich überlegen ist.

]]>
http://gerritbeine.com/2015/04/bertrand-meyer-agile-the-good-the-hype-and-the-ugly/feed/ 0
Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/ http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/#comments Wed, 04 Mar 2015 20:39:13 +0000 https://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/ Weiterlesen ]]> Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Allen, die als Nicht-ITler ins Thema Agilität und vor allem Führung im agilen Kontext einsteigen wollen, sei dieses Buch wärmstens empfohlen. Wer – wie ich – schon länger mit diesen Themen unterwegs ist, wird allerdings wenig neues entdecken.

Der Aufbau des Buches erinnerte mich sehr stark an Fearless Change. Zunächst wird im Teil Mehr Menschlichkeit im Management! die grundlegende Motivation für das Buch erklärt. Die von den Autoren vertretenen Ansichten teile ich auch – bis auf die Tatsache, dass Taylor unverdient mal wieder viel zu schlecht wegkommt.

Im zweiten Teil des Buches wird Management Y aus vier Sichten beschrieben: Organisation gemeinsam erleben, Liefern, was gebraucht wird, Menschen ehrlich begeistern und Kunden wirklich verstehen.Der zweite Teil ist eine Runde Sache und für Einsteiger super. Alle vier Blickwinkel werden kompakt beschrieben und moderne Wege gezeigt, sich ihnen zu stellen. Einziges Manko ist, dass bestimmte Modelle sehr stark im Fokus stehen – vielleicht weil sie den Vorlieben der Autoren entsprechen.

Mit insgesamt 24 Pattern ist der dritte Teil sehr hilfreich, wenn man sich in der Welt agiler Praktiken orientieren will. Wer regelmäßig in der Community unterwegs ist, Blogs liest oder schon andere Bücher zum Thema kennt, wird aber nur schwerlich etwas Neues finden.

Der Ausblick am Schluss ist für mich persönlich etwas zu esoterisch. Ich mache zwar regelmäßig Yoga und meditiere auch sehr gerne – aber das passt nicht zu einem Buch, dass das Wort Management im Titel trägt.

Der Titel ist auch das, was ich an dem Buch im Wesentlichen kritisieren muss. Ich bin ein großer Verfechter des Management 3.0 und empfand das Buch von Jurgen Appelo als einen Meilenstein der Management-Literatur. Management Y hat mit Management …wenig zu tun. Es ist eher eine Ideensammlung und ein Startpunkt für Menschen, die sich mit dem Thema Agilität auseinandersetzen wollen. Wer sich mit Führung – oder Management – in agilen Organisationen auseinandersetzen will, kommt nach wie vor an Appelo nicht vorbei.

Mein Fazit: Das Buch ist super. Für mich persönlich war es viel zu flach. Aber ich bin auch nicht die Zielgruppe. Es gibt dennoch vier Sterne bei Goodreads, weil die Zusammenstellung im Buch für Einsteiger richtig Klasse ist – und die sind mit Sicherheit auch die Zielgruppe :-)

]]>
http://gerritbeine.com/2015/03/ulf-brandes-pascal-gemmer-holger-koschek-lydia-schueltken-management-y/feed/ 0
Apple SuperDrive am USB-Hub http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/ http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/#comments Sat, 20 Dec 2014 19:43:51 +0000 https://gerritbeine.com/?p=163 Weiterlesen ]]> Apple empfiehlt das SuperDrive nur an USB-Ports direkt am Mac zu betreiben.
Nun stellt selbst das MacBook Pro leider nur zwei USB-Ports zur Verfügung, was das Ganze ziemlich lästig macht.

Hängt man das Laufwerk an einen USB-Hub, erhält man die lapidare Meldung, dass dieses Gerät mehr Strom benötigt. Dabei gibt es durchaus USB-Hubs, die genügend Strom für das SuperDrive bereitstellen.

Damit OS X das SuperDrive an so einem USB-Hub akzeptiert, muss man den Kernel wie folgt motivieren.

Als root muss man die Boot-Parameter editieren:

vi /Library/Preferences/SystemConfiguration/com.apple.Boot.plist

In der Datei ergänz man dann mbasd=1, so dass sie folgendermaßen ausschaut:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Kernel Flags</key>
        <string>mbasd=1</string>
</dict>
</plist>

Jetzt noch ein Neustart, und das SuperDrive läuft am USB-Hub.

Achtung: Wenn der USB-Hub tatsächlich zu wenig Strom zur Verfügung stellt, kann es zu Datenfehlern kommen. Ein USB-Hub, der auf zwei Power-Ports ausreichend Strom liefert, ist der DUB-H7 von D-Link.

Referenz: How to Run a SuperDrive on a Targus Hub

]]>
http://gerritbeine.com/2014/12/apple-superdrive-am-usb-hub/feed/ 0
Vertraue der Macht – Schätzen ohne Bezugssystem http://gerritbeine.com/2014/10/vertraue-der-macht-schaetzen-ohne-bezugssystem/ http://gerritbeine.com/2014/10/vertraue-der-macht-schaetzen-ohne-bezugssystem/#comments Fri, 31 Oct 2014 14:27:11 +0000 https://gerritbeine.com/?p=165 Weiterlesen ]]> Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.

Eine Methode, die genau das möglich macht und sich bei der initialen Schätzung von Backlogs schon oft bewährt hat, ist die Magic Estimation. Ich kenne etliche verschiedene Ausprägungen, wie eine Magic Estimation im Detail ablaufen kann.

Für die oben beschriebene Situation empfehle ich in der Regel folgenden Ablauf: Aus dem Backlog werden Items ausgewählt, auf Karten geschrieben und an die Teammitglieder verteilt, so dass jedes Teammitglied zwei bis vier Karten erhält. Die gewählten Backlog Items werden dann im Team und mit dem Product Owner diskutiert. Das geschieht in einer festen Timebox. Empfehlenswert ist, maximal eine Stunde dafür aufzuwenden. Nachdem die Items diskutiert wurden, beginnt die eigentliche Schätzung. Dafür wird ein langer Tisch benötigt, dessen gegenüberliegende Seiten mit „Klein“ und „Groß“ beschriftet werden.

Während der Schätzung darf nicht gesprochen werden. Die Teammitglieder dürfen in jeder Iterator zwei Backlog Items auf dem Tisch bewegen. Eine Bewegung ist das Hinlegen eines neuen Items oder das Verschieben eines Items, das schon auf dem Tisch liegt. Die Items sollen anhand ihrer Größe verglichen werden, gleich große Items werden untereinander gelegt, verschieden große Items nebeneinander. Die Orientierung dafür geben die Seiten des Tisches. Die Teammitglieder treten nacheinander an den Tisch heran, so lange, bis entweder die Timebox aufgebraucht ist oder sich das Bild auf dem Tisch stabilisiert. Das dauert meist nicht länger als eine halbe Stunde.

Auf dem Tisch haben sich nach Ablauf der Timebox in der Regel fünf Cluster ähnlich großer Backlog Items gebildet, mal einer mehr, mal einer weniger. Diesen Cluster werden nun von „Klein“ nach „Groß“ Story Points zugewiesen. Der Cluster, der am weitesten bei „Klein“ liegt, bekommt die Karte mit der 1 und alle folgenden Cluster die nächsthöhere Karte.

Die große Frage ist: Warum funktioniert das und wie zuverlässig ist diese Schätzung?
Die Antwort besteht aus mehreren Aspekten. Diese Schätzung funktioniert, weil sie auf einer Fähigkeit basiert, die Menschen sehr gut beherrschen, nämlich dem Vergleichen. Sie ist valide, weil die Story Points eine abstrakte Einheit sind, die erst durch die Velocity des Teams in eine Planungsgröße konvertierbar wird. Und sie ist zuverlässig, weil sie auf dem Intelligenz des Schwarms basiert. Die Backlog Items werden diskutiert, aber nicht, wie häufig beim Planning Poker, en detail zerredet.

Als Nebeneffekt entsteht durch die Magic Estimation eine Eichung der Größe von Backlog Items in Story Points für alle Größenordnungen – und diese ist wesentlich besser als Grundlage für Planning Poker Sessions geeignet, als die berühmte einzelne Referenz-Story. Das Team hat durch die Magic Estimation ein ganzes Set von Referenz-Items geschaffen, an denen sich zukünftige Schätzrunden orientieren können.

]]>
http://gerritbeine.com/2014/10/vertraue-der-macht-schaetzen-ohne-bezugssystem/feed/ 0
Mein privates Git Cheat Sheet http://gerritbeine.com/2014/09/mein-privates-git-cheat-sheet/ http://gerritbeine.com/2014/09/mein-privates-git-cheat-sheet/#comments Sat, 13 Sep 2014 11:22:58 +0000 https://gerritbeine.com/?p=167 Weiterlesen ]]> Da ich in verschiedensten Projekten regelmäßig mit Git arbeite, habe ich mir überlegt, die wichtigsten Szenarien, denen ich begegne, in einem privaten Cheat Sheet zusammenzufassen.

Ich weiß, dass ich der Welt damit nichts Neues offenbare, aber es ist praktisch, das alles mal an einem Ort versammelt zu haben.

Aktualisieren von Upstream-Repositories

Ich arbeite häufig mit Upstream-Repositories, von denen ich aus irgend einem Grund einmal einen Clone erstellt habe. Damit ich bei diesem Repositories auf dem Laufenden bleibe, füge ich sie meiner lokalen Arbeitskopie als Remote-Repository hinzu.

Ein Beispiel dafür ist mein Fork von Homebrew auf GitHub. Damit dieser nicht zu weit hinter dem offiziellen Homebrew-Repository läuft, aktualisiere ich ihn regelmäßig. Dazu habe ich auf meinem lokalen Clone (origin ist git@github.com:gbeine/homebrew.git) das Homebrew-Repository hinzugefügt:

git remote add upstream https://github.com/Homebrew/homebrew.git

Jetzt kann ich mein Fork Repository mit vier einfachen Schritten auf den aktuellen Stand des offiziellen Homebrew-Repositories bringen:

  1. Die Daten von Remote Repository holen:
    git fetch upstream
  2. Auf den master wechseln (ich arbeite hier normalerweise mit Branches):
    git checkout master
  3. Den master auf den Stand des upstream aktualisieren:
    git rebase upstream/master
  4. Den aktualisierten master auf origin veröffentlichen:
    git push origin master

Damit sind alle Änderungen aus dem offiziellen Repository in meinen Fork übernommen worden.

Mergen von Upstream-Repositories

Das zuerst beschriebene Szenario funktioniert gut, so lange man keine Änderungen auf dem master macht, die man veröffentlichen möchte. Macht man solche Änderungen, muss man entweder auf einen anderen Branch ausweichen oder die folgenden Schritte verwenden.

Als Beispiel dafür verwende ich meinen Fork des MediaWiki-Repositories. Auf GitHub habe ich einen Fork von https://github.com/wikimedia/mediawiki-core.git erstellt und einen lokalen Clone erzeugt. origin ist git@github.com:gbeine/MediaWiki.git.

Ich habe Änderungen auf dem master meines Clones gemacht und auch veröffentlicht. Dennoch möchte ich meine private Version von MediaWiki auf dem aktuellen Stand des offiziellen Repositories halten. Das geht ebenfalls mit einem Upstream-Repository und einem zusätzlichen Branch.

Zunächst muss ich wieder das offizielle Remote-Repository hinzufügen:

git remote add upstream https://github.com/wikimedia/mediawiki-core.git

Jetzt kann ich meinen master mit den folgenden Schritten auf den aktuellen Stand bringen:

  1. Die aktuellen Daten von Upstream-Repository holen:
    git fetch upstream
  2. Auf den Branch für upstream wechseln (-B benötigt man nur beim ersten Mal):
    git checkout -B upstream
  3. Den upstream aktualisieren:
    git merge upstream/master
  4. Optional, aber sinnvoll: den Branch upstream veröffentlichen:
    git push -f origin upstream
  5. Auf den master wechseln:
    git checkout master
  6. Vom Branch upstream auf den master mergen:
    git merge --no-ff upstream
  7. Den master veröffentlichen:
    git push origin master

Sofern man noch keine Änderungen auf dem master gemacht hat, kann man beim Schritt drei auch git rebase upstream/master verwenden. Das ist auf jeden Fall der beste Weg! Zur Not geht man für den upstream-Branch einige Commits zurück.

Wichtig ist, dass man beim Aktualisieren des master keinen Fast-Forward-Merge durchführt. Deshalb habe ich Fast-Forward-Merges für meinen master abgeschalten:

git config branch.master.mergeoptions "--no-ff"

Löschen von Branches

Die Möglichkeit, Branches zu löschen, benötige ich ebenfalls wegen meiner Homebrew-Aktivitäten. Das Löschen von Branches ist mit Git denkbar einfach.

  1. Remote Branch löschen:
    git push origin :mybranch
  2. Lokalen Branch löschen:
    git branch -d mybranch

Branches verfolgen

Einen lokalen Branch an einen bestimmten remote Branch zu binden, ist kein Problem:

git branch -u upstream/remote_branch local_branch

Branches veröffentlichen

Neue Branches lassen sich sehr einfach veröffentlichen:

git push git@github.com:gbeine/homebrew.git newbranch

Upstream mit Subversion

Das oben beschriebene Konzept der Upstream Branches lässt sich natürlich auch mit Subversion-Repositories anwenden. Wenn das Subversion-Repository der Upstream sein soll, funktioniert das wie folgt:

  1. Clonen des Git-Repositories als origin:
    git clone "git-url"
  2. Auf upstream Branch wechseln:
    git checkout -B upstream
  3. Verbinden mit Subversion-Repository als upstream:
    git svn init —prefix upstream/ -s "svn-url"`
  4. Daten von Subversion holen:
    git svn fetch
  5. Den upstream auf den aktuellen Stand bringen:
    git svn rebase
  6. Den upstream Branch veröffentlichen:
    git push origin upstream
  7. Zum master Branch wechseln:
    git checkout master
  8. Die Änderungen aus Subversion übernehmen:
    git merge --no-ff upstream
  9. Den master Branch veröffentlichen:
    git push origin master

Jetzt kann man wie oben beschrieben, Änderungen von Subversion nach Git mergen. Die Aktualisierungen aus Subversion zieht man immer in den upstream Branch und kann diesen auch im Remote Git-Repository veröffentlichen.

Löschen von Commits

Es passiert mir manchmal, dass ich etwas committe, das ich dann doch nicht so haben will. Dann muss der letzte Commit wieder gelöscht werden. Das geht mit diesem Kommando:

git reset —soft HEAD~1

Quellen

Da das alles nur gut geklaut ist, hier die URLs der Seiten, die mich inspiriert und illuminiert haben:

]]>
http://gerritbeine.com/2014/09/mein-privates-git-cheat-sheet/feed/ 0
Back to COBOL – natürlich mit Unit Tests http://gerritbeine.com/2014/09/back-to-cobol-natuerlich-mit-unit-tests/ http://gerritbeine.com/2014/09/back-to-cobol-natuerlich-mit-unit-tests/#comments Mon, 08 Sep 2014 23:08:05 +0000 https://gerritbeine.com/?p=169 Weiterlesen ]]> Ich hätte nie gedacht, dass ich mich nach über 10 Jahren noch einmal mit COBOL beschäftigen würde. Aber nun habe ich ein Team, das mit COBOL arbeitet und Scrum machen soll.

Nun sind COBOL und Scrum zwei Dinge, die die meisten Menschen, die ich so kenne, nicht oft in einem Satz verwenden. Das soll aber kein Grund sein, sich nicht mit der Materie zu beschäftigen. Letztes Wochenende habe ich OpenCOBOL – neuerdings GNU-Cobol – via homebrew auf dem Mac verfügbar gemacht.

Das war aber nur der erste Schritt, denn mein eigentliches Ziel war die Grundvoraussetzung für agile Software-Entwicklung mit COBOL zu nutzen. Na? Genau: Unit Tests! Mit CobolUnit gibt es dafür auch ein Framework, das aber schon seit einer Weile nicht maintained wird. Die letzten Commits sind von 2009, das versprach ein Abenteuer.
Und das wurde es dann auch. Ich habe mich von Fehlermeldungen wie
error: indirect goto in function with no address-of-label expressions
zu
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/Users/gbeine/GitHub/gbeine/COBOLUnit/COBOLUnitLib/lib/libCobolUnit.dylib' for architecture x86_64
durchgearbeitet.

Am Ende ist es mir gelungen, CobolUnit mit GNU-Cobol in der Version 1.1 und dem GCC 4.9.1 zum Laufen zu bringen. Das Resultat schaut recht erfreulich aus:

|--- Suite1
| Test 'CTU0S1T1 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
| Test 'CTU0S1T2 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

|--- Suite2
| Test 'CTU0S2T1 * SUCCESS * (008 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

********************************************************************
* SUCCESS *
* (003 test cases, 003 success, 000 failures, 000 errors) *
********************************************************************
(00 min:00 sec:01 ms)

Meine Änderungen dazu habe ich – natürlich – auf GitHub zur Verfügung gestellt. Nur für den Fall, dass das außer mir noch irgendwo auf der Welt irgendjemand nutzen möchte…

]]>
http://gerritbeine.com/2014/09/back-to-cobol-natuerlich-mit-unit-tests/feed/ 0
Einheit Story Points? http://gerritbeine.com/2014/08/einheit-story-points/ http://gerritbeine.com/2014/08/einheit-story-points/#comments Mon, 04 Aug 2014 11:20:11 +0000 https://gerritbeine.com/?p=174 Weiterlesen ]]> Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.

In der Diskussion auf der Agile World kam die Aussage auf, Story Points wären eine einheitenlose Größe (Quantity). Das kann nicht korrekt sein, denn Story Points beschreiben lediglich die Größe (Size) von Backlog Items. Das könnte man auch mit T-Shirt Sizes oder anderen abstrakten Mechanismen erreichen. Tatsächlich kann man sogar eine Umrechnung von Story Points in T-Shirt-Sizes definieren. Demzufolge können Story Points keine Größe (Quantity) sein. Und tatsächlich sind Story Points keine quantifizierende Eigenschaft von Backlog Items, sondern nur die Maßeinheit des Wert einer solchen Größe (Quantity), nämlich der Größe (Size) des Backlog Items. Die Größe (Size) des Backlog Items ist – nach Mike Cohn – eine Funktion f(Aufwand, Risiko, Unsicherheit) und mit einer gewissen statistischen Unsicherheit – die aus Risiko, Unsicherheit und Schätzfehlern resultiert – in Aufwand umrechenbar ist.

Bestätigt wird das auch durch den üblichen Sprachgebrauch. Mir ist noch niemand begegnet, der von den Story Points seines Backlogs als Eigenschaft gesprochen hätte. Man spricht immer nur von der Größe des Backlogs in Story Points. Oder T-Shirt Sizes. Oder Schokostreuseln.

Der Trugschluss, Story Points seien keine Einheit, kommt meiner Meinung nach daher, dass man vermeiden möchte, auf eine feste Formel festgenagelt zu werden, mit der man Story Points in Aufwand umrechnen soll. Ich kann mir gut vorstellen, dass es Leute gibt, die solche Dinge verlangen. Dass es nur mit statistischer Varianz möglich ist, zeigt Mike Cohn in dem oben zitierten Artikel. Und dass man es nicht benötigt, weil man auch ohne Umrechnung zu den Aussagen kommt, die relevant sind, wird von Henrik Kniberg in seinem Product Owner in a Nutshell erklärt.

]]>
http://gerritbeine.com/2014/08/einheit-story-points/feed/ 0