Agile jest super. Jak programować to tylko w adżajlu. Praca w inny sposób jest passe. W ciągu swojej kariery zawodowej miałem możliwość rozmawiać z wieloma programistami. Szczególnie obecnie większość osób chce pracować w scrumie. Firmy się ogłaszają, że mają scrum. To przyciąga programistów jednak nie wiele osób zastanawia się czym jest to zwinne podejście do programowana.

 

Aby być bardziej atrakcyjnym na rynku pracy, firmy organizują szkolenia ze scruma. Sam w takich uczestniczyłem. Po dwóch dniach szkolenia ludzie zostawali Scrum Masterami lub Product Ownerami. Większość uczestników stanowiły osoby które wcześniej były Project Managerami. Zmieniała się etykieta, niekoniecznie sposób pracy.

 

Manifest Agile został podpisany w 2001. Jego sygnatariusze pracowali w różnych metodologiach zwinnych.  W ciągu 3 dniowego spotkania doszli do konsensusu w 4 kwestiach.

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

http://agilemanifesto.org

 

Podczas gdy tematy to prawej stronie są dalej ważne, większą wartość dla osób podpisujących manifest miały te po lewej stronie.

 

Obserwując sytuację obecnie odnoszę wrażenie, że nie wiele osób mówiących, że dostarcza oprogramowanie w sposób zwinny, ma w ogóle świadomość powyższego manifestu.

 

Wiele osób dostarcza produkt po staremu, tylko firmy nazywają się agile, bo zainwestowały w szkolenia.

 

Scrum jest najpopularniejszym podejściem obecnie. Mam okazje rozmawiać z wieloma programistami, którzy pracują w ten sposób. Jako, że osobiście jestem bardzo zainteresowany ciągłym udoskonalaniem, często się pytam jakie zaproponowali ostatnio usprawnienia w procesie. Pytam o to, gdyż bardzo lubię się uczyć na błędach innych. Niestety ale nie wiele osób jest mi w stanie odpowiedzieć sensownie na moje pytanie. Coś jest więc nie tak, gdyż retrospekcja, która jest jednym z filarów prowadzenia projektów w ten sposób, powinna właśnie prowadzić do ciągłego samo udoskonalania.

 

Praca w ten sam sposób, bez wprowadzania udoskonaleń jest w sprzeczności z ideą zwinnego prowadzenia projektów.

 

Nie znając dokładnie zespołów w jakich osoby te pracują ciężko mi oceniać co tam jest nie tak. Jednakże bardzo często odnoszę wrażenie, że stoi to w sprzeczności do pierwszego punku manifestu. Zespół powinien pracować na poziomie ludzkim. Nie powinno mieć to znaczenia jakich używa procesów i narzędzi. Umiejętność przekazywania konstruktywnej krytyki, która prowadzi do udoskonalania procesów jest podstawą by można mówić o tym, że bardziej cenieni są ludzie i interakcje, ponad narzędziami i procesami.

 

Z uwagi na fakt, że większość firm nie jest zbyt dobra w budowaniu zaufania pomiędzy pracownikami na różnych stopniach w hierarchii, scrum ma specyficzną rolę Scrum Mastera. To ta osoba powinna stymulować zespół do otwartej współpracy. Wydanie certyfikatu kosztuje dwa dni i trochę pieniędzy. Tylko czy firma go wydająca robi to po to by zespoły lepiej pracowały czy po to by zrealizować swoje cele biznesowe? To już biznes czy krzewienie idei?

 

Nie jest tak, że wszyscy Scrum Masterzy są źli i w zespołach nie ma dyskusji opartej na zaufaniu. Takie osoby też poznałem, jednakże są one w mniejszości.

 

W zespole, w którym jest zaufanie i dobre relacje między ludzkie rolę tą mógłby pełnić każdy naprzemiennie. Nawet Team Leader lub Manager. Pomimo tego, że każdy w scrumie jest równy to nie przeszkadza to firmom tworzenia hierarchii.

 

Manifest, który został stworzony w 2001 roku nie mówi bezpośrednio nic o jakości oprogramowania. Temat ten pojawia się jednakże poszczególnych podejściach. Jednakże manifest mówi o tym by być w stanie szybko reagować na zmiany. Aby to było możliwe oprogramowanie musi być napisane w taki sposób by zmiany w specyfikacji można było wprowadzić bez konieczności przepisywania wszystkiego.

 

Zmiany w wymaganiach są tym co może decydować o przewadze jednego produktu nad innym.

 

A late change in requirements is a competitive advantage

Mary Poppendieck

 

Czy osoba, która pilnuje tylko tego by terminy były spełnione będzie weryfikować czy kod napisany jest dobrze i w taki sposób by dało się go łatwo rozszerzać? Jest to możliwe, ale nie jest to powszechne. Jest to o tyle trudne w przypadku gdy Scrum Master nie ma wiedzy technicznej, a zespołowi brakuje doświadczenia.

 

Problem, który obserwuje z programistami, którzy chcą tylko podążać za dobrymi praktykami oprogramowania jest taki, że osoby te bardzo często mają tendencje to przekomplikowania. Podczas gdy jakość jest potrzebna aby móc szybko odpowiedzieć na zmieniające się wymagania tendencja do pisania na wyrost niestety jest bardzo duża. Co ciekawe doświadczeni programiści wiedzą co to jest YAGNI, natomiast nie zawsze widać to w kodzie jaki jest tworzony.

 

Często brakuje pragmatycznego podejścia. Zarówno ze strony programistów jak i ludzi wyszkolonych w ciągu dwóch dni. Czy ty w swojej pracy, gdzie wykorzystujesz podejście zwinne do programowania zwracasz uwagę na manifest podpisany w 2001 roku? Czy po prostu podążasz za tym co było na szkoleniu i bardziej skupiasz się na procesie niż na współpracy?

 

Osobiście jestem gorącym zwolennikiem zwinnego podejścia do programowania. Wiem, że są miejsca gdzie działa to bardzo dobrze, jednakze wiem też z doświadczenia i rozmów z innymi, że często nie jest to tak kolorowa jak się o tym mówi publicznie.

 

Ciągłe udoskonalanie się jest jednym z przewodnich motywów ruchu Software Crafstsmanship. Nie każdy może to lubić. Jedni podchodzą do pracy programisty w kategoriach odbicia swoich 8 godzin a nieważne jakim stylu. Inni zaś tego stylu szukają a raczej ciągle go udoskonalają.

 

Podobnie jest w innych dziedzinach gdzie ciągłe udoskonalania warsztatu sprawia, że satysfakcje z wykonywanego zajęcia jest większa. Może to być granie na instrumentach muzycznych, sport czy tak przyziemne rzeczy jak programowanie. Osobiście nie uważam się za super najlepszego w świecie programistę, jednakże z dnia na dzień staram się udoskonalać swój warsztat.

 

Jednym ze sposobów udoskonalania umiejętności w programowaniu jest rozwiązywania zadań algorytmicznych. Tylko, żeby były one efektywne to powinny się zmieniać. Nie ma sensu pisanie codziennie tej samej pętli for, czy rozwiązywanie jednego algorytmu na tysiąc różnych sposobów.

 

Fakt, że większość osób pracujących na co dzień z komputerem, pisze regularnie maile nie sprawi od razu, że każdy stanie się poczytnym autorem książek. Aby to osiągnąć to musi się zmieniać otoczenie, muszą zmieniać się zewnętrzne bodźce, które sprawią, że posiadane umiejetności wejdą na kolejny poziom.

 

Dla mnie jednym ze sposobów podnoszenia swoich umiejętności jest rozwiązywanie zadań algorytmicznych. Poza tym, że utrwalam dzięki temu możliwości języka w jakim programuje, to także mogę praktykować podejście Test Driven Development. TDD nie jest czymś co na co dzień każdy wykorzystuje w swojej pracy programistycznej. Nie zawsze pisanie testów w pierwszej kolejności jest efektywne. Czasami lepiej najpierw zaimplementować metodę, a później napisać do niej odpowiednią ilość testów jakie są konieczne do tego aby uzyskać jak największe pokrycie. Zarówno od strony linii kodu jak i przypadków testowych.

 

Rozwiązywanie, krótkich zadać algorytmicznych, gdzie np. zadeklarowana jest z góry sygnatura metody umożliwia napisania najpierw odpowiedniej ilości przypadków testowych a później ich implementację. Jest to bardzo ciekawa cecha tego typu zadań.

 

W sytuacji, gdy zadanie do rozwiązania ma już zdefiniowane przypadki testowe można też się nauczyć lepiej testować swój kod. Pokrycie kodu w 100% nie oznacza, że został on pokryty w 100%. To, że coś działa na jednym przypadku testowym, nie oznacza, że będzie działać na innych danych.

 

Zachęcam do poświęcenia w tygodniu godziny na napisanie kodu, który będzie rozwiązaniem na proste zadanie algorytmiczne. Nie ma potrzeby wymyślania zadań dla siebie. Takowe dostępne są na wyciągnięcie ręki. Poniżej kilka linków, gdzie można znaleźć zadania programistyczne w różnych językach.

 

www.codewars.com

www.codekata.com

www.codingdojo.org

www.hackerrank.com

 

Rozwiązywanie kata, to nie jest jedyny i najlepszy sposób aby stać się lepszym w tym co się robi. Jest to tylko jedna z dróg do celu.