On May 18, 4:51 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
>
> > No więc właśnie to bzdura, bo nic takiego nie wynika. Jeśli kopiesz
> > rowy koparką, ale w ramach kopania rowów masz też etap gdzie
> > decydujesz czy i gdzie kopać, i do decydowania o tym koparki nie
> > używasz, to nie znaczy, że ta cała koparka jest bezuzyteczna, bo
> > przecież jej i tak "naprawdę" nie używasz.
>
> To oznacza tylko tyle, ze ta "koparka" jest malo wazna/interesujaca z punktu
> widzenia calosci przedsiewziecia. Reklamowanie jej jako panaceum (a tak jest
> reklamowane "agile") na cokolwiek jest albo glupota albo oszustwem.

Dla mnie z kolei mało interesujące jest to, jak coś "jest
reklamowane".


> > To jest pytanie interesujące dla kogoś, kto decyduje jakie metody/
> > procesy stosować dla jakich projektów. Samo pytanie jest przecież
> > zależne od szczegółów projektu.
>
> Tyle ze zanim zadamy to pytanie, to trzeba np. okreslic wielkosc projektu i
> wielkosc potrzebnego zespolu. Zeby to zrobic trzeba wykonac jakies czynnosci
> (hint: analiza wymagan i projekt - w kazdym razie wstepny projekt).

Nie no, oczywiście, zanim zaczyna działać agile potrzebna jest jakaś
koncepcja projektu, przynajmniej co to ma być za program i komu do
czego potrzebny. Tylko że to jest całkiem realny scenariusz, że taka
koncepcja istnieje i pytanie brzmi co dalej.

> > Nieprawda. Proponuję przeczytać jakąś książkę o XP, powiedzmy
> >http://www.amazon.com/Art-Agile-Development-James-S
hore/dp/0596527675/
>
> Tej akurat nie czytalem - wystarczyly mi wypociny niejakiego Kenta Becka -

Tutaj mamy problem definicyjny: jeśli dla ciebie XP to tylko to, co
opisał Beck i trzymanie się dokładnie tego bez zmiany ani słowa, to
nie mamy o czym dyskutować - powiem tylko, że być może masz rację.

Jeśli potraktujemy XP jako szerszą rodzinę metodologii wywodzących się
i rozszerzających koncepcje Becka, to polecam jednak zapoznać się z
Shore&Warden - to bardzo dobra książka, uzupełniająca i
uszczegóławiająca wiele braków w metodologii Becka.

> oparcie testowania (ale takze przeciez i projektu oprogramowania, ktory
> zarowno wynika jak i wplywa na sposoby testowania) o automatyczne "unit
> testy" i "customer testing" (jak w XP) jest po prostu liznieciem tematu.
> Ksiazka (gruba jak cholera - ok 1tys stron) tak naprawde tylko ilustruje jak
> szeroki on jest i ze nie ma mozliwosci organizacji procesu wytworczego bez
> przewidzenia miejsca dla _specjalizowanej_ grupy/roli testerow czy tez
> projektantow testow (bo przecietny programista nie ma o tym wiekszego
> pojecia). Znane mi metodyki agile (fakt - tylko XP) nie przewiduja takiej
> roli.

Shore&Warden przewiduje.

> > To nie tak. Agile mówi, że skutecznośc długotrwałego i skrupulatnego
> > planowania nie jest dużo większa niż skuteczność planowania w postaci
> > półodzinnego zebrania, a za to dużo więcej kosztuje no i pochłania
> > czas.
>
> Jasne - w pol godziny mozna zaplanowac budowe nietrywialnego systemu
> informatycznego. Ciekawe dlaczego nie daje sie tego zrobic z banalnym
> remontem parokilometrowego odcinka drogi powiatowej.

O tym musisz spytac kogoś, kto się zna na budowaniu dróg.

> > E tam. Budżetowanie i inwestowanie nie jest przecież funkcją
> > dostarczenia takich czy innych ficzerów w kodzie, tylko strumieni
> > przychodów i wydatków.
>
> No ale skad sie biora wydatki? Przeciez taki zespol programistow XP to spory
> koszt, ktory trzeba uwzglednic.

Programistom zwykle płaci się jakieś ustalone pensje czy stawki
dzienne, nie?

> > Dla dostawcy oprogramowania każdy nowy projekt
> > to niewspółmierne ryzyko, pieniądze robi się na ciągnięciu kasy od
> > istniejących klientów za istniejące produkty. Dla większej firmy
> > zawsze kalkulacja wygląda tak: "żeby się rozwijać, musimy zrobić nowy
> > produkt. Zapewne na tym stracimy, ale jest szansa, że produkt odniesie
> > sukces i w przyszłości zamieni się w stałe źródło zysków". Żadne
> > planowanie w tym nie pomoże, bo przecież nie uwzględnisz w planowaniu
> > tego, czy pomysł jest dobry, czy oprogramowanie będzie dobrej jakości
> > i jak się świat zmieni w przyszłości.
>
> Oczywiscie, ze uwzglednisz - sugerujesz, ze taki dajmy na to MS nie planuje
> wydatkow, deadlinow i ficzerow w nowej wersje Windows? (tylko prosze bez
> argumentu, ze Win jest be, bo to nie ma nic do rzeczy - zreszta nie jest
> taki be skoro wszyscy kupuja)

Nie uważam, że jest be i nie wiem jaki proces ma Micxrosoft, natomiast
patrząc na to, jak radzą sobie z dostarczaniem publicznie ogłaszanych
produktów w publicznie ogłaszanych terminach, to mam mocne
podjerzenia, że jeśli wewnętrznie używają jakichś terminów i budżetów
to są one kompletną fikcją.

> > Oczywiście w przypadku firmy robiącej program na konkrene zamówienie,
> > strumienie przychodów i wydatków zależą od podpisanych kontraktów i od
> > kosztów operacyjnych, więc też się poddają łatwemu planowaniu
> > niezależnie od tego, czy istnieje plan implementowania konkretnch
> > features.
>
> Oczywiscie, ze nie, bo takie podejscie zaklada, ze mamy stale koszty (w
> postaci stalego zespolu) lub stale przychody (bo z grubsza za kazdy
> "feature" jest dodatkowa kasa). A przeciez ludzi mozna po prostu (w
> uproszczeniu) zwolnic, jak sa niepotrzebni - tym samym zmniejszajac koszty.
> Lub mozna dorzucic features zwiekszajac margines zysku.

Możesz, ale plan całości projektu niewiele w tym pomoże. Jeśli z
twojego planu wynika, że połowa programistów zrobi zakontraktowany
scope w zakontraktowane 12 miesięcy, więc zwolnisz albo przeniesiesz
do innego projektu drugą połowę, to ryzykujesz, że obudzisz się z ręką
w nocniku, kiedy po 12 miesiącach zakontraktowany scope będzie
wykonany w 50%.

Jeśli natomiast chodzi o dodawanie features, to w przypadku
zamówionego programu jak ci to pomoże, skoro w umowie jest cena za to,
co w umowie? Myślisz, że z dobrego serca zleceniodawca zapłaci więcej?

W Agile robisz tak, że decydujesz ilu programistów pracuje przy
projekcie (w XP i tak masz wąski zakres) i w ramach tego cały czas
dodajesz features według tego, co klient mówi. W pewnym momencie masz
sytuację, kiedy odpowiedniu dużo features jest zaimplementowane,
jesteś "ready to release", stakeholder ogląda demo i mówi "chcę
release z taką funkcjonalnością". Potem się z nim dogaduje, czy chce
kolejną wersję, robi się planowanie co i w jakiej kolejności będzie
implementowane i jazda. Klient płaci zgodne z umową, programiści,
dzierżawa buira, prąd kosztują tyle a tyle i masz budżet.

