GoldenLine
Zaloguj się

konto usunięte

Temat: Scrum a sprawa polska

Obecni na tej grupie chyba się zgadzają, że scrum to świetna (bliska doskonałej) metodologia* prowadzenia projektu, prawdopodobnie dla wszystkich stron.

Polski kapitalizm jest jednak dość młody i dopiero wychodzi z okresu, kiedy najlepszym pomysłem na biznes było orżnięcie klienta na grubą (im grubszą tym lepiej) kasę. W związku z tym klienci w Polsce niechętnym okiem patrzą na prowadzenie projektu w którym płacą za godzinę, bo podejrzliwość nakazuje sądzić że developerzy będą za kasę owego klienta grać w gierki czy robić "YouTube marathon" zamiast generować realną wartość biznesową.

Z reguły obawy te znikają po jednym-dwóch sprintach, kiedy klient widzi realną wartość biznesową wygenerowanej za jego pieniądze (a raczej w opłaconych godzinach) aplikacji. Co oznacza, że klient "po jednym sprincie" jest już zasadniczo "nasz" i jedyne, o co pozostaje walczyć, to jak najlepsze wykonanie projektu jak najbardziej zgodnego z możliwościami klienta.

Mówię tu jednak o problemie wcześniejszym: jak w ogóle przekonać klienta do owego "pierwszego sprintu", czyli po prostu zaeksperymentowania z projektem prowadzonym według metodologii* Scrum? Czy znacie jakieś patenty, opowieści, "złote zdania" które mogą przekonać sceptyków?

* - Bartek, spróbuj tylko, a będzie to mój ostatni post na tej grupie. Plus będziemy się razem z Paulem (który otwarcie nazywa scrum "metodologią") natrząsać z Twojego "korygowania". ;)
Link do wypowiedziLink
Robert Dober

Robert Dober Ruby on Rails,
Aplikacje
Internetowe, ruby,
ROR

Temat: Scrum a sprawa polska

Tomasz Stachewicz:
Obecni na tej grupie chyba się zgadzają, że scrum to świetna (bliska doskonałej) metodologia* prowadzenia projektu, prawdopodobnie dla wszystkich stron.

Polski kapitalizm jest jednak dość młody i dopiero wychodzi z okresu, kiedy najlepszym pomysłem na biznes było orżnięcie klienta na grubą (im grubszą tym lepiej) kasę. W związku z tym klienci w Polsce niechętnym okiem patrzą na prowadzenie projektu w którym płacą za godzinę, bo podejrzliwość nakazuje sądzić że developerzy będą za kasę owego klienta grać w gierki czy robić "YouTube marathon" zamiast generować realną wartość biznesową.

Z reguły obawy te znikają po jednym-dwóch sprintach, kiedy klient widzi realną wartość biznesową wygenerowanej za jego pieniądze (a raczej w opłaconych godzinach) aplikacji. Co oznacza, że klient "po jednym sprincie" jest już zasadniczo "nasz" i jedyne, o co pozostaje walczyć, to jak najlepsze wykonanie projektu jak najbardziej zgodnego z możliwościami klienta.

Mówię tu jednak o problemie wcześniejszym: jak w ogóle przekonać klienta do owego "pierwszego sprintu", czyli po prostu zaeksperymentowania z projektem prowadzonym według metodologii* Scrum? Czy znacie jakieś patenty, opowieści, "złote zdania" które mogą przekonać sceptyków?

* - Bartek, spróbuj tylko, a będzie to mój ostatni post na tej grupie. Plus będziemy się razem z Paulem (który otwarcie nazywa scrum "metodologią") natrząsać z Twojego "korygowania". ;)


Klient nigdy nie zgodzi sie na realne płacenie za godzinę pracy programisty. Płaci on za efekt i funkcjonalność jaką dostanie.

