Feeds:
Beiträge
Kommentare

Archive for the ‘Gute Software’ Category

Ich habe meinen Internet-Anschluss bei Kabel-Deutschlands (jetzt Vodafone). Dazu gab es ein Kabelmodem. Um das Ubiquiti Security Gateway daran zu betreiben und kein doppeltes NAT und direktes VPN zu ermöglichen, brauche ich den Bridge Mode. Da das Kabelmodem aber nur ein Telefongerät mag und ich für die Telefonie gerne die DECT-Funktion der Fritzbox nutzen möchte, habe ich folgendes „durchlebt“.

Umstellung vom Kabelmodem auf die Fritzbox

Vodafone nimmt Geld für die Umstellung (einmalige Gebühr) und verlangt jeden Monat etwas. Man bekommt dafür:

  1. Fritzbox 6490 (Eigentum der Vodafone und funktionsbeschränkt)
  2. Umstellung aller Telefonnummern auf Internet-Telefonie

Beides ist hilfreich, denn „die Fritzbox funktioniert immer“, d.h. auch bei Störungen wird sie gebraucht weil Vodafone mit ihr durchmessen kann (also gut im Schrank ablegen).

Endgerätefreiheit

Flink eine eigene Fritzbox 6490 gekauft, die Vodafone box ins Regal gestellt und mit dem Freitschaltcode aktiviert. Voila, es läuft (wie vorher).

Bridge Modus

Der Bridge-Modus ist standardmäßig nicht zu sehen. Er muss durch einen Eintrag in der Konfiguration sichtbar gemacht werden.

  1. Passwort-Abfrage der Fritzbox ausschalten
  2. FBEditor 0.7.2 runterladen
  3. FBEditor starten und Konfiguration laden
  4. Zeile mit „bridge_hidden“ auf „no“ stellen
  5. Konfiguration speichern und zurück spielen
  6. Fritzbox startet neu durch.
  7. Im Menü rechts oben „Erweiterte Ansicht“ einschalten
  8. Im Menü „Internet -> Verbindung“ den Tab „Bridge“ auswählen
  9. z.B. LAN 4 für Bridge freischalten, Router dort anschließen
  10. Fritzbox noch einmal durchstarten und fertig!

Telefonie auf mehreren Etagen

Für die Etagen im Mehrfamilienhaus habe ich in jeder Etage eine Fritzbox (die oben beschriebene im Keller) an LAN2 und LAN3 jeweils EG und OG. In jeder habe ich die Internet-Telefonie-Einstellungen eingetragen und die DECT-Telefone angemeldet.

Read Full Post »

In unserer Berufspraxis erlebe ich immer wieder Teams, die nach agilen Vorgehensweisen entwickeln und in kurzen Abständen Releases herausbringen wollen. Das klappt aber im Konzernumfeld nicht, weil sie auf Funktionen warten müssen, die im Backend bereitgestellt werden. Das Backend ist dann ein Host und Host-Entwicklungsprojekte werden klassisch eher nach Wasserfall-artigen Entwicklungsmethoden durchgeführt und z.B. Releases nur alle halbe Jahr herausgegeben. Man muss sich erst für ein Release anmelden usw.

In einem ersten Schritt will ich nun Cobol lernen, um die Entwicklungsprojekte besser zu verstehen.

Cobol auf dem PC programmieren

Damit man Cobol programmieren kann, braucht man einen entsprechenden Compiler und eine Entwicklungsumgebung.

Auf dem Mac kann man mit der Paketverwaltung brew ganz leicht OpenCobol (jetzt GnuCobol) installieren:

brew install gnu-cobol [return]

Für Ubuntu ist eine Anleitung hier: https://wiki.ubuntuusers.de/OpenCOBOL/

Das quelloffene Projekt liegt unter https://sourceforge.net/projects/open-cobol/

Außerdem braucht man noch eine Entwicklungsumgebung bzw. einen Editor. Ich habe mich für OpenCobolIDE entschieden. Die findet sich hier: https://launchpad.net/cobcide/+download

Es gibt auch eine Plugin für Sublime – da ich den Editor aber nicht verwende, kann ich dazu nichts sagen.

Und dann gibt es noch Slickedit („the most powerful …“): https://www.slickedit.com/trial/slickedit Den will ich demnächst mal probieren.

Welcher Standard soll es denn sein?

Cobol gibt es in vielen Standards. Wir wissen, dass unsere Kunden nach dem IBM-Standard arbeiten. Das ist wichtig in der IDE und dem Compiler einzustellen. Ansonsten wird man mir Warnings überschüttet.

Und welches Tutorial soll ich nehmen?

Hier gibt es Video-Tutorials: Deutsch und Englisch https://www.linkedin.com/learning/topics/cobol gleicher Inhalt wie  https://www.lynda.com/COBOL-tutorials/Up-Running-COBOL/411377-2.html

Textbasierte Tutorial:

 

Read Full Post »

Das Agile Fluency Model finde ich persönlich sehr hilfreich. Es wurde 2012 von Diana Larsen und James Shore das erste Mal publiziert. Es unterscheidet vier Stufen der Gewandtheit (engl. Fluency). Gewandtheit bedeutet, dass ich auch unter Stress in der Lage bin, zuverlässig nach den Regeln der erreichten Stufe zu handeln, d.h. professionell zu handeln. Viele Teams geben unter Druck ihre agilen Praktiken auf und fallen in alte Vorgehensweisen zurück.

Fluency Level 1 – Focus on Value – Fokus auf Mehrwert

Die erste Stufe konzentriert sich auf das identifizieren von Werten, d.h. gegenüber vorher kümmert sich das Team darum, an Mehrwerten zu arbeiten. Sie erfordert, dass ich den agilen Prozess einhalten kann. D.h. wenn ich z.B. nach Scrum arbeite, dass ich die Dinge auswähle, die einen erkennbaren Wert für den Kunden liefern. Und ich werde meine Prioritäten nicht ändern, nur weil auf das Team Einfluss genommen wird. Diese Stufe ist meist mit Scrum Master und agilem Coaching zu erreichen. Es dauert meiner Erfahrung nach 8-12 Monate, bis ein Team auch unter größerem Stress bei seinem Prozess bleibt.

Fluency Level 2 – Deliver Value – Mehrwert liefern

Die zweite Stufe setzt den Schwerpunkt auf das zuverlässige Ausliefern von Ergebnissen, die einen Mehrwert darstellen. Bei Software-Entwicklung bedeutet dies, dass ein produktiv einsetzbares Ergebnis ausgeliefert wird. Dafür muss das Team sein Handwerkzeug beherrschen. Es muss Software programmieren, Fehler vermeiden bzw. entdecken und ausbauen, ein auslieferbares Artefakt erstellen und dieses in der Produktionsumgebung installieren.

Im Sprint werde ich deshalb so lange an etwas arbeiten, bis es direkt für den Kunden nutzbar wird. Dabei ist es wichtig, die agilen Entwicklungspraktiken (z.B. eXtreme Programming, testgetriebene Entwicklung, Refactoring) zu beherrschen. Das Team braucht außerdem Wissen über Build-Server / Build-Pipelines, um das Artefakt zuverlässig zu erstellen. Um die Software in Produktion zu aktivieren, ist es nützlich technisches Verständnis von der Produktionsumgebung zu haben.

Fluency Level 3 – Optimize Value – Kundenwert optimieren

Bei der dritten Stufe kann das Team den Mehrwert für den Kunden frühzeitig erkennen und Kundenbedürfnisse erfüllen, bevor diese ihm selber klar sind. Dazu ist eine enge Zusammenarbeit zwischen Product Owner und dem Entwicklungsteam notwendig. Beide leben die Verantwortung für das Produkt und bringen sich ein.

Organisationen auf dem Weg zur dritten Stufe müssen deswegen in einen organisatorischen Umbau investieren. Die Trennung der Verantwortung zwischen den Entwicklern und den Produktverantwortlichen muss aufgehoben werden, um gemeinsam das Produkt voran zu treiben. Erst dadurch werden Entwicklungsteams dazu fähig, frühzeitig Bedürfnisse zu erkennen und den Kunden zu begeistern.

Fluency Level 4 – Optimize for Systems – Die Organisation optimieren

Organisationen auf der vierten Stufe sind in der Lage, über mehr als einen Entwicklungsstrang hinaus, Mehrwerte für Kunden herzustellen. Es wird also nicht nur eine Produktlinie betrachtet, sondern das ganze Unternehmen hat agile Prinzipien verinnerlicht hat und verbessert sich kontinuierlich.

Diese Stufe ist eine besondere Herausforderung, denn sie bedeutet einen Kulturwandel im Unternehmen und fast immer auch das Aufbrechen von funktionalen Silos.

Agile Fluency Gathering und Game

Diesen Oktober (4.-6.10.2017) ist das erste Mal das Agile Fluency Gathering in Deutschland und das Fluency Game wird vorgestellt. Nähere Informationen finden sich auf der Webseite Agile Fluency Project.

 

Quelle: Agile Fluency™ Model

Read Full Post »

Holger Tewis (Scrumburg) und ich hatten eine sehr intensive Zeit bei unserem vorherigen Arbeitgeber, bei dem wir etwa 15 Monate versucht haben, mehrere nach Silos strukturierte Abteilungen in sinnvolle agile Teams zu verwandeln.

Auslöser war die sinkende Produktivität trotz (oder gerade wegen) immer mehr Mitarbeitern und die Unzufriedenheit unserer Kunden. Wir haben unsere Erfahrungen in einen Artikel gegossen, der in der Sonderausgaben 2017 der Agile Review (hier kann man die Zeitschrift bestellen) erscheinen wird (voraussichtlich Ende August 2017).

Mir hat es dabei sehr geholfen, die 8 Schritte von John P. Kotter anzuwenden. Wir haben die Schritte sowohl damals bei der Transformation verwendet als auch nun für die Reflexion. Und auch beim zweiten Mal war es sehr lehrreich.

Meine wesentliche Erkenntnis dabei bleibt, dass eine agile Transformation nicht funktionieren kann, wenn nicht alle Top-Level Führungskräfte der Firma hundertprozentig hinter der Transformation stehen. Es findet zu viel Interaktion mit anderen Firmen-Teilen statt, als dass es genügt hätte, den für unseren Bereich zuständigen Chef im Boot zu haben.

Mehr Details könnt ihr in der kommenden Ausgabe der Agile Review nachlesen.

Read Full Post »

Magic Mirror

Von meinem ehemaligen Kollegen Volker bin ich auf das Projekt Magic Mirror aufmerksam gemacht worden. Ich fand die Idee faszinierend, alle wichtigen Informationen morgens im Bad oder beim Frühstück angezeigt zu bekommen. Deswegen habe ich beides realisiert.

Als Rechner habe ich Raspberry Pis genommen und als Monitore erst einmal Dell P2412. An beide Geräte konnte ich günstig kommen, sodass keine große Investition nötig war. Um den Raspi mit Strom zu versorgen, nutze ich Power Over Ethernet (Poe) und verwende einen Adapter: DSLRKIT Active PoE Splitter. Das funktioniert mit meinem Zyxel-Switch wunderbar. Um das Video-Bild von HDMI auf den DVI-Eingang des Monitors zu übersetzen, habe einen zweiten Adapter: DVI HDMI Adapter Ugreen. Damit ist die Hardware komplett.

Für die Installation bin ich wie folgt vorgegangen:

  1. Jesse Light Image erstellt.
  2. Magic Mirror installiert
  3. Ich bin Markiper’s tip gefolgt, um den Screen Saver wirklich los zu werden (bitte schaut genau auf der Seite, um seinen Post zu finden)
  4. Installiere zusätzliche Magic Mirror Module (MMMs)
    1. Moon – um ein aktuelles Bild des Mondes inkl. Mondphase anzuzeigen (direkt von der NASA)
    2. GoogleMaps – um den Verkehr für die Route zu Arbeit zu sehen
    3. Forecast.io / Darksky – um das genaue Wetter für den Tag und die Woche zu zeigen
    4. WarnWeather – um Wetterwarnungen des Deutschen Wetterdiensts zu sehen
    5. Carousel – um zwischen verschiedenen Städten beim Wetter  zu wechseln

Außerdem habe ich mir noch das Upgrade gegönnt, Video-Streams auf dem Bildschirm anzuzeigen. Wir haben Kameras, die RTSP Video-Streams liefern. Ich habe das nach der Anleitung von Masondb gemacht. Die direkten Lösungen im Magic Mirror haben nicht gut funktioniert (JPGs pollen, RTSP als MMM).

Mit dem vorliegenden Ergebnis bin ich ziemlich zufrieden.

 

Read Full Post »

Heute konnte ich meinen Artikel für die aktuelle Ausgabe 2017/01 der Agile Review fertigstellen: Self-Contained-Systems mit Containern und Micro-Services. In der Ausgabe geht es darum, „Komplexität zu beherrschen“. Self-Contained-Systems helfen, in der Entwicklung die Komplexität zu beherrschen, denn sie stellen für das Entwicklungsteam eine Unabhängigkeit her. Entgegen klassischer Enterprise Architekturen werden zentrale Services nicht einmal bereitgestellt und von allen verwendet sondern immer wieder in Kopie erzeugt und über entkoppelte Mechanismen abgeglichen, wenn nötig.

