Użytkownik "Maciej Sobczak" napisał w wiadomości grup
dyskusyjnych:e82374b3-7d61-4319-ae78-d0fc65d320d2@go
oglegroups.com...

>jakaś kulturowa ściana, która to utrudnia, i to po obu stronach: zarówno po
>stronie wykonawców (za dużo pizzy) jak i po stronie agencji
>certyfikacyjnych (ci z kolei nie chcą chodzić na pizzę).
>Myślę, że wypracowanie dobrego nowego rozwiązania w tej dziedzinie zajmie
>jeszcze jedną albo dwie generacje metod. Tzn. jeszcze nie teraz.

Konstruktywna propozycja - spotykać się przy homarach... z członkami agencji
certyfikacyjnej.

do góry

On Monday, 22 July 2013 10:15:55 UTC+1, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksh8j8$6hm$...@s...invalid...
>
> >Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
> >systemu CRM, księgowości czy payroll?
>
> A nie można używać do księgowości etc.? Jakiś zakaz jest czy co?

W sensie żeby powiedzieć księgowym "Zamiast zamawiać wam system za miliony
dolarów, postanowiliśmy użyć darmowego Linuxa. Macie tutaj komputer z
Linuxem i prowadźcie na nim księgowość. Jakby wam czegoś brakowało, to piszcie
na listę linux-kernel, na pewno znajdzie się ktoś, kto wam doda co trzeba za
friko"?

> >kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
> >najtrudniej było z niej skorzystać.
>
> Ok, ale firma zamawiająca, sprzedająca "szlauchy i kalosze" (nie ma w niej
> dość "mocy przerobowej" do zrobienia programu, ale szef przypadkiem ma
> ukończone studia z informatyki, z zarządzania i z psychologii) może nie dać
> się łatwo wykiwać. I szybko zorientować, że ktoś sabotuje współpracę
> (utrudnia korzystanie).

Myślę, że takie przypadki wykonawca może wpisac w ryzyko.

Co natomiast proponujesz firmom potrzebującym zamówic oprogramowanie, gdzie
przypadkiem szef nie ma ukończonych studiów z informatyki, zarządzania i
psychologii?

> >Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które by
> >można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.
>
> Nie znasz? To znaczy że nie ma sensu zamawiać u ciebie programów ;)

Nie ma sensu przede wszystkim dlatego, że nie świadczę takich usług. Skoro
ty jednak wiesz o takich standardach, to może byś dla paddierżania razgawora
rzucił jakimś numerkiem ISO czy coś?

> >Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
> >wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten, co
> >je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego
>
> W tym właśnie miejscu przypomnijmy sobie "FAKT A" (czyli: że masz bogate
> doświadczenie i pracowałeś w wielu firmach).

Gwoli uwagi, fakt A brzmi jednak tak, że mam _wiele lat_ doświadczenia i
pracowałem w _kilku_ dużych firmach. "Wiele" jest oczywiście pojęciem
względnym, jest to wiele lat w stosunku do całości trwania mojej kariery
zawodowej i według mojego subiektywnego odczucia - oczywiście istnieją ludzie,
którzy pracują w branży znacznie dłużej i dla nich moje "wiele" może być
całkiem niewiele.

> Jeżeli Agile i ogólnie współpraca układają się tak dobrze - to nigdy nie
> musiałbyś "rozczytywać kodu" - bo po prostu tym kodem zajmowałby się ten, co
> pierwotnie go napisał.

Rozpatrujemy sytuację, kiedy wykonawca nie stosuje Agile, bo zamawiający
rozpatruje wyłącznie kontrakty fixed price fixed scope jako rzekomo najlepiej
zabezpieczające jego interesy. Całe rozważania o przejęciu kodu biorą się,
przypominam, z mojego pytania "a co jeśli po wykonaniu kontraktu fixed price
fixed scope okaże się, że chociaż program jest zgodny z umową, to UAT wykaże,
że przycisk jest źle umieszczony, a wykonawca zażąda ćwierć miliona za
przesunięcie go". Sprzedaż źródeł z programem nie załatwia problemu.

> To co robiłeś wynikało właśnie z tego, że - podobnie jak nieuchronna jest
> "zmiana" - podobnie nieuchronne jest, że kiedyś "ktoś inny będzie musiał
> poprawiać nasz program".

Jest kolosalna różnica między tymi sytuacjami.

Jeśli tym kims jest pracownik firmy, to taka sytuacja zdarza się bardzo rzadko
(przy jakiejkolwiek sensownej organizacji pracy). Problem dotyczy modułów,
które są bardzo rzadko ruszane, bo jeśli coś jest często ruszane, to
prawdopodobnie jest w zespole kilku developerów, którzy mają jakieś
doświadczenie z kodem danego modułu albo przynajmniej z modułami
współpracującymi z nim i można się ich spytać.

Dalej - nawet jeśli nei ma developerów, którzy by cokolwiek o tym kodzie
wiedzieli, to jest spora szansa, że przynajmniej będzie kilka osób z wiedzą o
funkcjonalności czy użytkownaiu danego modułu (analitycy, testerzy).

Dalej - nawet jeśli na module jako takim nikt się nie zna, to wielu członków
zespołu rozumie architekturę systemu, w którą ten moduł się wpasowuje, co
wybitnie może ułatwić zrozumienie kodu źródłowego i np. wnioskowanie o
możliwych skutkach ubocznych wprowadzanych zmian, skutecznych sposobach
testowania itd.

Dalej - jak dobrze pójdzie, moduł kodowany jest przy pomocy tych samych
coding standards, których dany programista uzywa na co dzień, co również
sprzyja rozczytaniu.

Jeśli mówimy o jakimś jednym egzotycznym module, to również brak sukcesu w
rozczytaniu nie powoduje straszliwych skutków - zawsze można zastąpić go nowym
modułem relizującym akurat potrzebny klientowi podzbiór funkcjonalności, ze
starego skanibalizować to, co się da odczytać a resztę oznaczyć jako
"deprecated".

Oczywiście jeśli konkretnie wykonawca stosuje Agile, to dostaje kilka
dodatkowych narzędzi zmniejszających prawdopodobieństwo takiego zdarzenia lub
ograncizających jego skutki - shared code ownership, programowanie parami,
acceptance tests, unit tests, simpel design, clean code, no bugs.

To jest zupełnie inna sytuacja, niż rzuceniem w nowego potencjalnego wykonawcę
milionem linijek kodu źródłowego, którego tamten wcześniej nie widział na oczy
i powiedzeniem "tutaj mam taki programik, chciałbym przesunąć ten o przycisk
trochę w lewo, ile czasu by wam to zajęło?"

Dodatkowo różnica jest taka, że wykonawca ma motywację do tego, żeby kod
pisany wewnętrznie był zrozumiały dla jego własnych pracowników, natomiast
jeśli oddaje kod klientowi, to w jego interesie jest to, żeby kod był jak
najtrudniejszy do przeczytania przez kogokolwiek innego.

> >kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny z
> >napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja
>
> Ba! Niektórzy autorzy nie żyją, inni są niedostępni. Ale wiesz co?
> Wynaleziono pismo, druk i nawet coś takiego jak dokumentacja, rysunek
> techniczny, UML i takie tam.

Które niekoniecznie będą dostarczone z kodem źródłowym. A jeśli będą bo umowa
tego będzie wymagać, to w interesie wykonawcy jest dostarczyć je w takiej
postaci, żeby były jak najmniej użyteczne.

> >Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale też
> >zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają, albo
> >proponują wyższe ceny.
>
> Dokładnie tak, jak w przypadku np. samochodów: można kupić tanie auto, bez
> gwarancji, do którego nie ma części zamiennych ani serwisu - albo nieco
> droższe, w którym jest serwis, są części zamienne i gwarancja, a do tego tak
> proste w konstrukcji że nie wymaga np. specjalnych narzędzi do naprawiania.

Jeśli chcesz mieć analogię do samochodu, to raczej sensowna byłaby taka:
kupując nowoczesny samochód wielu rodzajów napraw nie będziesz w stanie
wykonać ani samodzielnie, ani nie wykona ich nawet mechanik nie będący ASO
producenta, bo potrzeba specjalistycznych narzędzi. Żądanie kodu źródłowego to
tak, jakbys poszedł do przedstawiciela powiedzmy Hondy i powiedział, że chcesz
kupić nowy model Civic, ale żeby się zabezpieczyć na wypadek gdyby producent
przestał naprawiać, zbankrutował, albo podniósł znacząco ceny seriwsu, to
chcesz ten samochód ze wszystkimi schematami, projektem mechanicznym,
elektoronicznym, kodem żródłowym oprogramowania itd. wszystkim co potrzebne,
żeby sobie samemu takie narzędzia zbudować albo zlecić to komuś. I ile coś
takiego by kosztowało ekstra?

> >Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?
>
> A jest jakiś problem, aby to wpisać? Oczywiście konkretne sformułowanie może
> być nieco bardziej wyrafinowane i konsultowane z prawnikami.

A jak konsultowany prawnik powie "z całym szacunkiem, ale pan to chyba na
głowę upadł"? Ja prawnikiem nie jestem, ale jestem sobie w stanie wyobrazić
przynajmniej kilka powodów, dla których wpisywanie takich rzeczy mogłoby być
czymś, czego zarówno zleceniodawca, jak i wykonawca woleliby uniknąć.

Dla zelceniodawcy ryzyko jest przede wszystkim takie, że w razie czego sąd
uzna taki zapis za nieegzekwowalny. Dla wykonawcy problem może się pojawić w
momencie, kiedy zleceniodawca stwierdzi, że woli nie płacić za program i
zacznie szukać dziury w umowie, która mu na to pozwoli. Łatwo mu wtedy będzie
powiedzieć "nasz fachowiec nie rozumie tego kodu (lub: trudno mu zrozumieć ten
kod), ergo nie jest łatwy do zrozumienia, ergo niezgodny z umową, ergo nie
zapłacimy." I weź się potem w jednym czy w drugim przypadku ciągaj po sądach i
udowadniaj że coś jest czytelne albo nieczytelne.

> Coś takiego w umowie powinno skutecznie odpędzić partaczy przy np.
> przetargu.

Raczej odpoędzi wszystkich trzech, którzy nie uciekli w momencie zażądania
kodu źródłowego.

> >Przecież gdyby zamawiający miał na etacie programistów potrafiących napisać
> >ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.
>
> Może ich ma, ale oni mają co innego do roboty? A może ich ma, ale zbyt mało
> ich jest?

To będą wyjątkowe przypadki - większość firm nie ma działu rozwoju
oprogramowania. Jeśli ma, ale ci ludzie mają co innego do roboty, to też mają
co innego do roboty niz pisanie i sprawdzanie szczegółowej specyfikacji
liczącej setki stron. A jeśli nawet to zrobią, to fakt, że na codzień zajmują
się czym innym znaczy, ze tak czy inaczej ich szanse na wyłapanie wszystkich
błędów przegapionych przez resztę ludzi zajmujących się danym kontraktem nie
są takie duże.

> Wyobraź sobie - firma zamawiająca ma dział IT z 3-4 dobrymi fachowcami.

"Dział IT z 3-4 dobrymi fachowcami" zazwyczaj oznacza kolesi od zarządzania
Microsoft Exchange, konfigurowania firewalli i zmieniania toneru w drukarkach,
a nie ludzi zamujących się inżynierią oprogramowania.

Z drugiej strony - spora część mojego zawodowego doświadczenia związana jest z
tworzeniem oprogramowania dla banków inwestycyjnych lub używanego przez banki
inwestycyjne. Takie banki mają działy IT liczące setki osób, zajmujące się
między innymi produkcją bardzo zaawansowanego oprogramowania na własne
potrzeby i zatrudniające naprawdę bystrych kolesi do wytwarzania tego softu.

