nasze doświadczenie w stosowaniu najbardziej popularnych Agile Metrics

nasze doświadczenie w stosowaniu najbardziej popularnych Agile Metrics

używanie Agile metrics do pomiaru produktywności zespołu jest kluczową częścią filozofii Agile. Kierownicy zespołów i wszyscy członkowie powinni widzieć konsekwencje swojej pracy i wykorzystywać te dane do poprawy przepływu pracy i zwiększenia wydajności.

użytkownicy końcowi i klienci mogą również korzystać z wskaźników zwinnych projektów, które koncentrują się na ocenie wyniku produktu. Metryki pozwalają Scrum masterom, programistom, projektantom i testerom mierzyć wydajność aplikacji i śledzić, czy obecne i poprzednie zadania sprawiają, że produkt jest lepszy.

w tym artykule przejrzymy ważne wskaźniki zwinne i podzielimy się naszym doświadczeniem w stosowaniu tego pulpitu wskaźników zwinnych w rzeczywistym projekcie. Okazuje się, że aby skutecznie prowadzić zespół i dostarczać wyniki, nie tylko musisz wiedzieć, które metryki zastosować, ale jak to zrobić — podzielimy się tym, jak do tego doszliśmy.

rodzaje typowych wskaźników zwinnych

klasyfikacja wskaźników zwinnych nie jest ustalona — zawsze się zmienia i restrukturyzuje. Jednak na przestrzeni lat zaobserwowaliśmy wzrost trzech głównych rodzajów wskaźników zwinnych w różnych strukturach zwinnych.

1. wskaźniki Kanban — te wskaźniki opierają się na pomiarze zainwestowanego czasu (czasów cyklu) i dostarczonych wyników (przepustowości) oraz ich stosunku.
2. Scrum metrics-metryki, które koncentrują się na planowaniu i zrozumieniu przepływu pracy oraz wykazaniu, ile pracy wykonano w danym okresie;
3. Lean metrics — ciągły pomiar wydajności produkcji i jakości produktu wraz z oceną techniczną poprzez testowanie funkcji, Sprawdzanie ewentualnych błędów i przewidywanie negatywnych skutków.

używamy wszystkich trzech typów wskaźników do oceny głównych aspektów procesu tworzenia oprogramowania i wyników: jakość produktu, wydajność zespołu i zdrowie.

zwinne wskaźniki jakości

zanim zaczniesz mierzyć prędkość i wydajność zespołu, musisz wiedzieć, czy generalnie zmierzasz we właściwym kierunku. Jaki jest pożytek z szybkiej realizacji wszystkich zadań programistycznych, jeśli same zadania są tworzone w niewłaściwy sposób? Priorytetem dla każdego zespołu programistycznego i menedżera jest upewnienie się, że wszystkie działania są związane z ulepszaniem produktu — odbywa się to poprzez pomiar jego jakości i wykrycie negatywnych tendencji.

uniknięto defektów

każdy zwinny projekt ma sprinty lub cykle robocze, na końcu których dostarczane jest określone zadanie. Po zakończeniu prac kierownik zespołu musi ocenić jakość wyników turn-it. Wszystkie zmiany, edycje i nie naprawione błędy są unikniętymi defektami-problemami, które programiści mogli naprawić, ale nie zrobili tego. Zapisz ich dokładną liczbę i charakter, aby wiedzieć, jakie błędy zwykle umykają oczom programistów.

po sporządzeniu raportu o unikniętych defektach i zebraniu namacalnych statystyk, należy omówić wyniki ze swoim zespołem. Upewnij się, że każdy członek zespołu wie, jakiego rodzaju błędy zwykle pomija. Jeśli masz indywidualne sugestie, przedyskutuj je z członkami zespołu jeden na jeden.

nieudane wdrożenia

jeśli produkt został wdrożony, ale nie został wydany lub nie przyciągnął użytkowników, jest to rejestrowane jako nieudane wdrożenie. Czasami nieudane wdrożenie zdarza się decyzjom jednego z interesariuszy lub model biznesowy okazuje się nierzetelny. Niezależnie od tego, co było przyczyną problemu, musisz zarejestrować wszystkie nieudane wdrożenia wraz z przyczynami ich niepowodzenia.

