Von Anfang an wurde Software in einer Abfolge von Schritten entwickelt. Es beginnt normalerweise mit einer großartigen Idee oder der gewünschten Lösung für ein bestimmtes Problem. Dann geht es bis zur eigentlichen Lieferung oder sogar Wartung des Endprodukts.
Unabhängig davon, ob Ihr Unternehmen oder Team einen eher traditionellen oder agilen Ansatz verwendet, ist der Ablauf, bei dem ein Output als Input für den nächsten Schritt generiert wird, Teil jedes Softwareentwicklungsprozesses.
In diesem Artikel werden wir über einige der Praktiken sprechen, die während des gesamten Softwarelebenszyklus für verschiedene Zwecke verwendet werden und von Softwareentwicklungsunternehmen auf der ganzen Welt wie unseren verwendet werden - Imaginary Cloud. Begleiten Sie uns auf dieser agilen Reise, die bald beginnen wird!
SDLC steht für Lebenszyklus der Softwareentwicklung. Entgegen der landläufigen Meinung SDLC ist kein Framework oder sogar ein beschriebener Prozess. Es kann zwar definiert werden als konzeptionelles Modell verwendet, um darzustellen wie Software in einer Reihe von Schritten hergestellt wird. Diese Schritte umfassen Phasen von der Ideenfindung bis zur Umsetzung und werden wie folgt beschrieben:
1. Planung;
2. Analyse/Anforderungen;
3. Design und Prototypenbau;
4. Softwareentwicklung;
5. Testen;
6. Einsatz;
7. Betrieb und Wartung
Unabhängig von der Methodik oder dem Entwicklungsrahmen, den Ihr Team verwendet, sollte es mehr oder weniger detailliert alle Schritte, die im SDLC vorhanden sind. Zum Beispiel ein Wasserfall-Ansatz würde jeden Schritt als eine spezifische Phase des Projekts verfolgen, d. h. das Ende eines jeden einzelnen, ein Phasentor/Meilenstein in Bezug auf den Projektfortschritt. Ein Agile Methodik würde normalerweise all diese Schritte zu sich wiederholenden, zyklischen und iterativen Blöcken „zusammenfassen“ und all diese Schritte für jede Iteration abdecken.
Das Konzept von Agil in der Softwareentwicklung gibt es schon seit Jahrzehnten. Die mangelnde Formbarkeit, die üblichen Schwergewichtsprozesse und die Widerstandsfähigkeit gegen Veränderungen, die in der Branche bis Ende der 90er Jahre bei Wasserfallprojekten häufig auftraten, wurden mit einer neuen Ausrichtung konfrontiert. Damals waren agile Methoden (die damals noch nicht einmal diesen Namen hatten), wie Gedränge, XP, Kristall, Feature-getriebene Entwicklung (FDD), und Methode der dynamischen Systementwicklung (DSDM), unter anderem, begann zu erscheinen.
Mit Ideen, die verschiedene Aspekte abdecken von: Willkommen sich ändernde Anforderungen; Software häufig ausliefern; enge Synergie zwischen Geschäftsleute und Entwicklungsteam; sowie die Reflexion über wie kann man sich verbessern, bringt Licht in eine neue Art der Softwareerstellung. Abgesehen von allen Trends oder Trends, die kommen und gehen, besteht der wahre Vorteil von Agile darin, bekannte Probleme, mit denen in der Welt der Softwareentwicklung häufig konfrontiert sind, aus einer anderen Perspektive anzugehen.
Anstatt dem überbeanspruchten Pfad zu folgen, nur die vier Werte abzudecken, die in der Agiles Manifest, unser Ansatz wird darin bestehen, darüber zu sprechen Die Prinzipien und Best Practices von Agile. Sie werden oft übersehen, obwohl sie noch mehr Details der Denkweise repräsentieren, die Agile mitbringen sollte.
Eine „Praxis“ kann definiert werden als“die tatsächliche Anwendung oder Verwendung einer Idee, eines Glaubens oder einer Methode im Gegensatz zu Theorien, die sich darauf beziehen“. Diese Definition steht eindeutig was sind agile Praktiken: eine Möglichkeit, die Theorie anzuwenden, die hinter dem eigentlichen Konzept steht, was Agilität bedeutet.
Agile Praktiken können sogar verwendet werden, ohne einer bestimmten Agile-Methodik zu folgen — d. h. TDD (Testgetriebene Entwicklung) allein macht Ihre Lieferung oder Ihren Prozess nicht per se vollständig agil. Es ist wichtig zu erklären, dass die meisten agilen Praktiken so genannt werden, weil sie entweder ist aus einer agilen Methodik hervorgegangen oder wurden von agilen Praktikern entwickelt.
Verschiedene Agile-Methoden fördern unterschiedliche Agile-Praktiken, um sie objektiver und produktiver zu machen.
Jede dieser Praktiken konzentriert sich im Allgemeinen auf einen bestimmten Aspekt, wie Management, Entwicklung, Testen usw.
Im Folgenden stellen wir Ihnen ohne weitere Umschweife eine Liste von Agile-Praktiken vor, die in verschiedenen Schritten Ihres Unternehmens angewendet werden können SDLC (Lebenszyklus der Softwareentwicklung).
Denken Sie daran, dass einige der hier vorgestellten Praktiken je nach ihren Zielen möglicherweise einmal oder mehrmals angewendet werden können. Einige Methoden behandeln zufällig einen Schritt der SDLC als andere. Es kann jedoch vorkommen, dass eine bestimmte Praxis einen Aspekt vollständig und eine andere Phase teilweise abdeckt. Die Faustregel lautete schon immer: weniger darauf achten, streng zu sein, und mehr Fokus darauf, die gewünschten Ergebnisse zu erzielen :).
Eine der ersten Phasen, die das Projekt haben sollte, ist Produktvision. Bei der ersten Vorstellung des Projekts sind einige kurze Definitionen erforderlich: Wer sind die Kunden, das Team, ein übergeordneter Umfang (und ein Gegenbereich!) , Entwürfe des technischen Ansatzes, potenzielle Risiken sowie geschätzter Zeit- und Kostenaufwand. Ein nettes Thema, das behandelt werden sollte, ist das Leitbild - auch bekannt als „Elevator Pitch“, das ungefähr so aussehen sollte wie das Folgende.
Geschäftsmodell Canvas sollte verwendet werden, um das zu bauende Produkt zu gestalten und dabei eine praktische Richtung bei der Definition von Geschäftsmodellen einzuschlagen. Wird in Verbindung mit verwendet Lean Startup, dies ist ein Tool, das effizient als visuelles Diagramm der Ideen und Wahrnehmungen eines bestehenden oder neuen Unternehmens dienen kann.
Formulieren Sie daher ein vollständiges Verständnis als Grundlage für Hypothesen und Wertversprechen. Bedecken neun Blöcke: Aktivitäten, Partner, Ressourcen, Wertversprechen, Kunden, Kundenkanäle, Kundenbeziehungen, Kosten und Umsatz auf strukturierte Weise. Business Model Canvas kann bei der Planung eines Projekts eine wichtige Rolle spielen.
Das Product Backlog ist ein Liste der Geschäfts- und Projektziele und enthält das, was voraussichtlich von der entwickelt werden wird Entwicklungsteam, gepflegt von der Inhaber des Produkts. Es ist ein lebendiges Dokument, das kontinuierlich aktualisiert, priorisiert und geordnet nach geschäftlicher Wert. Es kann auch Produktverbesserungen, Fehler, technische Fragen usw. enthalten. Es dient hauptsächlich dazu, alles zur Verfügung zu haben, was zur Umsetzung der Produktvision des Projekts erforderlich ist.
Paulo Caroli schuf Lean Inception als seine Adaption und Weiterentwicklung der Inception-Phase, die bei ThoughtWorks verwendet wurde. Die Idee dahinter ist um Design Thinking und Lean Startup zu kombinieren über einen Entdeckungsworkshop zur Definition der MVP des Produkts. Im Abstand von einer Woche zielt der Workshop in der Regel darauf ab, die Richtung zu finden, die das Team einschlagen sollte, um das ideale Produkt zu entwickeln. Dieser Ansatz kann als Erweiterung des bereits erwähnten Themas „Produktvision“ betrachtet werden. Es umfasst auch Schritte wie die Definition von Personas, Reisen, Funktionen, technischen, UX- und Geschäftsrezensionen usw. während dieses einwöchigen Zeitraums.
Produktdesign-Prozess so definieren wir bei Imaginary Cloud, wie digitale Produkte hergestellt werden — und ja, wir haben ein Buch darüber. Dieser Ansatz, den wir intern verwenden in den Projekten, in denen wir arbeiten, wird auch extern von verschiedenen Akteuren der Branche verwendet. Es konzentriert sich darauf, die notwendigen Schritte zu behandeln, um eine bemerkenswerte Lösung zu finden, und bietet nicht nur Kunden und Produkteigentümer in den Mittelpunkt dieser Diskussion, aber auch die Benutzer.
Dieser Prozess kann ein bis mehrere Wochen dauern (abhängig von der Komplexität des Produkts und davon, wie tief wir graben müssen, um die Lösung zu definieren). Er beinhaltet 12 Schrittevon der Recherche über die Ideenfindung, Umsetzung und technische Bewertung bis hin zur bestmöglichen Untersuchung und Identifizierung der Entwicklung des Produkts.
Wir haben den Product Backlog bereits früher in diesem Beitrag erwähnt, um Ihre Produktziele zu planen und zu strukturieren. Es ist auch sinnvoll, eine Methode aufzuzeigen, mit der Sie damit arbeiten können (vorausgesetzt, dass User Stories zur Erstellung und Pflege Ihres Product Backlogs verwendet werden).
Zuordnung von Benutzergeschichten ist eine reine Technik, die eine visuelle Aufschlüsselung — oder „Slicing“ — von Benutzergeschichten ermöglicht, sodass sie nacheinander angegangen und behandelt werden können, sodass sie als Produkt sinnvoll sind, vom Backbone bis hin zu kleineren Details. Dieser Ansatz ist nützlich, wenn er den Kontext dahingehend vermittelt, dass die Funktionen als ganzes Projekt aufgeteilt werden und nicht nur als Darstellung einer gruppierten Liste. Es ist wichtig zu erwähnen, dass die Definition, wie dünn oder dick die Scheiben definiert sind, auf Folgendes abzielt durchgängige Erzählung, kommt von direkt Interaktion mit Kunden/Nutzern.
Domänengetriebenes Design - oder DDD - ist ein Konzept, das verwendet wird in Softwaredesign um die Softwarearchitekturmodelle mithilfe einer Abstraktion des Geschäftsbereichs der Anwendung zu strukturieren. Es erfordert Integration und Zusammenarbeit sowohl auf technischer als auch auf geschäftlicher Seite (dabei wird eines der Hauptmerkmale von DDD verwendet: eine allgegenwärtige Sprache, die auf ein gemeinsames Verständnis von Begriffen von allen Seiten abzielt).
Da DDD sich neben der Nutzung der Vorteile von stark auf die Definition der Domänenschicht konzentriert Objektorientierte Programmierung Konzepte, es wurde in der OOP-Community sehr beliebt. Die allgemeine Idee kann jedoch unabhängig vom verwendeten Programmierparadigma verwendet werden, insbesondere weil sie als Grundlage für Praktiken wie TDD, BDD, CI, Refactoring usw. verwendet werden kann.
Techniken wie die Verwendung von Entitäten, Wertobjekten oder Subdomänen wie begrenzten Kontexten, Bausteinen wie Services, Repositorys, Factories und Events verleihen der Anwendung ein strategisches Design. Es ermöglicht das Kombinieren Struktur der Domain, Lebenszyklus und Verhalten auf prägnante und verwandte Weise.
Stachel - ein in Agile häufig verwendeter Begriff, der aus XP stammt - bezieht sich auf eine Art von Anwenderbericht wurde verwendet, um einen Ansatz zu untersuchen und zu versuchen, gerade genug zu verstehen, um so das Risiko zu verringern, wenn er ergriffen wird. Architektonischer Spike geht noch einen Schritt weiter in Richtung Softwaredesign und Architektur. Es zielt darauf ab, die zu definieren Rückgrat der Modellierungsarchitektur und wie wird es alle arbeiten zusammen, aber mit genügend Pragmatismus wird diese Lösung auf der Grundlage der noch begrenzten vorhandenen Informationen zum Problembereich vorgeschlagen. Bei dieser Praxis werden häufig folgende Definitionen getroffen Softwareschichten, Grenzen der Subsysteme, sehr wahrscheinlich einige funktionierende Code- und Quellcodeverwaltungstools als minimales/optimales Grundgerüst der Anwendung. Es trägt dazu bei, die System-Metapher zu definieren und Teil davon zu werden, eine „einfache gemeinsame Geschichte darüber, wie das System funktioniert“.
Nicht genug zu sagen, dass mit der Weiterentwicklung des Projekts und der Anwendung auch die Architektur angepasst und verfeinert werden sollte, da der Architectural Spike nur die erste Aufgabe in diese Richtung ist. Diese Idee wird in der Praxis erörtert und im folgenden Abschnitt behandelt.
Das elfte Prinzip der Agiles Manifest Das oben erwähnte sagt das“Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.“ Wenn Sie genau über das Design sprechen, fragen Sie sich vielleicht immer noch, was das bedeutet. Emergent Design spricht davon, die Lösung evolutionär zu entwickeln, was sein Design ermöglicht und Architektur müssen während der gesamten Entwicklungsreise definiert werden. Um etwas Fachjargon zu verwenden, anstatt etwas zu tun BDUF (Großes Design vorne), JEDI wird häufig verwendet (Just Enough Design Initially). Wenn Entwickler dieser Denkweise schrittweise folgen, können sie sich auf die direkten Projektanforderungen konzentrieren und so eine frühzeitige und suboptimal definierte Architektur vermeiden — auch wenn es erwähnenswert ist, dass der Schwerpunkt auf der Erfüllung von Anforderungen liegen sollte, anstatt nur zu versuchen, die Zukunft vorherzusagen.
Trotz einiger Kritik an den Vorteilen der Definition von Architektur (im Gegensatz zur Definition starker und vollständiger Backbones eines so wichtigen Teils der Anwendung) sollte man die Vorteile, die Agile bieten kann, massiv nutzen Adaptions- und Lernumgebung.
Die Praxis des Tuns Kontinuierliche Integration (CI) entspricht der Hauptcode-Streamline, die die von den Entwicklern vorgenommenen Änderungen oder Ergänzungen separat in einem einzigen Software-Projekt-Repository/Branch aufnimmt. Diese Aktion sollte einige Schritte wie automatische Tests und Tools zur Überprüfung des Syntaxstils auslösen, die normalerweise von einem CI-Tool in Verbindung mit einem Versionskontroll-Managementsystem. XP schlägt vor, diesen Vorgang mehrmals täglich durchzuführen, um sicherzustellen, dass eine funktionierende integrierte Version des Codes existiert.
CI ist die erste Phase in einem Kettenprozess das umfasst Continuous Deployment (eine Anwendung wird in der Produktion veröffentlicht, wenn sie alle Schritte des automatisierten Bereitstellungsprozesses erfolgreich durchläuft) und Continuous Delivery (wobei die Codebasis jederzeit in verschiedenen Umgebungen bereitgestellt werden kann).
Die Standardstrategie der kontinuierlichen Integration, vorgeschlagen von Martin Fowler folgt dem Folgenden:
Die wichtigsten Vorteile, die mit CI beobachtet wurden, gehen von effizientere Erkennung von Bugs, Vermeidung des Mehraufwands eines manuellen Integrationsprozesses, immer verfügbarer Aufbau von Umgebungen, der Prozess wird immer mehr transparent (daher Verbesserung der Kommunikation) und Förderung einer umfassenderen Testabdeckung. CI schafft auch Raum für die Umsetzung von Praktiken wie Pull-Requests und Code-Review.
Testgetriebene Entwicklung, oder TDD, ist bekannt als die Praxis der Test-First-Programmierung, bei der durch die Erstellung automatisierter Komponententests ein wiederholbarer Ablauf von Folgendem folgt:
Die Hauptziele dieses Ansatzes sind mache den Code klarer, einfacher und fehlerfrei, während wir besser über die Struktur nachdenken und die internen Schnittstellen und Verantwortlichkeiten des Systems berücksichtigen.
Es gibt spezielle Tools, die Unit-Tests und TDD unterstützen, allgemein bekannt als XUnit-Tools (JUnit, NUnit, XpyUnit, PHPUnit usw.), aber nicht darauf beschränkt sind.
TDD ist zweifellos ein Paradigmenwechsel für Entwickler, die es nicht gewohnt sind, diese Schritte zu befolgen. Ein weit verbreitetes Tabu in Bezug auf TDD ist, dass es zu viel Aufwand und Zeit erfordert und sich daher nicht lohnt. Als Faustregel gilt in solchen Fällen, einen Mittelweg zu finden und diesen zu verstehen TDD sollte sowohl mehr getesteten als auch saubereren Code bringen zur Bewerbung.
Es ist wichtig zu erwähnen, dass TDD nicht der einzige Teil der sein kann Qualitätssicherungsstrategie der Anwendung, und das wird weiter unten behandelt, wenn wir über QA sprechen. Außerdem sollten die automatisierten Tests, die bei Verwendung eines TDD-Ansatzes erstellt werden, sicherlich Teil der Strategie der kontinuierlichen Integration der Anwendung sein, da sie einer der erforderlichen Schritte sind, um diesen Prozess durchzuführen.
Wahrscheinlich die besten Definitionen von Refaktorierung stammt von Martin Fowler.
„Eine disziplinierte Technik zur Restrukturierung eines vorhandenen Codekörpers, wobei seine interne Struktur geändert wird, ohne sein äußeres Verhalten zu ändern.“
Oder...
„Eine Änderung an der internen Struktur von Software, um sie verständlicher und kostengünstiger zu modifizieren, ohne ihr beobachtbares Verhalten zu ändern“.
Die Anforderungen an das Code-Refactoring ergeben sich häufig aus“Codegeruch“: ein Hinweis auf eine Reorganisation aufgrund von Schwächen oder potenziellen Problemen im Code. Refactoring wird häufig zur Begleichung der technischen Schulden eingesetzt — einer der Albträume eines der größten Projekte. Außerdem wird bei TDD der Schritt, in dem das (Neu-) Schreiben von Code erwähnt wird, der den Test besteht, im Allgemeinen auch als Refactoring bezeichnet.
Für manche Menschen mag es schwierig sein, die Vorteile einer konzentrierten Arbeit auf die Arbeit an bereits geschriebenem Code zu verstehen. Es kann jedoch sicherlich die Wartbarkeit, den Zusammenhalt, die Lesbarkeit, die Leistung und die Wiederverwendbarkeit des Codes verbessern, was unter anderem den Zeitaufwand rechtfertigen sollte. Es gilt, das noch einmal zu betonen Beim Refactoring geht es nicht darum, neue Funktionen zu erstellen, da dies über seinen Zweck hinausgeht. Das Ziel sollte immer sein behält sein aktuelles Verhalten bei (bestehende und/oder neue Tests sollten vorhanden sein, um dies zu gewährleisten).
Einige Beispiele für die übliche Verwendung von Refactoring sind: Verwendung von Entwurfsmustern, Polymorphie, Kapselung von Feldern, Änderung der Verwendung von Parametern, Ausnahmen usw.
Wahrscheinlich die besten Definitionen von Refaktorierung stammt von Martin Fowler.
BDD steht für Verhaltensorientierte Entwicklungund kann definiert werden als“ein Entwicklungsansatz, der die Kommunikation zwischen Geschäfts- und technischen Teams verbessert, um Software mit geschäftlichem Nutzen zu entwickeln“. BDD will der Treffpunkt für Geschäftsleute, Entwickler und QA-Tester sein (um nicht zu sagen alle am Projekt Beteiligten), um ein gemeinsames Verständnis und eine einheitliche Kommunikation der Merkmale der Anwendung zu gewährleisten. Dies wird erreicht, indem die Spezifikationen auf der Grundlage von Szenarien und Beispielen erstellt werden, wobei ein gemeinsames Muster „Gegeben-Wann-Dhen“ verwendet wird, um das tatsächliche Verhalten der Lösung darzustellen.
ATDD (Akzeptanztestgetriebene Entwicklung) geht noch einen Schritt weiter und verwendet die Basis von BDD, um codierte Akzeptanztests unter Berücksichtigung der erwartetes Verhalten zuvor in den Szenarien definiert. ATDD ähnelt TDD in dem Sinne, dass es in der Regel eine Reihe von Abnahmetests automatisiert, die nicht bestanden haben, bevor Code erstellt wird, der sie bestehen lässt, und teilt sich einen ähnlichen Zyklus wie dieser Ansatz.
Tools zum Testen wie Behat, Cucumber oder SpecFlow sind Beispiele für Optionen, die die Verwendung ausführbarer Spezifikationen unterstützen und die Verwendung von ATDD im Projekt ermöglichen und dabei die Vorteile nutzen, die mit BDD definiert wurden.
Obwohl sie nicht offiziell als agile Praxis definiert ist, ist es in der Community gesunder Menschenverstand, dass die Automatisierung von Tests die beste ist Hauptstruktur zur Bewältigung der Qualitätssicherung wenn es um Agile geht. Dadurch können unter anderem andere Praktiken wie ATDD, TDD, CI so effektiv wie möglich sein.
Wie Sie sich vorstellen können, automatisiertes Testen ist die Form der Verwendung einer separaten Software, um Tests in Ihrer Software zu implementieren. Entweder durch Überprüfung der externen Schnittstellen, wie z. B. mobile oder browserbasierte GUI-Tests, die interne Kommunikation zwischen den Ebenen, wie APIs oder sogar gezielte Leistungsanalysen. Der offensichtlichere und wichtigste Vorteil eines solchen Ansatzes besteht darin, dass die bei manuellen Prozessen üblichen Wiederholungen vermieden werden, ganz zu schweigen von der Wahrscheinlichkeit, dass menschliche Fehler auftreten.
Diese Vorteile zeigen sich in einigen Teststrategien wie Regressionstests, oder ein Kontinuierliche Integrationspipeline. Angesichts des erforderlichen Aufwands für die Implementierung dieser Arten von Tests ist es wichtig zu überlegen, wann und was automatisiert werden soll. Der Grad der automatisierten Testabdeckung, ob als Komponententest, Integrationstest oder allgemeiner als durchgängiges Testen, erfordert je nach gewünschtem Schwerpunkt unterschiedliche Anstrengungen und bringt unterschiedlichen Nutzen. Eine ähnliche Logik gilt bei der Entscheidung über das zu verwendende Instrumentarium, für das eine gewissenhafte Bewertung vorgeschlagen wird. Selenium, Jasmine und RSpec sind Beispiele für verschiedene Testwerkzeuge, die für verschiedene Testzwecke verfügbar sind.
Sitzungsbasiertes Testen ist ein weiteres Beispiel für eine Testpraxis, die zwar nicht offiziell als Agile definiert ist, es hat eine große Akzeptanz in der Agile-Welt. Diese Teststrategie kann als eine strukturiertere Methode für manuelles exploratives Testen bezeichnet werden, was im Grunde bedeutet, eine Software zu testen, ohne vorher Testfälle zu entwerfen oder zu definieren, wobei frei nach Fehlern gesucht wird. Auf diese Weise folgt das sitzungsbasierte Testen einemTeile um zu erobern“ explorative Idee, die zeitnahe Tests unterteilt in - rate mal was? -, Sitzungen. Es folgt einer Reihe von Schritten (selbsterklärend), nämlich Mission, Charta, Sitzung, Sitzungsbericht, Nachbesprechung und Analyse, die dabei helfen, genau genug detailliert abzudecken, was für einen solchen Prozess erforderlich ist.
Im agilen Kontext Für jede User Story können mehrere Sessions definiert werden, indem beispielsweise je nach den damit verbundenen Risiken mehr oder weniger davon abgedeckt werden. Diese Flexibilität ermöglicht es dieser Praxis, dem schnellen Tempo in Agile gerecht zu werden. Neben dem hohen Fokus, der mit der Automatisierung von Tests und Tests auf der Entwicklungsseite verbunden ist, ist es auch äußerst wichtig, Folgendes zu verstehen Wert neben manuellem Testen wenn es effektiv gemacht wird. Es kann bestimmte Aspekte der Software erreichen, die nur diese Ansätze nicht erreichen können. Sowohl manuelle als auch automatisierte Teststrategien sollten zusammen die notwendige Arbeit leisten, um die für ein Projekt erforderliche Qualitätssicherung zu gewährleisten.
DevOps steht für Kombination und Zusammenarbeit zwischen Entwicklungs- und IT-Betriebsteams um eine kontinuierliche und schnelle Lieferung zu erreichen. Bei diesem Ansatz arbeiten beide Seiten zusammen und unterstreichen die Bedeutung ihrer Kommunikation und Integration anhand des Konzepts Infrastruktur als Code (IaaC). Die wichtigsten Schritte, um dies zu erreichen, umfassen: Infrastrukturautomatisierung (Systeme, Konfigurationen und Anwendungsbereitstellungen als Code in der Gesamtstruktur des Projekts), Continuous Delivery (Apps automatisch und zeitnah erstellen, testen und bereitstellen) und Site Reliability Engineering: (Betriebssysteme, d. h. Überwachung und Orchestrierung, um sicherzustellen, dass sie solche Funktionen von Anfang an unterstützen).
Auf diese Weise ist der“DevOps-Leiter“ unten ist festgelegt und im Projekt vorhanden.
Der Einsatz von DevOps bietet einige Vorteile, wie z. B. beruhigende Skalierbarkeit, Zuverlässigkeit, Sicherheit, schnelle Bereitstellung (und damit bei Bedarf schnellere Markteinführungszeit), kürzere Mean Time To Recovery (MTTR), Vermeidung von menschlichem Versagen, geringere Ausfallrate bei neuen Releases und vieles mehr. DevOps wird zweifellos angesehen als eine ergänzende Praxis bei der Verwendung von Agile. Dabei werden Aspekte wie häufige Zustellung, Früherkennung von Fehlern, höhere Transparenz bei der Überwachung eines Antrags usw. berücksichtigt Teil von Agile Methodologies SAFe.
Diese Praxis behandelt Themen, die bereits im Rahmen von beschrieben wurden Kontinuierliche Integration und DevOps, ganz zu schweigen von der Korrelation mit automatisierten Tests. Wenn wir also alle Konzepte miteinander verbinden, können wir Continuous Deployment als nächsten Schritt der kontinuierlichen Integration definieren. Dabei werden automatisierte Tests verwendet, um sicherzustellen, dass der richtige Code automatisch in der Produktionsumgebung veröffentlicht wird. Dies erfolgt in der Regel unter Ausnutzung der folgenden Funktionen DevOps-Infrastruktur-Tools. Die automatische Veröffentlichung ist in der Tat ein Unterschied und ein weit verbreitetes Missverständnis, wenn es um Continuous Delivery geht, da sie zwar dieselbe Abkürzung haben, bei letzterem die Aktion „Zur Produktion gehen“ jedoch häufig manuell erfolgt. Continuous Deployment ist der komplette, durchgängige, automatisierte Ablauf der Softwarebereitstellung. Es kann so implementiert werden, dass es je nach Geschäftsanforderungen so oft wie für eine bestimmte Anwendung erforderlich ist.
Die typischen Schritte bei Continuous Deployment sind:
Diese Schritte sollten ausreichend garantieren, dass der erstellte Code ausreichend ist. gut abgedeckt und geprüft. Daher ist es ausgereift, die Produktion ohne größere Bedrohungen zu erreichen, und bietet die Möglichkeit, diese Gefahr bei Bedarf einfach von der Pipeline aus rückgängig zu machen. Sicherlich gibt es Bedenken, einen so wichtigen Schritt zu automatisieren, und die damit verbundenen Risiken sind in der Tat vorhanden. Außerdem muss erwähnt werden, dass eine solche Struktur, die auf Ihrer Anwendung basiert, mit Kosten verbunden ist. Dennoch können die Vorteile, die ein solcher Ansatz mit sich bringt, ein Kernmerkmal einer erfolgreiche Projekt- und Softwarelösung.
Wenn Sie diesen Teil des Artikels erreicht haben, können Sie davon ausgehen, dass Sie es wissen was ist Kanban. Kurz gesagt, es kann beschrieben werden als Workflow-Management-Methode zur Visualisierung der Arbeit, die sie steuert. Es wurde im japanischen Lean-Manufacturing-Bereich, genauer gesagt im Toyota Production System, entwickelt.
In jüngerer Zeit wurden die wichtigsten Ideen, die sich aus dieser Arbeitsweise ergaben, in der Softwarebranche umgesetzt. So entstand die sogenannte Kanban-Methode, die als Hauptartefakt das Kanban-Board verwendet. Dieses Board ist das führende visuelle Repositorium für Informationen und den Fortschritt eines bestimmten Prozesses in Echtzeit, das mögliche Blockaden und Engpässe auf einfache Weise aufzeigt. Die Spalten auf der Tafel stehen für die einzelnen Schritte im Arbeitsablauf und das Konzept von Work In Progress (und dessen Limit pro Spalte), das eine wertvolle Ressource darstellt. Die ganze Idee ist, dass deine Aufgaben (Tickets, Probleme, was auch immer) in jeder Spalte des Boards zu finden sind.
Kanban ist eine evolutionäre Methode, die sehr einfach implementiert werden kann (und deren Prozess und Verwendung schrittweise weiterentwickelt werden), um Dinge zu erledigen. Auch weil es ist nichts weiter als ein unterbrechungsfreies Change-Management-System, Kanban wurde häufig in Betriebs- und Wartungsprojekten eingesetzt. Es nutzt die genannten Punkte, um es in einer On-Demand-Just-in-Time-Umgebung umzusetzen, in der Initiativen wie Scrum nur Overhead und Verschwendung mit sich bringen.
Kanban ist nicht streng als agile Praxis definiert.. Jedoch es wird verwendet, um Agile- und Lean-Prinzipien umzusetzen bei gleichzeitiger Steigerung der Mitarbeiter- und Kundenzufriedenheit.
Das Ziel dieses Artikels war es, echte Optionen vorzustellen, die in jedem verwendet werden können SDLC (Software Development Life Cycle) mit einem starken Fokus auf agile Praktiken.
Dieser Ansatz wird Bestand haben, und solche Vorschläge wurden im Laufe der Jahre genutzt, diskutiert und verbessert. Sie lösen häufig auftretende Probleme, die bei den täglichen Aufgaben von Softwareentwicklungsprojekten auftreten.
Obwohl einige der Praktiken mehr oder weniger verbreitet und bekannt sind, evaluieren wir bei Imaginary Cloud zuerst jedes Szenario in unseren Projekten. Dann wenden wir Praktiken und Techniken an, die es den von uns entwickelten Lösungen ermöglichen, das nächste Level zu erreichen und erfolgreiche Lieferungen zu erzielen.
Basierend auf dem Fachwissen unseres Teams können wir definieren und empfehlen, wie agile Praktiken am besten genutzt werden können und wann sie im Lebenszyklus Ihres Unternehmens angewendet werden sollten Webapplikation oder UI/UX-Designprojekte.
Denkst du, du könntest Hilfe brauchen? Nehmen Sie Kontakt auf!
Fanden Sie diesen Artikel hilfreich? Diese könnten dir auch gefallen!
Softwarebegeistert und agil. Kann leicht beim Kochen, Volleyball spielen oder etwas Zeit mit Videospielen verbringen.
People who read this post, also found these interesting:
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
