eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingpl. usenet o agileRe: pl. usenet o agile
  • 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: pl. usenet o agile
    Date: Fri, 19 Jul 2013 14:29:48 +0200
    Organization: news.chmurka.net
    Lines: 66
    Message-ID: <ksbbg1$7g3$1@somewhere.invalid>
    References: <kroiv1$p67$1@speranza.aioe.org>
    <4...@4...com>
    <51e5880e$0$1222$65785112@news.neostrada.pl>
    <8...@g...com>
    <j...@4...com>
    <3...@g...com>
    <4...@g...com>
    <v...@4...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 1374236993 7683 195.182.34.201 (19 Jul 2013 12:29:53 GMT)
    X-Complaints-To: abuse-news.(at).chmurka.net
    NNTP-Posting-Date: Fri, 19 Jul 2013 12:29:53 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
    In-Reply-To: <v...@4...com>
    X-Authenticated-User: pkierski
    Xref: news-archive.icm.edu.pl pl.comp.programming:204090
    [ ukryj nagłówki ]

    W dniu 2013-07-19 02:13, A.L. pisze:
    > On Thu, 18 Jul 2013 06:55:29 -0700 (PDT), Maciej Sobczak
    > <s...@g...com> wrote:
    >
    >>
    >>> Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.
    >>
    >> Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.
    >
    >
    > Zmiany tanie nie sa. Potwierdzam.
    >
    > Gdy sie umawia z klientem na wykonanie projektu, to trzeba wiedziec
    > ile projekt bedzie kosztowal. Ustala sie to na podstaawie dokumentu
    > wysylanago pzrez klienta do potencjalnych wykonawcow. gdzie sa
    > wyspecyfikowane wymagania dotyczace projektu. Firmy wyceniaja i klient
    > wybiera firme ktora chce. Niekoniecznie najtansza. Normalka.
    >
    > Teraz, jak sie podpisze kontrakt, to jest obopolne porozumienie ze a)
    > klient nie bedzei wymagal wiecej niz jest w kontrakcie, ani inaczej
    > niz jest w kontrakcie b) dostawca dostarczy produkt zgodznie ze
    > specyfikacja, w budzecie i w czasie.

    Mała złośliwość:
    Jakbym miał taką szklaną kulę, która z sensowną dokładnością poda mi
    budżet po określeniu wymagań, to bym z marszu użył jej do typowania
    Lotto.

    Poważnie:
    Na ile dokładne i wiążące, a na ile negocjowalne są wg Ciebie pierwotne
    ustalenia dotyczące budżetu i terminów? Co z sytuacjami, gdy trzeba
    wyceniać rzeczy, o których od początku wiadomo, że są bardzo
    nowatorskie (w domyśle - wycena na pewno nie będzie ścisła, bo zakres
    jest nieznany obu stronom)?

    Jest taki fajny obrazek budowania piramidy:
    - klasycznie kładziemy poziome warstwy od dołu: musimy mieć wcześniej
    określone, jak duża ta piramida będzie, bo trzeba wiedzieć, jak duża ma
    być pierwsza warstwa. Tu można całkiem nieźle oszacować, ile czasu to
    zajmie i jak drogie będzie
    - agile: mamy zamówienie na "super wypasiony grobowiec dla władcy",
    ale nie mamy terminu ("Faraon - oby żył wiecznie - jest w dobrym
    zdrowiu, ale kto to wie..."), w sumie to może nie będzie to piramida
    tylko wieża (jeszcze się pomysł nie wykluł). To zaczynamy od komory
    grobowej i "oklejamy" ją kolejnymi warstwami tak, żeby na koniec każdego
    miesiąca mieć gotową budowlę (co znaczy "gotowa" w tym miesiącu umawiamy
    się na początku miesiąca). Inaczej niż w klasycznym podejściu możemy
    tylko powiedzieć ile kosztuje nasz miesiąc pracy.


    [...]
    > I na pewno Pzredsiebiorstwo
    > Kanalizacyjne nie wydeleguje swojego pracownika zeby siedzial z owym
    > deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
    > Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

    Ale nie musi siedzieć. Byle tylko deweloper mógł w miarę często
    zaprezentować, czy to co robi, to jest to, o co faktycznie chodziło.
    Innymi słowy - twierdzę, że gdyby Przedsiębiorstwo Kanalizacyjne
    potrafiło wyprodukować specyfikację wystarczającą dla "code monkey",
    to powinno zająć się analizą systemów informatycznych, a nie
    kanalizacją.

    --
    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: