blog.testowka.pl

5 poziomów wymagań i specyfikacji

opublikowany przez 16, Lip, 2014, kategorie: 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, kategorie: 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, kategorie: 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...

Coding Dojo – TDD Kata

opublikowany przez 31, Mar, 2014, kategorie: Agile, Automatyzacja, CI, TDD, XP

Kanji-shu-ha-ri507
Kilka tygodni temu miałem przyjemność poprowadzić dla jednego z moich klientów krótki warsztat w formie Coding Dojo. Na codzień z tymi zespołami pracujemy nad wdrożeniem Continuous Delivery oraz innych praktyk związanych z Agile. Dojo nie było częścią regularnego Agile Coachingu, ale pomyśleliśmy, że może być dobrą formą oderwania się od codziennej pracy, wyjścia ze strefy komfortu i nauczenia się czegoś nowego. I tak też chyba się stało.

Po pierwsze czym jest Coding Dojo?

Dojo to termin pochodzący z języka japońskiego oznaczający „miejsce treningu”. Odnosił się on do trenowania sztuk walki takich jak Kendo czy Aikido. Nie jest to zwykła sala treningowa, gdyż obowiązują na niej pewne zasady, wchodząc do Dojo zgadzamy się postępować zgodnie z obowiązującymi tam normami.

Coding Dojo to również miejsce gdzie chcemy potrenować nie tyle sztuki walki co sztuki tworzenia kodu. Tutaj też obowiązują pewne zasady, o których za chwilę…

Podczas Coding Dojo zgromadzeni programiści próbują rozwiązać określony problem. W naszym przypadku podeszliśmy do problemu „String Calculator” – prosty kalkulator obliczający sumę parametrów podanych na wejściu. Backlog do tego zadania udostępniłem tutaj.

Zasady

Dojo zorganizowaliśmy w formie TDD Kata oraz podzieliliśmy je na 4 iteracje. Każda iteracja to 30 minut kodowania, 6 minut na code review i 6 minut na wspólną retrospekcję.

Uczestnicy programowali w parach. Po każdej iteracji zmiana pary, poniżej więcej na ten temat.

W przeciwieństwie do typowego Code Retreat po każdej iteracji nie usuwaliśmy wytworzonego kodu tylko kontynuowaliśmy poprzednio zaczętą pracę.

Przebieg Coding Dojo

Pierwsza iteracja to dla większości uczestników pierwsze kroki w TDD (niektórzy mieli już pewną wprawę, niemniej jednak przypomnienie zasad każdemu się przydało) – programujemy zgodnie z zasadą Red -> Green -> Refactor. Co 3 minuty zmienia się osoba przy klawiaturze – to wymuszało komunikację. TDD Kata to ćwiczenie służące do doskonalenia swoich umiejętności.

Po blisko pół godziny tworzenia kodu przyszedł czas na Code Review, ze względu na to, że było około 20 osób postanowiliśmy, że w ramach Code Review wymieszamy pary, praca każdej pary musiała zostać przejrzana przez kogoś z innej pary. Ta praktyka pozwoliła bardzo szybko pokazać różnice pomiędzy parami i poszczególnymi uczestnikami, a następnie pozwoliła wymienić się zdobytą wiedzą i spostrzeżeniami.

I oczywiście wspólna retrospekcja, podczas której rozwiewaliśmy wszelkie wątpliwości i omawialiśmy problemy oraz spostrzeżenia.

W drugiej iteracji wprowadziłem dwie zmiany – po pierwsze postanowiliśmy stosować TDD ping-pong. Jest to metoda programowania w parze polegająca na tym, że pierwsza osoba pisze test, druga pisze funkcjonalność spełniającą ten test, pierwsza refaktoryzuje, druga pisze test itd. To ćwiczenie pozwoliło uczestnikom lepiej dostrzec różnice pomiędzy poszczególnymi etapami w pętli TDD, oraz to czym się różni TDD od Test-First.

Drugą zmianą (nie do końca w mojej ocenie udaną, powinienem zostawić to na trzecią iterację) był zakaz rozmawiania podczas kodowania. Znacznie lepiej było by, gdybyśmy wprowadzili to w następnej iteracji, po tym jak już uczestnicy opanowali podstawy pętli TDD. Celem wprowadzenia tej zasady było wymuszenie pisania na tyle czytelnego kodu by druga osoba mogła łatwo zrozumieć intencje. Niemniej jednak było to całkiem zabawne nawet pomimo tego, że jeszcze nie wszyscy zrozumieli dobrze zasady TDD w tej iteracji. Braki nadrobiliśmy w kolejnej.

Trzecia iteracja po Code Review i Retrospekcji była podobna do poprzedniej z tą różnicą, że teraz można było już rozmawiać. To zaowocowało ożywionymi dyskusjami, oraz dzieleniem się pomysłami, które nagromadziły się w poprzedniej iteracji, oraz podczas Code Review. W efekcie było dużo refactoringu.

Iteracja czwarta – „porzuć swój kod”. Ponieważ w życiu programisty bardzo często bywa tak, że musi grzebać się w kodzie, którego sam nie tworzył postanowiłem podczas naszego Coding Dojo również zrobić taki eksperyment. Tym razem zasada przy dobieraniu się w pary była prosta – wszyscy wstają od komputerów przy których siedzą i starają się dobrać w pary z kimś z kim jeszcze nie programowali oraz wspólnie usiąść przy komputerze przy którym jeszcze nie siedzieli.

Była to chyba jeden z najciekawszych eksperymentów jaki przeprowadzałem na ludziach (i ich kodzie) ;-). To niesamowite jak bardzo różnie można zaimplementować te same funkcjonalności oraz na jak wiele różnych pomysłów można wpaść w zależności od tego z kim się pracuje. Podczas tej iteracji niektórzy zawzięcie refaktoryzowali (pamiętając o zasadach TDD) inni starali się dodawać nowe funkcjonalności przyjmując zastane konwencje.

W ramach przedłużonego Code Review po tej iteracji poprosiłem by wszyscy wracali do wszystkich komputerów, przy których mieli okazję wcześniej pracować i dokładnie przejrzeli co stało się z „ich” kodem odkąd opuścili to miejsce (nie tylko w ostatniej iteracji ale także w poprzednich).

Wnioski

Pojawiło się kilka ciekawych pytań i wniosków oto kilka z nich:

„Tworząc kod w ten sposób widzę, że implementując w sumie prosty problem poprzez stosowanie TDD wydłużył się czas implementacji oraz tak na prawdę spadła jakość tego co zrobiłem – gdybym nie stosował TDD to zrobił bym to szybciej i lepiej”. 

Moja odpowiedź brzmiała: Tak! Gdybyś dzisiaj to zaimplementował bez TDD to zrobił byś to ładniej (i może nawet napisał byś testy). Niemniej jednak w TDD Kata chodzi właśnie o dążenie do perfekcji i doskonalenie swoich umiejętności. Tego typu ćwiczenia wykonujemy właśnie po to, by za którymś razem napisać ten kod jeszcze lepiej i szybciej używając TDD, gdyż ta metoda ma wiele innych zalet, które warte są poświęcenia czasu potrzebnego na jej dobre opanowanie.

„TDD jest proste, gdy tworzymy nową funkcjonalność – a co jeśli mam już sporo kodu i to nawet z testami i nagle przychodzi zmiana wymagań. Co jeśli mam na przykład 5000 testów? Mam teraz szukać i zmieniać wszystkie testy zanim wprowadzę zmiany?”

Moja odpowiedź: jeśli wiesz, które testy trzeba zmienić i możesz to w miarę prosto i szybko zrobić to to zrób. Jeśli nie wiesz to… napisz nowy test, wprowadź testowaną zmianę w zachowaniu aplikacji, odpal testy i zobacz które testy przestały przechodzić. Potem zastanów się czy testy, które przestały przechodzić zrobiły to. bo zmieniło się zachowanie, czy dlatego, że coś zepsułeś. Następnie przemyśl, czy poprawiając testy przypadkiem nie duplikujesz tych, które przed chwilą napisałeś. Jeśli nie, to zastanów się, czy zmiana w funkcjonalności, którą wprowadziłeś nie była przypadkiem zbyt duża i nie miała jeszcze innych niechcianych konsekwencji. Jeśli wszystko jest ok, to powtórz powyższą pętlę aż wprowadzisz wszystkie zmiany.

Moja ogólna rada – nie bójcie się czerwonych testów. One właśnie po to są by często nie przechodziły i pokazywały Wam status systemu. Jeśli zastosujecie zasady z Clean Code oraz dobrze przemyślicie swoje testy to analiza tego dlaczego nie przechodzą będzie łatwa i przyjemna, a co za tym idzie wniesie to znaczną wartość do Waszej pracy.

Reasumując

Coding Dojo w tej formie jest w mojej ocenie bardzo fajnym ćwiczeniem wartym polecenia każdemu zespołowi. Przedmiotem Dojo wcale nie musi być TDD Kata – możecie spróbować zmienić się z zupełnie innym problemem nawet niekoniecznie programistycznym. Najważniejsze jest to, by wykonywane ćwiczenia wnosiły jakąś wartość i pozwalały Wam poszerzyć wiedzę.