> >> Jak chcesz przekonac inwestorow gieldowych, ze inwestycja w
> >> oprogramowanie ma sens, jezeli jedyne co im jestes w stanie powiedziec,
> >> to ze "wywalimy tylko X PLN na dwa miesiace pracy zespolu i wtedy
> >> zobaczymy co dalej".
>
> > Ale o czym ty mówisz? O firmie, która nie ma gotowych produktów, nie
> > ma płacących klientów, ma tylko pomysł i zespół - i wchodzi na giełdę?
>
> Nie - firma notowana na gieldzie musi non-stop przekonywac inwestorow, ze
> jej plany inwestycyjne maja sens - w przeciwnym wypadku akcje stanieja,
> posiadacze akcji straca, zdenerwuja sie i zmienia zarzad. Proste jak budowa
> cepa.

Pracowałem przez kilka lat w spółkach giełdowych i według mojego
doświadczenia realia działania takich spółek nie mają nic wspólnego z
tym, co opisujesz. Posiadacze akcji nie widzą poszczególnych
projektów, dostają tylko roczne i kwartalne wyniki całej spółki, z
wyszczególnieniem tylko kilk głównych pozycji na co idą czy skąd się
bierze kasa. Zarząd (board of directors) ma jakiś tam bardzo ogólny
wgląd w działalność całości firmy, ale ni tez są bardzo daleko od
takich rzeczy jak to, jakie korzyści i terminy planowane są dla
konkretnych projektów. Decyzje podejmują tylko w grubych sprawach typu
megers and acquisitions, reorganizacja, wymiana CEO. CEO kieruje firmą
mianując kierowników regionów czy działów, w działach są zespoły które
mają swoich managerów i dopiero taki manager decyduje o tym, jakie
projekty i dlaczego ma realizowac zespół. Spokojnie może być tak, że
na podstawie jakiegoś pomysłu "takie coś możnaby sprzedać klientom"
popartego przez osoby z odpowiednim doświadczeniem i wpływami robi sie
np. dwumiesięczne viability study, w trakcie którego może być
wyprodukowane demo z zestawem features, który już wnosi jakąś wartość,
i jeśli to zostanie wdrożone i przyniesie zyski, a równocześnie będą
powstawać kolejne wersje z kolejnymi ficzersami wnoszącymi dalszą
wartość, to z punktu widzenia kierownika działu czy regionu dany
zespół będzie wygladał dobrze, a jeśli odpowiednia ilość zespołów
będzie odpowiedno szybko produkowała produkty przynoszące odpowiednio
wcześnie zyski, to dział będzie wyglądał dobrze i CEO powie
kierownikowi działu "dobra robota Stefek, powiedz, może by się dało
wprowadzić tę całą waszą 'metodologię' jako company-wide process" - a
zarząd przyklaśnie.

> >> A jakie np?
> > Np. retrospective.
> Jakis link?

Są opisane w Shore&Warden, ale są też całe książki na ten temat:
http://www.amazon.com/Agile-Retrospectives-Making-Te
ams-Great/dp/0977616649/
(przyznam że nie czytałem, bo mnie to aż na takim poziomie
szczegółowości nie interesuje, wystarczy mi to, opeiram się na tym, co
przeczytałem w Shore&Warden, gdzie jest rozdział poświęcony temu
tematowi)

do góry

Michoo wrote:

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

Ale po co dawac jej "dobrze napisane" GUI skoro mozna jej dac wyklikany w 20
min prototyp, po czym w nastepne 15 minut (lub po prostu na biezaco)
wprowadzic modyfikacje i znowu pokazac?
To sie nazywa "prototypowanie". Ale prototyp to nie produkt.

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

