“Jak to się robi” – o organizacji projektu przez Internet

Na wstępie, chciałem podziękować wszystkim, którzy ściągnęli i przetestowali pierwsze demo Wielkiego Mistrza – jak już wspomniałem, każda uwaga jest bardzo cenna. Dzisiejsza notka pośrednio się z tym wiąże – będę starał się przedstawić, jak wygląda organizacja takiego projektu przez Internet właśnie na bazie Wielkiego Mistrza. Oczywiście, nie wszystko da się opowiedzieć, ale myślę, że każdego początkującego programistę/informatyka/literata (no nie, może literata nie) powinno to zaciekawić i rozwiać pewne wątpliwości.

1. “Szukam chętnych”, czyli jak znaleźć odpowiednich ludzi?

Proste pytania, trudna odpowiedź – jak koordynator znajduje śmiertelników chętnych do zakłucia się w łańcuchy i pracy nad projektem, który ma zmienić świat i zapewnić kawior, szampan i emeryturę na wyspie Bali, ale ani nie zmieni, ani nie zapewni, bo to praca amatorska? Z mojej perspektywy (w końcu nie jestem koordynatorem, a do zespołu trafiłem, jak jego fundamenty już istniały) po nakreśleniu paruset słów układających się w dobrze wyglądający design doc tudzież ogólny opis projektu, taki pomysłodawca rusza na forum Warsztatu tudzież for skupiających grafików 3D i przedstawia swoje wypociny, umieszcza dane kontaktowe i czeka. Czasami bardzo długo.

W tym punkcie moje wynurzenia mogą być nieadekwatne do rzeczywistości – sam nigdy nie musiałem organizować projektu i szukać ludzi. Mimo wszystko, według mnie najlepiej, jeśli na początku mamy kilku kolegów “po fachu” u boku, z którymi dobrze się rozumiemy. Nie zawsze to jednak może się sprawdzić, szczególnie, kiedy marzenia przesłonią faktyczną pracę nad kształtem aplikacji (tak niestety bywa w młodym wieku –sam też to przeżywałem, jak miałem 14 lat. Chlip, jaki ja byłem młody). Dlatego też tak bardzo potrzebne jest, aby wstępny opis projektu był maksymalnie dopracowany i zachęcał do rozwijania.

A jakich ludzi szukać? Niekonieczne to muszą być programiści z krwi i kości, przed którymi koledzy (tudzież koleżanki) z branży zmiatają kurz z podłogi. O wiele ważniejsza jest umiejętność wkomponowania się w zespół i wykorzystywanie swoich predyspozycji do pomagania w projekcie. Zwykle niemile są widziane osoby, których tzw. “skill” jest na horrendalnie wysokim poziomie, ale czują się panami swojego podwórka i psują atmosferę. Dlatego też zwykle oferty współpracy do tego typu projektów są adresowane do młodych, niedoświadczonych programistów/grafików/projektantów, którzy chcieliby się czegoś nauczyć, trochę pomóc, a jednocześnie nie spalić się na samym początku.

2. “Halo wóz, halo wóz, odbiór”, czyli komunikacja.

Profesjonalne projekty zwykle skupiają swoich pracowników w jednym miejscu – zwanym dalej siedzibą firmy – dzięki czemu komunikacja jest dosyć prosta i skuteczna – podchodzimy do potencjalnego rozmówcy, otwieramy usta, wysyłamy fale dźwiękowe, czekamy na ewentualną odpowiedź, odchodzimy (rzadziej spotykana metoda to podejście, gwałtowne użycie ręki, głowy tudzież innej części ciała i atak w alternatywnym kierunku [czyli ucieczka]). Amatorskie projekty zwykle w całości odbywają się zdalnie przez medium zwane Internetem.

Z tego też powodu, ważna jest odpowiednia organizacja takiej wirtualnej siedziby firmy, czyli miejsca, gdzie można wymienić poglądy, podyskutować nad wizję, a co najważniejsze – aby odbywało się to w klarowny sposób. Przez ten ostatni punkt odpada nam wynalazek zwany forum – przekopywanie się przez wątki nie należy do najprzyjemniejszych zadań i efektywność takiej dyskusji jest bardzo nikła. O wiele lepiej postawić na serwis w stylu www.wikispaces.com, gdzie bardzo przyjemnie edytuje się podstrony, wkleja pliki, ustala szczegóły, a co najważniejsze – da się ustawić RSS z historią zmian na podstronach i zobaczyć, jakie nowe informacje doszły. Cudowna sprawa – każdy członek zespołu na jednej stronie ma wszystkie informacje odnośnie danego zagadnienia, może dopisać coś w środku, zapytać się o szczegóły, itepe, itede i nawet ikapee.

“Wikispacja”, jak jest często nazywane to rozwiązanie (może inaczej – ja akurat używam tego terminu, bo wydaje mi się adekwatny do rzeczywistości), jest głównym, choć nie jedynym środkiem komunikacji pomiędzy członkami zespołu. Pewne ustalenia robi się również poprzez komunikator internetowy w stylu Gadu-Gadu czy Tlena. W ostateczności pozostaje droga mailowa, ale mail służy do innych zadań – o których w ostatnim akapicie i następnym punkcie.

