{"id":1251,"date":"2021-03-23T11:02:00","date_gmt":"2021-03-23T10:02:00","guid":{"rendered":"http:\/\/agilepolska.pl\/zwinnyblog\/?p=1251"},"modified":"2021-03-23T12:29:32","modified_gmt":"2021-03-23T11:29:32","slug":"obsesja-velocity-i-jej-skuteczna-terapia","status":"publish","type":"post","link":"https:\/\/agilepolska.pl\/zwinnyblog\/2021\/03\/23\/obsesja-velocity-i-jej-skuteczna-terapia\/","title":{"rendered":"Obsesja Velocity i jej skuteczna terapia"},"content":{"rendered":"\n

Je\u015bli istnieje jakie\u015b s\u0142owo, kt\u00f3re w zwinnym \u015bwiecie wywo\u0142uje skrajne emocje, jest zar\u00f3wno policzalne, jak i niepoliczalne, wyra\u017cone liczb\u0105, ale niepor\u00f3wnywalne, kochane przez manager\u00f3w – tolerowane przez wszystkich innych i wreszcie – po\u017cywne i toksyczne jednocze\u015bnie, jak ryba Fugu lub Zenek Martyniuk – to jest nim Velocity<\/strong>. Jestem pewien, \u017ce to w\u0142a\u015bnie s\u0142owo jest przyczyn\u0105 wielu nieporozumie\u0144, konflikt\u00f3w i wypacze\u0144 w implementacji zwinnego podej\u015bcia. <\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n\n\n\n\n

<\/p>\n\n\n\n

M\u00f3wi\u0105c o wypaczeniach: przychodzi do Was Manager i pyta: jak tam wasza PRODUKTYWNO\u015a\u0106, towarzysze? Poka\u017ccie pr\u0119dko wasze VELOCITY. Dlaczego macie MNIEJ ni\u017c w ubieg\u0142ym miesi\u0105cu? Dlaczego macie mniej ni\u017c TEN DRUGI ZESP\u00d3\u0141?<\/em>
Je\u015bli czujecie, \u017ce w ka\u017cdym zdaniu tkwi pu\u0142apka, to macie racj\u0119. Jak zareagowa\u0107? Jak rozbroi\u0107 tak\u0105 bomb\u0119? Potrzebna b\u0119dzie wiedza, odpowiedni dob\u00f3r s\u0142\u00f3w i alternatywne rozwi\u0105zania dla szukaj\u0105cego agile\u2019owej b\u00f3jki Managera. <\/p>\n\n\n\n

Co to jest Velocity? Og\u00f3lnie m\u00f3wi\u0105c, jest to liczba, kt\u00f3ra m\u00f3wi o tym, jaki wynik zesp\u00f3\u0142 osi\u0105gn\u0105\u0142 na koniec sprintu. Najcz\u0119\u015bciej m\u00f3wimy o sumie warto\u015bci w Story Pointach tych historyjek, kt\u00f3re spe\u0142ni\u0142y DoD. Zdarza si\u0119, \u017ce zespo\u0142y wliczaj\u0105 do Velocity tylko historyjki maj\u0105ce warto\u015b\u0107 biznesow\u0105. Zdarza si\u0119 te\u017c, \u017ce wliczaj\u0105 bardzo szerokie spektrum historyjek – w tym improvementy, defekty, spike\u2019y i owocowe czwartki. Najwa\u017cniejsze, aby konsekwentnie trzyma\u0107 si\u0119 swojej definicji przez jaki\u015b czas, bowiem Velocity to warto\u015b\u0107 empiryczna, tworzy trend z przesz\u0142o\u015bci i to ten trend bywa najbardziej przydatny. Do czego? Zwykle do planowania kolejnego sprintu lub serii sprint\u00f3w. Czasami zespo\u0142y wyci\u0105gaj\u0105 \u015bredni\u0105 krocz\u0105c\u0105 za ostatnie kilka sprint\u00f3w, czasami m\u00f3wi\u0105: nasze Velocity nigdy nie by\u0142o mniejsze ni\u017c X i wi\u0119ksze ni\u017c Y, wi\u0119c w tych granicach ka\u017cda warto\u015b\u0107 jest dobra<\/em>. Mo\u017cna te\u017c powiedzie\u0107, \u017ce Velocity ma pewne odchylenie standardowe, wi\u0119c nie mo\u017cna m\u00f3wi\u0107, \u017ce Velocity = X tylko raczej Velocity = X\u00b1y. Zatem Velocity to de facto<\/em> przedzia\u0142, a nie liczba bezwzgl\u0119dna, o czym zapominamy zadaj\u0105c pytanie typu: dlaczego w tym sprincie Velocity by\u0142o 10% mniejsze<\/em>? Je\u015bli nie wiemy, jakie jest odchylenie, to te 10% mo\u017ce mie\u015bci\u0107 si\u0119 w granicach b\u0142\u0119du i powy\u017csze pytanie nie ma \u017cadnego sensu. A jak\u017ce cz\u0119sto pada! <\/p>\n\n\n\n

Wiedz\u0105c, czym jest Velocity, czy mo\u017cna na tej podstawie ocenia\u0107 Produktywno\u015b\u0107 zespo\u0142u? Ka\u017cdy przynajmniej raz do\u015bwiadczy\u0142 sytuacji, w kt\u00f3rej zesp\u00f3\u0142 ofiarnie pracuje w sprincie, czasem po godzinach, cudem jeszcze domyka ko\u0144c\u00f3wk\u0119 i co? Pada pytanie: dlaczego tak ma\u0142o? <\/em>Niejeden zesp\u00f3\u0142 odczytuje to, jako: dlaczego si\u0119 obijacie? <\/em>A m\u00f3wi\u0105c formalnie: dlaczego macie tak\u0105 nisk\u0105 Produktywno\u015b\u0107? <\/em>
Co to jest ta Produktywno\u015b\u0107 w \u015bwiecie wok\u00f3\u0142 nas? Mo\u017cna powiedzie\u0107, \u017ce jest to stosunek ilo\u015bci wytworzonej produkcji do zasob\u00f3w wej\u015bciowych. Zatem dla tych samych zasob\u00f3w wej\u015bciowych w dw\u00f3ch identycznych systemach ten, kt\u00f3ry dostarczy wi\u0119cej, ma wy\u017csz\u0105 produktywno\u015b\u0107. Proste! Je\u015bli wyobrazimy sobie dwie linie produkcyjne biszkopt\u00f3w, dw\u00f3ch grabarzy kopi\u0105cych do\u0142y lub dwie baterie zasilaj\u0105ce kr\u00f3liczki, mamy pe\u0142ne zrozumienie, czym jest Produktywno\u015b\u0107. Jak prze\u0142o\u017cy\u0107 to na software development? Prawdopodobnie systemem jest zesp\u00f3\u0142 scrumowy oraz sam produkt, zasobami jest czas sprintu, komputery, kawa w kuchni (aktualnie domowej, bo pandemia) oraz wymagania, za\u015b produktem ko\u0144cowym jest przyrost dzia\u0142aj\u0105cego oprogramowania, cz\u0119sto innowacyjny i niepowtarzalny. Mierzony poprzez Velocity. I tu zaczyna si\u0119 katastrofa. Je\u015bli w styczniu naprawiali\u015bmy defekty osi\u0105gaj\u0105c Velocity = 100, a w sierpniu do\u0142o\u017cyli\u015bmy 10 innowacyjnych funkcjonalno\u015bci osi\u0105gaj\u0105c Velocity = 90, to kiedy byli\u015bmy bardziej produktywni? Je\u015bli w sierpniu zamiast Agnieszki do\u0142\u0105czy\u0142a Magda i jej 20 lat do\u015bwiadczenia, to kiedy byli\u015bmy bardziej produktywni? Je\u015bli w styczniu pracowali\u015bmy w biurze, a w sierpniu ju\u017c hybrydowo, to kiedy byli\u015bmy bardziej produktywni? Jaki jest sens m\u00f3wi\u0107 o produktywno\u015bci, skoro nawet osi\u0105gaj\u0105c identyczne Velocity ani system, ani produkt, ani okoliczno\u015bci jego powstania nie by\u0142y do siebie podobne? A co dopiero, kiedy Velocity by\u0142oby r\u00f3\u017cne?<\/p>\n\n\n\n

Mo\u017cna wi\u0119c zada\u0107 sobie pytanie, czy praca tw\u00f3rcza o charakterze z\u0142o\u017conym, cz\u0119sto niepowtarzalna, wykonywana w zmieniaj\u0105cych si\u0119 okoliczno\u015bciach mo\u017ce by\u0107 okre\u015blana s\u0142owem produktywna<\/em>? Wed\u0142ug mnie absolutnie nie. Dodatkowo, w pracy o takim charakterze cz\u0119sto nie optymalizuje si\u0119 kosztu na pierwszym miejscu. Istniej\u0105 inne wyzwania, takie jak ryzyka techniczne, zbyt rzadkie dostarczanie, niestabilne komponenty 3rd party – wszystkie one nie poddaj\u0105 si\u0119 optymalizacji koszt\u00f3w. Wysoka produktywno\u015b\u0107 nie rozwi\u0105\u017ce wielu znanych problem\u00f3w przy wytwarzaniu oprogramowania. Dlatego termin produktywno\u015b\u0107 <\/em>najlepiej sprawdza si\u0119 przy powtarzalnych, wysoko kontrolowalnych procesach wytw\u00f3rczych o charakterze prostym lub skomplikowanym, ale nie z\u0142o\u017conym w uj\u0119ciu Cynefin.<\/p>\n\n\n\n

Skutki upartego d\u0105\u017cenia do produktywno\u015bci w \u015bwiecie IT mog\u0105 by\u0107 z\u0142e. Wyobra\u017amy sobie, \u017ce chcemy, aby deweloperzy pisali jak najwi\u0119cej linii kodu na godzin\u0119 (by\u0142y zreszt\u0105 takie miary). Du\u017co linii, to potencjalnie du\u017co defekt\u00f3w, d\u0142u\u017csze review pull request\u00f3w i tak dalej. Czy o to nam chodzi\u0142o? Presja na wysokie Velocity z kolei mo\u017ce prowadzi\u0107 do niesko\u0144czonych historyjek (niekt\u00f3rzy ze strachu dziel\u0105 historyjki na PART1 i PART2, byle tylko co\u015b zaliczy\u0107 na koniec sprintu). Czy o to nam chodzi\u0142o? Dodatkowo, znane s\u0105 przypadki zawy\u017cania Velocity przez wrzucanie tam r\u00f3\u017cnych zada\u0144, kt\u00f3re zesp\u00f3\u0142 wykona\u0142, niekt\u00f3rych naprawd\u0119 absurdalnych, np. udzia\u0142 w szkoleniu BHP itp. Tak ko\u0144czy si\u0119 cz\u0119sto presja na ci\u0105g\u0142e wzrosty Velocity i uto\u017csamianie jej z Produktywno\u015bci\u0105. <\/p>\n\n\n\n

Je\u015bli wi\u0119c nie Produktywno\u015b\u0107, to co w zamian? Najnowszy Scrum Guide wskazuje na odpowiedzialno\u015b\u0107 Scrum Mastera za Efektywno\u015b\u0107 zespo\u0142u, nie t\u0142umacz\u0105c przy tym niestety, czym ona jest. W zamian dostajemy bardzo du\u017c\u0105 elastyczno\u015b\u0107 tej definicji, z kt\u00f3rej mo\u017cemy skorzysta\u0107 ju\u017c teraz. Na pocz\u0105tek za\u0142\u00f3\u017cmy, \u017ce odchodzimy od mierzenia Velocity w Story Points, a jedyne co robimy, to zliczamy sztuki zamkni\u0119tych (uko\u0144czonych i odebranych przez PO) historyjek. Czym to w zasadzie si\u0119 r\u00f3\u017cni od zliczania Story Point\u00f3w? Ot\u00f3\u017c liczenie sztuk ma kilka niepodwa\u017calnych zalet i stosowane jest powszechnie r\u00f3wnie\u017c w mojej firmie:<\/p>\n\n\n\n