Praca nad projektami w Drupalu

Budowa serwisów i aplikacji internetowych jest złożonym oraz czasochłonnym zadaniem. Podczas tego procesu wykonywanych jest wiele czynności. Aby nad nimi zapanować, wspomagamy się różnego rodzaju aplikacjami. W tym artykule opisujemy, jak wygląda proces prac nad budową i rozwojem serwisu internetowego lub aplikacji webowej w firmie Droptica.

Używane narzędzia systematycznie ulepszamy lub zmieniamy na inne. W związku z tym, że aspirujemy do bycia najlepszą agencją drupalową, proces jest u nas stale modyfikowany, aby osiągnąć m.in. następujące cele:
- eliminacja czynności powtarzalnych, zastąpienie ich skryptami lub aplikacjami
- przyśpieszenie prac programistycznych
- lepsza komunikacja w zespole oraz między zespołem i klientem

Wspomaganie zarządzania projektami

Sercem całego projektu jest Redmine (http://www.redmine.org/), czyli system wspomagający zarządzanie projektami. W Redmine dodajemy zadania do wykonania i aktualizujemy informacje o postępie realizacji zadania. W Redmine też logujemy czas pracy poświęcony na każde zadanie.

Najczęściej w Redmine dla każdego serwisu budowanego dla klienta tworzymy 3 projekty w Redmine:
1) Backlog/Client - tutaj odbywa się komunikacja z klientem. Wprowadzamy tu ogólne zadania do wykonania (zadania wprowadza klient lub my, zależnie od sytuacji).  Nie są to zazwyczaj zadania programistyczne, tylko bardziej ogólnie zdefiniowane wymagania biznesowe. Klienci często oczekują efektu końcowego i nie mają czasu zagłębiać się w zadania programistyczne. Dlatego mamy osobny projekt do prac programistycznych, gdzie każde z wymagań klienta jest rozbijane na mniejsze zadania programistyczne.

2) Dev - w tym projekcie pracujemy nad konkretnymi zadaniami programistycznymi, aby wykonać zadanie zlecone przez klienta.  Tutaj używamy pluginu Backlogs (http://www.redmine.org/plugins/backlogs). Każde z wymagań klienta jest tutaj tworzone jako Story i do niego dodawane są podzadania. Główne statusy dla zadań w tym projekcie to:
- new: nowe zadanie, jeszcze nie zaczęte
- in progress: zadanie w trakcie realizacji
- test: zadanie wykonane w osobnym branchu i przekazane do sprawdzenia testerom
- code review: zadanie zaakceptowane przez testerów, kod gotowy do przejrzenia przez Lead Developera danego projektu
- resolved: zadanie wykonane, kod połączony z główną gałęzią w repozytorium

3) Nonbillable. W Droptica pracujemy w modelu time & material czyli rozliczamy się za czas poświęcony na prace nad projektem. Czasem chcemy wykonać zadania, dodać usprawnienia albo narzędzia projektowe, o które klient nas nie prosił. W takim przypadku zadanie jest wykonywane w ramach projeku Nonbillable i klient za ten czas nie płaci. W tym projekcie logujemy też czas na on-boarding nowego developera na projekcie, tak aby klientci nie ponosili kosztów zmian w zespole. Ogólnie projekt jest po to, aby być fair w stosunku do klienta, aby klient nie płacił za rzeczy których nie zamówił i nie ponosił kosztów wynikających ze zmian w zespole.

W Redmine mamy nie tylko projekty dla klientów, ale także wewnętrzne projekty. Są one podzielone na kilka typów (dodatkowe pole w projekcie z listą wyboru, to pole służy nam do filtrowania danych w raportach):
- development dla klientów
- nonbillable w projektach dla klientów
- projekty wewnętrzne
- marketing
- zadania administracyjne

Od pół roku korzystamy z Jira. System ten pozwala na większą elastyczność i ma ładniejszy wygląd. Po 6 miesiącach mogę powiedzieć, że jest to zmiana na plus i lepiej nam jest realizować projekty z pomocą Jira.

Szybka komunikacja

Często jest potrzeba krótkiej wymiany informacji między osobami w zespole czy zespołem i klientem. Jest to z reguły krótkie pytanie dotyczące realizowanego zadania. W tym przypadku wygodniej i szybciej jest napisać bezpośrednio do osoby, która zna odpowiedź w apikacji do czatu niż w zadaniu na Redmine.
W pierwszym okresie działania firmy Droptica używaliśmy do tego czatu na Skype. Założony nył czat grupowy dla całej firmy oraz dla projektów. Po pewnym czasie zaczęliśmy korzystać z HipChat (https://www.hipchat.com/). HipChat oprócz tworzenia czatów oferuje integracje. Mogliśmy w jednym miejscu mieć rozmowy dotyczące projektu i np. powiadomienia z Redmine oraz Github czy Bitbucket. Zmiana Skype na Hipchat była dużym ulepszeniem przepływu informacji dotyczących projektu.

W tym roku postanowiliśmy spróbować aplikacji Slack (https://slack.com/) do naszych wewnętrznych potrzeb (wcześniej okazyjnie używaliśmy Slacka na projektach klientów, gdzie klient dodawał nasz zespół do swojego Slacka). Początkowo używaliśmy Slacka na kilku projektach. Po kilku tygodniach testów postanowiliśmy się przesiąść całkowicie z HipChata na Slacka.
Slack odnośnie integracji oferuje właściwie te same opcje co HipChat. Jednak w Slacku jest kilka opcji, których brakuje w HipChacie:
- ustawienia powiadomień indywidualnie dla każdego kanału, a w ramach kanału osobno dla aplikacji desktop i aplikacji mobilnej
- bot, który umożliwia np. dodanie przypomnień (np. codziennie o 9 rano komunikat aby zrobić krótkie omówienie projektu)
- opcja "oznacz jako nieprzeczytane". Często w HipChat przy odczytaniu wiadomości na telefonie zapominałem, aby odpowiedzieć jak będę już przy komputerze. W Slacku można zaznaczyć wiadomość jako nieprzeczytaną i nie zapomni się o niej.

Tworzenie kodu

Najwięcej czasu spędzamy na tworzeniu kodu (PHP, CSS/SASS, JS, HTML). Kody są często powtarzalne lub wynikają z innych elementów aplikacji (np wywoływanie metody z klasy). W czasie istnienia Droptica testowaliśmy różne aplikacje wspomagające tworzenie kodu (środowiska programistyczne). Początkowo używaliśmy Netbeans i Eclipse. W pewnym momencie przeszliśmy na Sublime wraz z pluginami dla PHP i Drupala. Jednak od ponad roku używamy PHPStorm i według nas jest to obecnie najlepsze środowisko programistyczne dla PHP oraz dla Drupala. Nie jest to darmowe oprogramowanie, jednak jego możliwości znacznie skracają czas pracy przy tworzeniu kodu. Zdecydowanie polecamy inwestycję w PHPStorm (można za darmo przetestować przez 30 dni), aplikacja ta zwiększa naszą szybkość tworzenia kodu.

W kolejnych wpisach na blogu napiszemy m.in.  pracy z repozytorium, konfiguracji serwerów, testowaniu aplikacji.