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.

Komunikacja w pracy zespołowej jest kluczem do osiągania lepszych rezultatów. O ile się nie robi prywatnego projektu, to najczęściej programuje się w ramach zespołu. Mniejszego lub większego ale jest to zespół. Bez dobrej komunikacji pojawiają się problemy.

 

Abstrahując już od narastającej frustracji, niskiego morale czy braku pracy zespołowej, które to mogą pojawić się niezależnie od wykonywanego zajęcia, w przypadku programistów inne mogą być konsekwencje niewłaściwej komunikacji.

 

Obserwując ludzi przez kilka lat swojej pracy z zespołami zauważyłem, że wcale to nie te najczęściej wymieniane skutki braku komunikacji były widoczne. Wielu programistów to introwertycy i nie mają potrzeby się uzewnętrzniać. Dostają zadania i je realizują w swoim tempie. Nie zwracając w tym czasie na innych.

 

Poniżej 3 typowe problemy jakie wielokrotnie obserwowałem.

 

Przeciągające się zadania

Przez kilka lat pracowałem w środowisku gdzie utrzymanie istniejącego systemu zajmowało dużą ilość czasu pracy. Poprzez utrzymanie systemu mam na myśli naprawianie błędów zgłaszanych przez klientów. Nie jest to wymarzona praca większości programistów, w związku z czym obserwowałem dużą rotację w zespołach. Duża rotacja to wiele osób do podpatrzenia. Praca na dużym, skomplikowanym systemie wymaga dobrej komunikacji. Zawsze jest ktoś, kto ma większą wiedzę i jest w stanie coś podpowiedzieć, Nakierować na źródło problemu. Wielokrotnie widziałem jak programiści nie chcieli lub też obawiali się spytać o pomoc. Starali się rozwiązać problem samodzielnie. Różnie się to kończyło. Czasami problem rozwiązali dobrze z czasami nie. Minęło kilka dni a oni dalej się męczyli przechodząc przez kolejne moduły systemu. Wszystko trwało dłużej niż powinno w związku z czym nie było czasu na strategiczne zmiany. Po prostu inni czekali w kolejce aby ich problemy rozwiązać. A problem był łatwy do rozwiązania gdyby tej komunikacji pomiędzy poszczególnymi członkami zespołu było więcej.

 

Nieoczekiwane zachowanie aplikacji

Jak się nie wie co się robi, Prowadzi archeologię w kodzie programu to łatwo o wprowadzenie zmiany albo nie tam gdzie ona ma być wprowadzona lub też popsucie systemu w celu doraźnego rozwiązania problemu. Zakomentowanie kodu, tylko dlatego, że pojawił się błąd NullReferenceException nie należy do rzadkości. W końcu jak się zakomentuje miejsce gdzie występuje błąd to aplikacja nie będzie denerwowała już użytkowników komunikatami o błędach. Na początku swojej kariery w programowaniu byłem świadkiem jak osoba za takie podejście musiała odejść z pracy. Postępowanie takie jest związane z tym, że nie ma się odpowiedniej wiedzy na temat systemu. Rozwiązać to można na dwa sposoby. Albo analizować dalej kod albo spytać się kogoś kto wie jak to powinno działać o pomoc.

 

Duplikacja rozwiązań tego samego problemu

W przypadku większych systemów, nad którymi pracuje wielu programistów, do rzadkości nie należy implementacja podobnych rozwiązań w wielu miejscach. Np. może być to pakowanie i rozpakowanie plików zip. Dając ten sam problem do rozwiązania 10 programistom, każdy to zrobi w inny sposób. Każdy to zrobi po swojemu. Wymyśli koło na nowo. Nie ma ku temu jednakże potrzeby. Jedno rozwiązania może zadowolić wiele osób. Tylko ku temu potrzebna jest komunikacja. Po pierwsze zakomunikowanie innym, że się rozwiązało taki problem a po drugie zapytanie innych czy przypadkiem nie rozwiązali już takiego problemu. Programistom łatwiej przychodzi zadanie pytania na StackOverflow niż zapytanie osoby z innego zespołu pracującego nad tym samym projektem. Nie wykluczone, że ten pierwszy programista, który miał taki problem do rozwiązania też zadał pytanie na StackOverflow. Wtedy dochodzimy do sytuacji o której pisałem tutaj.

 

A ty z jakimi problemami się spotkałem, które wynikały z braku komunikacji?