Better Software Design

Better Software Design podcast. Rozmowy o projektowaniu oprogramowania, architekturze i wyzwaniach z tym związanych.

Kategorie:
Technologia

Odcinki od najnowszych:

83. O testowaniu systemu end-to-end i Quality Assurance z Arkadiuszem Jelonkiem
2024-03-19 01:00:00

Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób. Do tej pory temat jakości oprogramowania przewijał się głównie z perspektywy developerskiej w rozmowach o testach jednostkowych, Test Driven Development czy różnych odmianach piramidy testów. Na strukturę testów w projekcie warto też spojrzeć z jej drugiej strony, black-boxowych testów end-to-end całego systemu. Gościem w podkaście jest dziś Arkadiusz Jelonek, pracujący na co dzień jako Senior Quality Assurance Engineer w eSky Group. A rozmawiać będziemy nie tylko i testach E2E systemu, ale także o tym, jaką rolę QA pełni w projekcie i dlaczego QA warto czasem przetłumaczyć jako Questions Asker. W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o: roli Quality Assurance w projekcie zdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupie pytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Asker roli testów end-to-end w projekcie klasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testów powstaniu Playwrighta i problemach, które to narzędzie rozwiązuje testach regresji wizualnej sposobach unikania kruchości w testach E2E Ten odcinek jest także pierwszym z mini-serii rozmów poświęconych rozwojowi własnej kariery w IT, nie tylko na stanowisku developera. Myślisz o tym, aby pracować w tej branży np. jako Solution Architect, Engineering Manager, Chief Technology Officer czy zostać konsultantem? To tylko niektóre role i stanowiska, które pojawią się w przyszłych odcinkach Better Software Design… Materiały dodatkowe: The Evolution of Browser Automation , artykuł i prezentacja Christiana Bromanna z Sauce Labs Zawód tester - Od decyzji do zdobycia doświadczenia , książka Radosława Smilgina, dla osób początkujących Pasja testowania (wydanie 2, rozszerzone) , książka Krzysztofa Jadczyka, także dla początkujących

Odpowiedzialność za zapewnienie jakości w projekcie nie spoczywa na pojedynczej osobie, tylko na całym zespole. A rola QA nie sprowadza się tylko i wyłącznie do projektowania i implementacji przypadków testowych w procesie inspekcji systemu, ale także na byciu adwokatem jakości w projekcie, i czasem zadawaniu trudnych pytań o to, dlaczego pewne funkcjonalności są zrobione w ten, a nie inny sposób.

Do tej pory temat jakości oprogramowania przewijał się głównie z perspektywy developerskiej w rozmowach o testach jednostkowych, Test Driven Development czy różnych odmianach piramidy testów. Na strukturę testów w projekcie warto też spojrzeć z jej drugiej strony, black-boxowych testów end-to-end całego systemu.

Gościem w podkaście jest dziś Arkadiusz Jelonek, pracujący na co dzień jako Senior Quality Assurance Engineer w eSky Group. A rozmawiać będziemy nie tylko i testach E2E systemu, ale także o tym, jaką rolę QA pełni w projekcie i dlaczego QA warto czasem przetłumaczyć jako Questions Asker.

W dzisiejszym odcinku wspólnie z Arkiem rozmawiamy między innymi o:

  • roli Quality Assurance w projekcie
  • zdobywaniu doświadczenia pracując w Software House, dojrzałej firmie produktowej i startupie
  • pytaniach, jakie warto zadać w zespole wchodząc w rolę Questions Asker
  • roli testów end-to-end w projekcie
  • klasyfikacji, różnicach i doborze właściwych narzędzi wspierających automatyzację testów
  • powstaniu Playwrighta i problemach, które to narzędzie rozwiązuje
  • testach regresji wizualnej
  • sposobach unikania kruchości w testach E2E

Ten odcinek jest także pierwszym z mini-serii rozmów poświęconych rozwojowi własnej kariery w IT, nie tylko na stanowisku developera. Myślisz o tym, aby pracować w tej branży np. jako Solution Architect, Engineering Manager, Chief Technology Officer czy zostać konsultantem? To tylko niektóre role i stanowiska, które pojawią się w przyszłych odcinkach Better Software Design…

