eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingSCRUM umarł, niech żyje SCRUM › Re: SCRUM umarł, niech żyje SCRUM
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.chmurka.net!.POSTED!not-for-mail
    From: Paweł Kierski <n...@p...net>
    Newsgroups: pl.comp.programming
    Subject: Re: SCRUM umarł, niech żyje SCRUM
    Date: Tue, 20 Aug 2013 07:51:08 +0200
    Organization: news.chmurka.net
    Lines: 43
    Message-ID: <kuv04c$53e$1@somewhere.invalid>
    References: <e...@g...com>
    <kugrmv$bts$1@somewhere.invalid>
    <2...@g...com>
    <kuji43$mev$1@somewhere.invalid>
    <6...@g...com>
    <kusdar$tpv$1@somewhere.invalid>
    <9...@g...com>
    NNTP-Posting-Host: 195.182.34.201
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: somewhere.invalid 1376977868 5230 195.182.34.201 (20 Aug 2013 05:51:08 GMT)
    X-Complaints-To: abuse-news.(at).chmurka.net
    NNTP-Posting-Date: Tue, 20 Aug 2013 05:51:08 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
    In-Reply-To: <9...@g...com>
    X-Authenticated-User: pkierski
    Xref: news-archive.icm.edu.pl pl.comp.programming:204489
    [ ukryj nagłówki ]

    W dniu 2013-08-19 19:12, Wojciech Muła pisze:
    > On Monday, August 19, 2013 8:17:58 AM UTC+2, Paweł Kierski wrote:
    >>> Więc czasem tylko utrzymujemy i wtedy tak naprawdę nie ma co obgadywać,
    >>> kończymy szybko. Ale jak przychodzą nowe rzeczy, wówczas nierzadko nie
    >>> wystarcza czasu, nawet jak rozciągniemy spotkanie na maksa i się streszczamy.
    >>> Zresztą planowanie jest w wielu przypadkach bez sensu, ponieważ bez
    >>> jakiegoś rozpoznania tematu przez programistów estymaty są z kosmosu.
    >>
    >> Czyli klasyka - brakuje wizji na poziomie trochę wyższym.
    >
    > Błędna diagnoza. Oczekiwanie na decyzje klientów. Wyobraź sobie, że
    > liczą każdą złotówkę. :)
    >
    >> Skoro są sprinty, w których "tylko utrzymujemy", to wypada się
    >> zastanowić, czy na pewno potrzeba w ogóle pracy nad tym projektem.
    >
    > Akurat to nasz główny produkt, który jest na produkcji od kilku lat.
    > Nie można go olać, to nie opensource. :)

    Czyli są sprinty, w których nie ma nic do roboty poza utrzymaniem, bo
    backlog pusty, a klient nic do niego nie zdążył dodać? Przy okazji - jak
    duże (w porównaniu do mocy zespołu) jest obciążenie samym utrzymaniem?
    Może to znaczy, że zespół może zacząć zajmować się innym projektem, co
    najwyżej pozostawiając małą rezerwę na utrzymanie?

    >> Na estymaty z kosmosu znam dwie główne metody - uczyć się estymować oraz
    >> robić proof of concept. Niektórzy twierdzą, że to nie ortodoksyjne, ale
    >> w skrajnych przypadkach, gdy temat jest kompletnie nieznany robimy
    >> sprint wcześniej badanie tematu. Siada jedna osoba i dwa, góra trzy dni
    >> szuka rozwiązań, próbuje projektować, pisać jakieś mockupy, czy co tam
    >> jeszcze potrzebne do odpowiedzi na pytanie "ile to będzie kosztowało?".
    >> Rezultatem takiego zadania jest odpowiedź, np. "już nie między 5 a 40,
    >> ale między 20 a 40".
    >
    > Były takie pomysły, ale zostały - mówiąc efemistycznie - chłodno przyjęte. :)

    Czyli jest pomysł na zmniejszenie "zdupności" estymat, ale go olewamy,
    bo tak - bez sprawdzenia? A jednocześnie duże rozjazdy w estymatach
    pozostają problemem? A jakieś inne pomysły były?

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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: