(wady) Agile - Dyskusja

[Grzegorz Lipke]

Witam

Przyznam szczerzę, że czuje pewien niedosyst po ostatniej dyskusji na
temat agile (głównie SCRUM).
Postanowiłem ztem trochę rozwinąć temat moich zeszłowtorkowych
wypowiedzi w poniższym tekście. Ponieważ nie dorobiłem się jeszcze
własnego bloga zamieszczam go zatem na google docs'ach, a was
zapraszam serdecznie do lektury i dalszej dyskusji a ten temat.

http://docs.google.com/View?id=dd92h3f9_136f9t3pzgn

Agnieszko wybacz mi, że w taki nieładny sposób sprowadziłem dyskusje
na nieco inne tory :)

Pozdrawiam
Grzesiek
ten, dla którego to zależy od tłumaczenia ;)

[DanielMikucki]

Siemanko

Ciekawy artykuł. Myślę, że całkiem dobrze rzuca trochę świerzego
spojrzenia na podejście do Agile, bo jednak jakby nie patrzeć,
ostatnio istnieje moda na lekkie i zwinne metodyki, która jak to moda,
nie zawsze ma racjonalne uzasadnienie. Myślę, że istnieje również moda
na krytykowanie, tych którzy tę metodykę krytykują hehe. Fajnie, że Ci
się chciało coś takiego napisać Grześku.

Pozdrówka,

Daniel Mikucki

[Robert Sajdok]

2009/10/31 Grzegorz Lipke <grzegor...@gmail.com>

Witam

Przyznam szczerzę, że czuje pewien niedosyst po ostatniej dyskusji na
temat agile (głównie SCRUM).
Postanowiłem ztem trochę rozwinąć temat moich zeszłowtorkowych
wypowiedzi w poniższym tekście. Ponieważ nie dorobiłem się jeszcze
własnego bloga zamieszczam go zatem na google docs'ach, a was
zapraszam serdecznie do lektury i dalszej dyskusji a ten temat.

http://docs.google.com/View?id=dd92h3f9_136f9t3pzgn

Agnieszko wybacz mi, że w taki nieładny sposób sprowadziłem dyskusje
na nieco inne tory :)

Należy zastanowić się skąd wzięły się nowe metodyki tworzenia oprogramowania. Odpowiedź jest bardzo prosta, ponieważ dotychczasowe się nie sprawdzają na tyle, że szuka się innego podjeścia. Nie da się zaprojektować na papierze projektu na tyle dobrze, aby potem przesłać go do grupy programistów, którzy stworzą aplikację, którą wymyślił zleceniodawca. Dlatego Agile wygrywa. Problem z Agile jest jeden wycena projektu.

--
Robert Sajdok (Ris)

[Paweł Lipiński]

Grzesiek
Faktycznie dobrze, że napisałeś ten tekst, bo dotyka ok głównych
zarzutów stawianych zwinnym metodykom. Ważne jest, żeby poddawać
krytyce każdą myśl czy decyzję - inaczej nie mielibyśmy postępu i
osiedlibyśmy na mieliźnie rutyny i bylejakości. Choć akurat na
wymienione przez Ciebie zarzuty odpowiada prawie każdy artykuł w stylu
"common misconceptions about agile" :)

No to ja po kolei.
Wycena i konkurencja:
Ja zapytam odwrotnie: jak z pośród niezwinnych ofert wybrać tę
najlepszą? Zwykle decyduje cena, co oznacza, że wybieramy potencjalnie
oferenta posiadającego najtańszą siłę roboczą (tak tak, to znaczy
najbardziej niedoświadczonych programistów), a więc najprawdopodobniej
jest to najgorsza możliwa oferta. To oczywiście uproszczenie, ale
jednak myślę, że jest coś na rzeczy.
Z drugiej strony mylisz w tym paragrafie dwie rzeczy: zwinnie
prowadzone projekty i projekty fixed-price/fixed scope. Jedno to model
prowadzenia projektu, a drugie to model finansowania. Oczywiście ze
względu na iteracyjność i dawanie możliwości zmian w projekcie, model
coś-jednak-nie-fixed jest bardziej odpowiedni. Jednak również zwinnie
prowadzone projekty mogą mieć stałą cenę, czas i zakres. Kluczem do
tego jest właściwa wycena/oszacowania, co jeśli mamy szczegółową
specyfikację projektu nie jest w przypadku zwinnie prowadzonego
zespołu trudniejsze, tylko łatwiejsze. Nie zgadujemy, ile czasu zajmie
realizacja jakiejś funkcjonalności, tylko albo bazujemy na liczonej
wcześniej prędkości zespołu (jeśli zespoły są stałe między projektami,
nie jest to problem), albo na wycenach podobnych funkcjonalności w
innych projektach realizowanych przez podobne zespoły, co w przypadku
dobrze prowadzonych zwinnych projektów (z pełną estymacją i liczeniem
prędkości zespołu), też będzie zupełnie dobrym przybliżeniem. Zwinne
zespoły dokładnie mierzą swoją wydajność, więc łatwiej też dobrać
właściwy rozmiar zespołu, by zmieścić się w zadanym czasie.

Jak dużo osób może pracować w zwinnych projektach?
Nie wiem z kąd wziąłeś to 12. Pierwsze wydanie XP explained Kenta
Beck'a faktycznie mówiło o małych zespołach, ale już scrum nigdy nie
robił takich ograniczeń, a i po paru latach szerszych doświadczeń z XP
Beck zmienił zdanie.
Z tego co pamiętam, największy projekt prowadzony w Scrumie miał 600
osób. Ja brałem udział w projekcie gdzie było 35 programistów + parę
osób od wymagań + scrum masterzy, czyli ponad 40 w sumie. Jak
synchronizować pracę zespołów w takim projekcie to nie tylko temat na
dłuższy tekst, ale również kwestia doświadczenia. Tak czy siak jest to
dalej rozsądniejsze podejście niż dowolne nieiteracyjne.

Odpowiedzialność
Ja faktycznie jestem z tych, którzy twierdzą, że zwinne podejście jest
dobre w każdej sytuacji. Nie mówię, że scrum czy crystal, ale
generalnie podejścia bazujące na zwinnych wartościach i zasadach. I
projekty krytyczne dla życia ludzi nie są tu wyjątkiem. Zwinne
metodyki kładą maksymalny nacisk na odpowiedzialność poszczególnych
programistów i całych zespołów. Wystarczy poczytać trochę Kenta
Beck'a, Uncle Bob'a czy James'a Shore'a. Właśnie ze względu na naszą
odpowiedzialność za projekt dbamy bardzo szczegółowo o jakość kodu, o
ciągłe ustalania wymagań i weryfikację ich implementacji przez ciągłe
testy jednostkowe i akceptacyjne, statyczną analizę kodu, częstą
komunikację z biznesem, częste przeglądy aplikacji w czasie jej
rozwijania itp. Powiedziałbym nawet, że JEDYNYM powodem prowadzenia
projektów zwinnie jest chęć odpowiedzialnej ich realizacji,
odpowiedzialnego szacowania (a nie zgadywania czy nam się uda coś
kiedyś dostarczyć), odpowiedzialnego wykorzystywania pieniędzy klienta
(stąd np. dokumentacja tam, gdzie jest faktycznie potrzebna), itp.
Do tego dodam tylko, że największa chyba na świecie firma robiąca
oprogramowanie krytyczne dla życia - Siemens Medicals (czy jakkolwiek
to się nazywa) jest jednym ze sztandarowych przykładów wdrożeń Scrum'a
w dużych firmach. Z resztą mam tam dobrego znajomego, który jest tam
Product Ownerem, więc mogę potwierdzić, że faktycznie przynajmniej
część projektów jest prowadzonych tam Scrumem.

Świadomość oraz jakość zespołu
Tego to już nie rozumiem. Czy to znaczy, że chciałbyś mieć w
projekcie, od którego zależeć może czyjeś życie, albo nawet po prostu
zwykłej aplikacji webowej, za którąś KTOŚ PŁACI osoby niezaangażowane,
niezmotywowane i sfrustrowane? Ja nie chcę. Ja chcę, by w zespole
każdy czuł się dobrze - tylko wtedy można zapewnić jego dobrą pracę.
Więc tak, osoby, które nie chcą się zaangażować POWINNY opuścić
projekt. Czy są bezwartościowi? No jako osoby ludzkie to nie, ale jako
programiści w danym projekcie to pewnie tak. A nawet mogą przynosić
wartość ujemną, jeśli rozbijają pracę zespołu albo zaniżają jakość
(zaciągają długi, którzy inni muszą potem płacić).

W paru punktach poruszałeś kwestię dokumentacji - nikt nie mówi, że
mniej ją lubimy niż niezwinne zespoły, czy, że mniej się do niej
przykładamy. Tworzymy ją tam, gdzie jest niezbędna. W projekcie
medycznym, do elektrowni atomowej, czy samolotu to będzie co innego
niż do aplikacji webowej. Zwinność to elastyczność - dostosowujemy się
do projektu i wymagań (stąd druga nazwa tych metodyk - metodyki
adaptacyjne). Co więcej, jeśli mój klient będzie chciał jakąś
dokumentację, "bo tak" albo dlatego, że jest taka polityka, ISO, czy
cokolwiek innego, to oczywiście chętnie ją wykonam. Tyle, że nie na
początku, czy końcu projektu, jako oddzielna faza, ale będzie tworzona
ona na bieżąco, aby mogła na bieżąco przynosić wartość (np. służyć
weryfikacji poprawności czy wprowadzaniu nowych osób w projekt) i by
projekt był gotowy do wdrożenia (przynoszenia wartości jego
użytkownikom / mojemu klientowi) cały czas.

Myślę, że główny problem w akceptacji zwinnych metodyk to nie ich
nieodpowiedniość, ale założenie osób nowych w tym temacie, że wszystko
trzeba zawsze robić "by the book" - a to są przecież metodyki
adaptacyjne, dostosowywane do warunków projektu. Kent Beck powiedział
kiedyś coś takiego (cytat z pamięci): "jeśli po paru iteracjach dalej
robisz XP tak jak robiłeś to na początku, to nie robisz już XP". A Jim
Coplien (słyszałem na własne uszy): "jeśli zwinnego proces nie podlega
u Ciebie zmianom, to jak on jest zwinny?"

Ja więc nie wykażę się brakiem odwagi zwalając na zwinne metodyki, ale
stwierdzam, że ludzie i interakcje są ponad procesy (choćby zwinne) i
narzędzia, i że to oni kładą projekty podejmując złe decyzje i ślepo
postępując za wytycznymi z książki zamiast poddać je twórczej krytyce
takiej, jak Twoja :)

pozdrawiam przepraszając za długawy post
Paweł
--
www.pragmatists.pl
blog.pawellipinski.com

On 31 Paź, 23:51, Grzegorz Lipke <grzegorz.li...@gmail.com> wrote:

[Jakub Nabrdalik]

Dzięki Grzesiek za poruszenie tematu i dzięki Paweł za konkretną
odpowiedź. Mam jedną uwagę co do wycen i konkurencji:

Czy nie jest przypadkiem tak, że firma wybierająca wykonawce kieruje się
głównie doświadczeniami we współpracy z nim lub w przypadku braku
takowych, renomą na rynku i wykonanymi projektami? Mam dopiero 6 lat
doświadczenia, ale jak dotąd moje firmy wygrywały całą masę przetargów
gdzie wcale nie były najtańsze (fixed price zwykle). Pragmatists też
chyba wyrósł na dobrej współpracy Pawła z klientem a nie na najniższej
cenie.

Pozdrawiam,

Jakub Nabrdalik

[Paweł Lipiński]

To bardzo zależy. Jak firma ma dobre kontakty z dostawcą i jest z
niego zadowolona, to zmienianie go jest ponoszeniem niepotrzebnego
ryzyka (z resztą po co to robić?) Jeśli to robi, to dlatego, że nie
jest zadowolona (jakość, terminowość,ceny).

W przypadku przetargów to jednak często wygrywa najtańszy, bo albo
decyzję podejmuje np. Dział Zakupów (znam parę firm gdzie jest coś
takiego) albo jest podejmowana pod presją budżetu (kto zaoszczędzi
najwięcej ma najwyższą premię i takie tam) albo jest to przetarg
publiczny i nie wybranie najtańszego jest proszeniem się o komisję
śledczą do spraw nacisków przy podejmowaniu decyzji o realizacji
projektu :)

A Pragmatists "wygrało" projekt w przetargu, w którym brały udział z
tego co wiem 4 firmy (tak przynajmniej wciąż twierdzi nasz klient :))
Wszyscy oferenci byli <i>jakoś</i> znani i wybrany został oczywiście
najlepszy merytorycznie :) Co do cen to po prostu nie wiem. Z tego co
wiem, to że od samego początku chcieliśmy realizować projekt zwinnie,
oraz stawialiśmy na jakość i gwarancję jej wpisaliśmy w ofertę, miało
kluczowe znaczenie.

Paweł

[Agnieszka Orlewicz]

Cześć,
Ja również mam kilka pomysłów jak zaradzić tym całkiem słusznym zarzutom:

1. Wycena i konkurencja
Romawiałam wczoraj z Tatą, który zajmuje się budownictwem i przetergami budowlanymi, na które oferty
również są fixed-prize pomimo dużego zakresu, czasu realizacji. Budownictwo to dość dojrzała dziedzina i my z projektami informatycznmi
jesteśmy jeszcze na etapie piramid egipskich ... W każdym razie tam oferty mają dużo zmiennych zależnych od ceny materiałów,
siły roboczej i są całe katalogi określające normy, widełki cenowe. U nas pewnie też coś takiego się stosuje przy zakupie sprzętu/licencji
... ale może można by uzależnić projekt od jakości zatrudnianych programistów? Może kiedyś powstaną jakieś
normy oparte o doświadczenie, certyfikaty? Wtedy przynajmniej klient wiedziałby za co płaci, tak jak np za lepszą glazurę. Jako parametry można by też
zadać właśnie koszt  realizacji dodatkowych 'ficzerów' - i tu zgadzam się z Pawłem,
że SCRUM ułatwie oszasowanie ich średniego kosztu.

No i jeszcze jedno nawiązanie do budownictwa - inaczej wyceniamy domek
inaczej centrum hotelowo konferencyjne, więc przyda tu się jedna z czołowych zasad RUPa
'adapt the process'.

2. Odpowiedzialnośc
Myśle, że bardzo wartościowe w SRCUMie jest to, że produkuje tylko niezbędne dokumenty (liczy się jakość,
a nie ilość). Poza tym myśle, że dobra komunikacja z klientem, porządny  kod z komentarzami
oraz dodatkowy czas nie stracony na klepanie dokumentacji .... pozwoli może na opracowanie jakiś
automatów generujących dokumentację, aktualna i łatwą w utrzymaniu.

3 Wielkość zespołów
Zastanawiam się czy wyszło by coś takiego jak 'hierarchia scrumów'? Może ktoś próbował?

4.Świadomość oraz jakość zespołu
Nigdy nie pracowałam w SCRUMie, ale wyobrażam sobie, że zapewnia on fajną dynamikę pracy,
dającą okazję do dobrej komnikacji, wglądu w postępy ... i uczucia, że realizuje się jakieś cele a
nie jest się szarą korporacyjną mrówką. A to bardzo dobrze wpływa na świadomość, jakość, zaangażowanie
Poza tym retrospekcje to świetna okazja do przekazania informacji zwrotnej, a dzięki niej nawet ze złego programisty może być pożytek.

Pozdrawiam
Agnieszka

[Paweł Lipiński]

W sumie jak teraz przeczytałem to co napisałem, to sam się z tym nie
zgadzam ;) A dokładniej to wypowiedź była niepełna.

Nie jest tak, że uważam, że znanie i opinia o dostawcy nie ma
znaczenia - wręcz odwrotnie, na pewno ma, bo zmniejsza ryzyko
odbiorcy. I to w naszym przypadku na pewno miało znaczenie, że byłem
osobiście znany (a nawet explicite poproszony o pomoc w sprawie tego
projektu). To samo w przypadku Twoich firm Kuba, jeżeli wygrywały
przetargi, to pewnie właśnie ze względu na renomę. Natomiast nie
oszukujmy się, cena jest kluczowa. Klient po prostu wybierając
oferenta optymizuje (a przynajmniej stara się) stosunek ceny do
ryzyka.

Paweł

[Jakub Nabrdalik]

Paweł Lipiński pisze:

> Natomiast nie
> oszukujmy się, cena jest kluczowa. Klient po prostu wybierając
> oferenta optymizuje (a przynajmniej stara się) stosunek ceny do
> ryzyka.

Nawiązując do wypowiedzi Twojej i Agnieszki (z zakresu budownictwa) mogę
powiedzieć, że sam się kilka lat temu przekonałem, że minimalizowanie
ceny kosztem ryzyka jest strzelaniem sobie w stopę. Kupiłem mieszkanie u
developera który nie miał żadnych referencji/doświadczenia, ale był
najtańszy i do dziś dnia nie wiem czy warto je refactorować, czy trzeba
spisać na straty i zrobić od początku :D

A firmy w których o wszystkim decyduje "dział zakupów"... no cóż, tylko
im współczuć.

Jakub Nabrdalik

[Grzegorz Lipke]

Witam

Jeszcze raz dzięki za udział w dyskusji. Wiele z tego co napisaliście
rozjaśniło mi sytuacje przynajmniej teoretycznie :)
Liczyłem jeszcze na to, że ktos będzie miał odwage dorzucić jakies
wady od siebie, bo moje wynikaja tylko z kilkudniowych przemyśleń. Czy
znajdzie się ktos odważny ? :)

Pozdrawiam
Grzesiek

[Tomasz Łasica]

Hej,

trudno mi odnieść się krytycznie, bo jestem zwolennikiem lekkich
metodyk, ale przede wszystkim chciałbym zwrócić uwagę na fakt,
że miarą dobrego rzemieślnika jest m.in. umiejętność wybrania
odpowiednich narzędzi. Im więcej tych narzędzi zna i umie się nimi
posługiwać,
tym lepszy i trafniejszy będzie ów wybór. Tak samo jest z metodykami
zarządzania projektem, technologiami, językami itp.

Są zastosowania, w których SCRUM działa słabiej niż inne podejście.
Przykładowo: jeśli pracujemy w dziale utrzymania,
prawdopodobnie lepszy będzie KANBAN, bo tam liczy się dla nas przede
wszystkim jak najszybsze rozwiązywanie problemów "on site".

Osobiście napotkałem jeden koronny argument za tym, dlaczego wejście w
SCRUM się nie udaje (nie pamiętam autora),
otóż po prostu najczęściej jest on w nieprawidłowy sposób wprowadzany w
dodatku przez niekompetentne osoby.
Wydaje się to może niezbyt oczywiste - ale jest faktem.
Dowolna metodyka padnie w takiej sytuacji.

Trzeba pamiętać, że pracując w SCRUMIE cały czas można:
a) tworzyć wyczerpującą dokumentację (ortogonalne)
b) raportować "na zewnątrz" projektu w postaci Ganttów, MS PRojectów lub
innych wymysłów korporacyjnych (trochę więcej wysiłku)
c) szacować pracę w dowolny sposób
d) organizować swoje zespoły w dowolny sposób (np. ja mam ok. 50 osób i
nie robimy scrum of scrums tylko coś, co nazywamy "spacerem leadera" i
mamy w zespołach team leaderów, co się świetnie sprawdza - śmiem
twierdzić w oparciu o swoje doświadczenie, że taki zespół pracuje lepiej
- oczywiście zależy od tegoż lidera i tego jak zdefiniujemy jego rolę)
e) sprzedawać peojekty fixed price / fixed time
f) mieć umowę ale współpracować z klientem

Jako istotną wadę mogę podać ze swojego doświadczenia że faktycznie
niezwykle łatwo jest źle pracować w Scrumie.
Nie ma wtedy efektu a jest jakieś machanie karteczkami bez celu,
zawalenie dokumentacji, jakości, terminów a w rezultacie frustracja.

Obecnie wiodącym kierunkiem jest łączenie lekkich metodyk z PMI i
PRINCE2, zdaje się że nawet nowy PMI BOK coś tam na ten temat mówi.
I to chyba jest odpowiedź na duże, korporacyjne lub publiczne projekty:
z zewnątrz ciężko, w środku lekko. Zdecydowanie lepiej być w środku.

pozdrawiam
Tomek

PS. Naprawdę krótkie ćwiczenie czyni cuda. W przypadku scruma zazwyczaj
trening jest zdecydowanie bardziej efektywny niż w przypadku np. PRINCE2.


Grzegorz Lipke pisze:

[Adam Lider]

Witam,

On Nov 1, 2009, at 7:45 PM, Tomasz Łasica wrote:

...

Jako istotną  wadę mogę podać ze swojego doświadczenia że faktycznie
niezwykle łatwo jest źle pracować w Scrumie.
Nie ma wtedy efektu a jest jakieś machanie karteczkami bez celu,
zawalenie dokumentacji, jakości, terminów a w rezultacie frustracja.

..

Ciekawa cala wypowiedz Panie Tomaszu, ale szczegolnie ta czesc. W pelni sie z nia zgadzam. Jest to rodzaj paradoksu. Po kilku latach doswiadczenia z lekkimi metodykami jestem sceptycznie nastawiony do Scruma. Uwazam ze jest to metoda, ktora moze nawet wyrzadzic krzywde filozofii Agile. Wytwarzanie oprogramowania jest rzemioslem trudnym, wymagajacym wiedzy, doswiadczenia, a przede wszystkim dyscypliny. Aby dojsc do "mistrzostwa" trzeba po prostu duzo pracy. Natomiast Scrum jest czesto widziany jako rozwiazanie dla zespolow, ktore sobie nie radza. Niestety zdecydowana wiekszosc tych zespolow zbudowana jest z malo lub srednio doswiadczonych ludzi i Scrum moze im niewiele pomoc a nawet zaszkodzic, poprzez koncepcje samoorganizujacego sie zespolu. Jak ja moge wiedziec co jest dla mnie dobre skoro malo jeszcze doswiadczylem? Najczesciej nie wiem. Co wiecej wprowadzenie Scruma do takich zespolow wprowadza rodzaj sztucznego uporzadkowania, w ktorym czesto wieksza wage przewiazuje sie do pielegnacji Scruma niz projektu. Tam gdzie Scrum dziala to najczesniej zespoly zbudowane z bardzo dobrych ludzi, a Scrum jest tylko (bardzo waznym) smarem dla dobrego mechanizmu.Dla zespolow mniej doswiadczonych zdecydowanie bardziej polecam XP. Dla mnie glowna roznica w stosunku do Scruma to zdecyowanie wiekszy nacisk na czysto techniczne praktyki tj. TDD, No bugs, Done Done z podkresleniem, ze musisz stosowac wszystko i nie jutro, ale dzisiaj. Praktykowanie TDD nie jest latwe i wiekszosc mniej doswiadczoncyh zespolow pracujacych pod etykieta Scrum (lub bez) po prostu odklada w czasie zastosowanie tej (lub innych rownie wymagajacych) praktyki (w koncu sami sie organizujemy i skoro to dla nas trudne, mozemy to zaczac pozniej). Jak sie ma kiepskich rzemieslnikow to Scrum niewiele pomoze. To troche tak jak z nasza reprezentacja pilki noznej - czy wierzycie ze z super taktyka super trenera nasi kopacze zdobyliby puchar w 2012? Moze i zagraliby lepiej, a moze wrecz przeciwnie bo np. kluczem dla taktyki bylaby gra z pierwszej pilki, a to trzeba umiec.

Moj glowny zarzut dla tej metody to proba wmowienia, ze wytwarzanie oprogramowania moze byc efektywne i dosc latwe (ze Scrumem), z niedostateczny podkresleniem wagi rzemiosla zespolu i jego czlonkow.

- Adam

[Paweł Lipiński]

No cóż. XP opracował programista, Scrum opracował lekarz :)

Ja się absolutnie podpisuję wszystkim co mam z wypowiedzią Adama. Scrum wprowadzany jest bardzo często ze względu na to, że zespoły sobie nie radzą, a że jest modny i jest za nim machina organizacyjna (certyfikacje itp.), jest najprostszym wyborem. 

Z drugiej strony wszystkie szkolenia i prezentacje które widziałem/brałem udział/prowadziłem na temat Scrum'a mają część w której mówi się o praktykach rodem z XP, o jakości, o potrzebie coachingu (szczególnie na początku, ale potem z resztą też). Boję się tylko, że wrodzona w programistach pycha i pewność siebie kusi do powiedzenia sobie: "ja nie dam rady?" .

Poza tym jak firma wydała 4000zł na osobę na CSM, to oczekiwanie jest takie, że chłopaki-masterzy przyjdą po szkoleniu i świat stanie się różowy. I żadne dodatkowe wydatki w rodzaju trenera nie wchodzą często w rachubę.

Paweł

Wiadomość napisana przez Adam Lider w dniu 2009-11-02, o godz. 21:44:

[Jacek Laskowski]

2009/11/2 Adam Lider <adam....@googlemail.com>:

> Witam,
> On Nov 1, 2009, at 7:45 PM, Tomasz Łasica wrote:
> ...
>
> Jako istotną  wadę mogę podać ze swojego doświadczenia że faktycznie
> niezwykle łatwo jest źle pracować w Scrumie.
> Nie ma wtedy efektu a jest jakieś machanie karteczkami bez celu,
> zawalenie dokumentacji, jakości, terminów a w rezultacie frustracja.
>
> ..
> Ciekawa cala wypowiedz Panie Tomaszu, ale szczegolnie ta czesc. W pelni sie
> z nia zgadzam. Jest to rodzaj paradoksu.

Adam, tyś moim mistrzem Scruma teraz się stał :) Proszę o zezwolenie
na publikację całości na moim blogu. Oczywiście z całym należytym
wskazaniem na autora.

Ta wypowiedź dokładnie odpowiada mojemu poglądowi sprawy, tylko że
brakowało mi dotychczas słów/słuchaczy/cierpliwości, aby dobrze się
wyrazić. Scrum wymaga wiedzy, której młode zespoły zachłyśnięte
lekkimi metodykami nie mają, jeszcze. To, co napisałeś umieszczam jako
swój manifest poznającego Scruma (za pozwoleniem, jeśli można).

p.s. Bez urazy, ale Twoje nazwisko mówi samo za siebie i jedna
wypowiedź wystarczyła, abym nie miał złudzeń :)

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[Sławek Sóbotka]

Adam - przemówiło doświadczenie...

Właśnie bez doświadczenia (często jest to nieświadoma intuicja) można
łatwo nabrać się na kolejny produkt - tak, metodyka, framework,
platforma, biblioteka, język jest produktem.
Ktoś go wytworzył i ktoś go sprzedaje (zwykle pośrednio jako wsparcie/
książki/treningi).

A całościowy i rzetelny obraz można uzyskac tylko od kogos, kto
spróbował wielu alternatyw.

[Adam Lider]

Witam, 

On Nov 3, 2009, at 11:03 AM, Jacek Laskowski wrote:

Adam, tyś moim mistrzem Scruma teraz się stał :) Proszę o zezwolenie
na publikację całości na moim blogu. Oczywiście z całym należytym
wskazaniem na autora.

alez bardzo prosze

Ta wypowiedź dokładnie odpowiada mojemu poglądowi sprawy, tylko że
brakowało mi dotychczas słów/słuchaczy/cierpliwości, aby dobrze się
wyrazić. Scrum wymaga wiedzy, której młode zespoły zachłyśnięte
lekkimi metodykami nie mają, jeszcze. To, co napisałeś umieszczam jako
swój manifest poznającego Scruma (za pozwoleniem, jeśli można).

p.s. Bez urazy, ale Twoje nazwisko mówi samo za siebie i jedna
wypowiedź wystarczyła, abym nie miał złudzeń :)

;)

Adam Lider

[Tomasz Łasica]

Witam,

dziękuję za komentarz.
pozwalam sobie delikatnie się nie zgodzić, ale brakuje mi praktycznego doświadczenia z wprowadzania XP
Wystąpię w roli adwokata diabła:

pozdrawiam
Tomek Łasica


Adam Lider pisze:

Zgadzam się że praktyki związane z warsztatem i rzemiosłem programistycznym są ważniejsze
dla jakości pracy (szeroko rozumianej) niż wprowadzenie Scruma. Nie bez kozety pewnie 1/3 szkolenia CSM jest poświęcona praktykom z XP.
Jednak widzę szansę w rozpoczęciu od Scruma.

Wprowadzając Scruma nie spodziewałem się natychmiastowej poprawy np. jakości produktu czy wydajności.
Natomiast spodziewam się (po jakimś czasie) lepszej organizacji pracy, w tym przede wszystkim wizualizacji i przejrzystości pracy oraz czasu na aktywności,
na które bez wprowadzenia tegoż Scruma czas by się nie znalazł.

I to daje moim zdaniem podstawę do dalszej pracy, do tego aby zespół "się samo-organizował" i poprawiał.
Z tym, że nie ma mowy o samoorganizacji bez mentora lub coacha.
Dlatego nie sprawdzi się (raczej) Scrum Master, który nie ma solidnych podstaw deweloperskich, nie potrafi zespołowi pomóc "zauważyć" lub "znaleźć rozwiązanie".
Cuda potrafi zdziałać dotychczasowy lider zespołu przekonany do nowej organizacji pracy.

Może się mylę, ale wprowadzanie (i wprowadzenie) XP wydaje mi się trudniejsze i bardziej rewolucyjne w stosunku do Scruma.
Scrum mniej narzuca, pozostawia więcej swobody i w efekcie ułatwia ewolucyjne przejście.
Np. w obecnym miejscu wprowadziliśmy Scruma zupełnie nie dotykając procesu produkcji oprogramowania (notabene dość dojrzałego).
A potem po kolei staramy się wprowadzać praktyki, które pasują do naszego projektu (a nie wszystkie pasują).

Notabene ciekaw jestem czy są jakieś znane przypadki zastosowania XP do oprogramowania backend-u ?
Np. Czy wyobrażacie sobie zastosowanie XP przy pisanie takiego choćby RDBMS Oracle ?
Jak wyglądają w takiej kategorii user stories ? Jaki mają rozmiar ? Jak zapewnić Done Done ? Może ktoś ma doświadczenie ?

No i trochę niepolitycznie (pewnie mi się oberwie):
W przypadku kiepskich rzemieślników można zrobić z nich dobrych prawdopodobnie tak samo w XP jak Scrum jeżeli mają oni odpowiedni potencjał.
Być może w Scrum w stosunku do XP jest odwrócona kolejność, najpierw próbujemy poprawić organizację pracy w zespole, a potem warsztat.
A ze słabymi i nie rozwijającymi się członkami zespołu po prostu zazwyczaj się żegnam.
Może to arogancja, ale uważam że nie każdy musi być programistą, podobnie jak nie każdy musi skończyć wyższe studia ;-)

Moj glowny zarzut dla tej metody to proba wmowienia, ze wytwarzanie oprogramowania moze byc efektywne i dosc latwe (ze Scrumem), z niedostateczny podkresleniem wagi rzemiosla zespolu i jego czlonkow.

Nie zaprzeczam, że takie próby są powszechne.
To jest chyba chwyt marketingowy (czy na pewno promowany przez jej twórców?) i nie ma wiele wspólnego z samą metodyką.
(mi na kursie wpajano zdecydowanie odwrotnie : Scrum jest łatwy i dlatego jest taki trudny).
Po prostu na tym można zarobić.
Podobny zarzut można odnieść do wielu produktów - analogiczne problemy miało programowanie obiektowe,
które miało być pacaneum na wszelkie problemy (któż z nas nie programował semi-obiektowo...).
Do dzisiaj jestem zdania, że dobrze obiektowo potrafi programować <10% programistów (włączając w to mnie).

- Adam

[Paweł Lipiński]

Cześć

Myślę Tomku, że jesteś jedną z niewielu osób, które tak podchodzą do wdrażania Scrum'a (czy jakiejkolwiek innej metodyki). O większości zmian metodyk decydują managerowie bazując na założeniu, że jak wprowadzimy to będzie ekstra - wyniki od razu skoczą (a jak nie od razu, to szybko), jakość się poprawi, terminy będą krótsze i dotrzymywane przez zespoły. Pracowałem trochę jako agile coach i widziałem parę wdrożeń Scrum'a w różnych działach i firmach i niestety z tego co widziałem to bardzo częsty scenariusz.

Z drugiej strony rozumiem Tomka - jak ich proces działa i są z niego zadowoleni, to ewolucja będzie lepsza niż rewolucja. I dlatego właśnie, jak sądzę, Scrumowe nienarzucanie praktyk programistycznych im odpowiada. Ale boję się, że przypadek firmy Tomka jest kiepskim przykładem, bo jak sam powiedział to firma prawie wyłącznie MIMUW'owska, co oznacza jednak pewnie dość wysoką średnią jakości programistów. Do tego (z tego co wiem) to firma na tyle mała, że bardzo dużo inicjatyw oddolnych (od programistów) po prostu przechodzi, że komunikacja programista-management jest trywialna. I wdrażanie czegokolwiek (nawet wspólnego pieczenia szarlotki) jest łatwo wykonalne. W dużych firmach jest to dużo trudniejsze.

A z mojego doświadczenia wdrażanie Scruma nie wiele się różni od wdrażania XP. Przynajmniej jeśli chciało by się nie pozostać na wdrażaniu scrum'a jako samego procesu - wszyscy chyba trenerzy Scrumowi i tak zachęcają do praktyk XP. Przecież założenia są te same (iteracyjność, bliska współpraca z biznesem, planowanie, techniczna doskonałość, reaktywność na zmiany, etc.). Różna nomenklatura, trochę inne praktyki organizacji projektu (np. "customer on site" versus "sprint review"), ale generalnie to jeden pies. Dobrym przykładem jest tu przywołane przez Adama i powtórzone przez Tomka Done Done, które z tego co wiem ukuł Mike Cohn w czasie prowadzenia jakiegoś szkolenia CSM (a więc wcale nie XP). To, że Scrum i XP zbiegają do siebie, widać choćby po osobach związanych z XP a posiadających CST i wypowiadających się na oficjalnych listach scrum i xp. Stąd nielubiana przeze mnie rzeczownikowa wersja słowa Agile ma coraz bardziej sens.

Jedno co jest pewne co do Scrum'a to obietnica Kena Schwaber'a: 

Scrum is not a silver bullet. Scrum will not solve your problems. It will reveal them so that you and your people are compelled to address them.

Jeśli więc jest kiepski zespół,  to po prostu będzie to dobrze widać przez porażkę jaką odniosą, jeśli natychmiast nie zaczną nad sobą pracować, i to najlepiej z pomocą kogoś doświadczonego... 

I jeszcze kawałek Ken'a:

If you have a team of outstanding engineers that are using excellent engineering tools, have engineering practices down pat, understand the business domain and aren’t interrupted to have all the resources they need, then you can use Scrum. While it’s true that people like that can build an increment of software each iteration. That’s good.

However, Scrum works with idiots. You can take a group of idiots, that maybe didn’t even go to school, don’t understand computer science, don’t understand software engineering techniques, hate each other, don’t understand the business domains, have lousy engineering tools, and uniformly they will produce “crap” every increment. This is good!

Paweł

--

www.pragmatists.pl

blog.pawellipinski.com

Wiadomość napisana przez Tomasz Łasica w dniu 2009-11-03, o godz. 23:02:

[Adam Lider]

Witam,

On Nov 3, 2009, at 11:02 PM, Tomasz Łasica wrote:

> Zgadzam się że praktyki związane z warsztatem i rzemiosłem
> programistycznym są ważniejsze
> dla jakości pracy (szeroko rozumianej) niż wprowadzenie Scruma. Nie
> bez kozety pewnie 1/3 szkolenia CSM jest poświęcona praktykom z XP.
> Jednak widzę szansę w rozpoczęciu od Scruma.

Ja tez i to duze, ale pod pewnymi warunkami.

> Wprowadzając Scruma nie spodziewałem się natychmiastowej poprawy np.
> jakości produktu czy wydajności.
> Natomiast spodziewam się (po jakimś czasie) lepszej organizacji
> pracy, w tym przede wszystkim wizualizacji i przejrzystości pracy
> oraz czasu na aktywności,
> na które bez wprowadzenia tegoż Scruma czas by się nie znalazł.
>
> I to daje moim zdaniem podstawę do dalszej pracy, do tego aby zespół
> "się samo-organizował" i poprawiał.
> Z tym, że nie ma mowy o samoorganizacji bez mentora lub coacha.
> Dlatego nie sprawdzi się (raczej) Scrum Master, który nie ma
> solidnych podstaw deweloperskich, nie potrafi zespołowi pomóc
> "zauważyć" lub "znaleźć rozwiązanie".
> Cuda potrafi zdziałać dotychczasowy lider zespołu przekonany do
> nowej organizacji pracy.

a jeszcze wiecej gdy beda pracowali w parach, ale w 100%, scisle
wedlug regul

> Może się mylę, ale wprowadzanie (i wprowadzenie) XP wydaje mi się
> trudniejsze i bardziej rewolucyjne w stosunku do Scruma.
> Scrum mniej narzuca, pozostawia więcej swobody i w efekcie ułatwia
> ewolucyjne przejście.
> Np. w obecnym miejscu wprowadziliśmy Scruma zupełnie nie dotykając
> procesu produkcji oprogramowania (notabene dość dojrzałego).
> A potem po kolei staramy się wprowadzać praktyki, które pasują do
> naszego projektu (a nie wszystkie pasują).

jakie nie pasuja? jesli mozna wiedziec

> Notabene ciekaw jestem czy są jakieś znane przypadki zastosowania XP
> do oprogramowania backend-u ?
> Np. Czy wyobrażacie sobie zastosowanie XP przy pisanie takiego
> choćby RDBMS Oracle ?
> Jak wyglądają w takiej kategorii user stories ? Jaki mają rozmiar ?
> Jak zapewnić Done Done ? Może ktoś ma doświadczenie ?
>
> No i trochę niepolitycznie (pewnie mi się oberwie):
> W przypadku kiepskich rzemieślników można zrobić z nich dobrych
> prawdopodobnie tak samo w XP jak Scrum jeżeli mają oni odpowiedni
> potencjał.
> Być może w Scrum w stosunku do XP jest odwrócona kolejność, najpierw
> próbujemy poprawić organizację pracy w zespole, a potem warsztat.

Tutaj nie do konca o to mi chodzilo. Wedlug modelu (http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
) istnieje 5 etapow zdobywanie umiejetnosci. Zaczynajac od Novice
(praca wedlug regul) a konczac na Expert (bazowanie na intuicji). Moim
zdaniem Scrum sprawdza sie szczegolnie w przypadku zespolow
zbudowanych z ludzi bedacych na wyzszych poziomach. Tacy ludzi
potrafia "wyczuc co nie gra" i moze nawet nie umiejac tego precyzyjnie
wytlumaczyc umieja to skorygowac. Dla nich praca wedlug regul to
meczarnia bez sensu. To oni tworza reguly. Natomiast poczatkujacy (2
pierwsze poziomy) potrzebuja regul to pracy bo bez nich to jak we
mgle. Jesli z takich ludzi zbudowany bedzie zespol Scrum to bedziemy
mieli "machanie karteczkami". Dlatego stwierdzilem ze podejscie XP,
ktore bardziej narzuca praktyki (reguly) jest lepsze dla takich
zespolow. Co wiecej, zaryzykuje stwierdzenie, ze w takim przypadku
lepiej moze sprawdzic sie nawet waterfall model, w ktorym mamy
dokumentacje/projekt na poczatku (z wszystkimi jego wadami).
Absolutnie nie twierdze ze Scrum nie dziala. Chce tylko podkreslic, ze
Scrum zaczal byc lekiem na wszystkie problemy i jest stosowany dosc
slepo. Moze to prowadzic do rozczarowan (co mozna juz zaobserwowac)
nie tylko Scrumem, ale tez cala filozofia Agile.

PS
smutna prawda jest taka, ze (podobno) wiekszosc z nas nigdy nie
przekroczy poziomu Advanced beginner.

- Adam

[Tomasz Łasica]

Cześć,

No cóż, to faktycznie jest dopiero 2. firma w której wprowadzałem Scruma,
w sumie z mniejszymi lub większymi sukcesami było to jakieś 8-10 zespołów.
Nie wszystkie były tak mocne - faktycznie wówczas wychodziło to gorzej
(lub po prostu trwało dłużej). Ale w zasadzie się udawało.
W sytuacji słabszego zespołu bardzo przydawała się 1 osoba z autorytetem mocna technicznie.
Wystarczało. Reszta (m.in. dzięki scrumowi) zaczynała się uczyć.

A duże firmy omijam szerokim łukiem z zasady. Od 11 lat pracuję w firmach <50 osób,
a jedynym mankamentem jest brak szafy pełnej garniturów i ściany wyklejonej certyfikatami ;-)


Tomek

Paweł Lipiński pisze:

> www.pragmatists.pl <http://www.pragmatists.pl>
> blog.pawellipinski.com <http://blog.pawellipinski.com>