eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingpl. usenet o agile › Re: pl. usenet o agile
  • Data: 2013-07-22 17:54:36
    Temat: Re: pl. usenet o agile
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On Monday, 22 July 2013 15:30:54 UTC+1, Maciej Sobczak wrote:
    > > > Software wymagający drobiazgowych certyfikacji, np. medyczny.
    >
    >
    >
    > > Nawet jeśli certyfikacja przewidziana jest tylko dla "kompletnego"
    > > produktu, to nic nie stoi na przeszkodzie, żeby dojście do tego stadium
    > > było prowadzone metodami zwinnymi.
    >
    >
    >
    > Technicznie może i nie ma przeszkód, ale kulturowo będą. Agile kojarzy
    > się z nierobieniem niepotrzebnych rzeczy a tymczasem certyfikacja
    > wykonywana przez podmiot zewnętrzny (przez jakąś Agencję Sprawdzania
    > Projektów i Produktów, odpowiednio dla branży) robiona jest na
    > podstawie *artefaktów*, które w potocznie rozumianym agile po prostu
    > nie powstają.

    ...jeśli są niepotrzebne właśnie. W tym przypadku są potrzebne, więc i
    powstają.

    > Problem jest tym bardziej widoczny, im bardziej eksponuje się wartość
    > nieformalnych rozmów i spotkań - jeżeli agile zachęca do tego, żeby
    > Product Owner chodził ze Scrum Masterem (albo w ogóle z całym zespołem)
    > na przysłowiową pizzę w nadziei na sprawniejszą wymianę myśli, to
    > naturalne jest, że w takim pół-formalnym procesie pewne tradycyjne
    > artefakty nie powstaną. Tym bardziej, jeśli przedstawia się to jako
    > zaletę ("my tu robimy programy, które coś robią a nie dokumentację,
    > która nic nie robi").

    Bez jaj. Akurat zwykle jakaś forma dokumentacji jest wymagana i istnieją w
    ramach Agile różne rozwiązania tego problemu. Zasadniczo możesz zrobić dwie
    rzeczy: albo mieć osobny zespół od pisania dokumentacji dla odbiorcy, który
    niekoniecznie musi pracować w metodologii Agile (bo i w końcu nie tworzy
    oprogramowania), albo masz technical writerów w zespole developerskim - jedno
    i drugie rozwiązanie ma wady i zalety, właściwa implementacja sprowadza się do
    odpowiedzi na pytanie "skąd piszący dokumentację wie, co ma napisać?"

    Z drugiej strony jeśli chodzi np. o specyfikację funkcjonalną produktu, to
    agile-owe metodologie BDD i Specification By Example potrafią dać bardziej
    szczegółowy i formalny dokument specyfikacyjny niż tradycyjne metody.

    > No i na koniec taki zespół zanosi do Agencji Sprawdzania Projektów i
    > Produktów swoje dzieło a tam pani w recepcji mówi: proszę zostawić produkt
    > *wraz z pełną dokumentacją* na półce, odezwiemy się.
    >
    > A tu dupa - produkt udało się jakoś ulepić, ale dokumentacja to była nasza
    > rozmowa w pizzerni. I tyle z certyfikacji.

    I co - klient zamiawiał produkt do certyfikacji, a nie wiedział, że trzeba
    dostarczyć dokumentację? Przecież takie rzeczy są zwykle określone, pani w
    recepcji nie może powiedzieć np. "ale dokumentacja musi być wierszem, do rymu,
    i żeby wszystkie słowa były na literę C".

    > Myślę, że wypracowanie dobrego nowego rozwiązania w tej dziedzinie zajmie
    > jeszcze jedną albo dwie generacje metod. Tzn. jeszcze nie teraz.

    No właśnie rozwiązania raczej już istnieją, trzeba tylko umieć je zastosować.

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: