SWEN2

a

• Product owner

  • Definiert die Features, entscheidet über das Release Datum, prioritisiert Features und akzeptiert Resultate bzw. weist sie zurück.

• Scrum Master

  • Schützt das Team gegen äussere Einflüsse, entfernt Hindernisse und ist verwantwortlich für die Durchsetzung der Scrumwerte und Praktiken

• Team

  • 5-9 Cross-Funktionale Personen welche sich selbst organisieren.

• Agiler Prozess mit Fokus auf Business Value

• Selbstorganisierte, durchmischte Teams, iterativ, häufige releases

• Produkt wird während eines Sprints designt, codiert und getestet

• Parallel anstatt linear

• Sprint planning

  • Zu Beginn jedes Sprints findet das Sprint planning statt. 

  • Product Owner präsentiert dem Team aus dem Backlog die Items mit der höchsten Priorität. Das Team alleine entscheidet dann, welche von diesen Items im nächsten Sprints fertiggestellt werden können.

  • Das Team plannt im Details die Tasks und bricht die User Stories in kleinere Tasks herunter

• Sprint review

  • Team präsentiert die Resultate des Sprints live (keine Folien). Möglichst viele Personen nehmen daran Teil

• Sprint retrospective

  • Periodische Prüfung was läuft und was nicht. 

  • Alle nehmen daran teil.

• Tägliches Standup Meeting

  • 15 Minuten. Jeder antwortet auf die drei Fragen:

    • Was hast du gestern gemacht?

    • Was willst du heute tun?

    • Ist alles auf guten Weg? (gibt es Probleme)

  • Keine Problemlösungen während des Stand up meetings

• Product backlog
  • Alle Anforderungen des Projektes. Idealerweise prioitisiert
• Sprint backlog
  • Tasks aus dem Product backlog welche innerhalb des Sprints erfüllt werden sollen.
• Burndown Charts
  • Sagt aus wie gut ein Sprint vorwärts kommt.
  • Scrum master muss auf den Chart reagieren und Tasks entfernen oder neue hinzufügen

• Mut

  • Mut an schwierigen Problemen zu arbeiten

• Fokus

  • Fokus auf die Ziele des Sprints

• Commitment

  • Persönlicher Einsatz um die Ziele zu erreichen

• Respekt

  • Gegenseitiger Respekt

• Offenheit

  • Das Scrum team und der Product Owner sind offen miteinander.

CROFM

Iterationen eines Projekts. Typische Dauer ist 2-4 Wochen. Idealerweise sollte die Dauer konstant sein. Innerhalb dieser Zeit werden Features komplett designt, entwickelt und getestet.

Kurzes Statement zur Zielformulierung eines Sprints.

Pigs sind commited, Chicken sind involved.

• Pigs:
  • Direkt am Projekt beteiligt
  • Product Owner / Scrummaster / Team / Stakeholder
• Chickens:
  • Aussenstehende
  • Haben nichts zu sagen ausser bei den Sprint reviews

Gibt übersicht über Tasks eines Sprints: Not checked out / Started / Done. Ausserdem eine Abteilung für unplanned items und für den Burndown chart

Definition wann ein Task komplett abgeschlossen ist.

Die Summe aller abgeschlossenen Items.

an Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. 

Sie müssen es verstehen!

 https://www.scrumguides.org/download.html 

Im agilen Kontext sind user stories kurze Texte welche ein Feature kommunizieren. Die Form ist folgende:

Als ein [ROLLE] möchte ich [ZIEL] damit ich [NUTZEN]

Verschiedene Rollen die Users eines Programms haben.

z.B: Admin, Moderator, User bei einem Forum

Grosse User Stories.

Eine zusammenhängende Menge von User Stories.

• Relative statt absolute Messung der Komplexität einer User Story.
• Häufig verwendete Skala ist die Fibonacci Skala.
• Sprint wird anhand der Story Points festgelegt. (z.B. 25 Punkte für ein Sprint)
• Nicht zu granular schätzen

