Agile / Scrum - początek

0

Siema, każdy tak ostatnio zachwyca się, jaki ten agile jest świetny i w ogóle. A ja mam inne pytanie. Jak to wygląda w praktyce. Tzn. zaczynając od początku. Sprinty powinny być krótkie - tydzień do miesiąca. Ale zaczynając nowy system, rzadko kiedy jest szansa, że nawet w miesiąc stworzy się jakąś działającą wersję. Jak to powinno wyglądać?

1

Nie tworzy się całego systemu na raz, tylko dzieli na zadania, a tych w miesiąc już można trochę napisać. Przynajmniej tyle, by jakąś pierwszą wersję jakiegoś ekranu pokazać użytkownikowi.

A zachwycają się wielbiciele buzzwordów i management, nikt inny.

0

Zależy co robisz. Jeśli system bankowy to może być ciężko.
Ale idealnie by było, żeby oddawać coś po tygodniu. Jak napisano wyżej - podzielić na kawałki i oddawać kawałki.
To już abstrahując od Agile - klient zawsze lepiej patrzy na produkt który może używać już po tygodniu.

Agile to nie jest coś ostatnio modnego. Ta koncepcja ma już 16 lat! Prawie tyle co C#.

To jaki jest najmojszy Agile to już inna rzecz. Może być taki że "wrzućmy kod na svn i zobaczmy ile testów się wysypie", może być taki że klientowi oddajemy co x dni kolejne funkcjonalności (działające). Ja jestem bardziej za tą drugą koncepcją, niezależnie jak to się nazwie.

0

Ja również się zachwycam Agilem :)
Celem sprintu wcale nie musi być działająca aplikacja którą można komuś pokazać.

Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P

0

Czyli wystarczy, jak np. po tygodniu pokażę klientowi jakieś okienko np. do wprowadzania danych? Ale faktycznie to będzie tylko samo gui bez warstwy biznesowej ani danych?

1

Jak to już zauważono - Agile != Scrum.

Samo słowo Agile oznacza metodyki lekkie, tj. takie które kładą nacisk na iteracyjność procesu wytwórczego i minimalizację okładu na komunikację. Co samo w sobie jest całkiem OK.

Problemy się zaczynają gdy dojdziesz do Scruma i jego korporacyjnych mutacji. Jeśli o mnie chodzi to jedyną zaletą Scruma jest daily. Cała reszta, czyli bzdety w stylu "cały zespół jest odpowiedzialny za całość", "samoorganizacja zespołu", "Scrum master to nie PM" itp. to korporacyjne hasełka, które bardziej przeszkadzają niż pomagają.

0

OK, to w takim razie jak to jest z tym scrumem?

3
neves napisał(a):

Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P

Nie programistów tylko managerów, scrum masterów, agile coachy i innych tasiemców. Oraz oczywiście klientów, bo jak ktoś im rzuci hasło, że wszystko trzeba robić "agile", bo to rozwiąże problemy z nieudanymi projektami, to wszyscy w to wierzą. W efekcie jest wzajemnie nakręcająca się spirala głupoty, na której zarabiają jedynie firmy szkoleniowe.

Programiści są agile sami z siebie i nie potrzebują do tego żadnych korporacyjnych procesów ani nadzorców.

Juhas napisał(a):

Czyli wystarczy, jak np. po tygodniu pokażę klientowi jakieś okienko np. do wprowadzania danych? Ale faktycznie to będzie tylko samo gui bez warstwy biznesowej ani danych?

W ekstremalnym przypadku, jeśli nie wyrobisz się z ukończeniem całości, to będzie musiało wystarczyć
Ogólnie chodzi o to, żeby nie zamykać się z projektem na 5 lat, a po tym czasie pokazać klientowi gotowe coś, co w ogóle nie jest zgodne z jego zamysłem. Agile ma na celu ciągłą współpracę z klientem, zbieranie jego opinii (dlatego często trzeba coś dostarczać, żeby móc tą opinię zwrotną dostać) i poprawianie softu na bieżąco.
Tylko, że agile jest jak komunizm - teoretyczna utopia, która w praktyce nie ma prawa działać. Po pierwsze dlatego, że nie jest to zgodne ze sposobem pracy waterfallowych klientów obarczonych ciężką biurokracją, a po drugie dlatego, że firmy programistyczne, które zamiast dobrać narzędzia do projektu, dopasowują projekt do narzędzi sprawiają, że żadnej zwinności w tym nie ma.

0
somekind napisał(a):
neves napisał(a):

Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P

Nie programistów tylko managerów, scrum masterów, agile coachy i innych tasiemców. Oraz oczywiście klientów, bo jak ktoś im rzuci hasło, że wszystko trzeba robić "agile", bo to rozwiąże problemy z nieudanymi projektami, to wszyscy w to wierzą. W efekcie jest wzajemnie nakręcająca się spirala głupoty, na której zarabiają jedynie firmy szkoleniowe.

Programiści są agile sami z siebie i nie potrzebują do tego żadnych korporacyjnych procesów ani nadzorców.

I to jest właśnie przykład ignorancji osoby która utożsamia Agile wyłącznie z zarządzaniem procesem wytwarzania oprogramowania jakim jest chociażby scrum.

Agile powstał jako odpowiedź na największy problem wytwarzania oprogramowania w modelu kaskadowym : zmiany. Agile akceptuje to że "zmiana" jest nieodłącznym elementem w świecie IT i wysuwa ją na pierwszy plan, oferując wiele różnych rzeczy które mają tę idee wzmocnić.

Jednymi z tych rzeczy są rozmaite praktyki programistyczne, które zostały swego czasu przez Becka zebrane i nazwane jako "programowanie ekstremalne", a których zbiegiem czasu pojawiło się coraz więcej. Więc to że teraz w naszej codziennej pracy piszemy testy jednostkowe, programujemy w parach, mamy ciągłe integracje i wiele innych rzeczy to zasługa właśnie popularyzacji idei Agile. Więc jak najbardziej my programiści czerpiemy z tej idei pełnymi garściami!

Scrum natomiast jest jedynie szczegółem implantacyjnym Agilu w odniesieniu do zarządzania procesem wytwarzania oprogramowania. I, tak, głównie, dotyczy mangmentu, ale proces wytwarzania oprogramowania to gra zespołowa, w której bierze udział znacznie więcej osób niż tylko programiści.

1

Jest takie powiedzenie - w teorii teria działa. Podbnie jest z Agile/Scrum/XP... W teorii wszystko fajnie. W praktyce sprowadza sie to czesto do DDD - Demo Driven Development, czy SDD - Stand Up Driven Development, czyli myslenie dlugoterminonowe zostaje poswiecone po to by miec szybka, widoczna zmiane. Co z tego ze kosztem jakosci?

Chociaz z punktu widzenia klienta jest to czesto dobre bo moze szybko modyfikowac system. Sa modele biznesowe gdzie wystarczy ze system z grubsza dziala, jesli 95% przypadkow jest ok, to zamiast naprawiac pozostale 5 czassami bardziej sie oplaci dolozyc cos co zwiekszy dochod. Do tego kontakt bezposrednio z klientem pomimo ze potrafi byc stresujacy, dziala dobrze na zrozumienie tego co jest dla klienta wazna i co tak naprawde jest potrzebne. Dla managementu tez jest dobre ze szybko widac jak ktos slabo pracuje.

A dolozmy do tego jeszcze AgileFalla (Agile nalozony na waterfalla, czyli pracujemy w waterfallu tyle ze zamiast rozliczac sie co milestone robimy to codziennie/co tydzien i mamy czestsze wrzutki bo w koncu Agile jest po to bysmy byli dynamiczni).

Testy automatyczne, CI itp. Super. Tylko jest sporo projektow gdzie tego nie ma i nie bedzie (bo trzeba by bylo charytatywnie po nocach siedziec).

A juz w ogole koszmarem jest robienie testow integracyjnych dla kilkunastu zespolow agilowych (zwlaszcza majac AgileFalla). Sporo ludzi uwaza ze w Agile dokumentacja jest opcjonalana...

Prawda jest to co @somekind napisal. Jak jest dobry zmotywowany zespol to sie sam zorganizuje, komunikacja bedzie dzialac projekt pojdzie do przodu. Nie trzeba ani biczownika do poganiania ani niczego narzucac.

Oczywiscie podbno istnieje gdzies mityczny, dzialajacy idealny Agile... Ale to co sie spotyka bardziej przypomina mi Frankensteina.

3
neves napisał(a):

I to jest właśnie przykład ignorancji osoby która utożsamia Agile wyłącznie z zarządzaniem procesem wytwarzania oprogramowania jakim jest chociażby scrum.

:D
To nie ja utożsamiam agile z procesami i nie ja ograniczam agile do scruma tylko ci ludzie, których wymieniłem w poprzednim poście.

Ignorancją jest myślenie, że hierarchiczne korporacje potrafią przyjąć takie podejście do działania, że potrafią pozbyć się procesów i biurokracji na której stoją, że odejdą spotkania, których celem jest wypalenie iluś godzin, ustalenie terminu następnego spotkania i opracowanie raportu, do którego nikt potem nie zajrzy.

Więc to że teraz w naszej codziennej pracy piszemy testy jednostkowe, programujemy w parach, mamy ciągłe integracje i wiele innych rzeczy to zasługa właśnie popularyzacji idei Agile.

A w praktyce - na pisanie testów nie ma czasu (może by były, gdyby nie ciągłe spotkania) a na programowanie w parach nie ma czasu, bo estymacje tego nie uwzględniały.

Więc jak najbardziej my programiści czerpiemy z tej idei pełnymi garściami!

Rozsądni programiści po prostu używają narzędzi, nie dorabiają do tego idei.

P.S. U jednego z poprzednich pracodawców zaczęliśmy kiedyś nowy projekt z klientem, którym była ogromna globalną korporacja z branży naciągania ludzi. Po tygodniu klient nas odrzucił, bo na wideokonferencjach nie byliśmy w garniturach.

0

Uncle Bob powiedział, że Agile w swoim założeniu był ok i słuszny ale to jak przyjęli to ludzie, biznes, firmy itp. to powiedział, że okazało się... Failem.

1

Chyba nie Uncle Bob... Z jego postów wynika, że on w ogóle nie zdaje sobie sprawy z tego, jak "agile" wygląda w praktyce i broni go jak zakonnica dziewictwa.

0

Też wątpię by takie coś powiedział, bo Agile to jego drugie ukochane dziecko, najbardziej natomiast kocha TDD.

Swoja drogą to straszni z was pesymiści, nie wszystkie projekty w Polsce to jakiś smutny outsourcing, w którym terminy grają większą role niż jakość, a menagment nie ma większego pojecia o wytwarzaniu oprogramowaniu - w takowych warunkach wszystko jest skazane na porażkę.

No ale skoro już Agile to takie zło, no to polecam obejrzeć chyba najsławniejszy hejt na Scruma:
https://vimeo.com/110554082
w wykonaniu Erik Meijer'a - One Hacker Way :)

0
neves napisał(a):

Agile powstał jako odpowiedź na największy problem wytwarzania oprogramowania w modelu kaskadowym : zmiany.

To nie zmiana jest problemem przy wytwarzaniu oprogramowania. Problemem jest to, że w obecnym modelu dostarczania oprogramowania rzeczy, które powinny się odbywać jako procesy odbywają się jako projekty. A dzieje się tak dlatego, że obecni ludzie zarządzający firmami szkolili się zarządzania w czasach, kiedy uważano "The Principles of Scientific Management" jako wartościową i pouczającą pozycję.

Agile akceptuje to że "zmiana" jest nieodłącznym elementem w świecie IT

Tautologia. Każdy projekt z założenia ma coś zmienić. A jeżeli chodzi o zmiany zakresu projektu - to nie "w świecie IT", tylko "przy aplikacjach enterprise, i w dodatku takich które nie są krytyczne".

i wysuwa ją na pierwszy plan, oferując wiele różnych rzeczy które mają tę idee wzmocnić.

Nie. Agile po prostu dzieli duży projekt na mniejsze projekty (zwane iteracjami) i minimalizuje okład na start i koniec każdego małego podprojektu. Przy czym taka iteracja nie jest w żaden sposób bardziej przyjazna zmianom niż projekt zarządzany np. waterfallem. Różnica jest tylko taka, że te projekty są mniejsze wobec czego potencjalna zmiana nie musi psuć wszystkich następnych iteracji.

neves napisał(a):

Swoja drogą to straszni z was pesymiści, nie wszystkie projekty w Polsce to jakiś smutny outsourcing, w którym terminy grają większą role niż jakość, a menagment nie ma większego pojecia o wytwarzaniu oprogramowaniu - w takowych warunkach wszystko jest skazane na porażkę.

No pewnie, że nie wszystkie. Ale przecież traktowanie jakości priorytetowo nie ma nic wspólnego z Agilem.

Problemem przy tworzeniu oprogramowania jest to, że wielu rzeczy nie da się zmierzyć - a jeśli czegoś nie da się zmierzyć to dla managementu nie istnieje. Ot chociażby czytelność kodu - w dużych systemach ma to ogromne znaczenie. Ale nie da się go zmierzyć, czytelność przecież jest czymś subiektywnym (analiza statyczna kodu nie ocenia czytelności). Kiedy ostatnio słyszałeś o dyrektorze działu, który powie PMowi "słuchaj, przypilnuj żeby ten kod dało się czytać"?

Tak samo nie da się zmierzyć wydajności programisty (przy czym programiści nie są wyjątkowi w tej kwestii - nie da się zmierzyć wydajności wielu innych zawodów). No bo jak to niby obiektywnie zmierzyć? Liczbą dostarczonych funkcjonalności (funkcjonalność funkcjonalności nierówna)? Zrealizowanych story-points w sprincie (szacunki w story pointach są też skrajnie subiektywne)? Z drugiej strony - pracując w zespole dosyć szybko orientujesz się, kto co potrafi.

I dokładnie ta niemierzalność jest tym, dlaczego wynajduje się coraz to inne praktyki zarządzania zespołami informatycznymi. Dlatego kiedyś trzeba było produkować stosy dokumentacji której i tak nikt nie czytał. Dlatego teraz nazywa się PMów "Scrum masterami".

1

Uncle Bob powiedział, że Agile w swoim założeniu był ok i słuszny ale to jak przyjęli to ludzie, biznes, firmy itp. to powiedział, że okazało się... Failem.

To jest przewijajacy sie motyw wsrod agileowcow: jak cos idzie zle z implementacja agile'a to nie jest winny agile tylko ludzie. Zalozenia agile'a sa dooooobre, tylko ludzie nie potrafia ich poprawnie zaimplementowac. Tak samo mozna mowic, ze C byl dobry w swoich zalozeniach to ludzie maja problemy np. z poprawnym zarzadzaniem pamiecia. Co nie zmienia faktu, ze jakby uzyc Javy zamiast C to 90% problemow z zarzadzaniem pamiecia by odpadlo.

0
wartek01 napisał(a):
neves napisał(a):

Agile akceptuje to że "zmiana" jest nieodłącznym elementem w świecie IT i wysuwa ją na pierwszy plan, oferując wiele różnych rzeczy które mają tę idee wzmocnić.

Tautologia. Każdy projekt z założenia ma coś zmienić. A jeżeli chodzi o zmiany zakresu projektu - to nie "w świecie IT", tylko "przy aplikacjach enterprise, i w dodatku takich które nie są krytyczne".
Nie. Agile po prostu dzieli duży projekt na mniejsze projekty (zwane iteracjami) i minimalizuje okład na start i koniec każdego małego podprojektu. Przy czym taka iteracja nie jest w żaden sposób bardziej przyjazna zmianom niż projekt zarządzany np. waterfallem. Różnica jest tylko taka, że te projekty są mniejsze wobec czego potencjalna zmiana nie musi psuć wszystkich następnych iteracji.

Użyłem bardzo ogólnego stwierdzenia, bo to właśnie nie jest "zmiana" tylko w zakresie projektu, czyli w wymaganiach (nie)funkcjonalanych.
W klasycznym waterfallu zanim przejdziesz do następnej fazy musisz zamknąć poprzednią fazę, a to oznacza że po fazie analizy wymagania są zamrożone i nie możesz ich już mienić do końca trwania iteracji, które w waterfallu zwykle są liczone w miesiącach, w Agilu mrożenie występuje jedynie na czas bardzo krótkich iteracji.
W klasycznym waterfallu poszczególne komponenty są integrowane dopiero pod koniec fazy implementacji, w Agilu masz ciągłą integracje.
W klasycznym waterfallu, możesz zacząć testowanie dopiero jak wszystkie poprzednie fazy masz skończone, w Agilu masz ciągłe testowanie.
W klasycznym waterfallu po zakończeniu fazy analizy, klient nie ma nic do powiedzenia, i po kilku miesiącach/latach dostaje zwykle nie to co chciał, w Agilu masz ciągłą współpracę z klientem.
W klasycznym waterfallu musisz mieć wszystko udokumentowane, w Agilu głównie działające oprogramowanie.
i tak dalej ....

Klasycznego waterfalla nie robi sie już od lat, wszystkie projekty obecnie, w mniejszym lub większym stopniu bazują na Agile.

wartek01 napisał(a):
neves napisał(a):

Swoja drogą to straszni z was pesymiści, nie wszystkie projekty w Polsce to jakiś smutny outsourcing, w którym terminy grają większą role niż jakość, a menagment nie ma większego pojecia o wytwarzaniu oprogramowaniu - w takowych warunkach wszystko jest skazane na porażkę.

No pewnie, że nie wszystkie. Ale przecież traktowanie jakości priorytetowo nie ma nic wspólnego z Agilem.

Oczywiście że ma, jest to uwzględnione w zasadach z manifestu agile : http://agilemanifesto.org/ i jeszcze bardziej podkreślone w manifeście softwarecraftsmanship http://manifesto.softwarecraftsmanship.org/.

wartek01 napisał(a):

Problemem przy tworzeniu oprogramowania jest to, że wielu rzeczy nie da się zmierzyć - a jeśli czegoś nie da się zmierzyć to dla managementu nie istnieje. Ot chociażby czytelność kodu - w dużych systemach ma to ogromne znaczenie. Ale nie da się go zmierzyć, czytelność przecież jest czymś subiektywnym (analiza statyczna kodu nie ocenia czytelności). Kiedy ostatnio słyszałeś o dyrektorze działu, który powie PMowi "słuchaj, przypilnuj żeby ten kod dało się czytać"?

Tak samo nie da się zmierzyć wydajności programisty (przy czym programiści nie są wyjątkowi w tej kwestii - nie da się zmierzyć wydajności wielu innych zawodów). No bo jak to niby obiektywnie zmierzyć? Liczbą dostarczonych funkcjonalności (funkcjonalność funkcjonalności nierówna)? Zrealizowanych story-points w sprincie (szacunki w story pointach są też skrajnie subiektywne)? Z drugiej strony - pracując w zespole dosyć szybko orientujesz się, kto co potrafi.

I dokładnie ta niemierzalność jest tym, dlaczego wynajduje się coraz to inne praktyki zarządzania zespołami informatycznymi. Dlatego kiedyś trzeba było produkować stosy dokumentacji której i tak nikt nie czytał. Dlatego teraz nazywa się PMów "Scrum masterami".

Cały ten akapit jest o Scrumie a nie o Agilu, w Scrumie podstawową jednostką jest samo organizujący się zespół, a nie indywidualny programista.
Indywidualny programista w Scrumie nie istnieje, zespół bierze odpowiedzialność i zespół jest rozliczany.
Zespół jest odpowiedzialny za organizacje pracy, jeśli dyrektor ma coś narzucać zespołowi w kwestiach tego jak pracuje to nie jest ani Scrum, ani Agile.
Story-pointy służą do oszacowania prędkości zespołu, żeby wiedzieć ile zabrać na następny sprint, do niczego więcej!
Jeśli porównujesz za pomocą nich indywidualnych programistów, czy różne zespoły to nie jest Scrum.
Jeśli Scrum master wykonuje obowiązki PM, to również nie jest Scrum.
To że już nie trzeba produkować stosów dokumentacji jest właśnie zasługą propagacji idei Agilu, gdyby nie Agile to ciągle by to trzeba było robić.

Jeszcze raz chce podkreślić że Agile czyli programowanie zwinne to coś znacznie więcej niż Scrum, Scrum to tylko maleńka cząstka Agilu, i z punktu widzenia nas programistów najmniej istotna. Praktyki Agilowe w różnym stopniu już dawno przeniknęły wszędzie, tyle że nie wszyscy zdają sobie sprawę że to właśnie pochodzi z Agilu, a Agile kojarzy się tylko z zarządzaniem zespołem i Scrumem.

0
neves napisał(a):

Użyłem bardzo ogólnego stwierdzenia(...)
i tak dalej ....

Część z tych stwierdzeń nie jest prawdą, ale to i tak nie ma znaczenia w dyskusji. Waterfall nie jest jedyną metodyką kaskadową, a Agile nie jest jedyną metodyką iteracyjną.

Oczywiście że ma, jest to uwzględnione w zasadach z manifestu agile : http://agilemanifesto.org/ i jeszcze bardziej podkreślone w manifeście softwarecraftsmanship http://manifesto.softwarecraftsmanship.org/.

Może źle się wyraziłem. Chodziło mi o to, że Agile ani nie był pierwszy, ani - jako metodyka - nie ma obecnie wyłączności w kładzeniu nacisku na jakość kodu.

Cały ten akapit jest o Scrumie a nie o Agilu

Nie. Wcześniej stwierdziłeś, że największym problemem w modelu kaskadowym są zmiany. To nie jest prawda, bo taki PRINCE2 ma też w specyfikacji akapit o zmianie. Tzw. programowanie zwinne nie ma też monopolu na iteracyjność procesu wytwórczego, model kaskadowy zakłada że fazy następują po sobie - ale też nie ma nic przeciwko temu, żeby któryś z cykli powtarzać wielokrotnie.

Ja z kolei twierdzę, że obecnie mamy ciągły nacisk ze strony managementu na kontrolę, co prowadzi do tworzenia sztywnych ram projektów i długi proces akceptacji zmian.

Praktyki Agilowe w różnym stopniu już dawno przeniknęły wszędzie,

Nie wiem, co rozumiesz przez "praktyki Agilowa" ale zalety komunikacji face-to-face czy też bezsensowność utrzymywania dokumentacji odkryto już w dwudziestym wieku i w wielu organizacjach były promowane długo przed manifestem wujka Boba (np. sławne "minutki" czy też równie sławne spotkania-tasiemce).

Mam dodatkowo jakieś takie wrażenie, że utożsamiasz praktyki z XP (unit testy, komunikacja klient-developer) z praktykami Agilowymi co jest takim samym błędem jak utożsamianie Agile'a ze Scrumem.

0
wartek01 napisał(a):
neves napisał(a):

Użyłem bardzo ogólnego stwierdzenia(...)
i tak dalej ....

Część z tych stwierdzeń nie jest prawdą, ale to i tak nie ma znaczenia w dyskusji. Waterfall nie jest jedyną metodyką kaskadową, a Agile nie jest jedyną metodyką iteracyjną.

Nie. Wcześniej stwierdziłeś, że największym problemem w modelu kaskadowym są zmiany. To nie jest prawda, bo taki PRINCE2 ma też w specyfikacji akapit o zmianie. Tzw. programowanie zwinne nie ma też monopolu na iteracyjność procesu wytwórczego, model kaskadowy zakłada że fazy następują po sobie - ale też nie ma nic przeciwko temu, żeby któryś z cykli powtarzać wielokrotnie.

Ja się odwołuje wyłącznie do klasycznego waterfalla w przykładach jako do ekstremum, gdzie jako drugie ekstremum przyjmuje Agile. Przez lata powstało mnóstwo metodyk które się znajdują pomiędzy tymi ekstremami. Moim jedynym celem jest nakreślenie że każda obecna metodyka jest w jakimś stopniu agile.

wartek01 napisał(a):
neves napisał(a):

Praktyki Agilowe w różnym stopniu już dawno przeniknęły wszędzie,

Nie wiem, co rozumiesz przez "praktyki Agilowa" ale zalety komunikacji face-to-face czy też bezsensowność utrzymywania dokumentacji odkryto już w dwudziestym wieku i w wielu organizacjach były promowane długo przed manifestem wujka Boba (np. sławne "minutki" czy też równie sławne spotkania-tasiemce).

Mam dodatkowo jakieś takie wrażenie, że utożsamiasz praktyki z XP (unit testy, komunikacja klient-developer) z praktykami Agilowymi co jest takim samym błędem jak utożsamianie Agile'a ze Scrumem.

Dokładnie, Agile to jest zbiór praktyk które funkcjonowały już od dawna I zostały zebrane przez Becka, Fowlera, Uncle Boba i innych, dostały nazwę i tyle, oni żadnych cudów nie stworzyli, pokazali tylko drogę którą uznają za najlepszą.
To jest dokładnie to samo co Gang of four zrobił z wzorcami projektowymi.

Praktyki z programowania ekstremalnego XP wchodzą w skład Agilu, tak jak i Scrum, co już wcześniej podkreślałem.

0

@somekind:
@neves

Uncle Bob tak powiedzial

Ale oczywiscie sporo programistow ma za duze ego, wiedza wszystko najlepiej, beda mi wmawiac, ze slyszalem co innego itp.

Poza tym przeczytajcie ze zrozumieniem.
Uncle Bob twierdzi, ze Agile byl potrzebny ale rowniez, ze nie zostal przyjety tak jak to widzial.

0
0x200x20 napisał(a):

Uncle Bob powiedział, że Agile w swoim założeniu był ok i słuszny ale to jak przyjęli to ludzie, biznes, firmy itp. to powiedział, że okazało się... Failem.

To jest przewijajacy sie motyw wsrod agileowcow: jak cos idzie zle z implementacja agile'a to nie jest winny agile tylko ludzie. Zalozenia agile'a sa dooooobre, tylko ludzie nie potrafia ich poprawnie zaimplementowac. Tak samo mozna mowic, ze C byl dobry w swoich zalozeniach to ludzie maja problemy np. z poprawnym zarzadzaniem pamiecia. Co nie zmienia faktu, ze jakby uzyc Javy zamiast C to 90% problemow z zarzadzaniem pamiecia by odpadlo.

A umiesz udowodnic, ze tak nie jest?
Tony wiedzy leza w ksiazkach niewykorzystanej albo zle wykorzystanej. Z agile powstal osobny biznes i robia to ludzie nietechniczni. Zawsze bedzie ten sam efekt gdy za zarzadzanie biora sie ludzie, ktorzy sie nie znaja na 'robocie'. Akurat zarzadzanie to syf niezaleznie od branzy.

Wiekszosc firm posiadajacych np. Magazyn now imlementuje zadnej metodologii pracy mimo, ze powstaly 30 lat temu.

Zawsze sa winni ludzie.

0

Zawsze sa winni ludzie.

Bo ja wiem czy zawsze? Komunizm ma bardzo szlachetne zalozenia, co nie zmienia faktu, ze nie da sie go poprawnie wprowadzic w zycie. Tutaj nie jest winny czlowiek tylko nierealistyczne idee.

0
0x200x20 napisał(a):

Zawsze sa winni ludzie.

Bo ja wiem czy zawsze? Komunizm ma bardzo szlachetne zalozenia, co nie zmienia faktu, ze nie da sie go poprawnie wprowadzic w zycie. Tutaj nie jest winny czlowiek tylko nierealistyczne idee.

Idee też wymyślają ludzie ;)

Nie jestem ani troche fanem Agile i mysle, że sporo idei było znanych już dawno temu.
Ja tam uważam, że sam pomysł być ok tylko jak Uncle Bob zauważa wymyślili to ludzie techniczni, a obecnie zajmują się tym głównie ludzie nietechniczni.
Jakby ludzie zachowali resztki zdrowego rozsądku to by się to nie posypało. Ale jak ktoś jedzie ze Scrum Guidem no to cóż...

Inna sprawa, że o ile doceniam początkowy wkład Uncle Boba to później mam wrażenie, że był brak pomysłów.

Inna sprawa coś takiego jak Clean Code. Wszyscy niby wiedzą... a z jakim kodem głównie pracujemy ? Głównie pewnie z niskiej jakości.
Podobnie TDD. Wszyscy niby stosują a później ze świecą szukać.

Więc tak, śmiem twierdzić, że nie dość, że idee w postaci jakie zostały spisane są nie do końca realne to jeszcze na dodatek zostało to do reszty wypaczone.

0

Widzialem tez agile'a w wersji "mam dosc programowania, wiec zostane agile coachem" i to wcale nie bylo lepsze od agile'a wprowadzanego przez ludzi nietechnicznych.

2

W prezentacji co wysłałem Uncle Bob zdaje sobie sprawe z problemu i sam mówi, że "nie wyszło" i teraz mamy mumbo jumbo ;)

Z tym, że to prowadzi do tego, że trzeba zrobić ... kolejne manifesto....

Dlatego warto też posłuchać kogoś kto wyleje na to wiadro zimnej wody... albo wiadro pomyj ;)

0
neves napisał(a):

Ja się odwołuje wyłącznie do klasycznego waterfalla w przykładach jako do ekstremum, gdzie jako drugie ekstremum przyjmuje Agile. Przez lata powstało mnóstwo metodyk które się znajdują pomiędzy tymi ekstremami. Moim jedynym celem jest nakreślenie że każda obecna metodyka jest w jakimś stopniu agile.

To twoim celem jest puste stwierdzenie. Równie dobrze można powiedzieć, że każda metodyka nie będąca "ekstremalnym" agilem jest w jakimś stopniu waterfallowa - i przecież nic z tego nie wynika.

Dokładnie, Agile to jest zbiór praktyk które funkcjonowały już od dawna I zostały zebrane przez Becka, Fowlera, Uncle Boba i innych, dostały nazwę i tyle, oni żadnych cudów nie stworzyli, pokazali tylko drogę którą uznają za najlepszą.
To jest dokładnie to samo co Gang of four zrobił z wzorcami projektowymi.

Praktyki z programowania ekstremalnego XP wchodzą w skład Agilu, tak jak i Scrum, co już wcześniej podkreślałem.

Tak, praktyki XP wchodzą w skład Agile'u, ale nie musisz mieć Agile'a żeby z nich korzystać. Korzyści wynikające z XP nie są zasługą Agile'a, więc nie możesz pisać, że "To że już nie trzeba produkować stosów dokumentacji jest właśnie zasługą propagacji idei Agilu, gdyby nie Agile to ciągle by to trzeba było robić.".

0
Chory Pomidor napisał(a):

@somekind:
@neves

Uncle Bob tak powiedzial

Ale oczywiscie sporo programistow ma za duze ego, wiedza wszystko najlepiej, beda mi wmawiac, ze slyszalem co innego itp.

Poza tym przeczytajcie ze zrozumieniem.
Uncle Bob twierdzi, ze Agile byl potrzebny ale rowniez, ze nie zostal przyjety tak jak to widzial.

Aleś wyrwał z kontekstu i zmanipulował jego wypowiedź :),
w prezentacji wyraźnie mówi że porażką nie jest Agile (110), tylko jedna z idei którą było przybliżenie biznesu do programistów, że to się nie udało, i że biznes jest głównym winowajcom.
W tym samie tonie wypowiada się równie Fowler jak i Greg Young na konferencjach.
A dalej ciągle twierdzi że Agile jest potrzebny i nawołuje do większej dyscypliny.

O tym wszystkim można przeczytać na jego blogu.

0
wartek01 napisał(a):
neves napisał(a):

Ja się odwołuje wyłącznie do klasycznego waterfalla w przykładach jako do ekstremum, gdzie jako drugie ekstremum przyjmuje Agile. Przez lata powstało mnóstwo metodyk które się znajdują pomiędzy tymi ekstremami. Moim jedynym celem jest nakreślenie że każda obecna metodyka jest w jakimś stopniu agile.

To twoim celem jest puste stwierdzenie. Równie dobrze można powiedzieć, że każda metodyka nie będąca "ekstremalnym" agilem jest w jakimś stopniu waterfallowa - i przecież nic z tego nie wynika.

Wręcz przeciwnie, wynika z tego że każda podejście obecnie to jest mieszanka waterfalla z agilem, że robienie agile to nie logika zero jedynkowa, że jest agila lub jego nie ma.

wartek01 napisał(a):
neves napisał(a):

Dokładnie, Agile to jest zbiór praktyk które funkcjonowały już od dawna I zostały zebrane przez Becka, Fowlera, Uncle Boba i innych, dostały nazwę i tyle, oni żadnych cudów nie stworzyli, pokazali tylko drogę którą uznają za najlepszą.
To jest dokładnie to samo co Gang of four zrobił z wzorcami projektowymi.

Praktyki z programowania ekstremalnego XP wchodzą w skład Agilu, tak jak i Scrum, co już wcześniej podkreślałem.

Tak, praktyki XP wchodzą w skład Agile'u, ale nie musisz mieć Agile'a żeby z nich korzystać. Korzyści wynikające z XP nie są zasługą Agile'a, więc nie możesz pisać, że "To że już nie trzeba produkować stosów dokumentacji jest właśnie zasługą propagacji idei Agilu, gdyby nie Agile to ciągle by to trzeba było robić.".

Tak jak wyżej, nie ma czegoś takiego jak mieć Agila, jak bierzesz jakieś praktyki identyfikowane z Agile, to w pewnym stopniu robisz Agile, tu nie ma żadnego progu po którego przekroczeniu masz Agile, ani dopóki go nie przekroczysz że go nie masz. Więc to jeszcze raz podkreślę że Agile to zbiór różnych rzeczy, a nie coś co można zaimplementować tylko w całości lub w ogóle.

2

Wręcz przeciwnie, wynika z tego że każda podejście obecnie to jest mieszanka waterfalla z agilem, że robienie agile to nie logika zero jedynkowa, że jest agila lub jego nie ma.

Agile Schroedingera. Jezeli projekt sie powiodl to byl agile. Jezeli projekt sie nie powiodl to na pewno nie byl to agile. Wczesniej nie mozna powiedziec :D

0

@neves:

Biały Mleczarz napisał(a):

Uncle Bob powiedział, że Agile w swoim założeniu był ok i słuszny ale to jak przyjęli to ludzie, biznes, firmy itp. to powiedział, że okazało się... Failem.

nie czuję, żebym cokolwiek przeinaczył.

1 użytkowników online, w tym zalogowanych: 0, gości: 1