Myślisz, że takie banki, kiedy zamawiają oprogramowanie u zewnętrznych
dostawców, nie mają problemów z błędnymi lub nieprecyzyjnymi specyfikacjami?

> Program, aby był na czas, musi pisać 15-20 ludzi. Więc firma zewnętrzna. Ale
> tych 3-4 fachowców może dość łatwo zorientować się, czy wszystko jest
> robione jak trzeba - czy też wykonawca partoli.

Nie może, przynajmniej dopóki umowa nie zostanie podpisana i wykonawca nie
zacznie faktycznie czegoś robić.

> >Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
> >przesłanek. W rzeczywistości mogą być dużo wyższe.
>
> Teraz wiem, dlaczego ja nie zamówiłbym u ciebie programu - raz piszesz
> konkretne liczby (250 000, 100 000 etc.), potem "w rzeczywistości mogą być
> dużo wyższe".

Panie prezesie, koro pan nie rozumie czym jest ryzyko i co to jest wartośc
oczekiwana, to ja bym nawet nie chciał, żeby pańska firma zamawiała u mnie
oprogramowanie, bo co z tego, że obieca mi w umowie nawet nie dwa, ale i pięc
milionów, skoro jak zgłoszę się po odbiór, to pańska firma zapewne będzie już
dawno w trakcie postępowania upadłościowego i tylę z tych milionów zobaczę.

> >Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
> >oparta była na szacowanych zyskach czy oszczędnościach z użycia tego
>
> I dlatego te oszacowania muszą być rzetelne, a nie wyssaną z palca
> konfabulacją.

Rzetelne? Powiedzmy, ze w fazie UAT użytkownicy zgłaszają problem, że UI
wprowadza ich w błąd i czasem wywołują nie tę operację, co chcieli. Wykonanie
błędnej akcji naraża klienta na stratę, ale jak często właściwie użytkownicy
będą popełniać ten błąd i jakie będą wielkości straty za każdym razem zależy
od wielu czynników. Żeby to rzetelnie oszacować musiałbyś zrobić badania
behawioralne na reprezentatywnych grupach, eksperymenty z grupą kontrolną,
musiałbyś zatrudnić dobrych specjalistów od psychologii żeby ci zaprojektowali
te eksperymenty i powiedzieli jakie czynniki musisz wziąć pod uwagę.
Specjaliści mogą ci powiedzieć, że użytkownicy mogą się inaczej zachowywać jeśli
wiedzą, że pracują w środowisku testowym, a inaczej jeśli mają świadomość
pracy w prawdziwym środowisku produkcyjnym. Mogą dodatkowo powiedzieć, że
zachowania mogą się zwiększać w czasie, np. na początku będą bardziej ostrożni
a potem wejdą w rutynę, lub odwrotnie - że w miarę używania programu będą
popełniać coraz mniej pomyłek. Jedno i drugie wraz z potrzebnymi do rzetelnego
oszacowania danymi liczbowymi trzeba zmierzyć eksperymentalnie. Skoro
potrzebne jest badanie zachowań użytkowników w warunkach produkcyjnych to i w
takich warunkach trzeba ich badać, i to w dość szerokim przekroju środowisk,
żeby zapewnić reprezentatywność danych. Oczywiście tobie i twoim pracownikom
raczej mało kto da prowadzić badania we własnym środowisku produkcyjnym, więc
będziesz musiał zatrudnić szacowną i budzącą zaufanie instytucję, np. jeden z
dużych uniwersytetów albo jakiś Gallup Institute. Taka instytucja też coś
weźmie za firmowanie tych badań, im bardziej szacowna i godna zaufania, tym
weźmie więcej. Na podstawie zebranych w ten sposób danych zatrudnieni przez
ciebie wybitni naukowcy zrobią analizę i wyciągną wnioski. Żeby jednak było
żetelnie, musisz wynająć inną pulę wybitnych naukowców i poprosić ich o
zrobienie peer review. Te recenzje wykażą ewentualne braki metodologiczne,
alternatywne interpretacje i hipotezy, problemy w argumentacji. Następnie
zatrudniasz kolejną pulę naukowców, których prosisz o zajęcie stanowiska, a
następnie dopuszczasz do debaty między wszystki grupami, z której to debaty
wyłaniają się kolejne badania, które trzeba wykonać w celu potwierdzenia lub
eliminacji poszczególnych hipotez. Cały proces powtarzasz tak długo, aż
zatrudnieni naukowcy osiągną consensus.

Jak widzisz rzetelne oszacowanie może być całkiem kosztowne. Czy wydasz 50
milionów dolarów, żeby rzetelnie oszacować straty wynikające ze źle
umieszczonego przycisku w programie za dwa miliony, jeśli przesumięcie tego
przycisku kosztuje 250 tysięcy dolarów? Czy będziesz czekał 10 lat?

Co więcej, nie jest nawet tak, że możesz od razu wiedzieć, albo nawet
rzetelnie oszacować koszty tych badań. Przecież koszty będą zależały od tego,
co powiedzą wybitni specjaliści, czego sam nie będąc wybitnym specjalistą nie
jesteś w stanie przewidzieć nawet w przybliżeniu, oraz tego, jakie będą wyniki
badań, które dlatego trzeba przeprowadzić, że właśnie tego nie wiadomo.

Pytanie powstaje więc: w jaki sposób rzetelnie oszacujesz koszty rzetelnego
szacowania?

do góry

On Monday, 22 July 2013 10:15:55 UTC+1, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksh8j8$6hm$...@s...invalid...
>
> >E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś działają,
> >często z większym powodzeniem niż poprzednio.
>
> W tej samej branży? Podaj przykłady. Ja znam jeden, ale facet najpierw, już
> po bankructwie, spłacił wszystkich swoich wierzycieli.

Proszę bardzo, będą przykłady, ale radzę złap się czegoś, bo nazwiska możesz
skojarzyć i może ci się wywrócić światopogląd:
Walt Disney
Henry Ford

do góry

On Monday, 22 July 2013 16:30:54 UTC+2, 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ą.

Kulturowo nie ma przeszkód. Jeżeli do oprogramowania potrzebna jest certyfikacja, to
zamawiający to raczej wie i umieści w zamówieniu. Wykonawca umieszcza to w definition
of done i po sprawie.

> 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").

Powstaną, jeśli będą w definition of done.

AdamK

do góry

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ć.

do góry

On Monday, 22 July 2013 09:15:50 UTC+1, Paweł Kierski wrote:
> W dniu 2013-07-19 20:37, slawek pisze:
>
> > 1. Zamówienia publiczne, które musi (bo takie prawo) rozstrzygnąć przetarg.
>
>
> Cóż - z prawem i praktyką, które traktują stworzenie, utrzymywanie przez
> jakiś czas i szkolenia pracowników (przekazanie systemu) każą traktować
> jak produkt, a nie usługę świadczoną przez pewien czas, nie da się
> zawalczyć. Co wg mnie świadczy raczej o ułomności praktyki i prawa.

Przepraszam, nie znam się za bardzo na zamówieniach publicznych, ale jeśli
powiedzmy gmina chce zatrudnić firmę do sprzątania pomieszczeń rady, to nie
może rozpisać przetargu gdzie firma sprzątająca będzie dostawać określoną
kwotę za okres rozliczeniowy na czas utrzymywania pomieszczeń w czystości,
tylko musi być przetarg na każde sprzątnięcie oddzielnie, ze szczegółowym
spisem wszystkich papierków do podniesienia i plam na podłodze do zmycia w
załączniku?

