Wzorce i Praktyki Inżynierskie

Czym jest szkolenie Applying Professional Scrum for Software Development™? Applying Professional Scrum for Software Development™ to akredytowane szkolenie od Scrum.org, skierowane do zespołów realizujących złożone projekty i tworzących produkty/usługi z branży IT. Na bazie doświadczeń grona ekspertów zarówno Scrum.org, jak i uznanych światowych liderów rozwoju oprogramowania, powstał program pozwalający zwiększyć efektywność złożonych procesów wytwarzania oprogramowania.

Zastosowanie takich praktyk jak np. programowanie w parach, TDD, BDD, Clean Code, czy SOLID pozwala interdyscyplinarnym Developerom w Scrum dostarczać wysokiej jakości przyrost produktu/usługi. Poprzez wprowadzenie standardów projektowania architektury, dokumentacji technicznej oraz automatyzacji procesów integracji/wdrażania, możliwe jest ciągłe dostarczanie wartości biznesowej minimalizując ryzyko błędu lub powstawania długu technicznego.

Szkolenie ma postać warsztatu opartego na dyskusji i symulacji rozwoju oprogramowania w Scrum, uwzględniającej 3 sprinty, każdy trwający około 2 godzin. Najwięcej korzyści może przynieść organizacjom które są w trakcie, bądź planują dostarczać oprogramowania w podejściu zwinnym. Każdy sprint kończy się wspólnym omówieniem i dyskusją na temat dopasowania stosowanych praktyk do własnej sytuacji uczestników. Warsztaty realizowane są najczęściej w jednym z poniższych języków: .NET, .NET core, Java, Python czy C++, a o wyborze języka decydują wspólnie uczestnicy szkolenia.

Kto za tym stoi?

Od strony inżynierskiej zdecydowana większość praktyk wywodzi się od paradygmatu programowania ekstremalnego (ang. eXtreme Programming, XP), który sformułowany został przez Kenta Becka, do rozwoju którego następnie dołączyli m.in. Ward Cunningham i Ron Jeffries. Założenia tego paradygmatu określają zarówno przyświecające wartości, wydarzenia i konkretne praktyki inżynierskie.

W ramach Scrum.org działają tzw. stewardzi, są to trenerzy PST (Professional Scrum Trainers) opiekujący się m.in. obszarem praktyki inżynierskich, ciągłym rozwojem, doskonaleniem i zapewnianie spójności z możliwym wykorzystaniem omawianych praktyk jako komplementarnych do frameworka Scrum.

Czym jest Domain-Driven Design?

Szkolenie Domain-Driven Design skierowane jest do zespołów realizujących złożone projekty i tworzące produkty/usługi z branży IT. Bazując na szczegółowej analizie dostępnych źródeł i własnym doświadczeniu w prowadzeniu komercyjnych projektów trenerzy rozwiewają wątpliwości dotyczące DDD i uczą prawidłowego zastosowania technik pozwalających zapanować nad złożonym systemem informatycznym.

Domain-Driven Design obejmuje zagadnienia z pełnego spektrum stadiów procesu wytwarzania oprogramowania. Program polecany jest więc osobom pełniącym różnorodne role - architektom, programistom, analitykom biznesowym, Product Ownerom. Największe korzyści uzyskają firmy, w których metodyka będzie rozumiana i stosowana holistycznie w całej organizacji ze względu na wzajemne zależności, które występują pomiędzy zagadnieniami skierowanymi do każdej z wymienionych grup.

DDD uczy, jak podzielić i skutecznie modelować złożony problem biznesowy redukując dystans pomiędzy wymaganiami interesariuszy a techniczną realizacją. Stosowanie prezentowanych technik pozwala skrócić czas analizy biznesowej, modelowania i implementacji, poprawnie wyznaczać priorytety, zmniejszyć ryzyko nieporozumień oraz zbudować system łatwo adaptowalny do zmieniających się potrzeb klientów.

Kto za tym stoi?

Historia Domain-Driven Design zaczęła się w roku 2003, kiedy Eric Evans wydał swoją słynną niebieską książkę „Domain-Driven Design: Tackling Complexity in the Heart of Software”. Sam autor przyznaje jednak, że techniki, które zebrał, nazwał i pogrupował, były już wcześniej szeroko stosowane przez profesjonalnych analityków biznesowych i architektów systemów informatycznych działających w metodykach z rodziny Agile.

W kolejnych latach DDD upowszechniło się, rozwinęło i dostosowało do nieustannie zmieniającego się krajobrazu świata IT. Za ewolucję metodyki odpowiedzialni są autorzy tacy jak Vernon Vaughn, Martin Fowler czy Jimmy Bogard.

Czym jest szkolenie Behavior-Driven Development?

Szkolenie Behavior-Driven Development skierowane jest do interesariuszy i zespołów deweloperskich realizujących złożone projekty i tworzących produkty/usługi z branży IT. Uczestnicy doświadczą pełnego cykl dostarczania nowej funkcjonalności w systemie informatycznym. Zdefiniowane zostaną role analityka biznesowego, testera i programisty w nowoczesnym, zwinnym procesie wytwórczym.

Jak możemy mieć pewność, że dostarczana funkcjonalność odpowiada potrzebom interesariuszy? Jest to kluczowe pytanie, z którym zmagają się zespoły deweloperskie. Błędy pojawiają się powszechnie zarówno na etapie zbierania wymagań, jak i zapewniania jakości dostarczonego rozwiązania. Stanowią one jednocześnie najczęstszą przyczynę porażek projektów informatycznych.

BDD rozwiązuje ten problem, dostarczając narzędzia minimalizujące ryzyko nieporozumień występujących we wszystkich fazach wytwarzania oprogramowania. Buduje most pomiędzy wymaganiami, implementacją, testami oraz dokumentacją. Skorzystanie w pełni z zalet szkolenia wymaga więc obecności osób pełniących istotne role w wymienionych procesach.

Kto za tym stoi?

Hasło “Behavior-Driven Development” pojawiło się po raz pierwszy na konferencjach IT w 2003 roku za sprawą Daniela Terhorst-Northa. Koncepcja w dojrzałej formie ujrzała światło dzienne w roku 2006, kiedy magazyn Better Software opublikował artykuł jego autorstwa zatytułowany “Introducing BDD”. W międzyczasie North zainicjował prace nad pierwszym frameworkiem BDD o nazwie jBehave.

Dan North zaobserwował, jak silnie rozpowszechniło się w świecie IT mylne rozumienie metody Test-Driven Development. Była to dla niego motywacja do jej przeformułowania. North postanowił powrócić do oryginalnej intencji, która stała za zasadami wypracowanymi przez Kenta Becka. Nowatorska perspektywa szybko zyskała popularność i wokół BDD wytworzyła się szeroka społeczność inżynierów oprogramowania, testerów oraz analityków biznesowych rozwijających również bliźniacze koncepcje pod nazwami “Acceptance Test-Driven Development”, “Acceptance Test-Driven Planning”, “Story Test-Driven Development” czy “Specification by Example”.