Jeden programista wykona funkcjonalność w zupełnie innym czasie niż inny zdolny człowiek.
Realna ilość czasu spędzonego nad projektem nie jest zawsze taka sama jak ilość godzin wyceniona na dany sprint (nie da się tego precyzyjnie wyliczyć).
Link do wypowiedziLink
Dariusz Macina

Dariusz Macina Technology Manager,
Making Waves Polska

Temat: Scrum a sprawa polska

Robert Dober:
Klient nigdy nie zgodzi sie na realne płacenie za godzinę pracy
programisty. Płaci on za efekt i funkcjonalność jaką dostanie.

Jeden programista wykona funkcjonalność w zupełnie innym czasie
niż inny zdolny człowiek.
Realna ilość czasu spędzonego nad projektem nie jest zawsze taka sama jak ilość godzin wyceniona na dany sprint (nie da się
tego precyzyjnie wyliczyć).

Nie moge sie z tym zgodzic. Niby czemu klient nie mialby placic za realna godzine pracy? Pracowales kiedykolwiek jako konsultant bezposrednio u klienta? Przynajmniej w przypadkach z ktorymi mam do czyniena jest wlasnie tak, ze klient placi za godzine pracy. Nawet jesli realizujesz projekt fixed-price to i tak przeciez wycene opierasz na jakichs estymacjach - a estymaty musza uwzgledniac team jakim dysponujesz.

Jest jasne, ze ludzie pracuja roznym tempem i dlatego wlasnie najmujac ludzi do projektu wyrozniasz role np. junior, senior w zaleznosci od umiejetnosci. Lepszy gosciu kosztuje wiecej. Sprobuj wynajac sie jako freelancer/zewnetrzny konsultant, zobaczysz ze bedziesz mial placone od godziny.

Hmm... a moze ja po prostu zyje w jakiejs innej rzeczywistosci? ;)

Sorry za off-topic ale pozno jest ;)Dariusz Macina edytował(a) ten post dnia 22.05.08 o godzinie 02:40
Link do wypowiedziLink

konto usunięte

Temat: Scrum a sprawa polska

Tak jak Darek pisze - płacenie od godziny nie jest wcale takie od czapy i niespotykane, jak byś, Robert, myślał.

A Scrum zakłada oczywiście powstanie realnej wartości biznesowej w trakcie sprintu, co nie zmienia faktu że klient płaci (tak naprawdę) od godziny. Co wynika częściowo z dość miękkich kryteriów określania zadań - wiadomo że "must have" zostaną zrobione wszystkie, "should have" z reguły też (przynajmniej w połowie), a "could have" tylko jeśli któryś z dwóch poprzednich nie był show-stopperem.
Link do wypowiedziLink
Dariusz Macina

Dariusz Macina Technology Manager,
Making Waves Polska

Temat: Scrum a sprawa polska

Wydaje mi sie, ze jedyne co mozna (trzeba) robic to uswiadamiac, uswiadamiac i jeszcze raz uswiadamiac klientow o tym jak powstaje produkt i jaka jest charakterystyka pracy zespolu.

Wedlug mnie, w przypadku placenia za godzine kluczem do sukcesu jest zapewnienie klientowi poczucia bezpieczenstwa. Innymi slowy, wykladajacy kase musi miec pewnosc, ze zespol rzeczywiscie bedzie przez zaplacony czas pracowac a nie - jak to Tomek ujal - robic "YouTube marathon".

Z mojego doswiadczenia wynika ze zdecydowanie latwiej jest przekonac klienta jesli bedzie mial mozliwosc sporej kontroli procesu wytworczego. Dobrym sposobem jest np. zbudowanie teamu skladajacego sie po czesci z ludzi reprezentujacych klienta (i to w roli prosiakow bezposrednio bioracych udzial w developmencie). Wowczas znika ta niewidzialna barykada wytworca - odbiorca.
Sam uczestnicze w projekcie, w ktorym interaction designerzy to pracownicy odbiorcy, developerzy sa ode mnie z firmy a PM'em jest ktos zupelnie niezalezny. Akcja dzieje sie w biurze klienta, dzieki czemu wykladajacy kase wie ze jakby co to ma zespol pod reka.
Link do wypowiedziLink
Piotr T.

