Freilichtmuseum Stübing

Diese Diashow benötigt JavaScript.

ASP.NET vNext (Alpha 3) und Ubuntu

Katana, als eine Implementierung zu Owin, setze ich aktuell in zahlreichen Projekten ein. Weit angenehmer soll ASP.NET vNext werden. Da ich in den letzten Monaten wieder vermehrt mit Linux arbeite, musste ich natürlich gleich die Plattformunabhängigkeit testen, zumindest wenn es an die Installation ging. Da gab es dann aber doch ein paar Hürden, die jedoch schnell gelöst werden konnten.

Sehr hilfreich hat Christian Weyer zahlreiche Informationen und Tipps zusammen getragen.

Das funktionierte eigentlich auch gut, bis auf die Geschichte mit libuv. Der angegebene Hinweis hat bei mir nicht funktioniert. Eine Alternative, die unter Ubuntu 14.04 läuft findet sich hier.

Zusammengefasst:
* Kestrel beziehen
* Kompilieren
* libuv.so.1 nach ~/.kpm/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-alpha3/native/darwin/universal/libuv.dylib kopieren

Und hier der Beweis:
ASP.NET vNext (Alpha 3) unter Ubuntu

Anforderungen an die Produktentwicklung

Produktentwicklung ist eine richtig schwierige Angelegenheit und birgt zahlreiche Gefahren in sich. Da bedarf es nicht nur ordentlicher finanzieller Mittel, sondern auch einiges an Mut. Mut zu Entscheidungen, die gerade den ersten Kunden nicht wirklich gefallen werden.

Bedarf erkennen und Lösung anbieten

Wer mit einem Produkt erfolgreich sein möchte, muss einen konkreten Bedarf erkennen und lösen können. Entweder besitzen viele denselben Bedarf und es gibt noch keine Lösung hierzu oder man schafft es, einen Bedarf mit dem eigenen Produkt zu wecken.

Idealerweise ist man selbst der Mittelpunkt des Bedarfs und will das zu schaffende Produkt vorrangig für sich selbst einsetzen.

Die Grundidee, quasi die Vision des Produkts, muss an alle Beteiligten kommuniziert werden. Wer daran mitarbeitet, muss dahinter stehen um das Ziel mit Nachdruck verfolgen zu können. Große Zweifel an der Lösung, des gewählten Weges oder aber auch des Umfanges können das Projekt sehr schnell scheitern lassen.

Konsequente Verfolgung des Ziels

Der wohl wichtigste Schritt in der Produktentwicklung ist das Schaffen einer ersten verkaufbaren Version. Das sollte ein möglichst kleines Set des zu erreichenden Ziels sein. Dennoch muss es einen klaren Nutzen bringen, soll es auch verkauft werden können.

Dazu ist es unabdingbar, hartnäckig in die gewünschte Richtung zu arbeiten. Natürlich werden sich einige Dinge anders entwickeln als zuvor geplant, Ablenkungen sollten aber ferngehalten werden.

Essentiell ist aus meiner Sicht, diese erste Phase ohne gröbere Änderungen zu beenden. Das bedeutet:

  • Verkaufbarer Umfang definieren
  • Marketing / Vertrieb darauf abstimmen
  • Definierten Umfang entwickeln

Gerade in dieser Phase darf es keine Richtungsänderungen geben. Das würde das Produkt bereits in den Anfängen auf einen instabilen Boden stellen (sowohl technologisch, als auch in den Köpfen der involvierten Personen).

Nicht von Kunden steuern lassen

Jedes Produkt startet mit einem bzw. wenigen Kunden. Diese melden zurück, hätten gerne diese Verbesserung und diese Änderung. Außerdem hätten sie das auch gerne so, denn so arbeiten sie, nicht anders.

Natürlich muss man sich die Rückmeldungen der Kunden genau ansehen und sie teilweise (!!) einfließen lassen. Wie und was davon ins Produkt übernommen wird, entscheidet aber nicht der Kunde. Man darf sich hier nicht zu sehr treiben lassen. Tut man das, verlässt man den direkten Weg zu seinem Ziel. Das hat natürlich Implikationen auf den Zeitpunkt der Fertigstellung, den Umfang des Produktes usw.

Gerade hinsichtlich des Produktumfanges können flankierende Aufgaben Änderungen erfahren. Man denke hier an die Vorbereitung zu Marketing-Maßnahmen. Auch diese müssten sich ändern, sollte es zu größeren Änderungen aufgrund von berücksichtigten Kundenwünschen kommen. Das kann gewollt sein, wenn eine Idee so gut ist, dass sie unmöglich ignoriert werden kann. Meist sind die Änderungswünsche jedoch nicht strategischer Natur.

Man muss sich und dem Kunden vor Augen halten, dass ein “Standard-Produkt” nicht alle Wünsche aller Kunden berücksichtigen kann. Dafür ist es preislich wesentlich günstiger zu haben und deckt schon viele der Grundanforderungen ab.

Kundenspezifische Anpassungen vermeiden

Kundenspezifische Anpassungen werden gerne als zusätzliche Leistung angeboten. So hat man ein Standard-Produkt das für viele potentielle Kunden verfügbar ist. Auf Wunsch (und mit entsprechender Gegenleistung) bekommt der Kunde zusätzliche Funktionen oder aber Erweiterungen bestehender Möglichkeiten.

Das klingt gut, immerhin kann man sich so eventuell die Produktentwicklung (die zugegeben teuer ist) (mit)finanzieren lassen.

Dieses Vorgehen hat allerdings auch ein paar Nachteile:

  • Damit das Produkt für Kunden angepasst werden können, müssen Konfigurationsmöglichkeiten geschaffen werden wo vorher keine notwendig waren.
  • Sollen bestehende Funktionen für Kunden erweitert/verändert werden, müssen auch hier Mechanismen vorgesehen werden, damit ein austauschbares Eingreifen möglich ist. Das erhöht die Komplexität, Fehleranfälligkeit und Wartbarkeit der Anwendung.
  • Die Produktentwicklung steht natürlich nicht still und so kann es zu Veränderungen an den bestehenden Mechanismen geben. Diese Änderungen sind bei allen Kundenerweiterungen nachzuziehen. Wird dies hinausgezögert, wird irgendwann der anstehende Aufwand nicht mehr akzeptiert. Das Resultat ist die Verwaltung und Pflege von unterschiedlichen Versionen (meist Major-Versionen mit eigenen Änderungen/Erweiterungen).
  • Diese unterschiedlichen Konfigurationen und Erweiterungen stellen zusätzliche Anforderungen an das Configuration-/Release-Management und das Thema des Deployments im Allgemeinen.

Bereits diese wenigen Punkte lassen erahnen, was hier auf das Projektteam an zusätzlichen Aufwand zukommt. Die Schaffung eines eigenen Teams für die Erfüllung von Kundenträumen resultiert in erhöhtem Abstimmungsaufwand, Support, Diskussionen an welcher Stelle Umsetzungen stattzufinden haben. Allen voran stehen Kundenprojekte zudem meist unter Zeitdruck. Da eine Kundenanforderung gerne auch eine Verallgemeinerung an der Basis des Produktes verursacht, wird dieser Zeitdruck über mehrere Teams verteilt und Zeitpläne auch einmal massiv durcheinander gewürfelt.

Fixe Rahmenbedingungen für die Produktentwicklung

Alles ändert sich, laufend. So ist das in der Softwareentwicklung und dem sollte (muss) auch Rechnung getragen werden. In der Produktentwicklung bedarf es jedoch einiger fixen Säulen. Diese sind anfangs klar zu definieren und an ihnen sollten alle Vorgänge gemessen werden.

Dabei geht es zumindest um das zu lösende Problem und das gewählte Geschäftsmodell. Änderungen an einer dieser beiden Säulen hat massive Auswirkungen auf das gesamte Produkt plus Anhang.

Den eigenen Weg finden

Man kennt es: Da sieht man hier etwas, dann dort. Überall Informationen, Konzepte und Pläne, die auch das eigene Produkt bereichern würden. Dies ist vor allem dann ausgeprägt, wenn sich potentielle Konkurrenten am Zielmarkt tummeln. Das ist wunderbar und kann eigene Ideen ungemein bereichern, jedoch sollte man sich nicht davon vorrangig treiben lassen. Meist ist der eigene Produkt-Ansatz ein anderer und somit können unterschiedliche Ideen oft gar nicht so einfach kombiniert werden bzw. muss die Sinnhaftigkeit in Frage gestellt werden.

Das eigene Produkt muss eine eigene Persönlichkeit bekommen und dies auch vermitteln. Werden Eigenheiten anderer Produkte angenommen, ist dies nicht mehr möglich. Das eigene Produkt erscheint als Flickwerk. Das gilt es unbedingt zu vermeiden.

Daher Ideen/Umsetzungen der Konkurrenz beobachten und durchaus einmal längere Zeit “sitzen” lassen. Erstens muss man nicht alles haben, was die Konkurrenz hat und zweitens kann man das mit ein wenig Abstand und weniger eigenen Druck sicherlich besser machen.

Fazit

Wer ein Produkt für die Masse entwickelt, weiß wie schwierig diese Aufgabe ist. Vor allem, wenn das Unternehmen klein ist und Kundenanfragen nur sehr ungern abgelehnt werden. Nichts desto trotz muss man sich für eine Richtung entscheiden. Ein erfolgreiches Produkt zu schnüren und gleichzeitig den Kunden alle Wünsche zu erfüllen wird nicht möglich sein.

Link-o-licious #7

Interessante Web-Ressourcen habe ich wieder gefunden. Links zu den Themen Web, Go und Produktivität finden sich hier. Ebenfalls etwas zum Nachdenken.

Web

Go

Produktivität

Zum Nachdenken

JSON-Datei mit Go einlesen

Das JSON-Format wird ganz gerne verwendet, um Daten oder Einstellungen zu übertragen bzw. zu speichern. Daher stellt sich häufig die Anforderung, JSON-Dateien einzulesen. Dieser Kurzbeitrag zeigt den notwendigen Sourcecode zum Einlesen von JSON-Dateien und dem Mapping auf einen Go Typen.

Gegeben ist eine JSON-Datei mit Einstellungen für eine Anwendung:

{
    "connectionString": "der connection string im detail"
}

Zur Abbildung der Daten im JSON-Format wird ein Type namens Settings erstellt. Dabei ist zu beachten, dass ein JSON-Mapping angegeben werden kann.

type Settings struct {
    DbConnectionString string `json:"connectionString"`
}

Für das Einlesen der Datei wird das Package os benötigt. Für das Serialisieren der JSON-Daten das Package json. Der Vorgang wird in der Funktion ReadSettings durchgeführt, wie nachfolgend zu sehen:

package samplelib

import (
    "encoding/json"
    "os"
)

type Settings struct {
    DbConnectionString string `json:"connectionString"`
}

func ReadSettings(fileName string)  (settings *Settings, err error) {
    file, _ := os.Open(fileName)
    settings = new(Settings)
    err = json.NewDecoder(file).Decode(settings)
    return
}

Nach einem Import kann dies wie folgt aufgerufen werden:

var settings, err = samplelib.ReadSettings("settings.json")

if err != nil {
    fmt.Println("Error while reading configuration:", err.Error)
} else {
    fmt.Println("connection-string:" + settings.DbConnectionString)
}

Für weitere, tiefergehendere Informationen kann ich JSON and Go – The Go Blog empfehlen.

Link-o-licious #6

Ich habe wieder einige interessante Links, die ich mit euch teilen möchte. Dieses Mal dreht sich sehr viel um das Thema Go, da ich mich aktuell vermehrt damit beschäftige und den einen oder anderen Test damit mache.

Allgemein

Erfolgreich in der Unvorhersagbarkeit, oder: Softwareglück ohne Schätzungen

Web

Initiative “Schöneres Backend”: 20 kostenlose Dashboard UI Mockups

Go

Vor einigen Monaten habe ich vorsichtig begonnen mich mit Go zu beschäftigen. Dieses Engagement wird nun immer intensiver, wodurch sich in meinen Bookmarks nun auch vermehrt Links auf Go-Inhalte finden..

The Go Programming Language Specification
Common Mistakes Made with Golang, and Resources to Learn From
Build a RESTful API in Go – Video
Build a RESTful API with Martini
An Introduction to Programming in Go

.NET

Combining Modifiers in C#: “protected internal” and “override sealed”
Visual Studio 14 CTP 2 verfügbar

Link-o-licious #5

Speziell für AngularJS habe ich zahlreiche Links zu teilen:

Allegemein der Webentwicklung und JavaScript zuzuordnen sind nachfolgende interessante Beiträge:

  • reveal.js – A framework for easily creating beautiful presentations using HTML, Markdown
  • BreezeJS – Manage data in rich client applications

Nachfolgende Links könnten für .NET-Entwickler von Interesse sein:

Wer Brackets einsetzt, der sollte einen Blick auf die Brackets shortcuts werfen.

Und schlussendlich bin ich noch auf einige interessant klingende Bücher gestoßen, die ich nicht verheimlichen möchte:

Daily Scrum richtig einsetzen

Ein wichtiger Bestandteil von Scrum ist das sogenannte Daily Scrum Meeting, oder kurz auch gerne Daily genannt. Dies ist – meiner bescheidenen Meinung nach – wohl der Scrum-Bestandteil der vorwiegend in die Hose geht und als Klotz am Bein angesehen wird. Schade eigentlich, kann das Daily doch einen richtigen Boost bringen. Wie? Weiterlesen!

Ursprüngliche Definition

Das Daily Scrum Meeting ist – wie der Name so schön sagt – ein tägliches Meeting. Es soll die Dauer von 15 Minuten nicht überschreiten. Für gewöhnlich steht das gesamte Team im Kreis (keine Gegenstände sollen zwischen den Mitgliedern stehen) und beantwortet nach und nach die folgenden drei Fragen:

  • Was habe ich seit dem letzten Daily Scrum getan?
  • Was plane ich, bis zum nächsten Daily Scrum zu tun?
  • Was hat mich bei der Arbeit behindert (Impediments)?

Der Scrum Master ist dabei und erfasst die Impediments und triggert ein Lösen derselben an. Sehr positiv empfinde ich es zudem, wenn sich der Product Owner die Zeit zur Teilnahme am Daily Scrum Meeting nimmt, auch wenn er nur eine passive Rolle einzunehmen hat.

Probleme des Daily Scrum Meetings

Entsprechend meiner Erfahrung drehen sich 90% dieses Meetings um das am Vortag Erreichte. Jeder erzählt der Reihe nach auf, was er erreicht hat, ergänzt dies teilweise bereits mit Informationen, was hier noch offen ist und getan werden muss. Dies verschlingt eben sehr viel Zeit.

In den verbleibenden 10% werden anstehende Aufgaben und Impediments behandelt. Da die 15 Minuten aber eingehalten werden wollen (sonst ist es ja nicht Scrum-konform) verbleibt nur ein Bruchteil für die eigentliche Planung und das Erwähnen von wirklichen Problemen.

Das Endergebnis daraus ist, dass zwar jeder weiß, was gestern umgesetzt wurde, jedoch kaum jemand, was heute ansteht. In meinen Augen kann das nicht das gewünschte Ergebnis sein.

Wie besser machen?

Man muss sich die Frage stellen, welchen Output ein Daily Scrum Meeting liefern soll. Für mich hat das Meeting den Charakter einer Einsatzplanung. Ich möchte eigentlich nicht wissen, was jeder gestern gemacht hat, sondern was das gesamte Team an diesem Tag erreichen möchte und wodurch das Team daran gehindert wird.

Das Daily Scrum Meeting muss das Ziel des Teams festlegen, nicht das Ziel der einzelnen Mitglieder.

Was also jeder innerhalb der vergangenen 24 Stunden gemacht hat, sollte durch eine gute Team-Kommunikation ohnehin bekannt sein. Zudem stellt sich die Frage auch gar nicht, wenn es einen gemeinsamen Plan gibt. Und genau dies ist des Rätsels Lösung.

Sicherlich muss jeder Tasks erfüllen. Es gilt jedoch fest zu legen, was das Team als Ganzes an diesem Tag erreichen möchte. Man möge sich hier also ruhig an alte Filme über Seeschlachten oder ähnlichem erinnert fühlen, aber genau darauf läuft es hinaus. Zusammensetzen und definieren, was das gemeinschaftliche Ziel für diesen Tag sein soll. Was soll am Ende des Tages (oder zum nächsten Daily) funktionieren?

Auf Basis dieser Erkenntnis werden anschließend Aufgaben verteilt bzw. definiert wer was genau zu tun hat. Oberstes Ziel ist aber das gemeinsam definierte. Darauf sollte jeder hinarbeiten.

Was ist anders?

Die Änderung zur Lehrbuch-Methode ist, dass es keinen Fokus auf die oben genannten drei Fragen gibt. Es gibt eine richtige Einsatzplanung mit einer Definition was erreicht werden soll. Für dieses gemeinsame Ziel stehen alle ein, unabhängig davon, was ein Einzelner zu leisten hat.

Das ist nicht nur für das Gefühl oder das Gemüt gut, sondern bringt auch der tatächlichen Performance etwas. Und nicht nur dem. Es steigt die Kommunikation, alleine schon da der Bedarf höher ist, schließlich müssen Team-Mitglieder unterstützt werden, um das Tagesziel erreichen zu können.

Vorteilhaft ist, dass sich dadurch die erste Frage dieser drei Fragen erübrigt.

Im darauffolgenden Daily kann überprüft werden, ob das gestellte Team-Ziel erreicht wurde. Wenn ja, dann ist alles in Ordnung, andernfalls muss hinterfragt werden, warum dies nicht geschehen ist und was noch zu tun ist (neue Tasks entstehen etc.). Dies gibt ein gänzlich neues Gefühl des Fortschrittes, unabhängig der User Stories bzw. des Burndown Charts.

Fazit

Die ursprünglich definierten drei Fragen des Daily Scrum Meetings sind durchaus gut gemeint und es ist sinnvoll sich als Team jeden Tag zusammen zu stellen und über das aktuelle Projekt zu reden. Für meinen Teil sollte dies aber eine Einsatzbesprechung sein, in der vielmehr die Aufgaben für die kommenden 24 Stunden festgelegt werden sollten, als eine Retrospektive der vergangenen 24 Stunden. Die Zukunft ist wichtiger als die Vergangenheit und dies muss berücksichtigt werden. Wer daran denkt holt wesentlich mehr aus diesem Meeting heraus.

Link-o-licious #4

Kürzlich veröffentlichte Beiträge hier auf meinem Blog:

Interessantes aus der Welt der Webentwicklung:

Auch die .NET Community darf nicht fehlen:

Neue und/oder bessere Werkzeuge kann man auch immer brauchen:

AngularJS Links und Videos

Bedingt durch ein laufendes Projekt beschäftige ich mich aktuell (und das wird auch noch länger sein) mit AngularJS. Da ich hier noch in meinen Anfängen stecke, interessiert mich jeder gute Beitrag, der mir weiterhelfen kann. Diese wiederrum möchte ich mich meinen Lesern teilen. Here we go …

Allgemeine Ressourcen

Artikel und Posts

Videos

Gerne möchte ich auch auf ein paar Videos hinweisen, die mir sehr weitergeholfen haben. Sehr empfehlenswert sind auch die Videos der ng-conf 2014.

Hierzu meine AngularJS YouTube Playlist, die ich auch ständig erweitern werde:

Tools

Über Tipps, weitere hilfreiche Videos, Artikel und mehr freue ich mich natürlich jederzeit und hoffe auf einen entsprechenden Kommentar mit Hinweis.

© 2014 Norbert Eder

Theme by Anders NorenUp ↑