Od samego początku organizujemy nasze repozytoria tak, aby odpowiadały potrzebom naszej metody pracy z kodem. Używamy dwóch głownych gałęzi (master i development) oraz wielu dodatkowych gałęzi odpowiadających funkcjonalnościom i poprawkom. Gałąź master odzwierciedla kod środowiska produkcyjnego, natomiast development jest odniesieniem wewnętrznego środowiska programistycznego. Dla każdej nowej funkcjonalności tworzymy odrębną gałąź łącząc ją z elementem backlogu. To podejście pozwala lepiej monitorować postępy. Używamy również ustandaryzowanego nazewnictwa, co pozwala lepiej rozróżniać gałęzie i ich cele. Istotne kroki milowe zamrażamy w formie tagów.
Dajemy pełną wolność wyboru naszym programistom co do używanego IDE i edytora tekstowego ponieważ mamy dobrze ustandaryzowane wymagania dotyczące kodu. Przestrzegamy wewnętrznych standardów dotyczących nazewnictwa, formatowania, ponownego użytkowania kodu, struktury kodu, architektury, organizacji plików w projekcie. To wszystko pozwala nam tworzyć jednolity, czysty i wydajny kod. Używamy głównie dwóch podejść do projektowania rozwiązań w zależności od potrzeb projektowych - FDD (feature driven development) lub TDD (test driven development). Stawiamy również mocno na wzorce projektowe. Na koniec kod refaktoryzujemy i używamy linterów, żeby pozostał optymalny, spełniał nasze standardy i zaspokajał wszystkie potrzeby projektowanego rozwiązania.
Każda linia kodu, którą dodajemy do naszych głównych gałęzi jest podwójnie sprawdzana. Wykorzystujemy metodę krzyżowych weryfikacji przez programistów. Sprawdzamy kod z wielu perspektyw - od kwestii architektonicznych, przez strukturę, złe wzorce, problemy z nazewnictwem i formatowaniem po literówki. Dzięki temu możemy wyłapać potencjalne zagrożenia na etapie projektowym, zoptymalizować kod i uczynić bezpieczniejszym jeszcze przed etapem testów. Zdarza się, że musimy czasem wycofać zmiany i przemyśleć sposób rozwiązania usuwając pull request. Ale lepiej jest zrobić to na etapie przeglądania kodu, niż stwarzać problemy na produkcji.
Ostatnim krokiem, a zarazem najważniejszym krokiem jest testowanie. Podczas developmentu kod przechodzi testy jednostkowe i integracyjne. Następnie używamy testów automatycznych z przygotowanych wcześniej scenariuszy i testów manualnych. Jeżeli wszystko pójdzie bezbłędnie jesteśmy gotowi złączyć kod z gałęzią developerską i przygotować drugi pull request do środowiska produkcyjnego, gdzie kod z wielu gałęzi zostanie poddany ponownie procesowi testowania.
Dla każdego projektu tworzymy w pełni zautomatyzowane mechanizmy ciągłej integracji i ciągłego wdrożenia (wykorzystując między innymi Azure Pipelines and Azure Artifacts). Od 2019 roku wszystkie nasze rozwiązania wdrażamy z wykorzystaniem kontenerów zgodnych z Docker i Kubernetes.
Naszym nadrzędnym celem jest nie tyle dostarczanie oprogramowania, co realne adresowanie potrzeb i rozwiązywanie problemów naszych klientów. Zanim zaczniemy wspólnie tworzyć wizję funkcjonalności oprogramowania przeprowadzimy głęboką analizę, którą ujawnimy potrzeby. Następnie ułożymy je według priorytetów na podstawie wartości biznesowych. Będziemy również szukali ścieżek do optymalizacji działania Twoich procesów biznesowych, nie tylko z perspektywy samego oprogramowania.
Kluczową wartością we współpracy z klientami nieposiadającymi wiedzy technologicznej jest dla nas przybliżenie ich do technologii tak bardzo, jak to tylko możliwe. Dlatego poświęcamy dużo czasu i uwagi starannemu tłumaczeniu każdego etapu procesu powstawania oprogramowania. Służymy również doradztwem tak, aby podejmowane decyzje projektowe były w pełni świadome i podejmowane na podstawie zrozumiałych wartości.
Wielu klientów boi się ujawnienia budżetu na wczesnej fazie projektu sądząc, że wpłynie to negatywnie na wycenę projektu. To najczęstszy błąd i przyczyna frustracji w procesie tworzenia oprogramowania. Realne zdefiniowanie budżetu pozwala spojrzeć na potrzeby funkcjonalne z wielu perspektyw. Posiadając świadomość ograniczonego budżetu możemy szukać rozwiązań bardziej ekonomicznych, które być może nie będą w pełni satysfakcjonujące, ale na tym etapie zaadresują potrzeby i będą wystarczające. Wraz ze wzrostem wartości biznesowej całego przedsięwzięcia obszary te mogą zostać rozwinięte, jednak nie musi się to wydarzyć od razu. Istnieje kilka sprawdzonych rozwiązań pozwalających na kontrolowany sposób zarządzania budżetem - przedstawimy je i pomożemy w tym zadaniu jak tylko się poznamy.
To jedna z najczęstszych obaw, jaka pojawia się na wczesnym etapie rozmów o realizacji nowego projektu. W skrócie: nie. Zwinne podejście do projektu nie wyklucza postawienia sobie jasnych celów i punktów na osi czasu, które mają zostać osiągnięte. Natomiast częste i małe iteracje projektowe pozwalają szybciej otrzymać pożądane funkcjonalności przy zmniejszonym budżecie. Połączenie lean developmentu z ciągłą walidacją wymagań i założeń idealnie weryfikuje wcześniejszą analizę potrzeb. De facto analiza postępuje wraz z rozwojem projektu i w sposób naturalny optymalizuje jego zakres ograniczając zbędne kroki.
Jeżeli nasze portfolio nie jest wystarczającym argumentem chętnie przeprowadzimy prezentację możliwości technologicznych i porozmawiamy o wyzwaniach, które napotkaliśmy przez lata pracy nad innymi projektami i sposobu, w jaki znaleźliśmy rozwiązania problemów, które pozornie były nierozwiązywalne.
W komunikacji z klientami stawiamy przede wszystkim na szczerość, otwartość i transparentność. Pozwala to uniknąć niedopowiedzeń przy jednoczesnym budowaniu trwałego, obustronnego zaufania.
Na każdy projekt patrzymy w dwóch skalach - mikro i makro. W skali makro określamy kamienie milowe dotyczące modułów i obszarów funkcjonalnych, które chcemy osiągnąć w konkretnej kolejności i punktach na osi czasu projektu. W skali mikro zarządzamy zadaniami w iteracjach nie dłuższych niż 2 tygodnie, przez co w pełni panujemy nad etapem realizacji i możemy dynamicznie reagować, na pojawiające się zagrożenia przez np. zwiększenie wewnętrznego zasobu.
Wdrożenie nie jest ostatnim etapem cyklu rozwoju oprogramowania w aveneo. Pomagamy w szkoleniach i treningach użytkowników. Jesteśmy do tego najlepszym partnerem, ponieważ znamy wszystkie założenia projektowe i pełną mechanikę dostarczonego rozwiązania. Da to gwarancję satysfakcji i zrozumienia rozwiązania, a przy okazji pozwoli zebrać wnioski od użytkowników dotyczące potencjalnych optymalizacji i nowych funkcjonalności.
W przypadku dużych projektów trudno jest zebrać wszystkich interesariuszy na każdym spotkaniu. Pojawiające się oczekiwania różnych działów, które wzajemnie się wykluczają, są rzeczą zupełnie naturalną. Naszą rolą jest zebrać wszystkie potrzeby i zaprojektować takie rozwiązanie, które uwzględni wszystkie procesy biznesowe, a te stojące w wzajemnej opozycji pogodzi w spójną i logiczną całość.
To zupełnie normalne! Każda inwestycja niesie pewne ryzyko. W zależności od źródła obaw należy wdrożyć dodatkowy poziom zabezpieczeń. Z naszej strony postaramy się znaleźć takie narzędzia, które pozwolą pozbyć się stresu i zagwarantują sukces projektu. Przykładowo jeżeli obawy dotyczą zakresu funkcjonalnego sugerujemy wskazanie najbardziej wartościowych funkcjonalności i zbudowanie małego wycinka oprogramowania, a następnie walidację założeń i sprawdzenie w realnym środowisku, czy rozwiązanie jest satysfakcjonujące.