Materiały dodatkowe:

82. O architekturze makro front-endu Atlassiana z Bartoszem Cytrowskim prowadzi Tomasz Ducin
2024-03-05 01:00:00

Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin. Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem. Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie! W tym odcinku usłyszysz między innymi o: czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie, narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud, sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie, kontrolowaniu zależności pomiędzy modułami, stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów, testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji. Zapraszam!

Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.

Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem.

Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie!

W tym odcinku usłyszysz między innymi o:

  • czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,
  • narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,
  • sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,
  • kontrolowaniu zależności pomiędzy modułami,
  • stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,
  • testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.

Zapraszam!

81. O procesie discovery i wprowadzaniu DDD do organizacji z Darkiem Pawlukiewiczem i Michałem Wilczyńskim
2024-02-27 01:00:00

Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery. Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny. Materiały dodatkowe: Domain model purity vs. domain model completeness (DDD Trilemma) , wspomniany w rozmowie artykuł Vladimira Khorikova The failed promise of Domain-Driven Design - part 1 , artykuł Sebastiana Gębskiego The failed promise of Domain-Driven Design - part 2 , kontynuacja powyższego artykułu

Błędów nie popełnia tylko ten, co nic nie robi, a szramy Wietnamu biorą się z nie z czytania książek, tylko z osadzania zawartych w nich idei w złożonej rzeczywistości konkretnych projektów. Dziś zapraszam na rozmowę o często trudnych realiach wprowadzania Domain-Driven Design do organizacji i procesach Domain Discovery.

Moimi gośćmi są Dariusz Pawlukiewicz i Michał Wilczyński, programiści i architekci, zaangażowani w inicjatywę DevMentors. A rozmawiamy przede wszystkim o doświadczeniach związanych z wprowadzaniem DDD do zespołów i organizacji, oraz o częstych problemach występujących w procesach poznawania domeny.

Materiały dodatkowe:

80. O ostrej zasadzie Pareto, DDDozie i innych chorobach projektowych z Piotrem Przybyłem
2024-02-20 01:00:00

Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu... Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe. Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze. Materiały dodatkowe: Cztery choroby , prezentacja Piotra z konferencji Boiling Frogs 2019 Architecture antipatterns and how to beat them, część 1 , prezentacja Łukasza Szydło z konferencji 4Developers 2017 Architecture antipatterns and how to beat them, część 2 , kontynuacja powyższej prezentacji

Czy kilka twoich projektów dla różnych klientów ma dokładnie taką samą strukturę wewnętrzną, stosowane są dokładnie te same wzorce organizacji kodu i architektury? Albo wszędzie widzisz możliwość zastosowania CQRS, rozdziału na komendy i query, czy możliwość zaimplementowania taktycznych wzorców z DDD? W wielu przypadkach będzie to zapewne całkowicie uzasadnione, poza tymi, w których nie ma to większego sensu...

Abraham Maslow kiedyś opisał to zjawisko mówiąc: dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź. Idąc tym torem, posługiwanie się tylko jednym młotkiem nie jest ani wygodne, ani zdrowe.

Po ostatnich odcinkach podcastu poświęconych architekturze, zapraszam na luźniejszą rozmowę z Piotrem Przybyłem o chorobach, które czasami można zauważyć w naszych projektach i zespołach. A rozmawiamy m.in. o ostrej zasadzie Pareto, projektowym "good enough" i kilku chorobach, które warto mieć na swojej developerskiej uwadze.

Materiały dodatkowe:

79. O modularyzacji bez użycia subdomen i heurystyk DDD z Łukaszem Szydło
2024-01-30 01:00:00

Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw... Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka. Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać. W tym odcinku rozmawiamy z Łukaszem o: hype na Domain-Driven Design i trudnościach w jego stosowaniu intuicjach, heurystykach vs. praktyki inżynieryjne analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian weryfikacji wytwarzanych w ten sposób podziałów w projekcie dobrych momentach na refaktoryzację systemu Materiały dodatkowe: Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w First SDLab , inicjatywa projektów badawczych w zakresie projektowania oprogramowania

Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...

Bo czym właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i właściwie czemu to ma służyć? Jeśli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.

Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.

W tym odcinku rozmawiamy z Łukaszem o:

  • hype na Domain-Driven Design i trudnościach w jego stosowaniu
  • intuicjach, heurystykach vs. praktyki inżynieryjne
  • analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy
  • sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji
  • stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian
  • weryfikacji wytwarzanych w ten sposób podziałów w projekcie
  • dobrych momentach na refaktoryzację systemu

Materiały dodatkowe:

  • Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w First
  • SDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania

78. O Outbox Pattern i skutecznej komunikacji z Jackiem Milewskim
2024-01-16 01:00:00

W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox. Do rozmów w podkaście zapraszam osoby, które nie raz czy dwa zderzyły się z danym problemem w życiu i posiadają konkretne doświadczenie. Nie inaczej jest tym razem, a moim gościem jest dziś Jacek Milewski, który na co dzień pracuje jako modelarz i architekt oprogramowania. W tym odcinku wraz z Jackiem rozmawiamy między innymi o: problemach związanych z komunikacją w systemach, idei wzorca Transactional Outbox / Store&Forward, możliwych sposobach obsługi outboxa w systemie, zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych, kolejności przetwarzania wiadomości, deduplikacji czy message-poisoning. Materiały dodatkowe: Microservices: Transactional outbox oraz AWS Prescriptive Guidance: Transactional Outbox Pattern , opis omawianego w odcinku rozwiązania wraz z przykładowymi diagramami Outbox Pattern: kiedy ten strzał do API to jednak za mało , prezentacja Jacka z konferencji Confitura PL 2023 Push-based Outbox Pattern with Postgres Logical Replication , artykuł Oskara Dudycza przedstawiający rozwiązanie oparte o bazę danych Zapraszam także do śledzenia profili Jacka na Twitter/X oraz LinkedIn oraz do zapoznania się z listą szkoleń Jacka w Bottega IT Minds.

W informatyce są tylko dwie trudne rzeczy: unieważnianie pamięci podręcznej i nazywanie rzeczy... A jeśli mówimy co systemach rozproszonych, to do tej krótkiej listy Phila Karltona należy dopisać jeszcze skuteczną komunikację sieciową. Projektując systemy często zapominamy o tym, jak zawodny może być to komponent. A złośliwie zawiedzie pewnie w bardzo ważnym momencie... Na szczęście możemy temu zapobiec korzystając z wzorca Transactional Outbox.

Do rozmów w podkaście zapraszam osoby, które nie raz czy dwa zderzyły się z danym problemem w życiu i posiadają konkretne doświadczenie. Nie inaczej jest tym razem, a moim gościem jest dziś Jacek Milewski, który na co dzień pracuje jako modelarz i architekt oprogramowania.

W tym odcinku wraz z Jackiem rozmawiamy między innymi o:

  • problemach związanych z komunikacją w systemach,
  • idei wzorca Transactional Outbox / Store&Forward,
  • możliwych sposobach obsługi outboxa w systemie,
  • zastosowaniu tego wzorca zarówno w systemach rozproszonych jak i monolitycznych,
  • kolejności przetwarzania wiadomości,
  • deduplikacji czy message-poisoning.

Materiały dodatkowe:

Zapraszam także do śledzenia profili Jacka na Twitter/X oraz LinkedIn oraz do zapoznania się z listą szkoleń Jacka w Bottega IT Minds.

77. O couplingu i decouplingu w systemie z Grzegorzem Piwowarkiem
2024-01-02 01:00:00

Gdy coś się dobrze zaczyna, często kończy się źle... A jednym z tego powodów w projekcie jest niekontrolowane wprowadzenie couplingu, czyli sprzęganie różnych jego elementów ze sobą. Różne komponenty nagle stają się od siebie zależne, logika biznesowa połączona z frameworkiem czy bazą danych, a w efekcie całość jest coraz trudniejsza do utrzymania i rozwoju. Zwiększając sprzężenie zmniejszamy kohezję rozwiązania, a w myśl zasad GRASP Low Coupling i High Cohesion warto postępować dokładnie na odwrót. Na szczęście decoupling może zostać zrealizowany w projekcie na wiele różnych sposobów. A czasem wręcz świadomie pominięty, ponieważ nie przyniesie on oczekiwanych efektów. Dziś zapraszam na odcinek z Grzegorzem Piwowarkiem na tematy poświęcone couplingowi, decoplingowi i trzymania rzeczy w projekcie niektórych rzeczy (jak frameworki) na dystans, w którym rozmawiamy między innymi o: odcinaniu frameworka webowego czy ORM, efektach i zyskach płynących z decouplingu, przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność, architekturze heksagonalnej, historiach z życia... Materiały dodatkowe: Trzymaj Springa na dystans , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022 Recipes for Decoupling , książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP 4comprehension.com , strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javą pivovarit@x , profil Grzegorza na Twitter/X

Gdy coś się dobrze zaczyna, często kończy się źle... A jednym z tego powodów w projekcie jest niekontrolowane wprowadzenie couplingu, czyli sprzęganie różnych jego elementów ze sobą. Różne komponenty nagle stają się od siebie zależne, logika biznesowa połączona z frameworkiem czy bazą danych, a w efekcie całość jest coraz trudniejsza do utrzymania i rozwoju. Zwiększając sprzężenie zmniejszamy kohezję rozwiązania, a w myśl zasad GRASP Low Coupling i High Cohesion warto postępować dokładnie na odwrót.

Na szczęście decoupling może zostać zrealizowany w projekcie na wiele różnych sposobów. A czasem wręcz świadomie pominięty, ponieważ nie przyniesie on oczekiwanych efektów.

Dziś zapraszam na odcinek z Grzegorzem Piwowarkiem na tematy poświęcone couplingowi, decoplingowi i trzymania rzeczy w projekcie niektórych rzeczy (jak frameworki) na dystans, w którym rozmawiamy między innymi o:

  • odcinaniu frameworka webowego czy ORM,
  • efektach i zyskach płynących z decouplingu,
  • przydatnych heurystykach pomagających odpowiedzieć na pytanie, czy warto odcinać daną zależność,
  • architekturze heksagonalnej,
  • historiach z życia...

Materiały dodatkowe:

  • Trzymaj Springa na dystans , wspomniana w rozmowie prezentacja Grzegorza z konferencji Confitura 2022
  • Recipes for Decoupling, książka Matthiasa Nobacka opisująca implementację konceptów dla ekosystemu PHP
  • 4comprehension.com, strona Grzegorza, na której można zapoznać się zarówno z ofertą szkoleń programistycznych jak i wpisami związanymi z Javą
  • pivovarit@x, profil Grzegorza na Twitter/X

76. O 77 latach doświadczeń w branży IT z Wojtkiem Ptakiem i Jarkiem Pałką
2023-12-26 01:00:00

Mijający właśnie rok dla Better Software Design był szczególny i "naj" z wielu powodów - liczby nowych odcinków, odsłuchanych rozmów, nowych słuchaczy... Nie byłoby tego podcastu bez was, także w tym roku w formie podcastowego prezentu i podziękowania za wspólnie spędzony rok, zapraszam na odcinek specjalny. Wraz z Wojtkiem Ptakiem i Jarkiem Pałką, znanych doskonale z kilku poprzednich odcinków podcastu, rozmawiamy o karierze w IT z perspektywy naszych wspólnych... ponad 77 lat spędzonych w branży IT. W tym odcinku zaczynamy od łączenia kropek, które każdy z nas postawił na swojej developerskiej (i nie tylko) drodze... Jedną z takich moich kropek (choć niestety nie wspomnianą podczas rozmowy) było dołączenie do niektórych prac kierowanego przez Wojtka zespołu. Gdy na 2 godziny przed rozpoczęciem właściwej pracy analizuje się wspólnie wykorzystywane w projekcie techniki, wypracowuje na ich podstawie własne podejście do software developmentu, którym można się dzielić z innymi - czego chcieć więcej? Zapraszam!

Mijający właśnie rok dla Better Software Design był szczególny i "naj" z wielu powodów - liczby nowych odcinków, odsłuchanych rozmów, nowych słuchaczy... Nie byłoby tego podcastu bez was, także w tym roku w formie podcastowego prezentu i podziękowania za wspólnie spędzony rok, zapraszam na odcinek specjalny.

