Internship adventure, czyli moja przygoda z praktykami

Po zeszłorocznym sukcesie, kiedy to Maksymilian i Augustyn pracowali nad NoteeFY (żółte karteczki w chmurze), postanowiłem również i w tym roku przyjąć pod swoje skrzydła praktykantów z Politechniki Wrocławskiej. Na początku, jak zawsze w takich sytuacjach, miałem niemałe obawy, czy na pewno dam radę stanąć na wysokości zadania i poprowadzić zespół do stworzenia dobrej aplikacji. Finalnie, po miesiącu czasu, mogę z czystym sumieniem powiedzieć – tak, daliśmy wszyscy świetnie radę!

Przygotowania

Jakoś w połowie sierpnia, podszedł do mnie Jarek i zapytał, czy nie chciałbym przyjąć we wrześniu praktykantów. Zgodziłem się. Po tygodniu dowiedziałem się, że będzie ich 4 – Adam, Dawid, Gabriel i Tadeusz. W tym momencie rozpoczęła się procedura załatwiania oraz organizowania całego przedsięwzięcia. Jak za każdym razem, trzeba było naprawdę wiele ogarnąć. Pierwszym krokiem było zatelefonowanie do każdego z nich i zaproszenie na pierwszy dzień praktyk. Potem należało znaleźć dla nich miejsce w firmie. Najlepiej żeby siedzieli obok siebie (co często, gęsto nastręcza wiele problemów). Następnie wypadało sprawdzić sprzęt, na którym młodzi developerzy będą programować świat.

W międzyczasie należało wykoncypować temat, który będziemy realizować w czasie miesięcznych praktyk. Chciałem, aby był to projekt z oddzielną warstwą frontend i backend. W mojej głowie pojawił się pomysł na system do ankiet. Moim zdaniem jest to w miarę prosty temat do realizacji w wersji podstawowej, a bardzo rozszerzalny w dalszej perspektywie. Po podjęciu decyzji, że zaproponuje praktykantom właśnie taki projekt, rozpocząłem prace nad makietami aplikacji przy pomocy moqups oraz krótką specyfikacją w Google Docs w której krótko opisałem makiety.

Prolog

Oficjalne przywitanie wszystkich praktykantów rozpoczęło pierwszy dzień praktyk. Na tym spotkaniu prócz moich praktykantów poznałem również Basię, Iwonę oraz Martę, które odbywały praktyki testerskie. Marek, opiekun dziewczyn, zgodził się, aby to one stały na straży jakości naszej aplikacji (rewelacja!). Po spotkaniu zabrałem młodych programistów do salki konferencyjnej, gdzie przedstawiłem im wizję mojego projektu. To był ten moment, kiedy chciałem, a nawet musiałem, dobrze sprzedać im swój pomysł. Było to bardzo ważne, ponieważ miało zaowocować tym, że im także będzie zależało na tym produkcie. Chłopakom bardzo spodobał się mój pomysł, toteż wszyscy zgodzili się partycypować w tym przedsięwzięciu. Na koniec spotkania, wspólnie podjęliśmy kluczowe decyzje odnośnie narzędzi oraz technologii, w których była realizowana aplikacja. I tak w części backend wybór padł na Entity Framework w podejściu Code First oraz ASP.NET Web API do zwracania danych w formacie JSON. W części frontend był to HTML przyodziany w Bootstrap oraz KnockoutJS.

Kiedy mieliśmy już wybrane technologie mogłem przydzielić praktykantom pierwsze zadania. Rozpoczęli od zadań wprowadzających w technologie, frameworki, biblioteki. Moim zdaniem takie ćwiczenia to bardzo ważny element, ponieważ pozwalają zapoznać się z możliwościami konkretnego rozwiązania, co później przekłada się na właściwe i skuteczne wykorzystanie podczas implementacji projektu. I tak przez pierwsze godziny pracy, praktykanci mieli do zrealizowania mały projekt z wykorzystaniem EF Code First oraz Web API. Zupełnie bez frontendu. Na koniec tego zadania oczekiwałem możliwości pobrania oraz aktualizacji danych z bazy SQL Server. Wszystko przy pomocy formatu danych JSON w programie Postman. Drugim zadaniem wprowadzającym była mała frontendowa aplikacja typu ToDo lista zrealizowana w HTMLu, Bootstrapie i KnockoutJS. Samouczków tego typu w internetach jest bardzo dużo, więc tutaj od strony wizualnej liczyłem na estetykę oraz inwencję twórczą. Natomiast od strony kodu zależało mi, aby młodzi programiści zapoznali się ze wszystkimi podstawowymi możliwościami/mechanizmami biblioteki KnockoutJS. Patrząc z mojej perspektywy, te dwa małe zadania pozwoliły mi rozpoznać możliwości każdego programisty we frontendzie i backendzie. To była cenna wiedza, ponieważ potem podczas trwania praktyk mogłem odpowiednio pokierować każdą osobę indywidualnie.

Kiedy studenci pracowali nad zadaniami wprowadzającymi, ja załatwiałem naszemu zespołowi Jirę do zarządzania projektem oraz repozytorium Gita postawionego na Bitbucket Server. Oba narzędzia znakomicie integrują się ze sobą, co bardzo usprawniło pracę np. podczas wykonywania code review. Dodatkowo, jako osoba z większym doświadczeniem, wziąłem na swoje barki zaprojektowanie architektury aplikacji.

