9. Oktober 2015
Katrin Hammer
0

BASTA! – von Elefanten und Hamburgern

Letzte Woche fand die BASTA! 2015 in Mainz statt. Die Saxonia Systems AG war Gold Partner und mit 3 Vorträgen unserer Kollegen vertreten. Es reichte von Softwareevolution über „Was ist eigentlich Unit“ bis hin zu den Qualitätsmetriken. Speaker waren hier Hendrik Lösch, Kay Greybenstein und Martin Uhlig.

Ein Manko gab es: Die App zur Konferenz gab es nicht für das Windows Phone, obwohl die BASTA! selbst als „die führende unabhängige Konferenz für Microsoft-Technologien“ wirbt. Vielleicht beim nächsten Mal…

Da zur Zeit alles agil ist, gab es auch auf der BASTA! Vorträge zu agilen Themen.

Agil ist teuer?

„Agil ist teuer“. Dieser Meinung ist Christoph Seck mit seinem Vortrag „Agil und Festpreis, Mesalliance oder Dream-Team?“ Er veranschaulichte ein Festpreisprojekt an einem Data-Warehouse-System. Fester Preis und feste Leistung gehören dabei zusammen.

Im Gegensatz zu klassischen Wasserfall-Projekten, die eher einer Konstruktion mit einer großen Planungsphase gleichen, stellen agile Projekte eher eine Produktion dar, bei der Stück für Stück ein Teil der Software entwickelt wird. Bei klassischen Projekten wird versucht, das globale Optimum zu entwickeln, bei der agilen Entwicklung muss man kleiner denken, und sich auf das lokale Optimum beschränken. Was ist für den jeweiligen Teil die optimale Lösung? Dabei spielen Kompetenz und Konvergenz eine wichtige Rolle. Man hat in agilen Projekten nicht die Zeit, sich über einen langen Zeitraum hin Wissen anzueignen. Die Mitarbeiter müssen sowohl fachlich als auch technisch kompetent sein, um schnell ein (Teil-)Produkt entwickeln zu können. Auch die Zusammenarbeit mit dem Kunden spielt eine wichtige Rolle. Sie beschränkt sich nicht – wie bei klassischen Projekten – auf reine Kommunikation, sondern bedarf echter Zusammenarbeit im gesamten Prozess. Konvergenz bedeutet aber nicht nur die Zusammenarbeit zwischen den Beteiligten, sondern auch die Produktkonvergenz. Am Ende muss doch wieder ein großes Ganzes entstehen. Deshalb spielt auch die Architektur bei agilen Projekten eine wichtige Rolle. (Dieses Thema wurde in einem anderen Vortrag vertieft, siehe nächster Abschnitt).

Die feste Leistung wird definiert durch die Abnahmekriterien. Diese lassen sich gut über Tests abbilden, die der Kunde vorgibt. Der Kunde muss in einem agilen Projekt mehr mitarbeiten. Wichtig ist auch die faire Risikoverteilung. Als Kernrisiken gelten die Anforderungen und die Datenquellen. Der Kunde ist verantwortlich für die Qualität der Quelldaten und deren Struktur, und trägt damit auch einen Teil des Risikos.

Agil ist also zunächst vor allem teuer, weil es ein Umdenken im Prozess erfordert. Ist der agile Softwareentwicklungsprozess sowohl beim Auftragnehmer als auch beim Kunden etabliert, können beide davon profitieren und schneller zu einer besseren Lösung kommen.

Agile Architekturen

Agile Softwareentwicklung stellt auch den Architekten vor neue Herausforderungen. Diesem Thema widmete sich Urs Enzler in seinem Vortrag über „Agile Architektur“. Die Architektur muss Veränderungen vertragen können und mit der Zeit mitwachsen und sich verändern können. Das sind eigentlich Attribute, die man klassischerweise einer Architektur nicht zuordnen würde, sie sollte stabil und langlebend sein, und nicht flexibel und veränderbar.

Um auf Veränderungen vorbereitet zu sein, sollten alle Parteien von Anfang an die gleiche Vision haben. Denn nur wenn allen das eigentliche Ziel klar ist, kann der entsprechende Weg eingeschlagen werden. Dazu ist es sinnvoll, zu Beginn einen Requirements Workshop durchzuführen, bei dem sowohl funktionale als auch nichtfunktionale Anforderungen identifiziert werden können. Diese bilden dann das initiale Backlog und ergeben den Qualitätsbaum und Qualitätsszenarien. Danach lässt sich das große Ganze in Teile (Bounded Contexts) zerlegen, entweder anhand der Qualitätsattribute (wie Performance, Verfügbarkeit, …) oder nach Verantwortlichkeiten (für verschiedene Aufgaben oder Nutzer). Wichtig ist dabei auch die Kommunikation zwischen diesen Kontexten, also welche Daten sollen wie ausgetauscht werden. Wenn die verschiedenen Kontexte einer Anwendung einmal grob definiert wurden, kann man sich auf die eigentliche Entwicklung dieser Teile konzentrieren. Die Entwicklung kann nach und nach erfolgen, man kann mit einem Kontext anfangen, oder auf mehrere Teams parallelisieren.

Innerhalb eines Kontexts können nun die Komponenten identifiziert werden. Da es zu Beginn eines jeden Projektes jede Menge Unsicherheiten gibt, ist es wichtig, dass man Entscheidungen auch über die Zeit vertagen kann. Es muss nicht alles zu Beginn festgelegt werden. Man kann gar nicht alles am Anfang bestimmen. Sonst wäre es ein Wasserfallprojekt mit einer klassischen Analyse-Phase. Es gibt mehrere Möglichkeiten, wie man (Entwurfs-)Entscheidungen auf später verschieben kann. Dazu gehören die Abstraktion, das bewusste Ignorieren von Anforderungen, die Vereinfachung oder auch das Delegieren von Entscheidungen an andere Personen oder Komponenten. Es ist zum Beispiel möglich, die Geschäftslogik zunächst unabhängig von der Oberfläche zu entwickeln. Wenn dann der Designer oder eine andere Person die Oberfläche gestaltet hat, kann diese mit der Geschäftslogik verbunden werden. Es ist auch möglich die Datenhaltung zunächst komplett zu abstrahieren, und nur in eine Textdatei zu schreiben. Das wäre dann eine Kombination aus Abstraktion und Vereinfachung.

Über die Zeit wächst das Wissen über das Projekt und es ist möglich, die notwendigen Entscheidungen zu treffen und somit die Anwendung zu verfeinern und zu optimieren. Ziel ist es aber zu jedem Zeitpunkt ein lauffähiges Produkt zu haben. Continuous Integration und Deployment spielen dabei eine wichtige Rolle. Nach und nach werden Abstraktionen und Vereinfachungen durch die „richtigen“ Komponenten ersetzt. Test Driven Development ist hier ebenfalls hilfreich, um sicherzustellen, dass auch weiterhin alles wie gefordert funktioniert. Da sich sowohl Anforderungen als auch Technologien über die Zeit ändern, muss sich somit auch die Architektur anpassen. Dies sollte regelmäßig in einem Architekturworkshop geprüft werden. Entspricht die Architektur noch den Anforderungen, insbesondere den Qualitätsattributen? In einem agilen Projekt ist also auch die Architektur agil, sie wächst und verändert sich mit der Zeit. Und auf dem Weg zum Ziel sollte dies immer wieder überprüft werden.

Neben der agilen Softwareentwicklung waren für uns als WPF-Entwickler vor allem UI-Themen interessant, mit dem Schwerpunkt Windows 10. Hier ein kurzer Überblick.

Responsive UI

Ein weiteres großes Thema war das Responsive Design. Das Design einer Oberfläche sollte sich an die entsprechenden Geräte und Auflösungen anpassen können. Ziel ist es, eine Oberfläche nur einmal zu entwerfen, und sie so zu gestalten, dass sie auf den verschiedensten Geräten läuft, und gut aussieht. Dazu gehört z.B. dass Elemente ausgeblendet oder verschoben werden, Text auf eine oder mehrere Spalten aufgeteilt wird, je nachdem, wie viel Platz vorhanden ist. Einen guten Überblick bietet Microsoft unter https://msdn.microsoft.com/en-us/library/windows/apps/dn958435.aspx

IoT – Das Internet der Dinge

Windows 10 Apps kann man auch auf einem Raspberry Pi 2 laufen lassen, und damit die tollsten Dinge entwickeln. Einfach die Anwendung im Visual Studio entwickeln, den Raspberry Pi 2 anschließen, F5 drücken und schon läuft die App! (Wahrscheinlich) Mit den entsprechenden Sensoren, lässt sich so zum Beispiel die Heimautomatisierung Marke Eigenbau umsetzen. Na, schon neugierig? Unter https://dev.windows.com/de-de/iot findet man Starter-Packs und detaillierte Anleitungen.

Mehr Platz für Inhalte, weniger Chrome

Der Vortrag von Jörg Neumann „Touch-ready UI: Apps für Touch optimieren“ brachte interessante Information zum Thema UI in Bezug auf Touch hervor – getreu dem Motto „weniger ist mehr“. Weniger Chrome sollte es sein. Chrome ist nicht nur ein Browser, sondern als Chrome wird auch der Teil der GUI bezeichnet, der nicht zum Inhalt gehört, sondern Elemente darstellt, mit denen Kommandos ausgeführt werden können. Die View sollte auf das Wesentliche begrenzt sein – keine fette RibbonBar und kein breiter TreeView zum Durchhangeln durch die Daten. Der größte View-Bereich gehört den Daten, die der Nutzer zu bearbeiten hat.

Er gab außerdem interessante Ansätze so manches Control aus einer anderen Sichtweise zu sehen und es – entgegen des gewohnten Ablaufs – in ein touch-fähiges Control zu verwandeln. Auch die Datenreduktion war dabei ein Thema. Der Daten-Bereich sollte auf das Wesentliche begrenzt sein und zusätzliche Information je nach Bedarf einblenden.

Mit diesen guten Vorsätzen sind wir gleich in das nächste Kundenprojekt gestartet, und wurden sofort wieder auf den Boden der Tatsachen zurückgeholt, weil der Kunde doch wieder alles auf einen Blick haben – Zahlen, Daten, Fakten… Für ein modernes UI ist also auch ein Umdenken beim Anwender erforderlich. Nicht jeder mag Veränderungen…

Die Beispiele von der BASTA dazu findet man hier: http://headwriteline.blogspot.de/

Das Hamburger Icon

Windows 10 kommt mit einer neuen Schriftart: Segoe MDL2 (Microsoft Design Language). Diese Schriftart enthält viele Symbole, die als Icons für Oberflächen verwendet werden können. Für jedes Symbol gibt es einen Unicode. Da sich Unicodes schlecht merken lassen, findet man unter http://modernicons.io/segoe-mdl2/cheatsheet/ eine Übersicht aller Symbole. Der entsprechende Unicode kann dann zum Beispiel einfach als Text in einem Textblock zugewiesen werden.

<TextBlock Text="&#xE700;" FontFamily="Segoe MDL2 Assets" />

In dieser Schriftart findet sich auch ein ganz besonderes Icon – das Hamburger Icon.

hamburgericonVielen wird dieses Symbol bereits bekannt sein, vor allem aus Apps. Es symbolisiert ein Flyout-Menu. Mir war neu, dass das Ding einen Namen hat, nämlich Hamburger-Icon – weil es ein bisschen aussieht wie ein Hamburger…

Ich wiege 0,01 Elefanten

elefantenWindows 10 bietet noch ein weiteres nettes Feature. Wer immer schon mal wissen wollte, wie schwer man im Vergleich zu Elefanten ist, kann einfach den Taschenrechner öffnen und auf die Umrechnung für Gewicht und Masse umschalten.

fußballfelderDas funktioniert auch mit anderen Umrechnungen. Und schon kann man mithalten bei Dokumentationen und sagen: „mein Grundstück ist so groß wie 10 Fußballfelder“… Na gut, nicht wirklich…

Fazit

Die Sonne hat geschienen, das Essen war gut und es war für jeden etwas dabei, für Web-Entwickler allerdings mehr als für WPF-Entwickler. Dafür dass es eine Konferenz über Microsoft-Technologien war, wirkte der Microsoft-Stand winzig. Da war sogar unser Saxonia-Stand größer und besser besucht. Viele haben sich auch für das eteoBoard interessiert. (http://www.eteoboard.de) Die diversen Give-Aways der Aussteller reichten von Beuteln, T-Shirts, Lippenpflege (bei einer Frauenquote von unter 10%), bis zu Debuggern[Fliegenklatsche]. Bei Saxonia gab es wieder Kern-Energie. Die besondere Challenge für unseren Kay war es, dieses Wortspiel auf Englisch einer indischen Delegation zu erklären. Ob sie sich getraut haben die Nussmischung zu essen, nachdem ihnen etwas von nuclear energy erzählt wurde, wir wissen es nicht… 🙂

Katrin Hammer ist Entwickler und Architekt bei der Saxonia Systems AG in Dresden. Sie entwickelt und entwirft seit über 10 Jahren .NET-basierte Lösungen, mit dem Schwerpunkt WPF und Prism. Sie erreichen sie über katrin.hammer@saxsys.de.

LinkedIn Xing 

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0