In diesem Artikel beschreibe ich welche Vorteile für den Entwicklungsprozess der Ansatz bietet. Teams können entkoppelt arbeiten und somit eine höhere Entwicklungsgeschwindigkeit erzielen. Gleichzeitig kann Feedback schneller eingeholt werden, was Fehler schneller aufdeckt und zu kürzerer Time-to-market führt.

Die Agile Review erscheint voraussichtlich Ende April 2017.

Read Full Post »

Ab 1. Dezember 2016 arbeite bei einer der besten Firmen Deutschlands: it-agile!

Ich freue mich drauf, mit vielen bekannten Gesichtern zusammen zu arbeiten. Wir wollen im Team den Technik-Bereich stärken und ausbauen und dabei kann ich mich komplett einbringen.

Read Full Post »

Endlich wieder da

Dieses Blog war ziemlich ruhig geworden und dafür gibt es einen Grund. Ich habe die letzten knapp 3 Jahre für einen anderen Arbeitgeber gearbeitet.

Zum Ersten haben wir da eine richtig große Kugel geschoben, sodass wenig Zeit war zu publizieren. Zum Zweiten wollte mein Arbeitgeber nicht, dass Inhalte aus unserer Arbeit öffentlich gemacht werden. Deswegen habe ich mich auf meine Heim-Automatisierung gestürzt und dazu ein Blog gepflegt (Link).

Jetzt hat sich das aber wieder geändert. Seit Anfang dieses Monats bin ich wieder frei, über meine Arbeit zu schreiben und mein neuer Arbeitgeber ermutigt mich sogar, zu publizieren. Ich freue mich drauf!

Read Full Post »

In der aktuellen Folge des Podcasts “Softwaretechnik kompakt” interviewe ich Dr. Carola Lilienthal zum Thema „Qualität von Softwarearchitekturen“.

Zur Übersicht des Podcasts geht es hier: https://wolfgideonbleek.wordpress.com/podcast

Podcast direkt abonnieren: http://www.wolfgideonbleek.de/podcast/SoftwaretechnikKompakt.xml

Zum Lesen

https://www.xing.com/profile/Carola_Lilienthal

http://de.wikipedia.org/wiki/Liste_von_Softwareentwicklungsprozessen

http://de.wikipedia.org/wiki/Spiralmodell

http://de.wikipedia.org/wiki/Agile_Softwareentwicklung

http://de.wikipedia.org/wiki/Extreme_Programming

http://de.wikipedia.org/wiki/Prototyping_(Softwareentwicklung)

Read Full Post »

Ich komme mit vielen agilen Projekten in Kontakt und stolpere immer darüber, wie agile User Stories geschätzt werden.

Mittlerweile ist ja von vielen akzeptiert, dass ein Schätzen in Komplexitätsklassen besser funktioniert als in konkreten Zeitaufwänden. Die Argumentation dazu spare ich mir an dieser Stelle. Ich gehe auch davon aus, dass die Fibonacci-Zahlen als Schätzmaß akzeptiert sind. Wir haben also 1, 2, 3, 5, 8 und 13 als Beginn und machen dann mit 20, 40 und 100 weiter.

Dabei hat es sich in meiner Praxis bewährt, dass die einstelligen Schätzzahlen gute Komplexitäten sind, um sie in einem Sprint zu bearbeiten. Das ist eine Konvention. Natürlich geht es auch anders, aber ich halte es so für sinnvoll. Die zweistelligen Komplexitäten sind zu groß, als dass sie in einen Sprint genommen werden könnten. Dabei spielt die 13 eine besondere Rolle. Sie sagt aus, dass es zwar ein sehr komplexes Problem ist, aber prinzipiell noch mit Anstrengung in den Sprint passen würde. Die Story ist aber ein direkter Kandidaten für das Aufteilen. Stories mit den Schätzungen 20, 40 oder 100 haben nur grobe Aussagen über ihre Komplexität und müssen deshalb genauer betrachtet werden.

Schaue ich mir die einstelligen Schätzzahlen genauer an, kann ich noch weitere Aussagen darüber treffen. So möchte ich z.B. beim kleinsten Schätzwert die Möglichkeit haben, die Story in möglichst einem Arbeitstag abzuschließen. Ich will viele Erfolgserlebnisse und deshalb brauche ich kurzfristig Rückkopplung, ob die Story passt (z.B. ob der Product Owner sie richtig umgesetzt findet). Auf die gleiche Weise schaue ich mir die 8-Punkte-Story an. Wenn ich 13 Punkte in Ausnahmefällen noch für einen Sprint akzeptiere, muss eine 13-Punkte-Story in einen Sprint passen. Das bedeutet aber, dass eine 8-Punkte-Story etwa die Hälfte eines Sprints einnehmen kann. Das passt auch mit meiner Anforderung, dass ich sie möglichst in einer Arbeitswoche erledigt haben will.

In der Sprintplanung muss ich dann eine Zusammenstellung finden, die mit der gegebenen Teamgröße und Faktoren wie Pairing und Testing zusammen passt. Ich will außerdem zum Sprintende eher kleine Stories vorliegen haben, damit ich nicht sehenden Auges eine Story beginne, die ich nicht beenden kann.

Read Full Post »

Am 24. September 2013 findet in Frankfurt im Maritim Hotel der BITKOM Software Summit statt. Ich halte dort zusammen mit Frank Simon einen Vortrag mit dem Titel „Agile Entwickler und überzeugte Tester: Das neue Traumpaar„.

Ich freue mich über alle Besucher und einen spannenden Tag. Die Teilnahme ist für BITKOM-Mitglieder kostenfrei!

 

 

Read Full Post »

Ich bin letztens auf diesen Artikel gestoßen: http://spoonique.de/2012/09/18/agiler-mythos-1-management-ist-uberflussig/

Ich habe eine ähnliche Erfahrung gemacht. Nur weil Bücher zu agilem Vorgehen erst einmal nichts zum Projektmanagement sagen, heißt dies nicht, dass es keines Projektmanagements bedarf. Dieses Missverständnis habe ich bei vielen meiner Kunden vorgefunden.

Weil in der Scrum-Literatur von der Selbstorganisation des Teams die Rede ist, wird dies häufig über-interpretiert zu der Feststellung, dass kein zusätzliches Projektmanagement notwendig sein. Das ist aber nicht der Fall. Eine andere Motivation für das Weglassen des Projektmanagers ist, dass der Product Owner ja für viele fachbezogene Fragestellung der Entscheider ist.

Welche Fragestellungen aus dem Projektmanagement werden den typischerweise nicht bearbeitet:

  • Risikomanagement: Ein Klassiker. Scrum-Teams sind häufig zu sehr auf die Sache fokussiert und lassen die sachliche und systematische Betrachtung von Projekt-Risiken aus.
  • Kommunikations-Management: Ein Projekt muss – gerade in größeren Unternehmen – seinen Stand, seine Abgrenzung, die Zusammenarbeit und insbesondere Termine und Ergebnisse nach außen kommunizieren. Der Product Owner ist damit vielfach überfordert.
  • Ressourcen- und Budget-Management: Obwohl der Product Owner implizit über seine Sprintplanung Budget-Entscheidungen trifft, so ist es doch eine andere Ebene, z.B. einen externen Berater einzukaufen, Personen einzustellen, auszutauschen usw.
  • Personalplanung: Urlaube, Abteilungswechsel, Arbeitszeiten usw. sind in größeren Unternehmen über Matrixorganisationen schnell in ganz anderen Zuständigkeitsbereichen. Für das Projekt sind sie aber entscheidend, wenn es um Leistungsfähigkeit und Verlässlichkeit geht.

Gar keine gute Idee ist es, den Scrum Master in die Verantwortung für das Projektmanagement zu nehmen. Hier entstehen sofort Interessenkonflikte. Beispielsweise will der SM für Continuous Pace sorgen. Aus Projekt-Sicht sind aber Überstunden gefordert. Oder ein Mitarbeiter soll Urlaub abbauen, wird aber im Team unbedingt gebraucht.

Mir geht es deshalb darum, ein Verständnis für ein agiles Projektmangement zu bilden, in dem die Aufgaben zwischen den Scrum Mastern und Product Owner der Teams einerseits und einem Projektmanageer andererseits klar getrennt sind.

Read Full Post »

In größeren agilen Projekten kommt immer wieder die Frage auf, wie Sprintziele gewählt werden sollen. Unter einem großen Projekt verstehe ich hierbei eines, welches mit mehreren Teams gleichzeitig an einer Software arbeitet und wo es nötig geworden ist, die Gruppe der Product Owner mit einem Chief Product Owner zu hierarchisieren. Typischerweise geht das bei fünf bis acht Scrum-Teams zu je 8 bis 12 Personen los.

Das Sprintziel sollte in ein bis drei Spiegelstrichen ausgedrückt werden können (in Ausnahmen auch bis zu fünf). Formuliert werden sollten wirkliche Ziele, also was man erreichen möchte, nichts was man tun will, denn das steht ja schon in den Stories. Also: nicht „Refactoring der Datenbankschicht“ sondern „Entkopplung des Datenbankzugriffs vom Session-Parameter“ o.ä. nicht „Implementiere drei Varianten des Identity-Providers“ sondern „Umsetzung der gesetzlichen Mindestanforderungen für Identitätsprüfung“

Ein großes Projekt hat seine Zielsetzung allerdings durch ein Geschäftsziel, d.h. es gibt eine Management-Ebene, die ein Software-Projekt zur Erreichung eines gewissen Geschäftsziels eingesetzt hat. Insofern müssen die Sprintziele auch diesem Geschäftsziel zuarbeiten. Im Idealfall ist die Summe aller Sprintziele das, was man braucht, um das Geschäftsziel zu erreichen.

Die Aufgabe des Product Owners ist es nun, das Geschäftsziel über die Sprints herunter zu brechen in Sprintziele, die das Team versteht. Ein Geschäftsziel ist zu vage, um es zu operationalisieren. Stories sind zu konkret, um sie direkt auf ein Geschäftsziel zu beziehen.

Insofern sind inhaltliche Sprintziele für mich ein essentieller Bestandteil eines agilen Entwicklungsprozesses. Sie liefern konkrete Themen, an denen sich ein Team abarbeiten kann. Sie sind auch eine gute Grundlage für die täglichen Entscheidungen im Sprint. Ein Sprintziel sollte man unter keinen Umständen aufgeben. Eine Story kann man ggf. nicht umsetzen oder muss sie aufteilen.

Read Full Post »

Ich finde das Sprint Commitment einen ganz wesentlichen Bestandteil von Scrum. Es gehört für mich dazu, wenn ich agil arbeite. Dabei wird das Sprint Commitment häufig falsch verstanden.

Ich habe Teams erlebt, die Sprint Commitments aufgrund von Story-Points abgeben. Das halte ich für Unsinn. Ich habe Teams erlebt, die Sprint Commitments aufgrund einer Story-Anzahl abgeben. Auch das halte ich für unsinnig. Ich habe Teams erlebt, die sich auf eine klar definierte Auswahl von Stories committen. Das halte ich nicht für effektiv. Ich glaube, dass man das Meiste herausholt, wenn man ein Team dafür gewinnt, das Sprint Commitment zum Sprintziel abzugeben.

Hier ist meine Erklärung dazu:

1) Sprint Commitment zu Story-Points
Die Story-Points sind ein Hilfsmittel, um Komplexität von Anforderungen abzuschätzen. D.h. ich möchte wissen, welche Herausforderung eine Story für das Team darstellt. Mit der Velocity, die ich über die zurückliegenden Sprints gemessen habe, kann ich eine ausreichend genaue Aussage über die Möglichkeiten des Teams treffen. Wenn sich das Team jetzt zu einer Story-Point-Anzahl committet wiederhole ich eigentlich nur die Berechnung unter Berücksichtigung der Inhalte. D.h. ich bekomme heraus, wie sicher sich das Team bei seiner Schätzung fühlt. Nachteil: Ich kann in zwei Drittel der Fälle nur verlieren, denn ein Team wird ggf. weniger Story-Points leisten oder nur genauso viel. Dann habe ich aber im Zweifel keinen gefühlten Erfolg. Nur wenn ich mehr schaffe, fühlt sich das richtig gut an, weil es ja ein abstrakter Wert ist. Außerdem bekomme ich als Product Owner keine inhaltliche Garantie. Im Zweifel zieht das Teams die „einfacheren“ Stories vor, um das Commitment zu schaffen.

2) Sprint Commitment zu Story-Anzahl
Das ist genauso zweifelhaft und verhält sich ähnlich zu den Story-Points.

3) Sprint Commitment zu einer Auswahl von Stories
Ja, das geht schon in die richtige Richtung. Ist aber leider auch falsch. Denn das Team hat keine Steuerungsmöglichkeiten mehr. Es befindet sich in der Falle. Kann eine der Stories nicht zu Ende bearbeitet werden ist das Commitment gerissen. D.h. je mehr Stories ich habe, desto wahrscheinlicher ist es, dass das Commitment nicht eingehalten wird. Das ist demotivierend und nicht zielführend.

