Linear, śledzenie zadań bez ceremonii

Linear, narzędzie, w którym nie klika się myszą

Narzędzia do śledzenia zadań mają skłonność do rozrastania się: pola niestandardowe, przepływy z ośmioma stanami, formularze wymagające wypełnienia przy każdej zmianie. Po roku wypełnianie zgłoszenia trwa dłużej niż naprawienie usterki.

Linear idzie w przeciwną stronę. Zestaw pojęć jest wąski, każda czynność ma skrót klawiszowy, a interfejs reaguje natychmiast, bo zmiany zapisują się lokalnie i synchronizują w tle. To brzmi jak szczegół, a decyduje o tym, czy zespół faktycznie aktualizuje stan zadań.

Pojęcia, których jest niewiele

Zgłoszenie to podstawowa jednostka pracy. Ma tytuł, opis, stan, osobę odpowiedzialną i ewentualnie oszacowanie. Nie ma dwudziestu pól wymaganych, bo większość rzeczy wynika z kontekstu.

Cykl to okres, zwykle tygodniowy albo dwutygodniowy, w którym zespół pracuje nad wybranym zestawem zgłoszeń. Zadania nieukończone przechodzą do następnego automatycznie, więc nikt nie przenosi ich ręcznie.

Projekt to większa całość rozciągnięta na kilka cykli, z terminem i postępem liczonym z ukończonych zgłoszeń. Inicjatywa grupuje projekty, gdy organizacja jest większa.

Ten podział wystarcza w większości zespołów i to jest jego zaleta. Narzędzie pozwalające zbudować dowolny proces kończy się procesem, którego nikt nie rozumie, a tutaj ram jest tyle, że decyzji do podjęcia zostaje niewiele. Ograniczenie bywa zresztą cechą, a nie brakiem, bo oszczędza kwartalnych dyskusji o tym, jak powinien wyglądać przepływ.

Skróty i tempo pracy

Cała obsługa jest przystosowana do klawiatury i to nie jest dodatek, tylko główny sposób pracy.

Utworzenie zgłoszenia, zmiana stanu, przypisanie osoby, dodanie etykiety i przejście do wyszukiwania mają jednoliterowe skróty. Po tygodniu ręka sięga po nie odruchowo, a aktualizacja stanu przestaje być czynnością wymagającą decyzji.

To ma konsekwencję, którą łatwo przeoczyć. Narzędzie, w którym aktualizacja zajmuje sekundę, jest aktualizowane. Narzędzie wymagające otwarcia formularza i wypełnienia trzech pól jest aktualizowane w piątek po południu, jeśli w ogóle, a wtedy tablica pokazuje stan sprzed tygodnia.

Wyszukiwanie działa na tej samej zasadzie: jedno okno, w którym wpisujesz cokolwiek i przechodzisz tam, gdzie chcesz. To zastępuje nawigację po strukturze projektów, której przy stu zgłoszeniach nikt nie pamięta.

Integracja z repozytorium

Powiązanie zgłoszeń ze zmianami w kodzie działa przez konwencję nazewnictwa, a nie przez ręczne klikanie.

Gałąź nazwana identyfikatorem zgłoszenia wiąże się z nim automatycznie. Propozycja zmian otwarta z tej gałęzi przenosi zgłoszenie w stan przeglądu, a scalenie przenosi je w stan ukończony. Nikt nie musi pamiętać o zmianie statusu, bo wynika ona z tego, co faktycznie się wydarzyło.

git checkout -b piotr/PRJ-118-obsluga-zwrotow

Ta konwencja rozwiązuje najczęstszy problem narzędzi do śledzenia zadań: rozjazd między tym, co pokazuje tablica, a tym, co jest w repozytorium. Skoro stan wynika ze zdarzeń w repozytorium, rozjazd nie ma jak powstać.

Warto ustawić to na początku, razem z zasadą nazywania gałęzi. Zespół, który przyjmie ją od pierwszego tygodnia, dostaje aktualną tablicę za darmo. Zespół, który dokłada ją po pół roku, ma trzysta zgłoszeń w stanach nieodpowiadających rzeczywistości.

