Praca w Globemie jest ciekawa i rozwijająca. Poniżej znajdziecie krótkie opisy kilku obszarów, które przybliżą Wam, co i jak robimy:
Wojtek brał udział w realizacji modułu do generowania schematów sieci optycznej. Implementacja szczegółowych wymagań użytkowników wiązała się z rozwiązywaniem złożonych problemów algorytmicznych i architektonicznych zarysowanych poniżej.
Ogólne wymaganie:
- wszystko musi być rysowane ortogonalnie
- każdy schemat musi być możliwy do wydrukowania.
Zadanie Cable plan – wersja uproszczona
Mając dany potencjalnie dość duży (setki węzłów), nieskierowany multigraf z cyklami (wiele krawędzi między tymi samymi węzłami), należy wygenerować jego reprezentację graficzną.
Przy czym:
- krawędzie są etykietowane co najmniej dwoma napisami (na początku i końcu), rozmiar etykiet nie jest znany z góry, etykiety mogą być wieloliniowe
- węzły nie są punktowe, muszą mieć etykietę w środku, długość etykiet (a w związku z tym i rozmiar węzłów) jest zmienna
- wygenerowany obrazek musi być łatwy do wydrukowania na arkuszach o zadanym rozmiarze (np. od A4 do A0+), powinien zajmować ich jak najmniej nie tracąc przy tym na czytelności,
- wygenerowana reprezentacja o ile to możliwe powinna być planarna, jeśli nie uda się tego osiągnąć, to ilość przecięć powinna być minimalizowana (niekoniecznie minimalna).
Algorytmicznie: drzewa rozpinające, eliminacja cykli, drzewo „trójkątne”.
Zadanie Cable plan – wersja dla klienta z Danii
Zadanie jak wyżej z rozszerzonymi wymaganiami:
- końce krawędzi są dodatkowo etykietowane kolorami (czerwony, zielony, niebieski, biały), w zależności od pary kolorów krawędź musi mieć pewne właściwości, np. czerwone końce krawędzi zawsze wychodzą z węzła po prawej stronie, niebieskie po lewej, zielone na górze lub na dole w zależności od koloru po drugiej stronie,
- krawędzie nie powinny zawracać, jeśli wychodzi w lewo, to węzeł docelowy powinien być po lewej stronie,
- cykle muszą być rysowane nawet jeśli przecinają cały schemat na skos,
- ilość informacji w etykietach jest dodatkowo rozszerzona (większe węzły),
- krawędzie mają różny priorytet, ważne mogą być rysowane lepiej kosztem mniej ważnych.
Algorytmicznie: eliminacja cykli z uwzględnieniem priorytetów (NP), wyszukiwanie drogi (A*, wyprowadzone do C/C++ dla wydajności).
Zadanie Splice plan – rozwinięcie wersji uproszczonej i wersji dla klienta z Danii
Węzeł w naszym multigrafie ma wnętrze. Wnętrze określa w jaki sposób są między sobą połączone krawędzie, przy czym każda krawędź składa się z wielu włókien (od 2 do 2xx), a każde z nich może być połączone do dowolnego innego włókna.
Wymagania:
- połączenia muszą być rozłożone na możliwie małej powierzchni
- włókna mogą się przecinać tylko pod kątem prostym, niedopuszczalne jest stykanie się włókien rogami (nie wiadomo wtedy jak biegnie trasa)
- rozłożenie krawędzi musi być identyczne na splice planie jak na cable planie.
Algorytmicznie: A* z priorytetami i nawracaniem.
Problemy i wymagania:
- BARDZO duża ilość danych do przetworzenia,
- dane są wielokrotnie używane ale mogą się dezaktualizować („stale handle”),
- ponowne śledzenie z tymi samymi danymi wejściowymi powinno trwać rzędy wielkości krócej niż pierwsze śledzenie,
- wysoka odporność na błędy w danych (rozspójnienia, sytuacje „niemożliwe”).
Kwestie algorytmiczne:
- zadanie optymalizacyjne,
- sprytny sposób zapamiętywania wyników śledzenia,
- profilowane wyciągania informacji z bazy danych (pobieranie klastrami),
- minimalizacja rozmiaru pamięci używanej przez silnik.
Maciek kieruje projektem aplikacji Logical Network Inventory realizowanej dla General Electric.
Globema to nie tylko praca w Polsce, w Warszawie. W Globemie bierzemy udział w projektach dla firm rozrzuconych po całej Polsce, a nawet całym świecie. Niemcy, Dania, Wielka Brytania, USA, Indie – to tylko niektóre kraje, w których byliśmy prowadząc nasze projekty.
Najciekawszym i chyba najbardziej prestiżowym projektem prowadzonym obecnie w Globemie jest rozwój Logical Network Inventory (LNI) – systemu do projektowania i zarządzania siecią u operatorów telekomunikacyjnych. System tan wykorzystywany jest przez setki użytkowników na całym świecie: Europa, obie Ameryki, Azja, Afryka, Australia – tylko na Antarktydzie nie znajdziesz LNI.
Co więcej, przy LNI nie jesteśmy tylko wykonawcami, lecz sami mamy ogromny wpływ na to, co znajdzie się w kolejnej wersji. Na początku roku Darek był w Stanach, Łukasz w Norwegii, Claire i James z GE odwiedzali klientów w zachodniej Europie. Wszędzie tam staraliśmy się dowiedzieć, czego brakuje użytkownikom LNI, co chcieliby znaleźć w kolejnej wersji, co ułatwiłoby im codzienną pracę. Oczywiście nie byliśmy w stanie odwiedzić wszystkich użytkowników osobiście, dlatego z największymi klientami w pozostałych częściach świata kontaktowaliśmy się mailowo lub organizując telekonferencje. W ten sposób określiliśmy listę funkcjonalności, które powinny znaleźć się w nowej wersji. Mamy nadzieję, że przełoży się to na zadowolenie wszystkich obecnych i przyszłych użytkowników.
Jednak LNI to nie jedyny projekt, przy którym mamy możliwość pracy w międzynarodowych projektach. Często koledzy z Globemy wyjeżdżają pomagać innym firmom przy ich projektach. Marcin pomagał przy projekcie dla Deutche Telecom; Radek, Bartek, Macek, Michał i Janek tworzyli aplikację dla Swisscom; Krzysiek pomaga GE w Cambridge przy tworzeniu aplikacji gazowniczej.
To tylko niektóre projekty, ale jak widać Globema daje spore możliwości rozwoju – zagraniczny projekt pozwala zobaczyć jak działają inne firmy, wielkie korporacje, pozwala podszkolić znajomość języków obcych, a dodatkowo przy dłuższych wyjazdach, mamy możliwość zwiedzenia ciekawych zakątków.
Bartek kieruje projektami wdrożeniowymi aplikacji NIMS.
Pracuje w Globemie już sześć lat i choć trudno w to uwierzyć, nie doświadcza nudy czy rutyny. W pracy, poza bardzo dobrą, wręcz rodzinną atmosferą, najbardziej ceni sobie dużą skalę realizowanych projektów. Większość z nich to duże, trwające kilka lub kilkanaście miesięcy projekty o strategicznym znaczeniu dla naszych klientów.
Klienci stawiają wysokie wymagania odnośnie funkcjonalności jak i wydajności oferowanych przez nas rozwiązań. Aby sprostać tym wymaganiom niejednokrotnie musimy stosować bardzo złożone rozwiązania zarówno pod względem architektonicznym jak i technologicznym. Częste kontakty z klientami to okazja na zdobycie doświadczenia w analizie wymagań (również na poziomie procesów biznesowych) nie tylko od strony technicznej, ale również w warstwie komunikacji międzyludzkiej (co jest sztuką samą w sobie).
Dobrym przykładem dużego projektu mającego charakter produktu jest aplikacja NIMS. Spełnienie oczekiwań klienta wymagało napisania aplikacji internetowej, aplikacji mobilnej, aplikacji WinForms oraz API dla innych systemów (w postaci Web Service). Produkt finalny musiał współpracować z różnymi silnikami baz danych (wspieramy bazy Oracle i MS SQL Server), co dodatkowo podniosło poziom trudności.
W naszych projektach stałym elementem jest integracja naszego oprogramowania z innymi systemami IT klienta, np. SAP, aplikacjami CRM, workflow.
W projektach realizowanych w Globemie zawsze można znaleźć coś dla siebie, zawsze jest jakiś obszar, który trzeba odkryć, albo dziedzina wiedzy, z której trzeba się dokształcić. Wyzwań jest wiele. Począwszy od rozwiązywania problemów z ograniczoną ilością pamięci urządzenia mobilnego, przez zaprojektowanie architektury bardzo złożonego systemu, lub intuicyjnego interfejsu użytkownika w ograniczonym środowisku webowym aż do „odkrycia” rzeczywistych potrzeb klienta w procesie zbierania wymagań.
Tworzone przez nas oprogramowanie cechuje się dużą złożonością. Projekty realizowane są zwykle w czasie około roku i pracuje nad nimi zespół złożony nawet z kilkunastu osób. Tak duże przedsięwzięcia wymagają odpowiedniego podejścia do procesu wytwarzania oprogramowania w celu terminowego zakończenia projektu oraz zapewnienia odpowiedniego poziomu jakości dostarczanych produktów.
Inżynieria oprogramowania w Globemie czerpie ze znanych lekkich metodyk prowadzenia projektów, takich jak Microsoft Solution Framework, Feature Driven Development, SCRUM czy XP. Firma wdraża dobre praktyki opisywane w tych metodykach, w celu stałego polepszania jakości oferowanych rozwiązań, a także podnoszenia komfortu pracy pracowników odpowiedzialnych za ich wytwarzanie.
Najważniejszymi wykorzystywanymi praktykami są:
- Iteracyjne podejście do prowadzenia projektu. Projekt jest dzielony na fazy, w każdej z nich wytwarzany jest określony podzbiór funkcjonalności. Każda faza musi być kompletnie przetestowana i udokumentowana.
- Codzienne kompilacje. Produkty są codziennie kompilowane w celu wczesnego wykrycia problemów z kodem, który trafił do repozytorium w ciągu ostatniej doby.
- Przeglądy kodu. Każdy tworzony fragment kodu przed umieszczeniem w repozytorium musi być przejrzany przez inną osobę w celu weryfikacji jego poprawności oraz przekazania wiedzy na temat jego działania.
- Spotkania codzienne. Codzienne, zwykle poranne, spotkania zespołu projektowego mające na celu upowszechnianie wiedzy na temat postępów prac nad projektem wśród członków zespołu.
- Spotkanie retrospektywne. podsumowanie projektu i iteracji jest okazją do rozmowy o tym jakie doświadczenia powinniśmy kontynuować w przyszłości, a co powinniśmy robić lepiej.
Proces projektowania i wytwarzania oprogramowania zakłada duży udział programistów. Są oni angażowani do tworzenia koncepcji, projektów technicznych oraz do oceny pracochłonności zadań. Wśród zespołu promowana jest wiedza na temat całości rozwiązania oraz motywów biznesowych, dla których klient się na nie zdecydował. Dzięki temu programiści i testerzy mogą w pełni świadomie wykonywać swoją pracę, nie będąc skazanymi na mało precyzyjne zadania wykonywane w oderwaniu od większej, logicznej całości.
Globema stara się nadążać za zmianami zachodzącymi w świecie IT. Nowe technologie są rozpoznawane i następnie wdrażane do naszych rozwiązań. W celu zapewnienia wysokiego poziomu kompetencji wśród pracowników ich wiedza jest zwiększana przez udział w szkoleniach, zarówno wewnętrznych, jak i zewnętrznych. Dodatkowo utrzymywana jest „tradycja” cotygodniowych spotkań pracowników działu technicznego, na których omawiane są nowości pojawiające się w firmie w sferach technicznej i formalnej (np. wdrażanie nowych dobrych praktyk).
Mimo wieloletnich doświadczeń, spisanych reguł i procedur a nawet wdrożonego ISO, jesteśmy świadomi, że nasz proces wytwarzania oprogramowania nie jest idealny. Zawsze znajdzie się coś, co można jeszcze ulepszyć. I każdy z nas może mieć w tym swój udział.