Zaczynanie "od tyłu strony" vs. Agile

WeiXiao > Zgodzę się, że nic wspólnego nie ma bo wzorce i praktyki są niezależne od tej czy tamtej metodyki, procesu, frameworku, sraken pierdaken.

Nie zgodzę się natomiast ponieważ tu moje subiektywne doświadczenia wskazują, że jednak fanatykom agile czary bardzo mocno w łeb wchodzą i potrafią otwarcie powiedzieć, że walić dokumentację bo nowe ficzery.

I to nie mówię o kołczerach co o managemencie decyzyjnym. Naczytają się blogo-bełtów z neta pełnych bredni, sami nie potrafią liczyć to co, internet najlepszą wyrocznią. I nie mówię tu o wartościowych blog notach jak te o probabilistyce, zarządzaniu ryzykiem czy coś tylko o zwykłym ogólnikowym podejściu do agile.

@Fistandantilus

Cóż, pozostaje chyba tylko olewać pato-ewangelistów i nakłaniać zespoły do wypracowywania metodyk / podejść pod ich potrzeby, a nie pod trendy na konfach :D

WeiXiao napisał(a):

@Fistandantilus

Cóż, pozostaje chyba tylko olewać pato-ewangelistów i nakłaniać zespoły do wypracowywania metodyk / podejść pod ich potrzeby, a nie pod trendy na konfach :D

Łatwo powiedzieć Panie Kolego Devie.

Zobacz Pan - kieras ma budżet to da zarobić kolegom którzy kiedyś i jemu pomogli.

Przyjdzie guru, ludki go obsrają, kieras zadowolon - no i co z tego? Kasa przeszła gdzie miała przejść.

A spróbuj lobbować na neutralsów pod kątem ideololo w firmie to może akurat siądzie, natomiast z tego co znam branżę szkoleniową na wylot to to są układy i układziki i nie przejdzie nikt kto nie ma akurat przejść w danym momencie czasu i przestrzeni, choćby nie wiem jak zajebisty był.

Powiem tylko tak - czas Uncle Bob'a czy Mike Cohn'a czy innych tego typu da się po prostu kupić za skończoną ilość hajsu. Cóż z tego, skoro guru z Polski są z 5 razy tańsi, a i przeparsują notki tychże autorów po swojemu.

Tu nie ma cudów, to jest biznes.

Podobnie spece od TRIZ, od patentów czy innowacji z zagranicy - czas Petrova, Livotova, Karen Gadd czy Darell Mann'a da się kupić, ale jest to czas droższy od tańszego pirdo-lolo lokalnego, bo w Polsce nie inwestuje się w innowacje, mimo pięknego markietingu.

Choć akurat w Polsce mamy speców od TRIZ, ale to i tak trudna inwestycja.

Fistandantilus napisał(a):

Nie zgodzę się natomiast ponieważ tu moje subiektywne doświadczenia wskazują, że jednak fanatykom agile czary bardzo mocno w łeb wchodzą i potrafią otwarcie powiedzieć, że walić dokumentację bo nowe ficzery.

Nie warto polegać wyłącznie na własnych doświadczeniach z patologicznych miejsc.

Tyle, że nie ma żadnych kryteriów oceny dobre/niedobre miejsce. Agile to nonsens tego rzędu, że jakby jeden z drugim kołcz zobaczyli swoje własne cv lekko zmienione, bez nazw firm tzw blind to by się sami odwalili za brak kompetencji.

Testowałem to na ludziach, niestesty tak to działa.

To jest polityka, stołki i kasa, nic więcej. Juleczka odwala ekspertów bo sama nic nie umie więc nie zaryzykuje utraty 10 000+ za nic nie robienie.

Fistandantilus napisał(a):

Tyle, że nie ma żadnych kryteriów oceny dobre/niedobre miejsce.

Skoro nie ma kryteriów tego, czym jest niedobre miejsce, to nigdy nie ma też podstaw aby narzekać.

To jest polityka, stołki i kasa, nic więcej. Juleczka odwala ekspertów bo sama nic nie umie więc nie zaryzykuje utraty 10 000+ za nic nie robienie.

