Scroll to top
en pl

Co zrobić, gdy JIRA już nam nie wystarcza


Armin Orlik - 13 września 2017 - 0 comments

Jira jest narzędziem wyjątkowo lubianym przez zespoły deweloperskie (i nie tylko). Umożliwia śledzenie i poprawę błędów w łatwy i stosunkowo tani sposób. Współpraca w ramach tego procesu jest dość prosta. W momencie gdy dołączają nowi członkowie, nasz workflow staje się bardziej skomplikowany. Samo śledzenie i poprawienia bugów to zbyt mało.

Musimy pomyśleć o zarządzaniu wymaganiami, testami oraz artefaktami. W każdej chwili musimy wiedzieć z jakim wymaganiem wiąże się zgłoszony błąd oraz w jakim jeszcze innym miejscu to wadliwe rozwiązanie jest wykorzystywane. Jaki ma wpływ wprowadzenie kolejnej zmiany? Kto powinien zdecydować o tym co zrobić, kiedy otrzymamy prośbę zmiany?Jak utrzymać całą dokumentację aktualną, kiedy przez projekt przewijają się ciągłe zmiany, błędy, różne zespoły i dostawcy?

Dopasowanie systemu Jira do własnego systemu pracy

Bez względu na to czy w swojej pracy wykorzystujemy model Agile czy Waterfall, nasz typowy workflow będzie się zwykle składał z pięciu etapów: pomysł, prognoza, rozwój, implementacja i wprowadzenie. Jira świetnie radzi sobie w trzech ostatnich fazach. Bez instalacji płatnych dodatkowo rozszerzeń nie będzie łatwe wsparcie w dwóch pierwszych etapach.

Aby rozszerzyć zastosowanie systemu Jira na cały proces developmentu możemy posłużyć się wtyczkami z rozszerzeniami które dostępne są w sklepie Jira. Tu warto pamiętać o następujących kwestiach:

  • po podliczeniu kosztów dodatkowych opłat licencyjnych może się okazać, że koszt oprogramowania jest znacznie wyższy niż początkowo planowany,
  • konfiguracja i utrzymanie systemu może być tak skomplikowane, że będziemy musieli zatrudnić zewnętrznego specjalistę do nadzoru nad funkcjonowaniem,
  • musimy pamiętać o ciągłych aktualizacjach wszystkich dodatków,
  • w razie gdy pojawią się jakieś problemy z działaniem to do kogo zwrócić się właściwie o pomoc, do producenta Jira czy twórców zainstalowanych dodatków?

Jeśli nie kolejne rozszerzenia, to co?

Zastanówmy się zatem, co możemy zrobić, gdy Jira nie spełnia wszystkich naszych oczekiwań. W pierwszej kolejności możemy zainwestować w zakup i implementację nowego, mocniejszego narzędzia, ale wówczas stracimy środki zainwestowane dotychczas w system Jira. Oczywiście warto również zauważyć, że deweloperzy zdążyli się już przyzwyczaić do poprzedniego systemu. Innym wariantem jest rozszerzenie Jira tak, aby obejmowała cały cykl pracy od etapu koncepcyjnego do fazy wykonania. W takiej sytuacji:

  • Musimy mieć scentralizowany sposób na dostęp do zarządzania wszystkimi działaniami, które generuje projekt: wymagania, testy, zgłoszenia i inne elementy rozwoju,
  • Wszystkie działania rozwojowe mogłyby być automatycznie połączone — od  wymagań, przez testy, po zgłoszenia dając nam możliwość śledzenia zmian w przeszłości i przyszłości,
  • Lepsze śledzenie zmian ułatwiłoby osiągnięcie zgodności z przepisami w kwestii jakości i nadzoru.
  • Komunikacja między wszystkimi zespołami byłaby uproszczona i usprawniona.

Jednym ze sprawdzonych sposobów, który pozwoli nam zrealizować wymienione zadania, jest integracja Jira z systemem Helix ALM, otrzymamy pełny przekrój informacji o całym procesie tworzenia produktów.

Jednym z ciekawszych na rynku rozwiązań może być Helix ALM, który łatwo integruje się z Jira. Helix ALM dzięki modułowej strukturze produktu, pozwala wybrać tylko to czego dokładnie potrzebujemy w danej chwili bez potrzeby nadmiernej inwestycji w rozwiązanie o możliwościach, których jeszcze nie potrzebujemy.

Aby dowiedzieć się więcej o rozszerzeniu możliwości systemu Jira o funkcjonalności do zarządzania wymaganiami i przypadkami testowymi warto zapoznać się z materiałem: “Beyond Bug Tracking with Jira”. Jeśli masz więcej pytań i chciałbyś porozmawiać z polskim inżynierem o tym jak wykorzystać narzędzia wspierające proces rozwoju aplikacji zapraszamy do kontaktu.

 

Related posts