Was ich eigentlich möchte ist ein Team, das eigenverantwortlich Entscheidungen trifft und auf ein mit dem Product Owner gemeinsam vereinbartes Ziel hinarbeitet. Das bekomme ich in den drei oben genannten Varianten aber nicht hin.

Ich ermögliche solch ein Handeln, wenn ich das Commitment auf das vom Product Owner gesetzte Sprintziel einhole. Und das geht so:

Der Product Owner kommt zum Planning mit seinem Sprintziel und den vorbereiteten Stories. Das Team wählt zusammen mit ihm die Stories aus, die notwendig und sinnvoll sind, um das Sprintziel zu erreichen. Bei der Auswahl wird die Velocity als Erfahrungswert berücksichtigt. Am Ende des Plannings stellt der Product Owner die Frage, ob sich das Team dem Sprintziel verschreibt (sich darauf committet). Das sollte ein Selbstgänger sein.

Was jetzt möglich wird ist, dass alle Entscheidungen während des Sprints an dem Sprintziel ausgerichtet werden können. Man kann sogar Stories kürzen, aufteilen, herausnehmen. Immer wenn man dadurch das Sprintziel weiterhin erreicht, ist es in Ordnung. Das Team trägt dafür die Verantwortung, denn es hat ja sein Commitment gegeben. Hier kommt es nicht auf Story-Points oder konkrete Stories an sondern darauf, das Sprintziel zu erreichen.

Read Full Post »

Seit letztem Sommer habe ich ein neues Blog angefangen, in dem ich meine bescheidenen Erfahrungen zum Thema KNX/EIB Gebäudeautomatisierung am Beispiel unseres privaten Einfamlienhauses publiziere. Wer also selber so etwas vor hat, kann sich da ein paar Anregungen holen.

Das ist hier http://knxeib.wordpress.com/ zu finden.

Read Full Post »

Auf dem Kundenforum der DV-Ratio habe ich heute zusammen mit Heiko Scharding einen Vortrag zum Thema Projektmanagement und Agile Softwareentwicklung gehalten. Wir hatten eine sehr angeregte Diskussion zu der Frage, welche Rolle der klassische Projektmanager in einem agilen Umfeld spielt.

Unsere Kernaussage war, dass es ein Fehler ist, die klassischen Aktivitäten eines Projektmanagers wegfallen zu lassen, wenn man agil vorgeht. Vielmehr ist es wichtig, Agile Softwareentwicklung um die typischen Projektmanager-Aufgaben zu ergänzen.

Dabei ist es essentiell, die Projektorganisation so aufzubauen, dass die Rolle Projektmanager nebem dem Scrum-Master, dem Team und dem Product Owner sinnvoll eingeordnet ist. Der Projektmanager nimmt weiterhin wichtige Aufgaben im Projekt wahr. Neben dem Managen des Budgets pflegt und bearbeitet er die Projektrisiken und vertritt das Projekt gegenüber dem höheren Management.

Read Full Post »

Ich habe gestern zusammen mit Heiko Scharding am BITKOM Forum zum Thema „Agil vs- Industrialisierung“ teilgenommen. Bei dieser Veranstaltung haben verschiedene Vortragende aus unterschiedlichen Firmen zu ihren Erfahrungen mit agilen Methoden im Projektkontext berichtet. Unser Vortrag zielte auf Motivation in agilen Projekten ab.

Unserer Erfahrung nach ist die Qualität des Projektergebnisses nicht nur abhängig von einer professionellen Qualitätssicherung sondern auch von motivierten Mitarbeitern. Gut motivierte Team-Mitglieder liefern höhere Qualität ab. Wir können durch den Einsatz agiler Methoden im Team eine höhere Motivation erzeugen, weil viele Projektentscheidungen im Team transparent gemacht werden. Außerdem helfen agile Methoden, den Projektfortschritt sichtbar zu machen. Dies trägt besonders gut zur Motivation bei, weil Hindernisse schnell erkannt und aus dem Weg geräumt werden. Allgemein wird auch jedes Teilergebnis erfahrbar.

Informationen zu der Veranstaltung findet man unter: http://www.bitkom.org/de/veranstaltungen/66455_68010.aspx

Read Full Post »