Samą nazwę gałęzi da się wymusić po stronie repozytorium, zamiast liczyć na pamięć.

#!/bin/sh
galaz=$(git rev-parse --abbrev-ref HEAD)

if ! echo "$galaz" | grep -qE '^[a-z]+/[A-Z]{2,5}-[0-9]+-'; then
  echo "Nazwa galezi musi zawierac identyfikator zgloszenia, np. piotr/PRJ-118-opis"
  exit 1
fi

Ten skrypt zapisany jako zaczep uruchamiany przed wysłaniem zmian zatrzymuje wysyłkę z gałęzi nazwanej bez identyfikatora. Kosztuje kilka linii i usuwa całą klasę zgłoszeń, które zostają w stanie „w toku" mimo scalonej zmiany.

Agenci i serwer MCP

Narzędzie udostępnia dwie rzeczy związane z modelami językowymi i warto je rozróżnić.

Pierwsza to funkcje wbudowane: automatyczne kategoryzowanie napływających zgłoszeń, kierowanie ich do właściwego zespołu i wyszukiwanie po znaczeniu, a nie po słowach. Przy kilkuset zgłoszeniach miesięcznie triage jest zadaniem, które ktoś wykonuje ręcznie, więc jego automatyzacja oszczędza realny czas.

Druga to serwer w protokole MCP, dzięki któremu asystent kodu widzi zgłoszenia i może je aktualizować. Asystent w Cursorze albo w terminalu może wtedy przeczytać opis zadania, nad którym pracujesz, i zaktualizować je po zakończeniu.

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/sse"]
    }
  }
}

Konfiguracja trafia do pliku ustawień Twojego asystenta, a uwierzytelnienie odbywa się przy pierwszym połączeniu, więc w pliku nie ma żadnego klucza. To jest ta właściwość, dla której taki wpis można trzymać w repozytorium.

To zmienia sposób pracy przy zadaniach opisanych przez kogoś innego. Zamiast przeklejać opis do prompta, wskazujesz identyfikator, a asystent czyta treść razem z komentarzami i powiązanymi zgłoszeniami.

Granica jest ta sama co przy każdej integracji tego typu. Treść zgłoszeń pochodzi od ludzi, więc asystent powinien ją czytać, a nie wykonywać, zwłaszcza gdy ma uprawnienia do zmiany stanu.

Przy własnej automatyzacji poza asystentem sięgasz po bibliotekę kliencką, która daje typowany dostęp do tych samych danych.

import { LinearClient } from '@linear/sdk'

const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY })

const zespol = await linear.team('PRJ')
const zgloszenia = await zespol.issues({
  filter: { state: { type: { eq: 'started' } } },
  first: 50
})

for (const z of zgloszenia.nodes) {
  console.log(z.identifier, z.title, (await z.assignee)?.name ?? 'nieprzypisane')
}

Zwróć uwagę na oczekiwanie przy odczycie osoby przypisanej. Powiązane obiekty pobierają się osobnym zapytaniem w chwili odczytu, więc pętla po pięćdziesięciu zgłoszeniach wykonuje pięćdziesiąt jeden zapytań. Przy większych zbiorach warto pobrać powiązania jednym zapytaniem, zamiast polegać na wygodzie tego zapisu.

Triage, czyli skrzynka wejściowa zespołu

Zgłoszenia napływają z kilku źródeł: od wsparcia, od użytkowników, z automatycznych alertów. Bez osobnego miejsca na nie lądują wprost na tablicy zespołu i zaśmiecają widok pracy zaplanowanej.

Triage jest tym miejscem. Zgłoszenie trafia tam, ktoś je przegląda i decyduje: przyjmuje do zespołu, odrzuca, łączy z istniejącym albo odkłada. To zajmuje kilka minut dziennie, a chroni tablicę przed zamianą w listę wszystkiego, co komukolwiek przyszło do głowy.

Funkcje oparte o model przyspieszają ten etap, proponując kategorię, zespół i powiązanie z istniejącym zgłoszeniem. Propozycja wymaga zatwierdzenia, więc ryzyko jest niewielkie, a oszczędność przy kilkudziesięciu zgłoszeniach tygodniowo odczuwalna.

