Agile Arbeitsweisen

Im Februar 2001 entwickelt eine Gruppe um Kent Beck, Mike Beedle, Martin Fowler, Ken Schwaber und Jeff Sutherland das „Agile Manifest“ um neue Arten des Projektmanagements, nach denen sie arbeiten, zu beschreiben.

Das agile Manifest lautet wie folgt:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und ihre Interaktionen stehen über Prozessen und Werkzeugen.

Funktionierende Software steht über einer umfassenden Dokumentation.

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung.

Reagieren auf Veränderung steht über dem Befolgen eines Plans.

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Die später im Jahr gegründete Agile Alliance leitet daraus die 12 agilen Prinzipien ab.

Im Fokus agiler Arbeitsweisen stehen Kundenzentriertheit, Veränderungbereitschaft in Bezug auf Projektinhalt und Arbeitsweise und hochgradig eigenverantwortliche Teams. Die Aufgabe des Managements besteht in der Unterstützung beim Finden von Lösungen und dem Bereitstellen der benötigten Mittel, nicht in der Zuweisung von Aufgaben. Die unterschiedlichen agilen Vorgehensweisen sind Frameworks, an denen sich das Team orientiert um seine eigene, auf Projekt und Team angepasste Methode zu entwickeln.

Die adaptive agile Vorgehensweise ist gut geeignet für Projekte mit vielen für den Kunden sichtbaren Schnittstellen und einfacher Hintergrundverarbeitung, oder bei komplexen Problemen, bei denen viel unvorhergesehenes passieren kann. Die starren, von Beginn an durchgeplanten klassischen Projektvorgehensweisen eignen sich dagegen gut für Projekte mit einem komplizierten Rechenkern oder einer nicht in Einzellieferungen aufteilbaren Funktionalität.

Die bekanntesten agilen Frameworks sind

• Scrum als Framework für das allgemeine Projektmanagement, insbesondere die Software-entwicklung
• Kanban (als eine Technik der Lean Methoden) mit dem Schwerpunkt der Visualisierung im Kanban Board und der Optimierung des Workflowmanagements zur Sicherstellung eines kontinuierlichen Arbeitsflusses durch Limitierung der Work in Progress (WIP)
• Extreme Programming (XP), das als einziges agiles Framework auch konkrete Methoden zur Softwareentwicklung vorgibt, wie Pair Programming durch die gemeinsame Arbeit von zwei Entwicklern an einem Computer oder das Test-First Programming, bei dem zuerst der automatisierte Test für die gewünschte Funktionalität geschrieben wird.

Und eingeschränkt auch 

• DevOps mit der Zusammenbringung von Entwicklung und Betrieb und der Automatisierung des Workflows von der Entwicklung bis zum Kunden
• Design Thinking als nutzerorientierter Innovationsansatz für komplexe Probleme und Herausforderungen.

Allen Frameworks gemeinsam sind die Konzepte der 

User Stories als eine einfache Beschreibung einer Produktanforderung hinsichtlich dessen, was diese Anforderung für wen erreichen soll. Komplexere Anforderungen werden Epics genannt. Sie werden im Projektverlauf in Features und diese dann in User Stories heruntergebrochen. 

Daily Meeting: ein kurzes tägliches Team-Event, bei dem jeder beschreibt, was sein aktueller Status ist. 

Inkrementelle Entwicklung: Entwicklung kleiner potenziell einsetzbarer Softwareteile mit für den Kunden sichtbaren Funktionen. 

Iterative Entwicklung: wiederholende Arbeiten am selben Objekt, durch Prototyping, Refactoring oder inkrementelle Weiterentwicklung. 

Team: ein kleines, eigenverantwortliches Team, das ausschließlich diesem Projekt zugeordnet ist. 

Retrospektive: regelmäßige Überprüfung und Anpassung der Methodik durch das ganze Team mit dem Ziel der stetigen Verbesserung. 

Personas: Falls im Projekt erforderlich, werden fiktive Nutzer mit eigenen Biographien und individuellen Eigenschaften kreiert um Nutzergruppen darzustellen.

Scrum ist das bekannteste und am weitesten verbreitete agile Framework. Es besteht aus 3 gleichberechtigten Rollen, 3 Artefakten und 5 Aktivitäten.

Der Product Owner repräsentiert die geschäftlichen Interessen des Projekts. Er verwaltet das Product Backlog und nimmt fertiggestellte Arbeit ab. Das Entwicklungsteam ist selbstorganisierend, nur einem Projekt zugeordnet und idealerweise an einem Standort angesiedelt. Der Scrum Master unterstützt das Team bei der Verbesserung des Arbeitsumfeldes.

Im Product Backlog wird die vollständige Liste der Anforderungen gepflegt, aus denen für den jeweiligen Sprint eine Auswahl für das Sprint Backlog getroffen wird. Das Produktinkrement ist dann die einsatzfähige, potenziell auslieferfähige Funktionalität.

Zu Beginn der Sprint genannten, maximal monatlichen Entwicklungszyklen werden im Sprint Planning die Ziele für diesen Zyklus definiert. Während des täglichen 15-minütigen Daily Scrums berichtet jeder über seinen aktuellen Status. Im Sprint Review wird das fertige Produktinkrement den Stakeholdern vorgeführt, während in der Sprint Retrospektive das Scrum Team mögliche Prozessverbesserungen bespricht.

Zu Beginn eines agilen Projektes definiert der Product Owner in einem Product Vision Statement das Ziel des Projektes. In der Definition of Done legt das Scrum Team fest, wann etwas als fertig und potenziell auslieferbar angesehen wird. Der Aufwand für User Stories wird vom Scrum Team in (willkürlich festgelegten) Story Points gemessen. Die durchschnittliche Anzahl an Story Points, die das Team in einem Sprint umsetzt, ist die Velocity des Teams. Im Burndown Diagramm werden die geschätzten Story Points für einen Sprint eingetragen und die für fertiggestellte Arbeiten geschätzten Story Points entfernt um so den Fortschritt zu visualisieren.

Um in größeren Projekten agil zu arbeiten müssen die agilen Methoden so skaliert werden, dass Veränderungsbereitschaft und direkte, schnelle Kommunikation erhalten bleiben. Dafür gibt es unterschiedliche Frameworks, wie Scrum of Scrums, Scrum at Scale, Large Scale Scrum (LeSS), Nexus, Scaled Agile Framework (SAFe) oder Enterprise Scrum (ES) oder auch das Spotify Modell.

Auch bei der Skalierung entwickeln Organisationen aus den verschiedenen Frameworks meist ihre eigene Skalierungsmethode.

PDF-Download ausführliches Dokument 

Blockchain

Unter dem Pseudonym Satoshi Nakamoto wurde 2008 ein Whitepaper zur Blockchain veröffentlicht. 2009 wurde der Code für Bitcoin veröffentlicht.

 

Grundlegende Idee ist die sichere Weitergabe von Werten (in Form von Informationen) in einem Umfeld ohne vertrauensstiftende Intermediäre. Dabei werden die einzelnen Transaktionen digital signiert und fälschungssicher zu aufeinander folgenden Blöcken gebündelt. Durch ein implizites Konsens-Verfahren wird jeder Block der Blockchain vom dezentralen Netzwerk bestätigt. Das Netzwerk besteht aus sogenannten full nodes und Minern, die üblicherweise auch full nodes sind. Jeder full node erstellt gemäß den vorgegebenen Regeln seine eigene Blockchain auf Basis der von den Minern erstellten Blöcke.

 

Ein kryptografischer Hash ist ein digitaler Fingerabdruck einer Information, der eindeutig, leicht zu berechnen, aber in sinnvoller Zeit nicht umkehrbar ist.

 

Jede Transaktion in Bitcoin enthält Metadaten, wie den Hash der Transaktion als Referenz und die mit dem public/private Key-Verfahren erstellte digitale Signatur, sowie ein Array aus Inputs und ein Array aus Outputs. Die Summe der Inputs muss kleiner oder gleich der Summe der Outputs sein. Differenzen gehen als Transaktionsgebühr an den Miner, der diese Transaktion in einem Block veröffentlicht. Der public key (bzw. sein Hash) ist gleichzeitig die Adresse des Teilnehmers.

 

In einem Block werden die Transaktionen in der Struktur eines Merkle-Baums abgelegt. Dabei sind die Transaktionen die Blätter des Baumes, die paarweise über Hashs soweit zusammengefasst werden, dass ein Hash die fälschungssichere Wurzel des Baumes bildet. Der Header eines Blockes enthält neben dieser Wurzel u.a. einen Hashzeiger zum Header des Vorgängerblocks, wodurch die Blockchain gebildet wird. Außerdem enthält er die Lösung „nonce“ des Mining-Puzzles.

Neue Blöcke werden von Minern gebildet, die damit die Buchhaltung der Blockchain vornehmen. Sie sichern mit ihrer Arbeit die fälschungssichere Verknüpfung der Blöcke in der Blockchain. Im Proof-of-work ist ein Mining Puzzle zu lösen, das vom Netzwerk leicht verifiziert werden kann, aber nur durch Ausprobieren zu lösen ist. Der Miner muss den Wert „nonce“ (von „number used once“) finden, der in Verbindung mit anderen spezifischen Daten des Blocks und dem Hash des Vorgängerblocks einen Hash kleiner einem gewissen Zielwert ergibt. Jede nachträgliche Veränderung innerhalb eines Blocks erfordert dadurch die Neukalkulation dieses Blocks und aller darauf folgenden Blöcke um wieder eine korrekte Blockchain zu erhalten.

 

Der Zielwert des Mining Puzzles wird in regelmäßigen Abständen (alle 2.016 Blöcke, ca. 2 Wochen) vom Gesamt-Netzwerk angepasst, um eine durchschnittliche Zeit von 10 Minuten für die Bildung eines neuen Blockes zu gewährleisten und auf Veränderungen im Netzwerk und Hardware-Entwicklungen reagieren zu können. Da das Mining-Puzzle nur durch Ausprobieren gelöst werden kann, ist die Wahrscheinlichkeit, einen neuen Block zu erstellen, abhängig vom Anteil an der Rechenkapazität des Netzwerks und eine beherrschende Stellung wird unverhältnismäßig teuer.

 

Damit Miner diesen Aufwand treiben, enthält jeder Block als erste Transaktion die coinbase-Transaktion, die dem Miner einen bestimmten Betrag an Bitcoin (zu Beginn 50 Bitcoin) überträgt. Der Betrag halbiert sich alle 210.000 Blöcke (ca. 4 Jahre), bis in 2140 die maximale Zahl von 21 Millionen Bitcoin erreicht ist.

 

Andere Kryptowährungen verwenden teilweise andere Mining Puzzles, wie proof-of-stake (Anteilsbezogen) oder proof-of-Authority (ausgewählte vertrauensvolle Knoten bilden den nächsten Block).

 

Die Korrektheit der Blockchain wird durch einen impliziten Konsens sichergestellt:

Jeder Knoten speichert alle Transaktionen und seine Sicht der Blockchain. Bei der Verteilung eines neuen Blockes wird geprüft, ob alle Transaktionen innerhalb des Blockes valide sind und das Mining-Puzzle korrekt gelöst ist. Valide Transaktionen und Blöcke werden im Netzwerk weiterverteilt und die Blöcke in die individuelle Blockchain übernommen. Gibt es zwei korrekte Blöcke, die auf demselben Ausgangsblock basieren, werden beide Blockketten behalten. Neue Blöcke werden von den Minern immer auf der längsten Kette gebildet, weil hierin die meiste Rechenarbeit steckt und damit die Mehrheit des Netzwerkes dainter steht. Nebenketten verwaisen so schnell wieder. Die Transaktionen dieser Nebenketten gelten in der Hauptkette als offen und werden normal integriert.

 

Durch dieses Verfahren müssten bei rückwirkenden Änderungen in der Blockchain alle Blöcke von dort aus neu berechnet werden und die aktuell längste Kette der Blockchain eingeholt werden. Je weiter die Transaktion zurückliegt, umso aufwändiger wäre dieser Prozess. Innerhalb der Bitcoin-Blockchain können Transaktionen nach sechs folgenden Blöcken als sicher durchgeführt gelten.

 

Änderungen des zugrundeliegenden Blockchain-Protokolls können zu Forks (Aufteilungen) führen, wenn nicht alle Knoten die neuen Regeln übernehmen. Bei einer Soft Fork werden die Regeln strenger gefasst, so dass es bei einer Kette der Blockchain bleibt. Bei einer Hard Fork werden die Regeln gelockert (beispielsweise die höhere Blocksize in Bitcoin Cash), so dass es zu einer dauerhaften Trennung der Blockchain in zwei Ketten kommt, da Knoten die das neue Protokoll nicht anwenden, die entsprechenden Blöcke nicht akzeptieren.

 

Ein großer Nachteil von Bitcoin ist die relaitv geringe Skalierbarkeit durch die durchschnittlichen Block-Erzeugungszeiten von 10 Minuten und den Aufand der Verteilung aller Informationen im gesamten Netzwerk. Mit dem Lightning Netzwerk soll hier eine schnellere Alternative angeboten werden: es handelt sich um ein auf der Bitcoin-Blockchain aufsetzendes Netzwerk von vorfinanzierten Bezahlkanälen. Einzelne Knoten verbuchen in der Bitcoin-Blockchain einen Betrag, den sie im Lightning-Netzwerk verfügbar haben wollen. Innerhalb des Lightning-Netzwerks werden Transaktionen dann nur zwischen zwei Knoten abgehandelt, ohne sie an das restliche Netzwerk weiterzugeben. Das sichert eine erheblich höhere Transaktionsgeschwindigkeit und geringere Transaktionsgebühren. Es handelt sich aber durchgängig um valide Bitcoin-Transaktionen, es ist kein Vertrauen in die Partner notwendig.

 

PDF Download

DevOps

DevOps, die Zusammenarbeit von (nicht nur) Entwicklern und Operations in gemischten Teams basiert auf zwei Aspekten: der Übertragung der Prinzipien der Lean Production auf die IT (Arbeitsorganisation) und der Überzeugung, dass in den komplexen IT-Systemen von heute Fehler unvermeidlich sind (Führung).

 

Die drei Pfeiler von DevOps sind:

• Verbesserung des Workflows von Development über Operations bis zum Kunden
• Kontinuierliches, zeitnahes Feedback um immer stabilere Arbeitsergebnisse zu liefern
• Kontinuierliches Lernen und Experimentieren zur Einbindung eines dauerhaften Verbesserungsprozesses in die Arbeitsorganisation

Die Verbesserung des Workflows erfolgt in DevOps mittels

continuous integration → continuous delivery → continuous deployment.

Dabei bedeutet continuous integration, dass die Entwickler nur an kleinen Programmteilen arbeiten, die mindestens täglich in das Hauptprogramm integriert werden. Automatisierte Tests in produktionsähnlichen Umgebungen sorgen dabei dafür, dass immer fehlerfreier Code vorliegt.

Continuous delivery stellt sicher, dass jederzeit deploybarer Code erstellt wird und umfasst neben der continuous integration auch automatisierte Infrastruktur-Setups und die weitgehend automatisierten Tests und Paketierungen des gesamten Releasezyklus.

Der weitgehend automatisierte Prozess von Development bis zum deploybaren Code wird als Deployment Pipeline bezeichnet.

Als Continuous deployment bezeichnet man eine Erweiterung des continuous delivery, bei der grundsätzlich ein automatisiertes Deployment in Produktion erfolgt.

Kontinuierliches Feedback entsteht durch:

• Beobachten der Applikation durch Metriken fachlicher und technischer Art
• Verständnis des non-functional Bereich durch Mitarbeit der Entwickler in Ops
• Peer Review des Programmcodes

Ziel ist, die Qualitätssicherung immer möglichst nah an der Quelle durchzuführen, so dass der Zusammenhang zwischen Ursache und Fehlereffekt klar ist und keine Folgefehler entstehen.

 

Die Führungsphilosophie muss sich zu der einer lernenden Organisation ändern. Fehler werden als eine Möglichkeit zum Lernen angesehen, nicht als etwas, was zu bestrafen ist.

• Incidents werden nach Behebung ohne Schuldzuweisungen aus unterschiedlichen Perspektiven betrachtet und Gegenmaßnahmen eingeführt. Die Erkenntnisse werden in die gesamte Organisation gestreut.
• Mindestens 20% der Entwicklungszyklen werden reserviert, um organisatorische Verbesserungen und Lernen zu ermöglichen
• Standards und Prozesse werden in einem Shared Source Code dem gesamten Unternehmen zur Verfügung gestellt.
• Bewusstes Provozieren von Fehlern, um die Widerstandsfähigkeit der Systeme zu verbessern

Nach einer im Auftrag von CA Technologies 2014 durchgeführten Umfrage verbessert die Einführung von DevOps Zeitaufwand für Fehlerbehebung und Maintenance von Anwendungen, Application Performance, Mitarbeiterproduktivität und Softwareakzeptanz bei End Usern und Kunden um jeweils ca. 20%.

PDF Download

API

Eine API, Application Programming Interface, ist eine maschinenlesbare Schnittstelle zu einer Software-Komponente, die unter Verwendung von Standard-Technologien über ein Netzwerk aufgerufen werden kann. Sie dient dem Austausch und der einfachen Weiterverarbeitung von Daten.

 

Bei einer API geht es weniger um die Einführung einer neuen Technologie, als um eine andere Art mit Schnittstellen umzugehen: die Bereitstellung von Self-Service, 1:n, wiederverwendbaren Schnittstellen. APIs sind aus Nutzersicht geschrieben. Der Anwender muss keine spezifische Software oder Wissen über interne Prozesse oder Systeme haben. Moderne APIs sind auf einfache Nutzung statt auf einfache Erstellung ausgerichtet.

Bei der Einführung einer API sind neben der reinen Entwicklung auch API Governance, Cyber Security, die Messung der API-Performance, die Betreuung der App-Entwickler und ggf. Bezahlmodelle zu berücksichtigen. 90% aller APIs sind intern genutzt. Meist werden so erst interne Daten strukturiert, dann anderen Geschäftsbereichen verfügbar gemacht und schließlich Kunden, Partnern, oder der Allgemeinheit.

Interne oder private API werden intern oder restriktiv mit ausgewählten Partnern oder Kunden genutzt. Externe oder public/open API sind allgemein verfügbar.

Man unterscheidet auch verwaltete API mit einer klaren Definition und Zielgruppe von nicht-verwalteten API mit definierter Schnittstelle aber ohne weiteres Monitoring. Letztere kommen z.B. bei Sensoren wie Fitbit zum Einsatz.

 

Zur Standardisierung der Struktur einer API werden Protokolle wie SOAP und REST verwendet.

SOAP (ursprünglich Simple Object Access Protocol, heute eingetragener Markenname in den USA) ist ein industrieller Standard des W3C und unterstützt somit auch alle andere W3C-Standards wie WS-Policy oder WS-Security. Bei SOAP handelt es sich um ein Netzwerkprotokoll, meist werden HTTP oder TCP verwendet, möglich sind auch SMTP oder JMS. Als Datenformat wird meist XML verwendet, es sind aber auch andere Formate möglich.

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, welchem ein lokaler Name zugewiesen werden muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf http://www.w3.org/2003/05/soap-envelope. Kind dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem können Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung, untergebracht werden. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Zur Semantik applikations-spezifischer Daten macht SOAP keinerlei Vorschriften, es stellt lediglich ein Framework zu deren Übertragung zur Verfügung.

REST steht für Representational State Transfer und ist der inzwischen deutlich häufiger verwendete Standard. REST ist ein Architekturstil, Kernidee ist das Konzept der Ressource. Ort und Name der Ressource werden in der URL abgebildet, z.B. http://example.com/orders. REST funktioniert unabhängig von jedweden Protokollen, üblicherweise wird aber HTTP verwendet. Bei REST wird stets über einen einheitlichen Satz von Standardmethoden auf eine Ressource zugegriffen, bei HTTP über die Methoden GET (lesen), POST (erstellen), PUT (ändern) und DELETE (löschen).

 

Als Datenformate bei APIs kommen meist JSON oder XML zum Einsatz.

JSON, JavaScript Object Notation, ist ein einfaches Format, in dem Objekte mit zwei Teilen beschrieben werden: keys und values. Keys sind Attribute eines Objektes, wie Bearbeitungsstatus oder Belag einer Pizza. Values sind die Ausprägungen dieser Attribute, also 'versandt' oder 'Pilze', 'Salami'. Dabei lässt sich auch ein Objekt als value einbetten.

XML, Extensible Markup Language, dient der Darstellung hierarchisch strukturierter Daten im Format einer Textdatei und ist plattform- und implementationsunabhängig. Hier ist jeweils ein Anfangs-Node erforderlich, der den key angibt, gefolgt von den values und abgeschlossen von einem End-Node.

 

Für die Autorisierung hat sich das Framework OAuth2 etabliert. Hier gibt es vier unterschiedliche Abläufe: die sicherste Methode ist der Authorization Code Grant. Wenn die Client-App keinen Server hat, gibt es die Abwandlung des Implicit Grant. Für die reine Server-to-Server-Kommunikation gibt es die Vorgehensweise des Client Credential und beim Password Grant oder Resource Owner Password gibt der User sein Password für den Server in der Client-App ein. Eine Vorgehensweise, die man normalerweise vermeiden möchte.

Für die Authentifizierung sind bekannte Standards FacebookConnect, Google FriendConnect oder der OpenId-Standard. Statt des Aufbaus eines eigenen Userpools erfolgt die Authentifizierung hier über sogenannte Identity Provider, genannt Single Sign-On. OpenId ist ein Standard, den unterschiedlichste Anbieter verwenden und der eine Spezialisierung innerhalb des OAuth2-Frameworks darstellt.

 

Eine Aktion des Servers, wen sich dort Daten ändern, ist in der Architektur von APIs schwierig. Es gibt die Möglichkeit des Polling, einer regelmäßigen Anfrage des Clients beim Server, des Long Polling, wenn der Server erst bei einer Änderung der Daten auf die Anfrage des Clients antwortet, oder des Webhooks. Hier wird der Client zum Server und kann somit Requests empfangen. Dafür stellt er dem Server eine callback URL zur Verfügung, an die der Server Updates sendet.

PDF Download