Agilne organizacione dogme

[Zverilla]

Again, to sto niko ne gleda big picture nije do scruma i verovatno ne bi gledali i da ga nema, ovako im samo lakse.

 

scrum sebe predstavlja kao jedno opste resenje za sve i svja, pa i za taj big picture.

a vec u njihovom manifestu, oni ne umeju da objasne kako ga primeniti u slucaju koji je kompleksniji od "5 ljudi u jednom timu prave blog/app", vec u par recenica nemusto kazu da se radi scrum of scrums i to je to (bez detalja kako to zapravo sprovesti u praksi)

 

ima u njemu dobrih stvari, ali i previse besmislica i previse obecanja koja ne moze da ispuni

Edited March 27, 2017 by Zverilla

[Frank Pembleton]

Again, to sto niko ne gleda big picture nije do scruma i verovatno ne bi gledali i da ga nema, ovako im samo lakse.

 

Mislim, boze me sacuvaj da branim scrum, definitivno znam kako moze da se zloupotrebi. Imao sam slucaj da udjem u tim i pitaju me je l' zavrseno nesto, kazem jok. Onda par persona zestoko krene da se upire da dokaze da ipak jeste zavrseno i da se pusti pola proizvoda na produkciju iako nema apsolutno nikakvog benefita sa biznis (ili bilo koje druge) strane i ja ih gledam jesu li normalni, nije mi nista jasno. Tek par meseci kasnije saznam da je njima bonus vezan za procenat odradjenih poena u odnosu na planirane.

 

Al to opet nema veze sa metodologijom vec sa ljudima.

Ali čekaj ti bonusi i njihovo dodeljivanje su deo "sistema"?

Ne bi se ti ljudi gicali da neko nije napisao "koliko poena,toliko bonusa"?

[radisa]

Ali čekaj ti bonusi i njihovo dodeljivanje su deo "sistema"?

Ne bi se ti ljudi gicali da neko nije napisao "koliko poena,toliko bonusa"?

Tačno, time se ljudi teraju da budu agilniji™...

 

Mislim, to je odlično zamišljeno, kada su svi normalni, kada projekti nisu preveliki i kad nema potrebe za saradnjom više timova...

 

Recimo, kod mene bi moglo tačno d se primeni, jer ja radim sa najviše 2 ljudi u timu, stalno razgovarano sa klijentima, ali, prvi i poslednji  projekat koji smo tako radili, puštajući korisnika da vileni, po meni je bio totalni dizaster (ostali se ne bune, čak ni naručioc/korisnik, ali, ja jednostavno ne volim tako da radim),i to ne krivicom razvojnog tima (tj. mojom :))...

 

Naime, stalni razgovori sa klijentom su doveli do toga je klijent u nekih 30% projekta toliko proširio scope, da to nije bilo normalno, pa je taj deo postao dalko zahtevniji i veći od ostatka. Da je u početku sve predočeno, posao bi bio bar duplo skuplji, ali pošto se išlo u itracijama, doši smo do toga da se troši vreme, a ne možeš naplatiti, a želiš da ispoštuješ klijenta. Sa druge strane, ostalih 70% projekta, 10% su otkazali, za 10% su shvatili da im ne treba iako je urađeno, a ostatak odbijaju da prihvate da potpišu da je završeno, stalno dodajući po neku sitnicu™ koju bi želeli...

 

Jbg, ja sam za to da se napravi scope, dogovori šta se želi, može da se donekle menja, i ne previše i to je to (i što i inače radimo, ali ovde je bio veliki klijent, iz UAE, pa se titrala jajca)...

[Aion]

Agilne metode (posebno scrum) su na meti zestokih kritika u programerskom svetu. Ovaj clanak je, bar po recniku dosta odmeren i argumentovan

 

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

 

Ako vas zanima kako izgledaju neodmerene kritike potrazite sta o ovome misli Eric Meijer koji dosta poznato ime u programerskom svetu ( https://en.wikipedia.org/wiki/Erik_Meijer_(computer_scientist) ).

[Sammael]

Čisto da demistifikujemo još malo, evo šta je suština scrum sistema (onako ogoljeno):

 

1. Imamo samo tri uloge u timu:

 

- Product Owner (onaj ko određuje u kom smeru ide razvoj, zadužen je da napravi user story-e/taskove, i služi kao voice of customer)

- Scrum Master (onaj ko je zadužen da se scrum sprovodi i da rešava sve probleme unutar tima - od tehničkih, preko poslovnih do interpersonalnih)

- Članovi tima (oni koji preuzimaju na sebe obavezu da uspešno izvrše svaki sprint tj. kompletiraju neki posao u predefinisanom vremenskom periodu)

 

2. Sve što se radi mora biti definisano kao user story, odnosno mora imati opis procesa sa željenim ishodom koji bi trebalo da bude vidljiv korisniku. Svi user story-ji zajedno čine backlog posla. Svaki user story mora biti ocenjen od strane tima (standardno se koriste poeni koji odgovaraju Fibonačijevom nizu i koji predstavljaju apstraktnu kompleksnost posla; u praksi je često 1 poen = 1 dan ili nešto slično). 

 

3. Sve se izvodi u kratkim iteracijama koje se zovu sprintovi i traju od 5-20 dana (može i neki drugi broj, najčešće je 8-15). Poželjno je da zbog planiranja i praćenja svaki sprint traje jednako. Product owner prioritizuje backlog a tim uzima s vrha backloga onoliko zadataka koliko misle da mogu da ispune. 

 

4. Ima ceo niz sastanaka, ali najbitniji su: prioritizacija (gde se određuje šta ide u naredni sprint), grooming (gde se ocenjuju zadaci), daily (15 minuta svakog dana kad svako kaže šta je radio, šta će raditi i šta ima od problema), review (gde se prikazuje šta je napravljeno) i retrospektiva (gde se diskutuje o tome šta u sprintu nije valjalo).

 

5. Uspešnost sprinta se obično prati grafikonom koji se zove burndown chart. Chart predstavlja kombinaciju idealne linije (ide od ukupnog broja planiranih poena u sprintu do 0) i krive potrošenog vremena/spaljenih poena (prati realizaciju). Ako druga ne prati prvu, nešto ne valja i treba ponovo planirati.

Edited March 27, 2017 by Sammael

[Krošek]

ok. to je sekta.

[Budja]

Je l moze neko da kaze koje su organizacione forme superiorne za dati posao, posto se svi zalite?

To je kao kada se profani zale na indeksirane casopiste (klubastvo, short-termism, gaming the system).

Ili, kad se Srbi zale na demokratiju.

 

 

Mozda je sistem za dati posao sranje, ali nema boljeg?

[Sammael]

Je l moze neko da kaze koje su organizacione forme superiorne za dati posao, posto se svi zalite?

To je kao kada se profani zale na indeksirane casopiste (klubastvo, short-termism, gaming the system).

Ili, kad se Srbi zale na demokratiju.

 

 

Mozda je sistem za dati posao sranje, ali nema boljeg?

 

Kad iole imam opciju da sam odlučujem o tome (što nažalost više nije često), praktikujem kombinaciju waterfall-a i scrum-a: najpre se sagleda cela velika slika, podeli u logičke celine/faze i ugrubo odredi šta je minimalno neophodno da bi svaka celina mogla da se okonča. Potom se uradi projektovanje na nekom višem nivou i postave kontrolne tačke i uradi detaljnije projektovanje za prvu fazu. Kreće se sa izradom prve faze kroz iteracije (sprintove), a istovremeno se radi detaljno projektovanje za drugu fazu. Ako usput dođe do značajnih poremećaja, preplaniraju se sve faze s tim što se gleda da se ispoštuje krajnji rok tako što se seku manje bitne stvari iz projekta. 

[Krošek]

Scrum Master

scrum

sprint

voice of customer

backlog 

grooming

daily

burndown chart

Product Owner

ABLE

action phrases

affinity

affinity-reality-communication (ARC) triangle

auditing

Case Supervisor

Claims Verification Board

E-Meter

Dianetics

Thetan

...

[3opge]

Čisto da demistifikujemo još malo, evo šta je suština scrum sistema (onako ogoljeno):

 

1. Imamo samo tri uloge u timu:

 

- Product Owner (onaj ko određuje u kom smeru ide razvoj, zadužen je da napravi user story-e/taskove, i služi kao voice of customer)

- Scrum Master (onaj ko je zadužen da se scrum sprovodi i da rešava sve probleme unutar tima - od tehničkih, preko poslovnih do interpersonalnih)

- Članovi tima (oni koji preuzimaju na sebe obavezu da uspešno izvrše svaki sprint tj. kompletiraju neki posao u predefinisanom vremenskom periodu)

 

2. Sve što se radi mora biti definisano kao user story, odnosno mora imati opis procesa sa željenim ishodom koji bi trebalo da bude vidljiv korisniku. Svi user story-ji zajedno čine backlog posla. Svaki user story mora biti ocenjen od strane tima (standardno se koriste poeni koji odgovaraju Fibonačijevom nizu i koji predstavljaju apstraktnu kompleksnost posla; u praksi je često 1 poen = 1 dan ili nešto slično). 

 

3. Sve se izvodi u kratkim iteracijama koje se zovu sprintovi i traju od 5-20 dana (može i neki drugi broj, najčešće je 8-15). Poželjno je da zbog planiranja i praćenja svaki sprint traje jednako. Product owner prioritizuje backlog a tim uzima s vrha backloga onoliko zadataka koliko misle da mogu da ispune. 

 

4. Ima ceo niz sastanaka, ali najbitniji su: prioritizacija (gde se određuje šta ide u naredni sprint), grooming (gde se ocenjuju zadaci), daily (15 minuta svakog dana kad svako kaže šta je radio, šta će raditi i šta ima od problema), review (gde se prikazuje šta je napravljeno) i retrospektiva (gde se diskutuje o tome šta u sprintu nije valjalo).

 

5. Uspešnost sprinta se obično prati grafikonom koji se zove burndown chart. Chart predstavlja kombinaciju idealne linije (ide od ukupnog broja planiranih poena u sprintu do 0) i krive potrošenog vremena/spaljenih poena (prati realizaciju). Ako druga ne prati prvu, nešto ne valja i treba ponovo planirati.

 

u stvari, od svega mi je islo najvise na kurac to procenjivanje kompleksnosti posla Fibonacijevim brojevima.

ceo taj agile treba sasvim sigurno ukinuti i proterati scrum mastere u Sibir.

[Sammael]

Jbg, uvek neko mora da uradi procenu jer se na bazi te procene pravi budžet projekta i komunicira s klijentima. U klasičnom waterfall-u to rade PMovi i arhitekte i ostatak tima se ništa ne pita (da li im je to malo ili mnogo vremena). Scrum to pokušava da "demokratizuje" tako što ceo tim mora da se usaglasi oko ocena i tako što tim odlučuje o tome koliko kapaciteta ima za posao. Naravno, to se onda najstrašnije zloupotrebljava kada dođe do odstupanja, jer svako odstupanje sjebava burndown chart što onda treba da stvori psihološki pritisak na ceo tim da zalegnu više da bi jebeni grafik lepo izgledao (i, kao što je gore napisano, neko dobio bonus na bazi ispunjenja plana). 

 

Ja uvek menadžment iznad pitam "jel bitno da grafik lepo izgleda il da se posao završi kako treba?" Nažalost, često dobijam kao odgovor nemušto "pa naravno posao da bude kako treba, ali bitno je i da se prati grafik... bla bla... metrika... bla bla... performanse..." i od toga mi se povraća.

[Lezilebovich]

@sammael - tim u scrumu procenjuje taskove koji su u backlogu, nisam nigde naisao na ideju da procenjuju ceo projekat unapred ( kao sto radi sw arhitekta i pm i na kraju prodaja :) u klasicnim™ metodologijama)

 

@radisa - lepo si opisao zasto je skoro nemoguce raditi agilno implementaciju ERPa ( bar kod nas). Fakticki bi morali na pocetku implementacije reci da ne znamo sta je scope, koliko ce trajati i na kraju koliko ce kostati.

Skoro mi je jedan istaknuti pojedinac u basem malom MS Dynamics svetu pricao da je agilni nacin jedini koji daje zeljene rezultate. Lako je njemu kad je MVP i radi tamo sa Dancima i Islandjanima :)

 

Srecom, sad su tu kombinacije agilnog i vodopoda, pa u okviru zadatok scopa i cene imamo neki iterativan proces, nije bas da klijent na obukama prvi put vidi resenje

 

I jos nesto oko scruma - pre pre previse neproduktivnig vremena. Ako je sprint 10 dana, bar jedan dan po osobi odlazi na razne manifestacije.

Edited March 27, 2017 by Lezilebovich

[Sammael]

Pa upravo si u odgovoru radisi napisao u cemu je problem: po scrumu nema PMova, arhitekte su deo tima kao i programeri, i ocene se daju samo za backlog a ne za ceo projekat. Stos je ubediti klijente da to tako treba... sto u ovim krajevima nema sanse.

 

Ja nisam u ERP svetu ali ovi moji u Dynamicsu su presli prosle godine na scrum. Nemam pojma kako im ide, moracu da se raspitam.

[radisa]

@radisa - lepo si opisao zasto je skoro nemoguce raditi agilno implementaciju ERPa ( bar kod nas). Fakticki bi morali na pocetku implementacije reci da ne znamo sta je scope, koliko ce trajati i na kraju koliko ce kostati.

Skoro mi je jedan istaknuti pojedinac u basem malom MS Dynamics svetu pricao da je agilni nacin jedini koji daje zeljene rezultate. Lako je njemu kad je MVP i radi tamo sa Dancima i Islandjanima :)

 

Ja radim nešto drugo, ali to je to...

 

Inače, rekoh da su ono stranci, iz mog primera...

 

Inače2, ja strašno pizdim od menjanja scopea u sred projekta, jer ja radim sa DWH, i meni je jako jako važno da u startu imam definisane izvore podatka, kako treba, kako bi mogao da napravim DWH da radi stabilno i brzo... Svako kasnije budženje može da izazove problem negde, i zahteva dodatnog budženja i tako...

 

Mislim, u gornjem primeru je 30% projekta trebalo da bude model i izveštaji vezani za nabavku i delivery nabavke na odredište, praćeno po različitim vremenskim osama, meremo u kilaži i vrednosti. Samo po sebi je već komlikovano. E onda su mi na kraju (posle gomile modifikacija) tražili da u model ubudžim i razlaganje cena na cenovne uslove, posebno za delivery, posebno za nabavku,  iako to u stratu nije traženo, a ja sam pitao više puta. Sramota me od budža, ali mi se nije modelovalo od početka sve to...

 

I onda će neko doći i reći, šta su vam ovi koji kurac pravili, to se tako ne radi...

[Zverilla]

@sammael - tim u scrumu procenjuje taskove koji su u backlogu, nisam nigde naisao na ideju da procenjuju ceo projekat unapred ( kao sto radi sw arhitekta i pm i na kraju prodaja :) u klasicnim™ metodologijama)

 

dao si primer za jedan od sustinskih problema sa skraAamom: on zahteva da se cela organizacija podredi principima skrama

naravno, klijenta koji daje pare zaboli kita za skram, vodopad, kanban.

on daje odredjenu kolicnu para da dobije odredjeni proizvod (a ne odredjen broj sprintova), i to je ono sto ce mu prodaja i ponuditi i za taj proizvod ce se potpisati ugovor

 

i onda dolazi do "radisine" situacije: vreme za projekat je isteklo (po skramu to je kraj projekta, musteriju ko jebe sto nije bolje odredjivala prioritet zadataka)

ali da musterija i ocekuje vise i bolje i drugacije, i da ta zelja mora da se ispuni da bi se potpisao sledeci ugovor

 

e sad, da vidim tog SM koji ce da ode god prodaje i gazde firme i da mu kaze da otera klijenta u kurac, jer je klijent u ovom slucaju najveci impediment :)