Model DORA AI Capabilities: samoocena

Model DORA AI Capabilities wymienia siedem zdolności organizacji, które wzmacniają korzyści z AI w dostarczaniu oprogramowania: jasne i zakomunikowane stanowisko wobec AI, zdrowy ekosystem danych, wewnętrzne dane dostępne dla AI, solidne praktyki kontroli wersji, pracę w małych partiach, koncentrację na użytkowniku i dobre platformy wewnętrzne. DORA nie publikuje punktacji, więc ta strona dodaje skalę dowodów 0–3.

Firma kupiła licencje na agentów dla każdego inżyniera. Pół roku później dwa zespoły dostarczają więcej przy tej samej liczbie incydentów, trzy dostarczają więcej i częściej coś psują, a reszta prawie nie używa narzędzi. Różnicę rzadko robi model. Robi ją organizacja wokół agentów.

Ta strona jest dla CTO lub VP Engineering, który odpowiada za gotowość na AI, dla tech leada, który ocenia jeden zespół, i dla członka zarządu, który decyduje o następnej inwestycji.

Co daje ci samoocena według modelu DORA AI

Siedem zdolności pod dokładnymi nazwami DORA i to, co każda z nich wzmacnia.
Skalę ocen 0–3 z dowodami, które uzasadniają każdą ocenę w organizacji, w której kod piszą agenci.
Kartę oceny do skopiowania i tabelę decyzyjną, która zamienia oceny na kolejne kroki.
Przebieg agenta w trybie tylko do odczytu (Claude Code, Codex, Cursor), który zbiera z repozytorium dowody dla czterech zdolności.

Czym jest model DORA AI Capabilities?

DORA, program badawczy Google Cloud, który stoi za metrykami dostarczania oprogramowania, opublikował model 23 września 2025 roku (Kevin M. Storer i Derek DeBellis, „Introducing DORA’s inaugural AI Capabilities Model”). Wstępną listę zdolności DORA ustaliła na podstawie 78 pogłębionych wywiadów i literatury, a potem sprawdziła ją w badaniu, które objęło prawie 5000 respondentów. Wynikiem jest siedem zdolności, które w istotny sposób wzmacniają albo odblokowują korzyści z AI.

Model ma znaczenie z powodu tego, co pokazały badania z tego samego roku. Zapowiedź raportu DORA 2025 na blogu Google Cloud (Nathen Harvey i Derek DeBellis, 23 września 2025) odnotowuje pozytywny związek adopcji AI z przepustowością dostarczania oprogramowania i z wynikami produktu. Już w następnym zdaniu dodaje jednak, że adopcja AI nadal ma negatywny związek ze stabilnością dostarczania. Wyjaśnienie DORA jest powodem, dla którego w ogóle warto oceniać zdolności: AI przyspiesza wytwarzanie oprogramowania, ale to przyspieszenie może obnażyć słabości na dalszych etapach. Bez solidnych systemów kontroli, takich jak dobre testy automatyczne, dojrzałe praktyki kontroli wersji i szybkie pętle informacji zwrotnej, większy wolumen zmian prowadzi do niestabilności.

Ta sama zapowiedź streszcza główną tezę raportu w jednym zdaniu: AI nie naprawia zespołu, tylko wzmacnia to, co już w nim jest („AI doesn’t fix a team; it amplifies what’s already there”).

Jak ocenić każdą zdolność z modelu DORA AI?

DORA nazywa zdolności i opisuje, co wzmacniają, ale nie publikuje poziomów ani punktacji. Poniższa skala pochodzi z tego serwisu i ma jedną zasadę: ocena liczy się tylko wtedy, gdy możesz podlinkować artefakt, który ją potwierdza. Ocena, którą ktoś „pamięta”, to 0.

Ocena	Etykieta	Dowód, który ją uzasadnia
0	Brak	Nic nie istnieje albo nikt nie potrafi tego wskazać.
1	Doraźnie	Niektóre zespoły to robią, bo mają konkretnych ludzi. Nie ma spisanego standardu.
2	Zdefiniowane	Spisany standard obowiązuje w całej organizacji, ale nic go nie wymusza ani nie mierzy.
3	Wymuszone i mierzone	Kontrola go wymusza (ustawienia zarządzane, kontrola w CI, domyślna konfiguracja platformy), a metryka pokazuje, że działa, i jest przeglądana w stałym rytmie.

Oceniaj każdy zespół osobno, a jako wynik organizacji przyjmij medianę zespołów i wypisz obok zespół z najniższą oceną. Średnia ukrywa zespoły, w których agenci już pogarszają sytuację.

Siedem zdolności z oceną

Przy każdej zdolności: ustalenie DORA, jak wygląda ocena 3, test i strona, która ją buduje.

1. Jasne i zakomunikowane stanowisko wobec AI (clear and communicated AI stance)

Ustalenie DORA (23 września 2025): stanowisko obejmuje oczekiwania wobec użycia AI, wsparcie dla eksperymentów i listę dopuszczonych narzędzi. DORA stwierdziła, że jasne stanowisko wzmacnia pozytywny wpływ AI na efektywność indywidualną i wyniki organizacji oraz może zmniejszać tarcie w pracy. Późniejszy wpis DORA (Nathen Harvey i Allison Park, 10 grudnia 2025) dodaje, że niejasność tworzy ryzyko.

Ocena 3 wygląda tak: jednostronicowe stanowisko mówi, co agenci mogą robić i co zostaje po stronie ludzi, a jego egzekwowalne zapisy wymuszają ustawienia zarządzane (managed settings). Pytanie w kwartalnej ankiecie („Czy wiesz, do czego wolno ci używać agentów?”) jest śledzone.

Test: zapytaj pięciu inżynierów z różnych zespołów, gdzie jest stanowisko i które narzędzia są dopuszczone; pięć zgodnych odpowiedzi z linkiem to 2.

Jak to zbudować: jak przeprowadzić ludzi przez zmianę dla samego stanowiska i polityka korzystania z AI, której inżynierowie będą przestrzegać dla egzekwowalnych zapisów.

2. Zdrowy ekosystem danych (healthy data ecosystems)

Ustalenie DORA (23 września 2025): wysokiej jakości, łatwo dostępne i ujednolicone dane wewnętrzne istotnie wzmacniają pozytywny wpływ adopcji AI na wyniki organizacji.

Ocena 3 wygląda tak: dokumentacja, runbooki, decyzje architektoniczne i kontrakty API mają nazwanego właściciela i zaplanowaną kontrolę aktualności, a dane są sklasyfikowane, więc wiadomo, które klasy agent może czytać.

Test: spośród dziesięciu dokumentów, których agent potrzebuje do typowej zmiany, policz te z właścicielem, aktualizowane w ostatnich sześciu miesiącach i zgodne z kodem; osiem lub więcej to 2.

Jak to zbudować: prywatność danych i polityki firmowe dla klasyfikacji oraz przycinanie plików kontekstu dla aktualności.

3. Wewnętrzne dane dostępne dla AI (AI-accessible internal data)

Ustalenie DORA (23 września 2025): podłączenie narzędzi AI do wewnętrznych źródeł danych zwiększa ich wpływ na efektywność indywidualną i jakość kodu. Wpis z 10 grudnia 2025 nazywa to inżynierią kontekstu (context engineering).

Ocena 3 wygląda tak: każde aktywne repozytorium ma plik instrukcji (CLAUDE.md, AGENTS.md albo reguły projektu w Cursorze) z komendami budowania i testów oraz konwencjami, wewnętrzna dokumentacja i zgłoszenia docierają do agenta przez zatwierdzone serwery MCP o minimalnych uprawnieniach, a zespół platformowy śledzi pokrycie.

Test: prompt do zbierania dowodów (niżej).

Jak to zbudować: dokumentacja jako kontekst dla plików instrukcji, wewnętrzne serwery MCP dla podłączenia systemów firmy i serwery MCP z kontekstem dokumentacji dla gotowych rozwiązań.

4. Solidne praktyki kontroli wersji (strong version control practices)

Ustalenie DORA (23 września 2025): częste commity wzmacniają pozytywny wpływ AI na efektywność indywidualną, a częste korzystanie z funkcji wycofywania zmian (rollback) poprawia wyniki zespołów pracujących z AI.

Ocena 3 wygląda tak: praca agentów trafia do gałęzi domyślnej wyłącznie przez zrecenzowany pull request z wymaganymi checkami, pull requesty z udziałem agenta mają etykietę i można je porównywać jako kohortę, a rollback to przećwiczona operacja o zmierzonym czasie.

Test: prompt do zbierania dowodów plus data ostatniego przećwiczonego rollbacku.

Jak to zbudować: równoległe agenty z Git worktrees dla izolacji i progressive delivery dla rollbacku.

5. Praca w małych partiach (working in small batches)

Ustalenie DORA (23 września 2025): praca w małych partiach wzmacnia pozytywny wpływ AI na wyniki produktu i zmniejsza tarcie w zespołach deweloperskich. Wpis z 10 grudnia 2025: ogromne bloki kodu z AI trudno zrecenzować i przetestować.

Ocena 3 wygląda tak: budżet rozmiaru pull requesta jest w każdym pliku instrukcji i wymusza go kontrola w CI, a mediana rozmiaru i odsetek ponad budżetem są raportowane co tydzień, osobno dla zmian z udziałem agenta i pozostałych.

Test: prompt do zbierania dowodów, z progiem 400 zmienionych linii, który artykuł o kolejce review podaje jako budżet startowy.

Jak to zbudować: wprowadź budżet rozmiaru PR, którego agenci przestrzegają i backlog gotowy dla agentów, żeby dzielić pracę, zanim trafi do agenta.

6. Koncentracja na użytkowniku (user-centric focus)

Ustalenie DORA (23 września 2025): koncentracja na użytkowniku wzmacnia pozytywny wpływ AI na wyniki zespołu. I ostrzeżenie: bez niej adopcja AI może obniżać wyniki zespołu.

Ocena 3 wygląda tak: każde zadanie dla agenta zaczyna się od efektu dla użytkownika i wykonywalnych kryteriów akceptacji, a funkcje mają metrykę efektu i kryterium wycofania.

Test: spośród dziesięciu ostatnich zmian z udziałem agenta policz te, które prowadzą do efektu dla użytkownika z kryteriami akceptacji uruchomionymi w CI.

Jak to zbudować: zarządzanie produktem, gdy budowanie trwa godziny dla intencji i kryteriów wycofania oraz wykonywalne kryteria akceptacji dla kontroli, której agent nie ominie.

7. Dobre platformy wewnętrzne (quality internal platforms)

Ustalenie DORA (23 września 2025): w organizacjach z dobrymi platformami wewnętrznymi pozytywny wpływ AI na wyniki organizacji jest wzmocniony. Zapowiedź raportu DORA 2025 na blogu Google Cloud (23 września 2025) dodaje, że 90% organizacji wdrożyło co najmniej jedną platformę i że istnieje bezpośrednia korelacja między wysoką jakością platformy wewnętrznej a zdolnością organizacji do wydobycia wartości z AI.

Ocena 3 wygląda tak: zespół platformowy prowadzi środowisko uruchomieniowe agentów (harness) jak produkt (ustawienia zarządzane, wspólne reguły, umiejętności, hooki, bramki w CI i telemetria), dostarcza je domyślnie i mierzy adopcję oraz change fail rate zmian z udziałem agenta.

Test: prompt do zbierania dowodów plus jedno pytanie: czy nowe repozytorium dostaje zatwierdzoną konfigurację agentów, bramki i telemetrię bez zgłoszenia?

Jak to zbudować: zespół platformowy agentów, polityka zarządzana dla każdego agenta i wspólne reguły agentów.

Karta oceny zdolności DORA AI do skopiowania

Wklej ją do dokumentu lub arkusza, jedną kopię na zespół. Kolumna Evidence link jest obowiązkowa; pusta komórka oznacza ocenę 0.

# DORA AI capabilities self-assessment
Team: ______   Assessed on: YYYY-MM-DD   Assessors: ______ (lead), ______ (second rater)

| # | Capability (DORA name)             | Score 0-3 | Evidence link | Metric and value      | Builds it (owner, date) |
|---|------------------------------------|-----------|---------------|-----------------------|-------------------------|
| 1 | Clear and communicated AI stance   |           |               | survey: % who know it |                         |
| 2 | Healthy data ecosystems            |           |               | % docs owned + fresh  |                         |
| 3 | AI-accessible internal data        |           |               | % repos with context  |                         |
| 4 | Strong version control practices   |           |               | rollback time         |                         |
| 5 | Working in small batches           |           |               | median PR lines       |                         |
| 6 | User-centric focus                 |           |               | % changes with AC     |                         |
| 7 | Quality internal platforms         |           |               | self-serve: yes/no    |                         |

Lowest score: __  (capability #__)     Disagreements between raters: __
Next move (from the decision table): ______
Re-score on: YYYY-MM-DD (90 days)

Karta zostaje po angielsku, bo nazwy zdolności to oficjalne nazwy DORA i tak łatwiej porównać ją z raportem.

Jak przeprowadzić samoocenę?

Wybierz jednostkę i oceniających. Oceniaj zespołami, każdy przez dwie osoby: tech leada i kogoś spoza zespołu. CTO ocenia zdolności 1 i 7 na poziomie organizacji.
Najpierw zbierz dowody z repozytorium. Uruchom opisane niżej zbieranie dowodów w trybie tylko do odczytu dla zdolności 3, 4, 5 i 7, żeby ocena zaczęła się od liczb.
Oceniajcie niezależnie, potem uzgodnijcie. Każda osoba ocenia sama; różnica dwóch punktów trafia na 20-minutową rozmowę nad dowodami.
Zmapuj strumień wartości dla najsłabszej zdolności. DORA zaleca mapowanie strumienia wartości (value stream mapping): gdy zwizualizujesz przepływ od pomysłu do klienta, zobaczysz, gdzie praca czeka i gdzie powstaje tarcie (Nathen Harvey i Allison Park, 10 grudnia 2025). Zastosuj je do zdolności z najniższą oceną, żeby poprawka celowała w ograniczenie systemu.
Przypisz właściciela i stronę. Każda zdolność poniżej 2 dostaje właściciela, termin i podlinkowaną stronę, która ją buduje.
Oceń ponownie po 90 dniach z tymi samymi oceniającymi i porównaj wynik z metrykami dostarczania opisanymi niżej.

Zbierz dowody z repozytorium za pomocą agenta

We wszystkich trzech narzędziach agent czyta historię Gita, konfigurację CI i pliki instrukcji i niczego nie zapisuje; różni się tylko sposób wymuszenia tego.

Zapisz prompt poniżej jako dora-evidence.md i uruchom go bez interakcji w katalogu głównym repozytorium. --permission-mode dontAsk odrzuca każde wywołanie narzędzia spoza listy dozwolonych, więc przebieg nie może użyć narzędzi Edit ani Write ani uruchomić komendy spoza listy (sprawdzone w Claude Code v2.1.283). git log nadal przyjmuje opcję --output=<plik>, która zapisuje plik, dlatego uruchamiaj go na czystej kopii repozytorium i sprawdź potem git status.

claude -p "$(cat dora-evidence.md)" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Grep" "Glob" "Bash(git log *)" "Bash(gh pr list *)" "Bash(gh api repos/*/branches/*/protection)"

Lista dozwolonych zawęża gh api do komend, które kończą się ścieżką ochrony gałęzi, zamiast gołej reguły gh api, która dopuściłaby też wywołania zapisujące, na przykład gh api -X DELETE. Prompt zabrania zapisów, a sprawdzenie czystej kopii repozytorium i git status nadal obowiązuje.

Serwery MCP, do których Claude Code ma dostęp w tym repozytorium, wypiszesz komendą claude mcp list. Sprawdza ona stan zatwierdzonych serwerów, więc je uruchamia, a niezatwierdzone serwery z .mcp.json pokazuje jako oczekujące; jeśli nie chcesz uruchamiać żadnego procesu, przeczytaj bezpośrednio .mcp.json. Ten wynik to dowód dla zdolności 3.

Uruchom ten sam prompt nieinteraktywnie w piaskownicy tylko do odczytu (sprawdzone w Codex CLI 0.157.1):

codex exec --sandbox read-only -o dora-evidence-result.md "$(cat dora-evidence.md)"

--sandbox read-only to starsza (legacy) flaga, która nadal działa w 0.157.1; w nowych konfiguracjach możesz zamiast niej użyć profilu uprawnień w wersji beta, -c default_permissions=":read-only" (Codex CLI 0.157.1), bez --sandbox; te dwa systemy się nie łączą.

Piaskownica tylko do odczytu nie ma dostępu do sieci (Codex CLI 0.157.1), więc wywołania gh dla zdolności 4 i 5 się nie udadzą; te liczby weź z przebiegu w Claude Code albo z interfejsu GitHuba. Prompt zgłasza lukę zamiast zgadywać.

Serwery MCP skonfigurowane w Codeksie wypiszesz komendą codex mcp list. Ten wynik to dowód dla zdolności 3.

Otwórz repozytorium, przełącz agenta w Plan Mode, który tworzy plan przed napisaniem jakiegokolwiek kodu (Plan Mode według dokumentacji Cursora, sprawdzone 2026-08-28), i wklej prompt. Nie zatwierdzaj potem etapu budowania. Tryb tylko do odczytu jest tu kwestią procedury, a nie wymuszenia, więc uruchamiaj prompt na czystej gałęzi i sprawdź potem git status.

Dla zdolności 3 zapisz serwery z pliku .cursor/mcp.json w projekcie obok list z Claude Code i Codeksa.

You are collecting evidence for a DORA AI Capabilities Model self-assessment. Work read-only: do not edit, create or delete any file, and do not push, comment or label anything on GitHub.

For this repository, report the following. For every number, show the exact command you ran.

Capability 3, AI-accessible internal data:
- Which agent instruction files exist (CLAUDE.md, AGENTS.md, Cursor project rules under .cursor/), their last commit date, and whether they state the build, test and lint commands.
- Which MCP configuration files exist (.mcp.json, .cursor/mcp.json, .codex/config.toml) and the server names in them.

Capability 4, strong version control practices:
- Pull request data: use `gh pr list --state merged --search "merged:>=YYYY-MM-DD" --limit 1000 --json number,additions,deletions,labels,files`, with the date 90 days ago, and report how many pull requests it returned, so a truncated sample is visible.
- Over the last 90 days: merged pull requests, the share with a label containing "agent", and the number of reverts (commits whose message starts with "Revert").
- Whether the default branch requires pull requests and passing status checks (use `gh api repos/{owner}/{repo}/branches/{branch}/protection`; if access is denied, say so rather than guessing).

Capability 5, working in small batches:
- Median and 90th-percentile changed lines per merged pull request over the last 90 days, split into agent-labelled and other, and the share above 400 changed lines. Compute them with gh's built-in jq (`gh pr list ... --json additions,deletions,labels --jq '...'`) and show the jq expression; do not estimate numbers by reading the JSON.
- Whether any CI workflow enforces a pull request size limit.

Capability 7, quality internal platforms:
- Which CI checks run on every pull request, and which of them are defined in a shared or reusable workflow rather than in this repository.

Output a Markdown table with one row per capability: evidence found, numbers, and a proposed score 0-3 using this scale: 0 absent, 1 ad hoc, 2 defined but not enforced, 3 enforced and measured. Mark every proposed score as "proposed" and list what a human must confirm before it counts.

Attached are DORA AI capabilities scorecards from [number] teams, one per team, each with scores 0-3, evidence links and metric values for the seven capabilities.

Produce a one-page organization readout:
1. A table: capability, median team score, lowest team and its score, number of teams at 0-1.
2. Every score that has no evidence link, listed by team. Treat those as 0 in the table and say so.
3. Every capability where the two raters disagreed by two points or more.
4. The three next moves, chosen with these rules: any team with capability 4 or 5 at 0-1 pauses agent expansion; capability 1 at 0-1 means publishing the stance within 30 days; capability 7 at 0-1 with three or more teams using agents means chartering a platform team.
5. For each move: owner role, due date 30, 60 or 90 days out, and the delivery metric that should move if it works (change fail rate, deployment rework rate, median pull request size, or time in review).

Do not rank teams against each other, and do not invent numbers that are not in the scorecards.

Jak zamienić oceny w plan?

Czytaj kartę po minimum, nie po sumie: 17 na 21 z zerem przy małych partiach to większe ryzyko niż 12 bez oceny poniżej 1. Tabela stawia kontrole przed wolumenem; to rekomendacja tego serwisu, a nie DORA.

Jeśli widzisz	Wtedy	Dlaczego
Zdolność 4 lub 5 na poziomie 0–1	Wstrzymaj rozszerzanie użycia agentów w tych zespołach, dopóki obie nie osiągną 2. Zacznij od budżetu rozmiaru PR i ochrony gałęzi.	To systemy kontroli, które wymienia DORA.
Zdolność 1 na poziomie 0–1	Opublikuj stanowisko w ciągu 30 dni.	To najtańsza zdolność i tylko kierownictwo może ją dostarczyć.
Zdolność 6 na poziomie 0–1	Usuń z celów zespołów cele ilościowe (pull requesty, „% kodu z AI”); wymagaj kryteriów akceptacji w zadaniach dla agentów.	DORA stwierdziła, że bez koncentracji na użytkowniku adopcja AI może szkodzić wynikom zespołu.
Zdolności 2–3 na poziomie 0–1, pozostałe 2+	Sfinansuj pracę nad kontekstem: najpierw pliki instrukcji, potem jeden wewnętrzny serwer MCP.	Bez kontekstu firmy agenci pozostają ogólni.
Zdolność 7 na poziomie 0–1 i trzy lub więcej zespołów z agentami	Powołaj zespół platformowy.	Każdy zespół buduje własny harness, a zyski kończą się na granicy zespołu.
Wszystkie siedem na poziomie 2+	Podnieś każdą dwójkę do trójki, dodając kontrolę i metrykę.	Spisany standard, którego nikt nie wymusza, z czasem się rozpada.

Skąd wiesz, że samoocena mówi prawdę?

Ocena gotowości, której nikt nie sprawdza, z czasem sama rośnie. Uczciwą utrzymują ją cztery kontrole.

Dowód albo zero. Ocena bez działającego linku to 0, także przy zdolnościach, za które odpowiada sam CTO.
Dwie osoby oceniające, jedna z zewnątrz. Różnicę dwóch punktów rozstrzyga się na podstawie dowodów, a raport liczy rozbieżności.
Zestawiaj oceny z wynikami dostarczania. Zdolności to nakłady; dowód leży w metrykach dostarczania. Gdy małe partie i kontrola wersji rosną z 1 do 3, change fail rate dla zmian z udziałem agenta powinien się utrzymać albo spaść, a przepustowość rosnąć. Korzystaj z definicji z artykułu DORA, SPACE, DX Core 4 i pomiar AI.
Przetestuj inwestycję, zanim ją skalujesz. Gdy poprawka zdolności jest droga, na przykład zespół platformowy albo program wewnętrznych serwerów MCP, przeprowadź ją najpierw jako pilotaż z punktem odniesienia i regułą decyzji.

VP Engineering zatwierdza raport co kwartał, a jego pierwsze zdanie mówi, że oceny nigdy nie służą do rankingu zespołów ani ludzi.

Co idzie nie tak przy samoocenie według modelu DORA AI?

Każdy zespół daje sobie 2 albo 3. Jak wyjść: zastosuj wstecz zasadę „dowód albo zero”, dodaj oceniającego z zewnątrz i opublikuj, ile ocen spadło.

Suma staje się celem. Kierownictwo ustala „18 na 21 do drugiego kwartału”, a zespoły podnoszą łatwe zdolności, podczas gdy małe partie zostają na 1. Jak wyjść: raportuj minimum i najsłabszy zespół, nigdy sumę.

Samoocena zastępuje metryki. Zespół ma 3 wszędzie, a jego change fail rate rośnie. Jak wyjść: metryki dostarczania są arbitrem, a ocenę, której po dwóch kwartałach nie widać w wynikach, sprawdź ponownie.

Stanowisko zostaje opublikowane i zapomniane. Jak wyjść: opatrz je datą, przeglądaj co kwartał i trzymaj pytanie z ankiety na panelu zespołu.

Zdolność 3 rośnie bez zdolności 2. Agenci podłączeni do każdego wiki wiernie powtarzają nieaktualną dokumentację. Jak wyjść: podłączaj tylko źródła z właścicielem i kontrolą aktualności, a serwery MCP wskazujące na dane bez właściciela usuń.

Dokąd dalej po samoocenie DORA AI

Jeśli kierownictwo myli gotowość organizacji z autonomią pętli, zacznij od jednej mapy drabiny, cyklu życia i fabryki, a potem przejdź do strony dla swojej najsłabszej zdolności.

Jak przeprowadzić ludzi przez zmianę Opublikuj stanowisko wobec AI: pierwszą i najtańszą zdolność.

Kolejka code review z agentami Budżety rozmiaru PR i limity WIP, dzięki którym małe partie działają naprawdę.

Zespół platformowy agentów Prowadź harness jak produkt, żeby zyski wyszły poza jeden zespół.

Roadmapa transformacji Ułóż pracę nad zdolnościami w plan z punktami decyzji.

Najczęstsze pytania

Jakie siedem zdolności obejmuje model DORA AI Capabilities?

Jasne i zakomunikowane stanowisko wobec AI, zdrowy ekosystem danych, wewnętrzne dane dostępne dla AI, solidne praktyki kontroli wersji, praca w małych partiach, koncentracja na użytkowniku i dobre platformy wewnętrzne (DORA, Google Cloud, 23 września 2025).

Czy DORA publikuje poziomy dojrzałości albo punktację dla modelu AI Capabilities?

Nie. DORA nazywa siedem zdolności i opisuje, co każda z nich wzmacnia. Skala 0–3 na tej stronie to punktacja oparta na dowodach, przygotowana przez ten serwis, a nie przez DORA.

Którą zdolność z modelu DORA AI organizacja powinna naprawić najpierw?

Najsłabiej ocenioną spośród stanowiska wobec AI, praktyk kontroli wersji i pracy w małych partiach, zanim rozszerzysz użycie agentów, bo DORA wiąże większy wolumen zmian bez systemów kontroli z niestabilnością.

Czy model DORA AI Capabilities to to samo co drabina autonomii?

Nie. Model jest listą kontrolną gotowości organizacji i nie ma poziomów. Drabina autonomii mierzy, jak daleko każda pętla dostarczania działa bez człowieka, i tych dwóch rzeczy nie mapuje się na siebie.