Czym jest scrum?

Na samym początku scrum był tylko wykorzystywany w IT, ale z biegiem czasu zauważono, że można go wykorzystać prawie wszędzie. Postępując z jego założeniami jesteśmy w stanie opracowywać projekty idealne, wyróżniające się jakością oraz bardzo krótkim terminem realizacji. A jak można się łatwo domyślić, będzie to znacznie wpływać na przychód każdej firmy.

Metodyka scrum – jakie ma zalety i co ją wyróżnia?

Prowadzenie projektów metodyką scrum można bardzo łatwo przedstawić w sposób obrazowy. Załóżmy, że jesteśmy copywriterami, piszącymi e-booka. Dostaliśmy takie zlecenie od klienta oraz dokładne wytyczne. Jest w nich podane, ile stron ma mieć e-book, kiedy trzeba oddać kolejne rozdziały, jaką mają mieć objętość, jaki temat, jakie zagadnienia poruszać, jaką grafikę posiadać i gdzie dokładnie ją zamieszczać itp. Taki sposób zlecania pracy kreatywnej może wydawać się dla zleceniodawcy najlepszy, ponieważ efekt będzie spełniał jego oczekiwania, a dodatkowo wszystko jest jasne na początku, więc oszczędzi to czas i pieniądze. Nic bardziej mylnego. Często założenia zleceniodawcy mają się nijak do realnej pracy wykonawcy. Może okazać się, że potrzebuje on więcej czasu na zgromadzenie materiałów źródłowych lub że w trakcie pisania okaże się, iż niektóre rozdziały powinny być krótsze a inne dłuższe. Gdyby zlecenie opierało się na metodyce scrum, to copywriter miałby większe pole manewru, mógłby swobodnie pracować, a ze zleceniodawcą kontaktowałby się np. raz w tygodniu, informując o postępie prac. To pozwoliłoby mu na natychmiastowe reagowanie na różne przeciwności, jak, awaria komputera, chwilowa niedyspozycja czy konieczność poświęcenia większej ilości czasu danemu rozdziałowi e-booka. W efekcie zarówno copywriter, jak i zleceniodawca byliby bardziej zadowoleni ze współpracy.

1. scrum kończy się tam, (autor: Qjanusz | data: 29/06/18 | godz.: 08:29)
   gdzie pojawi się pytanie sponsora o ilość sprintów, po których projekt będzie można uznać za zamkniety.
   
   
   
2. @1. Akurat to da się zrobić (autor: Gakudini | data: 29/06/18 | godz.: 10:32)
   1. Tworzysz backlog
   2. szacujesz zgrubnie Story Pointy dla wszystkich zadań
   3. szacujesz ile SP można zrobić w 1 sprincie
   4. dzielisz sumę z 2. przez 3. i masz wynik wyrażony w ilości sprintów.
   Jeżeli zespół nie jest w stanie tego zrobić, oznacza to, że zespół nie ma doświadczenia w prowadzeniu takich projektów.
   Jeśli bierzesz wykonawców bez doświadczenia to inna metodologia nic tu nie pomoże. PRINCE2 dokładnie poda Ci czas i koszty, ale na koniec tego czasu i pieniędzy i tak projekt będzie najprawdopodobniej niezrealizowany.
   
   
3. Nie "metodyka" scrum, tylko "metoda" (autor: Star-Ga-Te | data: 29/06/18 | godz.: 11:37)
   Ja wiem, że metodyka brzmi poważniej, jednak to jest błędne określenie METODY.
   
   
4. @02 (autor: bmiluch | data: 29/06/18 | godz.: 15:22)
   jeżeli wymieniasz zelówki w 1000 lub nawet milionie par butów - pełna zgoda
   
   w oryginalnych projektach i skomplikowanych przypadkach proponowane porzez Ciebie rozwiązanie to "bajki" dla klienta
   
   
   
   
5. w Polsce dopiero SCRUM? (autor: pandy | data: 29/06/18 | godz.: 17:18)
   nie wiedzialem ze manager marketing story jest tak zacofane... SCRUM byl modny tak z 4 lata temu, teraz jest na topie jest DevOps i Agile.
   Swoja droga SCRUM jak i inne metody jest sposobem zdejmowania ciezaru decyzyjnego i ewentualnej porazki z leaderow projektu czy managerow - charakterystyczny dla ludzi bez wiedzy inzynierskiej ale dobrych blablingowo...
   
   
6. :)) (autor: Kenny | data: 30/06/18 | godz.: 15:34)
   1. To pytanie do product ownera. Dev team umie oszacowac effort a jego velocity jest znane, wiec wystarczy oszacowac backlog, tak jak napisal Gakudini. Tylko ze product backlog to zywy organizm a jego zmiennosc zalezy od tego jak trafnie product owner potrafi okreslic wymagania.
   
   4. Im bardziej skomplikowany projekt, tym scrum bardziej sie sprawdza. Zadaniem dostawcy jest wyedukowac klienta jaka jest jego rola a w szczegolnosci obowiazki, od tego sie zaczyna.
   
   5. Scrum jest agile, cos pomyliles.
   
   
7. @Kenny (autor: Qjanusz | data: 2/07/18 | godz.: 23:12)
   Jeżeli dev team ma powtarzalne zadania, które przekładają się na przewidywalny effort, jeżeli backlog jest z góry ustalone (przy czym backlog z definicji prosi sie o grzebanie), jeżeli product owner ma kręgosłup i najważniejsze, nikt nie liczy kasy... to a i owszem.
   
   Tyle teorii. W praktyce nie raz widziałem jak podczas męskiej rozmowy przy stole scrum padał jak mucha. pandy też dobrze napisał. Scrum to rozmycie odpowiedzialności i to jest kolejna słabość podejścia z punktu widzenia trzymającego kasę.
   
   
   
8. oj panie Qjanusz, w Agile & Scrum jest dokladnie odwrotnie (autor: Kenny | data: 5/07/18 | godz.: 23:03)
   Sponsor + produkt owner w zalozonym terminie i zaloznoym koszcie (!) dostaja to... co sobie wpisza w backlog otrzymujac w zamian od dev teamu estymacje.
   
   Projekt uznamy za zamkniety gdy w zalazonym czasie i koszcie otrzymaja produkt w specyfikacji, na ktorej im najbardziej zalezalo.
   
   Slaby to dev team jesli nie zna sie na swojej robocie ;) Znajac sie, nie bedzie mial probelmow z estymacja nowych taskow.
   
   Jesli juz wiec mowimy o odpowiedzialnosci, to mozemy co najwyzej mowic o jej przerzuceniu na klienta (product ownera), co jest swietnym rozwiazaniem. Jednak aby to zadzialalo, trzeba go non stop edukowac - priorytetyzuj sobie featuresy a my ci powiemy ile zajmie ich
   dostarczenie.
   
   Realizujemy tak projekty zarowno trwajace 3 tyg jak i 3 miesiace i jest git. Grunt to edukacja klienta.