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.