Jaka Juleczka? Jakich ekspertów? Jak odwala?
Mam wrażenie, że dalej opisujesz jakieś swoje patologiczne doświadczenia.

@Fistandantilus: Wydaje mi się że mylisz ruch scrum masterów i certyfikatowców i innych takich nonsensowców, z faktycznym Agile. Co do pierwszego się zgadzam całkowicie, że to nic niewarty chłam. Ale nie zmienia to faktu, że początkowe idee są nadal aktualne i wartościowe (np. krótkie iteracje, feedback, komunikacja, reakcja na zmiany, etc.)

@Riddle Nie ma kryteriów które pozwalają na ocenę kto jest kto, więc po prostu nie wiesz.

Dla przykładów

ITIL, PMBOK - ktoś zna te procedury i praktyki albo nie zna, tu nie ma miejsca na coś pomiędzy
Scrum i Agile - albo się czyjeś słowa zgadzają z moim podejściem jako osoby rekrutującej albo nie

Skill based - zarządzanie ryzykiem, zmianą, governance, kontrola pracy w projekcie - tu podobnie, albo mamy pokrycie z tym czego oczekujemy i co wiemy, albo nie. Czasem to akurat dobrze, bo ktoś dajmy na to zna się na Six Sigma i coś wniesie nowego, czasem to nie dobrze, bo będzie za bardzo dryfował w innym kierunku gdzie np. ten klient potrzebuje tylko poganiacza pracy.

To tylko moja opinia, ot mam wrażenie, że DevOps nadpisuje Agile bo nie dość, że czerpie z Agile to jeszcze rozwija praktyki people/processes/tools.

@somekind

Przy braku jasnych kryteriów wchodzimy w niepewność epistemiczną. Dajmy na to, nie ma kryteriów bycia fit. Ktoś jest grubas i po prostu czuje, że wolniej biega, szybciej się męczy tak dalej, a kolega który ćwiczy - nie. Więc może narzekać, bo jednak widzi potencjalny postęp.

Natomiast zobacz - o ile założenia Agile są górnolotne, ogólnikowe i w sumie ok, tak już to kto ma za to odpowiadać to już polityka i walka na słowa, obietnice, uzasadnienia, mniej lub bardziej mętne.

Opisuję po prostu doświadczenia. Tych dobrych po co opisywać, jak coś działa to z tego się konsultuje:)

@Fistandantilus: Agile ma swoją bardzo luźną definicję, która została umieszczona w Agile Manifesto. Scrum SAFe to metodyki, które się do tego agile niby przykleiły. Ich celem nie jest sprawienie, że wyprodukowany zostanie lepszy software, szybciej. Jedynym celem tych metodyk jest zarabianie kasy przez firmę, która to wymyśliła i opisała. Autoryzowane szkolenia, konsulting, egzaminy, certyfikaty, książki.
Menadżerska menażeria też zadowolona, bo "Ordung muss sein", można sobie wymyślić całe stado bezsensownych, ale mądrze wyglądających kejpiajów i przekonać pięterko wyżej, że według obiektywnych wskaźników projekt był zarządzany dobrze, bo przecież rosło velocity, stosowano ciągłe doskonalenie procesu na cotygodniowych retrospektywach i utrzymywano znakomitą zdolność zespołu do komunikacji wewnętrznej na dokładnie 15 minutowych daily jak każe księga. Zadbano też o przeszkolonych i certyfikowanych mistrzów scruma, więc jak jebło, to nie może być wina managera, tylko bóg tak chciał.

piotrpo napisał(a):

Jedynym celem tych metodyk jest zarabianie kasy przez firmę, która to wymyśliła i opisała. Autoryzowane szkolenia, konsulting, egzaminy, certyfikaty, książki.

Ale że tak od razu od cui bono? Może rzeczywiście jednak chcieli dobrze a wyszło jak zawsze?

@loza_prowizoryczna: No stary i zgorzkniały jestem. W dodatku z Polski. Jak czegoś nie rozumiem, to krzyczę "złodzieje" na wszelki wypadek. Nie wiem jak było na początku i czy taki Scrum powstał oryginalnie dla tworzenia oprogramowania, czy dla robienia kasy na certach i szkoleniach. Natomiast jest napisany pod managerów, a nie programistów. Taka metodyka, żeby ludzie, którzy w życiu nie zrobili działającej aplikacji, ani nawet nie widzieli jak ktoś robi działającą aplikację uwierzyli, że wprowadzą system zarządzania projektem i tym razem im się uda.

piotrpo napisał(a):

Taka metodyka, żeby ludzie, którzy w życiu nie zrobili działającej aplikacji, ani nawet nie widzieli jak ktoś robi działającą aplikację uwierzyli, że wprowadzą system zarządzania projektem i tym razem im się uda.

Może ja za młody jestem ale procedury, szkolenia i KPI to są podstawy skalowalnego przemysłu gdzieś tak od Forda (Nowy Wspaniały Świat czy jakoś tak). Więc nieważne jak to będzie nazwane, jeśli są metryki to znaczy że biznes jest skalowalny i mierzalny - a przecież o to chodzi w całej rewolucji, o optymalizację produkcji w oparciu o metodę naukową, prawda?

loza_prowizoryczna napisał(a):

Może ja za młody jestem ale procedury, szkolenia i KPI to są podstawy skalowalnego przemysłu gdzieś tak od Forda (Nowy Wspaniały Świat czy jakoś tak). Więc nieważne jak to będzie nazwane, jeśli są metryki to znaczy że biznes jest skalowalny i mierzalny - a przecież o to chodzi w całej rewolucji, o optymalizację produkcji w oparciu o metodę naukową, prawda?

Masz rację, jeżeli mówimy o przemyśle w rodzaju składania samochodów. Dzielisz proces produkcyjny na kawałeczki, opisujesz, tworzysz program szkoleń, bierzesz standardowego pracownika, szkolisz, stawiasz na miejscu zgodnym ze szkoleniem i mierzysz wydajność na poziomie czynności, stanowiska, całej linii, wprowadzasz drobne zmiany, mierzysz ich skutek itd. Oczywiście w programowaniu też dobrze byłoby mieć tak samo. Stawiasz salę z biurkami, wrzucasz do niej analityka, project managera, trenerów i tanią siłę roboczą po 3 miesięcznym szkoleniu i działa. Problem w tym, że to jeszcze nie działa. To trochę nie działa również w przypadku samochodów, ale w przypadku software nie działa bardziej.

piotrpo napisał(a):

Stawiasz salę z biurkami, wrzucasz do niej analityka, project managera, trenerów i tanią siłę roboczą po 3 miesięcznym szkoleniu i działa.

Jak ktoś tak wdraża Scruma, to nie jest to prawdziwy Scrum XD

Ja wiem, że to jest ulubione powiedzonko scrumistów, ale jednak takie podejście - dokonamy zmiany i będzie fajnie - pachnie waterfallem. Scrum zakłada iteracyjność (co zbliża go do programowania zwinnego), więc nie da się go tak wdrożyć po prostu jednym machnięciem. Tylko to wg założeń ciągły proces.

I może to jest problem z wdrożeniem Scruma, że firmy mają mental waterfallowy i wrzucają Scruma jako plaster na ranę. Albo jako foremkę, do której będą nalewać Waterfall co każdy sprint.

LukeJL napisał(a):

Jak ktoś tak wdraża Scruma, to nie jest to prawdziwy Scrum XD

No ja wiem, że można założyć, że Scrum działa, a jak nie działa, to nie jest prawdziwy, bo prawdziwy działa. wiec nie działanie nieprawdziwego scruma jest z automatu dowodem na działanie tego prawdziwego scruma. Coś jak z Tomaszem z Akwinu i jego dowodami na istnieni Boga :)

Ja wiem, że to jest ulubione powiedzonko scrumistów, ale jednak takie podejście - dokonamy zmiany i będzie fajnie - pachnie waterfallem. Scrum zakłada iteracyjność (co zbliża go do programowania zwinnego), więc nie da się go tak wdrożyć po prostu jednym machnięciem. Tylko to wg założeń ciągły proces.

I może to jest problem z wdrożeniem Scruma, że firmy mają mental waterfallowy i wrzucają Scruma jako plaster na ranę. Albo jako foremkę, do której będą nalewać Waterfall co każdy sprint.

Moja skromna opinia jest taka, że inżynieria oprogramowania wciąż jest na etapie pionierskim i posiadanie ogarniętego zespołu jest ważniejsze od posiadania dobrej metodyki pracy. To nie znaczy, że wszystko co proponuje agile, scrum jest złe, ale wciąż jest to nieprodukcyjne. Moim zdaniem, czerpanie z doświadczeń produkcji masowej jest nieco bez sensu, bo programowanie przypomina bardziej projektowanie samochodu, niż jego produkcję i jeżeli mamy brać jakieś wzorce z innych dziedzin inżynierii, to niech one chociaż będą trochę adekwatne.

Fistandantilus napisał(a):

Natomiast zobacz - o ile założenia Agile są górnolotne, ogólnikowe i w sumie ok, tak już to kto ma za to odpowiadać to już polityka i walka na słowa, obietnice, uzasadnienia, mniej lub bardziej mętne.

Opisuję po prostu doświadczenia. Tych dobrych po co opisywać, jak coś działa to z tego się konsultuje:)

Jak pisałem, nie warto polegać na doświadczeniach z patologicznych miejsc. Nawet jeśli 100% doświadczeń masz z takich, nie oznacza to, że są jakąś normą. Co najwyżej oznacza to, że masz pecha.
A nikt nie lubi pracować z pechowcami.

LukeJL napisał(a):

I może to jest problem z wdrożeniem Scruma, że firmy mają mental waterfallowy i wrzucają Scruma jako plaster na ranę. Albo jako foremkę, do której będą nalewać Waterfall co każdy sprint.

Dokładnie tak jest. Dodaj do tego jeszcze jakichś zakompleksionych managerów ze skłonnościami do mikromanagementu, i masz przepis na patologię.
A programiści zamiast zastanowić się, co jest nie tak z tą firmą, żeby następnym razem wybrać lepiej, zakładają, że całe zło jest przez scruma, a ze scrum jest wszędzie, to wszędzie jest źle.

@LukeJL:

I może to jest problem z wdrożeniem Scruma, że firmy mają mental waterfallowy

Mental waterfallowy w sensie że wszystko skrupulatnie projektują i mają pełną dokumentację? xD

Krolik napisał(a):

@LukeJL:

I może to jest problem z wdrożeniem Scruma, że firmy mają mental waterfallowy

Mental waterfallowy w sensie że wszystko skrupulatnie projektują i mają pełną dokumentację? xD

Raczej, że planują na 5 lat do przodu, i nie wprowadzają zmian w planie, mimo że od razu widać, że to nie będzie działać.

somekind napisał(a):

Krolik napisał(a):

Mental waterfallowy w sensie że wszystko skrupulatnie projektują i mają pełną dokumentację? xD

Raczej, że planują na 5 lat do przodu, i nie wprowadzają zmian w planie, mimo że od razu widać, że to nie będzie działać.

Przecież to nie jest waterfall. W waterfallu, takim jak go przedstawiono w pewnym artykule z okolic 1970 r., właśnie po to projektujesz i planujesz aby od razu było widać że coś nie będzie działać zanim wtopisz 5 lat na implementację. Bo znalezienie i poprawienie błędu na etapie projektowania jest tańsze niż na późniejszych etapach. To właśnie w scrumie masz ten problem ze możesz zapędzić się w kozi róg i nagle okazuje się że twoje 100k linii napisanych w poprzednich sprintach nadaje się do przepisania.

Poza tym w waterfallu masz sprzężenie wsteczne między fazami - jeśli w kolejnym etapie wyjdzie że był błąd w poprzednim, to się proces cofa i poprawia poprzedni etap. Np. jeśli podczas implementacji okaże się że projekt zawiera błędy i coś nie będzie działać to się poprawia projekt. A jeśli w testach wyjdą błędy implementacji to się poprawia implementację.

Ponadto nigdzie nie jest powiedziane że waterfall masz stosować do absolutnej całości systemu / tudzież jego ostatecznej wersji. W waterfallu realnie robi się iteracje i wiedziano o tym w latach 1970 więc zadziwiające że propagatorzy scruma i agile tak bardzo o tym zapomnieli.

