Unternehmer und Geek

Blog

  • Einfaches Backup Script

    Hier ein ganz einfaches Backup Script:

    #!/bin/sh
    rdiff-backup /srv/users/ /root/backup/
    rdiff-backup –remove-older-than 4W –force /root/backup

    Basiert auf rdiff und löscht alle Backups welche älter als 4 Wochen sind. –Force ist notwendig, um sicherstellen, dass auch mal 2 Backups welche älter als 4 Wochen sind gelöscht werden.

    Und hier ein Snipped, welches ein komplettes Backup einer MySQL DB macht:

    #!/bin/sh

    #TIME=»$(date +’%Y-%m-%d›)»
    BACKUP_DIR=»/tmp/backup_mysql»

    TIMESTAMP=$(date +»%F__%H»)
    DB_BACKUP_DIR=»$BACKUP_DIR»
    MYSQL_USER=»backup»
    MYSQL=/usr/bin/mysql
    MYSQL_PASSWORD=»the_password»
    MYSQLDUMP=/usr/bin/mysqldump

    mkdir -p «$DB_BACKUP_DIR»

    #backup database
    databases=`$MYSQL –user=$MYSQL_USER -p$MYSQL_PASSWORD -e «SHOW DATABASES;» | grep -Ev «(Database|information_schema|performance_schema)»`

    for db in $databases; do
    echo «Backup Database: $db»
    $MYSQLDUMP –force –opt –user=$MYSQL_USER -p$MYSQL_PASSWORD –databases $db | gzip > «$DB_BACKUP_DIR/$db.gz»
    done

    rdiff-backup /tmp/backup_mysql /root/backup_mysql

    Funktioniert nach dem einfachen Prinzip:

    • Dump DB als gzip
    • inkrementelles Backup via rdiff-backup

  • hc-sr501 PIR Motion

    Es sind lediglich drei Anschlüsse notwendig und somit sehr einfach zu machen:

    • Power
    • Ground
    • Datenfluss

    Die beiden organgen Regler am Besten zum Starten ganz gegen den Uhrzeigersinn drehen. Dadurch wird die Sensititivät sehr gering und man muss sehr nahe am Sensor sein und zudem «merkt» sich der Sensor die Zeit nicht.

    So sollte der Sensor aussehen. Die Plastikkappe lässt sich leicht entfernen. Dann kann man auch einfach prüfen, wie die Drähte gesteckt werden müssen.

    Dieser kleine Schnippsel sollte funktionieren und geht davon aus, dass der Datendraht an D6 angeschlossen ist.

    int sensor = D6;

void setup() {
  Serial.begin(115200);
  Serial.setDebugOutput(true);
  pinMode(sensor, INPUT);   // declare sensor as input
  //pinMode(Status, OUTPUT);  // declare LED as output
}

void loop() {
  Serial.println("start");
  long state = digitalRead(sensor);
  
  if(state == HIGH) {
      //digitalWrite (Status, HIGH);
      Serial.println("Motion detected!");
      delay(1000);
    }
  else {
      //digitalWrite (Status, LOW);
      Serial.println("Motion absent!");
      delay(1000);
      }
}

    Die eingesetzten Komponenten habe ich hier (https://de.aliexpress.com/item/V2-4M-4FLASH-NodeMcu-Lua-WIFI-Networking-development-board-Based-ESP8266/32647690484.html?spm=a2g0s.9042311.0.0.yFM7LS) und hier (https://de.aliexpress.com/item/Free-shipping-1PCS-LOT-HC-SR501-HCSR501-SR501-human-infrared-sensor-module-Pyroelectric-infrared-sensor-imports/32700407854.html?spm=a2g0s.9042311.0.0.yFM7LS) gekauft

  • Mein Start in die Arduino Welt

    Der Raspberry Pi war ein bisschen langweilig. Schlussendlich hat er für mich das gleiche gemacht, was irgend ein Server in der Amazon Cloud auch machen konnte.

    Mit einem ESP8266 scheinen sich hier komplett neue Wege zu eröffnen! Das gute Stück ist im Kern lediglich etwa 2 x 1 cm gross und hat bereits WiFi verbaut. Und oh wunder, nachdem ich es endlich geschafft habe, mich zu verbinden hat Wifi auch auf anhieb geklappt!

    Hier ein paar nützliche Links

    • Debuggen: http://www.instructables.com/id/HOW-TO-use-the-ARDUINO-SERIAL-MONITOR/
    • Die ersten Versuche mit Arduino IDE und Nodemcu: http://www.instructables.com/id/Quick-Start-to-Nodemcu-ESP8266-on-Arduino-IDE/
    • Super Tutorial, sehr detailliert: http://www.mikrocontroller-elektronik.de/nodemcu-esp8266-tutorial-wlan-board-arduino-ide/

    mal schauen, was daraus noch wird

  • Woocommerce Shopping Cart in WordPress Theme Integrieren

    Mist. Mein Theme unterstützt WooCommerce nicht. Somit gibt es auch keinen Shopping Cart. Ich mache mich schon für eine komplizierte und langwierige Entwicklungsorgie bereit.

    Ask Google: «woocommerce add cart theme» (erstaunlich, dass Google das sogar versteht.

    Oh Wunder. Die erste Seite ist ein absoluter Treffer. In 5 Minuten ist alles erledigt, so dass noch Zeit bleibt mein Wissen zu teilen:

    3 Steps To Add WooCommerce Cart Icon With Cart Count To Your Theme’s Header

  • Das Mentoring Handbuch

    Mentoring kenne ich vor allem von Star Wars. Qui-Gon Jinn ist Obi-Wan Kenobi’s Mentor und Obi-Wan wird dann Anakins Mentor.

    Ich habe mich dem Thema mal ein bisschen genauer angenommen und wurde im Mentoring Handbuch fündig. Mentoring wird dort wie folgt definiert:

    Mentoring beschreibt die Beziehung zwischen zwei Personen: Mentees, die Ziele erreichen möchten und MentorInnen, die Mentees auf diesem Weg unterstützen. Mentoring in einem Unternehmen fördert einzelne MitarbeiterInnen innerhalb eines bestimmten Zeitraums. Sowohl MentorInnen wie auch Mentees sollten die Beziehung freiwillig und gerne eingehen, die Inhalte der Gespräche vertraulich behandeln und gleichermaßen davon profitieren.

    Das Handbuch erklärt kurz und knapp, was von beiden Parteien zu erwarten ist und gibt konkrete Ratschläge, wie diese umgesetzt werden können.

  • Darum habe ich WordPress für kleine Web Projekte verbannt

    Freund: Hilfe, meine Seite wurde gehackt. Was muss ich tun?

    Ich: Hast du WordPress und die Plugins mal aktualisiert?

    Freund: Das letzte Mal vor sechs Monaten.

    Ich, innerlich stöhnend: Ok, dann aktualisiert mal die Seite und dann schauen wir weiter.

    WordPress selber behaupten, dass 27% des Internets auf ihrem CMS läuft. Das entspricht zwar noch nicht der Dominanz, welche Windows mal auf dem Desktop hatte, aber macht diese Plattform dennoch zum lukrativen Ziel für Hacker.

    WordPress ursprünglich als Blogginplattform angedacht wird heute für alle möglichen und unmöglichen Typen von Seiten eingesetzt: Von hochfrequentierten Newsseiten, über E-Commerceseiten bis hin zu kleinen Brochureware Webseiten mit einer handvoll einfachen Seiten.

    Sinnvoll?

    Ich glaube nicht. Daher kurz zu den Basics.

    In meiner Webkarriere habe ich mit drei Arten von Systemen gearbeitet:

    1. Die Klassiker: Datenbankgestützte Systeme wie WordPress, Drupal, TYPO3, Sharepoint, Ghost und und und…
    2. Komplett statische Seiten oder aber gestützt mit einem Static Site Generator wie Jekyll, Hexo oder Wintersmith.
    3. Flat File CMS, Grav, Kirby, Pico und noch ein paar andere

    Mein fast 10 jähriges Blog hat in den fast 10 Jahren Lebenszeit auch schon alle Systeme durchgemacht: Drupal, WordPress, Jekyll und Grav (wobei nur als Test).

    Während die Flatfile CMS sicher nicht die Eierlegendewollmilchsau sind, bieten sie doch einige herausragenden Vorteile.

    Problemzonen von WordPress

    Die Problemzonen von WordPress sind weder der Bauch noch die Beine. Ich sehe 5 Kernprobleme oder Herausforderungen, wenn man mit Datenbankgestützten Systemen (und im Speziellen mit WordPress) arbeitet:

    1. Die ganze Deployment und Staging Sache. Inhalt auf Dev, Test und Prod ist nie wirklich synchron. Dazu kommt, dass viele Konfigurationen in der Datenbank gemacht werden. Diese über die verschiedenen Server zu ziehen ist mühsam und fehleranfällig. Dazu weiter erschwerend ist auch die Sache mit dem Inhalt. Eigentlich müsste das VCS (z.B. Git) sowohl Files als auch Datenbank beinhalten.

    2. Gigantische schöne (und grosse) Themes, vor allem für WordPress. Doch mit dem Theme alleine ist nicht genug. Damit das Theme auch so funktioniert, wie es auf dem Screenshot ausschaut, muss noch Sliderplugin xy und Pagebuilder ab und Module rs installiert werden.

    All diese Themes und Plugin haben meistens ein Ziel: Möglichst viele Usecases möglichst Drag’n’Drop zugänglich zu machen, damit jeder Idiot sie benutzen kann. Der Preis dafür sind komplexe und gigantische Plugins und Themes mit zum Teil kompletten Applikationen innerhalb der Webseite.

    Dazu wird der Source Code mit unnötiger Divitis geflutet und die Pagebuilder führen dazu, dass Styledefinitionen pro Element gemacht werden, was wiederum zu Inkonsistenz im Design führt.

    3. Backup ist teuer oder ein Gebastel. Zwar gibt es zumindest für WordPress entsprechende Plugins, aber so richtig glücklich bin ich damit nicht geworden. Kommt dazu, dass eines der Plugins, die Settings Datei per se nicht inkludiert. Viele der Plugins setzen zudem eine Pro Version voraus, welche monatlich ein paar $$ kostet (Beispiel Vaultpress).

    Die zweite Option ist mit ein paar Scripten selber etwas zu bauen und das dann auf Amazon S3 zu speichern. Funktioniert gut und zuverlässig, aber ist halt ein Gebastel und für den kleinen Mann eher undenkbar.

    4. Unzählige Updates. Viele Module bringen die gewünschte Funktionalität und diese läppern sich schneller zusammen als einem lieb ist: Formulare, Google Analytics, Security, S3, Slider, E-mail und und und. Je grösser die Anzahl umso regelmässiger gilt es zu aktualisieren. Mit jedem neuen Stück Code werden Sicherheitslücken gestopft und neue geöffnet.

    Entweder vor jedem Update ausgiebig in einer Testumgebung testen (wobei wir wieder bei Problem 1 wären) oder auf gut Glück in der produktiven Umgebung aktualisieren und hoffen und beten, dass alles noch funktioniert.

    5. Security. Ich bin bei weitem kein Security Experte, aber SQL Injections gehören zu den viel gesehen Sicherheitslücken. Die Rechnung ist daher ganz einfach: ohne Datenbank gibts auch keine SQL Injections. Weiter wenig förderlich für die Sicherheit ist der Einsatz von PHP als Template Engine.

    Wie funktionieren diese Flat File CMS und was macht sie so genial?

    Nachdem ich über WordPress hergezogen bin, möchte ich schauen, was die Flat File CMS so viel besser macht. Ich nehme hier insbesondere Bezug auf Grav, aber die anderen werden eine ähnliche Mechanik haben.

    1. Inhalt liegt als Markdown in stinknormalen Textdateien. Metadaten können im Kopf des Files «ad-hoc» definiert werden:

    ---
title: Testartikel
header_image: header.jpg
taxonomy:
    category: [Blog]
---

    2. Templates sind einfach und direkt. Bei Grav kommt Twig zum Einsatz. In den Templates kann einfach auf diese Header Informationen zugegriffen werden. Kein PHP in Templates bedeutet mehr Sicherheit.

    Theoretisch könnte jeder Artikel eigene Headerinformationen haben, was jedoch wenig förderlich für die Wiederverwendbarkeit ist. Das fehlende «DB-Schema» ersetzt die Planung nicht!

    3. Von Grund auf portabel, versioniert und mit Backup: «git commit, git pull«. Sowohl der Code, als auch der Inhalt ist versioniert. Für Staging: git pull und auf einen Webserver kopieren und schon läuft die Seite 1:1, wie in der Produktion. Damit ist sowohl das Deployment Problem als auch das Backup Problem gelöst. Eine veraltete Testumgebung ist mit Grav und Git Vergangenheit.

    Im Klartext: Ich kann die komplette Webseite in Git ablegen und sie auf jeden beliebigen Webserver klonen und arbeiten.

    Für versionierte Gitbenutzer können alle möglichen Gimmicks eingebaut werden: Autodeployment via Webhooks, Branching Strategie …

    4. Grav bietet eine möchtige Form API und ein Plugin System. Zwar gibt es noch nicht annähernd die Flut an Plugins, wie sie in der WordPress Welt vorhanden sind, aber das ist auch nicht zwingend etwas schlechtes.

    Theoretisch könnte auch eine Gravseite von der Pluginseuche befallen werden, die direkte Codenähe macht es allerdings eher unwahrscheinlich oder zumindest weniger schlimm, als dies bei WordPress der Fall ist. Ein Google Analytics Tracker z.B. liesse sich mit genau zwei Zeilen (1x Config, 1x Template) einbauen.

    5. Geschwindigkeit. Die Einfachheit macht die Systeme schnell. komplizierte Mechanismen, komplexe und schlechte programmierte Plugins fallen weg. Auch Anfragen an die Datenbank fallen weg. Für hohe Lasten mit vielen gleichzeitigen Zugriffen ist wahrscheinlich eine Datenbank besser, aber im Bereich von Otto-Normalsterblich sicher nicht. Für die Optimierung muss lediglich am Webserver Hand angelegt werden.

    Wo liegen die Probleme

    Wo Licht ist fällt auch Schatten. Grav zu skalieren wird wohl nicht ganz so einfach sein, wie das mit einer Datenbank möglich ist. Solange ein Server ausreichend ist, sicher kein Problem, aber sobald nach Loadbalancing gefragt ist, könnte es schwieriger werden. Ich kenne mich jedoch zu wenig damit aus, um eine qualifizierte Aussage zu machen.

    Eine Aussage kann ich jedoch zu Content Management machen. Wenn Content aktiv verwaltet wird und damit gearbeitet wird ist Grav nicht wirklich komfortabel. Ich habe dieses Blog hier auf Grav migriert und ein wenig damit gearbeitet. Spass hat das nicht gemacht.

    Es gibt ein Admininterface, aber um hunderte von Seiten zu verwalten… ich weiss nicht so recht. Da fühle ich mich mit WordPress wohler.

    Wann verzichte ich also auf WordPress?

    Für mich ist WordPress für kleine hauptsächlich statische Seiten definitiv gestorben. Der Overhead und die Risiken und damit die Wartung sind zu gross, als dass die Vorteile überwiegen würden.

    Dazu hat mich die Portabilität mehr als überzeugt und bei einem schief gelaufenen Update einfach mal schnell auf eine vorherige Version zu wechseln gibt mir sehr viel Sicherheit. Auch ein Serverwechsel würde nur wenig Minuten dauern: «git clone».

    Auch die mächtigen Pagebuilder können mich nicht überzeugen. Im Gegenteil: Für mich als Developer sind sie eher hinderlich, mühsam und komplex und für totale Anfänger bergen sie das Potential die Seite zu zerstören.

    Kunden sind zufrieden, wenn sie Texte schnell und einfach anpassen können und sind gerne bereit für grössere Änderungen zum Profi zu gehen.

    Geht es in Richtung Blog oder Community mit viel Interaktion werde ich nach wie vor auf WordPress und Co. setzen.

  • Innovation durch Produktekombination

    Innovation, die Umsetzung guter Ideen (lediglich eine gute Idee zu haben ist meiner Ansicht nach noch keine Innovation). Innovation ist immer gefragt. Das Silicon Valley ist der Inbegriff von Innovation. Die Steigerung von Innovation ist Disruption: Die Innovation ist so gut, dass ganze Sektoren umgekrempelt werden: Beispiel Uber und Airbnb.

    Eine mögliche Technik, um zu neuen Innovation zu kommen ist die Kombination von zwei fremden Produkten. Gerade eben habe ich ein super gutes Beispiel dafür gefunden: Die Western Digital G-Drive. Die Festplatte, welche sowohl als Datenspeicher als auch als Netzteil für Notebooks funktioniert. Die Kombination zweier für Notebookbesitzer gängiger Tools, werden in einem Tool vereint.

    Gedanklich könnte man alle möglichen Produkte durchgehen und schauen, was bei der Verschmelzung herauskommt:

    • Eine Maus und ein Externe Festplatte?
    • Webcam und eine Maus?
    • Bildschirm und Webcam?
    • Drucker und eine Webcam?
    • Powerbank und Externe Festplatte?

    Klar, gewisse Sachen sind offensichtlich unbrauchbar, andere wiederum technisch wohl eher schwierig realisierbar. Aber so kommt man relativ rasch zu vielen Ideen.

    Den ursprünglichen Beitrag habe ich auf t3n gefunden.

  • Das erwartet dich am 3 tägigen Scrum Master Kurs

    Agile, XP, Lean, Scrum, Kanban und wie sie alle heissen. Ich vergrabe mich für 3 Tage in ein Kurszimmer, um mich im Detail mit Scrum zu befassen. Meine Scrum Erfahrung reicht bereits einige Jahre zurück.

    Wir schreiben das Jahr 2009. Als Hochschulabsolvent und Programmierer darf ich einen frei gewordenen Platz in einer Scrum/Kanban Tagung ergattern. Es ist alles neu. Die Professoren haben es verpasst über das Wasserfall Modell hinaus zu schauen. Ich bin begeistert.
    Obwohl es ein tägliches «sich-die-Beine-in-den-Bauch-Stehen» gibt, sind wir weit weg von Scrum: Teilpensen in verschiedenen Projekten, fehlender PO bzw. mangelnde Kompetenzen und mangelndes Verständnis für den Prozess.
    Büchern und Blogs sei Dank, lese ich mich ein und langsam formen wir ein erstes richtiges Scrum Team.

    Es sind 8 Jahre vergangen. In der Marketingabteilung eines Medizinischen Grosskonzerns war Scrum (noch) nicht anwendbar. Zu viel Politik, zu wenig Fokus, zu kleine Projekte, zu starre Vorgaben und Richtlinien des Konzerns.

    Die 3 tägige Ausbildung soll die Erfahrung, das Halbwissen und offene Fragen ergänzen und mich in einen Scrum Master verwandeln. Dieser Post soll nicht Scrum erklären (dafür gibt es genügend andere Blogs und Videos, welche das viel besser tun), sondern meine Take Aways und Gedanken darlegen.

    Was habe ich aus den drei Tagen mitgenommen

    In der Kürze liegt die Würze. Daher hier die Key Learnings und Aha Momente aus dem Kurs:

    • Das Team steht im Zentrum. Dazu gehört, das Entwicklungsteam, der Product Owner (PO) und der Scrum Master.
    • Der Scrum Master ist der IT Sozialarbeiter.
    • Entwicklungsteam ≠ Programmiererteam. Produktentwicklungsteam wäre der bessere Namen.
    • Im Vergleich zu Kanban bietet Scrum einige fix fertige Elemente (bsp. Retro, Daily, Sprint Planning)
    • Sprint Planning I bestimmt das Was, Sprint Planning II das Wie
    • Architekturfragen werden im Sprint Planning II adressiert.
    • Der Scrum Master ist für erfolgreiche, konstruktive Meetings verantwortlich
    • Review Meeting ≠ Demomeeting, wo der PO zum Produkt nickt. Vielmehr ist es die Gelegenheit für die Stakeholder (sprich potentielle Kunden), das Produkt zu reviewen und Feedback zu geben.
    • Das Tool der Wahl: Filzstift und Flipchart
    • Scrum ist radikal, Kanban sanft
    • Regeln für selbstorganisierende Team sichtbar machen
    • Dazu einige Taktiken und Werkzeuge für das Leben als Scrum Master: [ROTI](http://boeffi.net/tutorials/roti-return-on-time-invested-wie-funktionierts/), [Daumen Voting](https://www.oose.de/blogpost/entscheiden-im-konsens-teil-3-thumb-voting-und-fist-to-five/) und Führen durch Fragen.

    Obwohl ich im aktuellen Projekt nach Kanban arbeite, gibt es das eine oder andere aus Scrum, welches sich anwenden lässt. Daher meine Gedanken in aller Tiefe (ScrumBan ist übrigens ein offizieller Begriff).

    Das Team im Zentrum

    Damit ein Team im Zentrum stehen kann, muss es ein Team geben. Laut Wikipedia ist Team wie folgt definiert:

    Der Anglizismus Team bezeichnet einen Zusammenschluss von mehreren Personen zur Lösung einer bestimmten Aufgabe oder zur Erreichung eines bestimmten Zieles.

    In der Realität besteht unser Team aus 2 handvoll Kernteam Mitgliedern und einer Vielzahl von «Hobby Mitglieder». Auf den Sport übertragen: 7 Feldspieler und 5 Spieler, welche spielen wenn sie Lust und Zeit haben.

    Massnahme ist einfach: Entweder bist du dabei oder nicht und jeder im Team weiss, wer Feldspieler ist und wer lediglich auf der Ersatzbank für Spezialeinsätze sitzt.

    Der Scrum Master als Sozial Arbeiter

    Geht es dem Team gut. Sind alle glücklich und können unbesorgt arbeiten. Falls nicht, ist mindestens die eigene Produktivität beeinträchtigt und wahrscheinlich auch die der Kollegen.

    Massnahme: Regelmässigen Kontakt mit allen Teammitglieder. Spezifisch auf den Zahn fühlen, wie es läuft und wo der Schuh drückt.

    Interessant die Antwort auf die Frage bezüglich der Arbeitsauslastung im Projekt. Sehr einfach mit Directpoll auch im Plenum anonym durchführbar.

    Entwicklungsteam ≠ Programmiererteam

    Den Name ist irreführend. Entwicklung beschränkt sich nicht auf Code sondern auf ein Produkt. Das Produkt kann eine Software, eine Kamera oder eine neues 5 Gang Menu sein. Spiel keine Rolle.

    Daher soll sich auch ein Designer, Tester, Anforderungsmanager, Jurist, Architekt oder Koch damit identifizieren können.

    Massnahme: Keine.

    Bewährte Praktiken von Scrum *stehlen*

    Die 6 Praktiken von Kanban sind:

    1. Visualisiere
    2. Limitiere den Work in Progress (WIP)
    3. Manage Flow
    4. Mache Prozessregeln sichtbar
    5. Implementiere Feedback Loops
    6. Führe Verbesserungen basierend auf Methoden und Modellen durch

    Kanban gibt jedoch nicht vor, wie diese Praktiken konkrete umgesetzt werden sollen. Scrum hingegen ist sehr konkret: Es gibt Sprint Planning, Daily, Review und Retro. Alle Loops mit dem Ziel Feedback möglichst schnell zu erlangen. Viele davon funktionieren auch sehr gut in Kanban.

    Massnahmen: Die Sprintplanning Sache wäre ein Gedanke wert, allerdings ist dieser noch nicht reif genug.

    «Sprint Planning I» bestimmt das Was, «Sprint Planning II» das Wie

    Zu meinen Scrum Zeiten gab es lediglich eine Sprint Planning Session, in welcher wir uns hauptsächlich um das «Was» kümmerten. Das Wie ging oftmals einfach irgendwie unter bzw. jeder fing dann mal an. In letzter Zeit kam somit auch immer mal wieder die Frage auf, wie man denn mit Architekturfragen umzugehen hat: Sprint Planning II eben. Damit habe ich auch bereits mein nächstes Aha Erlebnis beschrieben:

    Architekturfragen werden im Sprint Planning II adressiert.

    Der Scrum Master ist für erfolgreiche, konstruktive Meetings verantwortlich

    Leider erlebe ich viel zu oft langweilige Meetings, wo ich gegen den Schlaf ankämpfen muss. Oftmals kommt es daher, dass jeder etwas dazu sagen möchte, aber nur beschränktes Wissen hat und anstatt die Leute einzeln abholt alle an einen runden Tisch holt. Das Grundproblem liegt daran, dass das Wissen zu verteilt ist und oftmals eine Kluft zwischen Wissen und Verantwortung klafft (ein fundamentales Problem von Management).

    Der Klassiker. Das Meeting wird mit ein paar Slides eröffnet, um dann über das Problem und die Lösung zu diskutieren bzw. bis man aus dem Meeting Raum geworfen wird. Warum hier nicht kreativer Arbeiten?

    Massnahme: Mehr Zeit in die Vorbereitung von Meetings stecken (und dafür weniger Meetings abhalten).

    Review Meeting ≠ Demomeeting

    Schon gar nicht wird hier dem PO gezeigt, wie cool die neuen Features sind und wie schnell die neue Lösung ist. Der PO ist teil des Teams und weiss das bereits vorher.
    Im Review Meeting geht es darum, Feedback von richtigen Stakeholders einzuholen. Insofern muss ein Review Meeting nicht eine plumbe Demo sein, wo der Entwickler am Beamer ein paar Usecases durchspielt, sondern kann durchaus auch interaktiv sein: Zum Beispiel ein paar Computer hinstellen und die Stakeholders dazu einladen damit zu spielen und auch gleich Feedback zu geben.
    wo der PO zum Produkt nickt.
    -> Im Sprint haben wir ein «potentially shipable product» gemacht: Getestet und ohne Bugs!

    Massnahmen: Keine

    Scrum ist radikal, Kanban sanft

    Kanban kann relativ sanft eingeführt werden. Der aktuelle Prozess wird nicht geändert sondern lediglich visualisiert. Scrum hingegen erfordert eine Umstellung. Entweder ich arbeite nach Scrum und halte mich an die paar Vorgaben und Rahmenbedingunen oder aber ich habe mein eigenes Framework.
    Insofern schmerzt die Scrumeinführung wahrscheinlich mehr, dafür ist bei Kanban die Gefahr, dass es lediglich eine übergestülpte Hülle bleibt und dem Team vorgaukelt, dass es jetzt agil arbeitet.

    Massnahmen: Keine

    Regeln für selbstorganisierende Team sichtbar machen

    Anstatt tausende von Regeln und Rahmenbedingungen irgendwo in einem Projekthandbuch, welches eh niemand liest zu führen, diese lieber auf ein Flipchart schreiben und aufhängen. Reicht ein Flipchart nicht, gibt es wahrscheinlich zu viele Regeln.
    Entweder man hält sich an die Regeln oder man löscht/ändert die Regel wieder, setzt aber voraus: Der Scrum Master hält eine Auge drauf.

    Massnahme: Regeln auf Flipchart visualisieren.

    Das Tool der Wahl: Filzstift und Flipchart

    IT schön und gut, doch ist Papier viel geduldiger. Anstatt Power Point Schlachten zu fechten können ein paar Flipcharts viel effektiver sein.

    Massnahme: Think, Baby Think. Anstatt für jedes Meeting gleich ein leeres Powerpoint zu öffnen, die grauen Hirnzellen anwerfen und schauen, wie man das Thema sonst noch angehen könnte.

  • Geeksession – Atom und Grav

    Ich bin viel zu alt, um mich noch mit Code zu plagen. Lieber tummle ich mich in Meetings, schiebe Termine, motiviere Leute, gestalte Kanban Boards und versuche intelligent und allwissend zu sein.

    Ich bin umgeben von jungen dynamischen Freaks und Nerds. Sticker zieren die Macbooks, die Kaffeefahne kündigt das Eintreffen an, bevor sie um die Ecke biegen und das Hemd ist nie gebügelt … meistens sowieso ein T-shirt.

    Das Lebens eines Projektmanagers halt. Auch schön. Anders halt.

    Zwischendurch packt es mich dann trotzdem noch. Meine neueste Spielwiese im Doppelpack:

    Atom

    "Screenshot von Atom Editor" "Atom Editor"
    Angefangen mit Windows Notepad (ja damit habe ich vor Jahrzenten mal Javascript und Java programmiert). Weiter zu Notepad++, irgendwann kamen die Elefanten IDEs rund um Eclipse. Weiter zu Sublime. Der Newcomer, welcher die Entwickler begeisterte und jetzt also bei Atom.

    Der Sprung von Sublime zu Atom ist relativ klein. Was ich extrem schätze ist:

    • Git Integration mittles Git Plus Package! Sehr cool. Besser als bei Sublime
    • Markdown Support und Live Preview fürs Scolling braucht es noch das Package Markdown Scroll Sync
    • Sieht einfach ein bisschen moderner aus

    That’s it. Wie gesagt, der Sprung war nicht besonders gross.

    Grav CMS

    "Screenshot Grav CMS" "Grav CMS Screenshot"
    Auch hier ist mein Leidensweg lang: Joomla, Drupal, WordPress mit einem Schlenker zu Sharepoint, ein paar Ausflüge in die Welt der Static Site Generators zurück zu WordPress und jetzt also neu bei Grav. Das kleine CMS ohne Datenbank.

    Die Static Site Generators fand ich auf Anhieb sympathisch. Ein bisschen yaml und Markdown, mittels Templatesprache die ganzen Attribute Verarbeiten und fertig ist die wunderschöne Seite.

    Klar: Auch in Drupal geht das, Felder zusammenklicken und ein paar Plugins installieren, allerdings meist auf Kosten von vieeeel HTML Code und CSS, welches umgebogen werden muss. Noch schlimmer mit WordPress: Die megabyite schweren Themes mit den wenig sympathischen Pagebuildern. Die sind gut gemeint und sicher auch nützlich, aber ein graus zum Customizen und warten.

    Dazu kommt bei Drupal und Co die ganze Datenbankgeschichte. Auch nicht immer schön und um mal schnell lokal ein paar kleine Änderungen am Code zu machen, bis die Site dann lokal läuft… geht mal schneller mal langsamer.

    Grav CMS verbindet irgendwie die Welten von Drupal und Co. mit den Static Site Generators. Der Inhalt wird in Ordnern in Markdown abgelegt und on-the-fly ins Template eingebaut und als HTML ausgeliefert.

    Passend dazu gibt es ein kleines einfaches Admin Interface, um kleine Änderungen schnell und einfach durchzuführen und dazu eine sehr mächtige Form API.

    Nach 7 Tagen Grav bin ich noch weit davon entfernt ein Experte zu sein, aber ich würde meinen ich finde mich zurecht.

    Wer nicht millionen (oder auch tausende) von Benutzer hat, lediglich ein paar wenige Seiten hat und einfach und direkt mit dem System arbeiten will, für den ist Grav sicher in Versuch wert.

    Einmal Geek immer Geek

    … so schnell werde ich das wohl nicht ablegen. Zwischendurch in die Tasten zu hauen, hat doch etwas beruhigendes.

  • Kann eine grosse Firma agile sein?

    Kann eine grosse Firma agile sein?

    Wahrscheinlich schon. Nichts ist unmöglich, aber wie?

    Für ein Startup bestehend aus drei Personen ist Agilität kein Problem. Ein Einzelunternehmen? Keine Frage, ausser es handelt sich um einen Masochist, der sich gernen komplexen Prozessen unterwirft. Agilität ist per se einfach da. Ein KMU mit 50 Mitarbeitern? Schon schwieriger, aber sicher machbar. Doch wie sieht es mit einem Konzern mit 30’000 oder gar 100’000 Mitarbeitern aus? Überhaupt möglich?

    Agile heisst so viel wie: Wendig, lebendig, flink oder beweglich. Eine Fliege ist beweglich. Ein Maus ist flink. Ein Hund kann lebendig sein, aber schon nicht mehr ganz so flink. Und ein Blauwal? Oder ein Elefant? Schon mal einen flinken Elefant gesehen? Eher nicht. Daher nochmals die Frage, kann ein Elefantenunternehmen überhaupt agil sein?

    Was ist Agilität? Was es sicher nicht ist: Agil ist weder ein Framework noch eine Methodik. Agile ist weder Scrum noch Kanban noch XP. Agile ist eine Lebenseinstellung, ein Mindset eine Kultur. Eine Kultur, wo das Produkt und der damit generierte Nutzen im Vordergrund steht. Ich verbinde Agilität mit Leidenschaft gegenüber der Arbeit. Agilität setzt viel intrinsische Motivation voraus, Veränderung und Verbesserung voranzutreiben.

    Politische Machtkämpfe, Gärtchendenken und Cover-my-Ass Mentalitäten finden keinen Platz in einer wirklich agilen Welt. Gibts einen Konzern, wo das nicht vorhanden ist?

    Nehmen wir mal Scrum. Es gibt einen Product Owner, einen Scrum Master und das Team. Es gibt keinen Projektleiter. Dann kommt immer gleich: «Ja aber irgend jemand muss ja Druck ausüben.» «Das Team ist verantwortlich, dann wirds sicher nicht rechtzeitig fertig.» Stimmt genau das ist das Paradigma in vielen Grosskonzernen, doch stimmt halt nur bedingt für Scrum. Diese Tätigkeit übernimmt dann eben der Product Owner.

    Organigramm

    Um zurück auf meine Frage zu kommen, ob grosse Firmen agile sein können. Keine Ahnung. Dafür müsste es eine Definition von «agile» geben und da gibt es einige, allerdings findet sich eine Gemeinsamkeit:

    sind unter anderem moderne Formen der internen Kommunikation – die Verwendung eigener Social Media innerhalb der Firma, die starre Informations- und Abstimmungsstrukturen aufbrechen sollen. [Haufe.de]

    Oder auf mbaskool.com

    Agile enterprises thrive in non-hierarchical organizations without a single point of control.

    Und auf agile-ux.com

    Agility is the ability of an organization to create value and to continuously delight the customer, while promoting and responding to change in its environment

    zum Schluss noch von Alain Veuve 

    Fast moving, flexible and robust firm capable of rapid response to unexpected challenges, events, and opportunities. Built on policies and processes that facilitate speed and change, it aims to achieve continuous competitive advantage in serving its customers. Agile enterprises use diffused authority and flat organizational structure to speed up information flows among different departments, and develop close, trust-based relationships with their customers and suppliers.

    Wenn ich es zusammenfassend müsste, dann sprechen wir hier von dezentral autonom agierenden Teams, ähnlich einer Terrorzelle. Ein Guru, welcher die Vision vorgibt und viele die selber schauen, was sie daraus machen. Zentralisierung und Agilisierung, passt daher meiner Meinung nach nicht zusammen. Ohne Zentralisierung gibt es jedoch keine Skaleneffekte und ohne diese Effekte, sind doch gewisse Industrien gar nicht Lebensfähig?

    Reine Spekulation und wilde Gedanken. Gerne würden mich Erfahrungen interessieren von Menschen, welche bereits in einem agilen Konzern mit 20’000 Mitarbeitern gearbeitet haben.