Czy na pokładzie jest tester? O roli testera oprogramowania w projekcie
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Agile w teorii ma umożliwić efektywną współpracę pomiędzy szeroko pojętym biznesem, a zespołami projektowymi. Ma być argumentem do tego, aby reagować na realny feedback użytkowników, na podstawie dostarczania rozwiązania w formie funkcjonalnych iteracji. Dzięki opozycyjnemu do Waterfall'owego podejściu do realizacji projektów, pozwala na testowanie rozwiązań wcześniej niż po miesiącach lub latach prac nad produktem. Dostarcza wiedzę o skuteczności wdrażanego rozwiązania na mniej zaawansowanych etapach, umożliwia szybszą reakcję na zmianę wymagań. Na konkretnych korzyściach wynikających z Agile'owego skupię się nieco póżniej. Teraz zacznijmy od teorii, czyli Manifestu zwinnego programowania:
Z założenia powyższej punkty sugerują, że elementy po prawej stronie są istotne, ale większą wagę mamy przykładać do tych wypisanych po lewej. W praktyce jednak, wprowadzenie i trzymanie się "dobrego" Agile nie jest łatwe, a dla większości organizacji staje się dużym wyzwaniem. Zwinne podejście przez lata (od 2001) dorobiło się wielu metodyk pracy, będących narzędziem, które w dobrych rękach usprawnia pracę, poprawia komunikację w zespołach, maksymalizuje efektywność realizacji zadań. Najpopularniejsze frameworki pomagające w zwinnym podejściu do realizacji projektów to - Scrum, kanban, dynamic system development method, programowanie ekstremalne, crystalclear feature driven development, pragramtic programing. W dzisiejszym artykule, skupię się na, moim zdaniem, najbardziej wartościowych elementach Scruma - Kim Gene, Behr Kevin , Spafford George.
„Na początku był chaos”, a potem pojawiły się freameworki, metodyki pracy dające możliwość zapanowania nad projektowym bałaganem. Pisząc to, na myśl przychodzi mi powieść "Projekt Feniks. Powieść o IT, modelu DevOps i o tym, jak pomóc firmie w odniesieniu sukcesu"- autorstwa KimGene, Behr Kevin i Spafford George, opowiadająca historię osadzoną w korporacyjnych realiach, dotyczącą złożoności realizacji dzisiejszych projektów wytwarzania oprogramowania.
Bohaterowie mierzą się tam z ogromną ilością piętrzących się zadań, które wydają się nie do opanowania, do momentu aż pojawiły się koncepcje uporządkowania pracy wokół tytułowego projektu. Scrum jak i inne frameworki powstały z takiej właśnie potrzeby. Podpowiadają konkretne rozwiązania pozwalające na opanowanie składowych etapów projektu i wyznaczają drogę do celu, jakim jest wdrożenie i rozwój skutecznego oprogramowania.
Scrum pozwala na wynikającą z Agile zmianę perspektywy tworzenia produktów, czyli to nie zakres projektu narzuca czas i koszt, a to czas i koszt są składowymi ostatecznego kształtu produktu. Ważnym aspektem Scruma jest to, że nie wpływa on wyłącznie na osoby techniczne w ramach zespołów, ale na całą organizację lub chociaż osoby odpowiedzialne za produkt już po stronie biznesu.
Nie chcę skupiać się nad składowymi Scruma i elementami jego idealnego modelu wynikającego ze Scrum Guide. Skupię się na jego praktycznym zastosowaniu, na tym co dla mnie w Scrumie jest najbardziej wartościowe- Scrum teams (zespołu scrumowe), samoorganizujące się zespoły posiadające komplet kompetencji do wdrożenia i rozwoju produktu. Zespół pracujący wspólnie nad rozwiązaniem, posiadający wspólny cel jakim jest dostarczenie produktu o możliwe najwyższej wartości, planujący, odbierający i analizujący problemy poprzednich iteracji, ma w założeniu wszystko, aby z sukcesami realizować kolejne zadania.Pracując razem z kompletem wiedzy na temat produktu i wdrożenia, zespół jest wstanie w możliwie najszybszym czasie rozwiązywać problemy i reagować na zmiany wymagań.
Kolejnym, bardzo istotnym elementem Scruma są sprinty, okresy w jakich powstają konkretne i zaplanowane przyrosty funkcjonalności. Podczas planowania zespół ustala zakres, w czasie sprintu go realizuje, następnie testuje. Powoduje to ciągły przyrost produktu o wartościowe i możliwe do odbioru składowe funkcjonalności, często uwzględniające feedback z poprzednich iteracji. Przyrost produktu, to moim zdaniem, nie tyle co wartościowy element Scruma (chociaż oczywiście tak jest), co argument dla osób sceptycznie podchodzących do jego założeń. W każdej kolejnej iteracji - product increment daje realną wartość, możliwą do zweryfikowania z wymaganiami i potrzebami użytkowników funkcjonalności. Ma to kluczowy wpływ na dalszy rozwój produktu i zakres projektu. Umożliwia to reagowanie w porę na nietrafione rozwiązania, zmianę wymagań, a co za tym idzie ograniczenie kosztów wynikających z dalszej pracy nad funkcjonalnościami, które z jakiegoś powodu nie spełniają oczekiwań użytkowników.
Scrum w praktyce, to dla małych przedsiębiorstw możliwość uporządkowania codziennej pracy, kładąc nacisk na współpracę członków samoorganizujących się zespołów daje także im narzędzia i argumenty do efektywnego rozwoju wartościowych produktów. W rozbudowanych strukturach dużych firm, to wsparcie dla wdrożenia innowacyjnej zmiany podejścia do realizacji projektów, a dla ich pracowników to szansa na uzyskanie większego wpływu na kształt i zakres realizowanych zadań. W ostatnim czasie rozwija się także usługa potwierdzająca zapotrzebowanie na podejście do pracy nad wdrożeniem i rozwojem oprogramowania wedle zasad tej metodyki - "scrum team as a service", czyli zewnętrzne zespoły projektowe, które wraz biznesowymi kompetencjami klienta, są w stanie efektywnie realizować założenia bez strat na jakości.
W mojej pracy, scrum jest frameworkiem pozwalającym mi na realizację projektu na przejrzyście określonych zasadach. Klient wie czego spodziewać się w konkretnym czasie i jakiego zakresu dotyczy iteracja w ramach, której obecnie pracujemy. Do faworyzowanych przeze mnie typów umów na wdrożenia bazujące na rozliczeniu time and material (T&M), scrum pasuje idealnie. Klient na kolejnych etapach wdrożenia nie płaci za kwartał wcześniej zaplanowany etap, a za wynikającą z realnej potrzeby użytkowników funkcjonalność, której kształt może określać feedback z wdrożonej i przetestowanej w poprzednim etapie iteracji. Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
Równie ważnym apsektem Scruma są ludzie, członkowie zespołów, posiadający swobodę działania, które dzięki bliskiej i ścisłej współpracy mają wszystko, żeby rozwijać się w swoich kompetencjach i czerpać satysfakcję z wdrożeń oprogramowania o możliwie najwyższej wartości.
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.