Jedną z pierwszych prezentacji, którą prowadziłem na konferencjach poza Olsztynem była prezentacja pod tytułem: “Praca grupowa dla studenta”. Pierwszy raz pokazałem ją szerszemu gronu podczas Lubelskich Dni Informatyki pod koniec kwietnia 2009 roku.

Konferencja była kierowana głównie dla studentów, a jedną z cech studentów jest to, że ciężko u nich z kasą. Dlatego wszystkie pokazane podczas prezentacji narzędzia są dostępne za darmo (w części tylko podstawowa funkcjonalność). Celem prezentacji było pokazanie przykładowego warsztatu pracy grupowej, nie chciałem pokazać jedynej słusznej ścieżki, jedynie zachęcić słuchaczy do własnych eksperymentów. Z racji dość szerokiej tematyki nie mogłem za bardzo wgłębić się w tematykę poszczególnych narzędzi (w szczególności, że o np. Subverion można zrobić nie małą konferencję).

Całą prezentacje podzieliłem na trzy tematyczne części:

• komunikacja w zespole
• kontrola wersji projektu
• ciągła integracja pracy zespołu

Komunikacja w zespole

Jednym z najważniejszych elementów pracy w zespole (o ile nie najważniejszym) jest komunikacja między członkami zespołu. Nie będę się rozpisywał dlaczego komunikacja jest ważna, zapewne dobrze wiesz, że tak jest :) Podczas prezentacji pokazałem dwa portale (basecamphq, project zoho), które ułatwiają komunikację oraz zarządzanie projektami. Oba portale umożliwiają utworzenie za darmo jednego projektu w ramach wirtualnej firmy. Chcesz zarządzać większą ilości projektów? Nic trudnego, zakładasz nowe konto i masz nowy projekt :D Nie będę się opisywał szczegółowo możliwości portali, zachęcam Ciebie do założenia sobie konta oraz zabawy. Oba portale umożliwiają takie rzeczy jak wysyłanie wiadomości do członków zespołu, listy zadań, milestones itp.

Jak komuś chciałby pobawić się innymi portalami do zarządzania projektami to odsyłam do wpisu, w którym znajduje się lista 16 tego typu witryn.

Ja podczas pracy nad swoimi aplikacjami do komunikacji w czasie “rzeczywistym” używam ciągłego czatu na skypie. Na takim czacie znajdują się wszyscy członkowie w zespole i jak trzeba się szybko wymienić spostrzeżeniami, problemami to używamy właśnie skypa. Skype niestety ma jedną wadę. W przeciwieństwie do np. gadu gadu, jak wyślemy wiadomość do użytkownika, który w danej chwili nie jest zalogowany, to otrzyma on wiadomość dopiero, gdy oboje będziemy zalogowani, a nie jak mogło by sie wydawać w momencie jego zalogowania do skype. Podczas mojej pracy zdarzało się, że jak mieliśmy pecha i mijaliśmy się na skypie, to wiadomości dochodziły do nas po kilku dniach, co często było niedopuszczalne. Rozwiązanie tego problemu jest dość proste: stworzyliśmy dodatkowe konto, zainstalowaliśmy skypie na komputerze, który jest ciągle uruchomiony i tam zalogowaliśmy te nasze pomocnicze konto. Dzięki temu nie mamy już problemów z “spóźnionymi” wiadomościami.

Kontrola wersji

Drugą częścią prezentacji było omówienie systemów kontroli wersji. W obecnej chwili systemy kontroli wersji możemy podzielić na dwie grupy: systemy scentralizowane oraz rozproszone. Przykładem systemów zcentralizowanych jest dość popularny Subversion zwany potocznie SVNem. Systemy ten charakteryzują się jednym centralnym repozytorium, do którego członkowie zespołu wrzucają swoje zmiany. Pod Windowsem można korzystać z bardzo przyjemnego, graficznego klienta, który integruje się z systemowym explorerem – TortoiseSVN (jakiś czas temu na blogu grupy .net eastgroup.pl pojawił się wpis o podstawowej pracy z Tortoisem).

Innym system kontroli wersji, różniącym się architekturą od powyższego SVNa jest GIT. GIT jest jednym z przedstawicieli rozproszonych systemów kontroli wersji. W przeciwieństwie do systemów scentralizowanych nie istnieje jedno główne repozytorium zmian. W skrócie każdy programista posiada swoje lokalne repozytorium, do którego wrzuca swoje zmiany. Następnie inni członkowie zespołu mogą (o ile chcą) zaciągnąć do swojego repozytorium zmiany innych osób. Ksirg swego czasu opisał jak zainstalować GITa w Windowsie oraz podpiąć go pod Visual Studio.

Ciągła integracja

Ostatnia część prezentacji była na temat ciągłej integracji pracy w zespole. Ile razy spotykamy się z syndromem “ale u mnie to działa”, gdy okazuje się, że kod pobrany z repozytorium nie buduje się lub wyrzuca jakieś dziwne błędy? Dzięki ciągłej integracji już tego nie uraczymy :D Cytując Martina Fowlera, ciągła integracja to praktyka wytwarzania oprogramowania, w której członkowie zespołu często integrują swoją prace. Pytanie jak często? Najlepiej po każdym commicie do repozytorium. Ciągła integracja jest już związana z technologią w jakiej wytwarza sie oprogramowanie (w przeciwieństwie do poprzednich części prezentacji, które są niezależne od technologii), a dokładnie narzędzie do niej. Pokazałem CruiseControl.NET, którego dzisiaj nie będą opisywał, ponieważ jest to temat na inny wpis.

Plik PowerPointa z prezentacją - Teamwork.pptx (2,69 mb)