Iteration 2
#Iteration 2 Die von uns initial angenommene Velocity von 0.7 hat sich als zu klein herausgestellt, da wir einen Task nicht fertigstellen konnten. Neu rechnen wir mit einer Velocity von 0.65, wie im Review der Iteration 1 erklärt.
##User Stories in dieser Iteration
| Identifier | User Story | Typ | Schätzung (mit Velocity) | Done |
|---|---|---|---|---|
| S2 | Left over von Phonegap für Android | Spike | 0.5 SP | |
| U3 | Teletextseite empfangen | User Story | 4.6 SP | |
| U4 | Aufbau einer Teletextseite empfangen | User Story | 3 SP | |
| U5 | Teletext-Unterseite empfangen | User Story | 1.5 SP | |
| U7 | Startseite ansehen | User Story | 4.6 SP | |
| U8 | Liquid Layout | User Story | 4.6 SP | |
| Total | 18.6 SP | |||
##Dashboard
###Woche 1
###Woche 2
##Burndown Chart
##Review Auch die zweite Iteration ist nicht ohne Probleme verlaufen. Zwar konnten wir alle User Stories und die dazugehörigen Tasks fertigstellen, doch stiessen wir auf das Problem, dass die Teletext-Seite Zugriffe zu drosseln und ab einer gewissen Frequenz ganz zu blocken scheint; dies wohl zur Vermeidung von DOS-Attacken. Das Phänomen zeigte sich besonders deutlich bei Unit Tests, welche den Service betreffen (und demenstprechend häufig ausgeführt werden) und wenn mehrere Benutzer die selbe Serviceinstanz benutzen um auf die Teletext-Daten zuzugreifen.
Aus diesem Grund haben wir eine neue User Story erstellt, welche wir in der nächsten Iteration prioritär behandeln werden, um die Abhängigkeit von der Teletext-Seite zu minimieren.
Die Velocity belassen wir unangetastet auf 0.65, da wir diese Iteration damit fertigstellen konnten.