TaskBeat częstokroć porównywany jest do narzędzi typu Jira lub Mantis, co oznacza że również ja częstokroć pytany jestem o różnice pomiędzy TaskBeatem, a tymi narzędziami. Bardzo trudno odpowiedzieć na takie pytania jednoznacznie, bo to pytania o porównanie jabłek do gruszek. Można rzeczywiście rzeczowo podejść do sprawy i wymienić wszystkie różnice pomiędzy dwoma zupełnie różnymi produktami, których łączy słuszna kwalifikacja do działu „owoce”, albo starać się podejść do tematu od zupełnie innej strony, byćmoże ryzykując trochę wrażenie że chce się ominąć temat.
Spróbujmy. Zarówno Jira jak i Mantis są głównie bug trackerami i z pewnością produktami przeznaczonymi dla konkretnej niszy: tworzenia oprogramowania, co wyjaśnia czemu pytania o porównanie obu produktów istotnie najczęściej padają w środowisku technicznym. Tutaj na samym wstępie należy pamiętać skąd wywodzą się oba produkty, ponieważ sam system ticketowy to jeszcze nie system dedykowany do zarządzania projektami, a biorąc pod uwagę że najczęściej firmy korzystają z jakiegoś systemu zarządzania ticketami oraz jakiegoś systemu do zarządzania projektami można by powiedzieć wręcz że już sam ten fakt dowodzi, że systemy do zarządzania ticketami, a systemy do zarządzania projektami to zupełnie coś innego.
Obrazowo można zilustrować sytuację tak: TaskBeat świetnie się nadaje dla tej części przedsiębiorstwa która myśli w ten sposób: mamy do opracowania trzy gry komputerowe, trzy gry do wdrożenia na rynek oraz trzy gry do wsparcia posprzedażowego. Mantis, Trac czy inny system z kolei świetnie nada się do sytuacji, w której konkretna gra powinna zostać rozpisana na user stories, a w trakcie jej tworzenia powstają konkretne błędy do poprawienia. Podobnie jak nie każdy pracownik w firmie będzie zainteresowany jest meandrami planowania dystrybucji gry, tak samo nie każdy pracownik będzie zainteresowany meandrami poprawek w systemie łączenia silnika wideo i kontrolera gry.
Warto natomiast zauważyć że niektóre systemy próbują wykroczyć poza swoje terytorium komfortu i tak TaskBeat świetnie nadaje się do zarządzania bugami dzięki możliwości wydelegowania obszaru, w którym takie mogą być rejestrowane z dala od strategicznych widoków zarządu. TaskBeat z pewnością może znaleźć zastosowanie tam gdzie zarządzanie zadaniami programistycznymi opiera się na metodologii zwinnej, w której istnieje pewien product backlog, który z kolei drużyna programistyczna organizuje w ramach konkretnych sprint backlogów. W tym zastosowaniu kwestia bezpośredniej integracji z systemem kontroli wersji pozostaje na dzień dzisiejszy otwarta, jednak kwestie zarządzania samym procesem wytwarzania oprogramowania działą znakomicie.
W celu zobrazowania TaskBeat domyślnie proponuje każdemu użytkownikowi rozpoczęcie pracy od wyboru szablonu działalności, co nazywamy szablonami projektów. W przypadku wyboru szablonu działalności typu: software użytkownicy otrzymują na starcie pewien system widoków i przykładowych zadań które predefiniowane są przy pierwszym uruchomieniu aplikacji i mogą być wykorzystywane jako punkt startowy do zdefiniowania konkretnych roadmap i sprintów odpowiadających specyfice danego projektu oprogramowania, nad którym zespół pracuje. Szablon zoptymalizowany jest w ten sposób aby dostarczyć widoki użyteczne zarówno dla kierownictwa działu, jak również i pracowników odpowiedzialnych za sam proces wytwarzania oprogramowania.
Comments are closed.