Die BLUECARAT AG hat eine neue Version des Ampel-Plugins erstellt, das dem Hudson Buildserver die Möglichkeit gibt, 230V-Geräte zu steuern. Entwickler können damit ein Projekt so konfigurieren, dass der Build-Zustand über eine Steckdosenleiste mit 230V-Geräten visualisiert wird. Z.B. kann eine umgebaute Verkehrsampel anzeigen, dass ein Build stattfindet (“gelb”) oder wie das Build-Ergebnis ist (“rot”, “grün”). Derzeit werden zwei verschiedene Modelle von Steckdosenleisten unterstütz. Die Software ist so konzipiert, dass für weitere Modelle Implementierungen hinzugefügt werden können.

Die Software kann unter der Adresse http://wiki.hudson-ci.org/display/HUDSON/Traffic+Light+Plugin bezogen werden.

Read Full Post »

Von Joseph Pelrine habe ich eine neue Methode zum Schätzen von Tasks an Stories kennen gelernt.

Die Methode heißt Quattro Staggioni und teilt einen Arbeitstag in vier Teile: Vor der ersten Kaffeepause, vor dem Mittag, vor dem Nachmittagstee und vor dem Arbeitstag-Ende. D.h. man hat nur vier Werte, mit denen man eine Schätzung ausdrückt.

Vorteil dieser Schätzmethode ist, dass sie implizit keine Tasks erlaubt, die länger als einen Tag dauern. Außerdem nutzt sie die intuitive Einschätzung eines jeden, ob er eine Aufgabe an einem Vormittag erledigen kann (2 Punkte). Dauert es signifikant weniger Zeit, nimmt man 1 Punkt. Dauert es länger, muss man sich der Frage stellen, ob es annähernd einen ganzen Tag dauert (4 Punkte) oder vor dem Nachmittags-Tee erledigt werden kann (3 Punkte). Außerdem macht sie das Schätzen einfach, denn die intuitive Vorstellung zu diesen Zeiträumen hat jeder.

Gut finde ich darüber hinaus, dass die Überprüfung des realten Zeitbedarfs von jedem sehr leicht selber gemacht werden kann. Man weiß, ob man es noch vor dem Mittag schafft. Außerdem ist man ein wenig flexibel, denn man kann ein paar Minuten früher oder später zum Essen gehen.

Einen Nachteil, den ich bei dieser Methode sehe ist, dass Personen, die sich den Tag deutlich anders organisieren (z.B. 10 Uhr kommen, 12 Uhr Mittagessen, bis 19 Uhr arbeiten) Schwierigkeiten haben, sich auf dieses Schätzmaß einzulassen.

Read Full Post »

Wir entwickeln seit Jahren mit Continuous-Intergration (CI) Umgebungen. Früher haben wir mit CruiseControl gearbeitet, heute ist Hudson unser Tool der Wahl. Dabei war es uns immer wichtig, den Build-Prozess so gut wie möglich für das Team zu visualisieren. Diverse Kleinigkeiten können dabei helfen.

Bei meinem Freund Alan Borning (Prof. an der Universität Washington in Seattle) habe ich die Idee mit den Ampeln kennen gelernt. Er hat für jedes seiner Projekte eine alte Verkehrsampel gekauft und diese durch den CI-Server gesteuert. Mit einem kleinen Script hat er die Ampel auf Gelb gestellt während der Build lief. Das Ergebnis des Builds wurde dann mit Rot oder Grün angezeigt. Die Ampeln hingen im Büro oder Flur des Teams und haben den Build gut visualisiert. Das haben wir nun auch umgesetzt.

Wir haben ein Ampel-Plugin für Hudson geschrieben und dieses auch veröffentlicht. Hier ist insbesondere Chris Stahlhut zu nennen, der einen großen Teil des Programms entwickelt hat. Das Plugin steuert eine Steckdosenleiste, die mehrere 230V Steckdosen besitzt und mittels Netzwerksteckdose am LAN angeschlossen ist. Das Plugin ist unter der folgenden Adresse zu finden:

http://wiki.hudson-ci.org/display/HUDSON/Traffic+Light+Plugin

Derzeit kann das Plugin nur mit einem Typ von IP-Steckdose zusammenarbeiten (genaue Typbezeichnung findet sich bei der Dokumentation). Wir würden uns freuen, wenn andere Leute für weitere Steckdosenmodelle Quelltext besteuern könnten. Derzeit sitzen wir daran, das Plugin für mehr als ein Projekt auf dem Buildserver nutzbar zu machen.

Read Full Post »

Older Posts »