-
Notifications
You must be signed in to change notification settings - Fork 1
Dobór i adaptacja metodyki
Projekt Emulator procesora Sharp LR35902
Link:
- v.0.1 doc: TBD
Dokument ten jest raportem dotyczącym ogólnego planu projektu wykonanym zgodnie z metodyką RUP.
| Wersja: | TBD |
| Data wydania: | TBD |
| Redaktor: | TBD |
| Współautorzy: | TBD |
| Etap/zadanie: | Etap 6 – Dobór i adaptacja metodyki |
| Nazwa pliku: | TBD |
| Status poufności: | JAWNE |
| Liczba stron: | TBD |
| Wersja | Data | Opis zmiany |
|---|---|---|
Projekt ma na celu wytworzenie wiernego emulatora konsoli do gier GameBoy Color i osadzenie go na małym urządzeniu przenośnym.
Produktem jest zarówno samo oprogramowanie, jak i sprzęt na którym zostanie ono osadzone. Planowo ma to być Raspberry Pi.
Projekt faktycznie wykonywany jest przez 3 osoby. Zarządzany jest przez 4 osoby wliczając opiekuna. Jest to stosunkowo mały zespół, produkt również można uznać za mały. Sugeruje to metodyki zwinne.
Produktem końcowym jest przedmiot-gadżet. Potencjalne błędy/niedoróbki mogą jedynie wpłynąć na zadowolenie klientów co może odbić się na reputacji zespołu. Metodyki sterowane planem mogą się okazać w takim przypadku przesadne.
Wszystkie osoby w zespole posiadają już pewne doświadczenie zawodowe i miały okazje pracować w metodykach zwinnych.
Przez większość czasu pracować będziemy z obszerną dokumentacją. Szansa na zmiany na tym froncie jest znikoma. Jedynym źródłem zmian jest praktycznie opiekun projektu. Taki stabilny stopień dynamiki nadaje się do metodyk sterowanych planem.
Na podstawie wcześniejszej współpracy i rozmów na ten temat, jedna osoba w zespole preferuje porządek, pozostałe dwie zaś - chaos.
Emulator nie należy do produktów w którym możemy szybko dostarczyć wartość biznesową. Wartość pojawia się dopiero kiedy tan naprawdę emulator jest prawie gotowy. Od emulatora jest również oczekiwane wierne odwzorowanie sprzętu, czyli nasz projekt będzie musiał spełniać dużo specyfikacji określonych w dokumentacji.
Wskazuje to na metodykę zdyscyplinowaną.
Mały zespół w którym członkowie mają ze sobą bezpośredni kontakt, nie potrzebne są żadne dodatkowe procesy. Wskazuje to na metodykę zwinną.
Wymagania co do naszego projektu są nam już w większej części znane i nie będą się zmieniać. Wskazuje to na metodykę zdyscyplinowaną, pomimo braku skupienia na organizacji.
W ramach projektu przyjmujemy że naszym klientem jest opiekun projektu. Jego sugestie traktujemy jak oczekiwania użytkowników. Jesteśmy w stanie na bieżąco weryfikować oczekiwania wobec produktu końcowego. Spotykamy się z nim w miarę potrzeb w celu doprecyzowania wymagań i określania naszego postępu. Jedynym terminem ważnym dla klienta jest termin końcowy oraz drugi, kilka-naście dni wcześniej, potrzebny do walidacji projektu. Wskazuje to na metodykę zdyscyplinowaną.
Emulacja jest dla nas tematem dosyć niezbadanym, także każda osoba w zespole w swoim własnym zakresie poszerza swoją wiedzę. Jeżeli ktoś posiądzie wiedzę która może przydać się w realizacji projektu dzieli się z nią na forum. Przy podziale zadań w naszym projekcie ważne jest aby na bieżąco komunikować się między sobą i ułatwić późniejszą integrację. Plany są raczej zaszyte i wynikające z dokumentacji emulowanego produktu, a nadzór jest zdecydowanie jakościowy. Wskazuje to na metodykę zwinną.
Korzystając z więcej niż jednego źródła szeroko dostępnych dokumentacji pojawia się ryzyko posługiwania się różnymi językami. Zapobiec temu można przez ustalenie wystarczającej ilości źródeł z których zespół będzie korzystać aby ułatwić późniejsze rozmowy. Wiedza jest zatem jawna i udokumentowana. Wskazuje to na metodykę zdyscyplinowaną.
Wymagania do naszego projektu przedstawiamy w formie krótkich historyjek. Obejmują one tylko warstwę interakcji z użytkownikiem, wszystkie wymagania samego procesu emulacji są dostępne w dokumentacji. Jednocześnie można argumentować, że źródłem wymagań jest też sama dokumentacja. Nie wskazuje to przeważająco na żaden z rodzajów metodyk.
Sam proces emulacji procesora i pamięci jest kluczowy i musi powstać jako jeden z pierwszych, dlatego ważne jest aby został odpowiednio przemyślany, naprawianie złej architektury która powstała na wczesnym etapie będzie później kosztowne. Reszta modułów jednak jest mała i ich refaktoryzacja jest raczej niekosztowna. Wskazuje to na metodykę zwinną.
Dla emulatora zostały przygotowane pewne testowe ROMy, których poprawne działanie będzie zawsze wymagane. Nie ma jednak szczególnie dokumentowanych procedur testowania. Wskazuje to na metodykę zwinną.
Tak jak zostało to wcześniej wspomniane, nasz opiekun projektu reprezentuje nam klienta. Uważamy że jest reprezentatywnym klientem i posiada odpowiednią wiedzę. Kwalifikuje się więc jako klient CRACK, ale jego stały dostęp nie jest wymagany. Wskazuje to na metodykę zdyscyplinowaną.
Wszyscy członkowie zespołu mieli już niejednokrotnie okazję ze sobą współpracować w trakcie studiów. Każdy jest przynajmniej poziomu 2. Wskazuje to na metodykę zwinną.
Każdej osobie w zespole zależy na tym aby projekt zakończył się sukcesem. W tym celu każda osoba według własnego sumienia wykonuje swoją pracę. Większość z nich jest skłonna do chaosu. Wskazuje to na metodykę zwinną.
Patrząc na analizę dwunastoskładnikową, metodyki zwinne wygrały ilościowo wynikiem 6-5.
Oczywiście jednak analiza ilościowa nie jest wystarczająca. Za metodykami zwinnymi opowiedziały się również inne fakty. Po pierwsze, każdy z członków zespołu miał wcześniejsze doświadczenie zawodowe, podczas którego korzystał z metodyk zwinnych, brak zaś było doświadczenia w kwestii metodyk zdyscyplinowanych. Po drugie, ze względu na to, że członkowie zespołu posiadają koleżeńskie relacje poza i przed projektem, trudniej jest im postawić się w ściśle określonych rolach projektowych. Po trzecie, ze względu na naturę projektu, który jest pracą inżynierską, każdy z członków zespołu jest w pewnym sensie zarówno wytwórcą, jak i odbiorcą projektu - od jego rezultatu zależy jego przede wszystkim osobiste dobro - kwestia uzyskania tytułu inżyniera. Oznacza to, że dla każdego z nich naturalna jest idea własności kodu, występująca w metodykach zdyscyplinowanych oraz chęć szybkich zmian i iteracji.
Ostatecznie zdecydowaliśmy się na metodykę Scrum, ale z pewnymi modyfikacjami.
Czas sprintu ustaliliśmy na miesiąc. Biorąc pod uwagę studia i pracę, krótsze sprinty wnosiłyby zbyt mało zmian. Sprint podzielony zostaje na dwie fazy:
- Wytwórcza (3 tygodnie)
- Stabilizacyjna (1 tydzień).
W pierwszej fazie każdy pracuje nad zadaniami których się podjął podczas planowania sprintu. Druga faza służy na domykanie zadań. Skupiamy się wtedy na code review. Przeglądamy kod pozostałych członków w celu wypunktowania błędów i ich szybkiej poprawy.
Emulator procesora Sharp LR35902, A. Misiak, Ł. Mrugała, M. Zalewski
Project related:
RPI related: