-
Notifications
You must be signed in to change notification settings - Fork 1
Backlog produktu i sprintu 1
Projekt Emulator procesora Sharp LR35902
Link:
- v.0.1 doc: TBD
Dokument ten jest raportem dotyczącym utworzonego backlogu produktu i bazującego na nim pierwszego sprintu.
| Wersja: | TBD |
| Data wydania: | TBD |
| Redaktor: | TBD |
| Współautorzy: | TBD |
| Etap/zadanie: | Etap 3 – Scrum: Backlog produktu i sprintu |
| Nazwa pliku: | TBD |
| Status poufności: | JAWNE |
| Liczba stron: | TBD |
| Wersja | Data | Opis zmiany |
|---|---|---|
(krótkie przypomnienie projektu i produktu)
Projekt ma na celu wytworzenie wiernego emulatora konsoli do gier GameBoy Color i osadzenie go na małym urządzeniu przenośnym.
Produktem jest samo oprogramowanie jak również sprzęt na którym zostanie ono osadzone. Planowo ma to być Raspberry Pi
(opowieść w języku naturalnym o wykorzystaniu powstającego produktu w docelowym kontekście przez użytkowników zamodelowanych przez persony w celu rozwiązania ich problemów, obejmuje wykorzystanie wielu funkcji systemu/aplikacji w logicznym ciągu dającym realną wartość użytkownikom, mogą być 2-3 scenariusze)
Joshua po długim dniu nauki na uczelni postanowił, że zrelaksuje się grając w Pokemon Yellow. Od jakiegoś czasu ponownie przechodził tę grę, która jest dla niego jedną z ulubionych gier z serii. Nie posiadał konsoli, na której mógłby zagrać, więc korzystał dotychczas z emulatora. Doskwierał mu jednak brak możliwości użycia swojego wygodnego pada i konieczność wykorzystania komputera, która była dość niewygodna. Nie mógł usiąść na swojej wygodnej kanapie, był skazany na pracę przy stanowisku przypominającym to w uczelnianej bibliotece. Zniechęcony tą sytuacją postanowił zakupić urządzenie do emulacji GameBoy Color, o którym czytał wcześniej na tematycznym forum.
Dziś miał pierwszy raz okazję, żeby z niego skorzystać. Nie chcąc zużywać niepotrzebnie baterii, które wymagałyby ładowania po kilku godzinach gry, podłączył urządzenie do gniazdka używając zasilacza, który zwykle służył mu do ładowania telefonu. Z dokumentacji urządzenia dowiedział się, że pliki zapisu stanu gry z jego emulatora są wspierane przez urządzenie, co było bardzo dobrą wiadomością -- mógł kontynuować grę od miejsca, w którym wcześniej ją zakończył. Zgrał z komputera na pendrive używany dotychczas ROM gry i plik zapisu, po czym podłączył go do urządzenia. Podłączył również swojego pada do konsoli XBOX 360 z użyciem portu USB.
Po włączeniu przełącznika POWER zapaliła się dioda z przodu urządzenia, a na wbudowanym wyświetlaczu przez chwilę pojawił się ekran włączania systemu, po czym wyświetlone zostało proste menu z listą znalezionych ROMów. Po wybraniu wgranego ROMu Pokemon Yellow za pomocą klawiszy kierunkowych pada i zaakceptowaniu wyboru domyślnym klawiszem A pojawiło się kolejne menu pozwalające wybrać jeden ze znalezionych plików zapisu, lub rozpoczęcie nowej gry.
Po wybraniu pliku zapisu z pendrive'a na pełnym ekranie urządzenia został wyświetlony znajomy ekran początkowy, charakterystyczny dla gier na GBC. Po załadowaniu właściwego ekranu początkowego gry okazało się, że przyciski na padzie od XBOX 360 są zmapowane do odpowiadających im przestrzennie przycisków z oryginalnej konsoli.
Poprzedni emulator pozwalał na przypisanie różnym klawiszom na klawiaturze wybranych przez użytkownika akcji, takich jak emulacja wciśnięcia kombinacji przycisków, czy szybki zapis/odczyt stanu gry. Zajrzenie do dokumentacji nowego urządzenia pozwoliło na ustalenie przycisku, który pozwalał wejść w trakcie gry do menu dającego możliwość m. in. zmapowania nieużywanych przycisków pada, zapisu i odczytu stanu gry oraz wyjścia z aktualnej gry z powrotem do menu głównego.
Emulacja samej gry była wierna, kolorystyką odpowiadała oryginalnym konsolom, które Joshua widywał na konwentach. Prędkość gry również była zachowana, co często stanowiło problem w innych emulatorach. Dzwięk podczas gry brzmiał tak samo, jak zapamiętał to z filmów w Internecie przedstawiających gameplay.
Po zakończonej sesji gry Joshua użył ustawionego uprzednio skrótu klawiszowego do zapisania stanu gry i przestawił przełącznik POWER do pozycji wyłączonej. Ekran wyłączył się, a po chwili zgasła również dioda z przodu urządzenia.
(wygenerowana z narzędzia wspomagającego lista zestawiająca elementy backlogu produktu (cechy produktu, user stories) z nadanymi im identyfikatorami, priorytetem dla interesariuszy, oszacowaniem złożoności w story points, wyjaśnienie jednostek i skal priorytetów i złożoności, wyjaśnienie sposobu posortowania listy elementów w backlogu)
Priorytety:
- P0 - Funkcjonalność niezbędna/krytyczna,
- P1 - Funkcjonalność potrzebna,
- P2 - Funkcjonalnośc która powinna zostać zaimplementowana,
- P3 - Funkcjonalnośc opcjonalna, jej brak nieznacznie wpływa na jakośc produktu.
Szacowanie story points zostało wykonane relatywnie do podobnych zadań już kiedyś wykonywanych przez członków zespołu, stosujemy skalę: 1, 2, 3, 5, 8, 13, 20
Elementy w Backlogu posortowane są w ten sposób aby być w stanie jak najwcześniej dojśc do działającego produktu, rzeczy mniej krytyczne takie jak np. dźwięk pozostawione są na koniec.
(zakładana liczba sprintów, pojemność zespołu, rezerwa w pojemności zespołu na pracę inną niż wytwarzanie np. spotkania, zakładana prędkość zespołu, wybrane elementy z backlogu produktu, uzasadnienie wyboru zakresu sprintu - elementów z backlogu produktu)
Pierwszy sprint będzie trwał 4 tygodnie, przy czym ostatni tydzień jest przeznaczony na domykanie pracy (szczególne skupienie na Code Review). Przewidujemy że obecnie każdy członek zespołu jest w stanie przeznaczyć około 8 godzin tygodniowo na projekt. Daje nam to na sprint 32 roboczogodzin na osobę, co wydaję się nam rozsądnym czasem na większe zadanie.
Na dzień dzisiejszy zakładamy 6 sprintów, nasz zespół liczy 3 osoby o podobnych kompetencjach. Zakładamy że 50% czasu przeznaczonego na sprint będzie faktycznym wytwarzaniem produktu.
W backlogu obecnie znajduje się 260 SP, przy 6 sprintach średnia prędkośc zespołu będzie wynosić około 43 SP na sprint. (Prędkość pesymistyczna 0.5*43SP/sprint = 21.5SP/sprint). Wynika z tego że w trakcie jednego sprintu wykonane zostanie przynajmniej jedno duże zadanie.
Z backlogu produktu do realizacji zostało wybrane zadania które realizują:
- Podstawowe instrukcje procesora
- Ładowanie pliku ROM do pamięci
- Załadowanie podstawowej biblioteki graficznej
Zadania zostały dobrane tak, aby jak najwcześniej zaczęła się wyłaniać architektura systemu, aby jak najszybciej wyłapać możliwe problemy. Wykonanie tych zadań będzie wymagało utworzenia już pewnego szkieletu na którym będzie opierać się cały produkt.
(określenie najważniejszej wartości dla interesariuszy wynikającej z przyrostu po sprincie 1)
Emulator wykrywa czy podany ROM faktycznie zawiera poprawnie zakodowaną grę oraz wyświetla podstawowe informacje na jej temat. (Tytuł, wersja językowa, etc.)
(wygenerowana z narzędzia wspomagającego lista/tabela zestawiająca elementy backlogu produktu (cechy, user stories), które zostały wybrane do realizacji w sprincie; większe elementy backlogu są rozbite na zadania wytwórcze dla zespołu Scrum i oszacowane w godzinach; backlog pokazuje stan na początku sprintu)
Emulator procesora Sharp LR35902, A. Misiak, Ł. Mrugała, M. Zalewski
Project related:
RPI related: