Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

test > Software Engineering 2 - 2 > Flashcards

Software Engineering 2 - 2 Flashcards

1
Q

test

A

test

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Warum ist die Dokumentation beim Software engeneering wichtig?

A

Software-Entwickeln ist Dokumentation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Allgemeines zu “Dokumentation”

A
  • Dokumentation gilt als ewiges Sorgenkind und ist eine Daueraufgabe
  • Nachträgliche Dokumentation ist eine unzureichende Notlösung (​Denn Info ist vergessen)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Begriffe der Dokumentation

A
  • Integrierte Dokumenttion

(enthaltene Komentare, Bezeichner des Layouts)

  • Separate Dokumentation

(Teil der Software, die nicht im Programm enthalten sind)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Ist die Form der Dokumente festgelegt (bei der Dokumentation)?

A

Nein, nur stabilität ist geforgert!

(Es gibt keine Dokumentation im Kopf)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Integrierte Dokumentation

A
  • Ist leichter zu bearbeiten und kann eher nachgeführt werden
  • Reicht in keinem Falle aus!
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Integrierte Dokumentation (Was muss unbedingt vorher entstehen?)

A
  • Glossar
  • Spezifikation (Wireframes, Use Cases, Datenmodell,…)
  • Architektur-Entwurf
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Integrierte Dokumentation (Warum müssen Glossar, Spezifikationen und Architektur-Etwurft´vorher entstehen?)

A
  • Sie können nicht in Code-Komponenten abgelegt werden

(Die Projektdokumentation ganz zu schweigen)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Separate Dokumentation (Ist sie gefährdet?)

A
  • Ist grundsätzlich gefährtdet und kann nur unter gewissen Bedingungen funktionieren?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Seperate Dokumentation kann nur funktionieren wenn?

A
  1. Anforderung an Dokumente müssen klar sein
  2. Verantwortlichkeiten klären
    • (Wer erstellt, prüft, gibt frei)
  3. Dokumentaion soll hoch bewertet und anerkannt sein
  4. Inhaltsverzeichnis (Struktur) muss von Anfang an klar sein
  5. Werkzeugunterstützung muss verfügbar sein
  6. Prüfung der Dokumente nach Ändereung/Fertigstellung
  7. Dokumente werden effektiver Konfigurationsverwaltung unterstellt
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Ziele einer guten Dokumentation?

A
  • Wissenstransfer und Kommunikation zwischen Auftraggeber- und Nehmer
  • Dokumentation bewahrt das Wissen über Programm, Entwicklung, Wartung
  • Dokumentation erlaubt systematische Prüfung (Review) und belegt diese (revisionsfest)
  • Dokumentation spiegelt Projektfortschritt wider (Liegt Test vor?-> nachgucken)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Nachteile einer Dokumentation?

A
  • Nutzen ist verteilt und fern
  • Kosten treten sofort sichtbar auf
  • Oft wird daher an der Doku gespart
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Nutzen von Dokumentation

A
  • Vermeiden (,rasches finden) von Fehlern
  • Software kann einfacher erweitert & wiederverwendet werden
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Faustformeln für die Kosten

A
  • Produktivität im Ø –> 4 Seiten pro Tag
  • Diese Arbeit ist 1000 € Wert
  • 40 Seiten Starkes Dokument 40.000€
  • (Produktivität hier eher hoch geschätzt)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Taxonomie (Alle Dokumente gehören zu einer der 4 Kategorien –> Welche sind dies??)

A
  1. Systemdokumentation
  2. Projektdokumentation
  3. Qualitätsdokumentation
  4. Prozessdokumentation

(Möglicher Wiki-Aufbau)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Taxonomie (Welche Dokumente fallen unter den Bereich Systemdokumentation?)

A

Dokumente die für die Konstruktion/ Betrieb/ Wartung der Software benötigt werden. (unterscheidung techn./fachl.)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Taxonomie (Welche Dokumente fallen unter den Bereich Projektdokumentation?)

A
  • Alle Dokumente die benötigt werden, um das Entwicklungsprojekt zu planen/zu leiten/abzuschließen.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Taxonomie (Welche Dokumente fallen unter den Bereich Qualitätsdokumentation?)

A

Alle Dokumente in denen die Maßnahmen zur analytischen Qualitätssicherung dokumentiert sind.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Taxonomie (Was ist Prozessdokumentation?)

A
  • Beschreibt den Entwicklungsprozess und seine konkrete Umsetzung im Projekt.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Kategorien im Überblick

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Was umfasst die Benutzungsdokumentation?

A
  • Dokumentiert wie sie installiert, betrieben und bedient wird.

(Notwending, damit Software eingesetzt werden kann)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Gib Beispiele für Benutzungsdokumentation.

A
  1. Benutzungshandbuch
  2. Tutorial
  3. Installationshandbuch
  4. Kontextsensitive Hilfe
  5. Onlineinformationen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

“Adressaten der Dokumente”

Wie du weißt, werden Dokumente für verschiedene Adressaten erstellt, die sehr unterschiedliche Information benötigen.

Nenne die 4 vers. Adressaten.

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Welchen Zweck hat die Dokumentation für den Kunden? Und Welche Dokumente bekommt er?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Welchen Zweck hat die Dokumentation für den Admin? Und Welche Dokumente bekommt er?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Welchen Zweck hat die Dokumentation für den unerfahrenen Anwender? Und Welche Dokumente bekommt er?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Welchen Zweck hat die Dokumentation für den erfahrenen Anwender? Und Welche Dokumente bekommt er?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Nenne 3 Folgen schlechter Dokumentation

A
  1. Wartungsingenieure arbeiten als Archäologen
  2. Grundlagen für die Handbücher fehlen
  3. Retrospektive Analysen sind nicht möglich (Keine Möglichkeit für Organisation aus Projekt zu lernen)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Warum gehört Dokumentation in der Praxis meist zu den Problemzonen des Software-Engeneerings?

A
  • Software-Entwickler haben dies nicht gelernt (Weder in Ausbildung noch in Praxis)
  • Priorität 1, 2 und 3 ist einhaltung des Liefertermins
    • FOLGE: –> Zeit für Doku fehlt
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Sollte man automatisch generierte Dokumentationen nutzten?

A

Eher nicht denn:

  • Keine Abstraktion
  • Stellt Code direkt dar
    • Lieber anders herum
  • Keine Gedanken vorher gemacht

(Wenn man automatisch generierte Dokumentation nutzt dann vielleicht über arc42.de)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Top 10 Risiken nach Boehm

A
  1. Personalprobleme (mangelnde Qualifikation durch Neueinstellung, Umschichtung, mangelhafte Fortbildung)
  2. Unrealistische Pläne/Budgets (Z.B durch Unterprisangebote wegen hohem Wettbewerbsdruck)
  3. Entwickeln der falschen Funktionen & Eigenschaften (Bsp.: Onlineshop gemacht mit schlechter Kundenanalyse)
  4. Entwickeln der falschen Benutzungsschnittstelle (z.B. komplizierte Oberfläche)
  5. “Goldverzierungen” (z.B graphisch verzierte Oberfläche–> Schnickschnack)
  6. Ständiger Wechsel der Anforderungen (Z.B. durch unzureichend ausgearbeitetes Lastenheft,…)
  7. Versagen externer Komponenten (Z.B. Fehler einer zugelieferten Komponente)
  8. Versagen externer Aufträge (Z.B. erxterner Lieferant für Datenbanklösung geht in Konkurs)
  9. Zu geringe Leistungen (Z.B. Überlastung von Servern)
  10. Fehleinschätzung des Standes der Technik (Z.B. Performance neu entwickelter Datenbanktechnik wird überschätzt)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Das Wasserfallmodell

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Die Probleme des Wasserfallmodells

A
  1. Unklare Zielvorstellungen/Anforderungen des Kunden
  2. Häufige Änderungen Während des Projekts (Change Requests)
  3. Arbeitsprozesse außerhalb des kurzfristigen Planungshorizontes bergen zu viele Unsicherheiten
  4. Zu viele abgegrenzte Aktivitäten/Teams (“Teilprodukte über die Mauer werfen”)
  5. Tests des Produktes am Ende ist viel zu spät
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Der traditionelle Ansatz

A
  • Prozessmodelle wie (Wasserfallmodell, V-Modell (später), Unternehmenseigene Modelle)
  • Anforderungen erheben
  • Architektur erstellen
  • Dokumente verfassen
  • Planung, Verträge
35
Q

Kritik am traditionellen Ansatz

A
  • Software-Bürokratie
  • Kunde zu spät eingebunden
  • Vertrags- statt Kundenorientierung
  • Kein Spaß
  • Träge und teuer

(Begründung dieser Kritik nicht wissenschaftlich sondern begründet durch Beobachtung, “gesunder Menschenverstand”)

36
Q

Agiler Ansatz

A
  • Geisteshaltung durch agiles Manifest populär geworden
  • Umgesetz durch “agile Methoden”
37
Q

Werte des Agilen Manifests ( 4 Stück)

A
  • Individuals and Interactions (over processes and tools)
  • Working Software (over comprehensive documentation)
  • Customer collaboration (over contact negotiation)
  • Responding to change (over following a plan)
38
Q

Agiles Manifest - Prinzipien

A

Kunden zufriedenstellen und Software ausliefern

Auf änderungswünsche des Kunden zu jeder Zeit eingehen

Software regelmäßig abfliefern

Leute aus Buiseness und Entwicklung müssen zusammenarbeiten

Gutes Arbeitsklima schaffen und Unterstützung geben

Face to Face conversation zum Infoweitergeben

Funktionierende Software definiert Entwicklungsfortschritt

Agile Prozesse –> Gut für Entwicklung, sollen in einer konstanten Geschwindigkeit geschehen

Wertlegen auf technische Perfektion

Einfachheit

Selbst-organisierte teams erzielen die Besten Ergebnisse

Wiederholende Selbstreflektion des Teams

39
Q

Agile ist ein Oberbrgriff für Methoden die dessen Werten und Prinzipien folgen, z.B. : (2 Beispiele)

A
  • XP - Extreme Programming → Fokus auf teaminterne Engeneering-Praktiken (“Von Programierern für Programierer)
  • SCRUM - Framework mit Fokus auf Struktur und Kommunikation (“Management”)
40
Q

Agile Methoden (Viele techniken und Prinzipien sind nicht neu, nämlich z.B.:)

A

Iterationen → Boehms’ Spiralmodell

Story Points → Function Points

Continious Integration → “Daily Build” bei Microsoft (1995)

Retrospective → Aus CCMI, KAIZEN (Kontinuierliche Verbesserung)

41
Q

Wann wurden die meisten agilen Methoden entwickelt?

A
  • In den 80/90ern
42
Q

Voraussetzungen für den agilen Ansatz

A
  • Verantwortlich arbeiten können nur hochqualifizierte Teams
  • Kleine Teams (bis 10 Pers) (Sonst zu viel Kommunikation)
  • Gemeinsamer Raum für alle Teammitglieder!
  • Wir brauchen keine: Star-Architekten, Gurus, Alleinarbeiter
  • Management-Akzeptanz bei Auftragnehmer und -geber
43
Q

Agile Softwareentwicklung - Gemeinsame Kernmerkmale

(8 Stück)

A

Kurze Zyklen bis zur Auslieferung

  • Nach ca. 1 Monat ausliefern
  • Realease abnehmen/bewerten lassen von Kunden

Evolutionäre Entwicklung

  • Keine große Architektur sondern mit klein & angemessen beginnen und dann refactoring

Testgetriebene Entwicklung

  • Automatisierte Tests vor dem Code schreiben
  • Testen aller features (User-Stories statt tradit. Anforderungen)

Teamarbeit

  • Pair Programming, Collective Code Ownership

Dokumentation verliert an Wichtigkeit

  • Nicht “keine Dokumentation”!
  • Kommunikation ersetzt Dokumentation

Kunde als Teil des Teams

  • ​Spart Zeit
  • Kunde bestimmt Umfang des Wertesnach seinen Prioritäten

Vertrauen

  • Kunde hat vertrauen in Team/Vorgehen
  • Statt Festpreis variabler Preis (oder variabler Umfang)

Änderungen Willkommen

  • Kein Change-Request-Verfahren, sonder Änderungen für neues Release immer möglich
44
Q
A
45
Q

Wofür steht Scrum wörtlich und was ist dessen Annahme?

A
  • Scrum = “Gedränge” (Aus dem Rugby)

Annahme

  • Entwicklungsprozesse sind so komplex, dass sie sich kaum vorausplanen lassen
46
Q

Idee hinter SCRUM

A

Es gibt groben Ramen vor

  • Darin organiesiert Team sich selbst, Produktivität soll dadurch steigen

Team übernimmt gemeinsam Verantwortung für Tätigkeiten

Keine Kontrolle von “Oben”

Keine konkreten Use-Cases und Entwürfe werden vorgegeben

47
Q

Srcum im Überblick

  1. Was ist Scrum
  2. Rollen
  3. Product Backlog & Sprint
A

Ist ein agiles Managementframework zur Entwicklung von Software mit wenigen klar definierten Regeln

Anwndung von 3 Rollen

  • Product owner
  • Team
  • Scrum Master

Das Product Backlog enthält priorisierte Anforderungen

Erstellung von Produktinkrementen innerhalb kurzer Arbeitszyklen, genannt Sprint

  • ​Jedes Produktinkrement ist getestet und dokumentiert
  • Jeder Sprint beinhaltet Analyse, Design, Implementierung, Test, Bugfixing, Dokumentation
48
Q

Verkörpert Scrum die Werte des agilen Manifests?

A

Ja, als agiles Framework tut es das.

49
Q

Scrum als Wundermittel?

A

Scrum fördert die enge zusammenarbeit ist aber kein Wundermittel!

Das erfolgreiche Anwenden ist ein Lernprozess (dieser braucht Zeit und Geduld)

  • Oft sind die ersten Sprints (Iterationen) schwierig
50
Q

Beschreibe den Scrumprozess

Nenne die Stationen des Scrumprozess

A
51
Q

Beschreibe den Scrum Prozess an dem Folgenden Bild

A

Weiter gehts, ich hab dich lieb!

52
Q

Artefakt - Produckt Backlog

A

Enthält Features/Anforderungen des zu entwickelnden Produktes

  • Grundlage (erster Fassung) bilden Lastenheft, User-Stories, Interviews, Workshops
  • Umfasst alle Funktionen die Kunde wünscht
  • Vor jedem Sprint neu bewertet/priorisiert
  • Aber auch Bugs, technische Zwischenaufgaben,..
53
Q

Produckt Baglock

“hoch priorisierte Features für den nächsten Sprint”:

“niedrig priorisiete Features”:

A

hoch prioris.

  • stehen am Anfang
  • werden im Aufwand geschätzt (von ENtwicklern)
  • in Sprint Backlog übernommen und in Unteraufgaben zerlegt

niedrig prioris.

  • nicht detailiert beschrieben
  • Zeit wird für wesentlichen Elemente verwendet
54
Q

Produckt Baglog

Faktoren die über priorisierung Entscheiden:

A

Vertrautheit mit der fachlichen Domäne?

Homogene bearbeitung der Geschäftsprozesse/Anwendungsfälle von vers. Benutzern?

Fachliche Varianten, Ausnahmen zu berücksichtigen?

Ist Ablauf neu/verändert?

Wie viele vers. personen als Anforderungsgeber sind zu beachten?

Gibt es Risiko durch zu wenig Requirements-Engeneering in verzögerung, mehrkosten zu kommen?

Folgen bei vergessen von fachlichen Varianten/Details

55
Q

Sprint, was ist das?

(Gibt es während eines Sprints Kundeninteraktion)

A

Ist Iteration in SRCRUM

Hat fixe Längen (2 Wochen, 4 Wochen)

Ergebnis von Sprint soll lauffähige Software sein

Wird Kunden am Sprintende zur Evaluation präsentiert

Während eines Sprints ist keine Kundeninteraktion (Product Owner) erlaubt

  • Konsequenz: Features/Anforderungen währen Sprint fixiert
  • Keine Störung von “außen”
56
Q

Artefakt - Sprint Backlog

(Was beinhaltet Sprint Backlog)

A

Enthält (technischen) Aufgaben die notwendig sind um das Sprint Ziels zu erfüllen

Charakterisierung: “Aufgabe”

  • eine nicht länger als 16 Std dauern
  • längere in Teilaufgaben zerlegen
  • bei Planung Arbeitsgeschwindigkeit (Team) bdenken
  • Teams aktualisieren Aufwände während Sprint
  • Jedes Teammitglied kann Pakete:
    • ergänzen, ändern, löschen
57
Q

Rollen im Scrum: “Product Owner”

A

Representiert Endkundenbedürfnisse

  • (traditionell machte dies der Prokejt manager)

Für erreichung der wirtschaftl. Ziele verantwortlich

  • Steuert diese durch priorisierte Produckt Backlog und den Release Plan

Erstellt Produktkonzept und das Product Backlog

  • Dies wird kontinuierlich bearbeitet
  • Neue Anforderungen kommen hinzu, werden neu priorisiert
  • hochpriorisierte Anforderungen werden in neue verfeinert
  • enge Kommunikation mit Kunden

Erstellt/Aktualisiert Releaseplan

⇒ Wichtige Projektmanagementaufgaben führt er also selbst durch!

58
Q

Rollen im Scrum: “Team”

  • Was macht das Team?
A

Das Team führt die Arbeiten zur Produkterweiterung aus

Team entscheidet selbst, wie viele Anforderungen es im nächsten Sprint in Producktinkrekremente umwandeln kann.

  • 5-9 Mitarbeiter
  • Team entscheidet über Arbeitschritte/Organisation
    • (Entgegen trationellen Management)
59
Q

Rollen im Scrum: “Scrum Master”

  • Was macht der Scrum Master? (4 Punkte)
A

Ist Coach → hilft Team Scrum richtig einzusetzen

Überwacht einhaltung der Scrum Regeln

Moderiert Meetings

Sollte versuchen sich schnell überflüssig zu machen

60
Q

Scrum -Schätzworkshops

Was ist das?

A
  • Teilnehmer, Team, Product Owner & Srcum Master
  • Geht 2 Std lang
  • Soll alle Einträge des Product Backlog abschätzen
  • Ist bei Veränderungen während des Sprints nötig
  • Team schätzt gemeinsam ab (durch Diskursionen)
61
Q

Scrum - Aufwandsschätzung mit Product Backlog

A
  • Aufwand ist relativ zu anderen Aufwenden abschätzbar
  • Beginn mit klarer u. kleiner Anforderung
  • Anhand kleiner Anforderungen große abschätzen
  • Gleichgroße Anforderungen gruppieren
  • Product Backlog bei Disskursion benutzen
  • Schätzungen möglichst realistisch
    • genau - ist unmöglich
62
Q

Scrum - “Sprint-Planung”

Sprint Planungstreffen Teil 1

&

Sprint Planungstreffen Teil 2

A

Sprint Planungstreffen Teil 1

  • Product Owner erklärt Team die Anforderungen an Backlog Einträge
  • Einigung über “Sprint-Ziel” (Basis für Abnahme)

Sprint Planungstreffen Teil 2

  • Eigenverantwortliche Planung durch Team
  • Zerlegung der Backlog-Einträge in Arbeitspakete (AP)
  • Verteilung der Aufgaben an Teammitglieder
  • Erstellung des Sprint Backlog (+Schätzung der AP in std)
  • Schätzung im BacklogProduct ergänzen/anpassen
63
Q

Scrum - Projektfortschrittverfolgung

  • Berichterstattung
  • Burndown-Bericht
  • Aufwandsschätzung
A

Berichterstattung in Scrum schafft Transparenz

  • Verzögerungen/Fortschritt schnell einsehbar

Burndown-Bericht

  • beschreibt aktuellen Projektfortschritt
  • führt Summe aller Aufwände im Spring-Backlog auf
  • Zeigt Änderungen der Aufwände an
  • Führt Summe aller Aufwände im Product Backlog am Ende jedes Sprints auf (zeigt Änderungen über Sprint-Grenzen hinweg auf)

Burndownchart

  • Verfolgung der Restaufwände für Gesamtprojekt

Aufwandsschätzung (Product Backlog) in Jira

  • Mittels Comulative Flow Diagramm
64
Q

Scrum - Velocity

Was ist Velocity?

A

Velocity = Entwicklungsgeschwindigkeit (in Scrum)

Für bessere Planung Einschätzung der Velocity

Velocity = Summe aller Aufwände der von Sprintende vom Product Owner abgenommenen Arbeitsergebnisse

  • Unfertige Ergebnisse (99,9% fertig) werden im Scrum nie abgenommen –> Es gibt daher keine “Anteilspunkte” für teilhafte Ergebnisse
65
Q

Scrum - Velocity (Entwicklungsgeschwindigkeit)

  • Wie können wir die Entwicklungsgeschwindigkeit bestimmen?
A
  • Erfahrungen aus vorhergehenden/ähnlichen Projekten
  • 2-3 Sprints durchführen und den erzielten Mittelwert nehmen
66
Q

Scrum - Velocity ⇒ “DoD”

  • Wofür steht Dod?
A

DoD = Definition of Done

  • Ist das Fertigstellungskriterium eines Product Backlog Eintrags
  • Variiert von Scrum zu Scrum Team
  • Sollte innerhalb eines Scrum Teams konsequent sein
67
Q

Scrum - Velocity - Entwicklungsgeschwindigkeit berechnen

  • Wie berechnet man die Entwicklungsgeschwindigkeit?
A
  • Punkte verrechnen
68
Q

Scrum - Velocity im Verlauf

“Häuprigkeiten”

A
69
Q

Scrum - Daily Scrum / Statusrunde

  • “Daily Scrum/Statusrunde/Daily stand up meeting” was ist das?
A

Statusmeeting des Teams (max. 15 min im Stehen)

Dient Informationsaustausch der Teammitglieder

Jedes Teammitglied beantwortet:

  • Welche Arbeitspakete hab ich seit letztem Meetig fertiggestellt
  • Welche Arbeitspakete wirst du bis zum nächsten Meetig bearbeiten
  • Gibt es behindernde Probleme bei deinen Aufgaben

Hindernisse nimmt der Scrum Master ins Impediment Backlog auf und beseitigt sie

70
Q

Scrum - Sprint Review

  • Sprint Review, was ist das und wer führt es durch?
A

Sprint Ergebnis wird einem Review unterzogen

  • Durch Team und Kunden
  • Z.B. Präsentation der laufenden Software

Was wird gemacht?:

  • Kunde prüft ob seine Anforderung erfüllt sind
  • Eventuelle Änderungen werden im Product Backlog dokumentiert
71
Q

Scrum - Sprint Retrospective

  • Was wird hiert gemacht?
A
  • Betrachtung der zurückliegenden Sprintphase
  • “Was war gut”/ “was hat Verbesserungspotential”?
    • Eventuelle Anpassung des Impediment Backlogs
    • Eventuelle Anpassung des Product Backlogs
  • 15-30 Min
72
Q

Gib einen Überblick über das Scrum verfahren.

A
73
Q

Empfehlung für Scrum-Ablauf

A
74
Q

Scrum und XP (- Extreme Programming)

A
75
Q

“Lean”

Was ist das

Vergleich mit Agile

Lean Software Developement Prinzipien

A

Westlicher Begriff für das TPS (“Toyota Production System”)

“Lean” stammt aus Produktion

“Agile” stammt aus Softwareentwicklung

Lean Software Developement Prinzipien

  • Müll beseitigen
  • Besser werden
  • Enscheiden so spät wie möglich
  • Liefern so schnell wie möglich
  • Das Team stärken
  • Qualität einbauen
  • Alles optimieren
76
Q

“Agile vs. Lean”

A

Agile: Fokus auf Produkt

  • “Agile” stammt aus Softwareentwicklung
  • Wollen auf veränderte Anforderungen reagieren können, daher bei ihnen sehr flexible Vorhergehensweise

Lean: Fokus auf Prozess

  • “Lean” stammt aus Produktion
  • Kombination aus Fokussierung auf beteiligte Menschen & Anspruch der stetigen Verbesserung
  • Wollen Prozesse standardisieren & vereinfachen
    • So lange bis nur noch die Elemente da sind, die wesentlich für Wertschöpfung sind
77
Q

Lean, Agile, Scrum, XP, Kanban,…

A
78
Q

Bewertung Agiler Softwareentwicklung (Nach Meyer)

A
  • Bertrant Meyer
    • Bewertung agile Entwicklungsmethodik aus entspannter wissenschaftlicher Sichtweise
    • Er deffiniert agile Methoden
    • Unterscheidet in
      • The “Good”
      • The “Bad”
      • The “Ugly”
79
Q

Bewertung Agiler Softwareentwicklung (Nach Meyer)

“The Brilliant”

A
80
Q

Bewertung Agiler Softwareentwicklung (Nach Meyer)

“The Good”

A

Anmerkung: Immer auch die anderen “alten” Tests durchführen

81
Q

Bewertung Agiler Softwareentwicklung (Nach Meyer)

“The Indifferent”

A
  • Pair Programming
    • = 2 gleich kompetente Programmierer arbeiten gleichzeitig (Dies ist manchmal sinnvoll)
  • Ein “Open-space”-Büro
  • Selbstorganisierende Teams
    • Bedenke (Fast kein Orchester kann ohne Dirigent arbeiten)
  • Verträgliche Arbeitszeiten einhalten (:/ Deadlines)
  • Erstellung von minimaler Funktionalität
  • Planning game, planning poker (Aufwände schätzen)
  • Jeder im Team kann alles (Anmerkung: unrealistisch)
82
Q

Bewertung Agiler Softwareentwicklung (Nach Meyer)

“The Ugly”

A
  • Ablehnung traditioneller Projektleitungsaufgaben
    • Geht für meisten Teams nicht
    • Niemand will “Hilfs- Projektleiter sein”
  • Ablehnung von Hilfs-/Zwischenprodukten/ nicht auslieferbaren Produktteilen
  • Ablehnunf von Softwarearchitekturen
  • Ablehnung von Wiederverwendbarkeit als Entwicklungsziel
  • Kunde im Team
    • (In Praxis Kunde schwierig) (Product-Owner gut)
83
Q

Plattitüden im Agilen Manifest

A

Reaktion auf Plattitüden –> Anmerkung

Anmerkung

  • kritisch mit neuen Vorhergehensweisen umgehen
84
Q

“Agile & Lean” - Fazit

A
  • Entwickeln sie Software systematisch und verbessern sie stetig
  • Benutzen sie projektspezifische, gut angepasste Methoden (Manchmal Agil, manchmal nicht
  • Kommunizieren sie
  • Softwareentwicklung ist nicht rein technisch
  • Bleiben sie am Ball den SE und Informatik entwickeln sich stetig
  • Keine unnötige Laberei
  • Kein certified Geldverfdiener-Master
  • Keine Religion statt Wissenschaft

Anmerkung

  • Zertifikate heißen nicht dass du gut bist
  • Sind aber gut für den Lebenslauf

test (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions