Agile / Scrum - początek

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.

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.

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.

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 :)

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

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.

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.

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.

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.

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