A co w tym ostatnim akapicie drugiego punktu? Czasami zdarzy się tak, że wraz z rozwojem projektu przytargał się jakiś bug – niepozorny robaszek niweczący jakiś efekt w zależności od swej wielkości i levelu w WoW-ie. Warto zatem tego typu informacje przekazywać między sobą dosyć szybko – do tego właśnie służy m.in. Bugzilla, czyli system raportowania o błędach w projekcie. Działa to w ten sposób, że “pomysłodawca” (czarny humor…) błędu zakłada nowy wątek i przekazuje informację o jego powstaniu do określonej osoby, która teoretycznie jest w stanie to naprawić. Odbywa się to drogą mailową, dzięki czemu całkiem szybko żądany członek zespołu dowiaduje się o bugu i może rozpocząć dalsze działanie – przekazanie go komuś innemu lub oznaczenie go jako “przyjętego” i rozpocząć pracę nad poprawą. Każdy błąd ma swój status, dzięki czemu wiadomo , co zostaje do zrobienia.

3. “To robimy”, czyli organizacja plików na serwerze.

Wbrew pozorom, nie latamy do siebie z dyskietkami, pendrive’ami czy płytami. Nie używamy też zwykłego serwera, gdzie są umieszczane pliki (choć to od biedy by się sprawdziło, ale szybko doprowadziłoby do furii). W inżynierii oprogramowania stosuje się coś takiego jak systemy kontroli wersji – jest to specjalna nakładka na serwer (mam nadzieję, że dobrze myślę – jak ktoś lepiej wie, o co chodzi, to proszę mnie poprawić), dzięki czemu pliki są wersjonowane (istnieje możliwość dokopania się do zatraconych danych) i wszystko jest składnie poukładane niczym książki na mojej półce (ironia, haha… Dobrze, to nie było śmieszne). Idea jest następujaca – każdy członek zespołu zakłada u siebie na dysku folder repozytoryjny, gdzie będzie składowana “zawartość” serwera SVN (ponieważ my taki system używamy), a następnie ściąga pliki. Jest to możliwe dzięki fajnemu programikowi TortoiseSVN, który polecamy. Każdy pracuje na plikach znajdujących się na własnym dysku, zatem ewentualnej krzywdy projektowi nie zrobimy – jeśli uznamy, że nasza praca zasługuje na wrzucenie na serwer – musimy plik “zakomitować” i przez to narazić się towarzyszom na potępienie, bo znowu coś się nie kompiluje (swoją drogą, przy tworzeniu Wiedźmina, programiści podobno musieli się zobowiązać do wrzucania 5 zł do firmowej świnki-skarbonki za każdy błędny kod wrzucony do repozytorium).

Brzmi prosto, ale zaraz padnie pytanie – a co, jeśli dwie osoby pracują nad tym samym plikiem i obie będą chciały komitować swoje zmiany przed aktualizacją katalogu na dysku? Ano, tutaj widać potęgę SVN, który temu drugiemu pokaże ładną informację, iż musi popracować nad szybkością pracy, gdyż ktoś go uprzedził, a jednocześnie utworzy dużo dziwnie wyglądających plików, gdzie widać każdą wprowadzoną zmianę. Dlatego najlepiej zawsze aktualizować swój obraz repozytorium przed wprowadzaniem zmian.

Każdy programista zespołu może oczywiście (i nawet powinien) kompilować program najpierw u siebie, aby zobaczyć, czy wszystko działa tak, jak powinno (i nie musieć wrzucać 5 zł do świnki-skarbonki). Można jednak ustawić tzw. automat do budowania snapshotów – jest to program, który automatycznie kompiluje kod znajdujący się w repozytorium i wyrzuca pliki w określone miejsce. Jeżeli coś się nie powiedzie – wszyscy członkowie zespołu dostają informację na maila o błędzie. Automat jest zwykle ustawiony na kompilację w godzinach nocnych, kiedy nikt nie wprowadza zmian w repozytorium.

4. “Raporty”, czyli metodologia Scrum.

W firmach pracujących w jednej siedzibie i stosujących się do idei programowania Agile (też kiedyś o tym wspomnę, ale raczej nie w najbliższym czasie – poczekam na komentarze, czy taka notka byłaby przydatna) zwykle raporty składa się codziennie. W naszych warunkach jest to niemożliwe, zatem stosujemy je co weekend. Polega to na tym, iż każdy członek zespołu jest zobligowany do informowania o następujących rzeczach:

• co zrobił w danym tygodniu
• co zamierza zrobić w przyszłym tygodniu
• co go blokuje lub czego oczekuje od innych

Oczywiście, ta lista jest modyfikowalna – dla naszych potrzeb te trzy rzeczy wystarczą. Dzięki temu wszyscy wiedzą nad czym każdy pracuje i zawsze można komentować sprawy bieżące.

5. Jak rozrysować projekt? Jak go rozwijać?

Takie pytanie również zostało mi zadane, ale odpowiedź raczej nie będzie satysfakcjonująca. Nie da się w sposób jasny i klarowny powiedzieć, co i jak po kolei powinno być robione, aby nasz projekt był chwalony przez użytkowników. Na pewno powinno się zacząć od ogółu – nakreślić ogólny plan, co chcemy robić, a następnie zastanowić się, co powinno być dalej robione i stopniowo uszczegóławiać wizję kolejnych zagadnień. Przy każdym projekcie wygląda to inaczej – w przypadku gry trzeba oczywiście zastanowić się nad gatunkiem i ogólnym schematem, jaką rozrywkę chcemy zapewnić. Następnie trzeba przejść kolejne etapy – najpierw organizacyjne, ogólny projekt działania aplikacji (np. główna pętla, praca kamery), a potem zastanowić się nad resztą.

To krótki wstęp do inżynierii oprogramowania – przepraszam, że aż tak krótki, ale o pewnych rzeczy nie da się opowiedzieć, jeśli nikt o to nie pyta. Powyżej przedstawiłem to, co według mnie jest najważniejsze – jeżeli ktoś uważa, że coś zostało gorzej wyjaśnione lub ma dodatkowe wątpliwości, czekam na komentarze.

Pozdrawiam i dziękuję – SceNtriC.