Wraz z Wojtkiem Ptakiem i Jarkiem Pałką, znanych doskonale z kilku poprzednich odcinków podcastu, rozmawiamy o karierze w IT z perspektywy naszych wspólnych... ponad 77 lat spędzonych w branży IT. W tym odcinku zaczynamy od łączenia kropek, które każdy z nas postawił na swojej developerskiej (i nie tylko) drodze...

Jedną z takich moich kropek (choć niestety nie wspomnianą podczas rozmowy) było dołączenie do niektórych prac kierowanego przez Wojtka zespołu. Gdy na 2 godziny przed rozpoczęciem właściwej pracy analizuje się wspólnie wykorzystywane w projekcie techniki, wypracowuje na ich podstawie własne podejście do software developmentu, którym można się dzielić z innymi - czego chcieć więcej?

Zapraszam!

75. O User Story Mapping i analizie warsztatowej z Michałem Bartyzelem
2023-12-19 01:00:00

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping. W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami. W tym odcinku rozmawiamy z Michałem między innymi o: bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie", odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu, sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu, wykorzystaniu USM w projekcie, różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem, sposobach prowadzenia warsztatu analitycznego. Materiały dodatkowe: It's All in How You Slice , artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story Mappingu The New User Story Backlog is a Map , drugi po artykule istotny wpis Pattona na temat problemów z historyjkami User Story Mapping: Discover the Whole Story, Build the Right Product , książka Jeffa z 2012 roku, przedstawiająca technikę User Story Mappingu Story Map Concepts oraz Agile Story Essentials , krótkie i rzeczowe podsumowania pokazujące zasadę działania USM Polecam także zajrzeć na stronę Michała , a w szczególności na prowadzonego przez niego bloga . Zapraszam!

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.

W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami.

W tym odcinku rozmawiamy z Michałem między innymi o:

  • bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",
  • odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,
  • sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,
  • wykorzystaniu USM w projekcie,
  • różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,
  • sposobach prowadzenia warsztatu analitycznego.

Materiały dodatkowe:

Polecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.

Zapraszam!

74. O syndromie wypalenia zawodowego z Olą Kunysz
2023-12-05 01:00:00

Stres w pracy nie jest rzadkim zjawiskiem. Pozostawiony sam sobie przez dłuższy czas, może zacząć wyrządzać nam więcej szkód, w tym doprowadzić do syndromu wypalenia zawodowego. O tym jak może się objawiać wypalenie w naszym codziennym życiu, jak można sobie z nim radzić i jak reagować, gdy problem zaczyna dotykać osoby w naszym otoczeniu - o tym wszystkim rozmawiamy dziś z Olą Kunysz. Bez technologii i architektury, ale o własnych doświadczeniach z wypaleniem w kontekście branży IT. Materiały dodatkowe: The Burnout Index , darmowy test Yerbo wspomagający określenie poziomu ryzyka zagrożenia wypaleniem, Test BAT12 , prostszy test w języku polskim, Nie wypalaj się! Jak żonglerka może uratować pracowników IT? , prezentacja Oli na TedX Koszalin Ola@Instagram , profil Oli na Instagramie, gdzie dzieli się m.in. informacjami na tematy związane z wypaleniem zawodowym

Stres w pracy nie jest rzadkim zjawiskiem. Pozostawiony sam sobie przez dłuższy czas, może zacząć wyrządzać nam więcej szkód, w tym doprowadzić do syndromu wypalenia zawodowego.

O tym jak może się objawiać wypalenie w naszym codziennym życiu, jak można sobie z nim radzić i jak reagować, gdy problem zaczyna dotykać osoby w naszym otoczeniu - o tym wszystkim rozmawiamy dziś z Olą Kunysz. Bez technologii i architektury, ale o własnych doświadczeniach z wypaleniem w kontekście branży IT.

Materiały dodatkowe:

Informacja dotycząca prawa autorskich: Wszelka prezentowana tu zawartość podkastu jest własnością jego autora

Wyszukiwanie

Kategorie