Razzmatazz Posted March 31, 2017 Posted March 31, 2017 Što? Beš me zanima tvoj uvid, ozbiljno... Elem, meni su problem kolege. Prvo, bolje je imati nekakvu metodologiju, nego ne imati nikakvu i raditi stvari stihijski. Ako si dobar u tome šta radiš, taj stihijski način rada će te pre ili kasnije zakopati, jer će se stvari komplikovati, nagomilati itd. Ako si loš u tome šta radiš, onda nema metode koja će ti pomoći, dok ne resetuješ neke druge stvari. Drugo, ne pasuje svaka metoda svakom timu ili svakom projektu. Taj scrum isto ne može biti odgovor na sva pitanja. I treće, bilo koja od tih metoda nije i ne može biti religija. Ako imaš takvog zealota u firmi ili timu, izbaci ga kroz prozor što pre. Uzmi metodologiju koja generalno najviše odgovara tipu projekta i timu i iskroji ga po meri. Izbaci višak, pogotovo prekomerno sastančenje. Ako ima rupa ubaci deo iz neke druge metodologije ili smisli sam nešto. Te mešavine poput scrumbana su toliko već dugo u upotrebi, da i same postaju standardne. Kao što je neko ovde već pomenuo - ako imaš neki projekat koji se razvija duže vremena, razvoj između major verzija hendluješ klasičnim metodama, a put kroz minor verzije možeš da voziš kao continous delivery koristeći metode na bazi scruma, kanbana ili neke svoje metode. U svakom slučaju, metoda je alat koji ti omogućava da lakše dođeš do cilja, a ne nešto što uzmeš kao okvir i onda pokušavaš nekako da se uguziš u sve to po svaku cenu. Ako te sputava i ima više štete nego koristi - prekidaj i pokušaj da nađeš gde je problem. Ne moraš ni jedan trend, bio on tehnološki ili organizacioni, da primeniš ako nemaš ništa od toga. Ne moraš da radiš TDD, ali je dobro da radiš testove i da imaju solidni coverage (ne, ne mora biti 100%). Ne moraš da koristiš pair progamming, to je rasipanje resursa, ali za posebno zajebane bugfixeve ili neke kritične komplikovane tačke nije loše uraditi to u paru. Za ovih 20-tak godina sam se nagledao svačega, od malih dinamičnih timova i startapova do tvrdih korporacija i nasilnih preuzimanja. Čak i takve idiotske odluke da se ista tema da dva različita tima "zbog interne konkurencije, to je zdravo", pa ko izađe sa boljim rešenjem dobija bonus. Rezultat je, naravno, bila klanica. Sve se svodi na ljude sa kojima radiš. Ako je neko drkadžija, možeš se slikati sa teorijom koliko hoćeš. Sećam se jednom prilikom ("during the war") da je na pomen code reviewa kao pojačavanja QA metode jedan majstor odbrusio "neš mi ti gledati kod, šta si mi ti, profesor?". Prva stvar koja ljudima teško padne oko scruma je u tome što to dožive kao vrstu kontrole. Kao, zamisli, treba da kažu šta su uradili. Jebiga, sutra moram svejedno tvoju komponentu da ugradim u moj deo, neću kao videti da nije gotovo? Ljudi treba da se otresu tog pritiska i da prihvate da je sasvim okej da kažu "nema ništa novo kod mene, radio sam od juče dokumentaciju, nisam gotov s time". Cilj tih dnevnih petominutnih okupljanja je prosto razmena informacija među ljudima koji na najblažoj relaciji rade zajedno i rano lociranje problema. Ne traži niko da se svaki dan pičuje kako si napravio novi google search engine od juče. Znamo svi da ima u timu ljudi koji rade brže, ima onih koji rade sporije i sve je to okej. Uzmi kod procene zadatka dan i po umesto dan, ali uzmi realno vreme koje _tebi_ treba. Nisu ni sve kolege u timu rock star developeri, nisu to sad novosti koje ćemo saznati tek uvođenjem scruma ili neke druge metode. Znamo da si juče vodio dete kod lekara i da nisi završio. Ako preko te osnove tim ne može da pređe i složi se oko toga, onda bato scrum nije vaš problem i nije za vas. Ima ljudi koji se zakopaju u govna i ćute. Ima ljudi koji se prodaju za više para nego što vrede. Ima i onih koji prosto kasne. Ali kako god da okreneš, na kraju dana (sprinta, meseca, čega god) imaš backlog i proizvod, svojih ruku delo - videće se ovako ili onako šta smo uradili. To je ono "unutar tima". Drugi problem sa ljudima je van tima, ka pretpostavljenima. Tamo gde sam video da je tako neki iskrojeni metod funkcionisao kako treba, pretpostavljeni nisu koristili te statistike za neke metrike na kojima bi bazirali pare i slično. Kinta je ionako u poslednje vreme definisana kao all-inclusive package i ako ima bonusa, on je definisan za ceo tim, ne za pojedince. Ostavili su razumno timovima da formiraju svoje verzije, da nađu neki balans između unutrašnjeg nagona ka odgovornosti i zadovoljstva samih ljudi. To je zanimljiva situacija - kad ostaviš ljudima da sami odluče o tako nekim detaljima, ne mogu da prenebregnu obaveze i svedu ih na minimum, a kad krene stvar da se kotrlja, svi su svesni da to nije nametnuto negde odozgo, nego smo sami to tako definisali. Sveli retro i review na minimum, refinement samo sa ljudima koji učestvuju u konkretnim taskovima, čak i uklonili i scrum mastera. Tj. PO/PM prisustvuje redovno dejli viđanjima, ako treba nešto na globalnijem nivou da se izvesti pretpostavljenima to radi ta osoba. Na stendapu se time ne izveštava nikome konkretno, nego grupi i grupa se komunistički samoreguliše da ne krene diskusija. To je tako sa određenim izmenama stvarno funkcionisalo u par firmi u kojima sam radio. Ja sam prvi kojim džigericu kljucaju pseudo metode motivacije, tim bilding i ostala sranja, ali svojim očima sam video kako tako manja grupa stvarno ponese ljude koji su bili slabiji i kako se sa vremenom poboljšaju u svakom pogledu.
Fins fleet Posted March 31, 2017 Posted March 31, 2017 Bravo. Sto je lepo kada pismena osoba kaze ono sto ti hoces, a numes.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now