surveyon-layers-diagram

Na koniec trzeciego dnia, mieliśmy już wszystko gotowe i byliśmy dobrze przygotowani, by rozpocząć pracę nad projektem SurveyOn, aplikacją do ankietowania!

Praktyki

Od samego początku starałem się tak prowadzić zespół, aby był w stanie organizować się, działać, pracować samodzielnie. Idąc za radą Damiana, mieliśmy role przechodnie w zespole – co tydzień ktoś inny przejmował rolę tech lead, kto inny rolę PMa. Dzięki temu, każdy z praktykantów mógł na własnej skórze poczuć odpowiedzialność za cały zespół. Mnie natomiast odpadło kilka kwestii organizacyjnych, na przykład rezerwacja salki czy załatwianie sprzętu.

Pracowaliśmy w metodyce Scrum, gdzie Sprint trwał 4 dni. Mieliśmy daily stand-up meetings, w których uczestniczyli zarówno programiści jak i testerki. Chciałem, aby od samego początku zespół programistów uczył się rozmawiać i współpracować z zespołem testerów. Ja natomiast przychodziłem na te spotkania tylko wtedy, kiedy miałem coś do zakomunikowania. Po dwóch tygodniach na stand-upach rozmawialiśmy już w języku angielskim. Moim zdaniem to ważne, aby mówić i pracować po angielsku od najwcześniejszych momentów wspólnej pracy.
Mieliśmy również planowanie sprintu na początku każdego tygodnia pracy. Na pierwszym planowaniu pokazałem praktykantom jak obsługiwać Jirę oraz jak w niej tworzyć zadania. Starałem się również przekazać im wiedzę, jak rozdzielać pracę/zadania oraz jak to powinno potem wyglądać w Jirze. Kolejne planowania organizowane były przez zespołowego PMa przy udziale zespołu testerskiego, który pilnował aby każde user story było należycie opisane. Przynajmniej dwa razy mieliśmy sprint retrospective, na którym każdy wymieniał plusy i minusy minionego sprintu, co finalnie przełożyło się na usprawnienie procesu implementacji aplikacji.

Na początku młodzi programiści pracowali na jednym, wspólnym branchu bez code review. Po pewnym czasie, kiedy zauważyłem że chłopaki świetnie dogadują się między sobą oraz że wytworzyły się pewne konwencje w kodzie, postanowiłem wprowadzić zasadę branch per feature. W myśl tej zasady, każda nowa funkcjonalność (każde kolejne story w Jirze) powinna być implementowana na oddzielnym branchu, aby po pozytywnym przejściu code review znalazła się w głównym branchu. Wykorzystywaliśmy do tego mechanizm pull request.

Istotnym elementem, który zdecydowanie pozytywnie wpłynął na dobrą współpracę całego zespołu, były wyjścia integracyjne zorganizowane w głównej mierze dzięki Marcie. Niby błahostka, niby oczywistość, ale z perspektywy czasu bez wahania stwierdzam, że miały one korzystny wpływ na atmosferę w projekcie.

Epilog

Zwieńczeniem miesięcznej, wytężonej pracy było demo aplikacji w ostatni dzień praktyk. Jak to na demo, nie obyło się bez małych niedociągnięć czy to wizualnych, czy to funkcjonalnych, jednakże finalnie aplikacja podobała się szerszemu gronu zaproszonych gości, co niezmiernie cieszy i napawa dumą.
W ostatni dzień zorganizowałem również młodym programistom finalne code review. Na tym spotkaniu chciałem ostatni raz, porządnie przejrzeć kod, który powstał w czasie tych praktyk. Chciałem ostatecznie podsumować co powstało i jak powstało. Chciałem zwrócić uwagę na kawałki kodu, które bardzo mi się podobały oraz na te, które były mniej udane. Myślę, że takie podsumowanie to cenna lekcja na koniec wspólnej pracy.
Kończąc praktyki nie mogło zabraknąć informacji zwrotnej (feedbacku) o przebiegu praktyk, toteż zwyczajowo zorganizowałem spotkanie w cztery oczy z każdym z praktykantów. I tak otrzymałem informacje o przebiegu całych praktyk, o tym co można by zmienić i ulepszyć, co się podobało i co było niefajne. Z drugiej strony, starałem się przekazać im informacje o ich mocnych i słabszych stronach, oraz o kompetencjach które warto doszlifować.

Zakończenie

Koniec końców, w jeden miesiąc powstała pierwsza wersja aplikacji SurveyOn, która na pewno będzie dalej rozwijana przez następnych praktykantów. Jestem bardzo dumny z zespołu oraz z aplikacji, którą stworzyli. Cieszy mnie fakt, że zespół był w stanie całkowicie niezależnie, bez nadzoru pracować i rozwijać projekt. Wielkie dzięki chłopaki i dziewczyny za miło i produktywnie spędzony czas.


Technology stack

Backend:

  • SQL Server
  • Entity Framework (Code First)
  • AutoMapper
  • Autofac
  • Microsoft Owin
  • ASP.NET Web API 2

Frontend:

  • ASP.NET MVC
  • KnockoutJS
  • Bootstrap
  • jQuery
  • FontAwesome
  • Masonry
  • Expandable textarea
  • DataTables

Podbij ↑

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *