On May 18, 6:06 pm, Michal Kleczek <k...@g...com> wrote:
> Michoo wrote:
> > Ale nadaje się do przetestowania usability już w momencie utworzenia
> > GUI. Potem jako kolejne przyrosty będzie można zrobić obsługę kolejnych
> > pitów.
>
> Ale sie nie nadaje do uzycia produkcyjnego (co jest postulowane przez
> "agile").

W którym miejscu?

> Do testowania "usability" nie potrzeba zadnego "agile" - wystarczy wyklikac
> _prototyp_ w jakims VB czy innym narzedziu RAD nie przejmujac sie tym, co
> jest "pod spodem" bo prototyp z zalozenia idzie do kosza. Tak jest po prostu
> taniej, bo mozna to zrobic w pare godzin.
> Oczywiscie rownolegle mozna robic to co "pod spodem" - ale do tego jest
> potrzebny (hint) projekt, ktory wyspecyfikuje, ze w ogole dzielimy
> oprogramowanie na UI i "pod spodem" oraz powie nam co to wlasciwie znaczy
> "podzielic" i jak ten podzial przebiega.

Nie jest potrzebny. Można mieć najpierw GUI w VB, potem przerobić
program w VB tak, żeby komunikował się z komponentem COM w DLL-ce
która realizuje jakąś szczątkową funkcjonalność, potem przerobić DLL-
kę na pełnosprawny server obliczeń, a równolegle dorobić obok COM
interfejs SOAP i interfejs webowy.

do góry

W dniu 2011-05-19 12:25, Stachu 'Dozzie' K. pisze:
[...]
>>>> Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
>>>> rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
>>>> projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
>>>> takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
>>>> potem regularni i dość często kolejne release'y, np. co miesiąc albo co
>>>> dwa miesiące.
>>>
>>> To co opisujesz, to bardziej mi pasuje do starej definicji
>>> prototypowania z ominięciem najważniejszej części, że prototypu nie
>>> wdraża się produkcyjnie.
>>
>> Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
>> kolejne wersje.
>
> Ale co miesiąc? O_o
> Toż samo testowanie czy wszystko działa w środowisku zbliżonym do
> produkcji trwa tyle czasu (patrzę z perspektywy admina, więc osoby,
> która to wdraża u klienta na produkcji).

Iteracje mogą być dłuższe, a nie każda musi się kończyć testowaniem od
A do Z, a np. tylko nowych ficzerów. Tu pewnie zwolennicy Kanbana
świetnie wykazaliby jego wyższość na Scrumem. W skrócie - Scrum zakłada
zamknięcie 1 lub więcej ficzerów w iteracji, co wiąże się z potencjalnym
czekaniem na wyniki testów. W Kanbanie pracuje się "wielowątkowo" nad
większą liczbą ficzerów, ale tak, żeby w kolejnej fazie nie było więcej
niż określona, mała liczba ficzerów.

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

do góry

W dniu 2011-05-19 12:02, Andrzej Jarzabek pisze:

> Może i tak, ale ostatecznie produkt idzie do produkcji i zarabia dla
> firmy pieniądze, so he must be doing something right.

Zakładając ze go po drodze nie położy. Ale mniejsza z tym.

> Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
> też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).

Nie chodzi o poleganie na automatycznie generowanej dokumentacji, ale o
wspomaganie się automatami w procesie jej powstawania.

> Byłaby potrzebna, gdyby była kompletna i aktualna. W takiej postaci
> jak była, to pożytki korzystania z niej były równoważone przez szkody
> - sumaryczna wartość zerowa, a koszt tworzenia i utrzymywania jednak
> niezerowy.

To już jest zadaniem prowadzącego projekt wymóc aby dokumentacja była
kompletna i aktualna.

> Ale jednak większość implementacji będzie pamiętał,

A niby czemu? Jak czegoś nie dotykasz przez rok, to naturalne jest że
zapomnisz szczegóły.

> bo regularnie
> wchodzi w nią debuggerem, refaktoryzuje itd. Pytanie, czy overhead

Po kiego grzyba? Moduł zakończony i się go nie tyka bez potrzeby, a już
na pewno nie debuguje się go przy okazji innych zadań tylko
korzystających z niego.

> związany z utrzymywaniem aktualnej i szczegółowej dokumentacji przez
> cały czas równoważy to, że raz na rok komuś ta dokumentacja się przyda
> żeby trochę szybciej zrozumieć jakiś rzadko używany kawałek kodu. I
> jak na tę odpowiedź wpływa stosowanie np. rygorystycznych coding
> standards, które zabraniają pisania kodu tak, żeby trudno go było
> czytać.

Tyko, że czasami żeby sprawdzić co będzie wynikiem danej funkcji trzeba
prześledzić tonę kodu, a w dokumentacji jest to opisane łącznie z wyjątkami.
To nie jest tak, że dokumentacja się nie przydaje bo jej nigdy nie
potrzebowałeś.

> Dobrze, w takim razie, i pytam o to bez żadnej szydery, proszę
> opowiedz o swoich doświadczeniach, jak to działa w praktyce w
> kolokalizowanych zespołach praktykujących coding standards, shared
> ownership, daily standup i najlepiej jeszcze pair programming (albo
> przynajmniej code review).

Ale co Ci mam powiedzieć, że już wiele razy dokumentacja przyspieszyła
proces tworzenia? Nie wiem, nie mam innych doświadczeń, ale mogę sobie
jedynie wyobrazić efekt jej braku w projektach. Poza tym, nie jestem
pewien czy koszt wytworzenia dobrej dokumentacji jest wyższy niż
przypadku pair programming.

> Ja mówię, że design phase to jest osobny problem. Nawet jeśli masz
> zformalizowane, udokumentowane i zakontraktowane wymagania, to możesz
> pominąć design phase i od razu zabrać się za kodowanie.

Chyba nie ma sensu dalej ciągnąć tej dyskusji. Ja tak nie uważam. Co
więcej uważam takie podejście za nieodpowiedzialne. Równie dobrze można
się umówić z klientem na piwo i na podstawie pogawędek zacząć pisać program.

> Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
> kolejne wersje.

Tylko że release ma pełną funkcjonalność, a prototyp częściową. I to
jest różnica.

>> Nie rozumiem. Patrzę teraz z perspektywy przedsiębiorcy. Mnie interesuje
>> na kiedy mogę mieć produkt i ile za niego mam zapłacić. Średnio mnie
>> interesuje czy dostanę jakiś kawałek wcześniej czy później. Ważna jest
>> data wdrożenia całości.
>
> Nieprawda. Jako przedsiębiorcę, interesuje cię, czy zarobisz na tym
> oprogramowaniu i ile.

Jeśli została podjęta decyzja o zamówieniu oprogramowania, to była
poprzedzona analizą ROI lub czymś podobnym. Więc aspekt zarobku jest
ważny ale tylko w korelacji z czasem i kosztem wykonania.

> Jeśli dochodzisz do wniosku, że potrzebujesz jakiegoś programu do
> zarabiania, i określasz zespół ficzerów jaki ten program (jak ci się
> wydaje) powinien mieć, to zawsze musisz brać pod uwagę taki
> scenariusz, że jeden kontrahent powie, że zajmie to trzy lata, drugi
> zażyczy sobie 150 milionów dolarów, a trzeci powie że zrobi w 12
> miesięcy, ale nie zgodzi się na takie kary za opóźnienie, jakbyś
> chciał (w praktyce pozostawiając sobie furtkę do nawet znacznych
> opóźnień).
<CIACH>

Co za mętny wywód. Po pierwsze nie wziąłbym trzeciego wykonawcy, bo
targowanie się o ewentualne kary prowadzi do wniosku, że
najprawdopodobniej zaistnieje sytuacja że będą one wymagane. I dalszy
wywód nie ma już sensu. Wybrałbym tego który ma doświadczenie poparte
działającymi wdrożeniami.
Poza konkurent po 9 miesiącach ma raczej wersję 0.1 niż 1 :) I na koniec
okazuje się, że program robi poważne błędy w obliczaniu VAT bo nie było
beta testingu i przedsiębiorca dostaje kare z US i na drzwiach firmy
zakłada kłódkę.
Wiesz co? Bajki można układać dowolnie żeby potwierdzić swoją rację.

> O kurcze, w tym momencie przebiłes o kilka długości wszystkie
> idiotyczne metafory i analogie jakie pojawiły się w tej dyskusji.

Guzik przebiłem. Nie chcesz zrozumieć podstawy że bez określenia wymagań
i projektu można spierniczyć dokładnie wszystko. Nie odnosi się to tylko
do oprogramowania. A takie spierniczenie na pierwszym etapie skutkuje
kilka razy wyższą ceną i dłuższym terminem wykonania. Bo komuś nie
chciało się kilku dni na początku poświęcić na projekt.

> I tylko pozornie nie ma związku z dowodzeniem Wielkiego Twierdzenia
> Fermata.

Przecież to Ty starasz się dowieść że płaci się za czas produkcji a nie
jej efekt?

> Jeszcze uściślę, nie chodzi mi o projekt wewnętrzny w sensie "jest
> używany przez firmę a nie klientów", tylko "jest zamawiany przez
> kierownictwo firmy, a nie przez klienta". W odróżnieniu od sytuacji,
> kiedy przychodzi klient do firmy i mówi "chcę to a to", sytuacja kiedy
> ktoś w firmie wychodzi z inicjatywą "gdybyśmy zrobili program, który
> robi to-a-to, to może udałoby się to komuś sprzedać". I ja w takim

Gdzie ty masz taką firmę? Zamiast gdybania robi się analizę potrzeb
rynku i na tej podstawie rozpoczyna się myślenie o projekcie.

> sensie pracuję głównie przy projektach wewnętrznych, i wtedy myślenie
> jest takie, że jeśli można zacząć sprzedawać program z okrojoną
> funkcjonalnością za 6 miesięcy, a potem dodawać ficzery w kolejnych
> wersjach, albo można zażądać pełnego zestawu ficzerów i czekać 18
> miesięcy na wersję 1.0, to to pierwsze rozwiązanie ma duży sens
> biznesowy.

Zakładając że program z okrojoną funkcjonalnością jest zamkniętą
kompletną całością to się zgodzę.
Natomiast jeśli zamawiam np. program księgowy to co mi po okrojonej
funkcjonalności np. księgowania tylko kosztów a nie zakupów (które będą
w następnej wersji), skoro i tak resztę będę musiał robić ręcznie?
Wszystko zależy od tego, co mamy na myśli pisząc "okrojona" funkcjonalność.

> Nigdy się nie sprawdzał.

Aha, a programy to tej pory to w kapuście się znajdowało? :/

> Tak z ciekawości, ta certyfikacja polega też na tym, że certyfikują
> wam cały proces, tzn. muszą być jakieś konkretne fazy zbierania
> wymagań, analizy, designu itd. z datami rozpoczęcia i zakończenia, czy
> tylko wymagają artefaktów? Bo przecież to, o czym ja piszę, nie
> wyklucza wcale istnienia projektu, analizy i dokumentacji kodu w
> momencie zakończenia projektu.

Wiesz co? Chyba naprawdę czas zakończyć tę dyskusje. To bez sensu.
Pewnie jak się ktoś uprze to można robić i analizę założeń po
zakończeniu projektu. Wszystko można, jak ktoś sobie lubi utrudniać zadanie.

> To ja powiem tak: może w waszej specyficznej branży się sprawdza, ale
> poza nią to jest piękna teoria, bo w fazie projektowania klient czy
> domain expert przeczyta dokument, popatrzy na schemat i powie "tak,
> tak to właśnie ma działać", a jak mu pokażesz wersję alfa, to powie
> "nie, zuepłnie nie o to chodziło", "jeśli nie ma tej informacji, to ta
> funkcja jest bezużyteczna", "owszem, w dokumencie tego nie ma, ale to
> oczywiste". I okazuje się, że musisz wyrzucić połowę kodu i 3/4
> projektu.

Naprawdę koniec dyskusji. Jakby tak było to analityk / projektant olali
sprawę. Byłyby wyciągnięte konsekwencje, a firma poniosłaby stratę.
Natomiast byłaby mądrzejsza o te doświadczenia przy następnym projekcie.
Analityk ma dociec co klient naprawdę chce, a nie doprowadzić żeby ten
tylko powiedział że o to mu chodzi.

pozdrawiam,
Przemek O.

do góry

On May 18, 5:19 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
> > On May 18, 3:15 pm, Michal Kleczek <k...@g...com> wrote:
> >> Znacznie taniej jest usiasc, pomyslec i _bez_ programowania stwierdzic,
> >> ze sie nie oplaca. Taki waterfall - najpierw myslimy, potem (ewentualnie)
> >> programujemy.
>
> > Agile też na tym polega. Z tą różnicą, że myślenie jest timeboxowane
> > na 15 minut. :)
>
> IMHO tu lezy sedno problemu z "agile" i niekorzystnego wplywu jaki "agile"
> wywiera na przemysl IT. Znam to z wlasnego doswiadczenia - klient
> zafascynowany "metodykami agile" wymaga np. cotygodniowych releasow (bo sie
> naczytal o krotkich iteracjach). Co wiecej - te "releasy" to musi byc
> oprogramowanie produkcyjnej jakosci i kazdy "release" musi byc bogatszy w
> funkcjonalnosc.

No niestety, podsawą jest komunikacja, takie rzeczy trzeba sobioe
ustalić, wytłumaczyć i być może nawet zapisać w kontrakcie.

Nawet w Shore&Warden, gdzie jest proponowane pewne ekstremum jeśli
chodzi o długość iteracji, mówi się o tym, że iteracja trwa tydzień,
że produkuje _demo_, że od pewnego momentu każde demo powinno być
"ready to release", ale to też nie znaczy, że można sobie wziąć płytke
z demo i zacząć instalować.

> Po czym nastepuja negocjacje, bo przeciez musi byc czas na _myslenie_ - a
> ten jak ostatni duren sie upiera, ze myslenie == programowanie.
> Juz nie mowiac o tym, ze jak sie uwzgledni sam proces przygotowania
> "releasu" i jego przetestowanie, to sie okazuje, ze ni diabla nie da sie
> napisac linijki kodu, bo caly tydzien sie releasuje i testuje. A jak
> probowac rownolegle miec iles tam galezi to nic sie nie robi tylko
> "merguje".

Zdaje się że część metodologii konkretnie przestrzega przed
zwielakratnianiem gałęzi w ramach jednego projektu. W sensie, że jak
już musi być osobny branch dla jakiegoś klienta, to ten branch
powinien stać się oddzielnym projektem z oddzielnym zespołem.

> Inny znowu - troche moze lepiej, bo przynajmniej nie wymaga produkcyjnej
> jakosci - oczekuje ciaglego dostarczania prototypow w trakcie
> przygotowywania projektu.
> I ni cholery nie jestem ludzi w stanie przekonac, ze bedzie duzo taniej
> zamknac paru ludzi na 1 miesiac w pokoiku z tablica i duza iloscia papieru
> ale bez dostepu do komputera.
> Bo na etapie projektu komputer tylko przeszkadza.

Powiem, że mnie tez nie przekonałeś.

do góry

On 2011-05-19, Paweł Kierski <n...@p...net> wrote:
> W dniu 2011-05-19 12:25, Stachu 'Dozzie' K. pisze:
> [...]
>>>>> Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
>>>>> rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
>>>>> projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
>>>>> takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
>>>>> potem regularni i dość często kolejne release'y, np. co miesiąc albo co
>>>>> dwa miesiące.
>>>>
>>>> To co opisujesz, to bardziej mi pasuje do starej definicji
>>>> prototypowania z ominięciem najważniejszej części, że prototypu nie
>>>> wdraża się produkcyjnie.
>>>
>>> Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
>>> kolejne wersje.
>>
>> Ale co miesiąc? O_o
>> Toż samo testowanie czy wszystko działa w środowisku zbliżonym do
>> produkcji trwa tyle czasu (patrzę z perspektywy admina, więc osoby,
>> która to wdraża u klienta na produkcji).
>
> Iteracje mogą być dłuższe, a nie każda musi się kończyć testowaniem od
> A do Z, a np. tylko nowych ficzerów.

Pawle, ja komentuję ostatnie zdanie pierwszego akapitu z powyższego
cytatu.
#v+
[...] a potem regularni i dość często kolejne release'y, np. co miesiąc
albo co dwa miesiące.
#v-

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 18.05.2011 19:06, Michal Kleczek pisze:
> Michoo wrote:
> Ale sie nie nadaje do uzycia produkcyjnego (co jest postulowane przez
> "agile").
Agile nie postuluje, że każdy jeden system będzie się nadawał na
produkcję po 2 miesiącach. Postuluje, że należy dać klientowi szybko to
co można dać aby przetestował to we własnym zakresie i zrobił to na
możliwie wczesnym etapie. Bo najcenniejszy jest feedback od klienta.


> Do testowania "usability" nie potrzeba zadnego "agile" - wystarczy wyklikac
> _prototyp_ w jakims VB czy innym narzedziu RAD nie przejmujac sie tym, co
> jest "pod spodem" bo prototyp z zalozenia idzie do kosza. Tak jest po prostu
> taniej, bo mozna to zrobic w pare godzin.
Tylko taki czysty prototyp jest dobry do pokazania idei. Dobrze napisane
core GUI można dać do pani Jadzi, która będzie używać tego produkcyjnie,
żeby się pół godziny 'pobawiła' i opisała uwagi, które na tym etapie
wprowadzić jest tanio.


> Oczywiscie rownolegle mozna robic to co "pod spodem" - ale do tego jest
> potrzebny (hint) projekt, ktory wyspecyfikuje, ze w ogole dzielimy
> oprogramowanie na UI i "pod spodem" oraz powie nam co to wlasciwie znaczy
> "podzielic" i jak ten podzial przebiega.


> Taki projekt robi sie _zanim_ zacznie sie programowac - taki waterfall:
> najpierw myslimy, potem programujemy.
Nie zwracasz uwagi na jedną rzecz - agile to metodyka dla małych
zespołów - powiedzmy 2-8 programistów (4-6 jako sensowna średnia).
Jeżeli zespół się zna to takie rzeczy jak używana technologia, sposób
podziału na moduły, etc już mają wypracowany i nie trzeba go
specyfikować formalnie.

Myślenie więc ogranicza się do "co robimy", bo "jak robimy" jest już
niejako ustalone, a to, że "naszą metodą" da się wykonać taki projekt
zostało przeanalizowane przed przyjęciem zlecenia.

Agile nie zakłada "przeszkolimy ludzi i za 2 miesiące będziemy mogli
zacząć prace programistyczne a w tym czasie projektujemy", a "jesteśmy
specjalistami od X, więc prace z okolicy X robimy szybko i sprawnie, do
Y poszukajcie innego zespołu".

--
Pozdrawiam
Michoo

do góry

W dniu 2011-05-19 12:39, Andrzej Jarzabek pisze:

> Przecież analityk pracuje dla wykonawcy, jaki miałby interes w tym,
> żeby doradzać klientowi, żeby nie zapomniał o wpisaniu błota do umowy?

Zadaniem analityka jest wyłapanie wszystkich wymagań klienta, nawet tych
o których klient nie wie. I tym się różni dobry analityk od analityka,
że ten pierwszy takie wymagania wyłapie.
Klient z zasady nie wie tak do końca czego chce, a tym bardziej nie
potrafi określić dokładnej listy wymagań.

A jaki miałby w tym interes? Po pierwsze uświadamia klientowi dodatkowe
potrzeby o których on nie pomyślał (lub były dla niego oczywiste i o
nich nie wspomniał), po drugie minimalizuje ryzyko niepowodzenia
projektu już na samym jego początku, po trzecie wynalezienie istotnych
wymagań których klient nie był świadom pociąga możliwość wyższej wyceny
projektu.
Tak więc jakby nie patrzeć, to w interesie wykonawcy jest doradzanie
klientowi żeby nie zapomniał o wpisaniu "błota do umowy" :)

pozdrawiam,
Przemek O

do góry

On May 18, 5:05 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> >> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
> >> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego) oprogramowanie,
> >> to oznacza tylko tyle, ze to oprogramowanie jest po prostu trywialne.
>
> > Można to też ująć w ten sposób, że prawie zawsze złożone
> > oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
> > minimalnym stopniu, rdzeń.
>
> Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz uzyteczny
> rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej sie do
> produkcji?

