Feature board
W DisplayLink, jak w każdej innej firmie jest więcej rzeczy do zrobienia niż można w danej chwili zrobić. Aby być zawsze pewnym tego, że firma zajmuje się tym co jest w danym momencie najważniejsze wszystkie rozszerzenia funkcjonalności przechodzą formalny proces, dzięki czemu pracujemy zawsze nad tym co jest naprawdę potrzebne. Każda nowa funkcjonalność zaczyna swój cykl w formie „feature request” – dokumentu opisującego problem do rozwiązania. Opisywane jest tutaj co chcielibyśmy zmienić w naszym rozwiązaniu, jaki jest potencjalny zysk z takiej zmiany, ew. jaki jest koszt niezrobienia danej rzeczy (np. niedostosowania się do zmieniającego się środowiska zewnętrznego).
Na tym etapie nieważne jest jak trudne jest to do zrobienia, czasami zdarza się że dany problem jest niemożliwy do rozwiązania. Wszystkie takie sugerowane funkcjonalności zebrane są w jednej liście wspólnej dla całej firmy. Raz w tygodniu zbiera się grupa reprezentantów poszczególnych grup firmy (Feature Board) i dyskutowane są priorytety poszczególnych elementów. Zanim zostanie podjęta decyzja o tym że dana funkcjonalność zostaje przekazana do implementacji, przeważnie jest ona przekazywana do analizy – wtedy trafia do poszczególnych zespołów gdzie dany problem jest analizowany w kontekście jego wykonywalności, tworzone są też prototypy – trzeba udowodnić że dany problem jest do rozwiązania oraz szacowany jest koszt i czas potrzebny na to żeby dana funkcjonalność została stworzona. Identyfikowane są również ryzyka i niewiadome które mogą stanąć na drodze.
Po takiej analizie Feature Board rozważa ponownie daną funkcjonalność i podejmuje decyzję odnośnie tego jak ważna jest ona dla firmy.
Dzięki temu, że zawsze jasne jest jakie rzeczy do zrobienia czekają na szczycie kolejki wszyscy wiedzą nad czym będziemy pracowali w najbliższej przyszłości. Cały ten proces jest jawny i dostępny dla każdego pracownika – po każdym spotkaniu Feature Board-u rozsyłane są zmiany wprowadzane w danym tygodniu, również aktualna lista jest ogólnie dostępna.
Unit testy
W DisplayLink wszyscy rozumiemy i czujemy potrzebę wykrywania defektów na jak najwcześniejszym etapie. W związku z tym, że testowanie naszych rozwiązań na etapie systemowym jest dość trudne i kosztowne bardzo duży nacisk położony jest na testy jednostkowe kodu. Znaczna większość tworzonych klas posiada towarzyszące im testy jednostkowe weryfkujące funkcjonalność. Również poszczególne komponenty i warstwy tworzone są w sposób umożliwiający testowalność na poziomie kodu źródłowego.
Dzięki promowaniu kultury testów jednostkowych tworzenie testowalnego kodu jest dla wszystkich naturalne i stało się po prostu codzienną praktyką. W połączeniu z przeglądami kodu tworzy to mechanizm obronny, który wiele razy sprawdził się już wyłapując błędy jeszcze zanim trafiły one do wspólnej bazy kodu.
Kultura przeglądu kodu
Jedną z wartości, w które wszyscy wierzymy jest wartość przeglądów kodu w codziennej pracy programisty. Praktycznie każda zmiana kodu trafiająca do wspólnej bazy jest przeglądana przez innego programistę, dzięki czemu wychwytywane są wcześnie dodatkowe defekty, promowana jest wysoka jakość na poziomie kodu źródłowego i dodatkowo propagowana jest wiedza dotycząca poszczególnych fragmentów kodu.
Dzięki temu że przeglądy kodu stosowane są na codzień są one naturalną częścią tworzenia oprogramowania i pomagają nam w utrzymaniu wysokiego poziomu jakości już od najniższego poziomu jakim jest kod źródłowy. Przeglądy kodu odbywają się albo w sposób naturalny, gdzie dwóch programistów siada razem na kilka minut dyskusując zmianę lub przy pomocy lokalnego serwisu ReviewBoard, gdy przegląd kodu odbywa się między osobami, które w danym momencie nie znajdują się w jednym miejscu.
Dług techniczny
Rozwój oprogramowania związany jest z odwiecznym balansem pomiędzy szybkością implementacji i „jakością wewnętrzną”, czyli aspektami takimi jak rozszerzalność, testowalność i aspekty architekturalne. Każdy programista z natury chciałby tworzyć kod jak najlepszy i perfekcyjny, a z drugiej strony osoby, dla których ważny jest aspekt biznesowy chciałyby mieć jak najwięcej jak najszybciej. Konflikt interesów stary jak świat towarzyszy prawie każdej firmie tworzącej oprogramowanie.
W DisplayLink uważamy, że najważniejsze jest podejmowanie decyzji na każdym etapie świadomie. Duży nacisk kładziemy na tworzenie rozwiązań, które nie tylko ładnie wyglądają z zewnątrz, ale także pod maską są architektonicznie przemyślane. Na poziomie organizacji promowanie takiego stylu zapewnia kultura code review i instytucja architektów. Prawie zawsze poprawne rozwiązania biorą górę nad szybkimi „hakami” mającymi na celu tylko dotrzymanie terminów za wszelką cenę. Oczywiście czasami zdarza się że niektóre fragmenty systemu mogłyby być zrobione lepiej co nie jest opłacalne w danej chwili. Bardzo dużą wagę przywiązujemy do tego żeby takie decyzje były podejmowane świadomie. Zawsze gdy coś jest robione „na szybko” wiąże się to z udokumentowaniem danego fragmentu i zgłoszeniem defektu architektonicznego opisującego zaciągnięty dług techniczny.
Niezależnie od wszystkich projektów, które są realizowane w danym momencie jest osoba lub grupa, która czuwa nad ogólnymi aspektami architektonicznymi i śledzi poziom zaciągniętego długu, spłacając go, gdy jest to możliwe, ewentualnie negocjując spłacanie przez poszczególne grupy podczas pracy nad konkretnymi projektami. Oznacza to również obserwowanie liczby defektów pojawiających się w różnych rejonach kodu i ewentualne mini projekty refaktoryzacji, gdy zidentyfikowane zostaną rejony, które sprawiają problemy i wtedy z czysto biznesowego puktu widzenia ma sens zainwestowanie pewnego czasu na zrefaktoryzowanie danego obszaru dzięki czemu dalszy rozwój jest szybszy.
Architekci
Większość rejonów funkcjonalnych rozwijanego przez nas systemu posiada jedną lub kilka osób, które odpowiadają za utrzymanie danego rejonu w jak najlepszej jakości architektonicznej. Mimo, że praktycznie nie ma obszarów, do których zmiany prawo mają tylko wybrane osoby to praktykuje się częste konsultacje z architektami poszczególnych komponentów. Szczególnie ważne jest to w przypadku rejonów stanowiących rdzeń architektury systemu.
Obowiązkiem architektów jest dbanie o stan nadzorowanego komponentu, monitorowanie zmian w danym rejonie i decyzje o tym czy planowane zmiany nie naruszają ogólnej architektury. Oznacza to także, że to właśnie architekci wyznaczają kierunki w których powinny architektonicznie zmierzać poszczególne komponenty. Wierzymy, że jedynie ciągłe monitorowanie i dbanie o to, żeby zmiany w architekturze zmierzały w dobrym kierunku można utrzymać stan stale rozwijającego się oprogramowania na wysokim poziomie.
Line management
Struktura zarządzania w firmie oparta jest na formie matrycowej. Każdy pracownik w danej chwili pracuje nad danym projektem i przeważnie odpowiada przed jakimś menedżerem projektu czy team liderem. Czas trwania projektów jest przeważnie dość krótki i trwa kilka miesięcy – każdy projekt powoływany jest poprzez wybranie członków zespołu jak najbardziej odpowiadających specyfice projektu, ludzie więc w naturalny sposób migrują pomiędzy grupami. Niezależnie od tego wszystkiego każdy pracownik ma przypisanego sobie „Line Managera” – jest to osoba która opiekuje się pracownikiem bardziej długofalowo.
Głównym celem line managera jest dbanie o rozwój osób, którymi się opiekują i dbanie o to, żeby nic nie stało na drodzeich rozwoju. Między line managerem i jego podwłądnymi tworzy się zrozumienie kierunku kariery, w którym dane osoby chciałyby się rozwijać, pozwala to na dopasowywanie projektów do poszczególnych osób tak, żeby zarówno jak najlepiej wykorzystać ich potencjał jak i pozwolić im na realizację się w tym, czym chcieliby się zajmować. Line manager również zbiera opinie o swoich podwładnych i dyskutuje z nimi jak są postrzegani, czy w ich pracy można coś udoskonalić, reaguje on również wcześnie na pojawiające się potencjalne konflikty z którymi dana osoba nie jest sobie w stanie poradzić sama.
Polityka jawności
W DisplayLink promujemy politykę daleko posuniętej jawności stanu firmy i zachodzących w niej zmian. Oznacza to w praktyce, że bardzo wiele spraw dotyczących poszczególnych projektów, polityki i strategii firmy jest w pełni jawne dla wszystkich pracowników. Bardzo rzadko zdarza się, że jakieś zmiany nadchodzą niespodziewanie w wyniku odgórnego zarządzenia, o którym wiedziało tylko kilku managerów wyższego szczebla. Przeważnie jawne i jasne jest to jakie aktualnie projekty są prowadzone, jaki jest ich stan i jakie są plany odnośnie bliższej i dalszej przyszłości.
Wierzymy, że gdy każdy z pracowników rozumie jakie są cele i motywacje wszystkiego co dzieje się w danym momencie w firmie, jest on w stanie samodzielnie podejmować lepsze decyzje w jego codziennej pracy. Co dwa tygodnie organizowane jest ogólnofirmowe spotkanie, na którym dyskutowany jest aktualny stan firmy, cele, zagrożenia i postęp prac w firmie.