Dojo, które przeprowadziłem z zespołem B&T Skyrise miało na celu przede wszystkim poszerzenie wiedzy na temat TDD oraz nabranie wprawy w praktykach Code Review. Myślę, że cel został osiągnięty.

PS: Niezmiernie ciekawi mnie, czy któryś z uczestników spróbował później podejść do samodzielnego rozwiązania jakiejś TDD Katy… Sprawdzę to przy najbliższej okazji.

1 komentarz więcej...

Quality Excites – się kręci…

opublikowany przez 17, Mar, 2014, kategorie: Jakość, Konferencje, Testowanie

qe

Jak co roku zachęcam Was do wzięcia udziału w Quality Excites. Miałem przyjemność uczestniczyć w Quality Excites od samego początku kiedy to w 2012 roku zostałem zaproszony jako jeden z kilku prelegentów. Od tamtego czasu wydarzenie rozrosło się i stało się jednym z najważniejszych miejsc na mapie i w kalendarzu naszego krajowego testowania i jakości oprogramowania. Co roku staram się jak mogę wspierać inicjatywę oraz dzielić się z uczestnikami swoim doświadczeniem.

W tym roku jakością będziemy się ekscytować 31 maja jak zawsze w Gliwicach.

Jeśli chcieli byście podzielić się jakimś ciekawym tematem to Call For Papers już wystartowało i potrwa do końca marca. Szczerze zachęcam do zgłaszania prezentacji, gdyż wiem, że wielu czytelników mojego bloga ma się czym pochwalić! (Poza tym ileż można ciągle oglądać te same twarze – w tym moją :P).

Swoją drogą jeśli sami nie czujecie się na siłach by coś opowiedzieć to może chcieli byście bym ja odpowiedział na jakieś Wasze pytania albo szerzej omówił któryś z tematów prezentowanych przeze mnie na blogu lub gdzieś indziej? Nie to żebym sam nie miał pomysłów, ale zawsze lepiej się opowiada mając świadomość, że gdzieś tam na widowni jest przynajmniej jedna osoba, którą dany temat interesuje :).

Zapraszam do podzielenia się propozycjami pod postem lub na facebooku.

4 komentarze więcej...

Jeśli awansowałeś na Scrum Mastera…

opublikowany przez 13, Mar, 2014, kategorie: Agile, Scrum


awans

Jeśli awansowałeś na Scrum Mastera…

…to zmień pracę…

Scrum Master to rola w zespole Scrumowym a nie stanowisko w organizacji. Jeśli ktoś awansował Cię na Scrum Mastera to albo nie ma pojęcia o tym czym jest Scrum i zrobił to ze względu na swoją ignorancję i niewiedzę, albo nie traktuje Cie poważnie…

Jak postąpić, gdy ktoś próbuje mnie awansować na Scrum Mastera? Grzecznie odmówić i wytłumaczyć, że nie da się kogoś awansować w ten sposób. Scrum Master nie jest przełożonym zespołu, a jeśli rolę tą pełni formalny przełożony to ma on zasadniczo utrudnione zadanie.

Niestety wiele organizacji nadal używa „Scrum” (samego słowa, bo to co robią ze Scrum ma niewiele wspólnego) jako narzędzia do marketingu – zarówno na zewnątrz jak i wewnątrz organizacji… Stwierdzenia typu: „Nie obchodzi mi jak to zrobicie ale macie sami wymyślić jak dotrzymać (nierealnych) terminów – przecież jesteście teraz samo-organizującym się zespołem Scrumowym” czy „Teraz jesteśmy Agile więc powinniście wyrabiać 600% normy (za pewnym niefortunnym stwierdzeniem pewnego guru)” są na porządku dziennym jeszcze w wielu firmach…

Pomimo tego iż jest coraz lepiej nadal warto przypominać o tym, że nie wszędzie jest tak różowo…

6 komentarzy więcej...

Komentarz do: „Błąd Arystotelesa w IT”

opublikowany przez 26, Lut, 2014, kategorie: Agile, CI, Scrum, XP

[W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany „Błąd Arystotelesa w IT„, który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu – poniżej… zapraszam do dyskusji]

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!

Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)…

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać… Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.

Samo omawianie od podstaw metod zwinnych w 2014 roku jest już raczej zbyteczne.
Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu…
Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać… Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup (gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań)

6 komentarzy więcej...