Jakich narzędzi używa się na co dzień?
Większość rozwiązań w DisplayLink tworzona jest w języku C++ . Narzędzia wykorzystywane na codzień to Visual Studio, Bugzilla do zarządzania defektami, Subversion do kontroli wersji, CruiseControl zapewniający „continuous integration”, ReviewBoard do przeglądów kodu, system Cognidox do zarządzania dokumentami. Oprócz C++ do kodu produkcyjnego wykorzystywany jest Python do zagadnień takich jak system buildów, testy automatyczne, skrypty testowe i obciążeniowe, itp. Poszczególni developrzy i testerzy korzystają również z różnego rodzaju narzędzi pomocniczych, takich jak dodatki do Visual Studio – np. VisualAssist X, CodeKana, profilery kodu, itd.
Jaką uwagę przykłada sie do jakości w DisplayLink?
Większość oprogramowania powstającego w DisplayLink to sterowniki i serwisy systemowe działające w interakcji z wieloma komponentami systemu. Z tego powodu dość trudne i kosztowne jest testowanie na etapie systemowym. To właśnie dlatego bardzo duży nacisk stawiany jest na wykrywanie jak największej liczby defektów na wczesnych etapach. Już w momencie projektowania danej funkcjonalności projekt rozwiązania jest poddawany przeglądom projektowym i konsultacjom z architektami danych obszarów funkcjonalnych. Na etapie tworzenia kodu mechanizmy wspierające wczesne wykrywanie błędów to testy jednostkowe, przeglądy kodu i system ciągłej integracji.
Jaki wkład będę miał w rozwiązania tworzone w DisplayLink?
DisplayLink zatrudnia developerów, a nie programistów – w praktyce oznacza to że problemy stawiane przed większością pracowników nie sprowadzają się do zaimplementowania zdefiniowanej funkcjonalności, ale do rozwiązania danego problemu.
Wspólnie z poszczególnymi stakeholderami zespoły zaangażowane są w stworzenie rozwiązania, zaprojektowanie go, implementację i produktyzację. Każdy projekt czy funkcjonalność ma przypisanego „właściciela produktu”, który dla zespołu stanowi bezpośredniego klienta zainteresowanego danym projektem.
Sposób rozwiązania rzadko jest narzucany z góry. Przeważnie tworzony jest przez zespół w konsultacji ze specjalistami poszczególnych rejonów funkcjonalnych i architektów.
Czym będę się zajmował jak już zostanę zatrudniony jako Software Developer?
Programiści zatrudnieni w DisplayLink zajmują się implementacją nowych funkcjonalności naszych rozwiązań i poprawianiem wykrytych defektów. Schemat organizacyjny opiera się na strukturze matrycowej, co w praktyce oznacza ze większość zespołów powoływana jest do życia dynamicznie na okres średnio kilku miesięcy potrzebnych na pracę nad danym projektem czy funkcjonalnością.
Oznacza to, że nikt nie zostaje na stałe przypisany do konkretnego zespołu, w którym spędzi następne kilka lat – zamiast tego każdy ma możliwość uczestniczenia w różnorodnych projektach, za każdym razem poznając coś nowego. Nie znaczy to oczywiście, że nie ma osób specjalizujących się w poszczególnych dziedzinach – wręcz przeciwnie, każdy ma wpływ na to, czym chciałby się zajmować i osoby chcące skupić się na danych rejonie są do tego zachęcane – stając się lokalnymi ekspertami w danej dziedzinie.
Jak wygląda organizacja pracy w projektach?
Większość grup projektowych w firmie pracuje korzystając z metodologii Scrum – praca grupowana jest przeważnie w dwutygodniowe sprinty rozpoczynające się spotkaniem, na którym cały zespół planuje co jest do zrobienia przez dane dwa tygodnie. Następnie jest to uzgadniane z osobami, dla których tworzymy to, co w danym sprincie będzie wykonywane.
Ustalenia są zawsze realne – ustalamy co jest do zrobienia przez dane dwa tygodnie, nie oszukując się, że coś co ostatnio zajęło pięć dni tym razem zrobimy w dwa. Podczas trwania sprintu zakres prac, do których zespół się zobligował pozostaje niezmienny – priorytety mogą się zmieniać pomiędzy sprintami, ale nie wewnątrz poszczególnych sprintów.
Każdy sprint powinien kończyć się demonstracją tego, co w danym sprincie zostało osiągnięte – jest to szczególnie ważne na wczesnych etapach pracy nad projektami, gdy wczesny feedback od osób, dla których implementowana jest dana funkcjonalność jest nieoceniony w upewnieniu się, że to co robimy jest tym czego oczekują od nas klienci. Defekty pojawiają się przecież również w fazie definicji wymagań i bez tych sprzężeń zwrotnych można wykonać świetny kawał dobrej, nikomu niepotrzebnej roboty.
Po zakończonym sprincie spotykamy się przeważnie na krótkie spotkanie retrospektywne, gdzie wewnątrz zespołu zastanawiamy się nad tym jak ocenić dany sprint, czy zostały popełnione jakieś błędy ktorych można było uniknąć i czy coś można usprawnić w przyszłości. Dzięki temu ze sprintu na sprint poprawiamy jakość wykonywanej przez nas pracy.
Jakie są możliwości rozwoju w firmie?
Dzięki zastosowaniu dość elastycznej struktury firmy faktyczny awans odbywa się w sposób naturalny – w zależności od chęci i predyspozycji danych osób mogą one organicznie stawać się odpowiedzialne za rejony funkcjonalne lub za mniejsze lub większe projekty i zespoły.
Każdy pracownik ma przypisanego do siebie „line managera”, który odpowiedzialny jest za długofalowy rozwój pracownika. Dzięki tej instytucji uwzględniane są aspiracje i potrzeby poszczególnych pracowników. Oczywiście nie zawsze jest możliwość uwzględnienia potrzeb wszystkich (jest to niestety przykład problemu n-zupełnego), ale staramy się tak dopasowywać pracę do poszczególnych ludzi żeby równocześnie zapewnić jak najlepsze wykorzystanie poszczególnych osób ze względu na prowadzone projekty, jak i dopasować rodzaj pracy do konkretnych osób i ich indywidualnych preferencji i ambicji.
Naturalny rozwój pracowników podparty jest dodatkowo formalnym procesem corocznych ocen pracowniczych i oficjalnych awansów.