Git ist eine moderne plattformübergreifende freie Sourcecodeverwaltungs Software. Git ist sehr flexible und kann auch Offline verwendet werden – lokal auf dem Rechner.
Der Name „Git“ bedeutet in der britischen Umgangssprache so viel wie „Blödmann“. Linus Torvalds erklärte seine Wahl des ungewöhnlichen Namens mit einem Witz sowie damit, dass das Wort praktikabel und in der Softwarewelt noch weitgehend unbenutzt war:
“I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘Git’.”
Remove final attribute from the class to inheriting
Change the visibility from the instance attribute to protected
To inheriting a class do:
CLASS <name> DEFINITION
INHERITING FROM <class_to_inheriting_from>.
Abstract Class
Define a base class as abstract
Sonstiges
lv_text = TEXT-t01 && | | && lv_text.
Space character in a text
&& | | &&
TEXT-<xxx>
Textsymbol
*
Comment out a line
CLASS <name> DEFINITION ENDCLASS.
Interface
CLASS <name> IMPLEMENTATION ENDCLASS.
Class object
CLASS IMPLEMENTATION INHERITING FROM <class_name>. ENDCLASS.
Inheriting
METHODES: show_details REDEFINITION.
Overwriting an inheriting methode
super->show_details( ).
Call the methode in the superclass
TRY. lcl_start=>run ( ) . CATCH cx_root INTO lcl_start=>mo_error. ENDTRY.
Unhandled exceptions cause short dumps
1
Paket
2
Unterpaket
3
Globale Klassen eines Unterpaketes
4
Programme (Reports) eines Unterpaketes
5
Program (Report) mit Klassen, Felder usw.
Prüfen, aktivieren und ausführen
ABAP Unit / Test Classes
CLASS lcl_test DEFINITION
FOR TESTING
DURATION SHORT
RISK LEVEL harmless.
PRIVATE SECTION.
DATA: lo_test TYPE REF TO zcl_main "class under test
METHODES: setup, teardown "Fixture methodes
METHODES: test_method1 FOR TESTING "Test method
ENDCLASS.
FOR TESTING
mark as an unit test class
DURATION
SHORT MEDIUM LONG
RISK LEVEL
HARMLESS (no changes to data or settings) DANGEROUS (date may changed) CRITICAL (data or settings may be changed)
Das Product Backlog ist der Schreibtisch, das Product Owners, welches immer aktuell und sauber geführt werden muss. Es ist eine priorisierte Liste mit Anforderungen / Requirements. Es besteht aus den User Stories, welche eine Anforderung in einem Satz erklären, den Akzeptanzkriterien, Schätzung der Komplexität und den Epics (Grosse Anforderungen, welche noch in User Stories aufgeteilt werden müssen)
DEEP- Kriterien
Detailed Appropriately (angemessen detailiert)
Estimated (geschätzt)
Emergent (mehr als eine Summe der Einzelteile)
Prioritized (priorisiert)
User Stories
INVEST-Kriterien:
Independent (unabhängig)
Negitiable (verhandelbar – veränderbar bis in Sprint Backlog aufgenommen)
Valueable (werthaltig)
Estimable (schätzbar)
Small (klein genug)
Testable (testbar)
Akzeptanzkriterien
Was muss sonst noch beachtet werden (Filterung, Sortierung…)
Gemeinsame Vorstellung / Vision erhalten des Produktes
Wann und wo werden die Stakeholder eingebunden
Risiken, ungefähre Dauer und Kosten
Teamspezifische Aspekte
Arbeitszeiten, Werte, was ist die Projektsprache
Erstellung der
Definition of Done (Wann ist eine Anforderunge Fertig?)
Definition of Ready (Wie muss der Product Owner eine Anforderung beschreiben?)
Organisationsspezifische Aspekte
Schlüsseltermine
Informationen rund um das Projekt
Zusammenkommen mit Stakeholdern
Sprint Planning
Dauer von 1 bis 4 Std.
Formulierung des Sprint-Ziels
Was wird in diesem Sprint Umgesetzt?
Wie viele User Stories können im Sprint umgesetzt werden
Übernehmen ins Sprint Backlog
Benötigte Vorarbeiten:
Vorbereitetes Product Backlog
Vorstellung der Anforderungen (User Stories) durch den Product Owner
Erstellung des Sprint Backlogs
Daily Scrum Meeting
Ist ein Event für das Development Team. Product Owner und Scrum Master sind nicht zwingend erforderlich. Die Praxis zeigt aber, dass es doch empfehlends Wert ist.
Time Box von 15 min.
Jeder beantwortet diese Fragen:
Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
Sehe ich irgendwelche Hindernisse (Impediments), die mich oder das Entwicklungsteam vom erreichen des Ziels abhalten?
Sprint Review
Am Ende des Sprints stellt das Entwicklungsteam die umgesetzten Anforderungen vor. Der Product Owner nimmt die User Stories ab. Der Scrum Master organisiert und moderiert (bei Unstimmigkeiten Entwicklungsteam – Product Owner) das Review.
Wiederholung des Sprint-Ziels
Vorstellung der neu gewonnen Funktionalitäten
Vorstellung der umgesetzten User Stories
Abnahme durch den Product Owner
Bei Abnahme: Anforderung gilt als umgesetzt
Bei Ablehnung durch eine der Begründungen:
Akzeptanzkriterium nicht erfült
Punkt der Definition of Done verletzt
Sprint Retrospektive
Für den Scrum Master ist sie das Herzstück des Frameworks. Im Fokus steht hier die Zusammenarbeit im Team und soll aufzeigen, was noch optimiert oder verbessert werden kann. Es sollen nur Personen aus dem Scrum Team teilnehmen.
Wie gut haben wir Scrum als Framework bereits adaptiert?
Wie läuft unsere Zusammenarbeit?
Was hinder uns, Scrum noch besser zu nutzen?
Folgende Regeln sind Zwingend zu befolgen:
Egal was wir heute erkennen, wir sind fest davon überzeugt, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.
Norman Kerth, 2001
Was auch immer in Vegas passiert, bleibt in Vegas.
Vegas-Regel
Sprint
Für den Scrum Master ist die Impediment-Liste das zentrale Artefakt für die allgemeine Organisation des Sprints
Der Scrum Master ist für einen reibungslosen Verlauf des Sprints verantwortlich
Der Product Owner sollte für den Rest des Teams zuallersrt als Ansprechpartner immer zu Verfügung stehen
Das Development Team sollte sich zuallererst während des Sprints Komplett aus sich selbst und sein Sprint Backlog konzentrieren
Dem Product Owner gehört das Produkt, an dem gearbeitet wird. Er trägt die komplette Verantwortung hinter dem Wert des Produktes. Er ist die Schnittstelle zwischen dem Scrum Team und allen anderen Stakeholdern.
Wichtige Punkte:
Mit welchen Anforderungen kann ich den Wert des Produktes für alle Anwender maximieren?
Wann wird das Produkt / Inkrement ausgeliefert?
Scrum Master
Scrum Master ist ein Vorbild beim Scrum Prozess, er ist quasi der Motor des Scrum Prozesses.
Scrum Experte – Muss immer auf dem neusten Stand sein
Change Agent – Bei Einführung von Scrum trägt er eine wichtig Rolle mit
Facilitator – Kümmert sich um alle Probleme im Team und löst diese
Prozesswächter – Überwacht den Prozess / Rahmen – Events müssen korrekt durchgeführt werden
Coach – Moderiert, führt Gespräche
Development Team
Ist eigenverantwortlich für die Umsetzung des vom Product Owner gesetzten Anforderungen. Es muss für die Umsetzung alle benötigten Kompetenzen besitzen – es muss crossfunktional sein.
