-
Notifications
You must be signed in to change notification settings - Fork 0
Coaching Protocols
Scrummaster für Sprint 1 ist Fabian Dreher.
Plan für erstes Coaching: Alle Dinge klären die für den 1. Sprint erforderlich sind.
Domain model sollte im Idealfall vor dem 1. Sprint abgeschlossen werden und danach nichtmehr verändert werden.
-
Ci-Pipeline aufgesetzt
Automatischer Build Prozess ist gut, kann/sollte erweitert werden mit automatischer Erstellung und Ausführung einer .jar
An sich sollte die Pipeline funktionieren, muss jedoch nicht perfekt sein für unsere Anwendung -
Kunden- & Applikationsdatenbanken aufgesetzt, Kundendatenbank wurde mit Datensätzen befüllt\
-
Projekt Struktur Diagramm erstellt, wie hängt was zusammen
Gut als übersicht zu verwenden, Ausarbeitung beinhaltet alles was für das Projekt benötigt/implementiert werden muss -
Domain Model
Song immer in einem Album (Singles) gut
Label reicht als Attribut keine eigene Klasse
Musikteil gut (länge des song nicht unbedingt notwendig, einzlne recordings müssen nicht unterschieden werden)
Modelkomplezität ist ausreichend für unser projekt
Warum 2 Preise (LineItem, MusicMedium)? Preis bei LineItem wurde entfernt
Warum unterscheidung zwischen Account & Customer? Nicht jeder Kunde hat einen Account, bei Straßenkunden haben wir garkeine Kundendaten
Kunden, Account bis nächstes Coaching durchbesprechen/überarbeiten!
Optional Employee zur Invoice anhängen, damit nachvollziehbar ist welcher Mitarbeiter welchen Kauf getätigt hat - Wird nicht umgesetzt!
Rolle des Employees als eigene Entity anlegen anstatt als Attribut, Rechte dann direkt an Rolle hängen
Messaging/Tag teil passt gut - Kann optional auf Kunden erweiter werden -
Project Canvas
Nicht besprochen -
Userstories
Kundensuche optional, genauso wie Transaktionshistorie von Kunden - Steht jedoch in Produktvision? Wird umgesetzt!
Kaufablauf: Employee sucht nach Musikstück -> in Warenkorb hinzugefügt -> Warenkorb kann gekauft werden -> Optional hinzufügen von Kunden -> Invoice erstellen
Kundendatenbank Zugriff mittels JPA oder nur mit JDBC?
Empfehlung JDBC ist einfacher, Remote Interface für die Kundendatenbank erstellen
Wie wird auf Server deployed bzw. wie kann lokal getestet werden?
Nicht viele Docker Kentnisse, direkt auf VM aufsetzen. Es wird ausführbahre jar benötigt die dann automatisch gestartet wird.
Optional Pipeline für Client einrichten welcher heruntergeladen werden kann.
Da Interface und DTP bei Client und Server benötigt wird, bietet sich an eine shared pipeline an.
Kann Swing anstatt JavaFX verwendet werden?
Swing darf verwendet werden, Oberfläche soll java basiert sein, alternative sei .jsp, auch awt kann verwendet werden. Keine direkte Vorgaben.
Design inwiefern wichtig/benotet?
Wie es aussieht ist egal, es sollte benutzbar sein. Usability > Ausehen
Genaue Aufgaben der unterschiedlichen Rollen?
Operator kann neue messages erstellen, ansonsten gleich. Rollen nur in Datenbank hinterlegt, keine administrative Benutzeroberfläche
Vorschlag für LDAP Server unter Linux?
Apache, wird jedoch erst in 2. Sprint benötigt
OpenAPI verwenden?
Ja, REST Schnittstellen Design/Aufbau wird noch im Detail im Unterricht besprochen
UserStories die noch benötigt werden erstellen
Mit Umsetzung von RMI Schnittstelle von Kundendatenbank kann schon begonnen werden
Scrummaster für Sprint 1 ist Fabian Dreher.
Plan für zweites Coaching: User stories besprechen, priorisieren, ggf. task erstellen in coaching, Alle offenen Fragen klären welche für sprint 1 benötigt werden.
Ins ilias Wiki kann ein Link zu unserem Github wiki einfügen.
-
Product Canvas
Weitere Personas definieren (z.B. für Operator, Web-Service etc.), die ebenfalls Interesse am System haben -
Domain Model
Messages müssen nicht modelliert werden; ein Tag mit einem Themennamen reicht.
Lager (-bestand) modellieren; siehe Punkte weiter unten.
Preis von MusicMedium muss ins LineItem kopiert werden.\
User Stories (für 1. Sprint):
-
Database access
In "Music search" hinzufügen; es ist keine sinnvolle, eigenstehende User Story -
Music search
Zu Beginn nur Alben anzeigen (einfachere Variante; später möglicherweise per Filter nach Songs suchen)
Anzeigen, ob Artikel auf Lager sind (*)
Einfacher wäre, wenn man in den Ergebnissen die Artikel einzeln pro Medium anzeigt -
Product overview
Download im Laden muss nicht berücksichtigt werden (somit reicht es für das Erste auch, wenn nur das Album am Anfang gekauft werden kann)
Überlegen ob Medium direkt in Suchliste angezeigt werden soll, jedoch uns überlassen -
Add music to cart
Als einzelne Story anlegen (keine Sub-Story) -
Display and edit cart
Alles OK
(*) Lager:
- Wenn etwas ausverkauft ist, soll statt dem "Add to cart"-Button ein "Order"-Button angezeigt werden
- Bestellung wird nicht reserviert oder sonstiges, first come first serve
- der Operator bekommt eine Nachricht, in der beschrieben steht, welche und wieviele Artikel bestellt werden sollen (Operator führ Nachbestellungen durch)
- Lagerbestand wird direkt über die Datenbank erhöht
User Stories (für 2. Sprint):
- Generate invoice from shopping cart
Erster Schritt nur anonyme Kundenbestellungen
Zweiter Schritt bestehende Kunden
Dritter Schritt neue Kunden aufnehmen/anlegen (optional)
Zahlungsmethode: Bar und Kreditkarte (optional auch auf Rechnung), wobei Kreditkarten-Information nur für Onlinekauf angegeben werden muss (bei Kauf vor Ort nicht relevant)
Rechnung muss nicht als PDF ausgegeben werden; aber der Kunde muss eine Rechnungsnummer erhalten, um Artikel ggf. zurückgeben zu können
RMI:
- Customer search: Ergänzen, dass auch Nachname und E-Mail gesucht werden kann, Teilstrings und case-insensitive
CustomerDTO:
- nur relevante Attribute hinzufügen (bzw. ergänzen)
Welche Funktionen werden für die Rechnung benötigt? PDF,Email?
Die Rechnung muss nur erstellt werden in Sprint 1/2, diese muss nicht als PDF/Email exportiert werden können. Später einfach einen Menüpunkt in welchem alle Rechnungen nach Rechnungsnummer durchsucht werden können.
Lagerbestand implementieren?
Produkte mit relevanten Mediums (CD,Vinyl) haben einen Lagerbestand. Falls dieser 0 dann sollte von Verkäufern eine Bestellung eingeleitet werden können. Hierbei wird später eine Message an Operator geschickt. Lagerbestand wird direkt über Datenbank
Link vom Board (DevOps) an Feilhauer und Stadelwieser weiterleiten
Definition of Done und Definition of Ready erstellen
Mit implementation der Userstories beginnen
Music search -> Suche sollte nächsten Sprint erweitert werden um die Teilstringsuche. Acceptance criteria sehr technisch ausgedrückt, normalerweise aus usersicht
Product Overview -> Spaltenbreite automatisch anpassen, Album infos sollten nicht in eingabefelder angezeigt werden, Anzahl feld könnte auch entfernt werden, bei add to cart direkt wieder auf suche weiterleiten
Display & edit cart -> eventuell clear button um shopping cart zu leeren\
Eventuell empfielt es sich nach dem login eine facade bereit zu stellen
User loggt sich erfolgreich ein -> über factory wird eine facade bereitgestellt -> diese facade gibt an welche services er benutzen darf -> Sessionfacade\
Neue Stories:
Login + Roles -> guter umfang ldap aufsetzten auch dabei. Acceptance criteria passend
Create invoice -> acceptance criterias passen, umfang ebenfalls
Invoice Search + Overview -> Passt gut\
Im aktuellen sprint eventuell noch kundensuche umsetzten je nach geschwindigkeit. Nächster sprint geht um messaging
Email Peter: [email protected] Beiden per Email Link zu DevOps schicken.
Board gut gepflegt, stories gut durchdacht.
Login + roles
Keine falschen Entscheidungen beim LDAP server. Session Facade; Rollenabhängige Funktionen mit dem RMIController einbinden. Session Facade genau wie es geplant und vorgesehen war. Logout notwendig(?). Kein muss, kann aber gemacht werden.
Invoice + search products
Kein Kommentar, hat alles gepasst.
Returning products
Ebenfalls kein weiterer Kommentar
Customer search
Kundensuche wichtiger als Umtausch. Priorität nach oben setzen.
UI vorzeigen
Zwei clients starten und scenario testen.
Sieht gut aus und keine weiteren Anmerkungen.
Brauchen Message producer Wird nachrichten aus dem System rss feed zusammenstellen und eintragen und an destinations schicken.
Message consumer Beziehen die Nachrichten und werden die destination kontaktieren und sich die vorliegenden Nachrichten anzeigen (Wie E-Mail client). In Tabelle anzeigen.
Wie lange werden die Nachrichten aufgehoben? Solange bis sie acknowledged werden (nicht per auto acknowledge). Müssen von user bestätigt werden.
RSS-feeds könnten interessant sein. Maintenance Nachrichten sollen möglich sein. Der Operator kann gezielt auswählen in was für eine Destination die Nachricht gesendet wird. (Music genre z.B. „Neues Album! Neuer Künstler!“ für Fans eines genres). Mindestens 2 neue views. Operator view wo man die Nachrichten posted und für alle consumer die die Nachrichten (E-Mail client style) ansehen können. Abhängig von Rolle. Der Operator kann auch seine eignen Nachrichten ansehen. Bestellen läuft auch über das messaging. Bestellen kann man Produkte die nicht auf Lager sind, dafür gibt es bestellen (order). Die Anzahl an Items wird per Nachricht an den Operator gegeben. Nachrichten lesen und löschen.
Wo instanziieren wir die JRS clients? Message Producer und consumer. Man kanns im Client oder im Backend (server) machen. Wann instanziieren wir diese clients? (Diskutieren und überlegen Im laufe des Betriebs, wann sollen die neuen Nachrichten angezeigt werden? Notifications sollen existieren. Farblich kennzeichnen, vlt. kleine Fahne oder Ähnliches. Client muss ständig im Kontakt sein um Nachrichten zu erhalten.
Login + Roles
- Für die Abgabe dokumentieren, welche User welche Rollen haben
Buy product and create invoice
- Invoice ID nach Kauf anzeigen lassen (speziell zum Testen)
- Testen, wie sich das Programm verhält, wenn zwei User gleichzeitig ein Product (mit wenig Stock) kaufen -> für nächste Woche Mittwoch vorbereiten und dann vorzeigen
Music Search
- Stock direkt anzeigen lassen in der Tabelle, nicht erst in der Product Overview Seite
Order Products
- Auf jedem Product soll ein Order-Button hinterlegt werden, unabhängig davon, ob man das Product in den Warenkorb legen möchte oder nicht
- Products, die nicht verfügbar sind, können auch nicht in den Warenkorb gelegt werden
- Stock des Products wird erst nach dem Kaufen heruntergezählt; das Hinzufügen zum Warenkorb darf den Stock nicht verändern
- Sales-Person soll bestimmen können, wie viele Products bestellt werden müssen; Operator kann dann immer noch entscheiden, ob die Menge OK ist
Subscribe/Unsubscribe to Topics
- User-Settings Seite ist zwar nice-to-have, aber wird nicht benötigt; Funktionalität (Messaging, Ordering etc.) steht im Vordergrund
Sollten wir in der Lage sein, alle User Stories bereits Tage vor Sprintende fertigzustellen, könnte man weitere User Stories zu EJB hinzufügen (sollte keine große Umstellung sein)
Zwischenabgabe
- Anleitung/Anweisung mitangeben, wie man Server/Client startet (entweder auf dem Localhost oder auf der separaten Maschine)
- Messaging sollte bei der Zwischenabgabe dabei sein
CI Pipeline
- Sollte in diesem Sprint erledigt werden; eventuell bei anderen Teams nachfragen, wie dies gelöst wurde