Erfreu Dich an Millionen von E-Books, Hörbüchern, Magazinen und mehr

Nur $11.99/Monat nach der Testversion. Jederzeit kündbar.

Bessere Softwareentwicklung mit DevOps

Bessere Softwareentwicklung mit DevOps

Vorschau lesen

Bessere Softwareentwicklung mit DevOps

Länge:
108 Seiten
1 Stunde
Herausgeber:
Freigegeben:
6. Juni 2017
ISBN:
9783868027570
Format:
Buch

Beschreibung

Die Welt der IT entwickelt sich rasant und gefühlt wird alles jeden Tag schneller, besser und komplexer. Agile Softwareentwicklung war der erste Schritt, um diesen neuen Anforderungen gerecht zu werden – bleibt aber oftmals auf Ebene des Entwicklungsteams stecken. Aber nur dann, wenn man Agilität auf den gesamten Unternehmenskontext ausweitet, wird man den Anforderungen von Digitalisierung und Industrie 4.0 gerecht. Uwe Baumann und Thomas Schissler schildern in diesem shortcut einen möglichen Weg dahin – und beschäftigen sich mit allen Facetten von DevOps.
Herausgeber:
Freigegeben:
6. Juni 2017
ISBN:
9783868027570
Format:
Buch

Über den Autor


Ähnlich wie Bessere Softwareentwicklung mit DevOps

Titel in dieser Serie (40)

Mehr anzeigen

Ähnliche Bücher

Ähnliche Artikel

Buchvorschau

Bessere Softwareentwicklung mit DevOps - Uwe Baumann

GmbH

1 DevOps und Business Agility

Im Zuge von Digitalisierung und Industrie 4.0 gefährden Softwarelösungen etablierte Geschäftsmodelle oder stellen zumindest einen wesentlichen Teil der Innovationskraft von Unternehmen dar. Es ist an der Zeit, zu hinterfragen, ob die Art und Weise, wie heute Software entsteht, den Anforderungen der Zukunft gerecht wird.

Nach dem klassischen Wasserfallmodell werden heute kaum noch Softwareprojekte realisiert. Die meisten Softwareentwicklungsteams sind mehr oder weniger agil unterwegs. Unstrittig hat sich damit die Entwicklungsarbeit verändert – für viele zum Positiven. Aber wie sieht die Veränderung durch Agilität für die Endanwender der Software aus? Wie hat Agilität die Arbeit von Vertriebsmitarbeitern beeinflusst, die die Software verkaufen sollen? Wie wirkt sich Agilität auf das Geschäftsmodell und die Marktposition unseres Unternehmens aus? Unsere These: Der tatsächliche Einfluss von Agilität im Software-Development auf das tatsächliche Business einer Firma ist sehr gering.

Im Grunde genommen verhält es sich – überspitzt gesagt – mit der agilen Entwicklung wie mit dem Einsatz des neuesten XY-Frameworks oder einer schicken neuen JavaScript-Bibliothek: Entwickler können sich dafür begeistern und klopfen sich gegenseitig auf die Schulter angesichts der phänomenalen Verbesserungen. Außerhalb des Entwicklungsteams bekommen aber Wenige davon mit.

Unsere These: Wir müssen uns stärker darauf konzentrieren, was Software in der realen Welt bewirken kann und wie gute IT-Lösungen dazu beitragen, auf die rascheren Veränderungen am Markt adäquat reagieren zu können. Doch die meisten Teams haben endlose Backlogs, prall gefüllt mit über lange Jahre gesammelten Userwünschen. Agilität ist hier lediglich ein Werkzeug, um besser zu steuern, was davon als Erstes abgearbeitet werden soll. Wie wollen wir damit aber innovativ sein? Wie wollen wir Kunden begeistern, wenn oftmals die positivste Reaktion ist „na endlich habt ihr dieses Feature eingebaut"?

Business Agility – Agilität auf den Unternehmenskontext ausweiten

Vielleicht ist es zehn Jahre nach dem Agile Manifesto [1] nun Zeit für ein neues Manifest: Wir brauchen eine neue Form der Kundenorientierung. Wir müssen nicht nur Wünsche erfüllen, sondern echten Bedarf erkennen und dafür Lösungen anbieten. Wir müssen die Software dazu nutzen, um die Marktposition und Wirtschaftlichkeit unseres Unternehmens positiv zu unterstützen. Wir müssen uns mehr darauf fokussieren zu lernen, was unsere Kunden benötigen und wie wir sie dabei unterstützen können. Wir müssen Experimente wagen und aus der Beobachtung der Reaktionen lernen, wie wir unser Angebot verbessern können. Dieses Vorgehen wird oft als Business Agility bezeichnet. Ein Zitat aus dem CIO-Magazin bringt es auf den Punkt: „It has been said that the only sustainable advantage in business is the ability for a company to learn faster and respond more effectively than its competitors (also known as business agility)." [2]

Der Begriff Business Agility beschreibt nicht nur sehr treffend das eigentliche Ziel unserer Arbeit in der Softwareentwicklung, sondern drückt gleichzeitig auch aus, dass wir auch Personen aus dem Business in unsere Softwareprojekte einbeziehen müssen. Wir müssen die Prinzipien und Philosophie von Agilität auf weitere Unternehmensbereiche ausdehnen, wie z. B. auf Marketing und Vertrieb, Support oder die Geschäftsführung. Wie dieser Umbruch konkret gestaltet werden kann, diskutieren wir im zweiten Kapitel.

Das Ziel von mehr Business Agility bedingt die Notwendigkeit, Softwareprojekte ganzheitlicher anzugehen. Wir müssen das Wissen und die Kompetenz von Kollegen aus unterschiedlichen Abteilungen nutzen, um uns möglichst gut zu positionieren. Wir müssen unsere Annahmen kritisch hinterfragen: Was macht die Anwender wirklich glücklich? Wir formulieren Hypothesen, die wir kontinuierlich beweisen oder widerlegen und somit weiterentwickeln und anpassen können.

Und hier schließt sich der Kreis zur klassischen agilen Idee. Damit dieser integrierte Prozess überhaupt funktionieren kann, brauchen wir ein flexibles, anpassungsfähiges, also ein agiles Vorgehen. Aber nur dann, wenn wir Agilität in diesen Gesamtkontext einbetten, werden wir auch das volle Potenzial nutzen können. Wir müssen in kurzen Iterationen agieren, um häufig eine Standortbestimmung vorzunehmen und entsprechend nachzusteuern. Diese kurzen Zyklen sind das Grundelement von Business Agility und DevOps.

Und DevOps, was ist das?

DevOps ist ein Begriff, der inzwischen sehr unterschiedlich gebraucht wird. In diesem Kapitel definieren wir DevOps als Prozess, der viele nötige Voraussetzungen schafft, um Software in kurzen Zyklen entwickeln und ausliefern zu können. Ursprünglich entstammt der Begriff der Idee, dass wir Software effizienter und in höherer Qualität bereitstellen können, wenn die Entwickler (Dev) und die Personen, die für den Betrieb der Software zuständig sind (Ops), eng zusammenarbeiten. So soll Operations bereits bei der Planung neuer Funktionen einbezogen werden, um frühzeitig Aspekte aus dem Betrieb einzubringen, die dann bereits bei der Entwicklung berücksichtigt werden können. Die Entwickler wiederum sollen nach Abschluss der Entwicklung einer Funktionalität die neue Version nicht einfach „über den Zaun werfen" und die Operations-Abteilung mit der Aufgabe allein lassen, den neuen Code auf dem Produktivsystem in Betrieb zu nehmen.

Vielmehr gibt es ein gemeinsames Ziel von Dev und Ops: Die Inbetriebnahme soll reibungslos verlaufen und die Anwender sollen neue, stabile und nützliche Funktionen nutzen können. Dazu sollen alle Beteiligten ihren Beitrag leisten. Idealerweise arbeiten Dev und Ops dazu in einem Team zusammen, und jedes Teammitglied bringt seine Erfahrungen und Kompetenzen ein. Dabei endet die Zusammenarbeit nicht mit dem Deployment. Erkenntnisse aus der Inbetriebnahme und dem Betrieb fließen in der Folge in die Entwicklung ein, um spätere Versionen der Software noch stabiler und besser zu machen [3].

Zu dieser ursprünglichen Idee wurden nach und nach weitere Konzepte hinzugefügt, wie das häufige Liefern neuer Softwareversionen, aber auch die Ausdehnung der Zusammenarbeit über Development und Operations hinaus. Gerade die kurzen Lieferzyklen generieren neue technologische Herausforderungen. Die Bewältigung dieser Herausforderungen durch entsprechende Tools, Practices und Prozesse, aber auch durch geeignete Architektur, Testmethoden und Telemetrie sind die Aspekte von DevOps, die wir in den nächsten Kapiteln beleuchten wollen. Aber zunächst können wir DevOps auch mit einem Satz zusammenfassen: DevOps bedeutet zehn Releases am Tag.

Der Weg hin zu DevOps

Bevor Sie aufhören zu lesen: Ja, viele Teams können neue Features gar nicht so schnell entwickeln und wenige brauchen tägliche oder stündliche Releasefrequenzen. Es geht vielmehr darum, die organisatorischen und technischen Voraussetzungen zu schaffen, sodass wir problemlos mehrmals am Tag eine neue Version bereitstellen könnten – idealerweise auf Knopfdruck und ohne manuelle Schritte.

Ob es nun zehn Releases am

Sie haben das Ende dieser Vorschau erreicht. , um mehr zu lesen!
Seite 1 von 1

Rezensionen

Was die anderen über Bessere Softwareentwicklung mit DevOps denken

0
0 Bewertungen / 0 Rezensionen
Wie hat es Ihnen gefallen?
Bewertung: 0 von 5 Sternen

Leser-Rezensionen