Skip to content

Prędkość a pojemność

Załóżmy, że dwa zespoły rozpoczynają pracę nad jednym i tym samym Backlogiem Produktu i niezależnie od siebie pracują nad tymi samymi historyjkami użytkownika (user stories). Dla uproszczenia przyjmijmy, że wszystkie historyjki zostały oszacowane na 5 punktów (story points) każda.

Elementy Backlogu Produktu Estymata
Historyjka A 5 pkt.
Historyjka B 5 pkt.
Historyjka C 5 pkt.
Historyjka D 5 pkt.
Historyjka E 5 pkt.
Historyjka F 5 pkt.
Historyjka G 5 pkt.
Historyjka H 5 pkt.
Historyjka I 5 pkt.
Historyjka J 5 pkt.

Sprint pierwszy

Na pierwszy Sprint każdy zespół wybrał po 3 historyjki: A, B i C. Oba zespoły ukończyły wszystkie zaplanowane historyjki, a więc prędkość (velocity) obu zespołów jest taka sama i wynosi 15.

Sprint drugi

Na drugi Sprint oba zespoły wybierają znowu po 3 historyjki: D, E, F i znowu wszystkie udaje im się ukończyć. Prędkość znowu 15.

Sprint trzeci

Na trzeci Sprint zespół nr 1 wybiera historyjki G, H i I. Zespół nr 2 natomiast wykrył błąd w aplikacji, który powstał podczas realizacji Historyjki B. Zespół dodaje więc do Backlogu Produktu element „Błąd B#1”, usunięcie którego zespół szacuje też na 5 pkt. Do trzeciego Sprintu wybiera więc usunięcie błędu B#1 oraz historyjki G i H, bo więcej nie zdąży zrobić.

Obu zespołom udaje się ukończyć wszystko, co sobie zaplanowały na Sprint. Prędkość obu zespołów znowu jest taka sama i wynosi 15. Czyżby?

Nie bilansuje się

Spójrzmy na Backlog Produktu i stan samego produktu. Produkt jest bogatszy w przypadku zespołu nr 1 o historyjkę I. Zespół 2 dopuścił się gdzieś wcześniej (przy historyjce B) zaniedbania i za ukończone zostało uznane coś, co zawierało defekt. Więc tak naprawdę należałoby cofnąć się do pierwszego Sprintu, cofnąć akceptację historyjki B i obliczyć prędkość zespołu na 10. Oczywiście nikt tego nie robi.

W takich przypadkach należy przyznać zespołowi nr 2 na start trzeciego Sprintu −5 do prędkości i wtedy wszystko się bilansuje. Prościej: nie wliczać do prędkości zespołu prac mających na celu usunięcie usterki. Dla pełnej przejrzystości rozgraniczyć prędkość (velocity) i pojemność (capacity) zespołu. W tym przypadku za trzeci Sprint prędkość zespołu nr 2 wynosiła 10, a pojemność — 15.

Uogólniając:

  • Prędkość zespołu to wszystkie ukończone w trakcie Sprintu elementy Backlogu Produktu, które tworzą wartość dodaną do produktu.
  • Pojemność zespołu to wykonana w trakcie Sprintu praca. Pojemność wyznacza możliwą do osiągnięcia prędkość, gdyby były przetwarzane tylko te elementy, które tworzą wartość dodaną, a praca była ukończona.

Co tworzy wartość dodaną?

Czy tylko usuwanie usterek i nieukończona praca nie powinny być wliczane do prędkości? Co tworzy wartość dodaną, a co nie? Posłużmy się autem, jako analogią.

Załóżmy, że jesteśmy właścicielem auta o nominalnej wartości 20 tys. złotych. Jak wiadomo, auto się czasem psuje i usterki trzeba usuwać, należy też dokonywać okresowych przeglądów i ponosić koszty na profilaktyczne naprawy. Wszystkie te prace, choć potrzebne, i związane z nimi koszty nie zwiększają nominalnej wartości naszego auta. Co innego, jeśli zainwestujemy na przykład w sprzęt audio, zamontujemy czujnik cofania (którego domyślnie nie było), wymienimy felgi na alu itp.

Tak samo należy patrzeć produkt, jakim jest oprogramowanie. Usuwanie usterek, refaktoryzacja, uzupełnianie kodu testami jednostkowymi, analizy, raporty, dopisywanie dokumentacji „po fakcie” — to wszystko, choć wartościowe, nie dodaje wartości produktowi, a jest jedynie kosztem ponoszonym na jego utrzymanie, a czasem wręcz spłacaniem długu technologicznego, czyli wyrównywaniem poziomu jakości do pewnego stanu zero, a nie na plus.

Warto rozgraniczać te dwie metryki; zwiększa to przejrzystość, a Zespół Scrumowy i interesariusze mają jaśniejszy obraz całej sytuacji, a ich analiza (np. w trakcie Retrospektywy) może pomóc w poszukiwaniu metody na zwiększenie prędkości.

Categories: Metryki.

Comment Feed

2 komentarze

  1. Bardzo fajne porównanie do samochodu. A co z takimi rzeczami jak przeniesienie aplikacji na szybsze serwery?

  2. Bogdan Baraszkiewicz18 listopada 2011 @ 19:59

    Dobre pytanie. Myślę, że nie zawsze da się tak jednoznacznie określić. Zależy od produktu, kontekstu.W odpowiedzi może pomóc pytanie: czy gdybyśmy odsprzedawali na wolnym rynku dany produkt, to czy za tę konkretną rzecz, którą właśnie robimy, można byłoby dostać wyższą cenę?Jeśli infrastrukturę traktujesz jako integralną część produktu i sprzedawałbyś produkt jako jedną całość, to czy produkt będzie wart więcej jeśli aplikacja będzie na szybszych serwerach? Myślę, że tak.Trzymając się analogii auta, migracja na szybszy serwer to może być np. zastąpienie starego silnika nowym, ale nie dlatego, że stary się popsuł, tylko dlatego, że warunki się zmieniły i teraz potrzebujemy większej mocy.Ale np. upgrade oprogramowania na serwerze, to już inna kategoria.



Some HTML is OK

or, reply to this post via trackback.