On Fri, 19 Jul 2013 14:35:58 +0200, Paweł Kierski<n...@p...net>
wrote:
> Teraz czas na rozbieżności - podaj przykłady projektów, w których
> wg Ciebie Agile na pewno się nie sprawdzi.

Software wymagający drobiazgowych certyfikacji, np. medyczny.

RW

do góry

On 19/07/2013 10:37, slawek wrote:
> Użytkownik "Sebastian Biały" napisał w wiadomości grup
> dyskusyjnych:ksan9m$aue$...@n...news.atman.pl...
>
>> Tym burdelem zarządza skutecznie system kontroli wersji powiązany z
>> jakąs bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na
>
> Przecież nie trzeba pisać kto jest autorem książki/filmu - jakaś baza
> danych wystarczy.
>
> Przecież nie ma sensu aby malarz podpisywał się na obrazie - wystarczy
> że mamy rachunek za malowidło.

Twórca do podpisu na dziele ma prawo z tego tytułu, że jest twórcą -
zarówno prawo moralne, jak i prawo z ustawy (o prawie autorskim). To nie
znaczy, że każdy się ma prawo podpisywać, czy że dobrze by było, żeby
każdy się podpisywał na wszystkim, co robi - np. murarz na każdej
kładzionej przez siebie cegle.

Oczywistym jest, że porada Wujka Boba dotyczyła kodu pisanego zespołowo,
w szczególności w kontekście oprogramowania komercyjnego, raczej
tworzonego przez jakieś przedsiębiorstwo. To, że programista dopisał w
kodzie if(c!=0) nie czyni z niego twórcy ani z tego kawałka kodu dzieła.
Liczą się tylko utylitarne aspekty takiego postępowania i o tym w tym
przypadku właśnie mówi Martin.

do góry

On 19/07/2013 15:27, A.L. wrote:
>
>>>> komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
>>>> przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
>
> Jak ktos zrobil zmiany w moim kodzie, to chce wiedziec KTO i DLACZEGO.
> KTO - rzeczywiscie moge sie dowiedziec z CVS siegajac 20 wersji
> wstecz. Ale DLACZEGO - to juz nie.

Natomiast komentarz "Added by Rick" mówi wszystko.

Poza tym pisałeś zdaje się, że korzystacie z SVN-a. Otóż SVN ma
możliwość dawania opisów przy committach. Celem istnienia tych podpisów
jest chyba właśnie opisanie dlaczego się wprowadza zmianę.

do góry

On 18/07/2013 14:55, Maciej Sobczak 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ą.

Przy zachowaniu odpowiednich praktyk zmiany nie muszą być drogie.

Przede wszystkim jednak stosunek wartości zmian to ich kosztu potrafi
być bardzo różny. W Agile dąży się do tego, żeby koszt zmiany dla
klienta był proporcjonalny do kosztu dla wykonawcy, dzięki czemu klient
może sobie wybierać te zmiany, które mu dają nawiększą wartość jak
najmniejszym kosztem.

W układach, gdzie każda zmiana oznacza negocjację kontraktu, wszystkie
zmiany mają spory narzut, ale przy małych, tanich zmianach narzut
administracyjny potrafi być gigantyczny, więc nie opłaca się ich robić.
Klient traci w ten sposób dużo na wartości otrzymywanego produktu.

do góry

Dnia pamiętnego Fri, 19 Jul 2013 20:53:27 +0100, Roman W wyjmując peta
oznajmił:

> On Fri, 19 Jul 2013 16:02:57 +0200, Sebastian
> Biały<h...@p...onet.pl> wrote:
>> Kod może być i na tysiące linijek o ile jego działanie opisane jest
>> testami. I który w przypadku watpliwości mogę przedebugować. Bo
> testy to
>> jedyna *pewna* dokumentacja projektu, szczególnie z wesołych
> metodyk
>> pisania byle jak.
>
> Test może byc typu
>
> x = 4.5;
> expected = 10.4;
> assertEquals (expected, f (x));
>
> I jaka ma wtedy wartość jako dokumentacja?

Przesadyzm, nikt tak skomplikowanego softu przecież nie pisze.
Do ogarnięcia jest

kupka = lewa;
expected = prawa;
assetEquals(expected, przelozDokument(kupka));

Po prostu nie ma sensu niepotrzebnie komplikować sobie życia,
jak to na jakiejś reklamie było "Simplifiers needed!". Jeżeli
jest jakiś test, kóry nic nie doukemntuje jak w takim przypadku,
należy zmienić podejście do programowania albo odejść z zespołu.

PS. Zombie łonts simpleeee! Eeeeeaaaeeeearrarraara!
--
Edek

do góry

Dnia pamiętnego Fri, 19 Jul 2013 07:00:36 -0700, Adam Klobukowski wyjmując
peta oznajmił:

> Agile to procesy nastawione na to że zmiany będą. Klasyczne metody to
> procesy nastawione na to że zmian nie będzie. Koszty zmian będą prawi
> zawsze, zmiany są praktycznie zawsze. Jak myślisz, jaki proces będzie
> oszczędniejszy, zoptymalizowany pod ewentualne zmiany, czy taki który
> zmian nie przewiduje?

Nie spotkałem się jeszcze z procesem, który *nie* uwzględnia możliwości
zmian. Spotkałem się jedynie z tym, że Agile jest jedynym, który
uwzględnia. Podobnie w kwestii testów, Agile też jest jedynym.

--
Edek

do góry

On 19/07/2013 14:54, A.L. wrote:
>
> Magia, magia, Panie Dzieju! W agile czas pracy programistow nic nie
> kosztuje, a zmiany wprowadzaja sie w zerowym czasie, Magia, no po
> prostu magia!!!

Czas pracy programistów kosztuje, ale wprowadzenie dowolnej dupereli,
która zajmuje programiście pół godziny, nie wymaga oprócz tego wielu dni
pracy prawników, sprzedawców, analityków, i reszty armii ludzi, którzy
są potrzebni do negocjowania kontraktu.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksc511$ie4$...@s...invalid...

>Nie da się wiedzieć. Można się umówić, że wykonawca dostarczy program w
>terminie według specyfikacji i że zapłacimy mu dwa miliony, to tylko idiota
>może wierzyć, że znaczy to, że "projekt będzie kosztował dwa miliony".
>Nawet zakładając, że wykonawca wywiąże się w 100% z umowy.
>
>Tzn. faktycznie projekt może kosztować dwa miliony, ale tylko pod
>warunkiem, że przyjmiemy możliwość (a nawet wysokie prawdopodobieństwo), że
>za te dwa miliony dostaniemy software, którego nie będziemy mogli używać.

Bob, który jest biznesmenem, umawia się z Fredem, programistą: Fred napisze
program który będzie kosztował dwa miliony [euro]. Umowa jest sporządzona na
piśmie i przy świadkach, Bob wpłaca zadatek wysokości 500 tysięcy euro, w
umowie podany jest czas realizacji jeden rok i takie tam. Zgodnie z umową, w
czasie jaki był określony, Bob dostaje od Freda software (czyli zamówiony
program), którego nie da się używać. Bob domaga się od Freda: zwrotu zadatku
w wysokości 500 tysięcy euro; zapłacenia 500 tysięcy euro za niewykonanie
(patrz przepisy o zadatku); zadośćuczynienia za straty jakie poniosła firma
Boba przez nierzetelne postępowanie Freda. Fred nie zgadza się oddać
pieniędzy, nawet jeżeli nie wydał z zadatku ani eurocenta nie ma skąd wziąć
drugich 500 tysięcy euro. Pomijając nieistotne szczegóły: sąd wydaje wyrok,
Fred ma 1 milion euro długów plus musi ponieść koszta sądowe. Jeżeli
komornik da radę ściągnąć ten milion euro z majątku firmy Freda (spółka
zoo), ew. z majątku Freda (spółka jawna i nie tylko), to Bob nawet nie
używając programu Freda zyska 500 tysięcy euro z "zainwestowanych" 500
tysięcy euro, czyli ma zysk równy 100%, znacznie wyżej niż jakakolwiek
lokata w twoim ulubionym banku.

I to tyle w temacie Fredów myślących że każdego klienta można zwodzić.

