{"id":29615,"date":"2023-06-30T11:36:13","date_gmt":"2023-06-30T09:36:13","guid":{"rendered":"https:\/\/www.altkomsoftware.com\/?p=29615"},"modified":"2026-01-26T10:02:10","modified_gmt":"2026-01-26T09:02:10","slug":"scrum-jak-waterfall","status":"publish","type":"post","link":"https:\/\/stg.altkomsoftware.com\/pl\/blog\/scrum-jak-waterfall\/","title":{"rendered":"Scrum jak Waterfall, czyli jak zarz\u0105dza\u0107 efektywno\u015bci\u0105 zespo\u0142\u00f3w, \u017ceby dowozi\u0107 na czas"},"content":{"rendered":"\n

Case Study: Jak szacowa\u0107 terminy i bra\u0107 odpowiedzialno\u015b\u0107 za wyniki?<\/h2>\n\n\n\n

Dla jednego z naszych klient\u00f3w prowadzili\u015bmy skomplikowany projekt budowy platformy sprzeda\u017cowej dla produkt\u00f3w finansowych. Nasz partner ju\u017c na wst\u0119pie posiada\u0142 wysokie standardy procesowe i metodyki realizacji projekt\u00f3w, sk\u0142aniaj\u0105c si\u0119 powoli ku metodykom zwinnym<\/strong>.<\/p>\n\n\n\n

Wa\u017cne jednak, \u017ce poprzedni etap projektu by\u0142 etapem waterfall \u2013 nie startowali\u015bmy z pracami od zera, ale do\u0142\u0105czaj\u0105c do klienta ju\u017c w trakcie pracy nad rozwi\u0105zaniem. Dlatego ca\u0142y zesp\u00f3\u0142 projektowy (nasz i klienta) musia\u0142 p\u0142ynnie przej\u015b\u0107 z jednej metody wykonywania projektu, do realizacji w scrumie<\/strong>. <\/p>\n\n\n\n

Nasz zesp\u00f3\u0142 projektowy sk\u0142ada\u0142 si\u0119 z ponad 20 os\u00f3b, w tym g\u0142\u00f3wnie developer\u00f3w. Jednak dla powodzenia ca\u0142ego projektu mieli\u015bmy te\u017c grup\u0119 os\u00f3b w rolach analityk\u00f3w biznesowo-systemowych, a tak\u017ce tester\u00f3w. Do tego Scrum<\/strong> Master jako osobna rola, ze wzgl\u0119du na liczb\u0119 os\u00f3b w teamie i poziom skomplikowania projektu.  <\/p>\n\n\n\n

Co wa\u017cne, nasz partner mia\u0142 jedno bardzo istotne oczekiwanie. Chocia\u017c realizowany przez nas etap budowy platformy sprzeda\u017cowej mia\u0142 by\u0107 prowadzony w metodykach zwinnych<\/strong> i nie umawiali\u015bmy si\u0119 na konkretny termin oddania, to jednak w miar\u0119 szybko po uruchomieniu projektu mieli\u015bmy oszacowa\u0107 dat\u0119 wdro\u017cenia.<\/p>\n\n\n\n

Nie jest to standardowe dzia\u0142anie w scrumie<\/strong>, ale dzi\u0119ki odpowiednim procesom, standardom i narz\u0119dziom, prowadz\u0105c projekty agile\u2019owe, mo\u017cna dosy\u0107 dok\u0142adnie szacowa\u0107 dat\u0119 realizacji, nie pozbawiaj\u0105c si\u0119 zalet, jakie niesie za sob\u0105 zwinno\u015b\u0107 w software developmencie.<\/strong><\/p>\n\n\n\n

\"Nagranie<\/a><\/figure>\n\n\n\n

Etapy budowania docelowego modelu scrum oraz planowania realizacji<\/h2>\n\n\n\n

Etap 1.0<\/h3>\n\n\n\n

Poniewa\u017c rozpoczynaj\u0105c wsp\u00f3\u0142prac\u0119 z klientem przechodzili\u015bmy z modelu waterfallowego, to wsp\u00f3lnie w zespole zdecydowali\u015bmy, \u017ce gwa\u0142towne przej\u015bcie do realizacji w pe\u0142nym scrumie<\/strong> mo\u017ce by\u0107 zbyt ryzykowne. <\/p>\n\n\n\n

Pracuj\u0105c ponad dwudziestoosobowym zespo\u0142em i wdra\u017caj\u0105c pierwsze standardy oraz narz\u0119dzia (cho\u0107by Jir\u0119<\/a>), postanowili\u015bmy na starcie etapu nie dzieli\u0107 zespo\u0142u i potraktowa\u0107 dalsze wyceny poszczeg\u00f3lnych funkcjonalno\u015bci\/historyjek na poziomie story point\u00f3w, ale przeliczanych 1:1 w zgodzie z czasem (przelicznik godzinowy).<\/p>\n\n\n\n

Odstaje to od standard\u00f3w scrumowych<\/strong>, ale takie podej\u015bcie pomog\u0142o p\u0142ynnie rozpocz\u0105\u0107 prac\u0119 i krok po kroku wyedukowa\u0107 zesp\u00f3\u0142 po stronie klienta, jak docelowe story pointy powinny tak naprawd\u0119 wygl\u0105da\u0107.  <\/p>\n\n\n\n

Wyceny, podobnie jak na poprzednim waterfallowym etapie, realizowane by\u0142y ekspercko. Grupa lider\u00f3w po naszej stronie dokonywa\u0142a kolejnych wycen, a zesp\u00f3\u0142 realizowa\u0142 taski wierz\u0105c, \u017ce wycena jest prawid\u0142owa. Kolejnym zadaniem, kt\u00f3re nie by\u0142o do ko\u0144ca zgodne z podr\u0119cznikowym scrumowym<\/strong> podej\u015bciem, by\u0142o r\u00f3wnoleg\u0142e uruchomienie sprint\u00f3w analitycznych razem ze sprintami developerskimi.<\/p>\n\n\n\n

Wynika\u0142o to ze wspomnianej ju\u017c wcze\u015bniej pro\u015bby klienta, aby dok\u0142adnie wskaza\u0107 dat\u0119 wdro\u017cenia. Pom\u00f3c w tym mia\u0142 Fix Version Report. Jednak, aby go u\u017cy\u0107, niezb\u0119dna by\u0142a wycena wszystkich historyjek przypisanych w backlogu do tego etapu wytw\u00f3rczego i to na poziomie bardzo szczeg\u00f3\u0142owym. <\/p>\n\n\n\n

Sam start budowania backlogu by\u0142 wa\u017cnym etapem w kontek\u015bcie architektury i schematu wi\u0105zania historyjek w epiki, wersje itp. Wiedzieli\u015bmy, \u017ce musi by\u0107 to przemy\u015blane, poniewa\u017c p\u00f3\u017aniej wszelkie raportowanie danych z Jiry b\u0119dzie bardzo u\u0142atwione (np. b\u0119dziemy mie\u0107 mo\u017cliwo\u015b\u0107 kontekstowego wybierania na poziomie merytorycznym danej wersji czy wszystkich historyjek zwi\u0105zanych z kontraktami integracyjnymi).  <\/p>\n\n\n\n

Ca\u0142y ten etap trwa\u0142 3 sprinty. <\/p>\n\n\n\n

Etap 2.0<\/h3>\n\n\n\n

Na tym etapie powoli zbli\u017cali\u015bmy si\u0119 do zbudowania docelowego modelu scrum<\/strong> w projekcie. Ca\u0142y nasz team podzieli\u015bmy najpierw na dwa, a nast\u0119pnie na trzy zespo\u0142y scrumowe<\/strong>, tak aby powoli zachodzi\u0142a w nich bliska wsp\u00f3\u0142praca, komunikacja i samoorganizacja.<\/p>\n\n\n\n

Ka\u017cdy z zespo\u0142\u00f3w posiada\u0142 grup\u0119 developer\u00f3w oraz tester\u00f3w, a analitycy do\u0142\u0105czali do zespo\u0142\u00f3w w poszczeg\u00f3lnych sprintach. Jednocze\u015bnie uruchomiali\u015bmy pozosta\u0142e standardy (na pocz\u0105tek g\u0142\u00f3wnie zebrania scrumowe<\/strong>), a tak\u017ce zacz\u0119li\u015bmy liczy\u0107 story pointy zgodnie z metodyk\u0105 (wcze\u015bniejsza edukacja pozwoli\u0142a wreszcie oderwa\u0107 je od miernika, jakim jest czas).<\/p>\n\n\n\n

Tak\u017ce wyceny by\u0142y ju\u017c liczone za pomoc\u0105 Scrum Pokera<\/a> i tym samym odpowiedzialno\u015b\u0107 za wycen\u0119 przesun\u0119li\u015bmy na ka\u017cdego z cz\u0142onk\u00f3w zespo\u0142u. <\/p>\n\n\n\n

W momencie, kiedy uruchomili\u015bmy ju\u017c elementy scrumowe<\/strong>, zacz\u0119li\u015bmy si\u0119 bacznie przygl\u0105da\u0107 burndown chartowi<\/strong> (wykresowi spalania), jako podstawowemu narz\u0119dziu do kontroli optymalnego sposobu pracy zespo\u0142u. Natomiast w momencie, w kt\u00f3rym analiza backlogu pozwoli\u0142a ju\u017c wyceni\u0107 wszystkie historyjki, bardzo przydatne okaza\u0142o si\u0119 ju\u017c wcze\u015bniej wspomniane narz\u0119dzie Fix Version. <\/p>\n\n\n\n

Capacity \u2013 podstawa wydajno\u015bci zespo\u0142u developerskiego<\/h2>\n\n\n\n

Wiedzieli\u015bmy, \u017ce dost\u0119pno\u015b\u0107 os\u00f3b niezb\u0119dnych dla danego sprintu warto planowa\u0107 do przodu. Pierwsza i podstawowa metoda, to oczywi\u015bcie plan urlop\u00f3w\/nieobecno\u015bci. Dodatkowo zastosowali\u015bmy prosty Excel, pokazuj\u0105cy dost\u0119pno\u015b\u0107 developer\u00f3w \u2014 w ko\u0144cu to oni w pierwszej linii spalali story pointy i byli kluczow\u0105 grup\u0105 ekspert\u00f3w w zespole.<\/p>\n\n\n\n

To w\u0142a\u015bnie ich obecno\u015b\u0107 sta\u0142a si\u0119 czynnikiem decyzyjnym w odniesieniu do pojemno\u015bci story point\u00f3w w ka\u017cdym sprincie. Proste obliczenia na podstawie samej (nie)obecno\u015bci developer\u00f3w by\u0142y bardziej miarodajne ni\u017c planowanie sprintu w oparciu o efekty dzia\u0142a\u0144 z poprzednich dw\u00f3ch tygodni.<\/p>\n\n\n\n

Narz\u0119dzia: czego u\u017cywa\u0107, \u017ceby monitorowa\u0107 post\u0119py i zarz\u0105dza\u0107 projektem w czasie<\/h2>\n\n\n\n

Narz\u0119dzia: Sprint burndown chart<\/h3>\n\n\n\n

Korzy\u015bci, kt\u00f3re mo\u017cemy odnie\u015b\u0107 stosuj\u0105c sprint burndown chart:<\/strong><\/p>\n\n\n\n

    \n
  • Monitorowanie post\u0119p\u00f3w w sprincie w czasie rzeczywistym;<\/li>\n\n\n\n
  • Ocena, jak wiele pracy pozosta\u0142o do wykonania;<\/li>\n\n\n\n
  • Wczesne wykrycie problem\u00f3w w danym sprincie;<\/li>\n\n\n\n
  • Wsparcie komunikacji w zespole;<\/li>\n\n\n\n
  • Motywacja w zespole;<\/li>\n\n\n\n
  • Wsparcie optymalizacji sposobu pracy w zespole.<\/li>\n<\/ul>\n\n\n\n

    Sprint burndown chart<\/strong> to narz\u0119dzie, kt\u00f3re pozwala wykry\u0107 wiele nieprawid\u0142owo\u015bci w projekcie, zaczynaj\u0105c od bardzo podstawowych b\u0142\u0119d\u00f3w jak cho\u0107by niew\u0142a\u015bciwe\/nierzetelne u\u017cytkowanie Jiry. Wiele z efektywno\u015bci prac developerskich tracimy przez proste niedopatrzenia, jak np. brak szybkiego przekierowania taska w Jirze na kolejn\u0105 osob\u0119.  <\/p>\n\n\n\n

    Mo\u017cemy z jego pomoc\u0105 r\u00f3wnie\u017c odkry\u0107, \u017ce nasze historyjki s\u0105 zbyt obszerne. Je\u017celi jaka\u015b historyjka w sprincie wymaga kilku czy nawet kilkunastu dni realizacji, warto poci\u0105\u0107 j\u0105 na mniejsze elementy.<\/p>\n\n\n\n

    Przy zbyt d\u0142ugim software developmencie<\/strong>, praca tester\u00f3w zaczyna by\u0107 nieoptymalna \u2014 zazwyczaj ju\u017c drugiego dnia sprintu testerzy powinni powoli startowa\u0107 z testami. Z naszej strony rekomendujemy historyjki poni\u017cej 13 story point\u00f3w.<\/p>\n\n\n\n

    Narz\u0119dzia: Fix Version Report<\/h3>\n\n\n\n

    Korzy\u015bci, kt\u00f3re mo\u017cemy odnie\u015b\u0107 stosuj\u0105c Fix Version Report:<\/p>\n\n\n\n

      \n
    • \u015aledzenie post\u0119pu prac nad konkretn\u0105 wersj\u0105 produktu;<\/li>\n\n\n\n
    • Strategiczna kontrola nad backlogiem (w projektach zwinnych backlog \u017cyje i cz\u0119sto dochodz\u0105 nowe historyjki. Przy zastosowaniu tego narz\u0119dzia product owner mo\u017ce zyska\u0107 szerszy pogl\u0105d na ca\u0142o\u015b\u0107 realizacji. Zobaczy\u0107, \u017ce kolejne zmiany oddalaj\u0105 nas od wdro\u017cenia i podj\u0105\u0107 odpowiednie kroki, np. okroi\u0107 MVP, \u017ceby wypu\u015bci\u0107 je na czas);<\/li>\n\n\n\n
    • Dok\u0142adne zaplanowanie prac nad dan\u0105 wersj\u0105;<\/li>\n\n\n\n
    • Ci\u0105g\u0142e doskonalenie proces\u00f3w pracy<\/li>\n\n\n\n
    • Koordynacja dzia\u0142a\u0144 (biznes-technologia) w celu osi\u0105gni\u0119cia cel\u00f3w.<\/li>\n<\/ul>\n\n\n\n

      Aby rozwia\u0107 wszelkie w\u0105tpliwo\u015bci, \u017ce projekt pozbawili\u015bmy elastyczno\u015bci kosztem daty wdro\u017cenia, to chocia\u017c wystartowali\u015bmy z poziomu 1100 story point\u00f3w, ostatecznie MVP rozbudowa\u0142o si\u0119 do 1400 story point\u00f3w.<\/p>\n\n\n\n

      Scrum<\/strong> nie s\u0142u\u017cy do zamkni\u0119cia backlogu, ale cho\u0107by dzi\u0119ki wymienionym wy\u017cej narz\u0119dziom, umo\u017cliwia ocen\u0119 i konsekwencj\u0119 dzia\u0142a\u0144, a tak\u017ce przejrzyste planowanie prac oraz realizacj\u0119 sprint\u00f3w w okre\u015blonych z g\u00f3ry terminach. <\/p>\n","protected":false},"excerpt":{"rendered":"

      W tym case study pokazujemy, jak przej\u0119li\u015bmy skomplikowany projekt platformy sprzeda\u017cowej w trakcie realizacji waterfallowej i krok po kroku przeszli\u015bmy do scrumowego modelu pracy \u2014 bez utraty kontroli nad harmonogramem. Opisujemy konkretne decyzje procesowe, narz\u0119dzia i kompromisy, kt\u00f3re pozwoli\u0142y du\u017cemu, ponad 20-osobowemu zespo\u0142owi nie tylko oszacowa\u0107 dat\u0119 wdro\u017cenia, ale te\u017c dowie\u017a\u0107 MVP w dynamicznie zmieniaj\u0105cym si\u0119 backlogu. To historia o \u015bwiadomym szacowaniu, odpowiedzialno\u015bci zespo\u0142u i agile\u2019u, kt\u00f3ry dzia\u0142a w realnych warunkach biznesowych.<\/b><\/p>\n","protected":false},"author":2,"featured_media":49771,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[500,1],"tags":[],"topic":[487,477],"blog-author":[412],"class_list":["post-29615","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uslugi-software-engineering","category-bez-kategorii","topic-doradztwo-technologiczne","topic-software-engineering","blog-author-marta-rutkowska"],"acf":[],"_links":{"self":[{"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/posts\/29615","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/comments?post=29615"}],"version-history":[{"count":5,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/posts\/29615\/revisions"}],"predecessor-version":[{"id":49779,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/posts\/29615\/revisions\/49779"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/media\/49771"}],"wp:attachment":[{"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/media?parent=29615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/categories?post=29615"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/tags?post=29615"},{"taxonomy":"topic","embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/topic?post=29615"},{"taxonomy":"blog-author","embeddable":true,"href":"https:\/\/stg.altkomsoftware.com\/pl\/wp-json\/wp\/v2\/blog-author?post=29615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}