Agilität Flashcards
Test-Driven Development (TDD) für die Codeimplementierung
Schreiben eines Tests: Zuerst wird ein Test geschrieben, der das erwartete Verhalten einer bestimmten Funktion oder eines bestimmten Teils des Codes beschreibt. Dieser Test sollte zuerst fehlschlagen, da die Funktionalität noch nicht implementiert ist.
Implementieren des Codes: Anschließend wird der Code geschrieben, um den Test zum Bestehen zu bringen. Das Ziel ist es, den einfachsten Code zu schreiben, der den Test besteht.
Ausführen des Tests: Nachdem der Code implementiert wurde, wird der Test erneut ausgeführt. Wenn der Test erfolgreich ist, wird erneut iteriert, indem entweder ein weiterer Test geschrieben wird oder der vorhandene Code verbessert wird.
Warum werden agile Praktiken nicht als vollständige Prozessmodelle/Vorgehensmodell betrachtet?
sind eher Entwicklungsansätze und keine vollständigen Prozessmodell
Continuous Integration (CI) und Continuous Deployment (CD)
Continuous Integration (CI) und Continuous Deployment (CD) sind Praktiken des Softwareentwicklungsprozesses, die darauf abzielen, die Entwicklung, Tests und Bereitstellung von Software effizienter und zuverlässiger zu gestalten.
Continuous Integration (CI):
CI bezieht sich auf den Prozess, bei dem Entwickler regelmäßig ihren Code in ein gemeinsames Repository integrieren. Dieser Code wird dann automatisch gebaut und getestet, um sicherzustellen, dass er gut mit dem bestehenden Code und anderen Änderungen zusammenarbeitet.
Das Ziel von CI ist es, Probleme frühzeitig zu identifizieren, indem Codeänderungen schnell und häufig in das gemeinsame Repository integriert und automatisch getestet werden. Dies reduziert das Risiko von Integrationsproblemen und trägt dazu bei, die Qualität des Codes zu verbessern.
Continuous Deployment (CD):
CD ist eine Erweiterung von CI und bezieht sich auf den Prozess, bei dem jede Änderung, die erfolgreich durch den CI-Prozess gegangen ist, automatisch in die Produktionsumgebung bereitgestellt wird, ohne manuelle Eingriffe.
Das Ziel von CD ist es, den Bereitstellungsprozess zu automatisieren und die Zeit zwischen der Entwicklung und der Bereitstellung von Software zu verkürzen. Durch die Automatisierung dieses Prozesses können Teams schneller auf Kundenfeedback reagieren und Fehler schneller beheben.
Zusammenfassend sind CI und CD zwei wichtige Praktiken im modernen Softwareentwicklungsprozess, die dazu beitragen, die Qualität der Software zu verbessern, die Entwicklungszeit zu verkürzen und die Effizienz des Bereitstellungsprozesses zu steigern.
Scrum
Scrum ist ein Framework und im weitesten Sinne ein
Vorgehensmodellю 2001 Schwaber unf Beedle.
▪ schafft einen Rahmen für Teams und Organisationen,
um adaptive Lösungen zu schaffen
▪ Scrum erwartet, dass hierfür ein Scrum Master eine
förderliche Umgebung schafft
▪ Nutzung von Scrum bei mehreren parallelen
Projekten des Devteams ist unwirtschaftlich / nicht rentable
▪ Anwendung von Scrum erfordert eine lange
Einarbeitung bzgl. dem Mindset der Mitwirkenden
(„Es muss trainiert und gelebt werden“)
Product Backlog
Dies ist eine To-Do-Liste, die das Scrum Team abarbeiten muss. Die einzelnen Elemente der Liste können Funktionsdefinitionen der Software sein, User-Storys oder Beschreibungen von zusätzliche Tätigkeiten, die erbracht werden müssen, zum Beispiel Benutzerhandbuch.
Sprint
Eine Entwicklungsiteration. Sprints dauern in der Regel zwei bis vier Wochen.
Produkt Owner
Eine Einzelperson / kleine Gruppe, dessen Aufgabe ist, Produktmerkmale oder Anforderungen zu identifizieren, zu priorisieren und ständig das Product Backlog zu überprüfen. Kann ein Kunde sein, ebenso ein Produktmanager oder Vertreter. Product Owner (PO) ordnet Arbeit für komplexes Problem in Product
Backlog an
Scrum Master
Ist dafür verantwortlich sicherzustellen, dass dem Scrum Prozess gefolgt wird, und leitet das Team beim effizienten Einsatz von Scrum. Er oder sie ist die Schnittstelle zum Rest des Unternehmens und dafür verantwortlich sicherzustellen, dass das Scrum Team nicht von äußerer Beeinflussung abgelenkt wird. Die Aussage, dass der Entwickler von Scrum darauf bestehen, dass der Scrum Master nicht als Projektmanager angesehen wird, bezieht sich auf eine grundlegende Unterscheidung zwischen der Rolle des Scrum Masters und der Rolle des Projektmanagers in traditionellen Entwicklungsmethoden.
Aufgaben:
1. Moderiert Sprint-Planungsmeetings
2. Hält täglich Stand-up-Meetings ab
3. Beseitigt Hindernisse (Препятствия)
4. Führt Retrospektiven durch
5. Unterstützt beim Product Backlog
Scrum Rollen
▪ Product Owner (PO) ordnet Arbeit für komplexes Problem in Product Backlog an
▪ das Scrum-Team umsetz während eines Sprints die ausgewählten Aufgaben oder User Stories in ein lauffähiges Produktinkrement
▪ Scrum Team und Stakeholder prüfen Ergebnisse im Review
▪ Iterationen werden wiederholt, wobei PO mit Kunden Priorisierung des Backlogs vornimmt
Daily Scrum
Scrum Event, ein 15-minütiges Timebox-Event, das jeden Tag für die Entwickler stattfindet. Das Daily Scrum findet an jedem Tag des Sprints statt. Dabei planen die Entwickler die Arbeit für die nächsten 24 Stunden.
Increment
Scrum-Artefakt, das die Arbeit definiert, die von den Entwicklern während eines Sprints umgesetzt wird. Die Summe aller Inkremente bildet ein Produkt.
Sprint Backlog
Scrum-Artefakt, das einen Überblick über die Entwicklungsarbeit zur Erreichung des Sprint-Ziels gibt, typischerweise eine Vorhersage der Funktionalität und der zur Bereitstellung dieser Funktionalität erforderlichen Arbeit.
Sprint Planning
Scrum Event, das auf 8 Stunden oder weniger begrenzt ist, um einen Sprint zu starten. Es dient dem Scrum-Team dazu, die Arbeit aus dem Product Backlog, die als Nächstes erledigt werden sollte, in das Sprint Backlog zu intgrieren
Sprint Retrospective
Scrum Event, das auf ein Zeitfenster von 3 Stunden oder weniger festgelegt ist, um einen Sprint zu beenden. Es dient dem Scrum Team zur Überprüfung der Team-Zusammenarbeit und zur Planung von Verbesserungen.
Sprint Review
Scrum Event, das auf eine Timebox von 4 Stunden oder weniger festgelegt ist, um die Entwicklungsarbeit eines Sprints abzuschließen. Es dient dem Scrum Team und den Stakeholdern dazu, das aus dem Sprint resultierende Produktinkrement zu inspizieren, die Auswirkungen der geleisteten Arbeit auf den Gesamtfortschritt in Richtung des Produktziels zu bewerten und das Product Backlog zu aktualisieren, um den Kundennutzen der nächsten Periode zu maximieren.