• Fortschrittsmessung eines Teams
• Wird berechnet durch die Summer der während einer iteration umgesetzten Story Points

• Product Owner erklärt User Story und jedes Teammitglied schätzt Aufwand verdeckt
• Differenzen werden diskutiert und finaler Wert festgelegt

Die Conditions of Satisfaction steuern die Release- sowie die Iterationsplanung. Sie sind definiert aus einer Kombination des Zeitplanes, des Scopes und der Ressourcen, die eingesetzt werden können.

Date-Driven Project: Das Release-Datum ist wichtig, die Features sind verhandelbar.

Feature-Driven Project: Das Vorhandensein aller Features ist wichtiger als das genaue Release-Datum.

Zwiebelschalen prinzip. Als agiles Team agieren wir in den innersten 3 Levels: Day, Iteration und Release. àussere Ebenen sind Portfolio, Product und Strategy

Der Product Owner kann am Anfang eines Sprints user stories Priorisieren.

Aufwandschätzung. z.B: Durch die Fibonacci Skala. Am besten relativ und nicht absolut schätzen.

Da sich eine genaue Stundenschätzung als sehr unzuverlässig herausgestellt hat sollte relativ geschätz werden.

User stories sollten nach dem INVEST Schema geschrieben werden.

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Welch9e Funktionen sollen entwickelt werden?

Faktoren für die Priotisierung:

• Finanzielle Wert einer Funktion
• Kosten für die Entwicklung und Unterhalt
• Umfang und die Signifikanz des Know-How-Gewinns durch die Entwicklung
• Das Reduzieren der Risiken als Konsequenz der Umsetzung einer Funktion

https://www.youtube.com/watch?v=qCqJmNolO-k

System zum Erringen der Kundenzufriedenheit. Beschreibt den Zusammenhang zwischen dem Erreichen von Features und deren Auswirkung auf den Kunden. 

z.B. Wunsch Features / Muss Features / Begeisterungsmerkamel / Unerhebliche Merkmale / Rückweisungs Merkmale

Ein Software Architekt bnaut Systeme welche verständlich, langlebig, wartbar, funktional, performant und sicher sind.

Die Qualität einer Software Architektur hat einen Einfluss auf die allgemeine Systemeigenschaften eines mit dieser Architektur umgesetzten Systems.

Systemeigenschaften lassen sich in zwei Gruppen Aufteilen:

1. Eigenschaften die zur Laufzeit eines Systems gemessen werden können 
   • Performance
   • Sicherheit
   • Verfügbarkeit
   • Usability
   • Stabilität
2. Eigenschaften die nur indirekt gemessen werden können
   • Skalierbarkeit
   • Integrierbarkeit
   • Portabilität
   • Wartbarkeit
   • Testbarkeit
   • Wiederverwendbarkeit

• Komplexität
  • Software gehört zum komplexesten was von Menschen entwickelt wird
  • Software kann nicht ohne Verlust von Features vereinfacht werden
• Konformität
  • Schnittstelle eines Systems zu anderen Systemen variieren stark
• Changeability
  • Software muss ständig verändert werden
• Unsichtbarkeit
  • Software lässt sich nicht einfach visualisieren

• Modularität
  • Komponeten eines Systems lassen sich leiecht austauschen
• Portabilität
  • Software sollen in verschiedenen Umgebungen lauffähig sein
• Changeability
  • Ein System soll leicht veränderbar sein
• Conceptual Integrity
  • Diejenigen Teiel eines Systems, die ähnliche Funktionen beinhalten, sollten auch ähnlich gestalt werden.
• intellectual Control
  • Softwaredesign sollte von den Zuständig komplett verstanden werden
• Buildability
  • Ein Software Design muss ein Zielsystem so spezifizieren, dass es von einem gegebenen Team in einer gegeben Zeit realisiert werden kann
• Kopplung und Kohäsion
• Design for change

Die organisierte Struktur eines Systems oder einer Komponente. z.B. MEAN Stack, oder Spring Framework etc

s