reQuest – konferencja dla wymagających
Przedstawiamy Państwu reQuest – konferencję przeznaczoną dla osób zaangażowanych w szeroko pojęty obszar analizy biznesowej i systemowej w IT.
reQuest to nowa marka na rynku polskim. Marka świeża i szybko rozwijająca się, której flagowym produktem ma być konferencja powołana z myślą o analitykach, realizowana przez analityków. Naszym celem jest zbudowanie społeczności skupionej wokół tematyki analizy, wymagań i potrzeb biznesowych; społeczności, która będzie aktywnie uczestniczyć w tworzeniu nowego wymiaru analizy – dziedziny innowacyjnej i interdyscyplinarnej, skutecznie przekuwającej potrzeby biznesowe na skuteczne i nowatorskie rozwiązania. Chcemy łączyć wiedzę i doświadczenia z różnych obszarów i dyscyplin, by rozszerzać kompetencje i możliwości analityków. Chcemy zachęcać do zadawania pytań, dyskusji i zejścia z utartych ścieżek w kierunku alternatywnych możliwości.
Osoby, które czują się częścią wyżej opisanej społeczności, serdecznie zapraszamy na konferencję reQuest. Zmieniaj z nami branżę IT!
Do pobrania:
Zapraszamy
- Analityków biznesowych i systemowych
- Projektantów rozwiązań IT
- Właścicieli Produktów
- Reprezentantów biznesu
- Testerów i specjalistów QA
- Wszystkich, którzy chcą wiedzieć i móc więcej!
Data i miejsce konferencji
Konferencja odbędzie się 4-5 października 2018
Lokalizacja:
Hotel Boss
Warszawa, ul. Żwanowiecka 20

Organizator konferencji
Stowarzyszenie Jakości Systemów Informatycznych
ul. Poznańska 16 lok. 4
00-680 Warszawa
WYKŁADÓW
WARSZTATÓW
DNI
MIEJSC
Prelegenci
Przedstawiamy naszych prelegentów.
Agenda
Rejestracja
Rejestracja uczestników, wydanie pakietów powitalnych, poranna kawa
Analityk i architekt w czasach automatyzacji i robotyzacji biznesu
Biznes się zmienia. IT się zmienia. Ale czy narzędzia i metody pracy analityka i architekta zmieniają się lub powinny zmienić się - w szczególności w czasach coraz powszechniejszej robotyzacji procesów? W prezentacji będę starał się spojrzeć na relacje występujące między analitykiem-architektem a robotami z dwóch różnych perspektyw – tj. czy musimy inaczej niż do tej pory podejść do analizy i architektury zrobotyzowanego biznesu i jak roboty mogą pomóc w pracy analityka/architekta. Okazuje się bowiem, że coraz częściej wiele firm patrzy na analityków/architektów jako koszt (który może i przynosi korzyści, ale mocno odroczone w czasie) i zastanawia się, czy jest jakieś podejście umożliwiające podniesienie efektywności pracy tych ról.
Andrzej SobczakAnaliza prawdziwie biznesowa - skąd biorą się projekty
Analityk biznesowy analizuje biznes? W większości przypadków – nie. Projekty wypadają nam jak z czarnej skrzynki. Czy mają sens? Czasem trafiają jak kula w płot. Czasem są jak armata na muchę. Czasem nie rozwiązują właściwego, najbardziej naglącego problemu. A czasem decydent chce zabawkę lub awans, zapominając o klientach i rozwoju firmy. Czy to problem analityka? Czy Twój projekt jest właściwy dla firmy? Przyjrzyjmy się temu, co dzieje się ponad projektem - analizie prawdziwie biznesowej, analizie organizacji i analizie strategicznej. Rozwikłamy zagadkę - skąd biorą się sensowne projekty i dowiemy jak definiować potrzebne firmie inicjatywy.
Hanna TomaszewskaBłędy w analizie z praktyki (nowe wydanie 🙂 )
Wiele lat temu podczas rozmowy rekrutacyjnej prezes jednej firmy powiedział do mnie: błędy popełniane na etapie analizy są najdroższe dla firmy. Wtedy była to dla mnie teoria, którą rozumiałam, ale za dużo na sobie nie doświadczyłam albo też nie potrafiłam ocenić skali czy wczuć się w powagę tych słów ☺ Każdy projekt, w którym brałam udział, każde doświadczenie dokładał kolejny kawałek do pewności co robię dobrze, a co źle, przyczyniał się do zmniejszenia ryzyka popełnienia błędu. Zazwyczaj uczymy się na własnych błędach, ale wiemy też, że najtaniej uczyć się na cudzych. Tylko nie zawsze to działa ☺ Zapraszam do edycji drugiej mojego wystąpienia „Błędy w analizie, co robić, i czy da się ich uniknąć” ☺ Opowiem o kilku kolejnych typowych potknięciach, które się zdarzają każdemu i o tym, jakie ja mam sposoby na przeciwdziałanie pojawieniu się podobnych kolejnych.
Elena ZhukovaJak NIE robić analizy w Scrumie
Większość firm technologicznych deklaruje, że używa Scruma. Często niestety jest to Scrum tylko z nazwy, a wprowadzone zmiany okazują się bardzo powierzchowne. Jednym z obszarów, który zwykle nie jest adoptowany do zwinnej rzeczywistości, jest szeroko rozumiana płaszczyzna analizy wymagań. W efekcie, pomimo dużych oczekiwań, wyniki pracy w Scrumie nie przynoszą spodziewanych efektów. Rozwiązaniem tej sytuacji jest dogłębne przeorganizowanie sposobu, w jaki wytwarzane są produkty w firmie. Zmiany te dotykają m.in. całościowego procesu wytwarzania, struktury firmy, sposobu w jaki zarządzane są zespoły czy technik zarządzania wymaganiami. Miałem okazję doświadczyć powyższych aspektów, pracując z wieloma firmami technologicznymi. Dzięki temu zrozumiałem m.in. jak ważne jest, aby to zespół — a nie pojedyncza osoba — brał na siebie odpowiedzialność za zrozumienie wymagań oraz potrzeb biznesowych. Podczas prezentacji dowiesz się, jak unikać najczęstszych pułapek pracy w Scrumie związanych z analizą wymagań oraz poznasz zwinne sposoby organizowania pracy, która zwiększą Twoje szanse na wczesne dostarczanie właściwych produktów.
Jacek WieczorekJak efektywnie współpracować ze zwinnym zespołem?
Analityk w zespole, analityk poza zespołem, analityk jako Product Owner, analityk jako Proxy Product Owner. W tej prezentacji skupię się stosowanych modelach pracy analityka ze zwinnym zespołem (w zespole). Poruszę ciekawsze techniki przydatne w tej współpracy takie jak: Living Documentation, Executable Specification, Domain Modeling, Event Storming. Jako osoba często zaangażowana w prace z zespołami dewelperskimi i patrząca z boku na pracę analityków, pokuszę się również moją subiektywną prognozę przyszłości tego zawodu.
Michał BartyzelArchitektura korporacyjna jako wstęp do analizy biznesowej i systemowej
Na ścianach, tablicach i innych powierzchniach nie jeden raz można zobaczyć kwadraty, prostokąty połączone ze sobą liniami. Obok znajdują się treści co te „kwadraty robią ze sobą”. Tak oto tworzy się architektura. W wielu przypadkach rysunki zostają przykrywane innymi rysunkami i tak idea architektury ginie. Sporo mówi się o procesach biznesowych. Wydaje się wręcz, że modelowanie procesów biznesowych w procesie wytwórczym oprogramowania to podstawa, do której odnoszą się kolejne etapy tego procesu. Z drugiej strony jest podejście zwinne, gdzie o architekturze i procesach mówi się mało lub wcale. W trakcie wystąpienia "Architektura korporacyjna jako wstęp do analizy biznesowej i systemowej" opowiem o moich praktycznych doświadczeniach z implementacji elementów architektury korporacyjnej w świecie wytwarzania oprogramowania. Na wstępie bardzo krótko scharakteryzuję architekturę korporacyjną. Wskażę jej produkty oraz interesariuszy, którzy powinni być nimi zainteresowani. Następnie skupię się na wykorzystaniu produktów architektury korporacyjnej przez analityków biznesowych i systemowych. W moim odczuciu architektura korporacyjna by istnieć i rozwijać się musi być włączona w proces wytwórczy oprogramowania. Z tego też powodu zaprezentuję wartość i wpływ produktów architektury korporacyjnej na pracę zespołów pracujących w modelu klasycznym jak i zwinnym.
Michał WolskiZagraj w zaangażowanie
Zagraj w zaangażowanie czyli jak dzięki grywalizacji angażować zespół projektowy. Graczy nie trzeba dodatkowo motywować do tego by chcieli osiągać kolejne poziomy w grze – dlaczego więc nie wykorzystać mechanizmów z gier do angażowania naszych zespołów projektowych by ułatwić im osiąganie celów? Możesz to zrobić dzięki grywalizacji, która w Polsce staje się coraz bardziej popularna. Fabuła, punkty, ranking, odznaki – to tylko niektóre ze stosowanych mechanizmów, które z codziennych zadań pracowników tworzą ich zawodową przygodę. Jak wpleść je w pracę naszego zespołu projektowego? Podczas wykładu nie tylko dowiecie się więcej o grywalizacji, ale będziecie mieli okazję sami zbudować koncepcję gry. Jakiej? Przyjdź i przekonaj się.
Anna JankowiakMiękkie umiejętności w pracy analityka biznesu
Jakakolwiek komunikacja odbywa się w relacji. Wywieranie wpływu, perswazja, przekonywanie odbywa się w ramach relacji. Praca analityka biznesu z klientem odbywa się w ramach utworzonych relacji. Kto opanuje sztukę perswazji zyskuje niezwykłą przewagę w procesie kontaktu z klientami. Przewaga ta jednak nie polega na znajomości jakiejś techniki, z którą wchodząc do klienta doprowadzamy go do współpracy i uzyskujemy niezbędne informacje. To nie jest technika, to idealne dopasowanie się do klienta, odkrycie jego potrzeby i zaspokojenie jej. Najważniejsze jest to, że liczą się niuanse, drobne szczegóły, a jednocześnie całość.
Tomasz FurgalskiJak sprzedać swój pomysł w 5 minut, czyli pitch deck dla BA
Każdy nowy pomysł, który chcemy zrealizować korzystając czy to z zasobów firmy czy też wsparcia inwestorów, musimy umieć skutecznie przedstawić. Najczęściej decydenci nie mają zbyt dużo czasu, aby zapoznać się ze wszystkimi szczegółami projektu. Jak ich przekonać w ciągu 5 minut? Co ich najbardziej zainteresuje? Jak powinna wyglądać skuteczna prezentacja? Im lepiej ją przygotujemy, tym większą mamy szansę na decyzję zgodną z naszymi oczekiwaniami. Zapraszam do wspólnego przyjrzenia się modelowi krótkiego, skutecznego przedstawiana pomysłów, który przydaje się w kontaktach z decydentami korporacji, z klientami czy z inwestorami.
Jarosław ŁojewskiCosmic truths about software requirements
Although there are few absolute truths in software development, I have discovered several requirements principles that apply almost universally to software projects. These principles emphasize the critical contribution that excellent requirements make to a project's success, and the critical contribution that customer involvement makes to excellent requirements. You'll hear several suggestions for practices that can help any team build a more effective customer-developer partnership. These cosmic truths can help your organization produce and manage accurate, consistent, and unambiguous sets of requirements.
Karl WiegersInternet of Things loves data - analysis of Industry 4.0
If Internet of Things is all about connectivity and cooperation then Industry 4.0 is based on data. In fact - lots of data! We are no longer talking about GigaBytes or TeraBytes but rather such abstract ideas and units like ExaBytes. And that's the main topic of this presentation - how huge is IoT, what is the value of switching from reactive to predictive company and why we use lambda architecture in the first place. And even if the concept of security, ethics, rules and regulations regarding data itself is also interesting on its own, this time we will focus directly on Industry 4.0 itself. Fast paced and intense presentation dedicated for Analysts and people loving and caring about IoT. Prelekcja w języku angielskim.
Marcin SikorskiStar Trek: BDD Enterprise
To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language. Prelekcja w języku angielskim.
Tomasz DubikowskiThe best techniques for Business Analysis and Requirements Engineering applicable in any Software Development Life Cycle
"Użytkownicy końcowi są w pełni zadowoleni ze swojego nowego oprogramowania", "Projekt rozwoju oprogramowania został zrealizowany dokładnie tak, jak oczekiwano i zakończył się sukcesem", "Komunikacja pomiędzy interesariuszami biznesowymi, technicznymi i użytkownikami była łatwa i skuteczna"... są stwierdzeniami, które rzadko słyszymy. Faktem jest, że wiele projektów zawodzi i często nie udaje się z tych samych powodów: niemożność zidentyfikowania właściwych potrzeb, podzielenia ich na wymagania i zarządzania nimi przez cały czas trwania projektu. W trakcie prezentacji przedstawimy kilka przykładów z życia codziennego, ilustrujących dobre i złe praktyki, wraz z zestawem technik rekomendowanych w celu ograniczenia ryzyka niepowodzenia projektu. Nawet jeśli istnieje bardzo duża liczba technik BA i Rozwoju Wymagań, wystarczy zapamiętać niektóre z nich i wybrać najbardziej odpowiednie w zależności od kontekstu. Podczas prezentacji, wychodząc od dobrych i złych przykładów z rzeczywistego życia dużych projektów IT z różnych sektorów, takich jak przemysł medyczny, określimy kilka dobrych praktyk wymaganych na początku projektu, aby zapewnić pozyskanie i zebranie odpowiednich potrzeb. Odpowiemy również na takie pytania: - jaki model rozwoju oprogramowania jest najlepszy do zapewnienia efektywnego procesu BA i rozwoju wymagań? - co zrobić, jeśli strona biznesowa projektu zmienia się nawet po rozpoczęciu Projektu Informatycznego? - w przypadku rzeczywistego sporu między stronami, jakie dowody powinny być w stanie dostarczyć obie strony? - jakiego poziomu dokumentacji (jeśli w ogóle) oczekuje się w przypadku zwinnego projektu.
Eric Riou De CosquerStart with Accessibility: Why, How and What
Dostępność jest wymogiem prawnym, prawie w każdym kraju na świecie. WCAG 2.1, sekcja 508 ustawy o rehabilitacji, ustawa o równości z 2010 r. to tylko przykłady świadczące o powadze dostępności. Dostępność oznacza zdolność każdego, bez względu na jego stan, do dostępu do produktów cyfrowych, transportu, produktów fizycznych. Sieć WWW i Internet jako całość stanowią coraz szersze źródło zasobów w wielu aspektach naszego życia, dlatego ważne jest, aby produkt cyfrowy był dostępny dla każdego, aby zapewnić równy dostęp i równe szanse. Dostępność jest łatwa i tania, jeśli tylko jako BA myślisz o tym na wczesnym etapie.
Piotr ZrolkaModel based testing as a BA tool
Model-based testing is an increasingly popular trend in the world of quality assurance. The aim of such an approach is to focus on a working system model and automatically generate test cases. However, how can it become useful in the work of a business or system analyst? The essence is in the model. It is called an executable specification. In this approach, it can take the form of code, gherkin syntax or UML graphs and diagrams. The latter is something that analysts use every day. In my presentation, I would therefore like to show how model-based testing can be used in the work of analysts. And how this approach can improve the work of the project team. Prelekcja w języku angielskim.
Arnika HryszkoAgile business analyst
Rozprzestrzenianie się Agile wiąże się z trudnymi wyzwaniami. Jeśli jesteś BA, który stoi w obliczu sytuacji, kiedy Twoja organizacja przechodzi transformację "zwinną", być może szukasz informacji o tym, co ta transformacja oznacza. Istnieje kilka błędnych przekonań na temat zwinnej adopcji i jeszcze więcej szumu. Wykład przedstawia moje osobiste doświadczenia w osiąganiu dojrzałości Agile organizacji z perspektywy analityka biznesowego. Prelekcja w języku angielskim.
Agnieszka KuglerDouble diamonds are a BA’s best friend
Design Thinking, co to jest tak naprawdę? Metoda - podejście - kultura - sposób myślenia? Tak, w rzeczy samej, wszystko z powyższych! Design Thinking staje się coraz popularniejsze wśród programistów, którzy chcą dostarczać lepsze rozwiązania dla swoich użytkowników; innowacyjne rozwiązania dla kiepskich, źle zdefiniowanych problemów - problemów, którymi organizacje naprawdę niepokoją się dzisiaj, ale których nie mogą wyrazić słowami dla swoich pracowników IT. Design Thinking opiera się na dwóch filarach: empatii i kreatywności, które są rozwijane w pięciu częściach: empatii, definicji, ideału, prototypu i testu. Elementy te nie są ściśle linearne, ani iteracyjne; przeplatają się ze sobą w trakcie realizacji projektu. Są sklejone ze sobą poprzez koncepcję "podwójnego diamentu". Propaguje to przemienność między myśleniem rozbieżnym, aby wygenerować bogaty zestaw innowacyjnych pomysłów i myśleniem zbieżnym, aby skupić się na jednym, wartościowym, działającym rozwiązaniu. Podwójny diament postuluje, by zrobić to dwukrotnie: najpierw dojść do jasnego punktu wyjścia dla rozwoju (oświadczenie "punktu widzenia"), a następnie dostarczyć uzgodnione, odpowiednio przetestowane, działające rozwiązanie.
Hans van Loenhoud7 Skills for highly effective teams
Despite years of efforts to improve the professional approach to developing software systems, many of these projects continue to fail. Investigations into these failures invariably denote poor interactions between humans, both within development teams and with customers and users, as a key factor. Recent evolution in development approaches, like human-centered design and extreme programming, try to address this problem, but until now, an overall view was missing. In this presentation we integrate these initiatives into a simple model, that arranges six key skills along two axes (customer–team and problem–solution) around communication as a core. Many techniques are available to implement these skills in development teams, so failure will no longer be the usual outcome. Prelekcja w języku angielskim.
Hans & OlivierCommunication - Language of Leader
Czy wiesz, że 65% naszego przeciętnego dnia pracy to komunikowanie się z naszymi kolegami i koleżankami? Komunikacja jest naprawdę niezbędna w naszym codziennym życiu. Komunikacja może zadecydować o sukcesie lub porażce projektu, nad którym pracujemy! Zła komunikacja sprawia, że tracimy nie tylko cenny czas, ale także pieniądze i zasoby. Przyjrzyjmy się stylowi, w jakim ludzie się komunikują, oraz różnym podejściom, które możemy zastosować, aby nasza komunikacja była bardziej efektywna i przestała marnować czas na spotkania, których nigdy nie potrzebowaliśmy, jeśli komunikowaliśmy się właściwie. Nauczę Cię najlepszych wskazówek i trików, aby odnieść sukces w komunikacji z Twoimi kolegami i partnerami i sprawić, by Twój projekt znów był wspaniały! Prelekcja w języku angielskim.
Petra BuskovaCosmic truths about software requirements
Although there are few absolute truths in software development, I have discovered several requirements principles that apply almost universally to software projects. These principles emphasize the critical contribution that excellent requirements make to a project's success, and the critical contribution that customer involvement makes to excellent requirements. You'll hear several suggestions for practices that can help any team build a more effective customer-developer partnership. These cosmic truths can help your organization produce and manage accurate, consistent, and unambiguous sets of requirements. Prelekcja w języku angielskim.
Karl WiegersDefiniowanie celów
Warsztat zawierać będzie część wprowadzającą – teoretyczną oraz praktyczną, podczas której uczestnicy będą mieli możliwość wykorzystać nabytą wiedzę na podanym przykładzie. Notacja Business Motivation Model pomaga zrozumieć zmianę, biznes, cel, powody zmian, uporządkować plany biznesowe, rozwoju organizacji, projektu, zmiany. Notacja ta pomaga uporządkować wiedzę, zrozumieć motywację a także zweryfikować spójność wymagań. Jest to świetne narzędzie dla twórców oprogramowania, analityków biznesowych, strategicznych, architektów, produkt ownerów, managerów, dyrektorów, project managerów, każdego kto ma styczność z biznesem i zastanawia się jak możemy go wspomagać. Dla każdego, kto zastanawia się, jak zweryfikować czy zebrane wymagania są spójne i kompletne. Podczas warsztatu uczestnicy będą mieli okazję na rzeczywistym przykładzie przećwiczyć tworzenie modelu BMM, zadać pytania i omówić rezultaty. Serdecznie zapraszam.
Elena ZhukovaWykorzystanie Canvasów w pracy analityka biznesowego - Value Proposal Canvas i Business Model Canvas w praktyce
Często występującym problem, z którym spotykają się analitycy biznesowi, jest niewłaściwy sposób zaadresowania wyzwań, którym mają sprostać tworzony produkt lub usługa. W konsekwencji powstają rozwiązania, które nie spełniają postawionych przed nimi, często niewypowiedzianych na etapie analizy założeń. To niesie za sobą konieczność wprowadzania zmian, frustrację i negatywne uwagi kierowane między innymi do analityka biznesowego. Bo jego rolą jest również pomoc pomysłodawcom we właściwym przygotowaniu podstaw do realizacji projektu. I nie jest tutaj istotne, czy posługujemy się metodą waterfall-ową czy zwinną – jeśli założenia projektowe zostały zdefiniowanie nieprawidłowo, to dowieziony rezultat też będzie nieprawidłowy. Wychodząc z założenia, że dostarczone rozwiązanie ma spełniać wymagania klientów czy użytkowników, którzy będą mieli z niego skorzystać, warto rozpocząć analizę od zdefiniowania ich potrzeb, oczekiwań, cech, których nie lubią w podobnych rozwiązaniach, ale też takich, które dają im przyjemność z ich używania. W takiej analizie i przełożeniu jej rezultatów na odpowiednie cechy produktu pomóc może Value Proposition Canvas (VPC). Jest to prosta w użyciu, ale mająca głęboki sens koncepcja mapowania potrzeb i oczekiwań różnych klientów i użytkowników na cechy produktu – wartości, które produkt da swoim odbiorcom. Sam produkt (materialny lub usługa) nie powstaje tylko dzięki określeniu, co ma dostarczyć. Aby mógł być dostarczony, musi być osadzony w szerszym kontekście, w pewnym otoczeniu. Do stworzenia produktu czy usługi potrzebne są zasoby, partnerzy, praca, która musi być wykonana. Jego dostarczenie odbiorcom możliwe jest dzięki specyficznym kanałom dystrybucji, a samo pozyskanie tych odbiorców wymaga wykonania określonych działań, zaadresowanych do danego produktu, klienta i kanału komunikacji. W kontekście ekonomicznym, wszystkie wymienione wyżej działania, które oznaczają określone koszty, muszą pozwolić na osiągnięcie przychodów, pozwalających na pokrycie wydatków inwestycyjnych, utrzymaniowych, sprzedażowych i rozwojowych. Wszystkie wyżej wymienione aspekty możemy przeanalizować dzięki kolejnemu, wizualnemu narzędziu, Business Model Canvas (BMX). Ten model, połączony z VPC poprzez wartości dostarczane przez produkt i klientów, pozwala na wykonanie takiej analizy. Pozwala też na przygotowanie różnych wariantów sposobu stworzenia produktu, jego dostarczania do klientów, utrzymywania i rozwoju – pilnując kosztów i korzyści. Stosując opisane wyżej dwa narzędzia możemy skutecznie wesprzeć koleżanki i kolegów z biznesu w odkryciu rzeczywistych wartości, jakie ich produkt może dostarczyć klientom. Pomożemy im też w osadzeniu wymyślonej koncepcji w szerszej perspektywie, która będzie miała wpływ na zakres i sposób realizacji projektu, który wspieramy.
Jarosław ŁojewskiPisanie testowalnych wymagań (Jak pisać wymagania, aby współpraca z testerami i programistami układała się lepiej).
Pisanie dobrych wymagań jest sztuką. Ale co tak naprawdę znaczy, że wymaganie jest dobrze napisane? Czy zastosowanie poprawnej polszczyzny, zobrazowanie odpowiednimi grafikami, czy może użycie języka technicznego? Dobre wymaganie to takie, które jest zrozumiałe dla wszystkich, w tym (a może przede wszystkim) dla programistów i testerów, którzy z tymi wymaganiami muszą pracować. Stworzenie dobrych i testowalnych wymagań przyczynić się może do skrócenia czasu spędzanego w projektach z powodu niejasnej lub niepoprawnie napisanej specyfikacji. A także do usprawnienia komunikacji wewnątrz zespołu. Uczestnicząc w warsztacie - poprzez serię praktycznych ćwiczeń i dyskusji - poznasz pojęcie testowalności wymagań, a także poszerzysz swoją wiedzę i umiejętności w zakresie pisania ich w sposób jasny i dobrze ustrukturyzowany. Warsztat ten kierowany jest do wszystkich tworzących wymagania, współpracujących z zespołami projektowymi, programistami i testerami.
Arnika HryszkoGry jako mniej konwencjonalna metoda poszerzania wiedzy o agile
W ramach warsztatu mam zamiar przedstawić uczestnikom 6 gier. Każdą grę poprzedza wstęp teoretyczny a następnie zapraszamy uczestników do wspólnej zabawy. Pierwsza z gier dotyczy wspólnej, pozytywnej komunikacji w zespole. Spośród osób z widowni zapraszam dwie osoby, które chcą wspólnie zorganizować przyjęcie. W pierwszej wersji jedna osoba daje pomysły a druga je torpeduje. Po chwili uczestnicy przedstawiają drugą scenkę, tym razem jedna osoba daje pomysły a druga dopełnia je własnymi pomysłami. Po występie, wspólnie z widownią podsumowujemy to co zaobserwowali. Druga gra to zabawa monetami Euro. Spośród widowni zapraszam do wspólnej zabawy 10 osób, każda z osób dostaje ściśle określoną rolę. Reszta widowni pozostaje czujnymi obserwatorami. Zabawa polega na budowaniu wież z monet Euro (każdej o tym samym nominale). W zabawie przeprowadzamy wspólnie 4 iteracje zmniejszając za każdym razem ilość monet w serii. Zabawa symuluje różne podejścia prowadzenia projektu a monety prace do wykonania. Symulujemy podejście klasyczne, hybrydę iteracyjno inkrementalną oraz agile w dwóch postaciach. Za każdym razem mierzymy czas potrzebny na osiągnięcie rezultatu prac. Na koniec wspólnie z całą widownią dokonujemy oceny rezultatów i szukamy wniosków. Trzecia zabawa polega na podziale wszystkich uczestników warsztatu na 5 osobowe zespoły, osoby dzielą się same. Następnie każdy z zespołów dostaje zestaw materiałów z których mają w trakcie jednej iteracji trwającej 18 minut zbudować jak najwyższą wieżę. Jednocześnie wyznaczone zostaje minimum zaliczające zadanie i punkty akceptacji wyniku końcowego. Drużyny mają okazję poznać zalety prototypowania i eksperymentowania oraz pracy w grupie osób świeżo poznanych (formowanie zespołu, podział prac, wspólny cel pracy, testowanie pomysłów). Czwarta gra to piekielne krzesła. Osoby dzielą się na 3 równe drużyny, każda z drużyn otrzymuje zadanie własne oraz informację, że na zwycięzców czekają nagrody. Nikt nie może się odzywać, testujemy cichą współpracę. Startuje czas i osoby zaczynają walczyć o krzesła. W grze chodzi o dojście do wspólnego celu który zadowoli wszystkich. Piąta gra to nauka przeprowadzania spotkania daily scrum. Wybieram z sali ok. 11 osób. Osoby tworzą jeden zespół pracujący nad własnym projektem. Mają zasymulować standardowe 15 minutowe spotkanie dzienne. Aby nie było za łatwo, każdy poza standardową agendą losuje ukrytą rolę (która pokazuje dysfunkcje podczas daily scrum). Dopóki osoba wybrana jako scrum master nie odkryje i nie zaadresuje ukrytej agendy dopóty dana osoba przeszkadza w przeprowadzeniu sprawnego spotkania. Na koniec widownia opowiada jakie dysfunkcje zauważyła i czy zostały prawidłowo zaadresowane. Wypowiada się również osoba wybrana do roli scrum mastera. Szósta gra ponownie angażuje do pracy wszystkich uczestników warsztatu. Osoby dzielą się na zespoły zwinne po około 5- 7 osób. Mają za zadanie symulować jedną organizację projektową produkującą papierowe samoloty na rynek. Grę zaczynają ze startowym budżetem i poleceniem samoorganizacji pracy w iteracjach. W ramach iteracji dostają od PO informacje o zapotrzebowaniu na rynku, szablony samolotów i warunki określające jakość produktu. Następnie zespoły symulują sprinty działając w oparciu o DoD. Do ich budżetu wpływa kasa za wyprodukowane samoloty spełniające DoD. Realizuję w ten sposób 3 iteracje, po czym zmieniają się realia rynkowe. Mierzymy budżety przez wszystkie iteracje a na koniec podsumowujemy symulację wspólną dyskusją.
Rafał StańczakDostępność w praktyce - nie taki diabeł straszny, jak go malują.
Szkolenie jest kierowane do wszystkich osób zaangażowanych w proces tworzenia produktów cyfrowych, a w szczególności projektantów, designerów, product managerów/ownerów, testerów i programistów oraz przedstawicieli administracji publicznej, którzy chcą, aby osoby wykluczone cyfrowo stały się potencjalnymi użytkownikami ich produktów. 1. WPROWADZENIE DO DOSTĘPNOŚCI -Podstawowe pojęcia związane z dostępnością, -W jaki sposób osoby niepełnosprawne i starsze korzystają z produktów cyfrowych, -Prawo o dostępności: Section 508, WCAG 2.0. 2. DOBRE PRAKTYKI W TWORZENIU PRODUKTOW CYFROWYCH -Odpowiedniki tekstowe dla elementów multimedialnych, -Nagłówki, -Kontrast, -Obsługa za pomocą klawiatury, -Etykiety pól formularzy, -Tabele. 3. PRZEPROWADZANIE BADAŃ DOSTĘPNOŚCI 4. ĆWICZENIA WARSZTATOWE
Piotr ŹrołkaChodzi o to, aby język giętki powiedział wszystko, co pomyśli głowa – czyli jak konstruować wymagania, aby być dobrze zrozumianym
Jednym z najtrudniejszych momentów w pracy inżyniera wymagań, bądź analityka jest nie sama analiza rozwiązania, lecz odpowiedni dobór słów opisujące co jest do zrobienia w systemie. Jest to kluczowe, ponieważ dokumentu nie tworzymy dla siebie, lecz dla: klienta, programisty oraz testera. Każda z grup ma różne oczekiwania względem takiego dokumentu. Powstaje pytanie- w jaki sposób opisywać wymagania biznesowe, oraz wymagania funkcjonalne, aby opis ten był zrozumiały, jednoznaczny? Czego unikać, a o jakie elementy wzbogacić nasz opis? O tym oraz o wielu innych dobrych praktykach dowiesz się podczas warsztatów, na które serdecznie zapraszam.
Monika PerendykConnecting PO with agile practices, traceability and testing
Cel: Celem warsztatu jest przekazanie uczestnikom wiedzy na temat efektywności Agile i potęgi kooperacji, którą oferuje. Nauczymy się również czemu dzielenie się dokumentacją nie oznacza zawsze dzielenia się wspólną wizją produktu i jakie są dobre praktyki i sposoby śledzenia zmian, które umożliwią zespołowi wykonanie większej ilości zadań w węższym zakresie czasu. Podyskutujemy również czemu agile jest swego rodzaju sztuką – zarówno metaforycznie jak i dosłownie – w zakresie produkcji oprogramowania. Materiał: Warsztat będzie mieszanką zadań praktycznych (gry) oraz teoretycznej (wyjaśnienia) wiedzy. W części teoretycznej trener wejdzie w interakcję z uczestnikami, by zdobyć wiedzę na tematy ich oczekiwań, a następnie podzieli się swoim doświadczeniem w obszarze Agile. Od postaw, manifestu, ról i znaczenia sprintu do praktyk dotyczących mierzalności i „zwinnego grzbietu”. Zagłębimy się w dyskusję dotyczącą różnego zrozumienia Minimalnego Widocznego Produktu i tego, jakie dobre praktyki stosować oraz adaptować we własnych projektach. Część praktyczna będzie serią ćwiczeń, które udowodnią ukryty potencjał drzemiący w metodykach zwinnych. W finałowym ćwiczeniu postaramy się wspólnie zaadoptować i zastosować „zwinny grzbiet” do przykładowego, zdawałoby się prostego projektu. Po zakończeniu zadania zastanowimy się jakie jeszcze praktyki zastosować by dodatkowo zoptymalizować efektywność i etyczność pracy. Korzyści: Po zakończonym warsztacie uczestnik powinien: · Być w stanie wyjaśnić zalety zwinnego podejścia; · Wyjaśnić dlaczego kooperacja z klientem jest tak istotna na każdym poziomie projektu; · Rozumieć potrzebę roli testera w zwinnym projekcie; · Być w stanie opisać i wymienić praktyki dotyczące mierzalności; · Użyć „zwinnego grzbietu” by tworzyć lepsze historyjki. Warsztat w języku angielskim.
Marcin SikorskiPresentation Skills: How to make every your presentation successful?
Czy denerwujesz się za każdym razem, gdy jesteś proszony o przemawianie przed publicznością? Czy jesteś zdenerwowany mówiąc przed ludźmi, nawet jeśli jest to tylko spotkanie biznesowe? Chcesz błyszczeć na scenie i podczas prezentacji? Jeśli odpowiedziałeś twierdząco na te trzy pytania, to nie ma nic lepszego, co mógłbyś zrobić, aby poprawić te umiejętności, niż dołączyć do warsztatu Petry poświęconego umiejętnościom prezentacji. Oczekujcie czterech godzin intensywnej pracy, podczas której poznacie wszystkie istotne elementy prezentacji oraz języka ciała na scenie i podczas spotkań biznesowych! UMIEJĘTNOŚCI PREZENTACJI: JAK SPRAWIĆ, BY KAŻDA PREZENTACJA ZAKOŃCZYŁA SIĘ SUKCESEM? Czy jesteś analitykiem biznesowym? Czy jesteś Test Leadem? Czy jesteś inżynierem jakości? Czy jesteś... Niezależnie od tego, kim jesteś, na jakimś etapie kariery zawodowej, musisz prezentować coś innym. Bez względu na to, jak dobry produkt posiadasz, jeśli nie wiesz jak go sprzedać, Twoi interesariusze nie zaaprobują go. W testowaniu oprogramowania koncentrujemy się na narzędziach, technikach i procesach, zapominając jednocześnie o podstawach. O tym, że jesteśmy ludźmi, którzy pracują z innymi ludźmi. Moim zamiarem jest nauczenie Was, jak wyrażać swoje idee i potrzeby w sposób zrozumiały i przekonujący. Chciałbym podzielić się swoimi doświadczeniami w zakresie prezentacji przed zarówno małą, jak i dużą publicznością. Porozmawiamy o tym, jak ważna jest świadomość siły pierwszego wrażenia. Wyobraź sobie, że w większości przypadków, pierwsze 7 sekund stanowią o "wygrać" i "przegrać" w każdym biznesie. Styl uścisku dłoni, sposób wprowadzenia. Po tym warsztacie natychmiast dowiesz się, jak dostać się pod skórę klienta. Czy znasz to uczucie? Wasza prezentacja była dobra, pełna wielu ciekawych i ważnych faktów. Ale nic nie pamiętasz. Brak kluczowych punktów, które utknęły w pamięci. Czy jest to problem struktury prezentacji? Może. A może będziecie zaskoczeni - często zdarza się, że brakuje języka ciała! Nauczę Cię, jak wspierać swoją wypowiedź konkretnymi gestami, tak aby ludzie skupili się, lepiej rozumieli i zapamiętali więcej. Opowiadanie historii w testach oprogramowania? Nie dotyczy. Mamy jasne wymagania, jasne instrukcje. Nie ma czasu na głupie historie. Chwila! Wszyscy kochamy historie. I jest różnica między tymi dwoma stwierdzeniami: 1. Nasza aplikacja umożliwia zamawianie do 100 ton betonu w trybie ad-hoc". 2. Nasza aplikacja umożliwia zamawianie do 100 ton betonu w trybie ad-hoc. Wyobraźmy sobie, że nasz ostatni klient desperacko potrzebował 90 ton w ostatniej chwili, na szczęście wszystko dostarczyliśmy w ciągu 2 godzin i uratowaliśmy jego pieniądze, czas i w zasadzie całą konstrukcję". Mówisz do mnie? Prezentujesz nowy produkt interesariuszom lub suche daty i wykresy dla Top Managmentu lub proces testowania dla Inżynierów Jakości? Jaki jest Twój cel? Poznaj swoją publiczność, to jest klucz. Istnieje wiele różnic w strukturze, tonie głosu, używanych słowach i poszczególnych krokach 'Call to action' w zależności od tego, czy chcesz poinformować, przekonać czy zainspirować publiczność. Co jeszcze? Znacznie więcej, mamy 4 godziny, więc nie spodziewaj się, że usiądziesz w kącie. Ta sesja będzie intensywna, pouczająca, zabawna i wciągająca. Każdy, kto chce być doskonały w prezentowaniu, nie powinien tego przegapić! Warsztat w języku angielskim.
Petra Buskova7 Skills for highly effective teams
The 7 Skills model helps IT projects to become more successful by addressing the key success factor of all teams: the soft skills of the team members. The model starts from two assumptions: (a) true success is a matter of good teamwork and (b) good teamwork is based on emotional interactions between individuals. The model is aligned along two axes: the ‘Customer facing’ - ‘Team facing’ axis and the ‘Problem facing’ – ‘Solution facing’ axis. In the center is ‘Communication’ as the fundamental skill that is the starting point for all interactions. Arranged around this core you find six key skills that are important for every IT project: ‘Empathize’ (customer/problem), ‘Explore’ (team/problem), ‘Collaborate’ (team), ‘Ideate’ (team/solution), ‘Tell’ (customer/solution) and ‘Sell’ (customer). The 7 Skills model serves as a road map to improve human interactions in development projects. To implement it, each skill has been substantiated by one or more simple but proven techniques. To mention some: communicate – Shannon-Weaver model; empathize – Personas; Explore – goal trees; Collaborate – Belbin team roles; Ideate – Wallas’ creativity model; Tell – storyboarding; Sell – Cialdini’s principles. These techniques of the 7 Skills model can easily be presented and explained. However, to make them work, one should exercise them. Therefore, a workshop is an excellent way to transfer the concept: you will learn most by actually doing it. In this workshop, you will work with other participants in a small team to design the outlines of a simple IT system. We will explain all techniques and give you some practical exercises with a challenging selection of them.
Hans & OlivierDancing with the devil - how to cooperate with a problematic customer
Jako analitycy biznesowi codziennie spotykamy się z trudnymi klientami. Dlatego też potrzebujemy specjalnego zestawu narzędzi, aby radzić sobie z takimi ludźmi i tworzyć sytuacje, w których nasze projekty przynoszą obopólne korzyści. Głównym celem tego warsztatu jest dostarczenie Tobie takiego arsenału. Cały warsztat zostanie podzielony na trzy części: 1. Jak zidentyfikować różnych typów klientów i jak z nimi negocjować - poznasz kilka różnych typów osobowości i nauczysz się analizować własnych interesariuszy. Dla każdego typu określimy konkretny zestaw narzędzi do wykorzystania podczas spotkań i w codziennej pracy. Następnie poproszę o scharakteryzowanie niektórych osób, z którymi współpracujecie, aby znaleźć najlepsze podejście do negocjacji z nimi. 2. Wizualizacja celów w ramach interaktywnych spotkań - dowiesz się, jak tworzyć Impact Mapy i jak je wykorzystać w swojej pracy. Ponieważ Impact Mapy mogą być wykorzystywane nie tylko w projektach IT, jest to realne narzędzie do wykorzystania nawet w życiu osobistym. W tej części omówimy również myślenie projektowe i jak można je wykorzystać do lepszego rozpoczęcia/odkrycia. Dlatego podczas tej części warsztatów będziemy: a. Uczyć się, jak tworzyć dobre cele biznesowe. b. Rysować własną Impact Mapę (w oparciu o założony cel). c. Uczyć się, jak walidować wymagania przy użyciu techniki mapowania wpływu na środowisko. d. Przekształcimy Impact Mapę w backlog e. Uczyć się o podejściu design thinking i jak go używać w codziennej pracy 3. Studium przypadku i dyskusja - przedstawię kilka złożonych przypadków, z którymi zetknąłem się w trakcie swojej kariery zawodowej i opiszę techniki analizy biznesowej, których użyłem. Następnie przeanalizujemy Wasze przypadki i wspólnie postaramy się znaleźć odpowiednie rozwiązania. Warsztat w języku angielskim.
Krzysztof KołosowskiRejestracja zakończona
Lokalizacja
- Hotel Boss
Warszawa
ul. Żwanowiecka 20 - kontakt@request.pl