Development blog #2: Pierwszy sprint, pierwsze problemy…
No i właśnie minęły kolejne dwa tygodnie wakacyjnej pracy, czyli przyszedł czas na podsumowanie pierwszego sprintu… a jest o czym pisać!
Fot: Tim Regan, CC BY 2.0.
W ostatnim artykule z serii „development blog” opisywałem w jaki sposób zorganizowałem pracę z repozytorium gita, nie było natomiast w ogóle mowy o kodowaniu, gdyż sprint zerowy był de facto sprintem „technicznym” przeznaczonym na ustalenie zasad pracy z danym projektem. Wiele osób miało więc mały niedosyt licząc na jakieś smaczki związane z programistycznymi aspektami projektu. Mało kto jednak zwrócił uwagę na to iż ostatni artykuł pokazał jeszcze coś więcej, mianowicie to iż kodowanie czyli pisanie kodu jest ostatnim i nawet można wysnuć tezę, że najkrótszym etapem związanym z cyklem tworzenia oprogramowania.
Jak widać zanim przystąpimy do pisania kodu najpierw trzeba poustalać cała masę rzeczy, zastanowić się co chcemy zrobić, przygotować taski, przemyśleć podział architektoniczny i sporo innych elementów. Dopiero po uporaniu się z tymi czynnościami możemy przystąpić do napisania kodu i realizacji poszczególnych tasków, następnie znowu się zastanawiamy i tak w kółko. To tyle tytułem wstępu i takich moich małych przemyśleń, pora więc przejść do konkretów czyli tego co udało się zrobić oraz tego czego się nie udało…
Idziemy na dłuższe skróty…
Pierwsze taski jakie były do wykonania w minionym sprincie były naprawdę banalne, stworzenie szkieletu projektu nie może być przecież trudne? Tak więc ochoczo zabrałem się do pracy tworząc w Visual Studio cały projekt zgodnie z zamieszczonymi w internecie materiałami (jak pisałem wcześniej korzystam z Mvvmcross’a tak więc nie było to takie oczywiste ;)). Wszystko poszło gładko więc szybko przeszedłem do kolejnych tasków… i tutaj zaczęły się pierwsze problemy.
Kolejnymi rzeczami jakie znajdowały się na tablicy były taski związane z przygotowaniem layoutu czyli interface’u użytkownika. Było tego dość sporo, a jak wszyscy wiemy tego typu praca nie jest zbyt lubiana przez programistów, tak więc postanowiłem pójść jak mi się wydawało nieco na skróty i skopiowałem kod xml z innego projektu, gdzie ten layout miałem przygotowany. Trochę pracy z tym było, ale udało mi się uporać i przeszedłem do kolejnych rzeczy.
Następnym krokiem było stworzenie dwóch aktywności (ang. activity) jednej dla ekranu startowego – nazwałem ją NewGame, a drugiej dla gry – którą nazwałem Game. Tutaj de facto przy okazji również zrealizowałem jeszcze jeden task polegający na przygotowaniu całego szkieletu architektonicznego aplikacji – stworzenie pików dla modeli itd.
Wszystko więc było świetnie dopóki nie zmegowałem kodu do developa od którego następnie zrobiłem sobie brancha na którym miałem wszystko domknąć i w efekcie połączyć pliki layoutu z logiką. Wtedy niestety zaczęły się dziać rzeczy, których się obawiałem…
Pierwsza kompilacja, 80 błędów!
Myśląc, że jest jest już „po robocie” postanowiłem zbudować projekt (ang. bild) i tutaj niespodzianka… kompilator krzyczy, że mam 80 błędów! Przeglądam więc dokładnie o co chodzi i oczywiście o layout, a dokładnie o brak zdefiniowanych stringów, kolorów, marginesów itd… Dodałem więc odpowiednie pliki do zasobów, ale krzyczy dalej, tym razem już nie 80, a około 20 błędów… uff coś poszło do przodu no i tak się namęczyłem z naprawianiem tego, że w sumie sprint się skończył, task dalej ze statusem ONGOING i błędy jak były tak są dalej…
Lekcja na dziś: nigdy nie idź na skróty bo potem zemści się to dwa razy…
Retrospekcja
Podsumowując dwutygodniową pracę nie mam większych zastrzeżeń co do jej przebiegu. Zawsze są jednak jakieś plusy i minusy, tak więc do plusów na pewno mogę zaliczyć:
- dobrze zorganizowane repozytorium,
- dobrze przygotowany WoW (Way of Working).
Minusy:
- brak zrealizowanych wszystkich zaplanowanych tasków,
- wprowadzenie trochę bałaganu w kodzie,
- złe nazwy plików z layoutem (czasami nie wiadomo o co chodzi),
- brak aktualnej dokumentacji.
Co prawda minusów jest więcej ale fundamenty jak organizacja pracy i repozytorium są w porządku co dobrze rokuje na następny sprint. Moim celem będzie więc jak najszybsze zrealizowanie zaległych tasków z obecnego sprintu oraz realizacja wszystkich tasków jakie dojdą dzisiaj.
Podsumowanie sprintu
Jak widać na powyższym obrazku udało się statystycznie zrealizować 84% zaplanowanych tasków. To wynik w sumie dobry, ale biorąc pod uwagę iż było to pierwszy sprint to raczej nie ma powodów do otwierania szampana.
Taski które zostały:
Na kolejny sprint przechodzą więc trzy taski, z czego dwa jeszcze nie zaczęte. Na szczęście nie są one zbyt skomplikowane i myślę, że szybko uporam się z nimi.
Merge request
Jak było ustalane na początku, po każdym sprincie miał być robiony merge z developa do mastera, tym razem nie zrobię go dzisiaj ale z kilkudniowym opóźnieniem po uporaniu się ze wszystkimi błędami związanymi z layoutem.
Nowe zadania
W nowym sprincie dochodzi tylko jedna ale za to dość spora historyjka (której raczej nie zrealizuję do końca w dwa tygodnie) moim celem będzie zapisywanie wszystkich zebranych danych od użytkownika. Trzeba więc w pierwszej kolejności zastanowić się tutaj w jaki sposób to zrobić, będzie więc trochę rzeczy do „ogarnięcia”.
Podsumowanie
Pierwszy sprint dobiegł końca, czas na kolejny. Obserwujcie bloga, bo w planach mam opublikowanie pierwszych artykułów technicznych związanych z Xamarinem i Mvvmcrossem. Pojawi się też pewnie jakiś artykuł przedstawiający wgl. działającą aplikację – ale to już po mergu do mastera. Wszystkim czytelnikom przypominam również o hasztagu #ProjektStrefaKodera gdzie zebrane są wszystkie artykułu dotyczące tej aplikacji.
Jeśli macie jakieś pytania, uwagi, sugestie piszcie śmiało w komentarzach… miłych wakacji!
