blog.testowka.pl

Agile

Światełko w tunelu dla Skalowania Agile

opublikowany przez 17, Gru, 2014, w kategoriach Agile, Scrum, Zarządzanie

Ci z Was, którzy znają mnie nie od wczoraj dobrze wiedzą, że nie jestem zwolennikiem żadnej z coraz popularniejszych „metod” skalowania Agile. Często wypowiadam się na ten temat i przeważnie negatywnie.

„Jeśli skalujesz Agile to robisz to źle.”

Wszystkie znane mi do tej pory metody i frameworki z SAFe (Scaled Agile Framework), Scrum of Scrums  i Agility Path na czele próbują narzucić rożne zasady i reguły, które maja być mniej lub bardziej uniwersalne dla każdej organizacji. To po prostu nie ma prawa działać.

Miałem okazję przez ostatnich kilka lat pracować z wieloma organizacjami, niektóre z nich były całkiem duże. Na tyle duże, że musiały zmierzyć się z problemem skalowania. Najczęstszym błędem który podczas takich prób zmierzenia się ze skalowaniem widziałem była próba zastosowania danej metody skalowania bez uprzedniego zastanowienia się nad problemami, które chce się rozwiązać.

Większość promowanych „metod” ze znajomości, których można sobie zrobić (kupić) różne certyfikaty których ładnie brzmiące nazwy możemy sobie później wpisać na linkedin według mnie nie rozwiązuje podstawowych problemów, lecz wręcz przeciwnie poprzez swoją pozorną prostotę i obietnicę naprawienia wszechświata generują więcej problemów niż rozwiązują. Nie – nie neguję wartości tych metod (nie wszystkich i nie całkowicie – tylko trochę) – niektóre z nich świetnie działają w pewnym kontekście. Niektóre pojedyncze elementy tych metod bazują przecież na prawdziwych wartości Agile i Lean jedyne co jest z nimi nie tak to próba zbudowania z nich zamkniętego narzędzia o uniwersalnym zastosowaniu.

Ktoś zarzucił mi nawet że jestem egoistą który twierdzi, że ludzie pracujący w dużych organizacjach nie zasługują na Agile. Hmm, niektórzy ludzie, w niektórych organizacjach – tacy, którzy nie chcą niczego zmienić, albo boją się zmian być może nie tyle nie zasługują na Agile  co Agile mógłby im zaszkodzić więc to raczej nie jest dla nich.

Powyższe nie oznacza, że nigdy z problemem skalowania się nie mierzyłem i nie mam w tym żadnego doświadczenia. Osobiście do tematu skalowania zawsze podchodziłem na kilku płaszczyznach i za każdym razem, w każdej organizacji wygląda to zupełnie inaczej, niemniej jednak często powtarzają się pewne tematy.

Pierwsze zadawane przeze mnie pytanie tyczy się tego dlaczego dana organizacja jest na tyle duża, że potrzebuje jakiejś metody skalowania?

To pytanie może wydawać się proste, ale w większości przypadków próba zastanowienia się nad odpowiedzią prowadzi do źródeł wielu innych problemów, których rozwiązanie pozwala uniknąć potrzeby zastosowania metod skalowania. Czasem okazuje się, że wystarczy organizację podzielić na mniejsze, bardziej niezależne komórki skupione wokół poszczególnych produktów lub komponentów i okazuje się, że niczego nie trzeba skalować. Czasem dochodzimy do wniosku, że problemy, które chcemy rozwiązać są gdzieś indziej niż adresują to różne metody skalowania i wystarczy właśnie tam skupić swoją energię. To co niewątpliwie jest potrzebne w każdej organizacji bez względu na wielkość to określona metoda wspomagająca proces Continuous Improvements.

Drugie pytanie dotyczy tego co rozumiemy przez skalowanie?

Skalować możemy organizację zapewniając odpowiedni framework wymiany wiedzy oraz zapewniania transparentności i możliwości ciągłej inspekcji i adaptacji na wielu (wszystkich?) poziomach organizacji. Każda organizacja jest inna i narzucanie tutaj odgórnie struktury (tak jak próbuje to zrobić SAFe) jest raczej wątpliwie skuteczne. Czasem oczywiście (zwłaszcza gdy mamy do czynienia z chaotyczną organizacją o wątpliwej strukturze) narzucenie struktury jest świetnym posunięciem – tutaj SAFE z pewnością się sprawdza (przyznam, że jako konsultant poleciłem kilka razy SAFe właśnie w takich przypadkach).

Skalowanie to również skalowanie produktu. Jeśli mamy do czynienia z monolitycznym produktem, z dużym legacy i długiem technicznym to wartość wdrożenia jakiejkolwiek metody skalowania będzie raczej znikoma. Często do tego problemu docieramy zadając pierwsze pytanie powyżej – to taka architektura często jest przyczyną nadmiernego wzrostu organizacji.

Trzecie pytanie to w zasadzie obserwacja tego jak w tej chwili wygląda organizacja i w jaki sposób podejmowane są decyzje?

Wizualizacja tego procesu często jest już wystarczającym krokiem w kierunku poprawy i usprawnień. Value Stream Mapping i zaangażowanie odpowiednich osób w dyskusję może bardzo pomóc.

Następnie jest czas na pytania o to czy istnieje coś takiego jak wizja organizacji i wizja produktu? Jak ta wizja, misja i deklarowane wartości są reprezentowane przez realne, codzienne działania? Czy wizja jest klarowana i transparentna? Czy wszyscy w organizacji są jej świadomi? Czy mają na nią wpływ? Czy ludzie w organizacji utożsamiają się z wartościami deklarowanymi przez organizację.

Mając jasną wizję produktu możemy ją dekomponować na pracę dla poszczególnych zespołów produktowych. Mając jasną wizję organizacji możemy ją dekomponować i uskuteczniać w pętli Inspect & Adapt na poziomie każdego zespołu i całej organizacji.

 

W powyższy (opis mocno uproszczony) sposób staram się pracować z organizacjami już od dłuższego czasu dlatego też wczorajszego wieczoru zainteresowała mnie prezentacja mówiąca o „nowym” podejściu do skalowania: Scrum at Scale proponowana przez Scrum Inc. Tak jak w tytule jest to niewątpliwie światełko w tunelu dla osób poszukujących odpowiedzi na pytanie jak skalować organizację. Czy to światełko okaże się oczekiwanym rozwiązaniem wielu problemów czy może raczej nadjeżdżającym pociągiem? Myślę, że wszystko zależy od tego jak to dalej się potoczy i w którym kierunku popchną tą „metodę*” jej „twórcy**”. Na szczęście nie  ma (jeszcze) zmyślnej ścieżki certyfikacji co moim zdaniem daje nadzieję, na to, że ktoś faktycznie chce pomagać organizacjom a nie tylko i wyłącznie trzepać kasę kopiując model szkoleń i certyfikacji CSM i PSM z przed lat (za pierwszym razem to miało sens i wnosiło wartość – teraz certyfikatów na rynku zdaje się być kilkadziesiąt razy więcej niż możliwych do zastosowania w praktyce metod).

Z pewnością w najbliższym czasie będę chciał się bliżej przyjrzeć tej metodzie. Być może za jakiś czas przeczytacie o tym jak bardzo się myliłem i to tylko kolejny marketingowy BS, który ktoś próbuje wcisnąć ludziom z problemami zamiast pomóc im naprawdę te problemy zdiagnozować i rozwiązać…

 

*Scum at Scale cieżko jest mi nazwać metodą – to raczej zbiór kilku celów czy problemów które każda organizacja powinna zastosować. Ciekawą ideą jest wspomniana modułowość  proponowanego rozwiązania.

**Nie jest to też nic nowego bo podstawy są zbliżone chociażby do tego co można było znaleźć w początkowych wersjach SAFe, na pierwszy rzut oka widać też, że twórcy dużo inspiracji czerpią od takich autorów i myślicieli ze świata Lean i Agile jak chociażby Mary i Tom Poppendieck (Lean Software Development) czy Tom Gilb (Evo Method)

1 komentarz więcej...

Ilu Agile Coachów potrzeba by wymienić żarówkę? – Agile Coach Camp PL 2014

opublikowany przez 20, Paź, 2014, w kategoriach Agile, ALE, Coaching, Kanban, Scrum

20141017_171017

W ten weekend miało miejsce niezwykłe jak naszą krajową społeczność wydarzenie – Agile Coach Camp. Blisko 60 mniej lub bardziej doświadczonych Agile Coachów, Scrum Masterów, Product Ownerów i Developerów przyjechało do Srebrnej Góry by przez 2 dni wymieniać się swoją wiedzą i doświadczeniami.

Nie było agendy, nie było prelegentów, nie było nawet ŻADNYCH slajdów! 60 osób z potężnym bagażem doświadczeń i wiedzy pracujących razem nad rozwiązaniem wielu problemów i uspójnieniem wiedzy. Duch ALE  był tam razem z nami, nowe znajomości, nowi przyjaciele, nowe perspektywy.

Pierwszy Agile Coach Camp odbył się pod hasłem „Prepare to be suprised”. Co zatem zaskoczyło mnie najbardziej?

Przede wszystkim zaskoczyłem się tym, jak wielu świetnych, doświadczonych Agile Coachów z Polski nie miałem okazji wcześniej poznać. Zaskoczył mnie niezwykle wysoki poziom wiedzy uczestników. Przyznam szczerze, że nie miałem oczekiwań przed tym wydarzeniem a mimo to bardzo wiele z niego wyciągnąłem.

To niesamowite jak nasza Agileowa społeczność wyewoluowała i dorosła na przestrzeni ostatnich kilku lat. Podczas podsumowania ACCPL nawiązałem do tego, że jeszcze 6-7 lat temu, kiedy dopiero zaczynała się moja przygoda z Agila nikt nie przypuszczał, że dojdziemy tak daleko. Wtedy ze świecą szukać można było tych którzy o Agile w ogóle słyszeli, a źródeł wiedzy na ten temat było bardzo niewiele. Dzisiaj nie tylko możemy wymieniać się wiedzą ogólnie dostępną ale nasze doświadczenia pozwalają nam na wspólne opracowywanie coraz to lepszych metod pracy. Równie ważne było to, że pomimo obecności wielu trenerów i konsultantów (ja też się w to wpisuje) udało się nam chyba uniknąć wszelkich prób indoktrynacji nowymi „modnymi” metodykami i frameworkami. Chyba nawet Scrum przestał już być „ideologią” i stał się (całkiem niezłym) narzędziem – jednym z wielu, które w dzisiejszych czasach wręcz wypada poznać i spróbować. 20141017_204216

Agile nie jest już niszowym, mało znanym i niesprawdzonym podejście do wytwarzania produktów. Dzisiaj coraz więcej osób wierzy (w oparciu o swoje doświadczenia), że Agile jest w tej chwili w większości przypadków najlepszą z dostępnych opcji.

Super było usłyszeć historie wielu udanych transformacji Agile prosto z naszego podwórka! Tak! W Polsce jest wiele firm, małych i dużych, które dzięki wielkim wysiłkom i pasji wielu ludzi udało się zmienić.

Poza wiedzą było też dużo zabawy – wieczorne dyskusje przy piwie, śpiewy z gitarą, karaoke z laptopa, nocne włóczenie się po lochach w twierdzy, coachowanie pejczem (ci co nie byli niech nawet nie próbują się domyślać ;-)), gry i zabawy typu jakiej wymówki używa zespół gdy nie dowiezie? („Bo pies pożarł mi backlog” okazuje się być niezwykle częste)… Nie mogę doczekać się kolejnej edycji oraz z chęcią pomogę przy organizacji!

Tych co byli serdecznie pozdrawiam, a tych co nie byli serdecznie zapraszam na kolejne edycje. Miejmy nadzieję, że częściej niż raz do roku – bo Agile to w końcu krótkie iteracje i szybki feedback, nie?

To ilu Agile Coachów potrzeba by wymienić żarówkę???

5 komentarzy więcej...

Perfection Game – czyli prosty, wartościowy feedback

opublikowany przez 09, Wrz, 2014, w kategoriach Agile, Coaching, Scrum, Zarządzanie

„Perfection Game” to prosta metoda pomocna w sytuacjach gdy potrzebujemy zebrać feedback od innych osób, lub gdy sami chcemy komuś dać feedback. Jak sama nazwa wskazuje metoda ta może być użyteczna zwłaszcza gdy w jakimś obszarze chcemy dojść do perfekcji.

Formuła

Formuła Perfection Game jest stosunkowo prosta – polega na odpowiedzi na trzy pytania:

  • Oceniam <ten produkt, usługę, wydarzenie, spotkanie> na … w skali od 1-10
  • To co mi się podobało to …
  • Aby ocenić <ten produkt, usługę, wydarzenie, spotkanie, etc> na 10 zmieniłbym …

(W miejscu … wstawiamy swoje odpowiedzi).

Istotne jest to aby zwłaszcza w przypadku trzeciego pytania formułować wypowiedź z perspektywy pierwszej osoby – co JA bym zmienił. Nawet w formie: Gdybym to ja prowadził to spotkanie to aby dostać lepszą ocenę zrobił bym…

Żadne pytanie nie może pozostać bez odpowiedzi.

Jak to działa?

Odpowiadając na pierwsze pytanie dajemy informację jak w naszej subiektywnej ocenie wypadł przedmiot oceny. Skala od 1-10 gdzie 1o oznacza, że to co ocenialiśmy jest w naszej subiektywnej ocenie niemal perfekcyjne i nie wymaga większych zmian – a przynajmniej spełniło nasze oczekiwania i nie chcemy żeby cokolwiek ulepszać.

Drugie pytanie wymusza na oceniającym/dającym feedback wskazanie pozytywnych obszarów. Dzięki temu zarówno z perspektywy dającego feedback jak i otrzymującego feedback całościowa ocena nie ma tylko i wyłącznie wydźwięku negatywnego. Nawet oceniający niejako zmuszając się do znalezienia pozytywnych aspektów w przedmiocie oceny delikatnie zmienia swoje nastawienie i pozwala spojrzeć na problem z innych perspektyw. Dodatkowo takie podejście może mieć też pozytywny wpływ na kreatywne poszukiwanie punktów do poprawy/ulepszeń.

Trzecie pytanie zwłaszcza, gdy odpowiadamy na nie z perspektywy pierwszej osoby – co ja bym zmienił/ulepszył daje to co w feedbacku jest najważniejsze – konstruktywną krytykę. Nie oceniamy negatywnie tego co jest ale konstruktywnie zastanawiamy się nad tym co można by ulepszyć. Dzięki temu nawet gdy oceniamy coś co jest „beznadziejne” w naszej ocenie osoba, która będzie czytała nasz feedback będzie w stanie wyciągnąć konstruktywne wnioski i zastanowić się nad tym co konkretnie poprawić.

Zastosowanie

„Perfection Game” można zastosować w wielu różnych sytuacjach.

Retrospekcja

Możemy skorzystać z „Perfection Game” na przykład do oceny tego w jaki sposób pracowało nam się w ostatnim Sprincie. Dzięki takiemu feedbackowi od razu mamy wygenerowanych sporo ciekawych pomysłów na temat tego, co można by ulepszyć i zrobić lepiej.

Rozmowa rekrutacyjna

Z powodzeniem stosujemy ten format podczas rozmów rekrutacyjnych z naszymi pracownikami. Bez względu na to czy kogoś zatrudnimy czy nie staramy się dać konstruktywny feedback by dana osoba mogła popracować nad swoimi umiejętnościami i wiedzą. Można też korzystać z tej formy w ramach regularnych rozmów z pracownikami/kolegami z zespołu na temat ich postępów w pracy.

Ocena produktu/Inkrementu po Sprincie

Możemy użyć tej formuły do oceny produktu naszej pracy. Możemy też  w ten sposób dać komuś feedback na temat pomysłów dotyczących dalszej pracy nad produktami.

Moja historia z Perfection Game w tle

Ten sposób dawania feedbacku znałem już od dłuższego czasu niemniej jednak prawdziwą moc „Perfection Game” poczułem w momencie gdy sam zacząłem dawać taki feedback podczas oceny zgłoszeń prezentacji na ALE2014. Początkowo nie wychodziło mi to zbyt dobrze i odpowiedzi były raczej koślawe, ale z czasem, gdy położyłem większy nacisk na format i na to by feedback był pisany z perspektywy pierwszej osoby myślę, że moje oceny były wartościowe. Prawdę mówiąc chyba wszyscy prezenterzy, którzy otrzymali nasz feedback w tej formule i na jego podstawie ulepszyli swoje prezentacje zostali zaakceptowani w drugiej rundzie ocen prezentacji (nawet, gdy za drugim razem prezentacje oceniał ktoś inny niż poprzednio) – to chyba faktycznie pokazuje wartość tej metody. Przyznam, że w kilku przypadkach musiałem spędzić naprawdę sporo czasu nad przemyślenie konstruktywnego feedbacku Znacznie łatwiej jest po prostu krytykować i mówić o tym co się nie podoba niż wymyślić co konkretnie powinno zostać poprawione i jak tak by przestało się mi to nie podobać.

Perfection Game staram się używać też często podczas szkoleń i agile coachingu aby ocenić to jak wartościowy dla uczestników był czas spędzony razem ze mną. Wielokrotnie dzięki temu podejściu udało mi się zebrać bardzo wartościowy feedback i konstruktywne uwagi, które pozwoliły znacznie ulepszyć moje usługi (czasem bardzo ogólnie, a czasem w kontekście danego klienta/zespołu).

 

2 komentarze więcej...

Ludzie zawsze podejmują najlepsze z możliwych decyzji – a managerowie?

opublikowany przez 22, Lip, 2014, w kategoriach Agile, Zarządzanie

decisionPisałem blisko rok temu o postawie coacha i o kilku faktach na temat nas samych którymi coach powinien się kierować. Jedną z przytoczonych przeze mnie prawd było stwierdzenie, że „Ludzie zawsze podejmują najlepszą z możliwych decyzji w oparciu o informacje, którymi dysponują”.

Tak, zdaję sobie sprawę z tego jak bardzo kontrowersyjne jest powyższe stwierdzenie. Wielokrotnie sam też miałem wątpliwości co do jego poprawności zwłaszcza obserwując osoby decyzyjne w firmach zajmujących się różnymi rzeczami (nie tylko IT).

Managerów można podzielić na tych dobrych i tych złych – na tych, którzy w naszej ocenie podejmują dobre decyzje i na tych, których decyzje nie są najlepsze (z naszej perspektywy). Często też upływ czasu pokazuje, że nasza perspektywa i obserwacje były poprawne i manager się mylił od samego początku.

Ale jak to? Przecież podejmował najlepszą z możliwych decyzji w oparciu o informacje które posiadał… No właśnie, pytanie brzmi czy posiadał wszystkie informacje jakie mógł zdobyć w danym momencie? Czy zrobił wszystko by te informacje pozyskać? Czy zadał odpowiednie pytania odpowiednim osobom? Czy może po prostu podjął decyzję na podstawie tego co wiedział w danym momencie?

Miałem przyjemność w swojej karierze pracować z wieloma managerami/osobami decyzyjnymi – zarówno jako pracownik, współpracownik jak i doradca czy agile coach. W mojej ocenie dobrego managera charakteryzuje właśnie ta dociekliwość i umiejętność pozyskania jak największej ilości informacji potrzebnych do podejmowania decyzji. Jednocześnie kluczowe jest podejmowanie decyzji wystarczająco szybko by nie powodować niepotrzebnych opóźnień.

Dlatego też radzę wszystkim osobom decyzyjnym, a przecież wszyscy podejmujemy na co dzień – zarówno w pracy jak i w życiu osobistym różne decyzje, by zanim powiedzą ostatnie słowo i przejdą do działania upewnili się, że informacje, które posiadają są względnie kompletne i prawdziwe.

4 komentarze więcej...

5 poziomów wymagań i specyfikacji

opublikowany przez 16, Lip, 2014, w kategoriach Agile, BDD, Scrum, Specyfication By Example, User Stories

Ten wpis jest (powiedzmy, że) kontynuacją wpisu „Wymagania != Specyfikacja

Piramida wymagań

Jeśli mówimy o wymaganiach i specyfikacji i wprowadziliśmy już rozróżnienie tego czym są wymagania i czym jest specyfikacja, oraz że istnieje specyfikacja funkcjonalna oraz specyfikacja techniczna to teraz możemy swobodnie przemyśleć to jak zkategoryzować poszczególne poziomy wymagań i specyfikacji.

Jak w tytule pozwoliłem sobie na wyróżnienie pięciu poziomów wymagań i specyfikacji, które można by przedstawić w postaci na przykład piramidy (Wygląda na to, że ludzie w IT lubią piramidy, nie wiem dlaczego…).

Na szczycie piramidy mamy pierwszy poziom: Jaki jest cel naszego przedsięwzięcia? 

Odpowiadając na pytanie po co nasza organizacja istnieje i po co tworzy produkty najprawdopodobniej dojdziemy do odpowiedzi, że oczywiście robi to dla pieniędzy. Tak, pieniądze i ich zarabianie są celem niemalże każdego biznesu (bezpośrednio lub pośrednio – np. zyski wizerunkowe, które później się monetaryzują). Warto o tym pamiętać bez względu na to gdzie w strukturach organizacji się znajdujemy bez względu na to czy tworzymy produkty dla naszej własnej organizacji czy jesteśmy jedynie dostawcami usług dla klientów/organizacji zewnętrznych. Aby osiągnąć cel (zarabianie pieniędzy) organizacja wytwarza pewne produkty – w IT mamy obecnie do czynienia raczej nie tyle z produktami w sensie wytwarzaniem pewnych dóbr materialnych co tworzeniem produktów będących narzędziami do świadczenia usług. Tworzymy produkty, które świadczą pewne usługi dla użytkowników końcowych za które są oni gotowi zapłacić.

Drugim poziomem jest odpowiedź na pytania: Kto jest interesariuszem naszego produktu i jakie problemy próbuje rozwiazać? 

Kto jest naszym odbiorcą i jest gotów zapłacić za „rozwiązanie” swoich problemów, spełnienie potrzeb? Jakich problemów i potrzeb? Warto pamiętać, że dla interesariuszy celem nadrzędnym też są raczej pieniądze więc myśląc nad produktami powinniśmy brać pod uwagę to w jaki sposób my możemy zarobić na tym, że zarabiają (oszczędzają) nasi klienci?

Mając problemy do rozwiązania i grupę odbiorców docelowych naszych rozwiązań mamy właściwie wysoko-poziomową definicję produktu.

Trzecie poziom to zdefiniowanie tego co będzie robił, czy też jakie funkcjonalności będzie zawierał nasz produkt by rozwiązać powyższe problemy interesariuszy?

Powyższe trzy poziomy to wymagania – co nasz produkt będzie robił by rozwiązać konkretne problemy, konkretnych interesariuszy. Na tym poziomie mamy zdefiniowane na pewnym poziomie abstrakcji ficzery naszego produktu. Możemy przystąpić do badania rynku i sprawdzania naszej hipotezy, że odbiorcy faktycznie potrzebują rozwiązać te problemy i są gotowi za nie zapłacić.

Czwarty poziom to  Specyfikacja Funkcjonalna – czyli odpowiedź na pytania w jaki sposób nasz produkt rozwiązuje problemy interesariuszy, jakie konkretne funkcjonalności dostarcza? 

Tutaj specyfikujemy jakie konkretnie funkcje naszego produktu użytkownicy będą mieli do dyspozycji. Możemy zbadać czy dane funkcjonalności są faktycznie przez użytkowników używane – czy są im potrzebne?

Piąty poziom to Specyfikacja Techniczna – w jaki sposób działają poszczególne funkcjonalności oraz jak są zaimplementowane?

Czwarty i piąty poziom to obszary w których możemy (a nawet powinniśmy) pokusić się o wykonywanie testów A/B i ciągłe usprawnianie dostarczanych przez nas funkcjonalności, tak by jeszcze lepiej spełniały oczekiwania użytkowników.

Na zakończenie jedna ważna uwaga: Nawet jeśli świetnie zdefiniujemy założenia co do wymagań i specyfikacji w naszym produkcie oraz poprawnie to zaimplementujemy to wcale nie znaczy, że nie mogą się one zmienić – to rynek zwaliduje czy mieliśmy rację. Dlatego też tak istotne jest testowanie naszych hipotez oraz wydawanie nowych wersji produktów – eksperymentowanie jak najczęściej, wprowadzając minimalne inkrementalne zmiany.

-==C.D.N==-

5 komentarzy więcej...

Podsumowanie Quality Excites 2014

opublikowany przez 02, Cze, 2014, w kategoriach Coaching, Jakość, Konferencje, Testowanie

qe

W sobotę miała miejsce już trzecia edycja darmowej konferencji Quality Excites 2014 w Gliwicach, organizowanej przez firmę Future Processing. Uczestniczyłem w tym wydarzeniu jako prelegent po raz trzecie – dzięki temu miałem okazję od samego początku przyglądać się temu jak rozwija się samo wydarzenie jak i firma je organizująca.

Może zacznijmy od organizatorów – nie wiem za wiele o FP bo nigdy tam nie pracowałem, ale znam tych ludzi i wiem, że jakość ma dla nich znaczenie. Teraz odwiedzając ich biuro mogłem zobaczyć postępy jakie poczynili. Gdy dwa lata temu byłem tam po raz pierwszy to w miejscu obecnego kompleksu biurowego była dziura w ziemi. W tej chwili stoi tam nowoczesny kompleks biurowy z kantyną, siłownią, centrum spa, zjeżdżalniami(!) i wieloma innymi fajnymi rzeczami wspierającymi kreatywną pracę. Niewiele jest w naszym kraju firm zdających sobie sprawę z tego, że ich największym kapitałem są ludzie i ich wiedza, a do tego jeszcze inwestujących w ten kapitał nie ilościowo ale jakościowo.

O samej konferencji można by napisać wiele. Zacznę od tego, że jest to jedyna (znana mi) konferencja w tym kraju, na której testerzy i programiści mówią tym samym językiem. Jest to wydarzenie skierowane zarówno do testerów, programistów, managerów, analityków poświęcone jednemu – bardzo ważnemu tematowi: szerokiej jakości oprogramowania. W programie znalazły się prezentacje zarówno o testowaniu, automatyzacji testów, wymaganiach, metrykach jak i praktykach  i narzędziach developerski. A wisienką na torcie był wykład o tym Kim jest Agile Coach według Krysitana Kaczora zamykający konferencję.

Oprócz wykładów, równolegle odbywały się niesamowicie ciekawe warsztaty prowadzone przez praktyków z Future Processing. Najciekawsze były oczywiście rozmowy w kuluarach i podczas afeter party. Spotkałem wielu starych znajomych i poznałem jeszcze więcej nowych. Zaskakująco miło mi, gdy ktoś w rozmowie odnosi się do tematów, o których mówiłem na poprzednich konferencjach i innych wydarzeniach. To znaczy, że to co robię ma jakieś znaczenie i nie ginie w przestrzeni – zostaje w głowach przynajmniej jednostek, które z sukcesami stosują tą wiedzę w praktyce.

Future Processing z Quality Excites byli chyba pierwsi jeśli chodzi o niekomercyjne wydarzenia tego typu, organizowane na taką skalę. Na szczęście tego typu imprez oraz różnych mniej lub bardziej lokalnych grup entuzjastów jakości przybywa co przekłada się na realne postępy w dziedzinie jakości oprogramowania.

Na koniec jeszcze kilka słów na temat wspomnianego wykładu Krystiana Kaczora – już dawno nie widziałem wykładu na interesujący mnie temat, z którym bym się tak bardzo zgadzał. Sam jakiś czas temu miałem podobne przemyślenia – więcej tu i tu. Tym bardziej cieszę się, że Krystian dołączył do naszego zespołu trenerów w Code Sprinters.

18 komentarzy więcej...

Wymagania != Specyfikacja

opublikowany przez 07, Maj, 2014, w kategoriach Agile, Scrum

„Wymagania” to nie to samo co „specyfikacja funkcjonalna/techniczna”! Wiem, że to nie wydaje się być oczywiste, ale gdyby wszyscy zdawali sobie z tego sprawę to mogli byśmy uniknąć wielu, tak często powtarzających się w IT problemów. Spróbujmy więc to jakoś zdefiniować.

Wymagania (ang. Requirements) – wymagania wobec tworzonej aplikacji to jest to, co ktoś od niej wymaga. Pisząc ktoś mam na myśli kogoś, kto ma jakiś interes w tym, by dane wymaganie zostało zrealizowane – ten ktoś jest więc Interesariuszem (ang. Stakeholder). Interesariusz wymaga od aplikacji, by realizowała ona lub pomagała w realizacji jakichś konkretnych celów. Przeważnie chodzi o cele biznesowe, ale mogą to też być też kwestie związane na przykład z wymogami prawnymi czy zależnościami od innych systemów. Ponad Interesariuszami (przeważnie jest ich wielu) jest jeszcze ogólny cel biznesowy naszej organizacji jakim przeważnie jest generowanie zysków – tak, chodzi oczywiście o pieniądze (choć nie zawsze wprost). Interesariusze wyrażają swoje potrzeby właśnie w postaci wymagań, a więc wymagania opisują to jaki cel ma zostać osiągnięty – czyli to CO aplikacja ma dostarczać. To czego wymagania nie powinny dotyczyć to sposób, w jaki ten cel musi zostać osiągnięty (można podać oczywiście w ramach wymagań jakieś przykłady różnych rozwiązań niemniej jednak nie jest to konieczne).

Większość problemów w wytwarzaniu współczesnych produktów IT bierze się właśnie stąd, że za definiowanie tego jak powinny wyglądać rozwiązania IT biorą się ludzie, którzy nie potrafią tych rozwiązań zaimplementować. Oczywiście robią to nie pytając o zdanie tych, którzy to potrafią. W ten sposób bardzo często powstaje właśnie specyfikacja funkcjonalna – czyli dokumentacja opisująca to JAK system ma spełniać wymagania Interesariuszy. Dokumentacja ta następnie (no może nie tak od razu) jest zazwyczaj przekazywana tym drugim (developerom), którzy implementują te rozwiązania na tyle na ile je rozumieją.

Warto zastanowić się nad tym po co tworzona jest zazwyczaj specyfikacja funkcjonalna? Przeważnie tworzy się ją po to, by za jakiś czas pamiętać o tym co nasz system ma robić i jak ma to robić? Kluczowe jest tutaj „…za jakiś [znacznie dłuższy] czas…”.

Potrzeba istnienia specyfikacji funkcjonalnej sprowadza się do minimum (w zasadzie zależy to tylko od tego, czy z jakiegoś rozsądnego powodu chcemy mieć na przyszłość dokumentację tego, co zostało zaimplementowane), gdy mamy do czynienia z inkrementalnym i iteracyjnym wytwarzaniem oprogramowania jak na przykład w Scrum. Planując pracę na najbliższe dwa tygodnie nie potrzebujemy z góry szczegółowo zapisywać tego jak zamierzamy zaimplementować rozwiązania postawionych przed nami problemów. Zgodnie z zasadą Just In Time – pracujemy w danym momencie nad tym co jest w danym momencie najważniejsze. Przed rozpoczęciem Sprintu przeważnie nie wiemy jak zaimplementujemy dane wymaganie.

Cały ten Agile dotyczy właśnie tego by zbliżyć tych ostatnich w łańcuchu – developerów, do tych z samego początku – Interesariuszy. Chodzi o to, by to właśnie ludzie, którzy mają implementować rozwiązania mogli podejmować decyzje, co do tego jak dane wymaganie zostanie zrealizowane.

To plus rozróżnienie wymagań od specyfikacji to fundamentalne podstawy dobrego zrozumienia metod takich jak Scrum czy BDD. Niestety wydaje mi się, że wiele osób zgubiło to gdzieś po drodze i teraz na przykład piszą User Stories tak, jak by były dokumentacją funkcjonalną. Wielokrotnie spotykałem się z (oczywiście bzdurną) opinią, że User Stories mają być odpowiednikiem dokumentacji funkcjonalnej…

Co w takim razie z analitykami? Nic… Analitycy są potrzebni – bardzo potrzebni! Pomagają zrozumieć domenę biznesową developerom, a także często samym Interesariuszom. Pomagają znaleźć optymalne rozwiązania problemów wyrażonych w postaci wymagań.

Jeśli natomiast Twoja praca sprowadza się głównie do pisania specyfikacji funkcjonalnej, którą później wysyłasz do developerów to przykro mi, ale jest spora szansa, że jesteś dokumentalistą a nie analitykiem (nawet pomimo swoich wybitnych umiejętności w tym zakresie). Analizując problem i poszukując jego rozwiązań należy bowiem brać pod uwagę różne aspekty – a już na pewno kwestie biznesowe oraz możliwości implementacyjne. Dobry analityk będący częścią wskroś-funkcjonalnego zespołu developerskiego wnosi niesamowitą wartość – jeśli tylko rozróżniamy wymagania od specyfikacji funkcjonalnej (patrz powyżej).

Specyfikacja funkcjonalna – czy inna dokumentacja tego typu stanowi zasadniczy koszt wytwarzania oprogramowania i naprawdę warto jest się zastanowić czy mamy doby powód by koszt ten ponosić. Zauważcie, że nie neguję istnienia takiej dokumentacji zawsze i wszędzie – jest z pewnością wiele przypadków, w których jej istnienie jest konieczne! Proszę Was tylko o to, byście zadali sobie pytanie z jakiego powodu taka dokumentacja jest konieczna w Waszym przypadku, oraz zastanowili się, czy odpowiedź na nie ma sens…

–== C. D. N. ==–

4 komentarze więcej...