surech.ch – Homepage von Stefan Urech

Praktizierender Zyniker und Freidenker

5. September 2017
von surech
1 Kommentar

Generische Team-Namen und ihre Folgen

Mein Scrum-Team trägt den Namen Phoenix. Noch selten hat ein so kleiner Entscheid zu so vielen Fragen und Unverständnis geführt. Zeit also, hier etwas Klarheit zu schaffen.

Wie kam es dazu?

Wie schon berichtet bin ich dran, zwei Scrum-Team zu einem zusammenzuführen. Diese hiessen FIN (von Finanzen) und SAV (von Service Après Ventes). Schnell war klar, dass das neue Team einen Namen braucht, z.B. um im Jira die Features und Bugs zuordnen zu können. Also schlug ich an einer Retro den (wenig kreativen) Namen „FinSAV“ vor. Natürlich wurde darauf vom ehemaligen SAV-Team der Gegenvorschlag „SAVFin“ eingeworfen. Aus der weiteren Diskussion kam die Idee eines generischen Namens.
Also sammelten wir während einer Woche kreative Namen an einem Whiteboard und stimmten anschliessend darüber ab. Und das Resultat war Phoenix.

Was bringt es?

Weiterlesen →

23. Juli 2017
von surech
Keine Kommentare

Scrum Refinement 2.0

In meinen bisherigen Scrum-Projekten habe ich das Product Backlog Refinement wie folgt erlebt: Das ganze Team versammelt sich in einem Raum und der PO stellt eine Userstory vor. Das Team stellt solange Fragen, bis (mehr oder minder) alles klar ist. Dann macht man eine Schätzung, z.B. mit Planning Poker-Karten und schreitet zur nächsten Story vor.

Flipchart mit dem neuen Refinement-Prozess.


Aufgrund der Grösse meines aktuellen Teams kam diese Form nicht mehr in Frage. Denn Meetings mit vielen Personen neigen dazu, dass sich einige langweilen und nicht mehr aktiv teilnehmen. Weiter habe ich in solchen Refinements endlose Diskussionen erlebt, wie genau eine Story jetzt definiert werden muss. Die einen wollen es halt detailliert, die anderen sehen es eher pragmatisch. Also musste eine neue Form des Refinements her, welche auch mit grösseren Gruppen effizient funktioniert.
Weiterlesen →

23. Juli 2017
von surech
1 Kommentar

Erfahrungen eines Scrum Masters

Seit Beginn dieses Jahres bin ich als Scrum Master in einem grossen Projekt in der SBB tätig. Im Frühling waren wir gezwungen, vier bestehende, kleinere Scrum-Teams zu zwei Grösseren zusammenzulegen. Der Grund war die angespannte finanzielle Situation und wir erhoffen uns damit, mit weniger Administration und besserer Nutzung von Synergien arbeiten zu können. Und so kommt es, dass ich nach einem halben Jahr als Scrum Master schon das zweite Team übernehmen und aufbauen darf.
In meiner neuen Rolle lerne ich sehr viel und darf jeden Tag neues ausprobieren. In einer losen Folge von Blog-Beiträgen möchte ich euch von meinen Erfahrungen und Erkenntnissen berichten.

Weiterlesen →

12. März 2017
von surech
1 Kommentar

Agile Software-Entwicklung mit einer Multi-Kanal-Architektur

Bitte entschuldigt den sperrigen Titel. Und gleich vorneweg: Ich habe dafür keine Lösung, sondern nur verschiedene Varianten. Zu diesen möchte ich gerne eure Meinung und Erfahrungen abholen.

Nachfolgend geht es um die Frage, wie man grosse Software-Projekte mit mehreren Teams agil führt. Mit „gross“ meine ich 50 Entwickler und mehr. Ich bewege mich im Scrum-Umfeld und verstehe unter einem Team ein Scrum-Master, ein Product Owner und das Entwicklungsteam.
Weiterlesen →

29. Januar 2017
von surech
Keine Kommentare

Vier Pro-Tipps zur Führung auf Distanz

Seit bald fünf Jahren darf ich ein Team mit Anfangs sechs und heute 13 Mitarbeiter führen. Wir sind in einer Matrix-Organisation aufgestellt. Das heisst, die Leute sind mir zwar organisatorisch unterstellt, arbeiten aber in verschiedenen Projekten. Aufgrund der sowohl fachlichen wie teilweise auch geografischen Entfernung nennt man das gerne „Führen auf Distanz“. Dies ist eine nicht ganz einfache Ausgangslage, die zu Beginn vielen Teamleitern Mühe machte. Deshalb hier vier Pro-Tipps, welche aus der Erfahrung der letzten Jahre entstanden sind:
Weiterlesen →

22. Januar 2017
von surech
2 Kommentare

Spass mit der (virtuellen) Slot-Maschine!

Auf Facebook fiel mir diese Anzeige auf:

Als regelmässiger Kunde vom Casino in Bern musste ich mir diese Angebot genauer anschauen. Es kommt schliesslich recht selten vor, dass ein Casino etwas gratis hergibt. Tatsächlich empfängt uns dort eine hübsche Slot-Maschine:

Leider gibt es (wie in den meisten Glückspielen) recht selten etwas zu Gewinnen. Aber wie schon Indiana Jones zu hören bekam:

You lost today kid. But that doesn’t mean you have to like it.

Tatsächlich verliere auch ich nicht gerne. Also schauen wir uns diese Slot-Maschine mal genauer an.
Weiterlesen →

1. Mai 2015
von surech
Keine Kommentare

Eine Verteidigung von Responsive Design

Heute stiess ich auf folgenden Tweet:

Der verlinkte Artikel zählt vier Nachteile von Responsive Design auf. Daraus schliesst die Autorin, dass maximale Ergebnisse für Händler und Marken nur mit „nativen mobilen Websites“ möglich ist.

Als bekennender Befürworter von responsive Design kann ich diese Aussage nicht so stehen lassen. Lasst mich also zu den einzelnen Punkte ein paar Worte verlieren:

1. Unnötig lange Ladezeiten: Das trifft vielleicht zu, wenn man eine bestehende Webseite mit ein paar Media-Queries ergänzt und sich dann als „mobile friendly“ brüstet. Aber schauen wir uns mal an, aus was heute eine typische Webseite besteht:

  • HTML: Da kommt man auch bei mobilen Seiten nicht drum rum. Dank Server-seitiger GZIP-Kompression sollte dies aber kein Problem sein.
  • Bilder: Bei vielen Webseiten machen grafische Inhalte den Löwenanteil der übertragenen Daten aus. Mit Media-Queries haben wir aber ein sehr gutes Werkzeug um abhängig vom Gerät kleiner oder gar keine Bilder zu laden
  • JavaScript: Mit zunehmend interaktiven Webseiten kommen schon mal ein paar JavaScript-Frameworks dazu, welche alle übertragen werden müssen. Standard-Bibliotheken werden aber schnell über CDNs geladen und bleiben im Cache. Wer es ganz ernst nimmt, kann sogar unterschiedliche Dateien abhängig von der Grösse laden.

Kurz: Es gibt viele Möglichkeiten, die Ladezeit einer Webseite zu verkürzen.

2. Benutzeroberfläche wird nicht optimal eingesetzt: Die Autorin behauptet, responsive Design unterbinde die Möglichkeiten zur Interaktion über Berührung, Stimme, Kamera etc. Warum? Swipe-Gesten kann man einbauen, ohne dass dies den Desktop negativ beeinflusst. Mein Laptop hat schon langen ein Mikrofon und eine Kamera, also auch da kein Unterschied zum Smartphone.
Zudem ist hier ein Reality Check angebracht: Wer hat schon mal eine Webseite gesehen, welche auf den Fingerabdruck-Scanner zugreift? Eben.

3. Keine Rücksicht auf die Nutzungssituation: Die Autorin sagt aus, dass der Benutzer eine Webseite auf dem Smartphone anders benutzt als auf dem Desktop. Stimmt. Genau deshalb passen wir diese ja mit responsiv Design an. Wo ist das Problem?

4. Keine Sonderfunktion: Es wird damit argumentiert, dass der Kunde das Smartphone zum Stöbern nach neuen Produkten braucht, den Kauf aber auf einem anderen Kanal abschliesst. Sollte es nicht im Interesse des Betreibers sein, dass der Kunde den Kauf gleich auf dem gleichen Kanal abschliesst? Und selbst wenn nicht: Ich sehe nicht ein wie es im Sinne des Kunden ist, wenn sich gleiche Webseite auf dem Desktop plötzlich ganz anders bedient als zuvor auf dem Telefon.

Nachdem der Artikel nur für Gründe gegen Responsive Design nennt, möchte ich noch ein paar dafür einbringen:

  • Es gibt nicht nur Desktop oder Smartphone. Inzwischen werden Webseiten auch auf Phablets, Tablet, Smart-TVs und zunehmend 4k-Bildschirmen angeschaut. Eine gute responsive Webseite sieht überall gut aus.
  • Entwickelt man eine Webseite von Anfang an Mobile First, sollte sich der Mehraufwand in Grenzen halten. Dafür sinken die Kosten im Betrieb dramatisch, weil nur eine Codebasis gepflegt werden muss.
  • Der Kunde erwartet je länger je mehr, auf dem Smartphone die gleichen Möglichkeiten zu haben wie auf dem Desktop. Ich hasse nichts mehr, als wenn ich auf dem iPad eine funktional und inhaltlich beschnittene „Mobile-Version“ erhalte.

Fazit: Es gibt keinen Grund, eine Webseite nicht responsive zu bauen. Wer wirklich alle Features eines mobilen Gerätes nutzen will, soll eine App anbieten. Aber sicher keine Browserweiche.

PS. Der Originalartikel ist von Keith Lietzke und etwas differenzierter formuliert als die deutsche Übersetzung. Die vier Kritikpunkte bleiben aber die gleichen.

21. Februar 2015
von surech
Keine Kommentare

Systemrelevante Webdienste

In der grossen Finanzkrise drohten etliche Grossbanken vor die Hunde zu gehen. Dies hätte massive Auswirkungen auf die Wirtschaft als Ganzes gehabt und der Staat musste unterstützend einschreiten. Sprich hier hatten ein paar privat geführte, nach kapitalistischen Grundsätzen operierende Firmen eine kritische Grösse erreicht. Deren Abhängigkeiten zum Rest des Marktes war so umfangreich, dass ein Wegfallen nicht akzeptabel war.

So abhängig die Wirtschaft von einzelnen Banken war, ist das Internet von einzelnen Diensten. Je nach Dienst betrifft dies die Benutzer direkt oder indirekt, entweder schon heute oder sicher in naher Zukunft. Gerne möchte ich diese These mit ein paar konkreten Beispielen untermauern:

Dropbox: Ursprünglich gestartet als einfacher Filehosting-Dienst, mit welchem ich meine Dateien zwischen verschiedenen Rechner synchron halten kann. Man konnte ein Ordner auf seinem Computer freigeben, dessen Inhalt dann automatisch mit den Servern von Dropbox abgeglichen wurde. Wenn der Dienst nicht verfügbar war, hatte man die Daten immer noch auf der eigenen Festplatte.
Mit dem Aufkommen von Smartphones nutzen aber immer mehr Apps Dropbox als Speicher für ihre Daten. Man legt seine Dokumente, Photos, Passwörter und noch vieles mehr in diesem Webspeicher ab, was ja wirklich sehr praktisch ist. Geht mein Smartphone verloren, habe ich immer noch alle Daten in der ominösen Cloud.
Damit bildet aber der Dienst Dropbox einen Single Point of Failure. Wenn Dropbox von heute auf morgen seinen Dienst einstellt, hätte dies einen immensen Datenverlust zu Folge. Alle Anwendungen, welche auf deren API aufbauen und vertrauen, würde nicht mehr funktionieren. Diese doch so bequeme Art der Datenspeicherung und -Austausch würde sich zu einem Fluch erster Güte wandeln.

Amazon Web Service (AWS), Windows Azure, Google Cloud Platform: Gehen wir eine Stufe tiefer. Alle sprechen von der Cloud; die Firmen frohlocken ob der Aussicht, ihre Anwendungen auf fremden Servern zu hosten und den erhofften Kostenersparnissen. Heute spricht man aber nicht nur darüber, sondern nutzt diese Möglichkeit schon extensiv. Instagram, Netflix, Airbnb, Pinterest oder das schon erwähnte Dropbox bauen auf AWS. Wie stark diese Abhängigkeit ist merkte man, wenn z.B. wegen eines Stromausfalls ein ganzes Rechnerzentrum vom Netz geht. Wir laufen also auf einen Situation zu, wo ein grosser Teil der Internet-Infrastruktur von ein paar wenigen, global funktionierenden Firmen laufen. Was ist, wenn diese irgendwie in Bedrängnis kommen? Oder die Vermietung von Rechnerleistung nicht mehr rentabel ist und z.B. Google diesen Geschäftszweig aufgibt?

Wikipedia: Nach zwei recht technischen Beispielen will ich mein Blick noch auf Wikipedia richten. Seit ihrem Start vor über 14 Jahren hat sich das Onlinelexikon zu DER Sammlung menschlichen Wissens entwickelt. Und damit unseren Alltag massgeblich beeinflusst. Denn wer hat noch einen 24-bändigen Brockhaus im Bücherregel? Die Wikipedia wird von einem gemeinnützigen Verein betrieben, welche die Informationen kostenlos und frei von Werbung anbietet. Die Kosten sind aber nicht unerheblich und so müssen die Macher regelmässig zu Spendenaktionen aufrufen. Ich bete dafür, dass sie damit noch lange über die Runden kommen. Was, wenn der Spendenstrom einmal einbricht? Wer unterstützt dann diese zentrale Säule heutiger Informationsbeschaffung?

Was bringt die Zukunft? Das Internet of Things wird langsam aber stetig Realität. Es wird eine Flut von Daten anfallen, die irgendwie gesammelt, ausgewertet und einem sinnvollen Zweck zugeführt werden wollen. Bereits stehen Dienste wie IFTTT in den Startlöchern, die Rolle als zentrale Drehscheibe zu übernehmen. Wenn zwischen dem Eintreffen zu Hause und dem Öffnen der Haustür ein solcher Dienst steht, kann man sich die Abhängigkeit dazu und die entsprechenden Auswirkung eines Ausfalls desselben leicht vorstellen.

Vor zehn Jahren stellte niemand die Zuverlässigkeit des Bankensystems in Frage. Diese Firmen waren riesengross, was soll da schon passieren? Das gleiche blinde, an Naivität grenzende Vertrauen bringen wir heute direkt oder indirekt einzelnen Internet-Diensten entgegen. Egal wie zentral ein solcher Dienst ist, er muss weder spezielle Anforderungen noch irgendwelche gesetzliche Vorgaben erfüllen. Finanzielle Reserven? Spezielle Anforderungen an die Sicherheit? Schutz der Kunden und deren Daten? Nichts dergleichen.
Ich prophezeie, dass uns irgendwann in Zukunft eine ähnliche Krise im Internet trifft, wie 2007 in den Finanzwelt. Schwarzmalerei? Ich sehe leider nicht viel, was dagegen spricht.

11. Januar 2015
von surech
Keine Kommentare

Hotline

Nach drei Wochen Ferien bin ich heute nach Hause zurück gekommen. Und als vernetzter Mensch merke ich sofort, dass das Internet nicht funktioniert. WLAN geht, aber statt dem weltweiten Netz erhalte ich nur eine Seite mit der Aufforderung, die Swisscom-Hotline zu kontaktieren. Dies tue ich nur sehr ungern. Obwohl ich ein bisschen etwas von Computer verstehe, muss ich jeweils trotzdem alle üblichen Schritte im Hotline-Protokoll durchlaufen. Spätestens wenn ich aufgefordert werde, alle Knöpfe am Router gleichzeitig für 30 Sekunden zu drücken und die Kabel nacheinander aus- und wieder einzustecken, fehlt mir das Verständnis.
Wie dem auch sei, mir bleibt nichts anderes übrig. Nach zahlreichen Fragen vom Automaten (Sprache, Geschäft/Privat, Produkt, Kundennummer, Sternzeichen) werde ich erfreulich schnell mit einem netten Menschen verbunden. Ich schildere ihm die Situation und teile ihm auch gleich mit, dass ich den Router schon neu gestartet habe und alle Stecker bombenfest sitzen. Und schon geht es los mit dem üblichen Drehbuch: Als erstes darf ich den Router zurücksetzen (15 Sekunden mit dem Kugelschreiber in ein Loch drücken). Das hilft nichts. Also den Router ausschalten, 10 Sekunden warten, wieder einschalten. Geht immer noch nicht.

Nun die Aufforderung, ich soll doch mal das Glasfaserkabel ausziehen und wieder einstecken. Ich denke mir: Was soll das bringen? Ich war gerade drei Wochen weg, da kann das Kabel ja wohl nicht von alleine rausgesprungen sein. Zudem haben solche Glasfaserkabel Steckverbindungen, welche selbst nach einem Erdbeben noch festsitzen würden. Aber der Hotline soll man nicht widersprechen. Also murkse ich das Kabel aus dem Router (es sitzt wirklich sehr fest) und stecke es wieder ein. Und siehe da, das Internet-Lämpchen leuchtet wieder in beruhigendem Weiss!

Ich habe keine Ahnung, wie das rational zu erklären ist. Für mich gehört dieses Verhalten in die gleiche Kategorie wie Spontanheilungen und Kornkreise: Es passiert offensichtlich, aber niemand weiss warum.

Der Dank gebührt jedenfalls dem Mitarbeiter an der Swisscom-Hotline, welcher mir auch am Sonntag-Nachmittag zu einem funktionierenden Internet verholfen hat!

15. November 2014
von surech
Keine Kommentare

NextCarWash: Die REST-API

Gleich vorneweg: Ich liebe REST-Schnittstellen. Eine wohl definierte API zu schaffen ist schon fast ein künstlerischer Schöpfungsprozess. Die Grundlagen (HTTP) sind jedem bekannt, und trotzdem hat man viele Freiheiten. Umso mehr kann man alles falsch oder eben auch vieles richtig machen. Trifft letzteres zu, erschliesst sich das Resultat dem Betrachter sofort ohne viele Erklärungen. Eben wie ein grosses Kunstwerk.

Und NextCarWash, meine Suche für die nächste Autowaschanlage, bietet eine solche Schnittstelle. Die ganze Kommunikation mit dem Webfrontend geschieht über diese API, entsprechend gut ist sie in der Praxis erprobt und mehr als ein theoretisches Konstrukt.

Die Schnittstelle setzt das HATEOAS-Prinzip um. Dieses definiert, dass über Links die verschiedenen Ressourcen miteinander verknüpft sind. Dies entspricht dem Ansatz, dass Internetseiten über Hyperlinks aufeinander verweisen. Damit entspricht sie dem Level 3 des von Leonard Richardson entwickelten REST Maturity Model. Die Daten werden im JSON-Format übermittelt, deren Struktur durch die Hypertext Application Language (HAL) definiert wird.

Nun genug der Theorie, schauen wir uns ein konkretes Beispiel an. Wir holen uns eine bestimmten Anlage:
http://www.nextcarwash.ch/api/rest/carwash/CW93X5UT
Weiterlesen →