Edit: waterfall w zarządzaniu projektami informatycznymi wprowadził Royce w artykule z 1970. Poprawiłem rok.

Krolik napisał(a):

Poza tym w waterfallu masz sprzężenie wsteczne między fazami - jeśli w kolejnym etapie wyjdzie że był błąd w poprzednim, to się proces cofa i poprawia poprzedni etap. Np. jeśli podczas implementacji okaże się że projekt zawiera błędy i coś nie będzie działać to się poprawia projekt. A jeśli w testach wyjdą błędy implementacji to się poprawia implementację.

Nawet zaplanowana i zrealizowana apka może się nie udać, bo może być toporna w użyciu albo nikt nie będzie używać danych funkcji. USOS jest przykładem takiej aplikacji, która działa, ale której prawie nikt nie potrafi dobrze obsługiwać, ani studenci ani wykładowcy. Albo Lotnisko w Radomiu. Zrobili? Zrobili. Tylko że niepotrzebnie.

Szeroko pojęte podejście zwinne to też iteracja w designie, testowanie pod kątem UX i czy w ogóle ludzie potrzebują danych funkcji, a potem w razie czego modyfikacja planów.

somekind napisał(a):

Krolik napisał(a):

Mental waterfallowy w sensie że wszystko skrupulatnie projektują i mają pełną dokumentację? xD

Raczej, że planują na 5 lat do przodu, i nie wprowadzają zmian w planie, mimo że od razu widać, że to nie będzie działać.

Dokładnie. Jeśli backlog ma już zaplanowane na miesiące roboty taski, jak ma apka wyglądać, bo sobie designerzy tak wymyślili, a programiści mają po prostu pobierać taski z backloga co sprint? Można sobie nazywać to scrumem, ale to po prostu waterfall opakowany w sprinty i różne ceremonie.

BTW tu fajnie gościu o tym gada

LukeJL napisał(a):

BTW tu fajnie gościu o tym gada

To chyba jeden z lepszych filmów jakie widziałem.

Nawet zaplanowana i zrealizowana apka może się nie udać, bo może być toporna w użyciu albo nikt nie będzie używać danych funkcji.

W każdej metodyce projektowej apka może się nie udać. Jednak większe prawdopodobieństwo jest że się nie uda jak się od razu wszyscy rzucą do implementacji z pominięciem etapu analizy wymagań i projektowania. Zbudowanie aplikacji jest kosztowniejsze niż projektowanie czy prototypowanie, więc lepiej jak najwięcej wątpliwości usunąć na tych wczesnych etapach. W ogóle po to w inżynierii stosuje się projekty aby zmniejszyć ryzyko że coś pójdzie nie tak podczas budowy czy użytkowania.

To że na etapie projektowania można również popełnić błędy to nie jest argument za tym aby nie projektować. Tak samo testy rzadko wyłapują 100% błędów w kodzie ale mimo to warto testować, prawda?

Krolik napisał(a):

Zbudowanie aplikacji jest kosztowniejsze niż projektowanie czy prototypowanie, więc lepiej jak najwięcej wątpliwości usunąć na tych wczesnych etapach.

No, nie do końca się z tym zgadzam.

Samo budowanie apki nie jest w gruncie rzeczy tak bardzo kosztowne. Wiem, że to brzmi kontrowersyjnie, więc pozwólcie wytłumaczyć.

Kiedy przychodzimy do pracy, i słyszymy wymagania klienta, i mamy napisać mu aplikację, to to faktycznie jest bardzo kosztowne, i długotrwałe - ale nie przez sam proces programowania i wytwarzania apki; ale przez dogadywanie tej aplikacji z klientami, i przez właśnie jej projektowanie. Jeśli mielibyśmy perfekcyjną wiedzę na temat tego, jak aplikacja ma wyglądać, napisalibyśmy ją w 5% czasu. Tylko problem jest taki że nigdy nie mamy perfekcyjnej wiedzy nt tej aplikacji, requirementy od klienta, chocćby nie wiem jak dokładne, nigdy nie są wystarczająco dobre, poza klienci też ciągle zmieniają zdanie, wizja tej apki ciągle się zmienia.

Więc to nie programowanie aplikacji jest kosztowne, tak na prawdę. Kosztowne, jest dogadywanie z klientem/PO co ta apka ma robić tak na prawdę, a to z kolei można robić tylko pokazując mu coś (bo jak mu powiesz to tego nie skuma), więc musisz budować coraz to (właściwie) kolejne, nowe apki, co chwila je zmieniając, żeby klient mógł na to patrzeć i prowadzić nas w jakąś stronę, aż w końcu w wersji powiedzmy 1.4.242 powie "dobra, mamy to". Gdybyśmy od początku wiedzieli jakie wymagania ma wersja 1.4.242, to napisalibyśmy ją pewnie w pare tygodni zamiast lat.

Dokładnie za tym polega metodyka "Revamp" z Extreme Programming. Można np rozwijać jakąś bibliotekę przez 10 lat, (i na ten rozwój przypada oczywiście development, próby, testy, szukanie rozwiązań), i po tych 10 latach to jest całkowicie normalne żeby ją przepisać np w 3 miesiące - nie dlatego żę programowanie trwało 10 lat; tylko próba ustalenia tego jak ta biblioteka faktycznie ma wyglądać, była najbardziej kosztowna. Mamy teraz potężne general-purpose języki, więc to nie programowanie zajmuje tyle czasu, tylko właśnie dochodzenie do tego co my tak na prawdę tworzymy.

piotrpo napisał(a):

Problem w tym, że to jeszcze nie działa. To trochę nie działa również w przypadku samochodów, ale w przypadku software nie działa bardziej.

