W trakcie transformacji do Agile jeden z problemów do rozwiązania to umiejscowienie roli analityka w nowej rzeczywistości. Pula rozwiązań wydaje się tutaj mocno ograniczona standardami. Scrum Guide nie wyznacza takiej roli i nie wskazuje co zrobić z analitykiem. A może analityk nie jest w ogóle potrzebny w Agile? Nawet jeśli znajdziemy dla niego miejsce to trudno jest pracować w iteracjach tak, żeby było to wartościowe i efektywne. W swojej pracy widziałem już kilka konfiguracji w mniejszych i większych przedsięwzięciach. Każdy wybór oczywiście ma swoje plusy dodatnie i plusy ujemne. Opowiem zatem jak funckjonowała w moim doświadczeniu analiza biznesowa w środowiskach Agile, w szczególności z zespołami Scrumowymi oraz jakie są opcje rozwiązania sytuacji Analityka.
Ilu z was pracuje w projektach prowadzonych w Agile? A ilu z was potrafi o sobie powiedzieć, że są Agile? I uwaga, agile niekoniecznie oznacza, że musicie godzic sie na wszystko i minute przed terminem zmieniac pół aplikacji
Agile ma lepszy PR niż Waterfall – jest bardziej „cool”, ale to nie znaczy że jest lepszy.
W koncu trzeba teraz wymyślić coś nowego, sprzedać dużo książek, no bo tak naprawde czy jednocześnie jesteśmy testerami manualnymi, automatycznymi, developerami, scrum masterami, asystentkami, project managerami ? Większość z Nas mówi, że pracuje w Agile. A kiedy tak naprawde testujecie? Pierwszego dnia sprintu czy tak naprawdę ostatniego? Kiedy rozpoczynacie cały proces testowania? Na etapie planowania czy, gdy cała dokumentacja jest gotowa?
Praca w Agile wymaga zaangażowania klienta. Klienta, który w pełni poświeci się w dany projekt. Nie bedzie oczekiwał konkretnej estymacji do nie do końca sprecyzowanych wymagań.
Jest cała masa projektów, które zwyczajnie muszą być prowadzone w “stary” sposób. I tutaj zwykle wracamy do waterfalla. No bo kto wsiadłby od samolotu którego hamulce rozwijane byłyby w metodologiach zwinnych – w ostatnim sprintcie dodamy user story “As a owner of this Boeing 747 I want it to break before end of the airstip so that nobody from passengers die” ? a może: “As a NASA we want this mars rover to land so we don’t waste milions of dolars” ?
Chcemy Wam dziś pokazać, że zamiast na siłę wdrażać w projektach zwinne podejście, może lepiej skupić się na eliminacji strat, stałej poprawie i na przykład zastosować LEAN software development.
Jak pracuje Product Owner? Spotkanie LubLean and AgileKrystian Kaczor
Product Owner jako osoba pisząca User Story (Historyjki Użytkownika) to jeden z najczęściej powtarzających się mitów na temat Scrum. Pojawiają się też głosy, że to niemożliwe, żeby jedna osoba potrafiła zarządzać Product Backlog. Czy aby na pewno? Czym zajmuje się Product Owner? Z jakich narzędzi korzysta Product Owner? Czy jest na 100% dostępny dla Zespołu Develoeprskiego? Co do tego ma Scrum Master?
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
W trakcie transformacji do Agile jeden z problemów do rozwiązania to umiejscowienie roli analityka w nowej rzeczywistości. Pula rozwiązań wydaje się tutaj mocno ograniczona standardami. Scrum Guide nie wyznacza takiej roli i nie wskazuje co zrobić z analitykiem. A może analityk nie jest w ogóle potrzebny w Agile? Nawet jeśli znajdziemy dla niego miejsce to trudno jest pracować w iteracjach tak, żeby było to wartościowe i efektywne. W swojej pracy widziałem już kilka konfiguracji w mniejszych i większych przedsięwzięciach. Każdy wybór oczywiście ma swoje plusy dodatnie i plusy ujemne. Opowiem zatem jak funckjonowała w moim doświadczeniu analiza biznesowa w środowiskach Agile, w szczególności z zespołami Scrumowymi oraz jakie są opcje rozwiązania sytuacji Analityka.
Ilu z was pracuje w projektach prowadzonych w Agile? A ilu z was potrafi o sobie powiedzieć, że są Agile? I uwaga, agile niekoniecznie oznacza, że musicie godzic sie na wszystko i minute przed terminem zmieniac pół aplikacji
Agile ma lepszy PR niż Waterfall – jest bardziej „cool”, ale to nie znaczy że jest lepszy.
W koncu trzeba teraz wymyślić coś nowego, sprzedać dużo książek, no bo tak naprawde czy jednocześnie jesteśmy testerami manualnymi, automatycznymi, developerami, scrum masterami, asystentkami, project managerami ? Większość z Nas mówi, że pracuje w Agile. A kiedy tak naprawde testujecie? Pierwszego dnia sprintu czy tak naprawdę ostatniego? Kiedy rozpoczynacie cały proces testowania? Na etapie planowania czy, gdy cała dokumentacja jest gotowa?
Praca w Agile wymaga zaangażowania klienta. Klienta, który w pełni poświeci się w dany projekt. Nie bedzie oczekiwał konkretnej estymacji do nie do końca sprecyzowanych wymagań.
Jest cała masa projektów, które zwyczajnie muszą być prowadzone w “stary” sposób. I tutaj zwykle wracamy do waterfalla. No bo kto wsiadłby od samolotu którego hamulce rozwijane byłyby w metodologiach zwinnych – w ostatnim sprintcie dodamy user story “As a owner of this Boeing 747 I want it to break before end of the airstip so that nobody from passengers die” ? a może: “As a NASA we want this mars rover to land so we don’t waste milions of dolars” ?
Chcemy Wam dziś pokazać, że zamiast na siłę wdrażać w projektach zwinne podejście, może lepiej skupić się na eliminacji strat, stałej poprawie i na przykład zastosować LEAN software development.
Jak pracuje Product Owner? Spotkanie LubLean and AgileKrystian Kaczor
Product Owner jako osoba pisząca User Story (Historyjki Użytkownika) to jeden z najczęściej powtarzających się mitów na temat Scrum. Pojawiają się też głosy, że to niemożliwe, żeby jedna osoba potrafiła zarządzać Product Backlog. Czy aby na pewno? Czym zajmuje się Product Owner? Z jakich narzędzi korzysta Product Owner? Czy jest na 100% dostępny dla Zespołu Develoeprskiego? Co do tego ma Scrum Master?
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
Jak podejść do wymagań w Agile? Jak pisać dobre User Story? Po czym poznam, że to jest dobre User Story? Kto pisze User Story? Czy w Scrum stosujemy tylko User Story? Jak szybko budować Product Backlog?
No i stało się. Nadszedł ten dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę, to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z Edge of Tomorrow. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/miała kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
Dlaczego developerzy nie lubią scrum Zwinna ŁódźKrystian Kaczor
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Jira jak każde narzędzie może posłużyć do czegoś dobrego albo czegoś złego. Możemy wspierać pracę w Agile, albo wręcz odwrotnie, zabić każdy aspekt Agile. A na początek wystarczyłoby skorzystać z ustawień schematu scrum w Jira Software.
No i stało się. Nastał dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z „Edge of Tomorrow”. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/a kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.
Scrum, choć jest wciąż popularny i lubiany, to zwykle nie jest już zwinny (Agile). Co robi różnicę? Jak bycie zwinnym zmienia myślenie o zadaniach ludzi w IT? Czym w praktyce różni się praca w zespole tradycyjnym i zwinnym? Wreszcie jak rozpoznać u potencjalnego pracodawcy prawdziwy Agile? Przy okazji odpowiedzi na te pytania sprostujemy wspólnie najczęściej pojawiające się przekłamania na temat Scruma i Agile.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development.
Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling:
http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/
Obecnie jedną z najpopularniejszych metodyk zwinnych jest Scrum, który pozwala w sposób iteracyjny i przyrostowy tworzyć oprogramowanie. Na środowisko Scrumowe składają się trzy role – Development Team, Scrum Master oraz Product Owner. Gdzie w tym wszystkim znajduje się tester? Czy jest on nadal potrzebny, czy może stanowisko to jest już zbędne? Jak powinno wyglądać testowanie w Scrumie?
W swoim wystąpieniu Marcin postara się dać odpowiedź na powyższe pytania oraz bliżej zaprezentuje pracę w Scrumie z punktu widzenia testera oprogramowania. Przedstawione zostaną najlepsze praktyki, które pozwolą podnieść jakość produktów tworzonych w środowisku Scrumowym. Dowiecie się również, jakie błędy i pułapki czyhają na osoby pracujące w Scrumie.
Przejdziemy przez wizję testowania w tradycyjnych metodach wytwarzania oprogramowania przez pierwsze próby podejścia do testowania w metodach zwinnych i dojdziemy do tego jak to powinno wyglądać w idealnym świecie. Dowiecie się także jak to się dzieje, że testerzy potrafią lepiej połączyć części produktu ze sobą i w związku z tym wiedzą więcej. Na koniec, krótka opowieść jak wygląda codzienna praca w produkcie przeznaczonym do automatycznego testowania.
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Jak podejść do wymagań w Agile? Jak pisać dobre User Story? Po czym poznam, że to jest dobre User Story? Kto pisze User Story? Czy w Scrum stosujemy tylko User Story? Jak szybko budować Product Backlog?
No i stało się. Nadszedł ten dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę, to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z Edge of Tomorrow. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/miała kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
Dlaczego developerzy nie lubią scrum Zwinna ŁódźKrystian Kaczor
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
Jira jak każde narzędzie może posłużyć do czegoś dobrego albo czegoś złego. Możemy wspierać pracę w Agile, albo wręcz odwrotnie, zabić każdy aspekt Agile. A na początek wystarczyłoby skorzystać z ustawień schematu scrum w Jira Software.
No i stało się. Nastał dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z „Edge of Tomorrow”. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/a kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.
Scrum, choć jest wciąż popularny i lubiany, to zwykle nie jest już zwinny (Agile). Co robi różnicę? Jak bycie zwinnym zmienia myślenie o zadaniach ludzi w IT? Czym w praktyce różni się praca w zespole tradycyjnym i zwinnym? Wreszcie jak rozpoznać u potencjalnego pracodawcy prawdziwy Agile? Przy okazji odpowiedzi na te pytania sprostujemy wspólnie najczęściej pojawiające się przekłamania na temat Scruma i Agile.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Prezentacja przedstawia pomysł Scotta Amblera na prowadzenie analizy w metodach zwinnych: Agile Modeling oraz Agile Model Driven Development.
Prezentacja została przedstawiona na spotkaniu IIBA PC Business Analysis Round-tables #7 Pomysł na analizę w Agile: Agile Modeling:
http://www.meetup.com/IIBA-PC-Business-Analysis-Round-tables/events/222647759/
Obecnie jedną z najpopularniejszych metodyk zwinnych jest Scrum, który pozwala w sposób iteracyjny i przyrostowy tworzyć oprogramowanie. Na środowisko Scrumowe składają się trzy role – Development Team, Scrum Master oraz Product Owner. Gdzie w tym wszystkim znajduje się tester? Czy jest on nadal potrzebny, czy może stanowisko to jest już zbędne? Jak powinno wyglądać testowanie w Scrumie?
W swoim wystąpieniu Marcin postara się dać odpowiedź na powyższe pytania oraz bliżej zaprezentuje pracę w Scrumie z punktu widzenia testera oprogramowania. Przedstawione zostaną najlepsze praktyki, które pozwolą podnieść jakość produktów tworzonych w środowisku Scrumowym. Dowiecie się również, jakie błędy i pułapki czyhają na osoby pracujące w Scrumie.
Przejdziemy przez wizję testowania w tradycyjnych metodach wytwarzania oprogramowania przez pierwsze próby podejścia do testowania w metodach zwinnych i dojdziemy do tego jak to powinno wyglądać w idealnym świecie. Dowiecie się także jak to się dzieje, że testerzy potrafią lepiej połączyć części produktu ze sobą i w związku z tym wiedzą więcej. Na koniec, krótka opowieść jak wygląda codzienna praca w produkcie przeznaczonym do automatycznego testowania.
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Founded in 2006 as a Polish-Dutch IT company, Goyello is a full service Agile Software Solution Provider
with over 100 employees, working in 3 offices, both in The Netherlands and in Poland (Gdańsk and Koszalin).
Talented, dedicated developers, consultants, designers, front-end developers, project managers, testers, support
and management team – all working as an energetic team for our clients in Europe and America.
Efektywne Testy Oprogramowania w Środowisku ScrumowymTestPro
Na środowisko Scrumowe składają się trzy role - Development Team, Scrum Master oraz Product Owner. Gdzie w tym wszystkim znajduje się tester? Czy jest on nadal potrzebny? Czy stanowisko te jest już zbędne? Jak powinno wyglądać testowanie w Scrumie?
Krzysztof Moskwa - Podstawy metod zwinnych: jak to działa? Story points, czyl...PMI Szczecin
Krzysztof Moskwa. Krzysztof ma ponad dziesięć lat doświadczenia w prowadzeniu projektów produkcji oprogramowania. Obecnie pracuje w firmie Orad (część Avid Technology). Absolwent Politechniki Wrocławskiej oraz Studium MBA US. Posiadacz certyfikatu PMP Project Managment Institute. Wspiera lokalny oddział PMI Szczecin jako wolontariusz.
Temat wystąpienia to "Podstawy Metod Zwinnych: Jak to działa? Story Points, czyli Jednostki Wartości."
Automatyzacja w praktyce. Praktyka automatyzacjiRadoslaw Smilgin
Automatyczna kontrola jakości oprogramowania jest obecnie w topie pożądanych działań projektowych. Można uznać, że w większości to właśnie zespoły testerskie są odpowiedzialne za dobór właściwego narzędzia, wdrożenie i utrzymanie automatyzacji w organizacji. Podczas prezentacji skupię się na analizie obecnej sytuacji projektów automatyzacji i roli testerów w tym procesie. Bazuję na dostępnych źródłach, własnych obserwacjach, rozmowach z ekspertami oraz na wynikach ankiety przeprowadzonej na testerzy.pl
Najważniejsze tematy:
– proces i projekt automatyzacji jest skrajnie trudny (analizując failure rate)
– czynności w automatyzacji nie są tak trudna jak się większości wydaje
– automatyzacja może być tańsza
– automatyzacja może dostarczać jeszcze większą wartość.
Zwinne metodyki zawdzięczają swoje powstanie dzięki potrzebie elastycznej obsługi szybko zmieniających się wymagań klienta w czasie trwania projektu oraz tworzeniu wysokiej jakości programów, aplikacji czy serwisów internetowych. Prezentacja ukazuje jedną z najpopularniejszych technik wspierających zbieranie i opisywanie wymagań użytkownika w postaci historyjek (User Stories) oraz ich późniejszą projekcję na codzienną pracę zespołu poprzez zbiór kryteriów akceptacji (Acceptance Criteria).
Coraz więcej firm decyduje się na wdrożenie oprogramowania, które podniesie efektywność pracowników. Dobrze zrealizowana inwestycja daje bowiem korzyści nie tylko finansowe. Zakup nawet najlepszego oprogramowania nie gwarantuje jednak efektów, jeśli wdrożenie nie zostanie odpowiednio przeprowadzone.
Więcej na ideo.pl
Wdrożenie nowego systemu informatycznego w firmie może się wiązać z popełnianiem wielu błędów, już na etapie jego uruchamiania, czego skutkiem będzie jego niewłaściwe działanie. Z drugiej strony - niezależnie jak dobry będzie wdrożony system – podjęte w tym kierunku działania mogą spotkać się z niechętnym przyjęciem pracowników.
W ostatecznym rozrachunku to oni będą z niego korzystać....
e_Talent to system informatyczny – aplikacja dedykowana menadżerom, którzy zarządzają pracownikami. Łączy ona trzy aspekty: ocenę kompetencji
i wartości, stawianie i ocenę celów oraz wspomaga zarządzanie rozwojem pracownika. A wszystko w jednym celu: aby nie stracić Państwa TALENTÓW.
Scaling is seen as a must and many companies see it as a way of transforming organizations. We see using the Spotify Model or SAFe from day one. However, what is missed it that when you scale, you scale your problems too. There are things to consider before you scale. You need to understand if you want to scale and how. Does it really pay off? What's your scaling strategy? There are also aspects to consider when you choose the approach.
I will share my experience with scaling and large organization transformation.
W ramach transformacji do zwinnej organizacji pojawiają się często niezaadresowane pytania. Jak managerowie powinni pracować z Zespołami Scrum. Czy w Scrum nie ma zarządzania? Co zrobić z managerami? Samo-organizacja jest postrzegana jako kompletny chaos. Pojawia się hasło, że potrzebujemy mieć procesy zarządcze, więc potrzebujemy mieć managerów. Wiele osób nie rozumie czym różni sie lider od managera. Jak managerowie powinni pracować z Zespołami Scrum? Czy w Scrum w ogóle nie ma zarządzania? Czy w Zespole Scrum są liderzy? W swoim wystąpieniu odpowiem na te pytania. Opowiem czym jest servant-leadership. Jak przejść z hierachicznej organizacji z kulturą zarządzania ludźmi na organizację zwinną. Opowiem czym mogą a nawet powinni zajmować się managerowie w organizacji.
Scrum studio - Agile in non-Agile organizationKrystian Kaczor
There are various approaches to Agile Transformation. Sometimes you can't handle a revolution and evolution would take too long. Then what's left is Scrum Studio.
I will share lessons learned from the New Online Banking at BGŻ BNP Paribas. I will tell you how we started. How the Product Owner influenced the shape of the studio and the shape of the product, how the Studio influenced the organization, our path through inspect & adapt and the way forward.
Why transform to Agile? What are the impediments to Agile Transformation? How to plan the Agile transformation? How to accelerate and sustain the Agile Transformation.
7 grzechów głównych Agile Coacha
Mam dla Ciebie dwie wiadomości, jedną dobrą i jedną złą. Zgadniesz, którą przeczytasz najpierw?
Pamiętam jak uczyłem żonę jeździć na nartach w austriackich Alpach i trzeciego dnia wybraliśmy się na duży stok. W trakcie zjazdu zatrzymaliśmy się na lunch i przed wyruszeniem w dalszą drogę spytaliśmy kogoś, kto wyglądał na lokalnego górala, którego szlaku powinniśmy się trzymać. Strasznie głupio czułem się później tłumacząc żonie, że jesteśmy 45 km od naszego samochodu. Najprostszym i najszybszym sposobem osiągnięcia celu było pokonanie góry jeszcze raz. Od tego czasu nie pytam o radę pierwszego lepszego człowieka wyglądającego na górala.
Agile obecnie przeżywa rozkwit na polskim rynku. Można śmiało powiedzieć, że na krzywej adopcji weszliśmy w etap przynajmniej wczesnej większości. I to jest dobra wiadomość dla tych, dla których Agile to pasja. Kiedy na rynku pojawia się popyt, pojawiają się sposoby zaspokojenia zapotrzebowania. Większa świadomość czym jest Agile i jak wygląda droga do osiągania zwinności powodują, że w naszym przypadku oznacza to prawdziwy wysyp osób określających się mianem Agile Coach. W połączeniu z krążącymi w Polsce mitami na temat coachingu tworzy to prawdziwie wybuchową mieszankę. I to jest ta zła wiadomość.
Jeżeli przypadkowy Agile Coach nie osiągnie efektów, to pół biedy. Ale może też wyrządzić duże szkody. A nie ma nic bardziej demotywującego dla organizacji niż oduczanie złych nawyków kiedy adres IP komputera poprzedniego coacha nie zdążył wygasnąć.
W trakcie mojego wystąpienia opowiem czego nie powinien robić prawdziwy Agile Coach. Powiem także co i jak powinien robić. Zapewnię dawkę unikalnej wiedzy, którą powinny poznać osoby które już pracują lub chcą zacząć pracować w Agile. Jeśli chcesz kiedyś zostać Agile coachem, przyjdź koniecznie.
Nas świat przyspiesza, czas wydaje się biegnąć coraz szybciej a zalewający nas potok informacji nie ma końca. Potrzebujemy szybkich i skutecznych metod wytwarzania nowych produktów. W tym celu zostały opracowane metody i frameworki Agile, ze Scrum na czele.
Jest więcej niż bardziej prawdopodobne, że następny projekt, na którym będziesz pracował, lub nowy kontrakt będzie oznaczał pracę według reguł Agile. Organizacje już teraz zaczynają poszukiwać na rynku specjalistów określanych jako Agile Tester. Czy możemy w pełni opisać kim jest i jak działa taka osoba?
Co tester może zrobić, żeby odnieść sukces w nowej sytuacji? Jak trzeba zmienić podejście do swojej roli i sposobu wykonywania pracy. Czy potrzebne są nowe procesy i narzędzia? Czy zmienia się misja testowania? Czy to prawda, że w zespole Scrum są tylko Deweloperzy?
Zapraszam na prezentację podczas której odpowiem na pytania najbardziej nurtujące testerów spotykających Agile na swojej ścieżce zawodowej. Do pełnego zilustrowania profilu Agile Terstera posłużę się modelem popularnie stosowanym w coachingu.
The document discusses three case studies of scaling Agile practices to the enterprise level. The first case study describes challenges with a team using only Scrum practices and how adopting additional XP practices like test-driven development and continuous integration helped. The second case study explains problems that arose from multiple teams working on a shared backlog and lack of synchronization; Kanban was introduced to help. The third case study outlines issues with multiple outsourced teams and lack of integration; Kanban, additional roles, and improved coordination helped address these challenges at the portfolio level.
This document contains slides from a 2010 presentation on testing in Scrum. It discusses key Scrum principles like iterations, self-organizing cross-functional teams, and continuous improvement. The slides cover testing practices like test-driven development, having no separate test team, continuous testing, and automating tests from the unit to GUI levels. User stories and their elements are explained. The document advocates testing that follows the Scrum process and values working software over documentation.
6. Oprogramowanie jest:
dostarczone na czas,
zintegrowane,
przetestowane.
Spełniona jest definicja DONE
Biznes akceptuje wynik Sprintu
Produkt w po iteracji jest potencjalnie
dostarczalny
7. Feedback jest natychmiastowy. Rozmowa
ponad raportowaniem wszystkiego
Bezpośrednia współpraca z biznesem i
deweloperami
Brak czasu na ręczne testy regresji
Testy opisują oczekiwania, wymagania
Defekty są naprawiane natychmiastowo
8. Podejście Test Driven
Testowanie nie powstrzymuje
wypuszczenia produktu na rynek, ale
pozwala na postęp projektu
Nie ma zespołu testerów, jest Zespół
Scrum
Tester dostarcza feedback i dodatkowe
informacje
9. Nie ma punktu przekazania
oprogramowania do testowania,
testowanie jest ciągłe
Każdy testuje
Nie ma ‘blaming game’
Zmieniamy dyscyplinę z biegu
sztafetowego na piłkę nożną.
10. Każde Story i zadanie są testowalne,
Kod jest napisany i kompletny,
Zadanie kompletnie wykonane,
Przegląd kodu został wykonany,
Przetestowane,
Brak błędów w Continuous Integration,
Brak wyjątków w logach Tomcat’a,
Udokumentowane (JavaDoc jest
obowiązkowy)
12. Sprawdź wszystkie warunki satysfakcji,
System Testing,
Naprawa defektów, ale tylko tych
krytycznych,
Nie ma nowego kodu i nowych
funkcjonalności,
UAT,
Szkolenia dla pracowników,
Aktualizacja instrukcji dla supportu
Ostateczna retrospekcja podsumowująca
release,
13. Rozpoczęcie projektu
Planowanie Release’u
Każda Iteracja
Czytanie dokumentacji, zrozumienie projektu
Uczestniczenie w
szacowaniuStory
Pytaj o przykłady, pytaj „ a
co by było gdyby … ?”
TworzenieTest Plan’u
Napisz i wykonaj testy Stories
Napisz i wykonaj testy funkcjonalne
Potwierdź bug-fix
Testowanie w parach z testerami i deweloperami
„Show me”
Automatyzacja testów funkcjonalnych
Uruchomienie testów automatycznych
Exploratory testing
Planowanie Iteracji Tworzenie i szacowanie
zadań testerskich
WalidacjaWarunków
Satysfakcji, dodawanie
nowych
14. Release & Support
End Game
Dodaj swoje uwagi z punktu widzenia testera,
testowania i procesów, wsparcia ze strony
biznesu
WykonajTesty obciążeniowe
WykonajTesty Regresji
Wykonaj UAT
Wykonaj SystemTesting
Przetestuj dokumentację instalacji, supportu
Uczestniczenie w przygotowaniach do Release’u
Uczestniczenie w Release na Produkcję
Uczestniczenie w Retrospekcji
Retrospekcja Iteracji
29. xUnit testy są podstawową warstwą
Dostarczają najszybszy feedback
Najlepszy ROI
Warstwa środkowa
Staje się funkcyjnymi testami regresji
Warstwa GUI
Może być częściowo zautomatyzowana
Głownie exploratory testing
34. Uwagi w 2014
• Wcześniejsze slajdy to oryginalna prezentacja
pokazana na konferencji TestWarez w 2010
• Tak zwani eksperci trzymający stwonę ISTQB
próbowali wyśmiać przedstawione pomysły
• Powiedziałem, że podejście ISTQB jest 5 lat za
tym co dzieje się na rynku
• Myliłem się
• ISTQB opublikowało Agile Tester add-on w 2014
(4 lata)
• Porównaj powyższe slajdy z zawartością sylabusa
;)
34