Tohle zna vetsina vyvojaru pracujicich na komplexnich backendovych slozitych komponentach.
Alokuji vas na projekt, kde mate za ukol spravu a vyvoj slozite komponenty, kterou uplne neznate a nikdy vlastne uplne detailne znat nebudete.
Dostanete od analytika za ukol implementaci netrivialni funkcionality, ktera neni zadana uplne 100% - nejsou v ni jeste rozresene uplne vsechny detaily, cast vykrystalizuje az v prubehu samotne implememntace.
Komponenta samotna je slozita a castecne je to legacy, vy se v ni tak dobr neorientujete, a ukol, ktery mate zadany, bude zasahovat do mnoha jejich ruznych casti, ktere uplne nevite, jak vlastne funguji.
To znamena, ze je to celkove slozita prace, ktera skrz na skrz obsahuje mnoho navzajem souvisejicich neznamych.
Moje otazka je, jak k tomu vlastne pristupovat. Je to tak standardni situace, ze jsem si rikal, ze by k tomu mohla byt formalizovana nejaka metodologie prace.
Ja se snazim delat tohle, ale myslim, ze to neni uplne optimalni:
1. Udelam si zakladni analyzu kodu, co kde a jak budu implementovat a jak to funguje doposud. Tahle cast je dost time-consuming a spatne se trackuje jeji progres, protoze zavery z ni dokazi byt vysoce promenlive s tim, jak clovek jde hloubeji do kodu. V podstate nema pevne hranice toho, kdy je vlastne skoncena, protoze komponenta muze byt slozita, ze by mohlo trvat tydny dostat z toho nejaky definitivni zaver. Takze tady se nesmi stravit mnoho casu.
2. Ta nova funkcionalita zpravidla reaguje na nejaky vstup a ma mit nejaky vystup. Proto nejprve se zkusim zamerit na napsani testu - TDD, coz jsou moje prvni krucky ke konkretni implementaci, pomuze mi to problem uchopit za nejaku konkretni konec a zacit neco konecne delat. Udelam tedy par novych testu, ktere budou do dilcich casti komponent strkat nova vstupni data.
3. V prubehu celeho tohoto procesu postupne vykrystalizuji dilci ukoly, ze kterych se bude implementace skladat. Tyto ukoly si sepisu do seznamu.
4. Jak prace zacne narustat a komplikuje se, musim si vezt nejaky dokument, kde si eviduju poznamky ke kodu a ruzna zjisteni a TODO, protoze jinak bych se v tom vsem proste za par dni ztratil.
Ted v tomto celem procesu klasicky existuji prvky, ktere znemoznuji nejake normalni postupny progress. Zpravidla ruzne male blockery, vetsinou zpusobene tim, ze se na neco potrebuju nekoho zeptat a ten nekdo nevi, popr. jeste nevi, nebo nema cas. Kvuli toho nejen ze musim resit slozity ukol, ale jeste musim ruzne klickovat mezi pod-ukoly a pracovat se spoustou neznamych tak, aby prace nestala.
Nakonec je z toho zamotane klubko vseho mozneho a me v tom chybi nejaka poradne formalizovana metodologie prace, ktera by pomohla nejen to klubko nejak standardne rozmotavat, ale jeste navic i praci dobre trackovat, napr. do JIRA, aby sel nejakym zpusobem videt den za dnem progres.
Ja nastesti mam praci takovou, ze na me nikdo nejak extra netlaci, a kdyz neco jeste neni, tak to proste neni, a nikdo me nebuzeruje. Ale jsou i prace, kde se progres musi spravne trackovat a jeste navic se musi odhadovat narocnost. A myslim si, ze to uz chce mit nejakou poradnou robustni metodologii.
Existuje neco takoveho?
Diky