Warto ustalić, kto pełni tę rolę i kiedy. Triage bez przypisanej osoby zamienia się w kolejkę, którą wszyscy widzą i nikt nie rusza, a zgłoszenia leżą tam tygodniami, co jest gorsze niż brak takiego miejsca.

Automatyzacja i integracje

Poza integracją z repozytorium narzędzie łączy się z komunikatorami, systemami wsparcia i usługami monitorującymi.

Najbardziej użyteczne połączenie to komunikator zespołowy. Zgłoszenie utworzone z wiadomości zachowuje odnośnik do rozmowy, więc kontekst nie ginie, a zmiany stanu wracają na kanał. To usuwa najczęstsze pytanie w takich rozmowach, czyli czy ktoś się tym zajął.

Drugie to alerty z monitoringu. Powiadomienie o błędzie tworzące zgłoszenie automatycznie sprawia, że incydent ma ślad, nawet gdy nikt nie zdążył go opisać. Warto natomiast ustawić filtr, bo bez niego jeden powtarzający się błąd tworzy sto zgłoszeń.

Trzecie to własne automatyzacje przez interfejs programistyczny. Zgłoszenia utworzone z formularza na stronie, zsynchronizowane z systemem wsparcia albo tworzone cyklicznie przy zadaniach powtarzalnych. Przy własnym zapleczu, choćby w Hono, to kilkanaście linii kodu.

Ceny

Plan darmowy wystarcza do sprawdzenia narzędzia i do małego projektu, a limit dwustu pięćdziesięciu zgłoszeń wyczerpuje się szybciej, niż się wydaje, bo liczą się też zamknięte. Osób w przestrzeni nie ogranicza natomiast wcale, więc barierą jest tu praca, a nie wielkość zespołu.

Przy wyborze między planami płatnymi rozstrzygają zwykle dwie rzeczy: zespoły prywatne, potrzebne gdy część pracy nie powinna być widoczna dla wszystkich, oraz dostęp gościnny dla osób spoza organizacji. Podstawowe funkcje związane z modelami są dostępne na każdym poziomie.

Rozliczenie roczne jest wymagane przy niższych planach, a wersja miesięczna kosztuje więcej. Przy zespole o zmiennej wielkości warto to uwzględnić, bo elastyczność kosztuje.

Linear kontra alternatywy

Trzeci wiersz bywa niesłusznie pomijany przy małych projektach. Zgłoszenia w repozytorium wystarczają, dopóki zespół liczy trzy osoby, a praca nie wymaga planowania w cyklach. Osobne narzędzie zaczyna się opłacać, gdy pojawia się potrzeba widoku ponad repozytoriami i planowania na kilka tygodni.

Wybór między pierwszymi dwoma wierszami sprowadza się do tego, kto jeszcze będzie tego używał. Narzędzie o wąskim zestawie pojęć jest szybkie dla programistów i za sztywne dla działu prawnego czy kadr, więc w organizacji, gdzie jeden system ma obsłużyć wszystkich, wygrywa konfigurowalność.

Warto natomiast zauważyć, że wymóg jednego systemu dla wszystkich bywa założeniem, a nie potrzebą. Dwa narzędzia dopasowane do dwóch rodzajów pracy kosztują więcej w abonamencie i mniej w czasie, który zespoły tracą na obchodzenie procesu zaprojektowanego dla kogoś innego. Ten rachunek rzadko jest robiony, a zwykle wypada inaczej, niż podpowiada intuicja o porządku.

Migracja z innego narzędzia

Przeniesienie kilkuset zgłoszeń brzmi jak główny koszt, a w praktyce jest najmniejszym.

Import z popularnych narzędzi działa i przenosi tytuły, opisy, komentarze i przypisania. Rzeczy, które się nie przenoszą, to pola niestandardowe bez odpowiednika i stany z przepływu, którego tutaj nie ma. Trzeba więc z góry ustalić, na co mapuje się każdy stan.

Prawdziwym kosztem są przyzwyczajenia. Zespół przyzwyczajony do wypełniania pięciu pól przy każdym zgłoszeniu będzie ich szukał, a ich brak odbierze jako niedostatek narzędzia, a nie jako zamierzoną prostotę. To przechodzi po dwóch tygodniach, ale warto tę fazę zapowiedzieć.

Praktyczna kolejność wygląda tak. Najpierw przenieś jeden zespół i pracujcie tak przez cykl albo dwa. Potem ustalcie, czego faktycznie brakuje, bo połowa rzeczy z listy życzeń okaże się niepotrzebna. Dopiero wtedy przenoś resztę.

Warto też nie przenosić wszystkiego. Zgłoszenia starsze niż rok, których nikt nie ruszał, lepiej zarchiwizować w starym narzędziu niż przenosić do nowego, gdzie od pierwszego dnia będą zaciemniać obraz.

Typowe błędy

Pierwszy to odtwarzanie procesu z poprzedniego narzędzia. Ośmiostanowy przepływ przeniesiony żywcem odbiera całą przewagę, bo wraca ceremonia, przed którą to narzędzie miało chronić.

Drugi to pomijanie konwencji nazewnictwa gałęzi. Bez niej stan zgłoszeń trzeba aktualizować ręcznie, a to znaczy, że po miesiącu jest nieaktualny.

Trzeci to traktowanie cyklu jak terminu. Cykl to okres pracy, a zadania nieukończone przechodzą dalej. Zespół, który traktuje koniec cyklu jak zobowiązanie, zaczyna dzielić zadania sztucznie, żeby zmieściły się w tygodniu.

Czwarty to zgłoszenia opisane jednym zdaniem. To dotyczy każdego narzędzia, a przy asystencie czytającym opis przez serwer MCP staje się widoczne od razu, bo wynik odpowiada opisowi.

Piąty to plan darmowy w projekcie, który ma rosnąć. Limit zgłoszeń liczy też zamknięte, więc wyczerpuje się w kilka miesięcy i wtedy migracja odbywa się pod presją.

Szósty to brak przeglądu zgłoszeń starszych niż kwartał. Lista rośnie, a zadania, których nikt nie zrobi, zaciemniają obraz. Zamknięcie ich raz na kwartał jest tańsze niż udawanie, że zostaną wykonane.

FAQ

Ile kosztuje Linear?

Plan darmowy obejmuje dwa zespoły i dwieście pięćdziesiąt zgłoszeń. Plan podstawowy to dziesięć dolarów za osobę miesięcznie, a plan biznesowy szesnaście, przy czym obie stawki dotyczą rozliczenia rocznego. Wersja płacona co miesiąc kosztuje więcej.

Czym różni się od Jiry?

Ma znacznie węższy zestaw pojęć i jest przystosowany do obsługi klawiaturą, więc aktualizacja stanu zajmuje sekundę zamiast minuty. Jira daje w zamian konfigurowalność, raporty i możliwość obsłużenia procesów spoza zespołu programistycznego, czego tutaj brakuje.

Czy warto przy małym zespole?

Przy trzech osobach i jednym repozytorium zgłoszenia w samym repozytorium często wystarczają. Osobne narzędzie zaczyna się opłacać przy pracy nad kilkoma repozytoriami naraz, przy planowaniu w cyklach i wtedy, gdy ktoś spoza zespołu programistycznego potrzebuje widoku postępu.

Co daje serwer MCP?

Pozwala asystentowi kodu odczytać zgłoszenie razem z komentarzami i powiązaniami oraz zaktualizować je po zakończeniu pracy. Zamiast przeklejać opis do prompta, wskazujesz identyfikator, a wynik zależy wtedy wprost od jakości opisu zgłoszenia.

Czy funkcje AI są w każdym planie?

Podstawowe, w tym kategoryzowanie napływających zgłoszeń i wyszukiwanie po znaczeniu, tak. Rozszerzone możliwości są przypisane do wyższego planu, więc przy wdrożeniu warto sprawdzić, które z nich faktycznie są Wam potrzebne.

Dokumentacja stoi na stronie projektu, a aktualne progi cenowe na stronie cennika.