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ń.
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.
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?
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.
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ń.
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.
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?
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?
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.
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.
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?
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ę. 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ć.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
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.
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.
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ć.
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.
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.
Jak wdrożyć Continuous Delivery do Twojego (starego) projektu?Daniel Pokusa
Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac.
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?
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.
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.
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?
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ę. 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ć.
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
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.
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.
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ć.
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.
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.
Jak wdrożyć Continuous Delivery do Twojego (starego) projektu?Daniel Pokusa
Stworzenie nowego produktu na bazie starego kodu źródłowego nie jest sprawą prostą. Nie jest też rzeczą niemożliwą! Na bazie własnych doświadczeń przedstawię możliwości i sposoby zorganizowania środowiska pracy tak, aby ciągłe dostarczanie nowych wersji i aktualizacji aplikacji stało się faktem. Zaproponuję narzędzia, które sprawdzają się w praktyce, wskażę rozwiązania jakich należy unikać, a także przedstawię kilka podejść do budżetu, który niekoniecznie pozwoli na kilka miesięcy „sprzątania” przed rozpoczęciem właściwych prac.
Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
Prezentacja powstała na potrzeby webinara pt. Praca testera w Scrumie.
Podczas webinara Ola Woszczyk- testerka z testuj.pl, opowiedziała, o tym czym jest SCRUM i jak wygląda praca w zespole Scrumowym. Ponadto wyjaśniła, jaką rolę w Scrumie pełni tester i jakie najczęstsze błędy popełniają członkowie zespołu.
Prezentacja dostępna jest jako kolejny slajd po wyświetlonym filmie.
JDD2015: DDD w praktyce, czyli jak wdrażamy i uczymy się DDD w Allegro - Krzy...PROIDEA
DDD W PRAKTYCE, CZYLI JAK WDRAŻAMY I UCZYMY SIĘ DDD W ALLEGRO
DDD nie jest frameworkiem czy też metodologią, jest raczej zbiorem zdroworozsądkowych wzorców i narzędzi, które każdy może komponować według uznania i potrzeb. Chociaż jest już z nami od ponad 10 lat, ciągle uczymy się jak najlepiej je wykorzystać, tak aby z jednej strony wnieść wartość do codziennej pracy, a z drugiej nie wpadać w formalizmy i teoretyczne dyskusje.
Przeprowadzając transformację monolitycznej platformy Allegro zastosowaliśmy wzorce DDD jako jedno z głównych narzędzi i stało się naszym chlebem powszednim.
W prezentacji opowiem co ze skrzynki narzędziowej DDD użyliśmy i z jakim skutkiem. Dowiecie się jak sami uczyliśmy się DDD i jak sprzedawaliśmy tę wiedzę w organizacji.
Wreszcie opowiem wam czego sam nauczyłem się o DDD, szczególnie jak zmieniało się moje zrozumienie Projektowania Strategicznego i jak uczyłem się stosować DDD w świecie mikrousługowym.
Prezentacja firmy XSolve - programowanie, e-commerce, bodyleasingXSolve
Prezentacja firmy XSolve.
XSolve jest prężnie działającą i wciąż rozwijającą się firmą informatyczną. Specjalizujemy się w znajdowaniu najnowszych i najlepszych rozwiązań dla sieci i oprogramowań komputerowych w zależności od potrzeb naszych klientów.
Sprzedaj swój program. Droga do udanych projektów programistycznychWydawnictwo Helion
Stwórz niezawodne oprogramowaniespełniające oczekiwania użytkowników
* Wykorzystuj odpowiednie narzędzia projektowe.
* Wdrażaj nowoczesne metodologie.
* Szybko rozwiązuj problemy.
Dyskusje nad wadami i zaletami przeróżnych metodologii tworzenia oprogramowania, mające na celu wyłonienie najlepszej z nich, zwykle do niczego nie prowadzą. Zwolennicy poszczególnych metodologii, takich jak Rational Unified Process, programowanie ekstremalne i inne, starają się udowodnić, że to ich stanowisko jest poprawnym sposobem realizacji projektów informatycznych. Tymczasem nie istnieje "jedyne słuszne" i uniwersalne podejście, które sprawdza się we wszystkich okolicznościach. Wybór właściwej metodologii w ogromnej mierze zależy od typu projektu i wielkości zespołu pracującego nad nim. Należy kierować się nastawieniem czysto pragmatycznym, czyli wybrać taką metodologię, która będzie najbardziej korzystna dla określonego projektu. Niewłaściwy wybór może skończyć się porażką.
Książka "Sprzedaj swój program. Droga do udanych projektów programistycznych" to zbiór wskazówek przedstawiających narzędzia i techniki, dzięki którym każdy projekt programistyczny zakończy się sukcesem. Czytając ją, nauczysz się korzystać z nowoczesnych instrumentów wykorzystywanych do projektowania oprogramowania, kontroli wersji kodu źródłowego i śledzenia procesu usuwania błędów. Dowiesz się, w jaki sposób zorganizować pracę zespołu projektowego i wdrażać metodologię wytwarzania oprogramowania. Porady, które znajdziesz w tej książce, pomogą Ci rozwiązać problemy pojawiające się podczas realizacji projektów programistycznych. Poznasz nowoczesne metody oraz dowiesz się, kiedy i jak z nich korzystać.
* Planowanie infrastruktury
* Dobór narzędzi projektowych
* Automatyzacja zadań
* Tworzenie listy zadań
* Rola kierownika technicznego
* Metodologia pocisku smugowego
* Rozwiązywanie problemów
Wskazówki zawarte w tej książce sprawią, że każdy prowadzony przez Ciebie projekt zakończy się w terminie i zmieści w wyznaczonym budżecie.
The IT systems has become more and more complex. Fortunately we have now a set of utilities and tools that helps us in the development process. Project management, collaboration platforms, build systems, source code management and quality has become a standard part of our workflow. Here's a talk on how to connect the dots and set up the development tools ecosystem. Moreover we will cover GIT Flow in depth.
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ą.
We have adopted Scrum and Kanban as our people framework and software engineering techniques and good practises XP, DevOps processes CI, CD, Quality, ChM, RM, BDD, TDD, Risk Management and GIT Flow for the technical counterpart. Here's a story of our problems and solutions we've came-up with. It has been a long journey already, but there's a lot of things to do ahead of us. Let's step into our Case Study
Przez kilkanaście lat pracy zawodowej wielokrotnie padłem ofiarą mitów i przejściowych trendów przemysłu IT. Bałem się wysłać CV na widok ściany wymagań. Wprowadzałem Scruma "na siłę", przepisywałem systemy od zera, budowałem wymyślną architekturę. Umknęło mi wiele ważnych rzeczy, na które dziś pragnę zwrócić Waszą uwagę. Opowiem jak możecie ruszyć swoją karierę "z kopyta" poprzez skupienie się na 20% rzeczy, które dadzą 80% rezultatów. Pokażę, jakie praktyki realnie pozwoliły mi osiągać duże sukcesy u klientów z całego świata.
Kompendium wiedzy dla każdego programisty, projektanta i kierownika projektu
* Nowoczesne metodyki wytwarzania oprogramowania
* Narzędzia do modelowania aplikacji i automatycznego generowania kodu
* Koncepcja architektury sterowanej modelami
* Sposoby zapewnienia jakości aplikacji
Tworzenie aplikacji korporacyjnych to wyścig z czasem. Organizacje zmieniają się podobnie jak otoczenie biznesowe, w którym działają. Zbyt długi okres przygotowania aplikacji może sprawić, że po wdrożeniu okaże się ona bezużyteczna. Z drugiej jednak strony, zbyt duży pośpiech przy tworzeniu aplikacji powoduje, że pomija się fazę modelowania i testowania, pisząc kod źródłowy bez jakiejkolwiek koncepcji i planu. Efektem takiego pośpiechu są aplikacje niedostosowane do wymagań użytkowników i pracujące niestabilnie. Sposobem na stworzenie odpowiedniego systemu informatycznego dla korporacji jest wykorzystywanie odpowiednich metodyk projektowych i nowoczesnych narzędzi ułatwiających zarówno pisanie, jak i testowanie aplikacji.
Książka "J2EE. Podstawy programowania aplikacji korporacyjnych" przedstawia najlepsze praktyki projektowe stosowane przy tworzeniu systemów informatycznych z wykorzystaniem platformy J2EE. Opisano w niej kolejne etapy projektu oraz narzędzia i metodyki, dzięki którym przeprowadzenie każdego z nich będzie szybsze i efektywniejsze. Czytając ją, poznasz metodyki RUP i XP, typy architektur systemów oraz sposoby modelowania aplikacji i narzędzia do automatycznego generowania szkieletu kodu źródłowego. Dowiesz się, jak optymalnie skonfigurować środowiska programistyczne i jak testować kolejne moduły aplikacji. Nauczysz się korzystać z nowoczesnych metodyk i narzędzi.
* Podstawowe wiadomości o błyskawicznym wytwarzaniu aplikacji (RAD)
* Metodyki projektowe Rational Unified Process (RUP) oraz Extreme Programming (XP)
* Wielowarstwowe architektury systemów
* Modelowanie systemów za pomocą języka UML
* Automatyczne generowanie kodu
* Stosowanie narzędzi XDoclet i Hibernate
* Komunikacja z bazami danych
* Zasady programowania aspektowego
* Testowanie aplikacji
Wiadomości zawarte w tej książce sprawią, że będziesz w stanie szybciej projektować i tworzyć aplikacje korporacyjne.
Słyszałeś, że firma, do której aplikujesz, pracuje w Scrumie i zastanawiasz się, co to oznacza?
* Chcesz wiedzieć, jak wygląda zarządzanie projektami według tej metodyki?
Pomimo rosnącej popularności Scruma uważasz, że nie ma on zastosowania w gamedevie?
Prezentacja odpowiada, jak wygląda zarządzanie projektami zgodnie z metodyką Agile i czym różni się to podejście od innych.
10. Dla każdej reguły, jakkolwiek
„fundamentalnej” czy
„racjonalnej”, istnieją okoliczności,
w których właściwe jest nie tylko
odstąpić od niej, ale wręcz
zastosować regułę przeciwstawną.
Paul K. Feyerabend, „Przeciw metodzie”
12. Manifest Agile
Ludzi i komunikację
ponad
procesy i narzędzia.
13. Manifest Agile
Ludzi i komunikację
ponad
procesy i narzędzia.
Działające oprogramowanie
ponad
wyczerpującą dokumentację.
14. Manifest Agile
Ludzi i komunikację
ponad
procesy i narzędzia.
Działające oprogramowanie
ponad
wyczerpującą dokumentację.
Współpracę z klientem
ponad
negocjowanie kontraktu.
15. Manifest Agile
Ludzi i komunikację
ponad
procesy i narzędzia.
Działające oprogramowanie
ponad
wyczerpującą dokumentację.
Współpracę z klientem
ponad
negocjowanie kontraktu.
Reagowanie na zmiany
ponad
trzymanie się planu.
20. Celem projektu jest dostarczenie
oprogramowania. Nie ma rzeczy
ważniejszej od tego. Model, tak jak
każdy inny sposób komunikacji, jest
wystarczający wtedy, gdy pozwala
drugiej osobie kontynuować pracę.
Efekt komunikacji jest ważniejszy
niż jej forma.
Alistair A.R. Cockburn
53. Literatura
Manifesto for Agile Software Development
http://agilemanifesto.org/
Software Management Manifesto
http://c2.com/cgi/wiki?SoftwareManagementManifesto
Optional scope contracts
http://www.xprogramming.com/ftp/Optional+scope+contracts.pdf
Are you Agile or Are You Fragile?
http://video.google.pl/videoplay?docid=490917380139552102
Practices of an Agile Developer
http://pragprog.com/titles/pad
InfoQ: Agile
http://www.infoq.com/agile/
54. Literatura
Alistair Cockburn
http://alistair.cockburn.us/
Ron Jeffries
http://www.xprogramming.com/
Scott Ambler
http://www.ambysoft.com/
Martin Fowler
http://www.martinfowler.com/