Kategoria 'Praktyki agile'
Chciałbym was zaprosić do napisania posta. Celem jest powstanie cyklu “Agile Made in Poland“, w którym zaprezentowane byłby polskie firmy stosujące szeroko rozumiane agile/lean, to jak to robią i jakie praktyki oraz elementy stosują. Fajnie byłoby gdyby powstał z tego taki przegląd na jak wiele sposobów można wdrożyć te idee (bo spodziewam się różnorodności :-))
Dla usystematyzowania postów proponuję następującą listę pytań / strukturę (oczywiście format możemy jeszcze przedyskutować w komentarzach):
- Czym zajmuje się wasza firma? Kim są wasi klienci (chodzi o branżę)?
- Jak w kilku zdaniach wygląda wasz proces lub cykl życia produktu/projektu?
- Jaka jest struktura i sposób działania waszych zespołów?
- Jakie praktyki uważacie za najlepiej sprawdzające się, w waszym przypadku, w pracy z klientem i z ludźmi wewnątrz firmy?
- Jakie praktyki stosujecie dla zapewnienia jakości oprogramowania?
- Czy były jakieś praktyki, które nie zadziałały mimo prób ich wdrożenia? Dlaczego?
- Co chcielibyście zmienić w działaniu firmy jeśli chodzi o proces jaki stosuje?
- Czy chcielibyście coś dodać? Jakieś luźne przemyślenia na temat agile u was lub w Polsce?
Jeśli ktoś pokusi się o napisanie posta w tym formacie, to chętnie opublikuję go tutaj, ale będzie świetnie jeśli napiszecie na swoich blogach. Będę tylko wdzięczny za zachowanie formatu i danie mi znać (np. wpisując linka w komentarzach).
Uchylcie rąbka tajemnicy jak wygląda Agile Made in Poland…
May 25th, 2011
Dzisiaj w Snowbird, Utah odbywa się spotkanie, które zorganizował Alistair Cockburn z okazji 10-tej rocznicy powstania Manifestu Agile. Z tej okazji Alistair zaprosił do dyskusji, nie tylko w Snowbird, ale także w internecie, nad trzema pytaniami:
- Jakie problemy w tworzeniu oprogramowania oraz budowaniu produktów zostały rozwiązane (i tym samym nie powinniśmy zajmować się ich rozwiązywaniem wciąż od nowa)?
- Które z problemów są z zasady nierozwiązywalne (i tym samym nie powinniśmy zajmować się próbami ich rozwiązania)?
- Które z problemów jesteśmy w stanie sensownie rozwiązać - problemy, które możemy złagodzić przy pomocy pieniędzy, pracy lub usprawnień/innowacji (i tym samym powinny się stać centrum naszej uwagi w najbliższym czasie)?
Na same pytania spróbowałem odpowiedzieć na blogu tinyPM. Jednak tam odnoszę się bardziej do ogólnej wizji jaka dla mnie kryje się za Manifestem i agile. Notomiast tutaj chciałbym zaprosić was do dyskusji bardziej lokalnej, naszej, polskiej.
Agile w Polsce rozwija się wolniej i krócej niż to ma miejsce np. w Stanach Zjednoczonych. Czy dotykają nas te same problemy, o których dyskutuje teraz społeczność agile na świecie? Co myślicie o obecnym stanie zastosowania praktyk agile w Polsce? W którym punkcie jesteśmy? Co chcemy osiągnąć w najbliższym czasie (2011?) oraz w perspektywie 5-10 kolejnych lat? Czy borykamy się z problemami, które zostały już rozwiązane?
Piszcie co sądzicie tutaj w komentarzach, albo na własnych blogach. Jeśli napiszecie na własnym blogu, wrzućcie tutaj komentarz z linkiem, żebyśmy mogli zebrać tę dyskusję w jedną całość.
Gdzie jest i dokąd zmierza polskie agile? Co jako społeczność agile w Polsce powinniśmy zrobić?
źródło obrazka: Pictofigo
February 12th, 2011
Jako, że jest początek roku, to powinienem pisać podsumowanie działań agile w Polsce w 2010 roku… i pewnie w ciągu paru dni to zrobię. Tymczasem pomyślałem, że napiszę o czymś niedocenianym, czyli o technice 5 Why znaną z Lean i o analizie źródłowego problemu. No i pozwolę sobie tym razem zrobić to w nieco lżejszej formie :-)
Na wstępie wyjaśnię tylko, że chodzi o to, iż często po wykryciu problemu w projekcie, zespole, życiu, itd., staramy się mu zaradzić nie zastanawiając się nad tym co jest faktyczną przyczyną… Tym samym leczymy objaw a nie przyczynę. Kończy się to zwykle powtórką problemu w niedalekiej przyszłości. Technika “5x Dlaczego?” (5 Why?) to jedna z wielu technik dochodzenia do sedna problemu i jednocześnie bardzo w prosta w zastosowaniu. Wystarczy zadać sobie kilka pytań dlaczego?
To tyle tytułem wstępu, a teraz przenieśmy się do… przedszkola :-) Usłyszałem jakiś czas temu od syna:
Problem: “Byłem dzisiaj niegrzeczny… :(”
Tutaj można by się zatrzymać i reakcja mogłaby być taka, że wpadamy w gniew i wymierzamy karę, np. “No jak mogłeś… nie będzie dzisiaj oglądania bajek w TV”. Ale poczekajmy z tym i zadajmy pierwsze pytanie “dlaczego?”.
Pytanie: “Dlaczego? Co się stało?”
Odpowiedź: “Popchnąłem koleżankę z innej grupy…”
Dzieci maja wyjątkową zdolność do przekazywania minimalnej informacji wymaganej do zaspokojenia pytania rodzica. Czy nie przypomina to nam naszych własnych wyjaśnień dotyczących problemu? No to drążymy dalej…
Pytanie: “Ale dlaczego? Czy coś Ci zrobiła?”
Odpowiedź: “Zabrała mi kolegę…”
No dobra… teraz wiemy jeszcze mniej niż na początku.
Pytanie: “Jak to zabrała? Dlaczego ją za to popchnąłeś?”
Odpowiedź: “Bo ona mieszka na tym samym podwórku… i chciała, żeby się bawił z nią. Ale ja się z nim bawiłem pierwszy!”
Ok. Teraz już mamy obraz całej sytuacji. No i właśnie… Czy właściwym problemem jest złe zachowanie. Nie, to raczej był zły efekt wynikający z innego problemu. Mój syn spotkał się w przedszkolu po raz pierwszy z sytuacją, gdzie jego kolega może znać kogoś innego, kogo on sam nie zna. Gdyby nie drążyć moglibyśmy nie dowiedzieć się co tak faktycznie wymaga wyjaśnienia.
Mogło się skończyć na reprymendzie “Nie popychaj nikogo więcej”. Efekt byłby taki, że następnym razem zamiast popychania byłoby szczypanie (dzieci nie tylko dostarczają bardzo precyzyjnych w ich mniemaniu odpowiedzi - bardzo precyzyjnie traktują też to co do nich mówimy ;-))
Po bardziej naukowy opis metody odsyłam np. do Wikipedii. Są też inne techniki (np. fishbone diagram). A wy jakie techniki stosujecie do root cause analysis?
January 3rd, 2011
Tak… pierwsze Code Retreat we Wrocławiu jest już historią. 23 października o nadludzkiej porze jaką jest 8:00 rano w sobotę przyszło razem pokodować 61 osób! Myślę, że już sam ten fakt świadczy o sukcesie przedsięwzięcia jakie Grzegorz Dziemidowicz zainicjował we Wrocławiu przy wsparciu JUG’a i grupy Kunszt.
Celowo piszę “zainicjował”, bo sami organizatorzy myślą o powtórzeniu warsztatów za ok pół roku, a ja mam nadzieję, że przy naszym (uczestników) pozytywnym odzewie uda się ich zachęcić do zrobienia tego nawet szybciej :-)
Jak wyglądało Code Retreat?
Cały dzień podzielony został na 2 bloki składające się z 3 sesji kodowania w parach, które trwały 45 min każda + 10 min na retrospekcję. Po 3-ciej sesji w hotelowej restauracji podano wyśmienity obiad, który zawdzięczamy sponsorowi wydarzenia, czyli firmie Tieto.
Z resztą z obiadem wiąże się taka mała anegdotka, bo na oficjalnej stronie Code Retreat Corey’a Haines’a, wśród reguł opisujących organizację takich warsztatów, można znaleźć zdanie:
“Obiad powinien być czymś dobry, serwowanym. Moją regułą jest, że jeśli masz chęć przyjść o 8:00 rano aby spędzić z innymi cały dzień na kodowaniu, to zasługujesz na coś więcej niż pizza na obiad.”
Ale nie o jedzenie w tym wszystkim chodzi. Podczas każdej sesji mieliśmy zmieniać pary, co też uczyniłem, bo pierwotnie moim zamiarem było właśnie spróbować pracy z różnymi ludźmi, których nie znam. Takie podejście gwarantuje maksymalny poziom wymiany wiedzy. Problem do rozwiązania był cały czas ten sam - gra w życie, ale po pierwszych dwóch sesjach pojawiły się pomysły na podejście do problemu z zupełnie różnych kierunków.
Pary mogły np.:
- spróbować używać maksymalnie 2-4 linijkowych metod i maksymalnie 4 metod w klasie
- używać tylko obiektów immutable
- nie używać if’ów
- nie używać liczb i tablic do reprezentacji planszy i reguł gry
- itp.
Niektóre pomysły podrzucał na Twitterze Corey, który był w tym czasie zdaje się w Amsterdamie na podobnym Code Retreat :-)
Co ćwiczyliśmy?
Każda para miała wybrać sobie co głownie będzie ćwiczyła podczas sesji. W parach, w których ja kodowałem wybraliśmy:
- Pracę w parze ze zmianami co 5 min + TDD
- Ping-ponga (praca w parze gdzie jedna osoba pisze test, druga go implementuje) + podstawy pisania testów w JUnit
- TDD as if you meant it (Darek Mielniczek zasiał zainteresowanie tym tematem, które trwało do ostatniej sesji :-))
- Implementacja zagadnienia od góry, czyli od testów akceptacyjnych na całej grze.
- Immutability - tutaj moim zdaniem za mało było testów.
- TDD as if you meant it - drugie ćwiczenie poszło lepiej. Siła w powtórkach (Kata).
Czego się nauczyłem?
- Pierwszy raz próbowałem “TDD as if you meant it”
- Poznałem trochę tricków na refaktoryzację w Eclipse (+ trochę nowych skrótów klawiszowych)
- Spojrzałem na problem z kilku perspektyw
- Popracowałem w parze, co rzadko mi się zdarza
Co być może dałem od siebie?
- Propagowałem szablon should* (given, when, then) jakiego nauczyłem się jakiś czas temu od Szczepana Fabera i Bartka Bańkowskiego
- Pokazałem użycie biblioteki FestAssert + pluginy do Eclips’a jak MoreUnit
- Być może przekazałem w jednej z par trochę podstaw na temat testów w ogóle i dzielenia ich na mniejsze kawałki
Myślę, że spokojnie mogę stwierdzić iż nauczyłem się dużo w tak krótkim czasie. Gdyby osoby, z którymi programowałem mogły powiedzieć, że zyskały ode mnie tyle co ja od nich, to byłby to dla mnie duży komplement.
Generalnie bardzo podoba mi się formuła Code Retreat, bo kompletnie usuwa bariery pomiędzy doświadczonymi i niedoświadczonymi uczestnikami. Wynika to chociażby z faktu, że nawet jeśli jesteś doświadczony w jakiejś sferze, to okazać się może, że ta druga osoba uzupełni tą wiedzę czym innym jeśli zmienimy nieco charakter ćwiczenia. I o to w tym wszystkim chodzi.
Na podsumowanie
Powiem tak. Jeszcze raz gratuluję organizatorom. Było świetnie. A dodatkowym dowodem niech będzie to, że nie zrobiłem ani jednego zdjęcia. Code Retreat wciągnęło mnie do tego stopnia, że od 8:00 do 17:00 nie przypominam sobie ani chwili, w której pomyślałbym, że nie ma co robić ani z kim porozmawiać, więc może pstryknę parę zdjęć.
W podsumowaniu warsztatów padały głosy, że być może można nieco usystematyzować ramy takich następnych sesji w parach i narzucić więcej tematów do ćwiczeń. Ja raczej pozostałbym przy dowolności tego co para chce ćwiczyć i przy swobodzie wymiany doświadczeń. Oby następne spotkanie odbyło się nie później niż po nowym roku!
October 24th, 2010
Już w najbliższą sobotę we Wrocławiu odbędzie się pierwsze otwarte Code Retreat. To niezwykła gratka dla tych, których interesuje ruch Software Craftsmanship i chcą dodatkowo poćwiczyć sobie pisanie czystego kodu, TDD i pracę w parach.
Cieszy też fakt, że zainteresowanie było tak duże, że wejściówki rozeszły się praktycznie natychmiast. Ale cały czas można się wpisywać na listę oczekujących. No i mam nadzieję, że jest to pierwsze z wielu tego typu spotkań, które na stałe zagoszczą we Wrocławiu. Zobaczymy 23 października. Postaram się napisać więcej po spotkaniu.
Chciałbym przy tej okazji wspomnieć o możliwości uzyskania zielonej obrączki “Clean Code” promowanej przez Uncle Bob’a (Robert C. Martin). Taką obrączkę może dostać każdy, to przekaże min 10 USD na jeden z celów charytatywnych wymienionych na stronie akcji. Osobiście zaświadczam, że obrączki do Polski docierają :-) Więcej szczegółów tutaj:
http://butunclebob.com/ArticleS.UncleBob.GreenWristBand
October 19th, 2010
Od dawna chciałem to zrobić i w końcu się udało. Zrobiliśmy z moim starym zespołem Agile LEGO Game. W związku z tym, że moja kariera szkoleniowa jest wyjątkowo krótka, więc to był doskonały temat do ćwiczeń. Dodatkowo poznawanie zasad agile poprzez grę przemawia do mnie najlepiej.
No więc do rzeczy. To co chcę tutaj napisać, to krótkie podsumowanie jak te mini warsztaty poszły moim zdaniem oraz kilka uwag co powinienem poprawić.
Zdecydowałem się do gry wybrać user stories używane już wcześniej podczas innych tego typu warsztatów, czyli budowanie nowego gatunku zwierzęcia ;-). Efekty możecie podziwiać poniżej na zdjęciach. Tutaj zamieszczam też krótką prezentację, której użyłem jako wstępu do gry.
Celem było:
- zapoznanie zespołu z wartościami skrytymi za terminem agile
- przedstawienie idei iteracyjnego wytwarzania oprogramowania
- wyjaśnienie jak działa velocity i jak zespół agile poznaje swoje możliwości
- dobra zabawa
Wydaje mi się, że udało się te cele zrealizować. Natomiast co do samej mechaniki gry, to:
1. Nie wyjaśniłem, przy okazji opisywania co to są stories tego, co oznacza business value i tego, że to ona stanowi priorytyzację ze strony klienta. Następnym razem lepiej wyjaśnić to przed startem pierwszej iteracji.
2. Ja grałem rolę klienta dla dwóch zespołów. Przy trzech i więcej lepiej byłoby mieć klienta na każdy zespół.
3. Zacierała się granica pomiędzy fazą estymacji i planowania w trakcie każdej z iteracji. Przy czym pozwoliłem zespołom estymować jak chciały. Być może warto wprowadzić namiastkę planning pokera (np. w formie gry w marynarza). Z resztą to się wiąże z następnym problemem.
4. Jeden zespół zrobił wszystkie, a drugi wszystkie bez jednej user story. Przy czym zestaw był raczej pomyślany tak, żeby jednak trochę stories zostało. Wynika to z kilku przyczyn. Zespoły były 4-5 osobowe i to chyba za dużo. Nie zwróciłem uwagi, że nie trzeba wykonać całego zestawu stories z pierwszej iteracji, co dało efekt małego wyścigu i oba zespoły w pierwszej iteracji zbudowały prawie wszystko.
5. Użyłem http://e.ggtimer.com do mierzenia czasu. Lepiej do odmierzania czasu zabrać osobny zegarek, żeby nie przełączać prezentacji.
Co poprawię następnym razem:
- zwrócę większą uwagę na business value
- postaram się zmniejszyć tempo na rzecz lepszego wytłuszczenia etapów iteracji
October 12th, 2010
Bitwa trwa, czas więc oddać swój strzał w dyskusji jaka rozgorzała na łamach Warszawskiego JUGa. Polecam poczytanie jej (urosła już do pokaźnych rozmiarów) a tymczasem ja postaram się ją tutaj (subiektywnie) streścić i odnieść się do paru rzeczy jakie mi wydały się tam najistotniejsze.
Tak więc dyskusja rozpoczyna się od słusznego spostrzeżenia Grzegorza Lipke (to on tą burzę wywołał :-), że Agile zdobywając popularność wśród polskich firm jest postrzegany jako proste rozwiązanie na trudne problemy, i że dużo ludzi liczy na pewnego rodzaju cudowne uleczenie po ich wdrożeniu.
Tymczasem rzeczywistość nie wygląda tak różowo. Podstawowy zarzut jaki pada w dyskusji to, że ta pozorna wolność jaką ludzie widzą w lekkich metodykach częściej prowadzi do chaosu i pogarsza sytuację pod przykrywką “samoorganizacji zespołu”.
Dyskusja zeszła też na tematy problemów:
- z wyceną i szacowaniem (o tym już parę razy pisałem, więc moje zdanie znacie),
- brakiem dokumentacji (która może być krytyczna)
- brakiem doświadczenia potrzebnego do prawidłowego zastosowania metodyk lekkich
Pojęcia
Po pierwsze czuję, że należy wyprostować trochę pojęć, bo w trakcie tej dyskusji przeplatają się wady Agile, czy Scrum czy może zamiast tego XP, albo prawie Agile = Scrum. To, dość typowe, utożsamienie Scruma z Agile wydaje mi się krzywdzące dla obu stron. Agile to pewna idea, zbiór czterech podstawowych wartości i zarys zasad jakie im towarzyszą. Scrum natomiast to jedna z implementacji tych wartości w dziedzinie lekkich metodyk (choć do końca metodyką nie jest). XP natomiast to zespół praktyk bardzo bliskich pracy programiście. Mało się w XP kładzie nacisku na zarządzanie ludźmi, projektami, produktami.
Jeśli więc mówimy o wadach Agile, to mówimy o wadach jakie dostrzegamy bądź w wartościach z Agile Manifesto, bądź w 12 praktykach, które tym wartościom towarzyszą. Pytanie czy któraś z nich wam się nie podoba? Co innego jeśli mówimy o ich wdrożeniu w życie. Tutaj jest już wiele pomysłów jak to zrobić. Jednym z nich jest Scrum, choć nie odpowiada on na wszystkie elementy z Agile Manifesto.
Może więc chodzi nam o wady Scrum? Na pierwszy rzut oka można zauważyć kilka:
- Scrum nie jest pełnym zbiorem, dlatego często uzupełnia się go w kontekście wytwarzania oprogramowania o praktyki z XP (uzupełnia a nie stosuje jedno zamiast drugiego)
- Scrum (z resztą jak cały ruch Agile) pierwszorzędny nacisk i całą odpowiedzialność kładzie na ludzi (tak na mnie i na Ciebie też :-) - czy to faktycznie wada?
- Scrum zakłada, że twoje otoczenie będzie równie zaangażowane jak ty, czyli zarówno sponsorzy jak i właściciele produktu, management, wszyscy mają swoje role. Problem w tym, ze nasze konteksty w życiu codziennym nie są takie różowe i w Scrum ciężko znaleźć na to odpowiedź.
Lekkość i prostota
Jacek Laskowski napisał w swoim komentarzu do dyskusji, że lekkie metody nie są, mimo swojej nazwy, wcale lekkie we wdrożeniu. A kto mówi, że są? Lekkość i prostota tych metod nie polega dla mnie na ich wdrożeniu. I nie mylmy prostoty z prostactwem (simple not simplistic). Ich lekkość leży w prostocie narzędzi jakich używają do osiągnięcia celu. Bezpośrednia rozmowa, krótkie spotkanie, mała kartka z user story, backlog (prosty w budowie). To są narzędzia, które są proste w zrozumieniu i nie wprowadzają zbędnego narzutu na zespół, który ma się skupić na swoim głównym celu, jakim jest dostarczenie wartości klientowi poprzez wytworzenie niezawodnego oprogramowania.
Zgadzam się z Pawłem Lipińskim w kwestii jakości. Każdy zarzut pod kątem pogorszenia się jakości w wyniku zastosowania lekkich metod jest nieuzasadniony, bo jednym z kluczowych problemów jakich Agile próbuje dotknąć jest właśnie jakość. Jeśli się pogarsza, to coś jest nie tak z zespołem a nie z założeniami metodyki (moja opinia).
Ludzie
Ludzie… W sumie to chodzi o dwie kwestie. Pierwsza to ta, że bardzo ciężko wprowadzać metodyki lekkie w niedoświadczonych zespołach. Moje pytanie brzmi - a którą metodykę wprowadza się łatwo w takich zespołach? Ja nie znam żadnej metodyki wytwarzania oprogramowania, którą wprowadzałoby się lekko i przyjemnie. Bo nie mówimy tutaj o produkcji masowej pana Forda, która była pomyślana właśnie pod kątem słabo wykwalifikowanej kadry. Więc jeśli mówimy o zespole, to jeśli ktoś poważnie myśli o podnoszeniu jakości jego pracy i w ogóle o zarządzaniu ludźmi, to nie zostawia słabo doświadczonych ludzi samych sobie.
Jeśli mówimy o dopiero formującym się zespole, np. w nowej firmie, gdzie brak nam doświadczenia z metodami lekkimi, to dlaczego oczekujemy, ze wszystko się nam uda? Wiadomo, będziemy eksperymentować. Nie zrzucajmy na karby metodyki naszych problemów z jej implementacją. Poza tym żadna z metodyk lekkich niczego nie narzuca pod rygorem kary śmierci. Te same problemy wystąpią w takim zespole podczas próby wprowadzenia PRINCE2 czy RUP (osobiście myślę, że większe). tutaj liczy się kontekst w jakim stosujemy dane praktyki. Coś co działa u mnie może nie działać u ciebie, więc się tego kurczowo nie trzymaj. To jest jedna z cech odróżniających metodyki lekkie od tych bardziej sformalizowanych.
Dla mnie małe doświadczenie nie jest problemem, bycie natomiast słabym programistą, managerem, testerem itd., mimo doświadczenia już problemem jest. Ja takich ludzi nie chcę. Rzadko wypowiadam się kategorycznie, ale w tym przypadku moje zdanie na ten temat jest jednoznaczne. Ja chcę mieć w zespole ludzi dobrych, ba… najlepszych. Idealnie lepszych ode mnie. Dla słabych, dla których to co robią to nic szczególnego, bo znaleźli się w IT przez przypadek, bo ta praca jest dobra jak każda inna, a przy tym można trochę zarobić, nie ma u mnie miejsca. Co mają ze sobą począć? Najlepiej znaleźć sobie inne zajęcie.
Dla mało doświadczonych, zapalonych do pracy, kreatywnych ludzi, wszystkie metodyki lekkie przygotowały narzędzia, aby uczynić z nich coraz lepszych specjalistów i to w wielu aspektach ich pracy. Trzeba tylko chcieć po to sięgnąć.
Po co Agile, czyli kontekst wdrożenia
Ach i jeszcze na koniec, bo zaczynam nudzić… Dla mnie podstawowym wyznacznikiem do podjęcia się wdrożenia metod lekkich jest odpowiedź na pytanie co tak faktycznie chcemy zmienić w obecnym procesie. Powszechna jest opinia, że z Agile będzie szybciej, lepiej, więcej, taniej, fajniej, lżej. WTF?
Może będzie szybciej, bo wcześniej klient dostanie to na czym mu zależało, a może szybciej się to wszystko wywróci i to też dobrze, bo można minimalizować straty. Czy będzie taniej? No pytanie dla kogo? Czasem faktycznie może się udać zmniejszyć koszty, ale częstsze będzie wykonanie produktu o wyższej jakości przy tym samym koszcie i czasie. Czy lżej? Na początku na pewno nie! Żadna z metodyk nie mówi nic o słodkim nieróbstwie (chyba, że coś przeoczyłem :-).
Tak więc Agile nie pomaga robić szybciej, taniej, więcej. Pomaga natomiast sprawnie ujawnić i rozwiązać problemy, które przed sobą postawimy - w naszym kontekście i z naszymi ludźmi.
November 4th, 2009
Dzisiaj chciałbym krótko zareklamować artykuł Pawła Lipińskiego z Pragmatists na temat “Zwinnego Rozwijania Oprogramowania”. Artykuł jest wprowadzeniem do filozofii kryjącej się za Agile Manifesto i zawiera interpretację zarówno czterech punktów manifestu, jak i dwunastu praktyk, które towarzyszą manifestowi (a o których często zapominamy).
Nie będę zbyt długo recenzował tego artykułu, bo nie mam się za bardzo do czego przyczepić :-) Zgadzam się zarówno z duchem całego artykułu jak i z interpretacją samego manifestu agile. Artykuł wypełnia lukę wśród materiałów na temat podstaw agile jakie można przeczytać po polsku, a jednocześnie zawiera wiele sugestii wynikających z praktyki.
Po lekturę odsyłam do Pragmatists oraz na bloga Pawła:
http://blog.pawellipinski.com/2009/10/wprowadzenie-do-zwinnego-rozwijania.html
Natomiast tekst polecam także jako czytankę, jaką można pokazać klientowi, którego chcemy uświadomić na temat tego, co do niego mówimy, kiedy próbujemy go przekonać, że te nasze czarne sztuczki to dla jego dobra :-)
Tymczasem czas samemu zabrać się za napisanie czegoś po polsku…
October 26th, 2009
Właśnie wróciłem z krótkich wakacji, z których przywiozłem sobie osobliwą pamiątkę - ulotkę pizzerii oferującej pizzę na telefon z dostawą do domu. Czemu jest w niej coś dziwnego? O tym za chwilę :-) Najpierw zabawmy się w mini projekt tworzenia takiej ulotki. Jesteśmy pracownikami restauracji i zastanawiamy się jak też ma nasza ulotka wyglądać:
- Oferujemy pizzę z dostawą do domu… napiszmy to dużymi literami, żeby każdy się zorientował.
- Mamy promocję “Zamów 3 pizze, 4-tą dostaniesz gratis” - musi być na ulotce!
- Oczywiście musi tam być też lista naszych pizz i ceny (duży wybór, więc poświęcimy temu całą stronę)
- Mamy ograniczony budżet ulotka będzie więc czarno-biała
- Jeszcze trzeba wybrać jakieś ładne zdjęcia z pizzą na jedną i drugą stronę.
Macie już w głowie jakiś ogólny obraz ulotki? Taka zwyczajna… A nie brakuje na tej liście czegoś? To może inaczej… Spójrzmy na planowanie funkcjonalności ulotki oczami jej użytkownika i spiszmy user story:
- Jako klient chcę się dowiedzieć jakie pizze są dostępne (z jakimi dodatkami) i ile kosztują abym mógł wybrać odpowiednią pizzę dla siebie.
- Jako klient chciałbym się dowiedzieć czy są dostępne jakieś promocje, abym mógł ew. dokonać jakiegoś korzystniejszego zakupu.
- Jako klient chcę się dowiedzieć z ulotki jaki jest numer telefonu abym mógł zamówić pizze, które wybrałem.
- Jako klient chciałbym wiedzieć gdzie mieści się pizzeria, na wypadek gdybym chciał się jednak przejść i zjeść pizzę na miejscu zamiast zamawiać ją telefonicznie.
Teraz już chyba domyślacie się dlaczego ta ulotka z “pizzą na telefon” tak mnie rozbawiła… Autorzy zapomnieli o numerze telefonu i adresie. Jedyną wskazówką była nazwa restauracji, więc ostatecznie udało się znaleźć numer w internecie :-)
A cały ten wakacyjny epizod skojarzył mi się z user story dlatego, że patrzenie na wymagania z punktu widzenia użytkownika a nie z punktu widzenia technicznych aspektów projektu jest moim zdaniem szalenie istotne i może czasem uratować “projekt” :-). User stories doskonale się do tego nadają, zwłaszcza, że początkowo celowo ukrywają te techniczne, nieistotne na etapie formowania wizji, szczegóły (jak kolory, zdjęcia, rozkład na stronach).
Innym aspektem, który tylko teraz zasygnalizuję jest to, ze często same user story są pisane bardziej od technicznej strony z pominięciem tej części “aby…”, która niesie ze sobą wartość dla użytkownika. A więc dostarczajmy przede wszystkim wartość użytkownikom, a nie projekt odbiorcy.
August 3rd, 2009
Agile powoli staje się głównym nurtem w sferze zarządzania wytwarzaniem oprogramowania (przynajmniej na zachodzie). SCRUM wdarł się na dobre do zespołów i całych organizacji. Co raz częściej słyszy się o zmianie kierunku i adaptacji elementów systemu produkcyjnego Toyoty takich jak Kanban (przynajmniej dla mnie ten rok w zachodniej blogosferze minie pod znakiem szczególnego zainteresowania Lean Software Development i Kanban).
Jeśli więc hasła Agile, SCRUM, Lean, Kanban są dla Ciebie nowością, ale ktoś wokół zaczyna o tym rozmawiać i ciekawi Cię o co w tym wszystkim chodzi, to poniżej znajdziesz moją subiektywną selekcję miejsc od których możesz zacząć podróż w ten ciekawy świat…
Na początek lektura obowiązkowa!!!
http://www.agilemanifesto.org
http://www.agilemanifesto.org/principles.html
To drugie szczególnie, bo często zapominamy o tej części Agile Manifesto. Jak dla mnie ruch, którego promotorem jest “Uncle Bob”, czyli Rober C. Martin, jest nierozerwalną częścią kultury agile… A tak, czy mówiłem już kiedyś, że agile to kulutra, sposób myślenia i podejścia do wytwarzania oprogramowania, a nie tylko zbiór praktyk… jeśli nie to na pewno powiem, ale może innym razem :-). Także do lektury obowiązkowej dołączam też:
http://manifesto.softwarecraftsmanship.org
SCRUM:
Żeby nie startować od razu od Kanban, to na początek Scrum w pigułce od Mike’a Cohna (taki mini słowniczek):
http://www.mountaingoatsoftware.com/scrum
Książek na temat SCRUM i Agile jest na prawdę dużo i ciężko wybrać jakąś konkretną. Dla mnie najlepszym wyborem na start będzie książka Henrika Kniberga “Scrum and XP from the Trenches” (PDF za darmo dostępny na InfoQ):
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Po pierwsze doskonałym uzupełnieniem do książki Henrika Kniberga o Scrum, jest jego artykuł “Kanban vs Scrum”:
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
A po drugie artykuł z InfoQ (polecam też śledzenie samego InfoQ!). Ten artykuł może jest ciut skomplikowany, ale są w nim zasygnalizowane wszystkie podstawowe rzeczy, więc to dobry start do ew. dalszych poszukiwań co te wszystkie dzwine rzeczy oznaczają:
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
AGILE
Jeśli nie zmęczy Cię lektura i wciąż zafascynowany tematem dotrzesz do tego momentu, to polecam śledzenie blogów. Ja czytam między innymi (takie moje prywatne TOP 5):
http://agile-commentary.blogspot.com
http://blog.mountaingoatsoftware.com
http://www.agileforall.com/blog
http://blog.crisp.se/henrikkniberg
http://agileinaflash.blogspot.com
Zapytasz - A CZEMU TO WSZYSTKO PO ANGIELSKU!? A no bo w Polsce wciąż kiepsko z materiałami o Agile.
Tym bardziej warto się czegoś na ten temat nauczyć i poeksperymentować bo reszta świata ucieka…
Po polsku polecam posłuchanie sobie podcastów z AgileTuning:
http://agiletuning.pl
To tyle na start ode mnie… Ciekaw jestem co polecą inny czytelnicy (zwłaszcza w swerze Lean / Kanban). Właśnie zaczynamy eksperymenty z Kanban w 9-osobowym zespole utrzymaniowo testowym, więc już niedługo trochę wieści z tych eksperymentów na pewno ujawnię :-) Tymczasem miłej lektury.
July 11th, 2009
Previous Posts
