eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingSCRUM umarł, niech żyje SCRUM
Ilość wypowiedzi w tym wątku: 55

  • 51. Data: 2013-08-29 10:11:02
    Temat: Re: SCRUM umarł, niech żyje SCRUM
    Od: Paweł Kierski <n...@p...net>

    W dniu 2013-08-28 20:29, Wojciech Muła pisze:
    > On Tuesday, August 20, 2013 7:58:56 AM UTC+2, Paweł Kierski wrote:
    >> Na sprint na pewno trzeba wiedzieć, o następnym trzeba mieć pojęcie
    >> w ramach zespołu. Co nie zwalnia PO od rozpisania backlogu na tyle,
    >> na ile tylko jest w stanie. Lepiej, żeby "smoki" polegały na tym, że
    >> nie wiemy w jakiej kolejności, niż nie wiemy nic w ogóle.
    >
    > Zero planu dalekosiężnego - mając specyfikację wiemy, co trzeba
    > robić, przynajmniej w zarysie. Widać ścieżkę/ścieżki krytyczne.
    >
    > Nie wykorzystywaliśmy tej wiedzy, bo fetysz "inkrementu" kazał
    > robić oderwane od siebie kawałki.

    Inkrementacja nie musi oznaczać oderwanych kawałków. Przyrost wartości
    ze sprintu na sprint czasem może być mniej widoczny dla końcowego
    użytkownika, ale dla klienta może objawić się w następnych sprintach -
    mniejszymi kosztami zmian. Prowadzenie backlogu to na prawdę
    nietrywialne zadanie.

    >> Skoro było wiadomo, co zrobić, to skąd przestoje?
    >
    > Gdybyśmy robili "warstwowo" (co było oczywiste, że to jedyna
    > sensowna droga), to nie byłoby co pokazać na review - takie
    > słyszałem wyjaśnienia. No i się robiło "pionowo" i się
    > refaktoryzowało kod napisany sprint wcześniej.

    Zaraz - czy to znaczy, że przestoje wynikały z czekania na implementację
    elementów funkcjonalności w różnych warstwach? Jeśli tak, to albo
    zawiódł podział na zespoły (odpowiadały za oddzielne warstwy?), albo
    komunikacja między zespołami - wracamy do jakiegoś ogólnego widoku
    i planowania na poziomie między zespołami.

    >> Cel spotkania - to naprawdę trudna sztuka dobrze go zdefiniować, a potem
    >> w trakcie trzymać się ścieżki. Pomaga określenie _przed_ spotkaniem
    >> z jakim ustaleniem lub odpowiedzią na jakie pytanie chcemy wyjść ze
    >> spotkania.
    >
    > Znalazłem lepszy sposób - poszedłem późno spać, przez co przez
    > cały dzień byłem senny i przetrwałem spotkania w letargu.

    I masz pretensje, że Scrum nie chce działać? 8-)

    --
    Paweł Kierski
    n...@p...net


  • 52. Data: 2013-08-30 22:41:11
    Temat: Re: SCRUM umarł, niech żyje SCRUM
    Od: Wojciech Muła <w...@g...com>

    On Wednesday, August 28, 2013 10:37:03 PM UTC+2, Andrzej Jarzabek wrote:
    > > Mieliśmy "release planning", ale nie do tego projektu.
    > >
    > > Wg mnie to jest wchodzenie w buty analityka, co jest kompletnie
    > > bez sensu.
    >
    > W jakim sensie?

    W takim, że podczas release planningu zespół programistów wykonuje
    prace analityczne. Raz, że nie ma kompetencji, dwa, że robi to w
    ograniczonym czasie.

    Czyste marnowanie czasu programistów.

    > Uważasz, że programiści nie potrzebują wiedzieć do czego
    > służy produkt, jaka jest przewidywana funkcjonalność, jaki jest plan
    > wprowadzenia do produkcji?

    Wystarczy wiedza ogólna, a jak ktoś potrzebuje znać szczegóły,
    to niech sobie przeczyta specyfikację.

    > > Osoby z oficjalnymi certyfikatami, pracujący dla dużych firm IT. Naprawdę
    > > Andrzeju, to nie ludzie z ulicy. :)
    >
    > Nie ma czegoś takiego, jak "oficjalny certyfikat" Scrum. Każdy,
    > dosłownie każdy może wystawiać "certyfikaty Scrum".

    A scrum.org prowadzony przez twórcę Scruma jest koszerny?
    I certyfikaty przez nich wydawane są coś warte?

    w.


  • 53. Data: 2013-08-30 22:55:24
    Temat: Re: SCRUM umarł, niech żyje SCRUM
    Od: Wojciech Muła <w...@g...com>

    On Thursday, August 29, 2013 10:11:02 AM UTC+2, Paweł Kierski wrote:
    > Inkrementacja nie musi oznaczać oderwanych kawałków. Przyrost wartości
    > ze sprintu na sprint czasem może być mniej widoczny dla końcowego
    > użytkownika, ale dla klienta może objawić się w następnych sprintach -
    > mniejszymi kosztami zmian. Prowadzenie backlogu to na prawdę
    > nietrywialne zadanie.

    Inkrement to jest potencjalnie sprzedawalny produkt - tak to ujmują
    w Scrum Guide. Więc nie ma możliwości np. napisania warstwy np. zapisu
    do bazy, czy komunikacji sieciowej i zakończenia na tym sprintu.
    Musi zaistnieć, coś co można pokazać klientowi, choćby to było skrajnie
    idiotyczne.

    > > Gdybyśmy robili "warstwowo" (co było oczywiste, że to jedyna
    > > sensowna droga), to nie byłoby co pokazać na review - takie
    > > słyszałem wyjaśnienia. No i się robiło "pionowo" i się
    > > refaktoryzowało kod napisany sprint wcześniej.
    >
    > Zaraz - czy to znaczy, że przestoje wynikały z czekania na implementację
    > elementów funkcjonalności w różnych warstwach? Jeśli tak, to albo
    > zawiódł podział na zespoły (odpowiadały za oddzielne warstwy?), albo
    > komunikacja między zespołami - wracamy do jakiegoś ogólnego widoku
    > i planowania na poziomie między zespołami.

    To był jeden zespół, który wziął sobie taki a nie inny zestaw tasków,
    żeby dało się zaprezentować ów "inkrement". Mimo ewidentnego idiotyzmu
    takiego podejścia - istniały "mniej" ważne taski, które można było
    wykonać niezależnie. Ale one nie dawały inkrementu.

    > > Znalazłem lepszy sposób - poszedłem późno spać, przez co przez
    > > cały dzień byłem senny i przetrwałem spotkania w letargu.
    >
    > I masz pretensje, że Scrum nie chce działać? 8-)

    Spotkania toczyły się spokojnie bez mojego aktywnego udziału. :)

    w.


  • 54. Data: 2013-08-31 11:44:18
    Temat: Re: SCRUM umarł, niech żyje SCRUM
    Od: Andrzej Jarzabek <a...@g...com>

    On 30/08/2013 21:41, Wojciech Muła wrote:
    > On Wednesday, August 28, 2013 10:37:03 PM UTC+2, Andrzej Jarzabek wrote:
    >>> Mieliśmy "release planning", ale nie do tego projektu.
    >>>
    >>> Wg mnie to jest wchodzenie w buty analityka, co jest kompletnie
    >>> bez sensu.
    >>
    >> W jakim sensie?
    >
    > W takim, że podczas release planningu zespół programistów wykonuje
    > prace analityczne. Raz, że nie ma kompetencji, dwa, że robi to w
    > ograniczonym czasie.

    No ale w release planning wcale nie chodzi o to, żeby programiści
    wykonywali pracę analityków. Chodzi o to, żeby wiedzieli jaki jest plan
    - kiedy biznes chciałby zrobić release i co z grubsza powinno się w nim
    znaleźć i żeby ewentualnie mogli zwrócić uwagę na problemy, zadać
    pytania itd.

    >> Uważasz, że programiści nie potrzebują wiedzieć do czego
    >> służy produkt, jaka jest przewidywana funkcjonalność, jaki jest plan
    >> wprowadzenia do produkcji?
    >
    > Wystarczy wiedza ogólna, a jak ktoś potrzebuje znać szczegóły,
    > to niech sobie przeczyta specyfikację.

    Ale dlaczego uważasz, że release planning odbywa się na poziomie
    "szczegółów" a nie "wiedzy ogólnej"? W XP idea jest właśnie taka, że na
    release planning ustala się do poziomu user stories lub nawet grubiej.

    Osobnym pytaniem jest na jakim poziomie operuje analityk i specyfikacja
    przez niego tworzona. Często analitycy znają się na dziedzinie programu,
    rozumieją potrzeby biznesowe, widzieli kilka programów wykonujących
    podobne funkcje, ale niekoniecznie znają się dobrze na inżynierii
    oprogramowania, w sensie jak projektować funkcjonalność, usability,
    bezpieczeństwo, administrację produktem - i przede wszystkim jak radzić
    sobie z problemem wieloznaczności specyfikacji pisanej w języku
    naturalnym. Dlatego też często zlecenie analitykowi pisanie specyfikacji
    na poziomie "jeśli użytkownik zrobi to, to program zrobi to" jest nie
    tylko kosztowne pod względem czasu pracy analityków, ale też wytworzone
    w ten sposób specyfikacje bywają bardzo problematyczne.

    >>> Osoby z oficjalnymi certyfikatami, pracujący dla dużych firm IT. Naprawdę
    >>> Andrzeju, to nie ludzie z ulicy. :)
    >>
    >> Nie ma czegoś takiego, jak "oficjalny certyfikat" Scrum. Każdy,
    >> dosłownie każdy może wystawiać "certyfikaty Scrum".
    >
    > A scrum.org prowadzony przez twórcę Scruma jest koszerny?
    > I certyfikaty przez nich wydawane są coś warte?

    Zatrudniliście scrum.org do wdrażania Scrumu?

    Moja odpowiedź jest taka, że nie mam podstaw, żeby się konkretnie
    wypowiadać o tej czy innej firmie, ale właśnie jedynym sensownym
    indykatorem tego, co jest sensowne, jest firmowanie tego przez kogoś,
    kogo się uważa za sensowną osobę mówiącą sensowne rzeczy (w książkach, w
    artyułach, na konferencjach). Osobiście nie jestem jakimś szczególnie
    wielim fanem Scruma i nie siedzę bardzo w tym środowisku siedzę, więc
    oprócz samych Schwabera i Sutherlanda kojarzę tylo Mike'a Cohna (z
    ludzi, których uważam za sensownych). Przy czym w takich przypadkach
    trzeba uważać na "degrees of separation" - jeśli zatrudniasz (dajmy na
    to) scrum.org do wdrożenia u siebie Scruma to masz dobrą szansę na
    sensowną usługę, jeśli robisz u nich certyfikację to pewnie masz dobrą
    szansę na sensowny kurs z którego wiele możesz wynieść; jeśli zarudniasz
    konsultantów, którzy są certyfikowani przez scrum.org to może masz nieco
    lepszą szansę że zrobią to sensownie, niż w przypadku ludzi z ulicy, ale
    za bardzo bym na to nie liczył.


  • 55. Data: 2013-09-02 09:50:00
    Temat: Re: SCRUM umarł, niech żyje SCRUM
    Od: Paweł Kierski <n...@p...net>

    W dniu 2013-08-30 22:55, Wojciech Muła pisze:
    > On Thursday, August 29, 2013 10:11:02 AM UTC+2, Paweł Kierski wrote:
    >> Inkrementacja nie musi oznaczać oderwanych kawałków. Przyrost wartości
    >> ze sprintu na sprint czasem może być mniej widoczny dla końcowego
    >> użytkownika, ale dla klienta może objawić się w następnych sprintach -
    >> mniejszymi kosztami zmian. Prowadzenie backlogu to na prawdę
    >> nietrywialne zadanie.
    >
    > Inkrement to jest potencjalnie sprzedawalny produkt - tak to ujmują
    > w Scrum Guide. Więc nie ma możliwości np. napisania warstwy np. zapisu
    > do bazy, czy komunikacji sieciowej i zakończenia na tym sprintu.
    > Musi zaistnieć, coś co można pokazać klientowi, choćby to było skrajnie
    > idiotyczne.

    Może za krótkie sprinty?

    >>> Gdybyśmy robili "warstwowo" (co było oczywiste, że to jedyna
    >>> sensowna droga), to nie byłoby co pokazać na review - takie
    >>> słyszałem wyjaśnienia. No i się robiło "pionowo" i się
    >>> refaktoryzowało kod napisany sprint wcześniej.
    >>
    >> Zaraz - czy to znaczy, że przestoje wynikały z czekania na implementację
    >> elementów funkcjonalności w różnych warstwach? Jeśli tak, to albo
    >> zawiódł podział na zespoły (odpowiadały za oddzielne warstwy?), albo
    >> komunikacja między zespołami - wracamy do jakiegoś ogólnego widoku
    >> i planowania na poziomie między zespołami.
    >
    > To był jeden zespół, który wziął sobie taki a nie inny zestaw tasków,
    > żeby dało się zaprezentować ów "inkrement". Mimo ewidentnego idiotyzmu
    > takiego podejścia - istniały "mniej" ważne taski, które można było
    > wykonać niezależnie. Ale one nie dawały inkrementu.

    Spróbowałbym w takim razie z dłuższymi sprintami.

    >>> Znalazłem lepszy sposób - poszedłem późno spać, przez co przez
    >>> cały dzień byłem senny i przetrwałem spotkania w letargu.
    >>
    >> I masz pretensje, że Scrum nie chce działać? 8-)
    >
    > Spotkania toczyły się spokojnie bez mojego aktywnego udziału. :)

    Wniosek - za duże zespoły? 8-)

    --
    Paweł Kierski
    n...@p...net

strony : 1 ... 5 . [ 6 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: