SCRUM DLA OPORNYCH. porady, tricki i dobre praktyki

Podobne dokumenty
SCRUM. jak pracować wydajniej i scalić zespół

EMPIRYZMSCRUM DOŚWIADCZENIE + PODEJMOWANIE DECYZJI = WIEDZA

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty

Planowanie i realizacja zadań w zespole Scrum

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

Scrum w praktyce. Michał Piórek

Spis Treści. Cel podręcznika. Definicja SCRUMa. Teoria SCRUMa. Zespół SCRUMowy. Właściciel Produktu. Zespół Deweloperski.

Zwinne metodyki - Scrum

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

Programowanie zespołowe

SCRUM. Wprowadzenie Role Zdarzenia Artefakty KANBAN SCRUM-BAN

Programowanie Zespołowe

DLACZEGO TO DZIAŁA? 21. marca 2012r.

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW. Ilona Ławniczak-Tomczak

Scaling Scrum with SAFe. Małgorzata Czerwińska

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora

Programowanie zespołowe

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

PROJEKTOWANIE ZORIENTOWANE NA UŻYTKOWNIKA W METODYCE SCRUM. Hubert Wawrzyniak Grupa Allegro

Marta Ożóg Agnieszka Pastusińska

Scrum. Zwinna metodyka prowadzenia projektów

Szybkość w biznesie. Zwinne testowanie oprogramowania (Agile) Mateusz Morawski (mateusz.morawski@hp.com) 14 kwietnia 2015

Klasyczna organizacja też może być zwinna! Zarządzaj zwinnie projektami!

Lekkie metodyki. tworzenia oprogramowania

Zarządzanie projektami w NGO

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Programowanie obiektowe

Zarządzanie projektami. Porównanie podstawowych metodyk

AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK

4. Wprowadzanie Scruma w ImmobilienScout Opis sytuacji

Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

e R gulamin Kuźni Talentów

Agile Project Management

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Feature Driven Development

Oferta szkoleń firmy Code Sprinters

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA

Scrum Guide. Przewodnik po Scrumie: Reguły gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Techniki komputerowe w robotyce

Agile vs PRINCE /2015 I rok st. magisterskie Informatyka

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Dobry Product Backlog Oferta szkolenia dla Product Ownerów

SCRUM Product Owner - wstęp do zarządzania produktami

Jak uchronić architekturę i wymagania przed chaosem? Warszawa, 27 stycznia 2016 roku

kompetencji zawodowych Professional Scrum Master I, Certified Scrum Master I Mirosław Dąbrowski zespół Indeed wprowadzenie Scruma

KILKA SŁÓW O ROLI PRODUCT MANAGERA

The Scrum Guide. Przewodnik po Scrumie: Reguły Gry. Lipiec Przygotowany i utrzymywany przez Kena Schwabera i Jeffa Sutherlanda

Testujemy dedykowanymi zasobami (ang. agile testers)

Metodyki programowania. Tomasz Kaszuba 2015

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Oferta usług coachingowych firmy Code Sprinters

Akademia ADB Wykład I Praca w grupie i jakość kodu

Opisy szkoleń dla certyfikatów Agile Scrum.

Koordynacja projektów IT w AGH

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Programowanie Zespołowe

MSF. Microsoft Solution Framework

Temat: Zwinne Zarządzanie Projektami IT (Agile / Scrum) Data: marca 2014 r. (2 dni, czwartek-piątek), godz. 9-16

Agile Project Management WHITEPAPER

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0)

Wszystkie problemy leżą w testach. ForProgress spółka z ograniczoną odpowiedzialnością sp.k.

Podejście zwinne do zarządzania projektami

EXIN Agile Scrum Foundation. Przewodnik egzaminacyjny

Programowanie zespołowe

Przewodnik egzaminacyjny. EXIN Agile Scrum. Wydanie

Skuteczność => Efekty => Sukces

PRINCE2 Foundation & Practitioner - szkolenie z egzaminem certyfikacyjnym

Metodyki zwinne wytwarzania oprogramowania

Programowanie Zespołowe

Nexus Przewodnik. Definitywny przewodnik po Nexusie: Rozszerzenie Scruma dla przedsięwzięć dużej skali

Metoda lean start-up

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Audyt organizacyjny. 4 powody, dla których warto przeprowadzić niezależny przegląd organizacji. 3. Rekomendacje. 1. Diagnoza. 4.

Jak wykorzystać design thinking w swojej firmie Doświadczenia praktyka.

Zagadnienia. Inżynieria Oprogramowania

Opis realizacji dla czterech zespołów (4 przypadki użycia)

Projektowanie oprogramowania. Termin zajęć: poniedziałek, a podstawie materiału ze strony.

Zarządzanie projektami IT metodyką SCRUM. Cezary Kamiński

HumanTechnology. Projektowanie interakcji. czyli łatanie dziury w procesie produkcji

Miary funkcjonalne i co można z nimi zrobić fakty i mity. Warszawa, 7-8 czerwca 2017

Leszno Jakie są i będą oczekiwania biznesu wobec IT?

Szkolenie Scrum w projektach IT (Agile)

Zarządzanie projektami a zarządzanie ryzykiem

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

Zarządzanie projektami. Porównanie podstawowych metodyk

Programowanie zwinne

I Twój zespół może być zwinny (choć to może trochę potrwać) Paweł Lipiński

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Szkolenie 1. Zarządzanie projektami

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Brakujący element Agile: Świadomy zespół

KANBAN SCRUM-BAN. Agile PM Zarys AUP

Projektowanie systemów informatycznych. wykład 6

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Transkrypt:

SCRUM DLA OPORNYCH porady, tricki i dobre praktyki

Spis treści 1 2 3 4 Wstęp Zwinny Scrum Scalony zespół Wydajny Sprint Praktyki techniczne Używaj Scruma, bo warto! Czym jest Scrum? Tradycyjna metoda pracy wobec zwinnej Wartości to podstawa! 3 filary Scruma Zespół scrumowy Role w zespole Zadanie zespołu Backlog produktu Zdarzenia w Scrumie Planowanie Sprintu Przebieg Sprintu Retrospekcja Sprintu Test Driven Development Pair Programming Domain-Driven Design Słowo od eksperta

Używaj Scruma, bo warto! Scrum to zwinna metoda zarządzania projektami. Jej filozofia i wartości, na których jest zbudowana, rewolucjonizują współczesną praktykę menedżerską. Jeśli chcesz przeprowadzić z sukcesem projekt - sięgnij po Scruma. Dlaczego warto? Wyjątkowo lekki Łatwy do zrozumienia Uniwersalny do zastosowania Pamiętaj! Scrum jest dla wszystkich, ale nie każdy potrafi z niego skorzystać. Pokażemy Ci, jak to zrobić najlepiej!

Zwinny Scrum 1

Czym jest Scrum? W Polsce coraz więcej firm IT wprowadza zwinne metodyki zarządzania (ang. agile), które mają pomóc w dostarczeniu rozwiązań w taki sposób, aby zmaksymalizować wartość dla klienta. Czym jest Scrum? Jego autorzy, Ken Schwaber i Jeff Sutherland, podają definicję w swoim przewodniku Scrum Guide, 2016: Ramy postępowania (ang. framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. Dla kogo jest Scrum? Każdy zespół mający do wykonania projekt może skorzystać ze zwinnych metod działania. Ale uwaga! Stosowanie Scruma natychmiast uwidacznia problemy i anomalie projektu i organizacji. Scrum promuje kooperację, przejrzystość i ciągłe doskonalenie. Stawia na ludzi i interakcje między nimi, umożliwia szybkie reagowanie na zmiany i regularne dostarczanie wartościowych produktów. Czy wiesz, że? Poza Scrumem powstał cały szereg innych zwinnych metodyk (Feature-Driven Development, Crystal, APM, itp.) Jednak to Scrum ze względu na swoją prostotę stał się najbardziej popularny. Warto jednak zaglądać do praktyk proponowanych przez inne metodyki.

Tradycyjna metoda pracy wobec zwinnej Scrum zapobiega głównym problemom, występującym zwykle w zarządzaniu projektami. Tradycyjna metoda Ryzyko niezrozumienia wymagań produktu. Konieczność podejmowania decyzji na początku projektu. Finalizowanie produktu przed pokazaniem klientowi. Niewiele informacji zwrotnych w trakcie trwania projektu. Ryzyko przekroczenia terminu i budżetu. A B Deadline Zwrot do klienta C Zwinna metoda Dostarczanie produktu najbliższego oczekiwaniom klienta. Możliwość odłożenia decyzji w czasie (ang. last responsible moment). Pozostawia miejsce na zmiany i feedback. Płynna produktywność i oszczędność energii. Pozwala na elastyczność budżetową. A 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 B Sprint Dzięki realizacji projektu w kolejności od najbardziej wartościowych funkcjonalności (oraz najbardziej ryzykownych biznesowo), do dodatkowych opcji nice to have, pozostawiamy klientowi decyzję, kiedy projekt jest wystarczająco dobry i spełnia jego potrzeby.

Wartości to podstawa! Scrum jest łatwy do zrozumienia, ale wymagający przy wdrożeniu. Powodzenie w jego wykorzystaniu zależy od biegłości postępowania zgodnie z pięcioma poniższymi wartościami. W nowej wersji przewodnika z 2016 r. Ken Schwaber i Jeff Sutherland zidentyfikowali 5 podstawowych wartości, na których opiera się Scrum: 1 Zaangażowanie 2 Odwaga 3 Koncentracja 4 Otwartość 5 Szacunek Czy wiesz, że już w 1999 te same wartości wyraził i opisał Kent Beck jako podstawę metodyki Extreme Programming? Lepiej późno niż wcale, Scrumie! Praktyki Zasady Wartości Codzienne praktyki (ang. pratices) wynikają z wdrożenia zasad (principales), a te z kolei opierają się na wspólnych wartościach (values). Scrum składa się zaledwie z kilkunastu elementów podzielonych na role, wydarzenia, narzędzia i reguły.

3 filary Scruma Jeżeli wdrożyliśmy 5 podstawowych wartości, na których opiera się Scrum, to zrobiliśmy tym samym miejsce na wprowadzenie 3 filarów Scruma. 1 Przejrzystość 2 Inspekcja 3 Adaptacja Wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Muszą być tak opisane, aby wszyscy tak samo je rozumieli i mogli posługiwać się wspólnym nazewnictwem. Np. osoby wykonujące pracę i osoby akceptujące wyniki tej pracy muszą posługiwać się wspólną definicją ukończonej pracy. Przejrzystość pozwala wszystkim poznać rzeczywisty stan projektu. Wszyscy korzystający ze Scruma muszą poddawać częstej inspekcji postępy w realizacji celu, żeby wykrywać niepożądane rozbieżności. Analiza tego, co się dzieje w zespole, produkcie czy organizacji, pozwala szybko zauważyć problemy, np. wolny czas odpowiedzi systemu, ale również możliwości, np. pojawia się nowa fukcjonalność otwierająca nowe rynki. Inspekcje nie powinny być zbyt częste, inaczej będą przeszkodą w wykonywaniu pracy. Jeżeli osoba dokonująca inspekcji ustali, że jeden lub więcej aspektów procesu wykracza poza przyjęte limity oraz że wytwarzany w ten sposób produkt nie będzie akceptowalny, proces lub przetwarzany materiał muszą zostać skorygowane. Korekta musi być wykonana jak najszybciej, by ograniczyć dalsze odstępstwa. Może to być na przykład zmiana zakresu, technologii czy zmiana sposobu działania zespołu.

Słowo od eksperta Scrum znakomicie zwiększa przejrzystość procesu. Wszelkie problemy szybko wychodzą na jaw. Scrum pozwala zauważać i poprawiać nieefektywności w zarządzaniu czy w praktykach technicznych. Dzięki temu zespoły dostarczają zrealizowane funkcjonalności regularnie i mogą dostosowywać kierunek prac do feedbacku ze strony użytkowników. Krzysztof Jelski Head of Trainings, Pragmatists Obserwuję, że wiele firm wdraża Scruma i myśli, że to załatwia całą sprawę prowadzenia projektu. To duży błąd. Scrum jest tylko lekkim zestawem reguł postępowania, które trzeba uzupełnić o działania zarządcze i praktyki techniczne. Pułapką jest luzowanie reguł Scruma, gdy zespół nie jest w stanie dostarczać działającego produktu co 1-2 tygodnie. Wtedy tracimy główne korzyści płynące z agile - szybszy feedback, szybszy time-to-market, możliwość adaptacji.

Scalony zespół 2

Zespół scrumowy W skład zespołu scrumowego wchodzą: właściciel produktu (ang. Product Owner), zespół deweloperski (ang. Development Team) oraz Scrum Master. Zespoły scrumowe są samoorganizujące się i międzyfunkcjonalne. Mają swobodę decyzyjną w zakresie niezbędnym do wytworzenia wysokiej jakości produktu, w tym wyboru stosowanych procedur i narzędzi i nie są w żaden sposób kierowane przez osoby spoza zespołu. Development Scrum - różne role, jeden cel! Dostarczają produkty iteracyjnie, czyli powtarzalnie oraz przyrostowo (ang. increment), zwiększając szanse na wczesne uzyskanie informacji zwrotnej. Klient bądź jego reprezentant biorą aktywny udział w procesie wytwórczym. Iteracje pozwalają zespołowi osiągnąć definicję zrobionego w każdym sprincie oraz, ostatecznie, produktu finalnego. Architect Tester Developer Scrum Master GUI Developer Product Owner

Role w zespole Product Owner Jest nosicielem i strażnikiem wizji produktu. Opowiada za budżet projektu. Pracuje w ścisłej łączności z zespołem - dostarcza feedback, zarządza zmianami, podejmuje decyzje. Odpowiada na pytania zespołu podczas całego projektu. Odpowiada za backlog produktu i user stories (historie użytkowników). Koncentruje się na maksymalizacji zysku z inwestycji. Product Owner jest klientem zespołu skupiającym się na stronie biznesowej przedsięwzięcia. Scrum Master Mistrz Scruma, który dba o jego prawidłowe wdrażanie. Pracuje zarówno z zespołem, Product Ownerem jak i całą organizacją. Upewnia się, że zespół jest optymalnie produktywny. Przyjmuje rolę zarządzającego w stylu partypacyjnym, a nie szefa projektu. Chroni zespół przed zewnętrznymi czynnikami i usuwa przeszkody stojące na jego drodze. Pokazuje im narzędzia pomocne w ich pracy.

Zadanie zespołu Mimo zróżnicowanych ról zespół ma wspólny cel, który spaja jego członków i pozwala na produktywną pracę. Zespół ma za zadanie przekształcić potrzeby wyrażone przez właściciela produktu w użyteczne funkcjonalności. Zespół deweloperski Zespół jest multidyscyplinarny (deweloperzy, graficy), złożony z profesjonalistów, których zadaniem jest dostarczenie na zakończenie każdego sprintu, gotowego do potencjalnego wydania przyrostu produktu. Dąży do wytworzenia ducha zespołowego (wszyscy jesteśmy na tej samej łódce). scrum nie uznaje podzespołów w zespole deweloperskim. Architect Tester Senior Developer Tester Junior Developer GUI Developer Członkowie zespołu deweloperskiego mogą posiadać wyspecjalizowane umiejętności, ale odpowiedzialność za pracę ponosi zawsze cały zespół.

Backlog produktu Właściciel produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy zespołu deweloperskiego. Odpowiada za backlog produktu. Właściciel produktu jest jedyną osobą zarządzającą backlogiem produktu (ang. Product Backlog). Aby właściciel produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje, które są odzwierciedlone w treści i kolejności elementów backlogu produktu. Właściciel produktu to pojedyncza osoba, nie komitet. Może reprezentować interesy grupy osób, lecz osoby chcące zmienić priorytet elementu backlogu produktu, muszą zwrócić się do właściciela produktu. Backlog produktu Formalizuje wizję produktu, który chcemy zrealizować. Opisuje główne cele użytkowników, do których chcemy dotrzeć. Działa jak przewodnik i scala członków projektu. Pozwala priorytetyzować te wymagania, które dostarczają największej wartości (albo największego ROI) interesariuszowi. Może ewoluować w ciągu trwania projektu.

Wydajny sprint 3

Zdarzenia w Scrumie Zdarzenia opisane w Scrumie są używane do wprowadzenia regularności i przejrzystości procesu. Wszystkie zdarzenia są ograniczone czasowo, co oznacza, że maksymalny czas ich trwania jest ustalony z góry. 1 Planowanie sprintu 2 Codzienny Scrum 3 Przegląd sprintu 4 Retrospekcja sprintu Każde ze zdarzeń w Scrumie, oprócz sprintu, który zawiera w sobie pozostałe zdarzenia, jest okazją do przeprowadzenia inspekcji i dokonania adaptacji. Zdarzenia te są specjalnie zaprojektowane w taki sposób, aby zapewnić przejrzystość i umożliwić inspekcję. Nieuwzględnienie któregokolwiek z nich redukuje przejrzystość i zaprzepaszcza szansę na dokonanie inspekcji i adaptacji. Czas trwania sprintu jest ustalany w chwili jego rozpoczęcia i nie może być skracany ani wydłużany. Pozostałe zdarzenia mogą się kończyć, kiedy tylko ich cel zostanie osiągnięty, co umożliwia wykorzystanie odpowiedniej ilości czasu i zabezpiecza przed jego marnotrawieniem.

Planowanie sprintu W planowaniu sprintu biorą udział wszyscy członkowie zespołu scrumowego. Sprint Backlog Zespół robi estymację czasu dla każdej czynności, która pozwoli przełożyć wymagania na funkcjonalności na koniec sprintu. Idealnie jest podzielić projekt na relatywnie krótkie odcinki, mniejsze lub równe 2 dniom roboczym. Działania, które są do zrealizowania w ciągu jednego sprintu są zcentralizowane w backlogu sprintu. Chodzi o oszacowanie, a nie o twarde zobowiązanie. Pozwala zespołowi na jasną wizję tego, co jest do zrobienia Uwaga! Agile nie musi mieć iteracji. Zwinne metodyki opierające się na systemie Kanban zamieniają regularność i przewidywalność czasową sprintu na minimalizację czasu niezbędnego do realizacji pojedynczej funkcjonalności oraz maksymalizację przepływu realizowanych funkcjonalności.

Codzienny Scrum Codzienny Scrum (stand up) jest zdarzeniem dla zespołu deweloperskiego, ograniczonym czasowo do piętnastu minut, podczas którego bieżące działania są synchronizowane i powstaje plan na najbliższe dwadzieścia cztery godziny. Co zrobiłem od ostatniego spotkania? Co zrobię w następnym kroku? Jakie trudności napotkałem lub jakich się spodziewam? Codzienna synchronizacja max 15 min.

Przegląd sprintu Przegląd sprintu to spotkanie organizowane na zakończenie sprintu w celu przeprowadzenia inspekcji przyrostu i, jeśli zajdzie taka potrzeba, dostosowania backlogu produktu. max 15 min. start 1 2 3 4 5 koniec SPRINT max. od 2 do 4 tygodni stały feedback od klienta Zespół koncentruje się na wypełnianiu zadań z backlogu sprintu Uwaga! Najtrudniejszą do zrealizowania, a najprostszą do zarzucenia praktyką jest faktyczne dostarczanie na koniec każdego sprintu gotowego do potencjalnego wydania przyrostu produktu. W naszej ocenie to właśnie dotrzymywanie tej praktyki określa stopień zwinności procesu. Wszystkie inne praktyki można dostosowywać w zależności od dojrzałości zespołu, rodzaju projektu, szczególnego kontekstu itp.

Retrospektywa sprintu Tutaj każda osoba z zespołu wypowiada się : z czego jest zadowolona, co poszło nie tak, co można usprawnić? Umożliwia to szybkie wyłapanie błędów w procesie i reakcję na nie. Retrospektywę moderuje Scrum Master Retrospektywa sprintu odbywa się po zakończeniu przeglądu i wstęp na nią ma jedynie zespół scrumowy. Następuje również identyfikacja dobrych praktyk, które powinny być stosowane w następnych iteracjach i ustalenie planu, w jaki sposób będą one wdrażane w codziennej praktyce zespołu. Najważniejsze ustalenia 1 godzina na każdy tydzień trwania sprintu Punkty dodatnie i punkty ujemne Jak się doskonalić? Feedback od klienta Przygotowanie kolejnego sprintu

Praktyki techniczne 4

Sam Scrum nie wystarczy Scrum jest dobry dla ludzi, ale nie definiuje, jak kodować. Do tego potrzebujesz praktyk technicznych. 1 Test-Driven Development 2 Pair Programming 3 Domain Driven Design Obniżenie odsetka błędów. Kod tańszy w utrzymaniu. Stabilny rozwój produktu. Jeszcze niższy odsetek błędów. Prostota rozwiązań. Większa produktywność. Trwałe podstawy pracy. Jednolite rozumienie domeny. Lepsze rozumienie wymagań biznesowych. Czy wiesz, że? Większość zwinnych praktyk programistycznych pochodzi z metodyki Extreme Programming. Najlepsze zespoły scrumowe są często w realizacji procesu dużo bliższe XP niż scrumowi: stosują 1-tygodniowe iteracje, korzystają z pomocy coach'a zamiast Scrum Mastera, stosują praktykę codziennych release ów (albo wręcz continuous delivery), pracują w parach i automatyzują wszystko, co się da.

Test Driven Development TDD to sprawdzona metoda działania, pozwalająca na ciągłe dbanie o jakość, na każdym etapie projektu. +1 Nieprzechodzący test Test driven development +1 +1 Udana refaktoryzacja Implementacja spełniająca test Czy wiesz, że? Rozpoczynanie prac od testów stosowali inżynierowie Projeku Mercury w NASA we wczesnych latach 60. Przy okazji: pracowali w półdniowych iteracjach. Agile i TDD to coś nowego? Raczej nie.

Pair programming Dwie osoby pracują razem przy jednym komputerze, nad tym samym zadaniem. Co dwie głowy, to nie jedna. Ciągła komunikacja prowadzi do najlepszych projektów. Intensywny kontakt z równym sobie partnerem prowadzi do wzrostu produktywności. Czy wiesz, że? Autorzy książki Pair Programming Illuminated, Laurie Williams i Robert Kessler, przytaczają wiele wyników badań naukowych dotyczących tej pratyki. Wynika z nich, że to bardzo efektywny sposób pracy!

Domain-Driven Design Zespół modeluje rozwiązanie z udziałem ekspertów domenowych. Następnie za pomocą sprawdzonych wzorców DDD wyraża Kod odzwierciedla ekspercką wiedzę z dziedziny Wszyscy używają jednolitego języka Dobrze podzielony projekt łatwo testować i rozwijać Czy wiesz, że? Domain-Driven Design definiuje zarówno przydatne wzorce programistyczne, jak również sposoby prowadzenia warsztatów z modelowania z udziałem ekspertów domenowych. Większość korzyści osiąganych dzięki wprowadzaniu popularnej architektury mikroserwisów odniesiesz stosując wzorzec DDD o nazwie Bounded Context.

Szkolenia Pragmatists Przez 7 lat pracy mentorskiej pomogliśmy wielu zespołom zmienić sposób, w jaki pracują i współdziałają. Uczymy tego, co sami stosujemy. 1 Trening przy biurku 2 Trwałe podstawy 3 Wspomagany rozwój Twoi ludzie pozostaną przy prowadzonych projektach. Zobaczysz efektywny transfer wiedzy, dzięki pracy 1 na 1. Wyposażysz zespół w nowe umiejętności do zastosowania natychmiast w praktyce. Zobaczysz, jak rozwijają oprogramowanie najlepsi programiści. Dowiesz się, co jest potrzebne, żeby szybko dostarczać działające funkcjonalności. Zapłacisz za samą esencję wiedzy. Wzmocnisz to, co służy częstemu dostarczaniu wartości klientom. Zbudujesz z nami nawyk ciągłego doskonalenia umiejętności. Zadbasz o długofalowe efekty.

Potrzebujesz dalszych wskazówek? Skontaktuj się z nami: +48 668 189 795 szymon.pruszyński@pragmatists.pl www.szkolenia.pragmatists.pl