> Ubezpieczenie od ryzyka - przyznam, że się nie spotkałem. Ale na ile
> mogę się domyślać, to Agile raczej pomoże - w kolejnych iteracjach
> widać, jak poziom ryzyka się stabilizuje (dokładniejsze, oparte na
> faktach szacowanie terminu, możliwa kontrola jakości w trakcie
> wykonania).

Także - dorzucę - kontrola ryzyka kontraktowego. Jeśli np. tempo prac czy
problemy metytoryczne z implementacją wymagań są większe niż zamawiający
przewidział, to może na wczesnym etapie (np. po wóch-trzech iteracjach)
odstąpić od projektu i zapłacić tylko za te dwie-trzy iteracje lub - w
zależności od umowy - w ogóle nic.


> > 4. Projekty tworzone społecznościowo na zasadzie totalnego wolontariatu.
>
> Tu Agile może być niepotrzebny, bo cel projektu jest wypracowywany
> wspólnie. I nie koniecznie celem tym jest produkt - czasem renoma
> zespołu lub poszczególnych deweloperów. To już kompletnie inna bajka.
>
> Ale jeśli jest jakiś cel produktowy i osoba/osoby, które chcą popychać
> produkt w kierunku realizacji tego celu, to czemu nie skanalizować
> wysiłków korzystając z elementów Agile?

A ja bym akurat się zgodził że do tego metody Agile nadają się słabo. W Agile
jest założenie, że pracuje się dla klienta, który może być prawdziwy lub
wirtualny, ale jest zewnętrzny wobez zespołu developerskiego. Celem zespołu
developerskiego jest wyłacznie zaspokojenie potrzeb i maksymalizacja wartości
klienta, a o tym co dokładnie maksymalizuje dowiadują się z konkretnego
źródła - mogą sugerować, ale nie mogą decydować. Jeśli developerzy mają inne
cele, np. chcą robić cool rzeczy, które przyniosą im "renomę", albo sami są
użytkownikami produkowanego softu lub reprezentują użytkowników i osobiście
zależy im, żeby produkt miał określone ficzery albo działał w określony
sposób, to cały proces Agile się sypie.

I dotyczy to nie tylko wyidelizowanego obrazu open source/free software gdzie
hobbyści czy pracownicy naukowi dłubią sobie w rzeczach, które ich interesują,
ale też rozwoju takiego oprogramowania w środowisku korporacyjnym, gdzie np.
do linuksowego kernela kontrybuują inżynierowie z Google, którym zależy na
implementowaniu tego, co jest potrrzebne Google, inżynierowie IBM, którzy chcą
implementować to, co jest potrzebne IBM itd.

do góry

Szarym od mżawki świtem Mon, 22 Jul 2013 08:15:33 -0700, Adam Klobukowski
wyrzucił pustą ćwiartkę i oznajmił:

> On Monday, 22 July 2013 16:30:54 UTC+2, 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ą.
>
> Kulturowo nie ma przeszkód. Jeżeli do oprogramowania potrzebna jest certyfikacja,
to zamawiający to raczej wie i umieści w zamówieniu. Wykonawca umieszcza to w
definition of done i po sprawie.
>
>> 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").
>
> Powstaną, jeśli będą w definition of done.

Tylko wytłumacz to zapalonym konsumentom pizzy. Jaki Technical Product
Owner, co, może jeszcze Certification Produkt Owner i Pizza Master i
Dokumentation Produkt Owner?

Naprawdę, nie zauważasz problemu kulturowego.

--
Edek

do góry

Szarym od mżawki świtem Mon, 22 Jul 2013 16:49:09 +0200, slawek wyrzucił
pustą ćwiartkę i oznajmił:

> Użytkownik "Maciej Sobczak" napisał w wiadomości grup
> dyskusyjnych:e82374b3-7d61-4319-ae78-d0fc65d320d2@go
oglegroups.com...
>
>>jakaś kulturowa ściana, która to utrudnia, i to po obu stronach: zarówno po
>>stronie wykonawców (za dużo pizzy) jak i po stronie agencji
>>certyfikacyjnych (ci z kolei nie chcą chodzić na pizzę).
>>Myślę, że wypracowanie dobrego nowego rozwiązania w tej dziedzinie zajmie
>>jeszcze jedną albo dwie generacje metod. Tzn. jeszcze nie teraz.
>
> Konstruktywna propozycja - spotykać się przy homarach... z członkami agencji
> certyfikacyjnej.

Wtedy, po trzech ...napojach z homara dadzą się przekonać i dać słowo,
że zaakceptują Documentation By Example czy dowolny inny nowoczesny
wynalazek i wystawią Certyfikat ze stemplem zwinnego kraba.

--
Edek

do góry

On Friday, 19 July 2013 19:37:10 UTC+1, slawek wrote:
> Użytkownik "Paweł Kierski" napisał w wiadomości grup
> dyskusyjnych:ksbbre$7n7$...@s...invalid...
>
>
>
> >Teraz czas na rozbieżności - podaj przykłady projektów, w których
> >wg Ciebie Agile na pewno się nie sprawdzi.
>
> 2. Programy robione ad hoc w jednoosobowym "zespole". Dotyczy także zespołu
> dwuosobowego.

No jednak nie. Nie da się bezpośrednio w "czystej" postaci stosować Scrum czy
XP, ale Agile to nie Scrum i XP, tylko pewne ogólne podejście i powiedzmy
kultura stosowania pewnych technik. Owszem, w Scrum i XP są rzeczy, których
zrobić się w pojedynkę czy nawet we dwóch się nie da, lub też robienie ich nie
ma sensu.

Ale w ogóle sensowne stosowanie Agile zaczyna się od tego, że to nie jest
magiczny rytuał na zasadzie zatańczysz w określony sposób i spadnie ci deszcz,
tylko że te wszystkie praktyki mają swój cel, który trzeba rozumieć. Jeśli to
rozumiesz, to wiesz, że pracując jedno- lub dwuosobowo ten sam cel możesz
uzyskać bez tego, nie musisz np. spotkać się z samym sobą żeby skoordynować z
samym sobą działania, nie musisz ze sobą nic uzgadniać, przekazywać samemu
sobie wiedzy itd. Jeśli te same cele osiągasz bez tych praktyk, to nadal
możesz sam działać w ramach procesu, który jest Agile.

Jedyne ograniczenie jest takie, że nie możesz tego programu robić dla siebie.
Jeśli robisz dla siebie, to nadal możesz (z sensem) stosować pewne praktyki
typowe dla Agile (TDD na ten przykład), ale całościowo o zastosowaniu procesu
z kategorii Agile raczej trudno mówić.

do góry

Szarym od mżawki świtem Mon, 22 Jul 2013 11:15:55 +0200, slawek wyrzucił
pustą ćwiartkę i oznajmił:

> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksh8j8$6hm$...@s...invalid...
>
>>Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
>>systemu CRM, księgowości czy payroll?
>
> A nie można używać do księgowości etc.? Jakiś zakaz jest czy co?

Niektórzy nie wiedzą, że systemy na Linuksie są droższe niż na Windows:

http://en.wikipedia.org/wiki/London_Stock_Exchange#T
echnology

Niektórzy jak dostają system warty tyle co kilka chińskich trampek
ze zniżką (LOL #1) i trzema subskrypcjami (LOL #2), a oryginalny
kosztuje tyle że hoho (LOL #3), to darmowy linuks jest gorszy.
Wystarczy zajrzeć do cennika systemów Enterprise, żeby zrozumieć
na czym polega błąd - w systemach serwerowych Windowsów sprzedaje
się dużo i tanio, linuksy do poważniejszych zadań.

Akurat tylko nie trafiony jest przykład CRMa - to tylko szczebelek
wyżej niż klepanie stronek w PHPie, cenowo nawet mniej. Podobnie
księgowość, od strony technicznej żadna filozofia.

--
Edek

do góry