Autor*in »Taras Zaika«

Alle Artefakte

Nachfolgend sind alle von Taras Zaika (mit-)erstellten Artefakte aufgelistet. Wenn es Co-Autor*innen gibt, sind diese ebenfalls aufgelistet.

	ID	Artefact	Ko-Autor(en)
	FR-16	Auswahl der Aufgaben für Überprüfung
	FR-45	Obergrenze für Feedback
	FR-57	UML Editor
	FR-58	UMLet Integration
	FR-76	Übersicht über Meilensteinergebnisse
	GO-24	Entlastung bei der Arbeit	Pascal Schorde
	GO-15	Das Erstellen von Aufgaben erleichtern
	GO-36	Korrektur von Aufgaben erleichtern
	INT-11	Interview mit »Fabian Krampe« (12.05.2021)	Henning Buhl
	PRS-15	Thomas Schmidt
	RV-26	useCase
	RV-30	useCaseDiagram
	SCN-16	Übersicht und zusammenfassung von Ergebnissen von allen Studenten
	ST-8	Studierende (Gruppe)
	STR-3	Informatik-Studierende*r	Tempoklaus und Pascal Schorde
	SYC-4	Discord	Alexander Kosmehl und Kay Ruck
	SYC-15	Meilenstein
	SYC-19	Pruefungsordnung
	UC-8	Feedback-Obergrenze setzen
	UCD-9	Use-Case-Diagramm zu funktionaler Anforderung »Obergrenze für Feedback«
	US-16	Feedback-Obergrenze erreicht
	US-32	Warnung über Feedback-Obergrenze
	US-18	Feedback-Obergrenze überwachen
	US-17	Feedback-Obergrenze setzen
	WS-1	Sammeln von Ideen für Weiterentwicklung des DiveKit aus Studenten-Sicht mit 6-3-5 Methode	Fabian Grüterich, Nathalie Giessler, und John Bryan Spieker

0 Fehlermeldungen für Taras Zaika

Yeehaw, keine Fehlermeldungen!

2 Warnungen für Taras Zaika

	Warnungen	Artefakt
	w534: Gibt es kein Interview für diesen Stakeholder?	ST-8
	w554: Zu dieser Stakeholder-Rolle gibt es keinen Stakeholder!	STR-3

10 Todos für Taras Zaika

	Todos	Artefakt
	(sbe) Bitte Begründung klarer machen, ich verstehe das noch nicht. Was hat der Student davon, dass eine Aufgabe noch nicht kontrolliert wird, obwohl er/sie als fertig gepusht hat?	FR-16
	(tza) (Antwort) Ich habe die Begründung etwas erweitert. Für mich war es aber ziemlich eindeutig, was gemeint war. Ich hoffe, wir haben jetzt eine ähnliche Vorstellung von dem Problem.	FR-16
	(sbe) warum wird das Alternativszenario gewählt? (tza) siehe [interview, fkrampe, 00-13-25] und leider konnte ich mir keinen besseren Weg vorstellen, das Ziel mit anderen Systemmitteln zu erreichen.	SCN-16
	(sbe) Für eine Stakeholderbeschreibung würde schon ein viel kürzerer Text reichen. Relevanz für Studierende ist gegeben, weil ST1/2 Pflichtfächer sind, das reicht. Alles weitere muss ja erst erhoben werden - siehe die Workshops.	ST-8
	(tza) (Antwort) Ich habe aus Max Maier 'Studierende' gemacht. Ich hoffe, es ist ok. Was die Beschreibung angeht, habe ich das etwas angepasst. Ich habe diesem Stakeholder geschrieben, wo die Workshops mit QQ2-Studenten noch nicht stattgefunden hatten. Einige Überschriften habe ich dem Methodentraining des Teams entnommen.	ST-8
	(tza) Akzeptanzkriterien präzisieren.	US-16
	(sbe) Glauben Sie, dass Sie diese US in einem Sprint umsetzen können? Ist zu groß (jedenfalls wenn das Limit auch überwacht wird) und in dieser Form als US unbrauchbar (ist eher ein Epic). Versuchen Sie einen sinnvollen ersten Schritt zu definieren!	US-32
	(tza) (Antwort) Ich habe jetzt noch paar Akzeptanzkriterien hinzugefügt. Es kann wohl sein, dass es noch nicht vollständig ist. Was die Größe angeht, bin ich eigentlich davon überzeugt, dass es in einem Sprint umgesetzt werden kann. Ich bin beim Schreiben eigentlich davon ausgegangen, dass für diese US alle notwendige Daten im System vorhanden sind (also keine Umsetzung von Zero) und nur noch Fachlogik gebaut werden muss + noch Wartungsausgabe, was auch trivial sein soll.	US-32
	(sbe) (von tza verkürzt) US Ist zu groß	US-17
	(tza) (Antwort) Ich habe jetzt noch paar weitere US's daraus gemacht. Hier wird auch davon ausgegangen, dass unterschiedliche Einstellungen durch den Nutzer bereits möglich sind und jetzt nur noch eine neue dazu kommt. Es soll locker in einem Sprint umgesetzt werden.	US-17