Archiv für den Monat März 2015

Nachgefragt – Interview mit Daniel Marbach zu MSpec

In einem Online Interview habe ich Daniel Marbach zur Zukunft des Open Source BDD Frameworks MSpec befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden nicht vorab abgesprochen, um ein authentisches statt ein werbelastiges Gesprächs zu führen.

 

image

Auf das Bild klicken um zum Video zu gelangen

 

An dieser Stelle möchte ich noch die Community aufrufen sich an der Weiterentwicklung zu beteiligen. Open Source Projekte leben von freiwilligen Helfern und Daniel macht da eine sehr gute Arbeit und ein tolles Produkt!

Fragen

  • Machine.Specifications
  • Was ist eigentlich ein BDD Framework
  • Stärken
  • Schwächen
  • Roadmap
  • Wie steht es um die Zukunftssicherheit
  • Tipps und Tricks
  • Ergänzende Frameworks
  • Gute Tests

 

Show Notes

Werbung

How to get the PostSharp package running with Paket

Recently, I reported some difficulties that I‘ve experienced with the PostSharp NuGet package when I was using the new package manager Paket. I tracked the problem down to the ‚install.ps1‘ script which is executed by NuGet after adding PostSharp to a project. This PowerShell script (located under packages\PostSharp\tools) patches your project file. Since this behaviour is already proclaimed from the pulpit by NuGet, I hope that PostSharp is going to remove that asap. Until then, you can execute the script manually or patch the csproj-File by yourself.

In order to do that, insert the following 2 snippets at the the position shown in the screenshots:

   1: <DontImportPostSharp>True</DontImportPostSharp>

 

image

 

Don’t forget to change the relative path to your PostSharp package in the following snippet:

   1: <Import Project="..\..\packages\PostSharp\tools\PostSharp.targets" Condition="Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" /> 

   2: <Target Name="EnsurePostSharpImported" BeforeTargets="BeforeBuild" Condition="'$(PostSharp30Imported)' == ''">

   3: <Error Condition="!Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" Text="This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://www.postsharp.net/links/nuget-restore." />

   4: <Error Condition="Exists('..\..\packages\PostSharp\tools\PostSharp.targets')" Text="The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://www.postsharp.net/links/nuget-restore." />

 

image

 

I also recommend you to activate the following PostSharp Option in Visual Studio:

image

Interview mit Daniel Marbach mitgestalten

Am 18. März wird mir Daniel Marbach ein Video Interview zu dem BDD-Framework Machine.Specifications geben. Ein kleiner Vorgeschmack gefällig?

Wodurch hebt sich MSpec von anderen BDD-Frameworks ab?

oder

Welche Features sind gerade in der Pipeline?

oder

Welche anderen Frameworks ergänzen MSpec gut?

Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die Richtung des Gesprächs mitgestalten, indem ihr mir rechtzeitig eure Fragen in die Kommentare postet.

Nachgefragt – dotnetpro Interview mit Tilman Börner

In einem Online Interview habe ich Tilman Börner über die digitale Zukunft der dotnetpro und die Anforderungen an potentielle Autoren befragt. Herausgekommen ist eine Aufnahme, die es jetzt auf YouTube gibt. Die Fragen wurden vorab nicht abgesprochen, um eine Gesprächsatmosphäre zu schaffen, wie sie bei einer Kaffeepause üblich ist.

Danke nochmal Tilman!

 

Interview mit Tilman Börner

 

Fragen

  • Angehende Autoren
    • Formale Anforderungen an einen potentiellen Autor
    • Formale Anforderungen an einen Artikel
    • Von der Idee bis zum fertigen Artikel: Das Prozedere kurz erläutert
    • Was macht einen guten Autor aus?
  • Änderungen am Magazin
    • Gibt es gerade einen Umbruch?
    • Finden Themenverschiebung statt?
  • Die Digitale Welt
    • Wird es vollwertige Ausgaben für Android und Kindle geben?
    • Wann bekommt die Homepage einen neuen Anstrich?

 

Show Notes

Schlanke Prozesse sind gute Prozesse oder warum wir Kanban einführen

In unserer IT Administration führen wir regelmäßige Retrospektiven durch. Das ermöglichte es uns Kategorien von Problem zu identifizieren, wie sie auf dem Bild zu sehen sind.