Wziąłeś dwa ogólne przykłady typów programów, które mają od dziesiątek
lat wielu przedstawicieli gotowych do kupienia lub wzięcia z półki.
Oczywiście istnieje użyteczny rdzeń RDBMS czy OS jako takiego.
Przykładowo dla RDBMS będzie to program, który trzyma n tablic, gdzie
każda tablica ma k kolumn, dane są persistent i istnieje dostęp do
nich w jakikolwiek sposób, plus jakieś indeksy. Program, który spełnia
te założenia można napisać nawet w miesiąc i on już może być do czegoś
użyteczny. Oczywiście tu i teraz, gdzie istnieją gotowe RDBMSy można
powiedzieć, że skoro mozna mieć znacznie bardziej użyteczne RDBMSy za
darmo, to użyteczność robionego na zamówienie RDBMSa o takiej
funkcjonalności jest w praktyce zerowa.

Ale w takim razie jeśli pytamy o robienie nowego RDBMSa na zamówienie
tu i teraz, to powstaje pytanie, dlaczego ktoś w ogóle zamawia nowego
RDBMSa? Odpowiedź może brzmieć np. tak, że potrzebny jest mu killer
feature A, którego nie ma żaden dostępny na rynku RDBMS. I w takiej
sytuacji dla klienta może być nawet użyteczny minimalny RDBMS z killer
feature A, choćby nie miał języka zapytań, dostępu przez sieć,
transakcji, równoległego dostępu, większości rodzajów constraint'ów,
wymagał wyłączenia bazy w celu zmiany schematu itd.

Jeśli wydaje ci się, że to abstrakcyjny przykład, to ja sam pracowałem
w całkiem sporej i nieźle dochodowej firmie, która sobie wewnętrznie
zrobiła i od kilkunastu lat intensywnie eksploatowała system bazy
danych odpowiadający mniej więcej temu, co opisałem powyżej - w
zasadzie wszystkie produkty tej firmy opierały się na tym RDBMSie. A
to był zestaw ficzerów po długotrwałym rozwoju, z poprawką tylko na
to, że była mocno ograniczona forma równoległego dostępu. Nie tak
dawno przed tym, jak zacząłem pracowac w tej firmie dodano rewolucyjną
możliwość dynamicznego resizowania tablic: wcześniej w konfiguracji
się określało, ile dana tablica ma maksymalnie rekodrów, i tyle ona
zajmowała miejsca zawsze, a jak się próbowało dodać więcej, to był
fail.

> Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
> "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
> dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej firma
> moze stracic tzw "dobre imie" co sie przeklada na przyszle przychody.

Na szczęście nie wypełniam PIT, więc nie mam na ten temat nic do
powiedzenia :)

> > Oczywiście cel posiadania wersji gotowej do releasowania w ciągu dwóch
> > miesięcy nie jest taki, żeby po dwóch miesiącach produkt wypuścić do
> > produkcji, tylko żeby od tego momentu być gotowym do zrobienia release
> > w dowolnym momencie.
>
> Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms innym
> niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy problem).

Release to jest to samo, co wypuścić do produkcji. Gotowy do release
to nie to samo, co zrobić release. Widzisz już różnicę?

do góry

Andrzej Jarzabek wrote:

> On May 18, 5:05 pm, Michal Kleczek <k...@g...com> wrote:
>> Andrzej Jarzabek wrote:
>>
>> >> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
>> >> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego)
>> >> oprogramowanie, to oznacza tylko tyle, ze to oprogramowanie jest po
>> >> prostu trywialne.
>>
>> > Można to też ująć w ten sposób, że prawie zawsze złożone
>> > oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
>> > minimalnym stopniu, rdzeń.
>>
>> Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz
>> uzyteczny rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej
>> sie do produkcji?
>
> Wziąłeś dwa ogólne przykłady typów programów, które mają od dziesiątek
> lat wielu przedstawicieli gotowych do kupienia lub wzięcia z półki.
> Oczywiście istnieje użyteczny rdzeń RDBMS czy OS jako takiego.
> Przykładowo dla RDBMS będzie to program, który trzyma n tablic, gdzie
> każda tablica ma k kolumn, dane są persistent i istnieje dostęp do
> nich w jakikolwiek sposób, plus jakieś indeksy. Program, który spełnia
> te założenia można napisać nawet w miesiąc i on już może być do czegoś
> użyteczny. Oczywiście tu i teraz, gdzie istnieją gotowe RDBMSy można
> powiedzieć, że skoro mozna mieć znacznie bardziej użyteczne RDBMSy za
> darmo, to użyteczność robionego na zamówienie RDBMSa o takiej
> funkcjonalności jest w praktyce zerowa.

Dokladnie o to mi chodzi - niebanalny system ma taka ceche, ze jego
"fragment" nie ma sensu z punktu widzenia uzytkownika. To nie jest tak, ze
funkcjonalnosc (juz nie mowiac o cechach) daje sie dzielic i "wyciagac" i
nadal twierdzic, ze system jest uzyteczny. To jest IMO mit rozpowszechniany
przez zwolennikow "agile", ktorzy probuja - na szkode klienta - przekonac
go, ze prototyp i produkt to to samo.

>
> Ale w takim razie jeśli pytamy o robienie nowego RDBMSa na zamówienie
> tu i teraz, to powstaje pytanie, dlaczego ktoś w ogóle zamawia nowego
> RDBMSa? Odpowiedź może brzmieć np. tak, że potrzebny jest mu killer
> feature A, którego nie ma żaden dostępny na rynku RDBMS. I w takiej
> sytuacji dla klienta może być nawet użyteczny minimalny RDBMS z killer
> feature A, choćby nie miał języka zapytań,

LOL - to wlasnie jest podstawowa cecha definiujaca RDBMS (specjalnie nie
napisalem DBMS). Sam fakt, ze w pliku mozna przechowywac rekordy stalej
dlugosci nie swiadczy o tym, ze system plikow to RDBMS.

> dostępu przez sieć,
> transakcji, równoległego dostępu,

Mozliwosc rownoleglego dostepu jest jedna z cech definiujacych DBMS (juz nie
mowiac o RDBMS) - za wikipedia:
"A DBMS provides facilities for controlling data access, enforcing data
integrity, managing concurrency control, recovering the database after
failures and restoring it from backup files, as well as maintaining database
security"

[ciach]
>> Niespecjalnie widze roznice (chyba ze "zrobienie release" jest czyms
>> innym niz "wypuszczenie do produkcji" - jezeli tak, to tylko przesuwamy
>> problem).
>
> Release to jest to samo, co wypuścić do produkcji. Gotowy do release
> to nie to samo, co zrobić release. Widzisz już różnicę?

Nie - dla mnie "zrobienie releasa" polega na doprowadzeniu oprogramowania do
stanu "gotowy do release" - czynnosci zwiazane z samym przygotowaniem
artefaktow sa nieistotnymi ( z punktu widzenia procesu tworzenia
oprogramowania ) i w wiekszosci zautomatyzowanymi technikaliami.

--
Michal

do góry

W dniu 2011-05-18 18:05, Michal Kleczek pisze:
[...]
> Nawet - przykladowo - glupi programik do wypelniania PIT nie ma takiego
> "rdzenia", bo - mimo ze koncepcyjnie prosty - nadaje sie do sprzedazy
> dopiero jak jest dopracowany w szczegolach (co zajmuje czas) - inaczej firma
> moze stracic tzw "dobre imie" co sie przeklada na przyszle przychody.

To nie musi być prawda. Jeśli nie masz nic do wspomagania wypełniania
PITu, to głupi formularz, który da się wydrukować może być
wystarczający jako wersja 1.0. Sprawdzanie, czy minimalny zestaw pól
jest jakkolwiek wypełniony, a potem sprawdzenie dla niektórych formatu
to już kolejne funkcjonalności. Na koniec może z tego powstać program,
który potrafi przeliczać kolejne pola na podstawie "wejściowych"
i wiele innych rzeczy. Ale nawet to też da się podzielić na działające
i "sprzedawalne" części.

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

do góry