Przez kilkanaście lat pracy zawodowej wielokrotnie padłem ofiarą mitów i przejściowych trendów przemysłu IT. Bałem się wysłać CV na widok ściany wymagań. Wprowadzałem Scruma "na siłę", przepisywałem systemy od zera, budowałem wymyślną architekturę. Umknęło mi wiele ważnych rzeczy, na które dziś pragnę zwrócić Waszą uwagę. Opowiem jak możecie ruszyć swoją karierę "z kopyta" poprzez skupienie się na 20% rzeczy, które dadzą 80% rezultatów. Pokażę, jakie praktyki realnie pozwoliły mi osiągać duże sukcesy u klientów z całego świata.
3. Agenda
01 Zły biznes, dobry development
02 Musimy mieć Scruma!
03 Spotkania to strata czasu
04 Pseudoelitarność
05 Wymyślna architektura
06 Wielkie przepisywanie
07 100% code coverage
4. Skup się na tym, co daje
największe korzyści!
Zasada Pareto:
20% czynności daje 80% rezultatów
6. Co myśli development:
biznes nie wie, czego chce 🤦
biznes ciągle zmienia priorytety
biznes nas nie rozumie
Co często myśli biznes:
ile to wszystko kosztuje!
za rok odejdą i zostawią nas z tym
nie rozumiemy, co oni gadają
po co ten kolejny "refaktor"?
10. Jak pogodzić tech i non-tech LUDZI
w firmie
development częścią biznesu
wymiana informacji (priorytety, release plan)
wspólne warsztaty
usprawnienie developmentu
dobry Product Owner
11. Krótki dokument o każdym zespole
Cześć! Jesteśmy zespołem XYZ i odpowiadamy za...
Pracujemy w cyklach 2-tygodniowych, zaczynamy planningiem w
poniedziałki.
Opisując zadania, użyj szablonu: ...
16. 5 dysfunkcji pracy zespołowej
Patrick Lencioni, "The Five Dysfunctions of a Team"
17. Empiryzm w Scrumie
Transparencja ➡️inspekcja ➡️adaptacja
CEREMONIE SCRUMOWE REALIZUJĄ TEN CYKL!
Planning ➡️daily ➡️review ➡️retro
18. Kiedy estymować zadania?
Estimation is valuable when it helps you make a significant
decision.
So whenever you're thinking of asking for an estimate, you
should always clarify what decision that estimate is informing.
martinfowler.com/bliki/PurposeOfEstimation.html
21. Development to praca zespołowa
Musicie pracować razem,
ale też szanować nawzajem swój czas!
22. Sposoby na lepsze spotkania
agenda przed spotkaniem
czy wszyscy są potrzebni?
prawo dwóch nóg
moderacja, zmierzanie do celu
timeboxing
skupienie (np. wyłączamy Slacka)
notatki, action points
narzędzia (Google Docs, Miro, Notion itp.)
24. Przeciętne ogłoszenie o pracę
Słynne "wiek 20 lat, 10 lat doświadczenia"
Dużo modnych słów kluczowych ✅
"Młody, dynamiczny zespół"
Rezultat: impostor syndrome
25. Jako kandydat
Nie musisz znać wszystkich fancy technologii...
...ale kształć się i rozwijaj, znajdź swoje mocne strony! 💪
Jako rekruter
Nie oczekuj od ludzi, że będą znali wszystkie fancy technologie
27. Co to daje, gdy szukamy pracy?
Większy wybór ofert
Nowe możliwości
Praca z lepszymi od siebie
28. Co to daje firmie?
Większy wybór kandydatów
Mocne, wszechstronne zespoły
Wiele punktów widzenia
Lepsze oprogramowanie
Szybszy onboarding
Niższe koszty
32. Problemy 😭
trudne utrzymanie
wysokie koszty 💸
brak specjalistów
porzucone frameworki
joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you
33. Nie od razu wielkie systemy
zbudowano
John Gall
Will Larson
A complex system that works is invariably found to have evolved from a simple
system that worked.
Most implemented systems are designed to support one to two orders
magnitude of growth from current load.
35. Historie nieudanego rewrite'u
Martin Fowler, "Refactoring"
“The old code had worked just fine. Yes,
the design was a bit more "pure", and a bit
more "clean." But the project had to ship
code that worked, not code that would
please an academic. (…) Six months later,
the project failed.”
36. Strategie pracy z kodem legacy
Testy automatyczne
Refaktoring małymi krokami ♻️
Proof of Concept
Event Storming
Fasada
Strangler Pattern
Anti-Corruption Layer
39. Co nam to daje
spełnienie deadline'ów
ochrona istniejącego zachowania systemu
efekty małych kroków są szybciej widoczne
uniknięcie wypalenia
więcej czasu na wartościowe rzeczy
40. Kiedy przepisanie systemu jest
konieczne?
śmierć technologii (np. Adobe Flash)
nowy system daje kluczowe możliwości, których stary system
nie może dać
45. Jakość testów
Line coverage: 100% 🎉
Branch coverage: 50% 😔
public function foo(bool $flag): void
{
if ($flag) {
doThis();
}
doOtherThing();
}
public function testFoo(): void
{
foo(true);
}
46. Strategia testowania
unit testy są najszybsze; E2E wolniejsze i mniej stabilne
jeśli nie mamy żadnych testów, to najlepiej zacząć od E2E happy path
nie trzeba testować jednostkowo kontrolerów
domena biznesowa powinna mieć najlepsze możliwe testy
48. Podsumowanie
Wymieniaj informacje z biznesem; buduj przewidywalność
Buduj dobre relacje w zespole
Dbaj o jakość spotkań
Twórz zróżnicowane zespoły / nie bój się rekrutacji :)
Projektuj rozsądną architekturę
Refaktoryzuj małymi krokami, jeśli to możliwe
Wprowadź jasną strategię testowania