Piotr T. Spring/Microservices

Temat: Scrum a sprawa polska

Robert Dober:

Klient nigdy nie zgodzi sie na realne płacenie za godzinę pracy programisty. Płaci on za efekt i funkcjonalność jaką dostanie.
Zagadka brzmi jak wiele kosztuje wyprodukowanie/wdrożenie produktu w dużej firmie za pomocą konsultantów a ile metodą "tradycyjną".
W pierwszym wypadku wycena jest oparta o koszty + zakładaną stopę zwrotu z konsultanta.
W drugim o tzw. "strategię dla wygranej" - ile klient z tego będzie miał i na tej podstawie ile można zarobić na tym że on zarabia :).

Im większe korzyści wynikające ze skali przedsiębiorstwa , niż ze skomplikowania produktu tym więcej będzie kosztować wdrożenie systemu metodą tradycyjną .

Dlatego duży klient się zgodzi :) .Bo płacenie od godzin jest w takim przypadku tańsze niż zakup kolejnej funkcjonalności .
Dodatkowo jeśli zespół działa według SCRUMa to od razu można negocjować rabat przynajmniej na pierwszy sprint żeby płacić za godziny "efektywne" czyli za 8h płacić tak jak za 5h.

Apropo : Asysta konsultanta technicznego w Polsce z Microsoftu kosztuje od 120$ do ok. 1000$ za godzinę a mimo to są chętni.
Link do wypowiedziLink
Piotr Słowik

Piotr Słowik projektowanie mobile
user experience to
jest to :]

Temat: Scrum a sprawa polska

Wydaje mi się, że odpowiednia osoba nie będzie miała problemu z wyjaśnieniem klientowi profitów wynikających z rozliczania godzinowego.

Jeśli klient naprawdę interesuje się projektem i bierze udział w całym procesie Scrumowym czy to osobiście czy przez osobę product ownera to ryzyko "bycia oszukanym" drastycznie spada.

Wbrew pozorom hasło "rozliczanie godzinowe" nie wywołuje u klientów reakcji alergicznych. Z mojego doświadczenia wynika, że wcale nie tak rzadko koszty produkcji danej aplikacji są niższe od tych z początkowej wyceny, która zawsze obejmuje element marginesu bezpieczeństwa.
Link do wypowiedziLink
Bartosz Kramek

Bartosz Kramek Fundacja Otwarty
Dialog

Temat: Scrum a sprawa polska

Tomasz Stachewicz:
Mówię tu jednak o problemie wcześniejszym: jak w ogóle przekonać klienta do owego "pierwszego sprintu", czyli po prostu zaeksperymentowania z projektem prowadzonym według metodologii* Scrum? Czy znacie jakieś patenty, opowieści, "złote zdania" które mogą przekonać sceptyków?

Klient: Ok... a ile to będzie właściwie kosztować?

Paul Klipp: To zależy od Ciebie

:)
Link do wypowiedziLink

konto usunięte

Temat: Scrum a sprawa polska

Doskonałe :) Więcej takich proszę :)
Link do wypowiedziLink
Ewa F.

Ewa F. HR

Temat: Scrum a sprawa polska

Z innej beczki rzecz ujmując (tej wewnętrznej)-
polskie realia struktur organizacyjnych a organizacja scruma.
Przyszło mi pracować w firmie, gdzie pracę organizuje scrum i tu się pojawia mnóstwo pytań:

- czas pracy etatowy a zadaniowe podejście scruma (to jeszcze można rozgryźć)
- stanowisko szeregowego pracownika a przechodnia rola scrum mastera jak to się ma do wynagrodzenia na ten przykład
- mozliwość wybrania każdego na sm a różny poziom kompetencji...
- funkcja kierownika a sm w projekcie

i jeszcze więcej
jakie widzicie sposoby na najsensowniejsze poradzenie sobie z tymi kwestiami?
Link do wypowiedziLink
Piotr Słowik

Piotr Słowik projektowanie mobile
user experience to
jest to :]

Temat: Scrum a sprawa polska

- czas pracy etatowy a zadaniowe podejście scruma (to jeszcze można rozgryźć)

Nie widzę tutaj problemu. Dobrze skonstruowane tickety nie powinny zająć programiście więcej niż dzień roboczy. Jeśli dany ticket zajmuje więcej czasu to albo powinien zostać zatomizowany (rozbity na większa ilość ticketów), albo po prostu zajmie większą ilość czasu w ramach normalnej, etatowej pracy.
Po to są estymacje, aby dobrze i przede wszystkim realnie ocenić czas potrzebny na stworzenie pakietu żądanych funkcjonalności w danym sprincie. Jeśli okazuje się, że programiści nie pracują tak szybko jak się początkowo zakładało to sprawę przedyskutowuje się na retrospekcjach.
Chyba, że chodziło o coś innego a ja nie bardzo zrozumiałem pytanie :)
- stanowisko szeregowego pracownika a przechodnia rola scrum mastera jak to się ma do wynagrodzenia na ten przykład

To chyba zależy od organizacji pracy w firmie i rodzaju podpisanej z SM umowy? Ja tutaj widzę dwa rozwiązania: praca na etat lub rozliczanie godzinowe. Tutaj pojawia się jednak problem. Jeśli rozliczanie godzinowe to albo wysokie stawki (by wyjść na swoje) albo dużo projektów (mało dokładna praca). Tak więc etat wydaje mi się najbardziej sensowny, jednak to w dużej mierze zależy od konkretnego człowieka.
- mozliwość wybrania każdego na sm a różny poziom kompetencji...

To jest jedno z tych założeń teoretycznych, które jak najbardziej mogą podlegać zmianom :) Moim zdaniem dobrym rozwiązaniem są "dedykowani" SM. Czy każdy może zostać SM? Moim zdaniem np. programista z danego projektu nie powinien.

Pozdrawiam
Link do wypowiedziLink
Ewa F.

Ewa F. HR

Temat: Scrum a sprawa polska

Dzięki Piotrze.
Na ile miałam okazję zobaczyć scruma póki co, to właśnie funkcja sm jest przechodnia i każdy członek zespołu może nim potencjalnie być, a kompetencje wiadomo, różne.
stąd moje pytanie. Poza tym kwestie finansowe- pytanie czy i jakie powinny mieć odbicie...

Jeśli dobrze Cię zrozumiałam, jeden sm może równocześnie prowadzić kilka projektów? Myślałam, że to dotyczy tylko PO.?
Link do wypowiedziLink
Paweł Gawliczek

Paweł Gawliczek QA Manager

Temat: Scrum a sprawa polska

Nie spotkałem się jeszcze z przypadkiem kiedy jeden Scrum Master uczestniczy w kilku projektach. Może to być troche kłopotliwe ... Scrum Master ma pomagać zespołowi pokonywać problemy, podnośić współczynnik skupienia. Jak go nie ma może się to źle skończyć (no chyba że mówimy o super doświadczonych zespołach, jednak nawet wtedy bym tego nie polecał).
Link do wypowiedziLink
Piotr Słowik

Piotr Słowik projektowanie mobile
user experience to
jest to :]

Temat: Scrum a sprawa polska

Stad właśnie napisałem o etacie, jako najbardziej odpowiedniej formie.
Moim zdaniem bardzo doświadczony SM może spróbować poprowadzić dwa projekty jednocześnie, ale zakładając, że będą to dwa zespoły w sąsiadujących ze sobą pokojach :)

Najlepszym rozwiązaniem jest jeden SM na jeden projekt.

Ewo, nie bardzo wyobrażam sobie sytuację, w której SM mógłby zostać każdy z członków zespołu. Jestem zwolennikiem jasno i z góry ustalonych kompetencji i obowiązków.

Poza tym SM jakby nie było jest punktem kontaktu między developerami a klientem, głównie poza codziennymi spotkaniami. I tak się zastanawiam, czy wielokrotna zmiana kompetentnej do kontaktu osoby dobrze by wpłynęła po pierwsze na rozwój projektu a po drugie na zadowolenie klienta.
Link do wypowiedziLink

konto usunięte

Temat: Scrum a sprawa polska

Praca Scrum Mastera potrzebna do prowadzenia jednego projektu nie ma (moim zdaniem) szans wypełnić pełnego (8h/dzień) etatu. Stąd nie rozumiem co złego jest w jednym SM dla 2-3 projektów?
Link do wypowiedziLink
Paweł Gawliczek

Paweł Gawliczek QA Manager

Temat: Scrum a sprawa polska

Piotr Słowik:
Stad właśnie napisałem o etacie, jako najbardziej odpowiedniej formie.
Moim zdaniem bardzo doświadczony SM może spróbować poprowadzić dwa projekty jednocześnie, ale zakładając, że będą to dwa zespoły w sąsiadujących ze sobą pokojach :)
Ryzykowne ale możliwe :)

Najlepszym rozwiązaniem jest jeden SM na jeden projekt.

Ewo, nie bardzo wyobrażam sobie sytuację, w której SM mógłby zostać każdy z członków zespołu. Jestem zwolennikiem jasno i z góry ustalonych kompetencji i obowiązków.
Tutaj się nie zgodzę. W moim teamie wprowadziliśmy przechodnią rolę scrum mastera. Zresztą temat został już poruszany na polish agile user group. Zainteresowanych odsyłam tutaj

Poza tym SM jakby nie było jest punktem kontaktu między developerami a klientem, głównie poza codziennymi spotkaniami.
Czy to nie jest odpowiedzialność Product Ownera ? >I tak się zastanawiam, czy wielokrotna zmiana kompetentnej do
kontaktu osoby dobrze by wpłynęła po pierwsze na rozwój projektu a po drugie na zadowolenie klienta.
Link do wypowiedziLink
Piotr Słowik

Piotr Słowik projektowanie mobile
user experience to
jest to :]

Temat: Scrum a sprawa polska

Częściowo tak, ale z mojego doświadczenia wynika, że klient jako taki mimo wszystko chce mieć osobisty kontakt (raz na jakiś czas) z przedstawicielem wykonawcy.

Są sprawy istotne, które nie zawsze załatwisz z Product Ownerem.

Wydaje mi się, że sprawa "przechodności" SM w dużej mierze zależy od stopnia transparencji projektu na szczeblu zleceniodawca - wykonawca. Jeśli Scrum jest raczej spodobem na wewnętrzą organizację to ok. Natomiast, jeśli większość procesów jest transparentna to ja jednak opowiadam się za stałym SM.

Nie widzę natomiast problemu, żeby w przypadku kiedy SM nie może z przyczyn różnych poprowadzić Scrum Meetingu jego rolę przejął jeden z najbardziej doświadczonych członków zespołu.
Link do wypowiedziLink
Paweł Gawliczek

Paweł Gawliczek QA Manager

Temat: Scrum a sprawa polska

Przechodznia rola ScrumMastera w dużym stopniu pozwala zapewnić "płynność pracy zespołu" w momencie kiedy obecny Scrum Master jest nieobecny.

Nie twierdzę, że przechodni Scrum Master jest rozwiązaniem na stałe. Po pewnym czasie zespół powinien sam dojść do tego kto jest do tego lepiej predysponowany.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Dlaczego scrum działa




Wyślij zaproszenie do
Anuluj