>> wymagania naruszaja "timing" projektu - projektu nei da sie wykonac na
>> czas, a za opoznienia moga byc kary umowne. Wiec co bedzie z tymi
>> karami?

Jak słusznie zauważył A.L. - co będzie z tymi karami?

>Ale też taki układ niekoniecznie jest korzystny dla zleceniodawcy. Przede
>wszystkim dlatego, że wykonawca ma w tym momencie wszelkie powody, żeby
>wydoić z niego ile się da - w kwestii terminów i w kwestii

Jeżeli ktoś z kogoś będzie "doił" - to raczej ten co już ma dwa miliony euro
do wydania (czyli zamawiający) - niż ten co tęskni aby te dwa miliony
zarobić (piszący program). Zamawiający "potrzebuje" programu. Fakt. Ale ma
wybór: firm tworzących software jest dużo. W razie czego można jeszcze przez
parę miesięcy prowadzić działalność używając poprzednich rozwiązań (czyli
starych programów.) Natomiast firma softwareowa musi walczyć z konkurencją
i - jeżeli nie będzie miała zleceń - to po prostu padnie. Nie stać jej na
półroczny przestój. Dlatego prawdopodobnie na te dwa miliony euro będzie
trzeba dość ciężko zapracować. W tym mieści się także znoszenie różnego
rodzaju dziwacznych wymagań (np. że zapis danych ma być na dyskietkach).

>powie zleceniodawcy że zrobi ją za dodatkowe 20 tysięcy i przesunięcia
>terminu o sześć tygodni.

Problemem będzie jeżeli zleceniodawca: a. nie będzie chciał wydać ani euro
więcej; b. przesunięcie terminu jest niemożliwe. Oczywiście, bardzo lubimy
zleceniodawców, którzy są chętni dawać nam ekstra czas i pieniądze... ale to
trochę dziecinne myśleć, że takich będziemy często spotykać. Ba! Ktoś kto ma
dwa miliony euro do wydania... prawdopodobnie jest bardzo twardym graczem w
biznesie, bo jakoś te dwa miliony euro zarobił.

>Ponieważ ilość poprawek nie może być znana z góry, odpowiedź na pytanie
>"jeśli się umówimy na dwa miliony i dwa lata, to za ile pieniędzy i za ile
>czau będziemy mieli system, którego używanie będzie miało sens" brzmi "nie
>wiadomo, może za dwa lata i dwa miliony, ale to raczej mało prawdopodobne;
>może to będą cztery lata i dziesięć milionów, a może takiego systemu nie
>dostaniemy nigdy, i nawet nie będziemy mieli kogo pozwać".

Jeżeli będzie takie jakieś gdybanie - to skończy się odpowiedzią - "to nie
będziemy realizować tego projektu". I co ciekawsze - ty sam możesz stać się
w firmie zbędny. No bo po co ktoś, kto nie potrafi załatwić prostej sprawy,
zwłaszcza że projekt nie jest realizowany.

>I dlatego klient nie będący idiotą może właśnie woleć Agile - żeby uniknąć
>takiej sytuacji. [płacenia 500 000 USD za drobną zmianę w umowie]

Nie wiem kto jest idiotą: czy klient, którego stać na zapłacenie 500 000 USD
za zmianę w projekcie (czyli spodziewający się, że ta zmiana przyniesie zysk
przekraczający 500 000 USD)...

... czy też może klient, który nie wie nawet czego chce i pozwala aby
manipulował nim zleceniobiorca.

do góry

Użytkownik "Roman W" napisał w wiadomości grup
dyskusyjnych:a...@n...plus.
net...

>Bzdura. Nawet ze szwagrem dom budujesz według projektu. Nie zmienisz w
>połowie budowy liczby pieter, czy rozmieszczenia scian nośnych.

Aby była jasność: nie jestem za agile; jestem przeciw agile.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksc9uj$kjh$...@s...invalid...

>Czas pracy programistów kosztuje, ale wprowadzenie dowolnej dupereli, która
>zajmuje programiście pół godziny, nie wymaga oprócz tego wielu dni pracy
>prawników, sprzedawców, analityków, i reszty armii ludzi, którzy są
>potrzebni do negocjowania kontraktu.

Co konkretnie można zrobić w pół godziny?

do góry