przed wydaniem nowego wdrożenia zespół zawsze może sprawdzić listę wcześniej nieudanych wdrożeń i sprawdzić, czy ta nie może przejść tego samego procesu. Analiza przyczyn niepowodzenia poprzednich wersji pozwala uniknąć przyszłych problemów.

Release Net Promoter Score (NPS)

Net Promoter Score jest metryką, która obejmuje ocenę reakcji użytkowników pod względem ilościowym (liczby, statystyki, średnie oceny) i jakościowym (recenzje, bezpośrednie opinie, wiadomości, e-maile, połączenia). Po zebraniu i przeanalizowaniu opinii, każdy członek zespołu sugeruje wynik, który ocenia, ile użytkownik może polecić produkt (zazwyczaj wyniki są ustawione w granicach od 1 do 10).

zwinne wskaźniki zarządzania projektami

po uzyskaniu pełnej historii poprzednich niepowodzeń i sukcesów można przeanalizować kierunek obrany dla wszystkich bieżących niekompletnych projektów i podać odpowiednie zadania, opierając się na wcześniejszych doświadczeniach. Po ustaleniu kierunku rozwoju – „co robić” produktu, ” musisz ocenić wydajność zespołu-jest to czynnik „jak nam idzie”. Możesz użyć zwinnych wskaźników projektu, aby dowiedzieć się, czy członkowie zespołu spełniają Twoje oczekiwania, rozumieją ich zadania, zarządzają terminami i czy wszystkie procesy są skoordynowane i zsynchronizowane.

czas realizacji

czas realizacji jest metryką, która pozwala zespołom sprawdzić, ile zajęło wpisanie zaległości produktu na koniec sprintu. Może być używany do śledzenia produktów na dowolnym etapie rozwoju, zadanie po zadaniu, lub oceny ogólnych kosztów czasu, od pomysłu do wydania. Jest to długoterminowa metryka, z której deweloperzy mogą korzystać podczas planowania przyszłej pracy i szacowania cen.

pamiętaj, aby nagrać czas realizacji każdego z projektów. Najlepiej jest zachować zarówno większe statystyki, które obejmują cały projekt, jak i zorganizować wskaźniki sprintu — dzięki czemu można zbadać każdy etap osobno.

czas cyklu

jeśli czas realizacji należy do długoterminowych wskaźników wydajności zespołu, czas cyklu koncentruje się na poszczególnych zadaniach. Ten wskaźnik ocenia czas trwania pojedynczego cyklu, w którym jeden cykl jest wykonywany przez jedno zadanie, oblicza liczbę cykli na projekt i mierzy osiągnięte wyniki dla użytkownika końcowego, jeśli produkt jest już Beta-testowany lub wydany.

dzięki czasowi cyklu zespoły mogą natychmiast sprawdzić, czy jedno zadanie zajmuje zbyt dużo czasu lub czy niektórzy członkowie zespołu nie realizują swoich celów. Ten krótkoterminowy wskaźnik znacznie ułatwia zarządzanie projektem i pomaga szybko zidentyfikować pojawiające się problemy.

Sprint burndown

ta metryka jest stosowana zarówno krótko, jak i długoterminowo. Menedżerowie mogą tworzyć raporty Scrum sprint burndown w czasie rzeczywistym, aby śledzić postępy swojego zespołu w bieżącym projekcie — w tym celu muszą oszacować całkowitą liczbę sprintów i przewidzieć prawdopodobne wydatki czasowe. Może być również stosowany długoterminowo-menedżerowie mogą analizować raporty z poprzednich projektów, wskazywać etapy, które nie przyniosły oczekiwanych ram czasowych i analizować przyczyny opóźnień.

co najważniejsze, sprint burndown umożliwia śledzenie dynamiki przepływu pracy zespołów. Niektórzy członkowie mają tendencję do wolniejszej pracy na pierwszych etapach, podczas gdy inni wypalają się pod koniec projektu. Dzięki funkcji sprint burndowns liderzy zespołów mogą wykryć te tendencje, określić ich przyczyny i pomóc członkom w dystrybucji pracy i zarządzaniu czasem.

Epic & Wydanie burndown

ten wskaźnik jest podobny do Sprintu Burndown — jedyną kluczową różnicą jest to, że skupia się na wydajności zespołu przed i po wydaniu. Menedżerowie mogą dodawać nowe wymagania i włączać zadania oparte na opiniach użytkowników końcowych. Jest to ulepszona wersja sprint burndown, ponieważ zawiera również zadania podane po wydaniu projektu.

Velocity

ta metryka oblicza liczbę ukończonych punktów historii w danym okresie. Na podstawie swojej historii możesz przewidzieć wydatki na przyszłe punkty fabularne. Spadek prędkości zespołu na poszczególnych sprintach może wskazywać na nieporozumienia między członkami zespołu lub wskazane zadania, które są trudniejsze niż wcześniej przewidywano.

dodatkowe wskaźniki zwinne

wskaźniki zwinne pomagają zespołowi lepiej poznać swój projekt i śledzić wiele istotnych aspektów rozwoju produktu. Istnieją również wskaźniki zwinne dla kadry kierowniczej wyższego szczebla, które pozwalają zobaczyć szerszy obraz rozwoju i dobrego samopoczucia zespołu. Zgodnie z naszym doświadczeniem, te dodatkowe wskaźniki pomagają zmierzyć każdy aspekt twojej pracy. Jednak zdefiniowaliśmy kluczowe cechy, które mówią najwięcej o produkcie końcowym i pomagają uzyskać w pełni kompletny wynik.

przepływ skumulowany

nazwa miernika wyraźnie komunikuje swój cel-zgromadzić wszystkie przepływy projektu i ocenić je w jednym diagramie. Posiadanie takiego wykresu zapewni Ci Widok na dużą skalę — może być wysyłany do interesariuszy projektu, którzy nie mają czasu na analizowanie bardziej szczegółowych raportów zwinnych.

diagram zwykle opisuje następujące procesy:

• zadania w Backlogu: ile zadań w Backlogu mają członkowie zespołu w danym przedziale czasowym;
• zatwierdzona praca: ile zadań spośród zaplanowanych zostało ukończonych-kierownik zespołu natychmiast widzi różnice między zaplanowanymi i sfinalizowanymi działaniami;
• zadania buforowe: wszystkie prace, które czekają na zatwierdzenie, są zdefiniowane jako strefy buforowej;
• w toku: musisz ocenić bieżące obciążenie pracą.

zmiana kodu

ten wskaźnik pokazuje trendy zmian podstawy kodu przed wydaniem. Diagramy Churn pokazują, ile kodu zostało dodanych, usuniętych lub zmienionych raz na raz. Na początku sprintów będzie wiele skoków i spadków na wykresie, ponieważ kod jest nadal niestabilny, ale w miarę postępu projektu, Wykres utraty kodu powinien stać się stabilny, bez drastycznych wzlotów i upadków.

przed wydaniem, churn powinien uzyskać spadek — dodanie lub edycja kodu przed samym wydaniem oznacza, że nie będzie on poddawany wystarczającym testom. Ogólnie rzecz biorąc, ilekroć na wykresach zwinnych występuje nieprawidłowość, należy zbadać przyczyny.

Wykres kontrolny

Wykres kontrolny to wykres, na którym zespół może zobaczyć informacje na temat czasu trwania ich cyklu. Idealny wynik sprawiłby, że linia na wykresie stopniowo spadałaby z czasem — oznaczałoby to wzrost prędkości zespołu — mniej czasu jest wymagane na pojedynczy cykl. Kolejnym ważnym aspektem jest spójność-czasy cykli muszą pozostać równomierne niezależnie od rodzaju zadania-oznacza to prawidłowy rozkład pracy.

wskaźniki zdrowia

zespoły programistyczne muszą skupić się na długoterminowych priorytetach, takich jak utrzymywanie płynnej komunikacji między członkami i sprawdzanie, czy wszyscy są zadowoleni. Agile to elastyczna metodologia, co oznacza, że może dostosować się do zainteresowań różnych członków, gdy tylko menedżerowie będą wiedzieć, na co zwracać uwagę. Oto, w jaki sposób dowiemy się, czy wszyscy członkowie naszego zespołu są zadowoleni z przepływu pracy.

szczęście

jeśli masz zaufane, nieformalne relacje w swoim zespole, łatwiej jest rozpocząć od otwartego dialogu z każdym członkiem. Poproś wszystkich o ocenę swojego doświadczenia w firmie od 1 do 5. Możesz zadawać pytania-Jakie są najlepsze i najgorsze aspekty ich pracy, co można poprawić, a co może zwiększyć szczęście? Jeśli zespół nie ma przyjaznych nawyków komunikacyjnych, korzystanie z anonimowych ankiet może prowadzić do bardziej obiektywnych wyników.

morale zespołu

morale zespołu i szczęście to nie to samo. Szczęście ma więcej do czynienia z komfortem, podczas gdy morale zespołu jest związane z produktywnością, samooceną, oceną własnych cech zawodowych. Ponownie możesz poprosić pracowników o ocenę ich morale od 1 do 5 i zadać następujące pytania;

• czy praca w firmie przyczyniła się do doskonalenia Twoich umiejętności?
• ile w pełni wykorzystujesz przy obecnym obciążeniu pracą?
• podoba Ci się praca?
• czy widzisz wyraźne efekty swojej pracy?
• czy jesteś entuzjastycznie nastawiony do nowych projektów?

celem jest zrozumienie, że prąd rozwoju zespołu idzie we właściwym kierunku. Czasami kierownik zespołu programistycznego wykonuje dochodowe, ale nudne zadania, ignorując interesy członków. Ta ankieta pomoże Ci sprawdzić, czy pracownicy są podekscytowani i zakwestionowani przez swoją pracę.

rotacja członków zespołu

jeśli kierownicy zespołu często zastępują członków zespołu, oznacza to, że środowisko pracy jest prawdopodobnie niezdrowe. Pewna stopa obrotu w czasie jest zdrowa – w rzeczywistości nie chcesz mieć żadnego dodatku ludzi przez lata, ponieważ oznaczałoby to stagnację. Należy jednak uważać na nagłe skoki aktywności-miesiące, gdy kilka osób opuściło zespół lub dołączyło Wiele osób. Jeśli masz nagłe dodanie wielu nowych uczestników, musisz zwrócić uwagę na proces wdrażania przed przejściem bezpośrednio do pracy związanej z projektem.

pomiar korzyści dla użytkowników końcowych

zwinne zespoły powinny wiedzieć, jak dobrze produkt pasuje do potrzeb użytkownika końcowego i właściciela firmy. Odbywa się to za pomocą kompleksowej analizy kodu, która określa jakość kodu i jego użyteczność dla użytkownika końcowego, a także możliwe komplikacje konserwacyjne.

statyczna analiza kodu

jest to prosty typ analizy kodu, gdy oprogramowanie jest nieaktywne. Wystarczy automatycznie monitorować kod za pomocą narzędzi open-source, aby zidentyfikować problemy z bezpieczeństwem, wykryć zadłużenie techniczne i błędy oraz wysłać problematyczne fragmenty kodu do garbage collector.

dynamiczna analiza kodu

dynamiczna analiza kodu wymaga od zespołu uruchomienia oprogramowania do oceny doświadczeń użytkowników końcowych. Zachęcamy naszych programistów i testerów, aby zawsze stawiali się w sytuacji użytkowników, badając najczęstsze scenariusze. Na przykład mogą przedstawić rozwiązanie swoim kolegom i członkom rodziny, prosząc o opinię — chyba że nie jest to zabronione w umowie. Co najważniejsze, mamy zespół specjalistów QA, którzy są w pełni odpowiedzialni za dynamiczną analizę kodu – chociaż uważamy, że im więcej osób przyczynia się do testowania wskaźników w Agile, tym lepsza jest jakość produktu końcowego.

jak zastosować najlepsze wskaźniki zwinne

ze wszystkich dostępnych wskaźników zwinnych, musisz wybrać te, które będą istotne dla Twojego zespołu i projektów w dłuższej perspektywie. Śledzenie tych kluczowych cech powinno być nawykiem, podczas gdy nie powinno odwracać uwagi od pilniejszej pracy. Oto, w jaki sposób bezproblemowo włączyliśmy zwinne wskaźniki do naszego przepływu pracy.

skoncentruj się na wydajności, budżecie i jakości

musisz upewnić się, że po wybraniu wszystkich wskaźników będziesz w stanie uzyskać jasny obraz jakości swojej pracy, obciążenia, wydatków czasowych i budżetu. Po pierwsze, stworzyliśmy krótkoterminowe wskaźniki, które odnoszą się do naszych aktywnych projektów: czas cyklu i prędkość dla zwinnej oceny wydajności, analiza kodu dla oceny jakości kodu i przepływ skumulowany, aby śledzić wszystkie procesy rozwoju i ich koszty.

podczas pierwszego sprintu wykonujemy następujące czynności:

• określ, ile sprintów i cykli będzie miał projekt;
• oszacuj czas całego projektu, biorąc pod uwagę potrzeby klienta;
• oceniając konkurencyjne rozwiązania, aby zrozumieć poziom złożoności produktu końcowego;
• Zbierz opinie od członków naszego zespołu na temat ich oczekiwań dotyczących najbardziej ekscytujących, trudnych i trudnych aspektów projektu.

w ten sposób możemy wiedzieć, ile czasu poświęcimy na realizację projektu, ustalić standardy jakości w oparciu o podobne rozwiązania oraz czy nasz zespół jest zmotywowany do pracy nad zadaniami, czy nie (ma to ogromny wpływ na produktywność).

dane po pierwszym sprincie

tutaj skupiamy się na uzyskiwaniu informacji zwrotnych od klienta i wszystkich członków zespołu. Po pierwszym sprincie chcemy wiedzieć, że wszystkie strony zaangażowane w przepływ pracy rozumieją ten proces i czują się komfortowo. Ponadto kładziemy nacisk na ocenę jakości kodu – planujemy nawet analizę kodu i ocenę zadłużenia technicznego jako część każdego z naszych kolejnych sprintów. Jak tylko pierwsze linijki kodu zostały napisane, utrzymanie jego jakości jest naszym priorytetem.

prędkość jest po

prędkość jest jedną z najważniejszych wskaźników w naszych projektach, ale nie kluczową. Powstrzymujemy się od opierania naszej oceny na liczbach prędkości na początkowych etapach. Strategia szybkiego przejścia przez pierwsze kroki to katastrofa, która czeka — zespół może pominąć planowanie lub zapomnieć zadać klientowi kilka kluczowych pytań. Nie spieszymy się z pierwszymi etapami produktu, pozwalając klientom i członkom zespołu znaleźć swoje tempo.

zwiększenie prędkości naszego zespołu staje się jednym z naszych priorytetów, gdy jesteśmy na etapie realizacji. Jak tylko wszystkie funkcje i projekt są rozplanowane, staramy się zminimalizować koszty czasu i wykonać wszystkie zadania tak szybko, jak to możliwe.

Wskaźniki indywidualne

każda z użytych wskaźników powinna być dostępna zarówno dla całego zespołu, jak i dla poszczególnych członków. Programiści, testerzy, projektanci powinni być w stanie zobaczyć tempo i wyniki swojej pracy, a nie tylko zespół jako całość. Aby tak się stało, używamy narzędzi produktywności i śledzenia czasu, takich jak Jira i Hubstaff. Wszystkie raporty ogólne są zsynchronizowane z indywidualnymi-członkowie mogą zobaczyć, jaki procent ogólnego czasu produkcyjnego generują ich godziny pracy.

Najczęściej zadawane pytania

co to jest KPI w Agile?

kluczowe wskaźniki wydajności w Agile to mierzalne wartości, które pokazują efektywność zespołu w osiąganiu celów biznesowych. Wysokie wskaźniki KPI koncentrują się na długoterminowych wynikach, które zależą od wielu czynników-liczby użytkowników przyciągniętych przez produkt końcowy, współczynniki konwersji, jakość informacji zwrotnej. Niskie wskaźniki KPI to krótkoterminowe wartości, na które nie ma wpływu wiele powiązanych ze sobą czynników — czas spędzony na projekcie (Zwykle liczony w godzinach), budżet projektu (Inwestycja na zadanie) itp.

Agile to metodologia rozwoju oparta na ciągłym doskonaleniu-tworzenie oprogramowania analizuje dane i dostosowuje się do nich. Zespół analizuje zwinne wskaźniki KPI pod kątem wydajności i jakości pracy i wdraża zmiany od razu w następnym sprincie.

co to są metryki Sprintu?

wskaźniki Sprint to wskaźniki, które oceniają wyniki zespołu programistów, sprawdzając, ile wartości dostarczono klientowi końcowemu pod koniec każdego sprintu . Wartość ta może być mierzona za pomocą nowej funkcji, ulepszeń projektu lub usuwania błędów.

kolejnym celem sprint metrics jest pomiar efektywności zespołu w kategoriach biznesowych — jak szybko rozwiązanie zostało dostarczone na rynek, jakie są opinie klienta i poziomy konwersji. Wreszcie, wskaźniki muszą pokazywać zadowolenie programistów z ich projektu i ogólnie z kierunku, w którym podąża zespół.

dlaczego metryki są ważne dla zwinnych projektów?

cały sens zwinnej metodologii polega na tym, że programiści zawsze mogą wprowadzać poprawki w procesie po każdym sprincie. Posiadanie namacalnych danych, statystyk i wykresów pozwala programistom zrozumieć, jakie zmiany należy wprowadzić w następnym sprincie i umożliwia ocenę jakości produktu końcowego — w przeciwnym razie łatwo byłoby się zorientować w szczegółach technicznych i organizacyjnych.

co to jest sprint w Agile?

sprint to jasno określony okres z datą rozpoczęcia i zakończenia, kiedy zespół ma wykonać określoną liczbę zadań. Sprinty są podstawą Scrum, Agile i DevOps-zespoły dzielą swoje obciążenie na mniejsze, łatwe do opanowania części i śledzą wyniki każdego sprintu. Każdy z tych okresów jest traktowany jak mini-projekt z wcześniejszym planowaniem, oceną ryzyka, przypisaniem odpowiedzialności i analizą po sprincie.

każdy projekt składa się z serii sprintów. Ponieważ każdy sprint jest oceniany, łatwo jest wcześnie wykryć problemy i usunąć je podczas następnego sprintu — dzięki czemu przepływ pracy jest stale optymalizowany.

jakie są metryki dotyczące tworzenia oprogramowania?

wskaźniki rozwoju oprogramowania są wartościami ilościowymi, które pozwalają mierzyć jakość, wydajność i stan zespołu projektu rozwoju oprogramowania. Pomagają one usprawnić proces rozwoju w miarę postępu projektu i mogą być wykorzystane do przyszłej pracy zespołu w celu poprawy organizacji i planowania.

istnieje sześć głównych typów wskaźników rozwoju oprogramowania:

• formalne metryki kodu — są to obiektywne wartości jakościowe, które obliczają, ile pracy wykonano, określając liczbę linii kodu (LOC), Długość ścieżki instrukcji i inne.
• wskaźniki efektywności deweloperów — zespół może obliczyć kod przydziału, aktywne dni i czas spędzony na zadaniu.
• zwinne wskaźniki procesu – gdy projekt jest podzielony na sprinty, zespół może zmierzyć wydajność mniejszych części projektu – czas realizacji (ile czasu poświęcono na pewien etap rozwoju, który może zawierać kilka sprintów), czas cyklu (jeden sprint zwykle przypada na jeden cykl) i prędkość (ile zadań zostało wykonanych w określonym przedziale czasowym).
• wskaźniki operacyjne — te wskaźniki sprawdzają charakterystykę działania oprogramowania i określają, jak skuteczny jest personel firmy w utrzymaniu narzędzia bez pomocy stron trzecich. Średni czas między awariami i średni czas odzyskiwania (MTTR) sprawdź, jak oprogramowanie będzie działać w naturalnych warunkach i jak wyposażony jest wewnętrzny zespół w obsłudze ładunku.
• wskaźniki testowe — te wskaźniki oceniają pokrycie kodu — ilość testowanego kodu, liczbę błędów i procent zadłużenia technicznego.
• satysfakcja klienta — zespół otrzymuje wgląd w reakcje użytkowników końcowych na produkt poprzez pomiar Net Promoter Score, Customer Satisfaction Score i Customer Effort Score. Wskaźniki te oceniają, odpowiednio, czy użytkownicy poleciliby produkt i czy są zadowoleni z wyniku.

wskaźniki zwinne są częścią sieci oprogramowania i mogą obejmować inne kategorie, jak można zauważyć w naszym przewodniku.

czym są metryki SDLC?

SDLC jest cyklem rozwoju oprogramowania — zestawem etapów, które typowa technologia przechodzi podczas jej koncepcji, wykonania i finalizacji. Średnia SDLC składa się z następujących etapów:

• ocena istniejących systemów i definiowanie ich cech, zalet, problemów;
• Definiowanie wymagań dla nowej funkcjonalności projektu, projektu, grupy docelowej itp.;
• Projektowanie systemu i wyznaczanie typowej ścieżki użytkownika;
• tworzenie oprogramowania, czyli pisanie kodu, przygotowanie sprzętu i tworzenie funkcji;
• testowanie wydajności oprogramowania, funkcjonalności, bezpieczeństwa, interfejsu itp.;
• wdrażanie oprogramowania w jego naturalnym środowisku, w którym technologia będzie działać długoterminowo;
• utrzymywanie systemu poprzez aktualizację kodu, wymianę lub edycję niektórych fragmentów oraz usuwanie błędów.

każdy etap SLDC można zmierzyć za pomocą następujących cech.

• wymagania: zespół musi zebrać wszystkie wymagania dotyczące projektu i ocenić realizację każdego z nich pod względem czasu i pieniędzy;
• jakość oprogramowania: wszystkie zwinne wskaźniki jakości mogą być używane na etapie rozwoju SDLC;
• przypadki testowe: zespół musi obliczyć liczbę wykonanych czynności testowych, ich prędkość i końcowe pokrycie kodu;
• wady: aby zmierzyć wydajność swojej pracy, programiści i testerzy muszą zdawać sobie sprawę z dokładnej liczby problemów pojawiających się podczas rozwoju;
• zadania: pomiary czas spędzony i zarobione pieniądze na zadanie pozwala ocenić, czy wszyscy członkowie zespołu są produktywni, czy nie.

wszystkie wskaźniki opisane w naszym przewodniku mogą być używane na różnych etapach cyklu rozwoju oprogramowania. Projekt jest najbardziej potrzebny do monitorowania bliżej wydania, ponieważ problemy mogą się kumulować i łatwo jest pominąć krytyczną usterkę w produkcie.

co to jest przepustowość w metrykach Agile?

jest to metryka, która oblicza liczbę historii ukończonych na sprint. W Scrum podobna metryka jest określana jako prędkość sprintu.

podsumowanie

wskaźniki zwinne tworzą solidną podstawę do podejmowania świadomych decyzji w całym projekcie tworzenia oprogramowania. Programiści mogą wykorzystać te spostrzeżenia, aby zwiększyć swoją wydajność w kolejnych sprintach i stale poprawiać jakość swoich produktów. Warto jednak zauważyć, że wskaźniki rozwoju nie powinny stać się absolutnym priorytetem w projekcie tworzenia oprogramowania. Programiści powinni przede wszystkim polegać na potrzebach projektowych i preferencjach odbiorców.

w Jelvix stosujemy spersonalizowane podejście do stosowania wskaźników do projektu. Najpierw omawiamy MVP projektu z klientem, badamy grupę docelową, analizujemy konkurencyjne rozwiązania, a dopiero potem wybieramy wskaźniki, które najlepiej pasują do projektu. Nie staramy się stosować każdego KPI — zamiast tego wybieramy te, które najbardziej odpowiadają potrzebom projektu.