No jezeli zespol robi po raz n-ty te sama aplikacje skladajaca sie z trzech
formularzy do wklepania danych zeby je zapisac w juz istniejacej RDB (bo
dobrze zaprojektowac schemat dla wiekszego systemu wymaga czasu i doglebnej
analizy) to oczywiscie - nie trzeba myslec.
Tylko to samo moze zrobic jeden czlowiek - zaden "zespol" XP nie jest
potrzebny - a juz "pair programming" to po prostu wyrzucanie pieniedzy.

--
Michal

do góry

Andrzej Jarzabek wrote:

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

No sam pisales o "jadrze", ktore moze powstac w 2 mies i jest uzyteczne.

>> 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" -
^^^^^^^^^^^^^^^^^^^^^^^^
(podkreslenie moje)

>> 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
Czyli nie rownolegle.

Prosze - czytaj posty, zanim na nie odpowiesz - w przeciwnym wypadku
dyskusja przypomina rozmowe "wola z prosieciem".

--
Michal

do góry

On May 19, 1:33 pm, Michal Kleczek <k...@g...com> wrote:
>
> 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.

Oczywiście, że się daje. Kiedyś był taki czas, że nie było na świcie
ani jednego RDBMSa. Maksymalnie okrojony pseudo-RDBMS byłby wtedy
produktem potencjalnie przydatnym. Tak samo jakby ktoś dzisiaj chciał
zrobić system o funkcjonalności wczesnego CP/M, to nikomu by taki
system bnnie był potrzebny, mimo że kiedyś był powszechnie używany i
bardzo użyteczny dla wielu ludzi.

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

A ja nie mówię o tym, czym jest, a czym nie jest RDBMS, tylko co jest
trywialnym jądrem RDBMSa. System zarądzania bazą danych, o którym
pisałem, nie miał języka zapytań, a jednak z powodzeniem służył do
zarządzania bazami wielkiej ilości produktów, na których firma
zarabiała kupę szmalu.

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

No więc system, o którym pisałem, nie robił połowy z tych rzeczy, a
jednak chodziły na nim bazy danych wielkiej ilości produktów itd. itp.

do góry

W dniu 2011-05-15 15:19, k...@g...pl pisze:
> <f...@g...pl> napisał(a):
>
>> kiedys juz to pytanie nawet chyba sie przewinelo bez odpowiedzi
>> - a to ciekawa kwestia; czy ktos ma pojecie ilu jest programistow
>> na swiecie - oszacowac chyba powino sie jakos dac (na pewno jest ich
>> sporo); ilu moze byc programistow w polsce - ze sto tysiecy moze?
>> na swiecie? kilka milionow?
>
> Zbyt wielu.

żaden z nich nie śmiał zagrać przy Jankielu

do góry

W dniu 2011-05-19 14:33, Michal Kleczek pisze:
> 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ż to zależy od klienta i systemu. Z drugiej strony nie wierzę, że
nie można w dużym odsetku projektów nie wyodrębnić choćby
funkcjonalności klasy "nice to have". I takie nie są krytycznie
potrzebne, da się je "wyciągnąć". Nie jest tak, że wszystkie systemy są
typu "wszystko albo nic", gdzie brak jednej funkcjonalności powoduje
kompletną bezużyteczność. Pozwolę sobie sparafrazować - to jest IMO mit
rozpowszechniany przez zwolenników waterfalli, którzy próbują - na
szkodę klienta - przekonać go, że bez choćby jednej funkcjonalności
produkt nadaje się tylko do kosza.

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

Co nie umniejsza użyteczności rozwiązania, jakkolwiek by go nie
klasyfikować. Po prostu tyle wystarczyło, więcej było wyrzucaniem
pieniędzy w błoto, a co gorsza - stratą czasu. Budować w tej sytuacji
coś, co spełnia definicję (R)DBMS, kosztem czasu i pieniędzy w celu
spełnienia definicji (lub stworzonych rok wcześniej, a już
nieaktualnych założeń)?

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

do góry

On May 19, 1:49 pm, Michal Kleczek <k...@g...com> wrote:
> Andrzej Jarzabek wrote:
> > 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?
>
> No sam pisales o "jadrze", ktore moze powstac w 2 mies i jest uzyteczne.

O PITach nic nie pisałem. Do użycia produkcyjneo nadaje się wersja
release, co taka wersja będzie miała, to kompetentnie się nie
wypowiem.

> >> 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" -
>
> ^^^^^^^^^^^^^^^^^^^^^^^^
> (podkreslenie moje)
>
> >> 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
>
> Czyli nie rownolegle.

Czemu nie równolegle? Równolegle może jedna osoba/para dłubać GUI w
VB, druga pisać funkcje liczące (czy stuby udające, że liczą) w tym
samym programie VB. Jeśli po pierwszej iteracji zapada decyzja, że
obliczenia jednak mają być robione w C++, to zespół, który robi GUI
przerabia je tak, żeby brało obliczenia z DLL-ki, a zepsół od obliczeń
przepisuje obliczenia/stuby na C++. W trzeciej iteracji można
równolegle dalej rozwijać kod robiący obliczenia, przepakowywać DLL-kę
w serwer obliczeń i pracować nad GUI.

do góry

W dniu 2011-05-19 13:00, Przemek O. pisze:
[...]
>> 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.

Istnieją proejekty, w których dostarczenie częściowej funkcjonalności
przez zakończeniem całości daje dodatkową wartość. Istnieją nawet takie,
w których bez dostarczania 1/5 funkcjonalności po kwartale może
spowodować, że całość przestaje być akutalna. Bo np. konkurencja nas
wyprzedziła dając 1/4 funkcjonalności w pół roku, a my nadal czekamy
na całość.

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

Lepiej sprzedać edytor tekstowy bez możliwości obracania czcionek, czy
dać się wyprzedzić konkurencji czekając na całość? Jeśli tego w analizie
biznesowej ktoś nie dopilnuje, to zasługuje na porażkę.

[...]
> 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?

Jeśli efektem ma być most - masz rację. Jeśli efektem ma być
wyprzedzenie konkurencji w przeprawianiu towarów i ludzi przez rzekę, to
może warto zaiwestować w dowolne, nawet ułomne rozwiązanie, które to
umożliwia? Mając zapewne na względzie docelową stałą przeprawę.

[...]
>> 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ść.

Taka, dzięki której mogę ograniczyć koszty, zwiększyć przychód lub zająć
lepszą pozycję rynkową wyprzedzając konkurencję.

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

do góry

On May 19, 12:13 pm, "Przemek O." <p...@o...eu> wrote:
> 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ł),

I jaką korzyść z tego uświadomienia ma wykonawca?

> po drugie minimalizuje ryzyko niepowodzenia
> projektu już na samym jego początku,

Niby w jaki sposób?

> po trzecie wynalezienie istotnych
> wymagań których klient nie był świadom pociąga możliwość wyższej wyceny
> projektu.

Albo i nie. Bo przecież z punktu widzenia zleceniodawcy zamawia on
ciągle ten sam produkt.

> Tak więc jakby nie patrzeć, to w interesie wykonawcy jest doradzanie
> klientowi żeby nie zapomniał o wpisaniu "błota do umowy" :)

No to jak ci napiszę, jak można na to patrzeć, żeby to nie było w
interesie wykonawcy: nie uwzględnienie istotnych rzeczywistych wymagań
w umowie daje wykonawcy kartę przetargową w scope negotiations. Jeśli
np. w umowie zawarty jest bdziąbągator, a w trakcie prac okazuje się,
że wykonanie działającego bżdziągąbatora jest bardzo trudne,
czasochłonne i kosztowne, a z drugiej strony wiadomo, że bez
bżdziągąbatora traktor też będzie działał, to wykonawca może tylko iść
do zleceniodawcy i powiedzieć mu "nie damy rady zrobić bździągąbatora
w terminie, możemy dostarczyć pierwszą wersję bez bździągąbatora, albo
opóźnić dostawę o pół roku". Zleceniodawca może w takiej sytuacji
powiedzieć "bździągąbator jest w umowie, dostarczacie w terminie albo
płacicie kary". I teraz jeśli w umowie nie ma błota, to wykonawca mówi
"ok, dostarczymy traktor z bździągąbatorem, ale za to nie jeżdżący po
błocie".

do góry

W dniu 2011-05-19 16:01, Paweł Kierski pisze:

> Istnieją proejekty, w których dostarczenie częściowej funkcjonalności
> przez zakończeniem całości daje dodatkową wartość. Istnieją nawet takie,
> w których bez dostarczania 1/5 funkcjonalności po kwartale może
> spowodować, że całość przestaje być akutalna. Bo np. konkurencja nas
> wyprzedziła dając 1/4 funkcjonalności w pół roku, a my nadal czekamy
> na całość.

Ale oczywiście, tylko że nie można tego uznać za powszechnie
obowiązującą zasadę dla całości tworzonego oprogramowania.
Z tym wyprzedzaniem konkurencji to też tak nie do końca, konkurencja nas
wyprzedziła dając 1/4 funkcjonalności w pół roku, ale my dostarczamy
całość w rok, a konkurencja ma dopiero połowę. Dlaczego? Bo czas
poświęcony na wydanie wersji też trzeba liczyć. Chyba że robimy to
równolegle, ale wtedy zwiększają się koszty. Więc pytanie czy lepiej
poczekać na całość rok i zapłacić mniej, czy dostawać ćwiartkę w co pół
roku za większe pieniądze.
Tylko że to jest gdybanie. Żeby o tym dyskutować trzeba by mieć jakiś
konkret.

> Lepiej sprzedać edytor tekstowy bez możliwości obracania czcionek, czy
> dać się wyprzedzić konkurencji czekając na całość? Jeśli tego w analizie
> biznesowej ktoś nie dopilnuje, to zasługuje na porażkę.

Jeżeli ficzerem który był istotny miało być obracanie czcionek to lepiej
poczekać na całość. Czym niby mam się dać wyprzedzić konkurencji? I tak
nie będzie miała tego obracania czcionek. A jeśli będzie miała to znaczy
że jest lepsza i po prostu przegraliśmy rywalizację rynkową.
Zauważ że ja będę miał cały produkt w jakimś tam czasie i określonym
budżecie. Domniemana konkurencja robiąc wydania co jakiś czas, całość i
tak będzie miała co najmniej w tym samym czasie, jak nie później (ze
względu na proces dostarczania działającego wydania) i w tej samej
cenie, albo drożej (bo wydłuży się czas produkcji lub będą poniesione
dodatkowe koszty na dodatkowe osoby przygotowujące wydania).
To wszystko przy założeniu takiej samej prędkości tworzenia projektu i
identycznych osobo/kosztów. Czyli dywagacja czysto akademicka.
Bo ja mogę mieć większy/szybszy zespół i w pół roku wydać całość. Albo
na odwrót konkurencja tak może mieć.

> Jeśli efektem ma być most - masz rację. Jeśli efektem ma być
> wyprzedzenie konkurencji w przeprawianiu towarów i ludzi przez rzekę, to
> może warto zaiwestować w dowolne, nawet ułomne rozwiązanie, które to
> umożliwia? Mając zapewne na względzie docelową stałą przeprawę.

Pytanie to samo jak wyżej. Tylko czy koszt takiej prowizorki +
rozwiązania docelowego łącznie z czasem tego wykonania miałby sens?
Wszystko zależy jakim procentem docelowego rozwiązania miałaby być ta
prowizorka.

> Taka, dzięki której mogę ograniczyć koszty, zwiększyć przychód lub zająć
> lepszą pozycję rynkową wyprzedzając konkurencję.

No tak, ale jeśli całość projektu to wymagania minimalne dla owego
ograniczania czy zwiększania?

pozdrawiam,
Przemek O.

do góry