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.
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?
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.
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.
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.
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?
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.
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.
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ć.
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?
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.
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ń.
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 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.
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.
Webinarium by Krzysztof Walczak
To nie będzie webinarium reklamowe.
Pokazuję tutaj narzędzia z którymi pracowałem lub pracuję, więc jest to po części subiektywna prezentacja świata DevOps i PMO (Project Management Office).
Z drugiej strony prezentuję również analizy Gartner Group wskazujące na postrzeganie świata narzędzi przez uznanych analityków rynku. Czyli już niesubiektywnie. ;-)
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/
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.
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.
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ć.
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?
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.
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ń.
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 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.
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.
Webinarium by Krzysztof Walczak
To nie będzie webinarium reklamowe.
Pokazuję tutaj narzędzia z którymi pracowałem lub pracuję, więc jest to po części subiektywna prezentacja świata DevOps i PMO (Project Management Office).
Z drugiej strony prezentuję również analizy Gartner Group wskazujące na postrzeganie świata narzędzi przez uznanych analityków rynku. Czyli już niesubiektywnie. ;-)
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/
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.
Refactoring - Jak pozostać przy zdrowych zmysłach, redukując długMax Małecki
Pracowałem przy wielu projektach, które to miały specyfikę totalnie zadłużonych. W prezentacji podzielę się 14 latami moich doświadczeń i zmagań z długiem technicznym w projektach small & medium business. Odpowiem jak my sami się godzimy na wprowadzenie długu technicznego do projektu. Opowiem jak go trzymać w ryzach i monitorować. Dam przykłady narzędzi do monitorowania miejsc w kodzie, które są potencjalnymi nosicielami długu technicznego. Podam gotowy przepis jak wprowadzić do work-flow walkę z długiem technicznym.
InfoShare 2014: Skok na naderwanym bungee, czyli agile bez automatyzacjiJIT Solutions
Prezentacja z wykładu prowadzonego przez Witka Boła i Bartka Ziębę o automatyzacji procesów wytwórczych w zespołach softwareowych. Prezentacja odbyła się w ramach konferencji InfoShare 2014, 22.05.2014 w Gdańsku.
Skok na naderwanym bungee, czyli agile bez automatyzacjiWitold Bołt
Slajdy z prezentacji przeprowadzonej w ramach konferencji InfoShare 2014, 22 maja 2014 r. w Gdańsku. Prowadzący prezentacje: Witold Bołt i Bartłomiej Zięba.
Prezentacja ze spotkania itSMF Pomorze. Krótko - jak połączyć wymagania modeli Corporate Governance i możliwość zwinnego wytwarzania produktów w SCRUM.
Konfiguracja GitLab CI/CD pipelines od podstawBrainhub
O prezentacji:
W trakcie prelekcji pokażę jak zaimplementować proces CI/CD dla aplikacji napisanej w JavaScript, używając GitLab CI/CD Pipelines. Będzie on zawierał kroki lint (statyczna analiza kodu), unit test, API test, Docker Build i UI end-to-end test. Pokażę też jak tworzyć, parsować i wyświetlać raporty z testów w GitLabie. Powiem też co nieco o używanych w procesie Dockerfile i docker-compose.
O prelegencie:
Przygodę z profesjonalnym IT rozpoczął ponad 10 lat temu, jako Manual Junior Tester. Od tego czasu stara się w pełni zrozumieć rolę QA w projekcie i wielopoziomowo pracować nad poprawą jakości projektu, produktu i pracy.
Prezentacja z gościnnego wystąpienia na spotkaniu Project Management Institute (PMI) w Krakowie. Prezentacje punktuje najczęstsze problemy występujące podczas wdrożeń metodyki Scrum w środowisku średniej i dużej organizacji, powodów tych problemów upatrując w przyzwyczajeniach, kulturze organizacyjnej i obawie przed zmianą.
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.
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.