Czyli cały postęp w inżynierii oprogramowania sprowadza się w zasadzie do prostego zasypywania problemów za pomocą code-monkey? Trochę smutny obraz branży ale wyjaśnia wiele rzeczy :(

Krolik napisał(a):

Nawet zaplanowana i zrealizowana apka może się nie udać, bo może być toporna w użyciu albo nikt nie będzie używać danych funkcji.

W każdej metodyce projektowej apka może się nie udać. Jednak większe prawdopodobieństwo jest że się nie uda jak się od razu wszyscy rzucą do implementacji z pominięciem etapu analizy wymagań i projektowania.

To jest fałszywa dychotomia projektowanie -> implementacja vs. sama implementacja.
Przecież można etap projektowania robić iteracyjnie, wraz z postępem prac nad projektem.

Chociaż zgadzam się, że może to wyglądać trochę jak wszyscy rzucą do implementacji z pominięciem etapu analizy wymagań i projektowania..
Bo czasami faktycznie może to polegać na tym, że designerzy będą tworzyć na bieżąco nowe ficzery i każdego sprintu zalewać programistów ficzerami do zrobienia, a programista sobie będzie je implementować i nie będzie wiedział po co i co designerzy wymyślą w następnym sprincie, ważne żeby zakodzić bieżący task. I przy takim wykrzywionym podejściu zwinnym można zgubić kontekst i sens całego projektu (w zasadzie to już raczej iteracyjny waterfall).

Ale nie sądzę, żeby zaprojektowanie całej apki od A do Z na początku było rozwiązaniem. To są dwie skrajności:

• nie myślimy dalej niż bieżący sprint
• mamy zaplanowany cały projekt i wszystko rozpisane przed napisaniem linijki kodu

i obie skrajności mają wady:

• jak patrzymy tylko na najbliższy sprint, to robi się chaos i dryfowanie raz jedną, raz w drugą stronę (dodajmy do tego potrzebę komunikacji z designerami, bo jeśli ci nie mówią wszystkiego programistom, to programiści nie mogą zaprojektować dobrze czegoś w kodzie).
• jak wszystko jest ustalone, to wtedy ciężko coś zmienić, jeśli coś jest zaprojektowane bez sensu. Aplikacja staje się przestarzała już w momencie robienia.

Myślę więc, że należy sięgać wzrokiem poza horyzont i coś planować, robić prototypy wcześniej, propozycje designu. Programiści powinni robić PoC zanim zrobią coś produkcyjnie. Ale też nie warto projektować wszystkiego na sztywno, tylko lepiej traktować pierwotne plany jako zamysł niż zobowiązanie (szczególnie, że jak ktoś od razu się rzuca do projektowania wszystkiego od a do z, to taki pierwszy projekt zwykle jest "z d**y")

Teraz mi @LukeJL przypomniał jak @Sławomir Sobótka kiedyś mówił:

• Wiemy wszystko -> należy brać waterfall
• Wiemy czego nie wiemy -> należy brać "metodyki lekkie" thin lean (nie wiem co to, pewnie chciał szkolenie z tego sprzedać :P )
• Nie wiemy czego nie wiemy -> należy "Scruma" (chociaż wzasadzie chodziło mu o demo z prawdziwym klientem gdzie klient rozjaśnia co wiemy a co nie wiemy)

BTW sam pracuję w jeszcze innej sytuacji gdzie X klientów zgłasza swoje pomysły na feature i w zalezności od budżetów danych klientów to implementujemy. Ale o budżetach ani priorytetach nie mówią mi za dużo z wyprzedzeniem. Zresztą jestem teraz tak zawalony robotą i obecnymi zadaniami że jakie dalekosiężne plany mało mnie interesują

@LukeJL: Co masz na myśli pisząc PoC? Pytam, bo w "biznesowych" aplikacjach nie ma za dużo rzeczy, które trzeba koniecznie udowodnić, zanim przeznaczy się kasę na tę mityczną implementację. Jak klient ma dostać formularz przez www, wprowadzić do tego formularza dane, następnie te dane mają zostać przesłane przez jakiegoś ~resta i utrwalone po stronie serwera, to nie bardzo jest co tutaj dowodzić.

Zaskakująco obie strony (@Krolik i ci podchodzący z drugiej strony) mają trochę racji, bo czym innym jest:

• Zmiana kolorów na stronie koszyka, wdrożenie tej stronki i zebranie feedbacku (easy, fast feedback loop)

• Zmiana kolorów w aplikacji desktopowej, przygotowanie strategii wdrożenia (poinformowanie userów lub w skrajnych przypadkach potrzeba zainstalowania im) i zebranie feedbacku (medium complexity, medium feedback loop)

• Zmiany w kodzie związanym mocno z danym sprzętem gdzieś na jakiejś hali bez dostępu do internetu, przygotowanie + zrealizowanie wdrożenia i zebranie feedbacku (high complexity, slow feedback loop)

W każdym przypadku zmiany w kodzie mogą trwać 10min, jednakże cały proces software development lifecycle może znacząco się różnić czasowo/kosztowo na danych etapach.

Krolik napisał(a):

Przecież to nie jest waterfall. W waterfallu, takim jak go przedstawiono w pewnym artykule z okolic 1970 r., właśnie po to projektujesz i planujesz aby od razu było widać że coś nie będzie działać zanim wtopisz 5 lat na implementację. Bo znalezienie i poprawienie błędu na etapie projektowania jest tańsze niż na późniejszych etapach.

Tak, w świecie idealnie doskonałych projektantów zbierających doskonale precyzyjne wymagania od idealnie rozgarniętych klientów... to i tak by nie działało, bo po 5 lat cały genialny projekt może być już zbędny przez zmiany w prawie, koniunkturze albo po prostu będzie tak odstawał wyglądem od standardu na rynku, że nikt nie będzie chciał tego używać.

To właśnie w scrumie masz ten problem ze możesz zapędzić się w kozi róg i nagle okazuje się że twoje 100k linii napisanych w poprzednich sprintach nadaje się do przepisania.

Jak mogę się zapędzić, skoro po 1-3 tygodniach widać, czy się nie zbłądziło, więc co najwyżej tyle pracy można stracić?

Krolik napisał(a):

W ogóle po to w inżynierii stosuje się projekty aby zmniejszyć ryzyko że coś pójdzie nie tak podczas budowy czy użytkowania.

Tak, w inżynierii.
IT to nie jest inżynieria. Może za kilkadziesiąt lat będzie, jak ludzie wyrosną z etapu stosowania jednego narzędzia do wszystkich problemów, i związanej z tym tej ciągłej huśtawki, w której najpierw się technologię kocha i źle używa, a potem nienawidzi winiąc za fiasko przedsięwzięcia.