Skip to Content

Changes for page Scrum

Last modified by pmeyer on 2025/09/12 04:57
From version arrow_back 1.8 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:48
Change comment: There is no comment for this version
To version arrow_back 6.3 arrow_forward
edited by Pascal Meyer
on 2025/07/29 03:53
Change comment: There is no comment for this version

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -54,7 +54,7 @@
54 54  **** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
55 55  **** Wichtig! Wird gerne unterschätzt
56 56  **** Hilft, das Ziel im Auge zu behalten
57 -** **Sprint Review​​​​​​​**
57 +** **Sprint Review**
58 58  *** Das Team präsentiert, was es während eines Sprints erreicht hat
59 59  *** Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
60 60  *** Das ganze Team nimmt teil!
... ... @@ -70,129 +70,34 @@
70 70  *** Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
71 71  *** Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
72 72  * **Artefakte:**
73 -** Product Backlog
74 -** Sprint Backlog
75 -** Produktinkrement
73 +** **Product Backlog**
74 +*** Die Anforderungen für das finale Produkt
75 +*** Eine Liste aller gewünschten Projektarbeiten
76 +*** Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
77 +*** Im SWP: Zu Beginn füllen und später ergänzen
78 +*** Vom Product Owner priorisiert
79 +*** Zu Beginn des Sprints repriorisiert
80 +** **Sprint Backlog**
81 +*** Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
82 +*** Aber**:**
83 +**** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
84 +**** Im Zweifelsfall durch Zuweisung...
85 +*** Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
86 +*** Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
87 +*** Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
88 +** **Produktinkrement**
76 76  
77 -=== **Rollen** ===
90 +**[[image:Scrum-Prozess.JPG]]**
78 78  
79 -Product Owner:
92 += Scrum - im Detail =
80 80  
81 -* Definiert Product-Features
82 -* Bestimmt Auslieferungsdatum und Inhalt
83 -* Akzeptiert oder weist Arbeitsergebnisse zurück
84 -* Im SWP der Tutor in Absprache mit Marco und das Team
85 -
86 -Scrum Master:
87 -
88 -* Repräsentiert das Management gegenüber dem Projekt
89 -* Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken
90 -* Beseitigt Hindernisse
91 -* Stellt sicher, dass das Team vollständig, funktional und produktiv ist
92 -* Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen
93 -* Schützt das Team vor äußeren Störungen
94 -
95 - → Im SWP ein spezielles Mitglied der Gruppe
96 -
97 - → Soll trotzdem auch mit entwickeln
98 -
99 -Entwicklungs-Team:
100 -
101 -* Typischerweise 5-9 Personen
102 -* Funktionsübergreifend
103 -** QS, Programmierer, UI-Designer, etc.
104 -* Mitglieder sollen Vollzeitmitglieder sein
105 -* Teams organisieren sich selbst
106 -* Mitgliedschaft kann nur zwischen Sprints verändert werden
107 -
108 - → Es kann helfen, einen Projektleiter zu bestimmen (ist nicht Scrum-Konform, aber im SWP kann es hilfreich sein)
109 -
110 -=== **Meetings** ===
111 -
112 -Sprint Planning
113 -
114 -* Sprint Priorisierung
115 -** Product Backlog analysieren und auswerten
116 -** Sprint-Ziel festlegen
117 -* Planung
118 -** Entscheiden, wie man das Sprint-Ziel erreichen kann (Design)
119 -** Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen
120 -*** Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus
121 -* Sprint Backlog schätzen (Planning Poker, Magic Estimation, etc.)
122 -* Sprint-Ziel
123 -** Kurze Angabe dessen, worauf sich die Arbeiten während des Sprints fokussieren
124 -** Wichtig! Wird gerne unterschätzt
125 -** Hilft, das Ziel im Auge zu behalten
126 -
127 -Daily Scrum //(hier: Weekly)//
128 -
129 -* Wöchentliches Treffen startet mit Scrum-Meeting
130 -* Am Ende der Sitzung Verteilung neuer Aufgaben (jeder hat mindestens ein Ticket)
131 -* Im Weekly werden keine Lösungen diskutiert, dies kann im weiteren Verlauf der Sitzung passieren
132 -
133 -Sprint-Review
134 -
135 -* Das Team präsentiert, was es während eines Sprints erreicht hat
136 -* Typischerweise in Form einer Demo mit neuen Features oder der zugrunde liegenden Architektur
137 -* Das ganze Team nimmt teil!
138 -
139 -Sprint-Retrospektive
140 -
141 -* Regelmäßig prüfen, was gut und was nicht so gut funktioniert
142 -* ca. 15-30 min lang
143 -* Nach jedem Sprint
144 -* Das gesamte Team kommt zusammen und diskutiert, wie es sich verbessern möchte
145 -* Methode hierfür bspw: Starfish (siehe Bild)
146 -* Weitere Methoden für die Retrospektiven finden sich z.B. hier: [[https:~~/~~/retromat.org/>>url:https://retromat.org/]]
147 -
148 -[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png~|~|alt="Retrospektive.png" height="393" width="524"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/e505851f2237f527759101e71f2207f9/Retrospektive.png]]
149 -
150 -=== **Artefakte** ===
151 -
152 -Product Backlog:
153 -
154 -* Die Anforderungen für das finale Produkt
155 -* Eine Liste aller gewünschten Projektarbeiten
156 -* Eigentlich immer mehr, als im aktuellen Sprint gebraucht wird
157 -* Im SWP: Zu Beginn füllen und später ergänzen
158 -* Vom Product Owner priorisiert
159 -* Zu Beginn des Sprints repriorisiert
160 -
161 -Sprint Backlog:
162 -
163 -* Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen)
164 -* **Aber:**
165 -** Im SWP hat jeder am Ende einer Sitzung eine Aufgabe!
166 -** Im Zweifelsfall durch Zuweisung...
167 -* Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern (basierend auf dem aktuellen Ziel)
168 -* Wenn Arbeit unklar ist, definieren Sie erstmal einen Task mit größerer Schätzung und erstelle Unteraufgaben, sobald die Arbeit klarer wird
169 -* Definieren Sie für die Tickets eine Definition of Done ([[https:~~/~~/www.scrum-events.de/was-ist-die-definition-of-done-dod.html>>url:https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html]])
170 -
171 -= Scrum im Detail =
172 -
173 173  == Scrum-Prozess ==
174 174  
175 -Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom
176 -Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint
177 -Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam
178 -//(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet
179 -wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten
180 -kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach
181 -dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte//
182 -//Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine
183 -Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.
96 +Nachdem die Produktvision definiert wurde, wird das Product Backlog erstellt und vom Product Owner //(hier: gesamtes Team im Softwareprojekt)// verwaltet. Aus dem Sprint Planning resultiert das Sprint Backlog, welches im Sprint durch das Entwicklungsteam //(hier: Scrum Master gehört zum Entwicklungsteam und programmiert mit)// abgearbeitet wird. Der Scrum Master sorgt dafür, dass das Entwicklungsteam ungestört arbeiten kann. Täglich //(hier: wöchentlich)// trifft er sich im Daily Scrum mit dem Team. Nach dem Sprint wird ein Produktinkrement an den Auftraggeber //(hier: an das gesamte Team)// ausgeliefert und in einem Sprint Review näher erläutert. Anschließend wird eine Sprint Retrospektive durchgeführt, in der das Team die Zusammenarbeit reflektieren kann.
184 184  
185 185  == Product Backlog ==
186 186  
187 -Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber
188 -gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der
189 -Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den
190 -meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund
191 -sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen
192 -zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben
193 -oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der
194 -Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für
195 -alle Mitglieder des Scrum Teams ersichtlich sein.
100 +Ein Product Backlog ist eine priorisierte Anforderungsliste für das von dem Auftraggeber gewünschte Softwareprodukt. Diese ist nie vollständig und zu jederzeit anpassbar. Der Product Owner //(hier: das gesamte Team)// ergänzt das Backlog stetig und hat in den meisten Fällen bereits User Stories für den nächsten Sprint geplant. Aus diesem Grund sind in dem Backlog nicht alle für das komplette Produkt relevanten Anforderungen zu finden, weil sich von Sprint zu Sprint immer wieder neue Anforderungen ergeben oder alte verworfen werden. Es ist auch möglich, dass sich die Prioritäten ändern. Der Product Owner //(hier: das gesamte Team)// verwaltet das Backlog, allerdings muss es für alle Mitglieder des Scrum Teams ersichtlich sein.
196 196  
197 197  === **Der Nutzen eines gepflegten/priorisierten Product Backlogs** ===
198 198  
... ... @@ -214,11 +214,7 @@
214 214  
215 215  == Sprint Planning ==
216 216  
217 -Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann
218 -das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und
219 -das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden
220 -User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem
221 -Scrum Master und dem Product Owner der Sprint vorbereitet.
122 +Nachdem das Product Backlog initial gefüllt und das Sprint-Ziel festgelegt wurde, kann das Planning beginnen. Das Sprint Planning ist wichtig, weil der Product Owner und das Entwicklungsteam //(hier: das gesamte Team)// sich so einig über die zu bearbeitenden User Stories werden können. In diesem Meeting wird gemeinsam mit dem Team, dem Scrum Master und dem Product Owner der Sprint vorbereitet.
222 222  
223 223  === **Ablauf eines Plannings (Checkliste)** ===
224 224  
... ... @@ -241,15 +241,7 @@
241 241  
242 242  == Schätzen von Aufwänden ==
243 243  
244 -Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder
245 -einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie
246 -umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das
247 -Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine
248 -teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß,
249 -worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem
250 -können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden,
251 -wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden
252 -kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".
145 +Es sollte aus mehreren Gründen geschätzt werden. Zum einen bekommen alle Teammitglieder einen Einblick in den Inhalt aller User Stories, bevor angefangen wird, sie umzusetzen. Dies schärft das Verständnis für das Produkt. Zum anderen findet das Schätzen im besten Fall mit dem gesamten Team statt, wodurch dieses Meeting eine teamgeistfördernde Aktivität ist. Ein weiterer Vorteil ist, dass jede Person im Team weiß, worum es in der Story geht, sodass jede Person jede Aufgabe bearbeiten kann. Außerdem können so in Diskussionen Probleme oder zusätzliche Informationen identifiziert werden, wenn eine User Story beispielsweise in kleinere sinnvolle Einheiten aufgeteilt werden kann. Die Einheit, in der zumeist geschätzt wird, nennt sich "Story Points".
253 253  
254 254  === **Ablauf der Aufwandsschätzung (Checkliste)** ===
255 255  
... ... @@ -275,42 +275,25 @@
275 275  * Nur wenige Zahlen auswählen (bspw. 1,2,3,5,8)
276 276  * Wenn in T-Shirt-Größen geschätzt wird, dann jeder Größe eine Zahl zuweisen, sodass das Burndown- und Velocity-Chart genutzt werden kann
277 277  
278 -[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG~|~|alt="tshirtfibo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/78f387122adf2a44d3b92efa743d3446/tshirtfibo.JPG]]
171 +[[image:tshirtfibo.JPG]]
279 279  
280 280  === **Definition eines Velocity Charts** ===
281 281  
282 -Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf
283 -Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
284 -Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam
285 -in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf
286 -folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der
287 -vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart.
288 -Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die
289 -in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint
290 -15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten
291 -Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.
175 +Hat das Team schon mindestens einen Sprint hinter sich, kann der nächste Sprint auf Basis der Velocity aufgebaut werden. Die Velocity steht für die Geschwindigkeit des
176 +Teams. Das bedeutet, dass ermittelt wird, wie viele Story Points das Entwicklungsteam in dem vorherigen Sprint geschafft hat. Aufgrund dieser Information kann der darauf folgende Sprint genauer geplant werden, indem sich das Team nur auf die Anzahl der vorher erledigten Story Points committet. Die Abbildung zeigt ein solches Velocity Chart. Die x-Achse zeigt die bisherige Anzahl an Sprints und die y-Achse die Story Points, die in einem Sprint erledigt wurden. Es ist zu sehen, dass beispielsweise im zweiten Sprint 15 Story Points geschafft wurden, jedoch im dritten Sprint nur fünf. Ab dem dritten Sprint kann eine Verbesserung der Geschwindigkeit des Teams wahrgenommen werden.
292 292  
293 -[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG~|~|alt="velo.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/3bb28351d712bbf3e9ad6360fd85bc6a/velo.JPG]]
178 +[[image:velo.JPG]]
294 294  
295 295  === **Definition eines Burndown Charts** ===
296 296  
297 -Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung
298 -eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis
299 -der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder
300 -Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden,
301 -damit über die Probleme gesprochen wird. Die Abbildung zeigt ein
302 -Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse
303 -die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team
304 -bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.
182 +Eine Möglichkeit zur Überprüfung des Fortschritts während eines Sprints ist die Erstellung eines Burndown Charts. Es zeigt die bereits erledigten Story Points auf Basis der verbleibenden Zeit an. Somit kann schnell gesehen werden, ob Verzögerungen oder Probleme auftreten und falls dies der Fall ist, kann ein Meeting einberufen werden, damit über die Probleme gesprochen wird. Die Abbildung zeigt ein Burndown Chart. Auf der x-Achse sind die Arbeitstage zu sehen und auf der y-Achse die noch zu erledigenden Story Points für den Sprint. Es ist zu sehen, dass das Team bisher einen guten Fortschritt hat, weil der Graph bisher stetig abfällt.
305 305  
306 -[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG~|~|alt="burnd.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/a5dbbbeddb36c2545d5748bfef5124c2/burnd.JPG]]
184 +[[image:burnd.JPG]]
307 307  
308 308  == Daily Scrum ==
309 309  
310 -Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master
311 -zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am
312 -gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird.
313 -Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
188 +Täglich //(hier: wöchentlich)// treffen sich das Entwicklungsteam und der Scrum Master zu einem Meeting. Es ist ein sehr kurzes Treffen, welches immer zur gleichen Zeit am gleichen Ort stehend stattfindet. Zumeist stehend, damit es bewusst kurz gehalten wird. Das Treffen sollte nicht länger als 15 Minuten dauern. Jedes Teammitglied beantwortet
189 +
314 314  drei Fragen:
315 315  
316 316  1. Was habe ich gestern gemacht?
... ... @@ -317,12 +317,7 @@
317 317  1. Was werde ich heute tun?
318 318  1. Gibt es Hindernisse, die mir im Weg stehen?
319 319  
320 -Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer
321 -Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend
322 -beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig
323 -zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen
324 -möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher
325 -überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
196 +Durch das Daily Scrum werden Probleme sichtbar, die für den Scrum Master von großer Bedeutung sind, da er hierdurch eventuelle Impediments wahrnehmen und anschließend beseitigen kann. Außerdem ist dieses Treffen für das Team wichtig, um sich gegenseitig zu informieren und nach eventuell benötigter Hilfe zu suchen. Damit dieses Treffen möglichst effektiv ist, sollten sich die Teammitglieder darauf vorbereiten und vorher überlegen, was gestern bearbeitet wurde und was heute erledigt wird. Der Scrum
326 326  Master sorgt in diesem Meeting dafür, dass die anderen Teammitglieder nicht den Fokus
327 327  verlieren. Außerdem achtet er auf die Zeit, sodass diese eingehalten wird.
328 328  
... ... @@ -365,7 +365,7 @@
365 365  
366 366  == Sprint Review ==
367 367  
368 -Am Ende eines Sprints findet das Sprint Review statt (siehe [[Sprint-Review mit Jira>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/691404828/Sprint-Review+mit+Jira]]). Bei diesem Treffen werden
239 +Am Ende eines Sprints findet das Sprint Review statt. Bei diesem Treffen werden
369 369  die Sprint-Ergebnisse allen Interessierten präsentiert. Dazu gehören beispielsweise der
370 370  Auftraggeber oder andere Stakeholder //(hier: mit dem gesamten Team und ggf. dem//
371 371  //Tutor)//. Der Scrum Master bereitet dieses Meeting vor, indem er die Interessenten über
... ... @@ -393,8 +393,10 @@
393 393  
394 394  Beispiele für Retrospektiven finden sich z.B. hier: [[https:~~/~~/dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410>>url:https://dzone.com/articles/7-formats-for-great-team-retrospectives?edition=703410]]
395 395  
396 -Video zur Sprintretrospektive und die Verwendung in Jira [[1080p>>url:https://swl.informatik.uni-oldenburg.de/swp/video/Jira/Sprint-Retrospektive.mp4]]
267 +[[image:Unbenannt2.JPG]]
397 397  
398 -[[~[~[image:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG~|~|alt="Unbenannt2.JPG"~]~]>>path:/SPB/softwareprojekt-wiki_all/-/wikis/uploads/26a515caf8f128ae250a0240aea01531/Unbenannt2.JPG]]
269 +
399 399  
400 400  
272 +
273 +
attach_file Scrum-Prozess.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +59.4 KB
Content info
attach_file Unbenannt2.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +60.7 KB
Content info
attach_file burnd.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +21.3 KB
Content info
attach_file tshirtfibo.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +20.8 KB
Content info
attach_file velo.JPG
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.PascalMeyer
Size
... ... @@ -1,0 +1,1 @@
1 +25.3 KB
Content info