2015-03-04 18.36.43

  • Weniger wichtige Aufgaben wurden zuerst erledigt (Priorisierung)
  • Vermeintlich kurze Projekte haben sich stark in die Länge gezogen
  • Aufgaben wurden nicht vollständig erledigt
  • Zuständigkeiten / Ansprechpartner waren nicht klar
  • Aktuelle Projektstände waren nicht transparent
  • Aufgaben blieben bei Externen hängen bzw. blockierten uns
  • Engpässe / Verzögerungen machten uns das Leben schwer
  • Planung war schwierig
  • Häufiges “auf einen Stand bringen” und mehrfaches Besprechen gleicher Punkte

Die Systemadministration ist von Natur aus ein stark vom Tagesgeschäft abhängiges Umfeld mit viel Klein-Klein-Arbeit. Der Anwender ruft an, meldet PC Probleme (Spezifisches hört man selten), der Kollege unterbricht seine eigentliche Tätigkeit wie z.B. die Vorbereitung einer größeren Umstellung und kümmert sich um die Nöten des besorgten Anrufers. Kaum zurück und wieder in die Umstellung vertieft, kommt eine E-Mail, dass die Druckertoner leer sind. Erneut gilt es die aktuelle Arbeit zu unterbrechen.

Darüber hinaus laufen natürlich immer Projekte mit anderen Abteilungen oder Externen (Telekommunikationsanbieter, Dienstleister, etc.), die voran getrieben werden müssen. Selbst der Entwickler-Kollege aus der selben Abteilung ruft an und möchte einen neuen Testserver aufgesetzt bekommen – am besten vorgestern versteht sich.

Kurzum: Ein reges Tagesgeschäft parallel zu großen Projekten und das alles im Umfeld von unterschiedlichen Stakeholdern. So wie es auch in Marketingabteilungen oder Zentralen der Fall ist.

Nüchtern betrachtet handelt es sich um eine Warteschlangensystem. Da Menschen nicht gut darin sind viele Dinge parallel zu machen, vermuten wir hierin eine der Ursachen: Zu viele Dinge werden gleichzeitig erledigt. Außerdem stehen wir Dritten skeptisch gegenüber, welche uns rein gefühlsmäßig ausbremsen. Bei den Telekommunikationsanbietern können wir indes von einer Tatsache sprechen…Darüber hinaus meinen wir diverse weitere Hindernisse erkannt zu haben, die den Arbeitsfluss immer wieder stören.

Um weil wir uns gerne verbessern möchten, eine zu große Umstellung auf einmal eher scheuen und der Evidenz der Vermutung den Vortritt geben möchten, haben wir uns entschieden Kanban einzuführen. Auf einen Nenner gebracht liegen dem 3 Prinzipien und 5 Praktiken zu Grunde.

Prinzipien:

  • Starte mit dem, was du jetzt machst
  • Verfolge inkrementelle, evolutionäre Veränderungen
  • Respektiere initiale Prozesse, Rollen, Verantwortlichkeiten und Job-Titel

Praktiken:

  • Mache Arbeit sichtbar
  • Limitiere den WIP
  • Manage den Arbeitsfluss
  • Mach Prozess-Regeln explizit
  • Führe gemeinschaftliche Verbesserungen durch (basierend auf Modellen)

Alle Regeln werden penibel eingehalten, jedoch ist die erste Regel alle Regeln abzuschaffen, die nicht mehr funktionieren.

Über die ersten Ergebnisse werde ich demnächst berichten. Falls jemand schon gute Erfahrungen primär im Administrationsumfeld gemacht hat, dann würde ich mich über Input freuen. Gerne auch aus der Softwareentwicklung.

Interview mit der dotnetpro mitgestalten

Am 12. März werde ich mit Tilman Börner ein Online Interview führen. Die Fragen beziehen sich natürlich primär auf die dotnetpro. Ein kleiner Vorgeschmack gefällig?

Kann jeder einfach Autor werden und einen Artikel schreiben?

oder

Wann können wir mit einer Kindle Ausgabe rechnen?

oder

Welche Änderungen sind dieses Jahr nach dem Design Relaunch noch zu erwarten?

Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die Richtung des Gesprächs mitgestalten, indem ihr bis zum 11 März eure Fragen in die Kommentare postet.

Es gibt keine passive Kaizen-Kultur

Es braucht keine Retrospektiven und dedizierte Kaizen Phasen; schließlich hat das vorher auch alles geklappt und die Verbesserungen haben sich genauso eingestellt.

Aussagen wie diese hört jeder Change Agent früher oder später. Ich will gar nicht abstreiten, dass in jedem Unternehmen mehr oder weniger kontinuierlich optimiert wird. Jedoch geht durch das passive Verhalten viel Potential verloren. Das kann jeder ganz einfach kontrollieren. Der geneigte Leser soll dazu für einen kurzen Zeitraum – beispielsweise 2 Monate – jede Idee protokollieren, welche von Kollegen mit “das müssen wir mal machen” oder “das sollten wir demnächst angehen” kommentiert wird. Im Anschluss ist zu prüfen, was tatsächlich umgesetzt wurde. Ich wäre überrascht, wenn bereits 5% fertig sind. Wohlgemerkt fertig umgesetzt, nicht nur angefangen und wieder liegen gelassen. Ganz im Sinne von stop starting, start finishing. Bereits die Definition von Kaizen drückt das aus:

“Kaizen […] bezeichnet ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht.”Wikipedia

Es handelt sich um ein methodisches Konzept. Eine Methode ist ein systematisches Verfahren. Laissez faire im Kontext von Verbesserungen kann aber nicht systematisch sein. Passive Kaizen-Kultur ist also ein Widerspruch.

Ein klarer Indikator für ungenutztes Potential, ist das wiederholte Auftreten des gleichen Problems. Der erste Gedanke, der einem dann kommt, ist: Mist, das wollten wir doch mal machen (siehe Aussage oben). Das können häufig kleine Dinge wie eine fehlende Fahrzeugpoolverwaltung oder eine Verwaltung für die ohnehin nicht gerade reichlichen Besprechungsräume sein. Aber auch komplexere Themen wie die hohe Informationsflut im Zeitalter der Wissensarbeit. Schon mal über eine SharePoint Dokumentenbibliothek oder ein Wikisystem nachgedacht? Und wenn ja, auch realisiert?

Unabhängig von den Implementations-Phasen solcher Ideen/Lösungen, gehören zu einer soliden Kaizen-Kultur auch Retrospektiven. Selbstverständlich werden hier wieder Stimmen laut, die behaupten, dass ich mir doch keine Zeit reservieren muss, in welcher ich reflektiere und nach Verbesserungsmöglichkeiten suche. Das ist leider eine ähnliche Floskel wie:

Wir brauchen keine Mitarbeitergespräche. Wir reden regelmäßig miteinander.

Wer sich aber mit den Themen intensiv beschäftigt und ganz darauf einlässt, stellt einen großen Unterschied fest. Persönlich habe ich sogar den Eindruck, dass durch kurze, oberflächliche Problemanalyse Lösungen entwickelt werden, die das Symptom kaschieren, nicht aber aber die Ursache beheben. Als Change Agent hat sich in dem Fall die sokratische Methode bewährt. Stelle solange W-Fragen (Warum, Wer, Was) bis – wie Goethe sagt – des Pudels Kern gefunden ist.

Der Leser kann sich dazu kurz in Erinnerung rufen wie es bei der Zulassungsstelle bei einer Ummeldung abläuft. An dem einen Schalter beantragt man die Anmeldung. Mit dem Papier geht man an den Schalter neben an. Natürlich muss dort wieder angestanden werden. Nach einer meist längeren Wartezeit wird dort das alte Schild vernichtet und das neue ausgegeben. Damit läuft man wieder an den ersten Schalter und nach noch längerer Wartezeit erhält man dann endlich die Papiere.

Wenn ich jetzt danach frage, wie sich der Prozess optimieren lässt, dann kommt ohne lange Überlegung die Antwort: Na indem am Schalter schneller gearbeitet oder mehr Personal eingestellt wird. Überstunden wären ebenfalls möglich. Das sind zwar alles Optionen, allerdings lange nicht die besten, da diese nur sehr beschränkt skalieren und teuer sind. Vielleicht ist das der Grund, warum bis heute die meisten Kfz Halter sich einen halben Tag Urlaub für das Ummelden nehmen müssen. Eine mathematisch nachweislich bessere Antwort gibt es hier.

Fazit

Keine Frage: Es braucht kleine, kontinuierliche Verbesserungen, damit die Unternehmen diese verdauen können. Evolution statt Revolution (manchmal auch letzteres!). Aber Evolution im Schneckentempo gleicht eher einem Rückschritt, weil die anderen schneller voran kommen. Wer jeden Tag 30 Minuten ins Fitnessstudio geht und sonntags ruht, hat am Ende der Woche auch 3 Stunden trainiert. Und genauso wie Trainings als feste Termine eingeplant werden müssen, bedarf es auch fester Zeiten für Retrospektiven und die Umsetzung der daraus resultierenden Ergebnisse.

Und wenn der Leser immer noch motiviert ist, dann kann er gerne einen Kommentar hinterlassen, ob in seinem Unternehmen bereits Kaizen an der Tagesordnung ist oder nicht und warum respektive warum nicht.

%d Bloggern gefällt das: