Wydanie 2.7.1 pozwala uzupełnić dane historyczne z Jiry i Confluence. Uzupełnione dane trafiają do Kalorii, a z Jiry także do Czasu realizacji i Czasu cyklu. Konektor Confluence może pobierać dane po API, bez konfigurowania webhooków, tak jak konektor Jiry od wydania 2.7.0. Administrator widzi w Konfiguracji parametry licencji organizacji i liczbę wykorzystanych kont. Wydanie usprawnia też wybór zakresu dat i pracę na liście użytkowników.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Uzupełnianie danych historycznych z Jiry i Confluence​

Q247 może uzupełnić dane z okresu sprzed podłączenia konektora Jiry albo Confluence. Enterprise Plugin pobiera historię zmian przez API i liczy z niej Kalorie według tych samych zasad co dla danych bieżących. Z Jiry trafiają komentarze, edycje opisu i zmiany statusów ticketów, więc Czas realizacji i Czas cyklu obejmują też tickety utworzone w tym okresie, łącznie z zakończonymi przed uruchomieniem integracji. Z Confluence trafiają kolejne wersje stron i komentarze, które zasilają Kalorie z dokumentacji. Zasięg wstecz, liczony w dniach, ustawia się w formularzu konektora, w polu „Okno backfillu (dni)”.

Pobieranie danych z Confluence po API​

Konektor Confluence ma drugi tryb pobierania danych: bezpośrednio przez API. W tym trybie Enterprise Plugin sam łączy się z Confluence, więc webhooki nie są potrzebne, a integracja działa także wtedy, gdy Confluence nie może nawiązać połączenia z wtyczką. Tryb wybiera się w formularzu konektora opcją „Sposób pobierania danych”, a częstotliwość pobierania ustawia się na co godzinę albo raz na dobę, w nocy. Można wskazać przestrzenie do odpytywania, a pusta lista oznacza wszystkie przestrzenie dostępne dla podanych poświadczeń. Strony zachowują historię po zmianie tytułu i po przeniesieniu do innej przestrzeni. Tryb działa z Confluence Cloud i Confluence Data Center i wymaga Enterprise Plugin w wersji q247-enterprise-plugin-linux-v2.6.0 lub nowszej.

Licencja organizacji w Konfiguracji​

Parametry licencji organizacji są teraz widoczne w Zarządzaniu Organizacją, na stronie Konfiguracja, w pierwszej sekcji „Licencja”. Administrator widzi tam nazwę licencji, datę ważności i ID organizacji, które można skopiować i podać wsparciu Q247 przy sprawach licencyjnych. Panel „Wykorzystanie licencji” pokazuje łączną liczbę kont w statusie Aktywny, z dostępem i bez dostępu, na tle limitu licencji. Nową licencję, otrzymaną od wsparcia Q247, wkleja się w tej samej sekcji, a nowe limity obowiązują od razu po zapisaniu.

---

Usprawnienia​

Poprzednie okresy w wyborze zakresu dat​

Selektor zakresu dat ma nowe gotowe zakresy „Poprzednie 14 dni”, „Poprzednie 30 dni” i „Poprzednie 90 dni”, czyli okres tej samej długości bezpośrednio przed ostatnimi 14, 30 albo 90 dniami. Gotowy zakres obowiązuje od razu po kliknięciu, bez zatwierdzania. W trybie „Niestandardowy” daty można też wpisać z klawiatury, w widoku na komputerze.

Pełna lista osób w oknie „Scal konta”​

Lista w polu „Dodaj nowy alias” doczytuje kolejne osoby przy przewijaniu i pokazuje, ile z nich wyświetlono. Osoba znaleziona wyszukiwaniem trafia na listę za pierwszym kliknięciem.

Wykluczanie commitów przez menedżera zespołu​

Menedżer zespołu może wykluczać ze statystyk commity osób ze swojego zespołu i przywracać je, także w projektach, do których sam nie ma dostępu.

Retencja uwzględnia commity przywrócone do statystyk​

Commit przywrócony akcją „Uwzględnij w statystykach” jest liczony w Retencji (R1, R7, R30, R90), również we wskaźniku R30 w panelu Adopcji AI. Dotyczy to także commitów ukrytych wcześniej przez próg kalorii albo wykluczonych automatycznie, na przykład jako revert.

Wydanie 2.7.0 wprowadza Health Metrics, czyli ocenę kondycji projektów i zespołów. Pięć metryk pokazuje, gdzie metodyka pracy wymaga uwagi, a ocena jest widoczna na Pulpicie, w widoku Zespołów oraz na stronach pojedynczych projektów i zespołów. Kalorie obejmują teraz również pracę w Azure Boards i na stronach Azure Wiki, a dane z Jiry można pobierać po API, bez konfigurowania webhooków.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Health Metrics​

Nowy komponent pokazuje w jednym miejscu, jak wygląda organizacja pracy w projektach i zespołach. Na Pulpicie występuje jako „Przegląd kondycji projektów" i ocenia projekty, do których użytkownik ma dostęp. W widoku Zespołów, pod nazwą „Przegląd kondycji zespołów", pozwala wejść w strukturę organizacji poziom po poziomie. Na stronie pojedynczego projektu lub zespołu pokazuje stan tego węzła razem z metrykami, które wymagają uwagi.

• Pięć metryk kondycji. Q247 ocenia:

  • Zbyt duże PR-y
  • PR bez recenzji
  • Zaległe PR-y
  • Błyskawiczne PR-y, czyli scalone bez recenzji niemal natychmiast
  • Aktywność w nadgodzinach

  Cztery pierwsze metryki liczą się z Pull Requestów, a Aktywność w nadgodzinach ze zdarzeń w commitach i w dokumentacji.

• Ocena projektu i zespołu. Każda metryka dostaje własny stan na podstawie progów organizacji: Zdrowy, Obserwacja albo Krytyczny. Ocena całego projektu lub zespołu to stan najgorszej z ocenionych metryk, więc jedna metryka w stanie Krytyczny wystarczy, żeby cały węzeł był Krytyczny. Metryki bez wystarczającej próbki danych nie biorą udziału w tym wyliczeniu.
• Progi dopasowane do organizacji. Administrator ustawia progi każdej metryki w Zarządzaniu Organizacją, w sekcji Konfiguracja. Po wejściu w edycję obok pól z progami widać rozkład rzeczywistych danych organizacji z ostatnich 90 dni, a znaczniki progów przesuwają się na wykresie już w trakcie wpisywania wartości. Metryki z własnym progiem wartości, czyli Zbyt duże PR-y, Zaległe PR-y i Błyskawiczne PR-y, mają dodatkowy wykres pokazujący, ile Pull Requestów ten próg odcina. Progi domyślne są propozycją na czas wersji beta, dobraną na próbie danych, i nadal je kalibrujemy.

• Stan „Brak danych" dla zbyt małej próbki. Projekt lub zespół, dla którego danych jest za mało, żeby ocena miała sens, otrzymuje osobny stan i własną pozycję w podsumowaniu. Taki węzeł nie wpływa na ocenę pozostałych ani na dobór progów.
• Wykluczanie repozytoriów z oceny. Administrator może wskazać repozytoria, dla których ocena metodyki pracy nie ma sensu, na przykład repozytoria automatyzacji i infrastruktury. Ustawienie znajduje się na liście Źródła, w kolumnie Health Metrics, i można je w każdej chwili cofnąć. Wykluczenie obejmuje wyłącznie Health Metrics, pozostałe statystyki repozytorium pozostają bez zmian.
• Włączanie modułu i zakres widoczności. Health Metrics włącza się przełącznikiem „Pokaż Health Check" w Zarządzaniu Organizacją, w sekcji Konfiguracja. Moduł działa od wersji Enterprise Plugin q247-enterprise-plugin-linux-v2.4.2, udostępnionej w poprzednim wydaniu, a przy starszej wersji komponent pozostaje ukryty. Na Pulpicie widzą go osoby z dostępem do całego projektu, a w widoku Zespołów osoby zarządzające co najmniej jednym zespołem. Każdy widzi kondycję policzoną ze swojego zakresu.

Dowiedz się więcej: Metryki kondycji

Kalorie z Azure Boards i Azure Wiki​

Q247 liczy teraz kalorie także z pracy w Azure Boards i na stronach Azure Wiki. Aktywność z obu źródeł wchodzi do kalorii na tych samych zasadach co praca w Jirze i Confluence, więc widać ją w tych samych widokach i filtrach co dotychczas. Oba źródła podłącza się jednym połączeniem Azure DevOps w Zarządzaniu Organizacją, w sekcji Konfiguracja, a następnie przypisuje do projektów na liście Źródła. Pierwsza wersja obejmuje Azure DevOps Server 2022 w wariancie on-premise.

Dowiedz się więcej: Azure Boards

Pobieranie danych z Jiry po API​

Konektor Jiry może teraz pobierać dane bezpośrednio przez API. Konfigurowanie webhooków po stronie Jiry przestaje być potrzebne, co skraca wdrożenie i zdejmuje zależność od uprawnień administratora Jiry. Częstotliwość pobierania ustawia się w panelu organizacji, co godzinę albo raz na dobę. Tryb działa z Jira Data Center i z Jira Cloud.

Dowiedz się więcej: Sposób pobierania danych

---

Usprawnienia​

Wybór zakresu dat jednym selektorem​

Zakres dat wybiera się teraz w jednym kalendarzu, z gotowymi zakresami 14, 30 i 90 dni. Wybrany zakres obowiązuje na wszystkich widokach i pozostaje zapamiętany po odświeżeniu strony.

Jednolita paginacja​

Przechodzenie między stronami list wygląda i działa tak samo w tabelach, w Obciążeniu pracą, w Health Metrics i w panelu Adopcji AI.

Próg ukrywania przyrostów obejmuje dane historyczne​

Po ustawieniu progu Q247 ukrywa także przyrosty zeskanowane wcześniej. Próg porównuje wartość widoczną na wykresie, czyli kalorie policzone po wykluczeniu wskazanych plików.

Dowiedz się więcej: Działanie na dane historyczne

Usunięcie nazwiska z profilu widoczne we wszystkich widokach​

Po usunięciu nazwiska użytkownika zmiana pojawia się od razu wszędzie, gdzie prezentowane są jego dane, między innymi na liście projektów, w tabelach uczestników i w legendach wykresów.

Wydanie 2.6.2 skupia się na wydajności i stabilności. Widoki analityczne ładują się szybciej, a wykresy i wybór osób działają płynnie również w zespołach liczących tysiące osób. Wydanie uruchamia też zbieranie danych dla metryk kondycji zespołów i projektów (Health Metrics), których widoki udostępnimy w kolejnej wersji.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Wydajność i stabilność​

Szybsze ładowanie danych w widokach analitycznych​

Zoptymalizowaliśmy pobieranie danych na Pulpicie i w widokach analitycznych. W zależności od widoku ładują się one ponad dwukrotnie szybciej, co najbardziej odczują duże organizacje liczące ponad 1500 projektów. Prezentowane wartości pozostają bez zmian. W kolejnych wydaniach obejmiemy optymalizacją kolejne dashboardy.

Wykresy i wybór osób w dużych zespołach​

Na wykresie można teraz dowolnie wybrać osoby z zespołu projektu, które mają być na nim prezentowane. Wyboru dokonuje się na liście rozwijanej określającej zawartość wykresu, która działa płynnie również w zespołach liczących kilka tysięcy osób. Szybciej otwiera się także okno ze szczegółami przyrostów.

Przebudowa obsługi błędów interfejsu​

Obsługę błędów po stronie interfejsu zbudowaliśmy od nowa, żeby ograniczyć sytuacje, w których pojedynczy błąd wyłącza całą aplikację. Zamiast pustego ekranu użytkownik dostaje komunikat i może pracować dalej w pozostałej części widoku. Dotyczy to również Pulpitu, który wcześniej przestawał działać, gdy nie udało się pobrać danych adopcji AI.

Szybsza odpowiedź AI Assistant na pierwsze pytanie​

Pierwsze pytanie w sesji było obsługiwane znacznie dłużej niż kolejne. Czas odpowiedzi wrócił do wcześniejszego poziomu.

---

Nowe funkcjonalności​

Metryki kondycji zespołów i projektów (Health Metrics)​

Wprowadzamy warstwę danych i obliczeń dla nowej grupy wskaźników opisujących kondycję pracy zespołu i projektu. Wskaźniki odpowiadają na pytanie, czy sposób pracy nad kodem nie tworzy ryzyka dla jakości i tempa dostarczania.

Przygotowaliśmy pięć wskaźników:

• udział pracy wykonanej w godzinach pracy skonfigurowanych dla organizacji, który sygnalizuje ryzyko przeciążenia zespołu,
• udział zmian scalonych bez recenzji,
• udział zmian oczekujących na recenzję dłużej niż przyjęty próg,
• udział zmian scalonych tak szybko, że recenzja nie była realnie możliwa,
• udział wysiłku przechodzącego przez zmiany zbyt duże, by dało się je rzetelnie ocenić.

Dane o zmianach zgłaszanych do recenzji pobieramy z GitLab, GitHub, Bitbucket, Gerrit oraz Azure DevOps, w wersjach chmurowych i instalowanych lokalnie. Do platformy nie trafia kod ani treść komentarzy z recenzji, a pobieranie włącza się automatycznie przy dodaniu połączenia do repozytorium.

Widoki z tymi wskaźnikami udostępnimy w kolejnym wydaniu, natomiast zbieranie danych rusza już teraz. Zobaczą Państwo wyniki od razu wraz z historią z tego okresu, bez czekania na napełnienie bazy. Zbieranie danych wymaga aktualizacji pluginu do wersji dostarczanej z tym wydaniem.

Automatyczne skanowanie nowych repozytoriów​

Po włączeniu tej opcji system codziennie wykrywa nowe repozytoria, do których ma dostęp, i obejmuje je analizą bez ręcznej konfiguracji. Do wyboru są dwa tryby: dołączanie wszystkich nowych repozytoriów do projektu powitalnego albo zakładanie dla każdego osobnego projektu o nazwie repozytorium.

---

Usprawnienia​

Statystyki w trakcie przeliczania danych​

Dane statystyczne są cyklicznie przeliczane w tle. Widok pokazuje teraz poprzednie wartości do czasu, aż nowe będą gotowe.

Przyjmowanie danych z systemów źródłowych​

Nietypowy identyfikator uczestnika w paczce zdarzeń nie przerywa już zakładania pozostałych użytkowników z tej samej paczki. Prawidłowo obsługiwane są też repozytoria Azure DevOps, których nazwa projektu zawiera spacje.

Pozostałe zmiany​

• Widok projektu prezentuje Project Managerów jako czytelny tekst zamiast etykiet.
• Wykresy pokazują imiona i nazwiska uczestników w legendzie oraz w oknie ze szczegółami przyrostów. Dane szczegółowe pochodzą z tego samego źródła co wykres.
• Zmiana języka interfejsu odbywa się bez przeładowania strony.
• W zarządzaniu organizacją nazwy stref czasowych są przetłumaczone, a domyślna strefa jest taka sama we wszystkich widokach.
• Sortowanie listy w Adopcji AI obejmuje cały zbiór danych.
• Kolumna z datą ostatniego skanowania w widoku Źródeł pokazuje aktualną wartość również po ponownym uruchomieniu pobierania danych.
• Pola formularzy nie pokazują już nietrafionych podpowiedzi autouzupełniania przeglądarki.

Wydanie 2.6.1 kontynuuje rozwój metryk przepływu pracy wprowadzonych w poprzedniej wersji. Statystyki na kartach projektu, zespołu i uczestnika zyskały nowy wygląd i pokazują teraz zmianę wartości względem poprzedniego okresu. Dodano nowe metryki opisujące tempo realizacji zadań, liczbę zadań w toku oraz rozkład typów wykonywanej pracy, dostępne na poziomie projektu i uczestnika. Wydanie zawiera też usprawnienia wizualne w kilku widokach oraz poprawki stabilności.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Nowy wygląd statystyk z prezentacją zmiany wartości​

Statystyki w widokach Project, Team i Participant mają nowy, ujednolicony wygląd. Każda karta metryki pokazuje teraz zmianę wartości względem poprzedniego okresu o tej samej długości, więc bez dodatkowych porównań widać, czy wynik rośnie, czy spada. Dzięki temu można szybciej ocenić trend, na przykład czy tempo pracy zespołu w ostatnim miesiącu jest lepsze niż miesiąc wcześniej. Zmiana dotyczy prezentacji istniejących metryk, takich jak kalorie, przyrosty, czas realizacji i czas cyklu, bez zmiany sposobu ich liczenia.

Nowe metryki tempa i charakteru pracy​

Do metryk przepływu pracy dodano nową grupę wskaźników widocznych na karcie projektu:

• tempo realizacji zadań, czyli liczba zadań zakończonych w tygodniu,
• łączna liczba zadań zakończonych w wybranym okresie,
• liczba zadań będących w toku na koniec okresu, również w przeliczeniu na jednego dewelopera,
• rozkład zakończonych zadań według typu, na przykład funkcje i błędy (podział typów można dostosować w konfiguracji organizacji i projektu).

Na karcie uczestnika widoczna jest liczba zadań będących w toku na koniec okresu. Wszystkie nowe wskaźniki reagują na wybrany zakres dat i pokazują zmianę względem poprzedniego okresu. Doprecyzowano też komunikaty pojawiające się, gdy metryki przepływu pracy nie są jeszcze dostępne dla danego projektu, na przykład z powodu braku podłączonego systemu do zarządzania zadaniami.

---

Usprawnienia​

Wykres Delivery Tracker działa teraz bardziej przewidywalnie. Legenda pokazuje poprawne imiona i nazwiska uczestników, filtr uśredniania odnosi się tylko do wybranych osób, a wybrane serie danych nie restartują się po zmianie zakładki.

Poprawiono kilka usterek wizualnych w różnych częściach aplikacji. W widoku Adopcji AI ujednolicono skalowanie pasków i sposób wyświetlania danych na wykresach i etykietach. W widoku Workload poprawiono nawigację do szczegółów uczestnika i odstępy między elementami.

Wydajność i stabilność​

Zwiększono stabilność konfiguracji organizacji i przetwarzania danych napływających z systemów źródłowych.

Wydanie 2.6.0 wprowadza metryki przepływu pracy: czas realizacji i czas cyklu. Metryki pokazują, jak szybko zadania przechodzą od zgłoszenia do zakończenia. Są widoczne na karcie każdego projektu oraz na liście projektów w Overview. Organizacje mogą samodzielnie zdefiniować, co oznacza start i koniec cyklu pracy, oraz jakie typy zadań wliczać do metryk. Wprowadzamy też ogólnoorganizacyjny kalendarz dni wolnych i godzin pracy. Wybór zakresu dat został ujednolicony w całej aplikacji: jeden, zapamiętywany selektor w górnym pasku zastępuje osobne filtry na każdej stronie.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Metryki przepływu pracy: czas realizacji i czas cyklu​

Czas realizacji pokazuje, jak długo trwa droga zadania od zgłoszenia do zakończenia. To pokazuje, jak długo biznes czeka na efekt od momentu zgłoszenia potrzeby. Czas cyklu pokazuje tempo samej pracy, czyli czas od faktycznego podjęcia zadania do jego zakończenia. Obie metryki liczone są na podstawie danych z systemu ticketowego używanego przez organizację. Wyniki podawane są w dniach roboczych jako mediana. Metryki są widoczne na karcie każdego projektu oraz jako nowe kolumny na liście projektów w Overview.

Dzięki temu organizacja zyskuje stały wgląd w rzeczywisty czas dostawy i tempo pracy zespołów, bez ręcznego liczenia w arkuszach czy osobnych narzędzi do analizy przepływu pracy. Można też szybciej zauważyć, gdzie w procesie narastają opóźnienia. W Manage Organization administratorzy mogą zdefiniować, co oznacza początek liczenia czasu realizacji (domyślnie utworzenie zgłoszenia) i czasu cyklu (domyślnie moment podjęcia pracy), a także jakie typy zadań mają być wliczane do metryk.

Te ustawienia można nadpisać na poziomie pojedynczego projektu. Wraz z tą funkcją wprowadzamy też ogólnoorganizacyjny kalendarz dni wolnych i godzin pracy. Nowe metryki uwzględniają go od razu, a dotychczasowe statystyki liczone w dniach roboczych będziemy na niego sukcesywnie przełączać w kolejnych wydaniach. Dane do tych metryk zbierane są od momentu aktualizacji Enterprise Plugin.

Globalny selektor zakresu dat​

Wybór zakresu dat został ujednolicony w całej aplikacji. Jeden selektor w górnym pasku, obok przełącznika organizacji, zastępuje osobne filtry na każdej stronie. Można w nim szybko wybrać ostatnie 14, 30 lub 90 dni, albo ustawić zakres własny. Wybór jest pamiętany przy przechodzeniu między widokami i po ponownym zalogowaniu.

---

Usprawnienia​

Ujednolicony wygląd i zachowanie interfejsu: spójne poprawki obejmujące pop-up edycji tabeli, pop-up przypisywania kierowników projektu, layout edycji konta przy długich nazwach zespołów, wykres Delivery Tracker przy braku danych w wybranym zakresie dat oraz wygląd rozwijanych list w górnym pasku.

Wydajność i stabilność​

Zwiększono stabilność widoku Overview i widoków statystyk pod dużym obciążeniem.

Wydanie 2.5.0 wprowadza kluczową funkcję śledzenia adopcji AI w codziennej pracy zespołów deweloperskich - istotną w obliczu dynamicznych zmian, jakie sztuczna inteligencja wprowadza w procesie wytwarzania oprogramowania. Organizacje zyskują wgląd w realną skalę wykorzystania narzędzi wspomaganych AI przy tworzeniu kodu - dane prezentowane są na poziomie całej organizacji, zespołów, projektów oraz pojedynczych uczestników. Dodatkowo doprecyzowano sposób liczenia objętości treści dokumentacji niezależnie od jej źródła oraz rozszerzono widoczność danych o projektach dla wybranych administratorów.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Śledzenie adopcji AI w pracy zespołów deweloperskich​

Q247 zyskuje nowy, kompleksowy widok pokazujący, w jakim stopniu zespoły korzystają z narzędzi wspomaganych sztuczną inteligencją - takich jak Claude Code, GitHub Copilot, Cursor, Aider, Devin czy OpenAI Codex - przy tworzeniu kodu.

Widok prezentuje wskaźnik adopcji AI wraz z trendem w czasie. Pokazuje też wysiłek programistyczny przypisany kodowi tworzonemu z pomocą AI (AI calories) na tle całkowitego wysiłku zespołu (Coding Calories). Uzupełnieniem są zużycie tokenów i koszt w dolarach wynikający z korzystania z narzędzi AI. Widoczne jest również to, jak dobrze utrzymuje się w czasie kod tworzony z pomocą AI w porównaniu do kodu pisanego bez niej.

Dane są dostępne na stronie głównej organizacji, w widoku zespołów oraz w szczegółowych widokach każdego projektu i zespołu, zawsze z możliwością rozwinięcia do bardziej szczegółowych danych.

Administratorzy mogą powiązać konta używane w narzędziach AI z użytkownikami Q247 (domyślnie automatycznie po adresie e-mail, z możliwością ręcznej korekty).

Commit jest rozpoznawany jako stworzony z pomocą AI, gdy w jego opisie (commit message) pojawia się charakterystyczna fraza - domyślnie ustawiona dla każdego wspieranego narzędzia (np. Co-Authored-By: Claude dla Claude Code), z możliwością dodania własnych wzorców rozpoznawania dopasowanych do specyfiki organizacji.

W obecnej wersji funkcja zbiera dane o zużyciu tokenów i kosztach z Claude - jesteśmy przy tym gotowi na kolejne integracje z innymi narzędziami AI, w miarę zgłaszanych przez klientów potrzeb. Funkcja wymaga zaktualizowania Enterprise Plugin do najnowszej wersji, ale nie wiąże się z żadną dodatkową instalacją na komputerach użytkowników.

---

Usprawnienia​

• Spójne liczenie objętości treści dokumentacji - ujednolicono sposób liczenia objętości treści dokumentacji niezależnie od źródła.
• Szersza widoczność Project Managerów dla administratorów na poziomie organizacji - administratorzy z rolą Team Member na poziomie całej organizacji widzą teraz pełną listę Project Managerów w widoku zarządzania organizacją.

Wydanie 2.4.4 wprowadza nowy komponent Workload - heatmapę obciążenia zespołu na widokach Project i Team, która pokazuje rozkład wysiłku programistycznego poszczególnych osób w czasie i ułatwia dostrzeżenie przeciążeń oraz nierówno rozłożonej pracy. Dodaliśmy również możliwość wskazania gałęzi repozytoriów uwzględnianych w analizie, co przekłada się na precyzyjniejsze metryki. Pozostałe usprawnienia podnoszą dokładność i spójność danych analitycznych - m.in. lepsze wykrywanie cherry-picków i natychmiastowe ukrywanie commitów we wszystkich widokach - oraz wzmacniają bezpieczeństwo dostępu do systemu.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

Workload - heatmapa obciążenia zespołu​

Nowy komponent analityczny, który na widokach Project i Team - bezpośrednio pod wykresem Delivery Tracker - pokazuje rozkład wysiłku programistycznego poszczególnych osób w czasie. Każdy wiersz odpowiada jednej osobie, każda kolumna kolejnemu okresowi, a intensywność koloru komórki odzwierciedla poziom aktywności. Dzięki temu jednym spojrzeniem widać, kto jest przeciążony, gdzie praca rozkłada się nierówno i jak obciążenie zmienia się w czasie.

Heatmapa dopasowuje się do kontekstu: korzysta z zakresu dat i typu metryki wybranych dla całego widoku, a skala czasu automatycznie przełącza się między ujęciem dziennym, tygodniowym, miesięcznym i kwartalnym w zależności od długości okresu. Najechanie na komórkę pokazuje szczegóły aktywności danej osoby, a wbudowane wyszukiwanie i sortowanie (po nazwisku lub aktywności, z osobami aktywnymi zawsze na górze) pozwalają szybko odnaleźć potrzebne informacje. Większe zespoły obsługuje paginacja, a stopka podsumowuje kluczowe statystyki - liczbę osób, dni robocze oraz średnie i szczytowe obciążenie. Zakres widocznych osób jest zawsze zgodny z uprawnieniami użytkownika.

Przy okazji ujednoliciliśmy istniejącą heatmapę aktywności na widoku Participant - ta sama skala kolorów i bogatszy podgląd szczegółów - aby porównywanie obciążenia między widokami było spójne.

Wybór gałęzi repozytoriów uwzględnianych w analizie (beta)​

Udostępniliśmy w wersji beta możliwość wskazania, z których gałęzi repozytoriów liczone są commity - globalnie dla wszystkich repozytoriów oraz indywidualnie dla wybranych. Pozwala to pominąć na przykład gałęzie eksperymentalne czy release'owe i uzyskać dokładniejszy obraz pracy zespołu. Na tym etapie funkcja nie ma interfejsu użytkownika i jest uruchamiana na życzenie organizacji; wymaga również najnowszej wersji Enterprise Plugin.

---

Usprawnienia​

• Wzmocnienie bezpieczeństwa uwierzytelniania i kontroli dostępu - zestaw poprawek podnoszących bezpieczeństwo logowania, tokenów i nadawania uprawnień w systemie.
• Wyższa dokładność i spójność danych analitycznych - lepsze wykrywanie cherry-picków (oznaczana jest wyłącznie kopia commita, nie oryginał) oraz natychmiastowe i spójne ukrywanie commitów we wszystkich widokach analitycznych.
• Usprawnienia widoku Participant i logowania - użytkownik bez podwyższonych uprawnień widzi teraz własny komponent OTIF, widok zachowuje wybór „Total Metrics” po odświeżeniu, listy rozwijane otwierają się płynnie, a odzyskiwanie hasła dla kont z logowaniem SSO pokazuje czytelny komunikat.
• Dopracowanie interfejsu i odświeżenie technologii - drobne poprawki spójności tabel, wykresów i ekranów logowania oraz aktualizacja bibliotek interfejsu użytkownika.

Wydanie 2.4.3 wprowadza OTIF Retencję - nową miarę trwałości pracy programistycznej, pokazującą, jaka część wytworzonego kodu utrzymuje się w repozytorium po 1, 7, 30 i 90 dniach. Wskaźnik jest dostępny na widokach Participant, Team i Project oraz w zestawieniach tabelarycznych, dając zespołom i kadrze zarządzającej spójny obraz tego, ile włożonej pracy realnie zostaje w produkcie. Wydanie rozszerza również kontrolę nad jakością danych analitycznych - z możliwością wykluczania wybranych plików z naliczania Coding Calories - oraz dodaje Gitea jako kolejne źródło repozytoriów.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

OTIF Retencja​

Q247 wprowadza OTIF Retencję - nową miarę pokazującą, jaka część wytworzonego kodu faktycznie pozostaje w repozytorium po określonym czasie. Dla czterech okresów - 1, 7, 30 i 90 dni (R1/R7/R30/R90) - wskaźnik podaje procent linii z danego commita, które przetrwały do danego momentu. Wysoka retencja oznacza, że praca ma trwały charakter i realnie buduje produkt, a niska wskazuje kod tymczasowy, wielokrotnie przepisywany lub szybko usuwany - dzięki czemu zespoły i kadra zarządzająca zyskują nowy, obiektywny wymiar oceny wkładu, obok samej liczby zmian.

Wskaźnik dostępny jest jako dedykowany komponent z wyborem zakresu dat na widokach Participant, Team i Project, prezentując wartości R1/R7/R30/R90 dla wybranej osoby, zespołu lub projektu. Te same wartości pojawiają się jako kolumny w zestawieniach tabelarycznych - projektów (Overview, Participant), zespołów (Teams) oraz uczestników (Project, Team) - co pozwala porównywać i sortować trwałość pracy w całej organizacji; domyślnie widoczna jest retencja 30-dniowa, a pozostałe okresy można włączyć w ustawieniach tabeli. Wartości prezentowane są na skali kolorów od najniższej do najwyższej retencji, więc mocne i słabe obszary widać na pierwszy rzut oka, a pomiar pozostaje poprawny niezależnie od sposobu pracy z gałęziami (merge, squash, rebase, cherry-pick).

Dane retencji wyliczane są przez Enterprise Plugin, dlatego wskaźnik zaczyna się wypełniać po jego aktualizacji do najnowszej wersji. Retencja liczona jest również dla wcześniejszych commitów, więc historyczny obraz trwałości pracy jest dostępny od razu, bez czekania.

Wykluczanie wybranych plików z naliczania Coding Calories​

Administrator organizacji może teraz wskazać, które pliki mają być pomijane przy analizie wkładu - na przykład pliki generowane automatycznie, zależności czy wygenerowany kod, które zniekształcają metryki. Konfiguracja dostępna jest w panelu Manage Organization → Configuration, gdzie administrator definiuje dowolną liczbę wzorców nazw lub ścieżek plików i może je swobodnie dodawać, edytować oraz usuwać. Pliki pasujące do dowolnego wzorca nie są wliczane do Coding Calories ani do liczby linii - zarówno w agregatach, jak i na wykresach; commit zawierający pliki wykluczone i pozostałe liczony jest częściowo, a commity złożone wyłącznie z wykluczonych plików znikają ze statystyk i widoków analitycznych. Zmiana wzorców obowiązuje od razu po zapisaniu konfiguracji. Funkcja wymaga aktualizacji Enterprise Plugin do najnowszej wersji - to on skanuje pliki w commitach z uwzględnieniem zdefiniowanych wykluczeń.

Gitea jako nowe źródło repozytoriów​

Do obsługiwanych źródeł repozytoriów dołącza Gitea - zarówno w wersji chmurowej, jak i self-hosted - którą administrator dodaje w panelu Manage Organization → Sources, uwierzytelniając połączenie nazwą użytkownika i tokenem dostępu (Personal Access Token). Repozytoria Gitea są skanowane na tych samych zasadach co pozostałe źródła, więc wszystkie metryki i analizy działają dla nich bez różnic.

Przeniesienie historii przy zmianie projektu repozytorium​

Po zmianie przypisania repozytorium do innego projektu jego dotychczasowa historia aktywności przenosi się razem z nim, z zachowaniem reguł kierujących dane do właściwych projektów. Zestawienia pozostają dzięki temu kompletne i spójne z konfiguracją, bez ręcznego porządkowania danych.

---

Usprawnienia​

Automatyczny mail aktywacyjny przy nadaniu dostępu​

Po nadaniu użytkownikowi dostępu lub utworzeniu konta system automatycznie wysyła wiadomość aktywacyjną - z linkiem do ustawienia hasła dla nowych kont albo z linkiem do logowania dla osób, które hasło już mają. Na formularzu konta widoczna jest informacja, że taka wiadomość zostanie wysłana, o ile automatyczne powiadomienia są włączone.

AI Assistant w języku interfejsu​

Odpowiedzi AI Assistant są teraz zgodne z językiem ustawionym w interfejsie, więc użytkownik otrzymuje analizę w swoim języku bez dodatkowej konfiguracji.

Czytelniejszy status konta​

Status konta oznaczany dotychczas jako „Technical” nosi teraz nazwę „Untracked” (pol. „Pomijany”), co jaśniej komunikuje, że aktywność takiego konta jest pomijana w analizie.

Czytelniejsze podpowiedzi​

Zaktualizowano treść podpowiedzi opisujących metryki oraz oznaczenia commitów, w tym nowy opis dla oznaczenia cherry-pick, dzięki czemu łatwiej zrozumieć, jak interpretowane są poszczególne wartości.

Spójne listy rozwijane i filtry​

Ujednolicono wygląd list rozwijanych oraz sposób prezentacji wartości w filtrach, tak aby interakcja z filtrami i polami wyboru była spójna w całym produkcie.

Stabilniejsza synchronizacja work items​

Usprawniono pobieranie powiązanych zadań (work items) podczas skanowania repozytoriów, dzięki czemu synchronizacja przebiega stabilnie i bez przerywających ją błędów.

---

Poprawki​

• Wybrane filtry są ponownie widoczne w polu filtrowania tabel.
• Treść (message) commitów pustych oraz powstałych przez cherry-pick i revert nie jest już gubiona ani ucinana.
• Eksport tabel do pliku CSV działa również w przeglądarce Safari.
• Poprawny zakres adresów email w tooltipie „others” na widoku Team.

Wersja 2.4.2 Q247 wprowadza integrację SCIM - automatyczną synchronizację użytkowników i zespołów z dostawcami tożsamości (Okta, Microsoft Entra ID, Google Workspace i innymi zgodnymi z SCIM 2.0), z opcjonalnym sterowaniem rolą ADMIN i dostępem do logowania po stronie IdP. Wydanie obejmuje także wykrywanie cherry-pick, rebase i revert w historii repozytorium z możliwością wyłączenia ich z metryk, oraz nową prezentację grupy „Others” w tabelach uczestników z opcją skopiowania listy osób. Pozostałe zmiany to seria zmian mająca na celu poprawę korzystania z tabel i wykresów, konfiguracji źródeł danych, ekranów logowania oraz zwiększenie wydajności widoku Participant w dużych organizacjach.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Nowe funkcjonalności​

SCIM Provisioning - integracja z dostawcą tożsamości​

Q247 obsługuje teraz standard SCIM 2.0 - konta i zespoły są automatycznie tworzone, aktualizowane, dezaktywowane i usuwane na podstawie zdarzeń z dostawcy tożsamości (Okta, Microsoft Entra ID, Google Workspace lub innego systemu SCIM 2.0). Dostawca tożsamości grupuje też użytkowników w zespoły (każda zsynchronizowana grupa pojawia się jako zespół w Q247) i utrzymuje członkostwo w tych zespołach, natomiast układ zespołów w strukturze organizacji (Team Tree), promocja członka na managera oraz przypisania zespołów do projektów pozostają po stronie Q247.

Integrację włącza się w Manage Organization → Configuration → SCIM Provisioning, gdzie Q247 generuje jednorazowy bearer token oraz adres endpointu SCIM do skonfigurowania po stronie dostawcy tożsamości; w razie utraty tokena dostępna jest jego rotacja.

Opcjonalnie administrator może wskazać dwie grupy SCIM: jedna automatycznie nadaje swoim członkom rolę ADMIN (blokując pole roli na profilu), druga decyduje o tym, kto z użytkowników z linkiem IdP może się zalogować - mapowania są od siebie niezależne.

Użytkownicy i zespoły zarządzane przez SCIM są oznaczane fioletowym znacznikiem „SCIM”; dla takich użytkowników zablokowane są pola nazwa, e-mail, status oraz członkostwo w zespołach SCIM, natomiast udział w projektach i członkostwo w zespołach utworzonych ręcznie pozostają edytowalne. Konfiguracja może być dodatkowo zawężona listą dozwolonych adresów IP, a wszystkie operacje SCIM są zapisywane w dzienniku zmian z atrybucją „SCIM”.

Wykrywanie cherry-pick, rebase i revert w historii repozytorium​

Q247 klasyfikuje commit'y powstałe w wyniku cherry-pick, rebase lub revert i pozwala je opcjonalnie wyłączyć ze statystyk metryk aktywności (Coding Calories, Increments, Activity i pozostałych). Mechanizm włącza administrator organizacji za pomocą flagi „wyłącz cherry-pick / rebase / revert z metryk” na poziomie organizacji; po włączeniu sklasyfikowane commit'y są oznaczane jako wykluczone, przestają być wliczane do statystyk teamu, projektu i uczestnika oraz domyślnie nie pojawiają się na wykresie Delivery Tracker.

Klasyfikacja działa na dwa sposoby: po pierwsze na podstawie wiadomości commita - fraza cherry picked from commit w treści oznacza cherry-pick, a fraza This reverts commit oznacza revert (z pierwszeństwem, jeśli commit pasuje do obu reguł); po drugie na podstawie tożsamości commita - jeśli na tym samym remote występuje więcej niż jeden commit o identycznym autorze, dacie autora i identycznej liście zmienionych plików, pierwszy chronologicznie traktowany jest jako bazowy, a kolejne duble jako rebase / cherry-pick.

Analogiczna logika została uruchomiona wstecz na całej bazie istniejących commit'ów, więc historyczne metryki odzwierciedlają nową klasyfikację po włączeniu flagi. Pojedynczy wykluczony commit można ręcznie przywrócić do statystyk z poziomu szczegółów commita na wykresie - wykluczone wpisy są też wyróżnione wizualnie.

Nowa wizualizacja grupy „Others” w tabelach uczestników​

W tabeli Participants po nałożeniu filtra dat grupa „Others” jest teraz rozdzielona na dwie podlisty: uczestników, którzy w wybranym okresie wykonali przynajmniej jeden increment, oraz tych, którzy nie mieli w tym czasie żadnej aktywności. Obok nagłówka każdej z podgrup znajduje się przycisk kopiowania listy adresów e-mail do schowka (jeden adres na linię), co ułatwia szybkie wyodrębnienie zespołu osób aktywnych lub nieaktywnych do dalszej komunikacji poza Q247.

Rozwijany infotip grupy „Others” został też wizualnie ujednolicony z makietą Design System - spójne kolory, tła, font i divider.

---

Usprawnienia​

Domyślnie średnia na wykresie Delivery Tracker - widok team i project​

Po wejściu na widok projektu i teamu wykres pokazuje średnią liczbę kalorii i sumę kalorii wszystkich uczestników. Dropdown wyboru zakresu uczestników na wykresie Delivery Tracker (widoki Project i Team) zmienia opcję „Top 5 participant” na „Top 15 participant” - wybranych po największej łącznej liczbie kalorii w bieżącym zakresie dat.

Edycja pluginów w Manage Organization​

Nazwę istniejącego pluginu można teraz edytować - wcześniej była ona ustawiana tylko przy tworzeniu. Formularz dodawania nowego pluginu został uproszczony przez usunięcie pól, które nie były wymagane do konfiguracji.

Czytelność tabel i wykresów w widokach analitycznych​

Drobne poprawki w tabelach i wykresach: czytelniejszy układ kolumn, ikony filtrów mieszczą się w layoucie, poprawione tooltipy i sortowanie, dokładniejsze nazwy plików przy eksporcie CSV oraz eliminacja krótkich mignięć wykresów przed wyświetleniem skeleton loadera. Stabilniej działają również widgety ulubionych na stronie głównej i ulubione zespoły.

Polska wersja interfejsu​

Uzupełnione i ujednolicone tłumaczenia interfejsu na język polski oraz spójna interpunkcja w komunikatach powiadomień.

Konfiguracja źródeł danych i konektorów​

Walidacja formularzy w Sources (m.in. URL repozytorium GIT_MANUAL i adresy źródeł), wyeliminowane duplikaty na liście źródeł, czytelniejszy multibar przy operacjach zbiorczych, spójne ustawienia domyślnych konektorów dla nowych organizacji. Drobne korekty układu (Client Secret, badge „Not working”, placeholder Increment Visibility).

Logowanie i ekrany kont​

Poprawione komunikaty walidacyjne podczas logowania i aktywacji konta, czytelniejszy układ ekranów MFA i ustawiania nowego hasła oraz właściwie spozycjonowany przycisk GO BACK.

Manage Organization​

W Edit Member status konta można już zapisać po zmianie, a próba zmiany nazwy projektu na pustą jest blokowana komunikatem. Eksport CSV z listy użytkowników wyraźnie rozróżnia statusy Active i Aliased.

Szybsze ładowanie widoku Participant​

Widok Participant ładuje się istotnie szybciej w dużych organizacjach. Zmiana obejmuje zarówno samą kartę uczestnika, jak i tabelę wszystkich projektów.

Wydanie 2.4.1 wprowadza Work Dynamics Indexes - pięć nowych wskaźników aktywności developera (Activity, Presence, Effort, Throughput, Work Rhythm) prezentowanych w tabelach uczestników na widokach Project, Team, Overview i Teams. Zaktualizowano także definicję dni produktywnych: są teraz liczone wyłącznie na dni robocze. W tej wersji administratorzy zyskują możliwość wyłączenia automatycznych notyfikacji, a użytkownicy synchronizację dat między tabelami a wykresami oraz szybki kanał zgłaszania problemów bez konieczności logowania.

Poniżej znajdziesz szczegółowy opis najważniejszych zmian.

---

Work Dynamics Indexes (Indeksy dynamiki pracy) - 5 nowych KPI aktywności developerów​

Tabele uczestników na widokach Project, Team, Overview i Teams pokazują teraz pięć nowych wskaźników aktywności. Activity (średnia z czterech pozostałych) prezentowana jest jako pięciopoziomowy wykres słupkowy z procentowym tooltipem, a tabele są domyślnie sortowane według tej wartości.

• Presence (Zaangażowanie) - pokazuje, jak regularnie uczestnik był aktywny w wybranym okresie. Wyliczany jako stosunek dni roboczych z co najmniej jednym przyrostem do wszystkich dni roboczych w zakresie.
• Effort (Wysiłek) - mierzy intensywność pracy uczestnika. Wyliczany jako średnia liczba Coding Calories na dzień roboczy znormalizowana do progu 50 kcal/dzień (powyżej tej wartości współczynnik osiąga maksimum).
• Throughput (Wydajność) - mierzy przepustowość, czyli liczbę przyrostów na dzień roboczy. Liczony osobno dla kodu i dokumentacji, z różnymi progami normalizacji (1 przyrost kodu lub 10 przyrostów dokumentacji per dzień = 100%).
• Work Rhythm (Rytm pracy) - pokazuje równomierność pracy. Wyliczany jako 1 minus znormalizowane odchylenie standardowe odstępów między aktywnymi dniami uczestnika - im bardziej regularne odstępy, tym wyższy wskaźnik.
• Activity (Aktywność) - syntetyczny wskaźnik aktywności. Średnia arytmetyczna z Presence, Effort, Throughput i Work Rhythm.

---

Productive / Non-Productive Days liczone wyłącznie na business days​

Productive Days, Non-Productive Days oraz Days Between Increments są teraz liczone wyłącznie na dni robocze (poniedziałek–piątek), wykluczając weekendy z bazy obliczeń. Eliminuje to zaniżanie metryk uczestników przy zakresach dat obejmujących soboty i niedziele.

---

Settings w Manage Organization - toggle wysyłki maili powitalnych​

Zakładka Settings w Manage Organization zyskuje nową sekcję, w której administrator może wyłączyć automatyczną wysyłkę maila powitalnego do nowo tworzonych użytkowników - także tych powstających w wyniku aliasowania kont. Domyślnie maile pozostają włączone, więc zachowanie dla istniejących organizacji nie zmienia się.

---

Report An Issue - zgłaszanie problemów bez logowania do JIRA Service Management​

W aplikacji dodano przycisk Report An Issue, który otwiera portal JIRA Service Management z prefilled adresem e-mail użytkownika. Wnioski można składać bez konieczności osobnego logowania w portalu.

---

Domyślny zakres dat na tabelach i wykresach + synchronizacja zmian zakresu​

Tabele i wykresy na widokach Project oraz Team są domyślnie zsynchronizowane co do zakresu dat - zmiana zakresu w jednym miejscu propaguje się do drugiego, a przy zakresach dłuższych niż trzy miesiące pojawia się informacja na wykresie. Na listach uczestników, zespołów i projektów domyślny zakres tabeli to ostatnie dwa tygodnie.

---

Drobne udoskonalenia i poprawki​

• Ujednolicone wyświetlanie imion i maili użytkowników we wszystkich widokach. Nazwy i adresy e-mail prezentowane w aplikacji są teraz spójnie pobierane z profilu organizacyjnego użytkownika, co eliminuje rozbieżności widoczne wcześniej dla kont zaliasowanych lub kont z innym adresem logowania.
• Tooltipy filtrów + kolumna „Last Increment Date" w widoku Users. Ikony filtrów i edycji tabeli pokazują opisowe tooltipy po najechaniu, a tabela Users w Manage Organization zawiera nową kolumnę „Last Increment Date" wspierającą decyzje o statusie kont.
• Poprawki: sortowanie kolumn tabel (polski alfabet i kolumny z chipsami), edycja imienia i nazwiska dla roli Member, race condition powodujący 404 przy szybkim przełączaniu widoków, poprawne przeliczanie Grade po zmianie filtra Coding/Documentation.