E-seminarium: zwinne praktyki dbania o jakość oprogramowania
Tematem pierwszego w tym roku e-seminarium Polskiej Grupy Scrum będą zwinne praktyki dbania o jakość oprogramowania.
Test Driven Development to praktyka pochodząca oryginalnie z eXtreme Programming. Jest, przy programowaniu w parach, najbardziej ekstremalną praktyką, przez co jeszcze niedawno stosowana była wyłącznie przez czysto agile’owe zespoły. Powoli jednak zyskuje na popularności, głównie dzięki rosnącej świadomości zarówno programistów jak i kierowników projektów co do roli jakości w oprogramowaniu.
Czytaj więcej
E-seminarium: Kanban
Zapraszamy na kolejne e-seminarium Polskiej Grupy Scrum już w środę o 13:00.
Tym razem tematem będzie Kanban – jedna z najpopularniejszych nowych metodyk tworzenia oprogramowania. Kanban operuje w podobnym obszarze co Scrum, jednak prezentuje trochę inne podejście do tematu. Bardzo duża elastyczność metodyki pozwala na stosowanie jej w szerego różnych sytuacji. Prezentacja skupia się na przedstawieniu podstaw Kanbana pokazując również szereg rozwiązań dla typowych problemów, przed którymi stają zespoły korzystające z Kanbana w pierwszych miesiącach pracy.
Spotkanie poprowadzi Paweł Brodziński, który zawodowo kieruje projektami i zarządza zespołami tworzącymi oprogramowanie w firmie VSoft, gdzie obecnie pracuje. Pisze również bloga zatytułowanego Software Project Management, na którym można znaleźć tematy związane z prowadzeniem projektów, tworzeniem oprogramowania czy zarządzaniem ludźmi. Jest także częstym prelegentem na konferencjach branżowych.
Paweł zawsze stara się znaleźć rozwiązania dopasowane do konkretnych problemów i nie zgadza się poglądem że są metody pasujące do wszystkich sytuacji. W ostatnich latach dużo pracuje właśnie z Kanbanem.
To e-seminarium już się odbyło – tutaj można obejrzeć nagranie.
E-seminarium: Scrum, Scum, Sacrum…
Zapraszamy na kolejne, trzecie już e-seminarium Polskiej Grupy Scrum. Środa, 22 września, godzina 13:00.
Temat to “Scrum, Scrum, Sacrum…”, a prowadzi Tomek Włodarek.
Będzie to opowieść o iluzorycznej naturze samoorganizacji, czyli “a co ja będę miał ze Scruma”? Prezentacja traktująca o postrzeganiu i wykorzystaniu Scruma w praktyce, o codziennych grzechach zespołów scrumowych oraz ich przełożonych, oparta o doświadczenia własne z kilku lat coachowania zespołow scrumowych. Przedstawię kilka sytuacji w których dwie podstawy metodyki – samoorganizacja i kultura usprawniania procesu – nie mogą w pełni zaistnieć, co prowadzi do spowolnienia lub zatrzymania procesu zmiany (czyli “flaccid Scrum”).
Tomasz Włodarek posiada ponad 12-letnie doświadczenie w produkcji oprogramowania różnej skali i rodzaju – od gier poprzez oprogramowanie wbudowane (embedded) po złożone systemy czasu rzeczywistego. Od kilku lat dzieli czas pomiędzy obowiązki kierownika zespołów deweloperskich i/lub projektów a niezależnego konsultanta i wykładowcy zaangażowanego w rozwój lekkich metodyk.
Realizując pragmatyczne i adaptacyjne podejście do produkcji oprogramowania pomaga zespołom developerskim osiągać punkt, w którym wykorzystywana technologia, narzędzia i procesy zaczynają działać na korzyść zespołu i realizowanego przez niego przedsięwzięcia a nie przeciwko nim.
Pomożecie?
Polska Grupa Scrum – Polish Scrum Users Group – zaczęła się od konferencji Scrum Gathering w Sztokholmie w 2007 roku. Na konferencji tej Ken Schwaber rzucił hasło by organizować grupy praktyków i zainteresowanych Scrumem po to przede wszystkim, by ludzie mogli lokalnie (i w ojczystym języku) wymieniać się doświadczeniami.
Scrum jest bowiem bardzo prostą metodą – można go przedstawić w godzinę, a kursy certyfikacyjne trwające dwa dni umożliwiają omówienie go naprawdę dogłębnie – jednak jak to zwykle bywa z metodami prostymi prawdziwa trudność ukryta jest w ich stosowaniu. Wymaga ono dyscypliny w dążeniu do jak najlepszych efektów ale i elastyczności w dostosowaniu się do lokalnych warunków i możliwości. Dlatego wydaje się, że ludzie pracujący w Scrumie – i z użyciem innych metod agile takich jak XP czy popularny ostatnio Kanban – powinni mieć potrzebę wymiany doświadczeń z innymi. Wskazuje na to dynamiczny rozwój podobnych grup w innych krajach.
PSUG powstał w listopadzie 2007 roku nie tylko po to by propagować Scrum, ale także by stworzyć możliwość wymiany doświadczeń dla już przekonanych. Działamy już jakiś czas i nie narzekamy na brak uczestników na naszych spotkaniach, wciąż jednak brakuje nam chętnych by na tych spotkaniach mówić, by pisać artykuły na stronę www.scrum.org.pl, by organizować spotkania w swoim mieście czy w inny sposób włączyć się w działalność PSUG-u.
Dlatego spotkania nie odbywają się tak często, jak byśmy chcieli i wciąż nie udało się rozpocząć działalności w innych niż Kraków ośrodkach. Wydaje mi się, że czas to zmienić – ale nie dam rady zrobić tego sam, z okazjonalną pomocą kolegów z Krakowa.
Dlatego zwracam się z apelem: jeśli pracujesz w agile/Scrum, wdrażasz gdzieś Scruma albo inną metodę agile i jesteś entuzjast[k]ą tego podejścia, to możesz:
- opowiedzieć coś ciekawego o Scrumie, XP, Kanban czy innych metodach agile na spotkaniu,
- zorganizować i poprowadzić spotkania w swoim mieście,
- napisać ciekawy artykuł o Scrumie, XP, Kanban czy innych metodach agileowych,
- pomóc PSUG w inny sposób (np. masz rewelacyjny pomysł jak rozwinąć naszą działalność, na którą my nie wpadliśmy).
Napisz do nas i przyłącz się! Pokaż, że w naszym “polskim światku agile” są nie tylko bierni słuchacze! Właśnie planujemy nasze po-wakacyjne spotkania, to dobry czas żeby teraz się do nich przygotować.
Nie jesteśmy formalną organizacją, więc nie możemy obiecać honorariów, wierszówek i innych korzyści materialnych. Możemy za to zapewnić, że dzielenie się z innymi swoimi doświadczeniami daje wiele satysfakcji i samo w sobie jest rozwijającym doświadczeniem.
Czekamy na Wasze maile: info@scrum.org.pl .
Lista kontrolna Scrum
W zeszłym roku znany na świecie CST Hernik Kniberg opracował listę kontrolną Scrum. Dzięki niej zespoły mogą dokonywać własnej ewaluacji żeby zobaczyć na jakim etapie znajdują się w procesie implementacji tej metodyki.
Większość materiałów o Scrumie (i Agile w ogóle) jest dostępna w języku angielskim. Dla niektórych nie jest to przeszkodą, ale bywa że jest inaczej. Właśnie w związku z tym postanowiłem przetłumaczyć Scrum Checklist na polską “Listę Kontrolną Scrum”, która dostępna jest tutaj.
Poniższy tekst jest tłumaczeniem artykułu umieszczonego na stronie: http://www.crisp.se/scrum/checklist i pozwala zrozumieć czym ta lista jest i jak jej używać.
Co to jest?
“Lista Kontrolna Scrum” jest prostym narzędziem pozwalającym wystartować ze Scrumem lub sprawdzić na etap implementacji Scruma.
To nie są zasady. To są wytyczne. Zespół liczący 2 osoby może zdecydować się nie robić codziennego Scruma (Daily Scrum), ponieważ programują w parze przez cały dzień i nie potrzebują osobnego spotkania na synchronizację. To jest w porządku. Świadomie ominęli praktykę Scruma, ale zapewnili że cel przyświecający tej praktyce został osiągnięty w inny sposób. I to się liczy!
Jeżeli już stosujesz Scrum może warto żeby zespół przeszedł wspólnie przez tą listę na retrospekcji? Oczywiście, traktując ją jako narzędzie do dyskusji, nie do oceniania.
Jak korzystać z listy kontrolnej?
• Robert: “Przyniosłem użyteczną listę kontrolną na tą retrospekcję. Jest coś na tej liście czego nie robimy?”
• Monika: “Hmmm, zobaczmy. Wygląda na to że na pewno nie mamy ‘Kryterium ukończenia’ i nie mierzymy prędkości”
• Robert: “‘Kryterium ukończenia’ jest wymienione jako ‘Podstawa Scruma’ więc wydaje się być całkiem ważne! Prędkość jest pod ‘Rekomendowane ale nie zawsze potrzebne’, więc poczekajmy z tym i zacznijmy z rzeczami podstawowymi”
• Monika: “Popatrz, nie spełniamy także ‘Dostarczanie działającego, przetestowanego oprogramowania co 4 tygodnie lub szybciej’. To jest wymienione jako ‘Kwintesencja’. Brzmi sensownie, bo marketing zawsze na to narzeka!”
• Robert: “Może koncepcja ‘Kryterium ukończenia’ może nam pomóc w braniu mniejszych porcji do sprintu i umożliwi częstsze robienie wydań?”
• Monika: “Dobry pomysł, spróbujmy!”
Jak NIE używać listy kontrolnej?
• Wielki szef: “Ok zespole, zobaczmy jak zgodny ze standardem jest Wasz Scrum. Wypełnijcie proszę listę kontrolną”
• Robert: “Szefie, cieszę się że mogę Ci powiedzieć że robimy wszystko. W zasadzie wszystko poza Burndown chart””
• Wielki szef: “Niedobry, niedobry zespół! Z listy wynika że powinniście robić te…burny…czy coś! Ja je chcę!”
• Monika: “Ale my robimy 2-tygodniowe sprinty i prawie zawsze dostarczamy to, do czego się zobowiązaliśmy, a klienci są zadowoleni. Na tym etapie Sprint burndown chart nie wniesie żadnej wartości.”
• Wielki szef: “Z listy wynika że powinniście to robić, więc nie pozwólcie żebym znowu Was przyłapał na oszukiwaniu, albo wezwę Policję ds Scruma!”
Czy to oficjalna lista kontrolna?
Nie. Lista została zrobiona przez Henrik Kniberga i wyraża jego osobiste i subiektywne opinie na temat tego co tak naprawdę jest ważne w Scrumie. Poświęcił kilka lat pomagając firmom zacząć pracę ze Scrumem, spotkał setki innych praktyków, trenerów i coachów; i przekonał się że stosowanie list kontrolnych jest pomocne, jeżeli odpowiednio się z nich korzysta.
Co ze starą wersją?
Stara lista kontrolna (w postaci mindmapy) jest ciągle dostępna. Jednak jest już w obiegu dosyć długo, a nowa jest wg Henrika dużo lepsza.
Gdzie mogę podzielić się swoją opinią?
Jeżeli chciałbyś podzielić się opinią na temat listy kontrolnej lub zaproponować jej usprawnienie napisz emaila na henrik.kniberg(AT)crisp.se (po angielsku). Jeżeli masz uwagi do polskiego tłumaczenia napisz na b.kobylecki(AT)gmail.com lub po prostu napisz komentarz poniżej.
Scrum a kultura bylejakości
Ostatnio miałem okazję obserwować jak w pewnym zespole (a właściwie dwóch) Scrum nie daje oczekiwanych rezultatów. Pomimo szkoleń, zatrudnienia Certyfikowanych Scrum Masterów nadal problemem jest niska jakość tworzonego oprogramowania, chaotyczność pracy, nieprzewidywalność rezultatów.
Jak się wydaje wynika to z jednego podstawowego problemu, który trudno określić inaczej niż “kultura bylejakości”. Jest to połączenie niemożności osiągnięcia zakładanego poziomu jakości tworzonego systemu z akceptacją tego stanu rzeczy przez otoczenie obu zespołów. Ta akceptacja jest pełna rezygnacji, by nie powiedzieć fatalizmu, zwłaszcza ze strony kluczowych odbiorców systemu (oba zespoły budują systemy wewnętrzne) – ale jest. Efektem jest funkcjonowanie całkiem poważnie nastawienia, które najlepiej oddał jeden ze Scrum Masterów mówiąc do zespołu “wydajmy to na produkcję – juzerzy nam to przetestują”. Najbardziej niebywałe jest tu to, że nikt nie zaprostestował.
Przy takim podejściu katastrofa (w postaci spektakularnego padu krytycznego dla firmy systemu) tylko czeka aby się wydarzyć, a praca obu zespołów jest pasmem “marszów śmierci”, następujących po nich okresów letargu i stałego gaszenia pożarów.
Nie wchodząc zbytnio w szczegóły warto pochylić się nad tymi przypadkami, bo mają one – niestety – nie tylko szanse stać się przykładem, że Agile ogólnie a Scrum szczególnie “nie działa”, ale wydają się być dość typowe.
Jak mi się wydaje najistotniejszym wnioskiem jaki z nich wypływa jest taki, abyśmy zawsze pamiętali to, co wbijane jest do głów na każdym (porządnym) szkoleniu scrumowym – Scrum nie rozwiązuje sam ze siebie żadnych problemów, Scrum jedynie czyni je widocznymi. Scrum to nie panaceum, nie uczyni cudów.
Nie da się zatem przy pomocy Scruma i Agile przerobić grupy studentów bez solidnych podstaw informatycznych na sprawny zespół programistów. Zanim zacznie się stosować praktyki XP i pracować w krótkich sprintach w Scrumie trzeba na początek umieć dobrze obiektowo modelować i programować, trzeba umieć pisać czytelny kod (np. mieć nawyk stosowania sensownych nazw obiektów, metod i zmiennych czy pisania sensownych komentarzy), mieć pojęcie o wzorcach projektowych, umieć je stosować i tak dalej. Trzeba wreszcie posiadać wiedzę o stosowanej technologii, a więc o języku w którym się pisze i jego właściwościach, właściwościach stosowanych kompilatorów czy interpreterów i innych związanych z danym językiem narzędzi.
Trzeba też umieć korzystać z frameworków i bibliotek – a więc przede wszystkim mieć świadomość ich istnienia, a także wad i zalet by móc odpowiednio dobrać je do swojego projektu. Trzeba wreszcie umieć właściwie wykorzystać środowisko pracy, takie jak systemy kontroli wersji, błędów, automatycznych buildów itp. No i oczywiście cały szeroki świat testów – nie dość, że trzeba mieć nawyk ich pisania oraz wykonywania – trzeba także mieć umiejętności i narzędzia. To właśnie braki tej podstawowej wiedzy i związanych z nią praktyk decydują o wspomnianej wyżej niemożności jaka trapi oba zespoły.
Oczywiście, wszystkiego można się nauczyć – ale trzeba mieć od kogo. Jeśli w zespole wszyscy są mniej-więcej równie początkujący jego rozwój jest znacznie utrudniony jeśli nie niemożliwy. Zdecydowanie lepiej jest, jeśli w zespole przynajmniej część stanowią doświadczeni programiści i testerzy, którzy mogą pomóc “świeżym” kolegom w rozwoju. W przeciwnym razie praktyki takie jak przeglądy kodu czy programowanie w parach niewiele dają – przeciwnie, petryfikują wręcz niski poziom i jako “bezsensowne” są szybko zarzucane.
Równie toksyczna i prowadząca do utrwalania się dysfunkcji zespołu – który miast miejscem rozwoju staje się miejscem walki z problemami dawno już rozwiązanymi gdzie indziej – jest akceptacja marnych wyników przez odbiorców i kierownictwo.
I tu dotykamy innego problemu – otóż niezwykle często myli się u nas samoorganizację i inne cechy Scruma z brakiem zarządzania. Tymczasem samoorganizacja dokonuje się wokół celów, które to cele ktoś z zewnątrz musi postawić i wymagać ich osiągania. Jakość jest jednym z takich celów – jakość nie jest jakimś regulowalnym parametrem (niczym na linii produkcyjnej), przeciwnie – pewien ustalony poziom jakości tego co jest budowane (będący potem podstawą kryterium ukończenia) jest jednym z celów służących samoorganizacji zespołu.
Ale samoorganizacja wymaga nie tylko celów – wymaga również presji. Samoorganizacja nie nastąpi jeśli zobowiązanie zespołu do wykonania tego co wziął “do sprintu” nie jest traktowane poważnie. A poważne traktowanie oznacza nie tylko świętowanie osiągnięcia celu sprintu podczas przeglądu (sprint review) – oznacza także poważne traktowanie porażek. Wymaga to od zarządzających takimi zespołami subtelności, stanowczości ale przede wszystkim konsekwencji – zespół musi dobrze rozumieć, że zawiódł; musi zdawać sobie sprawę z tego, że nie jest dobrze (no bo jeśli jest dobrze – to po co coś poprawiać?).
I tu dochodzimy do najistotniejszego – dobra firma czy dział tworzący oprogramowanie to taki, gdzie sprawy takie są dla wszystkich oczywiste. A więc jest dla każdego jasne, że fuszerka to fuszerka i trzeba się jej wstydzić (niezależnie od tego czy na wierzchu działa czy nie), że system krytyczny dla firmy ma działać zawsze a wszelkie zaburzenia tego stanu rzeczy są porażką dla zespołów i plamą na ich profesjonaliźmie. To jest właśnie kultura jakości, w której metody agile kwitną i pomagają. Bez niej – w kulturze bylejakości, a więc akceptacji marności rezultatów i mierności wysiłków – Scrum, Agile – czy w ogóle inne metodyki działające na innym poziomie abstrakcji nie przyniosą oczekiwanych efektów.
Dlatego zanim będziemy próbować wdrażać gdzieś Scruma upewnijmy się, że środowisko w ogóle się do tego nadaje – że sypiemy ziarno na żyzną glebę kultury jakości, a nie na uklepany nawykiem ugór bylejakości. I jeśli to konieczne lepiej zacząć pracę od postaw, od budowania kultury jakości, nawet jeśliby to była przysłowiowa “orka na ugorze”.
Andrzej K. Brandt
Code Sprinters
Polecamy!
Kalendarz
« stycznia 
marca » luty 2012 P W Ś C P S N 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
