Czy ktoś wie co to SAFe?

Jak w tytule.

1. Czy ktoś wie co to SAFe?
2. Czy to prawda iż to najgorsze połączenie Scruma i Waterfalla?
3. Czy zgodzilibyscie się pracować w projekcie gdzie jest SAFe?

KamilAdam napisał(a):

1. Czy ktoś wie co to SAFe?

No ja wiem, tylko że ja na to zawsze mówiłem SAF.

KamilAdam napisał(a):

2. Czy to prawda iż to najgorsze połączenie Scruma i Waterfalla?

Mam z SAF (czy SAFe) taką samą relację jak z flacid-scrum; tzn. ktoś usłyszał określenie, źle je odebrał, wdrożył je (bez wysiłku) i spodziewa się rezultatów — a że metodologia jest źle wprowadzona, to i rezultatów nie ma; i wtedy często taki delikwent obwinia metodologię (a nie szuka błędu w swoim niepoprawnym wprowadzeniu jej).

Mam wrażenie że efekt jest taki sam jak z Agile — tzn. w genezie miał pomagać programistom, ale został wdrożony w zbyt korporacyjny sposób, przez co nie pomaga, a czasem i nawet szkodzi.

KamilAdam napisał(a):

3. Czy zgodzilibyscie się pracować w projekcie gdzie jest SAFe?

Ja w swoich projektach staram się pracować w XP, i nie widzę powodu żeby to zmieniać — ergo, raczej podziękuję.

Ale nawet gdyby nie XP, to nie chciałbym pracować w SAFe. Za bardzo mi to przypomina waterfalla.

Waterfall jest najgorszy, SAFe jest trochę lepszy, SCRUM jest trochę lepszy, i XP (IMO) jest lepsze od pozostałych.

To był plakacik na ścianie w jednym banku, gdzie mieliśmy SAFe
Pokazywał co programiści o tym myślą

Tak po prawdzie to w samym SAFe nie ma nic od razu złego.
Zasadniczy problem polega na tym, że jak już masz wystarczająco dużą organizację, żeby potrzebny był SAFe to jednocześnie jest to wystarczająco duża organizacja, żeby rozpleniły się pasożyty SCRUMowe, czyli nie tylko Scrum Masterzy, ale kołcze, policjancji scrumowi itd. Ciężko coś w takich warunkach w ogóle robić.

jarekr000000 napisał(a):

Tak po prawdzie to w samym SAFe nie ma nic od razu złego.

No właśnie w samym SAFe jest coś złego — a mianowicie jest w niego wręcz wbudowane nie reagowanie na zmiany i nowe info.

Nazwa "Scaled Agile Framework" powinna być zmieniona na "Scaled Unagile Framework".

Pamiętajmy cytat od Martina Fowlera:

SAFe stands for the Shitty Agile For Enterprises, as my friend calls it.

KamilAdam napisał(a):

Jak w tytule.

1. Czy ktoś wie co to SAFe?

Pewnie jacyś ludzie od certyfikatów.

2. Czy to prawda iż to najgorsze połączenie Scruma i Waterfalla?

W sumie nie wiem jak takie połączenie miałoby w ogóle wyglądać.

W SAFe kilka sprintów połączonych jest w jeden etap, przez pierwsze N sprintów się pracuje nad zadaniami, a ostatni sprint ma na celu zaplanowanie następnego etapu. Podczas tego planowania zespoły ogarniają zależności między sobą, a management widzi, co od czego zależy, i czy plan jest wykonalny.
Mnie mierzi to, że takie podejście w sumie spowalnia pracę, ale z drugiej strony mimo braku zapieprzu wszystkie taski są dowożone na czas. No nudno jest po prostu, a mnie bardzo męczy nicnierobienie.

3. Czy zgodzilibyscie się pracować w projekcie gdzie jest SAFe?

W firmie bez kultury pracy, takiej jak typowy SH, w którym 1SP = 1 dzień roboczy, skutkiem czego praca jest planowana co do godziny, daily trwa godzinę, a planowanie sprintu 3 dni, to nie.
Jeśli miałoby to działać tak jak u mnie teraz, to nie mam nic przeciwko.

Ogólnie nie przywiązywałbym się do tego, co jest napisane w ogłoszeniu o pracę, bo ta sama z nazwy metodyka różnie wygląda w różnych firmach.

Riddle napisał(a):

No właśnie w samym SAFe jest coś złego — a mianowicie jest w niego wręcz wbudowane nie reagowanie na zmiany i nowe info.

Nie jest też zakazane - a to już dużo.

somekind napisał(a):

Riddle napisał(a):

No właśnie w samym SAFe jest coś złego — a mianowicie jest w niego wręcz wbudowane nie reagowanie na zmiany i nowe info.

Nie jest też zakazane - a to już dużo.

No niby nie jest.

Ale z tego co pamiętam, to jednym z filarów SAFe jest "predictibility". I jeśli moja dedukcja działa dobrze to nie można można mieć jednocześnie predictibility i reagowania na zmiany. Jeśli reagujesz na zmiany, to siłą rzeczy to musi być unpredictable.

"Miłość" dla SAFe jest tak wielka, że powstają nawet o tym strony: https://safedelusion.com/.
Mam szczęście/nieszczęście pracować w tym teraz - jak słyszę, że mam zrobić estymaty na cały następny PI (circa kwartał), to się zastanawiam, gdzie w tym jest ta słynna zwinność.

Podejrzewam, że intencją powstania SAFe było ogarnięcie programów, które składają się z wielu projektów, robionych przez zespoły, mające wzajemne zależności. I wyszło jak wyszło.

Mnie kiedyś rozbawiło jak Agile Coach mnie upomniał że nie powinienem zmieniać sprintu z 2 tyg na np. 3tyg. (czasem wydłużaliśmy jak koniec wypadał w okresie świątecznym).

To się zasanowiłem po co w ogóle w tej nazwie "AGILE" występuje skoro nie można takiego banału modyfikować ad hoc...

Damian Korczowski napisał(a):

Mnie kiedyś rozbawiło jak Agile Coach mnie upomniał że nie powinienem zmieniać sprintu z 2 tyg na np. 3tyg. (czasem wydłużaliśmy jak koniec wypadał w okresie świątecznym).

Dobrze Ci powiedział, bo sprinty nie są po to żeby "coś zrobić".

Ale powód ku temu nie jest taki, jak większość ludzi myśli.

Sprint w agile'u ma Ci pomóc zmierzyć prędkość zespołu - to jest jedyny sens istnienia sprintów. Np robisz 8 sprintów przez 4 miesiące, liczysz średnią ilość dowiezionych rzeczy (jakkolwiek miarą chcesz, punkty, story points, godziny pracy, etc.), żeby na jej podstawie móc przewidzieć przyszłą prędkość. Jak zmienisz długość sprintu - to ta miarnodajnośc idzie do kosza. Jak zmieniasz czas sprintu, to w ogóle mógłbyś go nie robić.

Poza tym, po co w ogóle miałbyś zmieniać czas z 2 tyg. na 3 tyg.? Co byś tym zyskał? Zmniejszasz tylko rozdzielczość swojej metryki.

Riddle napisał(a):

Sprint w agile'u ma Ci pomóc zmierzyć prędkość zespołu - to jest jedyny sens istnienia sprintów.

A do czegoś się ta prędkość przydaje?

jarekr000000 napisał(a):

Riddle napisał(a):

Sprint w agile'u ma Ci pomóc zmierzyć prędkość zespołu - to jest jedyny sens istnienia sprintów.

A do czegoś się ta prędkość przydaje?

Żeby biznesy mogły lepiej spriorytetyzować następne zadanie.

Często jak biznesy słyszą że mają "do dyspozycji" 20 story pointów to wybiorą zestaw featureów A, B, C; a kiedy mają tylko 10 (bo np są święta), to wybiorą tylko feature'y E i F.

PS: Oczywiście, jeśli Twoje biznesy nie interesuje taka rzecz, czyli wybiorą kolejnośc feater'ów A, B, C niezależnie od prędkości; to wtedy w ogóle sprinty Ci nie są potrzebne - nie potrzeba ich. Mógłbyś z nich zrezygnować, bo nic Ci nie dają. Jednak w moich projektach biznesy zawsze są zainteresowane tą prędkością.

Riddle napisał(a):

Często jak biznesy słyszą że mają "do dyspozycji" 20 story pointów to wybiorą zestaw featureów A, B, C; a kiedy mają tylko 10 (bo np są święta), to wybiorą tylko feature'y E i F.

PS: Oczywiście, jeśli Twoje biznesy nie interesuje taka rzecz, czyli wybiorą kolejnośc feater'ów A, B, C niezależnie od prędkości; to wtedy w ogóle sprinty Ci nie są potrzebne - nie potrzeba ich. Jednak w moich projektach biznesy zawsze są zainteresowane tą prędkością.

I serio ta prędkość mierzona z velocity jest na tyle godna zaufania, że biznes decyduje się bawić w Scrumowego tetrisa?
Łociepanie.
Bo u mnie kurteczka nie ma żadnego velocity, a też wiemy co możemy obiecać na kwartał, miesiąc czy dziesięć dni do przodu. IMO z dokładnie takim samym poziomem zaufania, a może nawet wiekszym, bo ktoś za ten wybór odpowiada.

jarekr000000 napisał(a):

I serio ta prędkość mierzona z velocity jest na tyle godna zaufania, że biznes decyduje się bawić w Scrumowego tetrisa?

Jeśli nie jest przekłamywana (np. w taki sposób jak Pan wyżej chciał sobie wydłużyć sprint), i programiści nie są karani za "nie dowiezienie"; i wszyscy traktują sprinty jako metrykę, a nie jak commitment i obietnicę — to tak, jest to miarodajne.

jarekr000000 napisał(a):

Bo u mnie kurteczka nie ma żadnego velocity, a też wiemy co możemy obiecać na kwartał, miesiąc czy dziesięć dni do przodu. IMO z dokładnie takim samym poziomem zaufania.

Nie jestem w Twojej skórze, więc Ci nie powiem czy to co się dzieje u Ciebie działa dobrze czy źle. Nie wiem jak często te wasze "obietnice" się sprawdzają, a jak często nie.

Poza tym, w Agile nie chodzi o to żeby coś obiecać. Jak obiecasz klientowi że jego funkcjonalność będzie dostarczona za 2 miesiące, a skończycie ją w miesiąc, to co — nie wdrożysz jej wcześniej "bo przecież obiecane"? Agile to po prostu kółko — zbierz następną istotną rzecz do zrobienia, zrób, pokaż klientowi, zbierz feedback, powtórz. Po co tu miejsce na obietnice i estimate'y?

Agile nie polega na tym, żeby dostarczenie oprogramowania było przewidywalne — bo nigdy nie jest. W byciu agile chodzi tylko i wyłącznie o zrobienie najmniejszej możliwej rzeczy istotnej dla klienta, i zebranie feedbacku. Ciągłe zakładanie że jest się w błędzie, ciągłe spodziewanie się zmian, ciągłe dostosowywanie się do nich. Pomysły że można coś "zaplanować" albo "obiecać" są bardzo nie agile. Oczywiście, biznesy mogą sobie zaplanować co chcą zrobić w następny rok czy dwa — ale to nie znaczy od razu że Ty masz wytwarzać oprogramowanie w taki sposób. Programowanie powinno być prowadzone w taki sposób, żeby cały czas zakładać że wymagania mogą się zmienić — to jest agile.

PS: Poza tym, skoro nie musisz nic mierzyć — no to skoro nie musisz tego mierzyć, po co Ci sprinty w takim razie?

Riddle napisał(a):

Jeśli nie jest przekłamywana (np. w taki sposób jak Pan wyżej chciał sobie wydłużyć sprint), i programiści nie są karani za "nie dowiezienie"; i wszyscy traktują sprinty jako metrykę, a nie jak commitment i obietnicę — to tak, jest to miarodajne.

Kluczowe jest tu poczatkowe zalozenie, Jesli

Poza tym, w Agile nie chodzi o to żeby coś obiecać.

Pomijajac teoretyczne zalozenia, pomijajac fakt iz Agile z de facto narzedzia majacego ulatwic zycie programistom, transformowalo w twor ktory Agile'm jest tylko z nazwy, czy w sensie zawodowym miales do czynienia z tzw biznesem?

proximus-prime napisał(a):

Riddle napisał(a):

Jeśli nie jest przekłamywana (np. w taki sposób jak Pan wyżej chciał sobie wydłużyć sprint), i programiści nie są karani za "nie dowiezienie"; i wszyscy traktują sprinty jako metrykę, a nie jak commitment i obietnicę — to tak, jest to miarodajne.

Kluczowe jest tu poczatkowe zalozenie, Jesli

No jeśli są przekłamywane, to troche ich idea nie ma sensu. Dodajesz ludziom dodatkową rzecz o której muszą myśleć i brać w niej udział, a zysk żaden.

proximus-prime napisał(a):

[...] czy w sensie zawodowym miales do czynienia z tzw biznesem?

Owszem, i nadal mam, codziennie właściwie.

1. W praktyce nie, w teorii tak (=naczytałem się, mam jakieś przemyślenia w temacie, ale czekam na okazję przeszkolenia się, tak by mieć uczciwe podstawy teoretyczne)
2. Jest jeszcze swoboda interpretacji i kreatywności zespołów, obstawiam, że "najgorsze", nie jest ostatnim stopniem jakości ;-)
3. Jasne, że tak - jak organizacja ma SAFe, to siłą rzeczy musi realizować gigantyczne programy, w których jest przepalana astronomiczna ilość $$$.

Pytanie do praktyków, jak SAFe w organizacji wpływa na Waszą sytuację w zespole agile'owym? Jaka jest zasadnicza różnica vs sytuacja w zespole agile'owym ale bez SAFe?

Riddle napisał(a):

jarekr000000 napisał(a):

Bo u mnie kurteczka nie ma żadnego velocity, a też wiemy co możemy obiecać na kwartał, miesiąc czy dziesięć dni do przodu. IMO z dokładnie takim samym poziomem zaufania.

Nie jestem w Twojej skórze, więc Ci nie powiem czy to co się dzieje u Ciebie działa dobrze czy źle. Nie wiem jak często te wasze "obietnice" się sprawdzają, a jak często nie.

Poza tym, w Agile nie chodzi o to żeby coś obiecać. Jak obiecasz klientowi że jego funkcjonalność będzie dostarczona za 2 miesiące, a skończycie ją w miesiąc, to co — nie wdrożysz jej wcześniej "bo przecież obiecane"? Agile to po prostu kółko — zbierz następną istotną rzecz do zrobienia, zrób, pokaż klientowi, zbierz feedback, powtórz. Po co tu miejsce na obietnice i estimate'y?

Nie wiem skąd wymyślasz takie problemy. Nikt klientowi nie pisze, że coś (nietrywialnego do zakodowania) będzie zaimplementowane w środe 12 marca o czwartej po południu (i ani wcześniej, ani później).

Jeśli nie jest przekłamywana (np. w taki sposób jak Pan wyżej chciał sobie wydłużyć sprint), i programiści nie są karani za "nie dowiezienie"; i wszyscy traktują sprinty jako metrykę, a nie jak commitment i obietnicę — to tak, jest to miarodajne.

To już nic nie rozumiem. Bo wyżej pisałeś, że nie należy obiecać i estymować. To na czym polega ta miarodajność?

Agile nie polega na tym, żeby dostarczenie oprogramowania było przewidywalne — bo nigdy nie jest. W byciu agile chodzi tylko i wyłącznie o zrobienie najmniejszej możliwej rzeczy istotnej dla klienta, i zebranie feedbacku. Ciągłe zakładanie że jest się w błędzie, ciągłe spodziewanie się zmian, ciągłe dostosowywanie się do nich. Pomysły że można coś "zaplanować" albo "obiecać" są bardzo nie agile. Oczywiście, biznesy mogą sobie zaplanować co chcą zrobić w następny rok czy dwa — ale to nie znaczy od razu że Ty masz wytwarzać oprogramowanie w taki sposób. Programowanie powinno być prowadzone w taki sposób, żeby cały czas zakładać że wymagania mogą się zmienić — to jest agile.

Czyli piszesz, że "coś zaplanować" jest nie agile, a jednocześnie twój biznes planuje na podstawie tego agile, bo to jest zalega agile.
Moja prosta logika nie radzi sobie w takich przypadkach.

PS: Poza tym, skoro nie musisz nic mierzyć — no to skoro nie musisz tego mierzyć, po co Ci sprinty w takim razie?

Nie wiem po co mi sprinty -> nie mam sprintów.

jarekr000000 napisał(a):

Jeśli nie jest przekłamywana (np. w taki sposób jak Pan wyżej chciał sobie wydłużyć sprint), i programiści nie są karani za "nie dowiezienie"; i wszyscy traktują sprinty jako metrykę, a nie jak commitment i obietnicę — to tak, jest to miarodajne.

To już nic nie rozumiem. Bo wyżej pisałeś, że nie należy obiecać i estymować. To na czym polega ta miarodajność?

jarekr000000 napisał(a):

Agile nie polega na tym, żeby dostarczenie oprogramowania było przewidywalne — bo nigdy nie jest. W byciu agile chodzi tylko i wyłącznie o zrobienie najmniejszej możliwej rzeczy istotnej dla klienta, i zebranie feedbacku. Ciągłe zakładanie że jest się w błędzie, ciągłe spodziewanie się zmian, ciągłe dostosowywanie się do nich. Pomysły że można coś "zaplanować" albo "obiecać" są bardzo nie agile. Oczywiście, biznesy mogą sobie zaplanować co chcą zrobić w następny rok czy dwa — ale to nie znaczy od razu że Ty masz wytwarzać oprogramowanie w taki sposób. Programowanie powinno być prowadzone w taki sposób, żeby cały czas zakładać że wymagania mogą się zmienić — to jest agile.

Czyli piszesz, że "coś zaplanować" jest nie agile, a jednocześnie twój biznes planuje na podstawie tego agile, bo to jest zalega agile.
Moja prosta logika nie radzi sobie w takich przypadkach.

Czym innym jest priorytetyzować następne zadanie/zadania, a czym innym jest zaplanować dostarczenie X zadań w przyszłość.

Agile powinno pozwolić biznesom przedstawić priorytety programistom (i po to jest miarodajność i sprinty), ale bez planowania że coś będzie dostarczone kiedyś (dlatego obietnice i estimate'y są niepotrzebne).

• Priotytetyzowanie jest wartościowe, bo pozwala ukierunkować programowanie, i maksymalizuje wartość dostarczoną klientom i end-userom
• Planowanie jest niepomocne i spisane na porażkę, bo zawsze wyjdzie coś nowego czego nie przewidzisz.

PS: Chyba trochę rozumiem o co Ci chodzi, powiem to w prostych słowach:

• Biznes, na podstawie miarodajnych sprintów, ma powiedzieć "teraz róbcie X" albo "teraz róbcie Y" (to jest pomocne, taka bliska komunikacja biznesów z programistami jest jednym z powodów czemu takie zespoły tak wydajnie pracują).
• Biznes nie ma używać sprintów, żeby zaplanować że za N dni X będzie zrobione (to nie jest pomocne).

Najgorszym przypadkiem jest jak biznes mówi "teraz róbcie X, potem Y, potem Z, a potem jeszcze Z1". Po każdym skończonym featurze powinna nastąpić ponowna ewaluacja tego jaki feature ma być następny (możliwe że ten który sobie zaplanowałeś, ale możliwe że nie).

Jak biznes Ci powie "potem chciałbym dodać jeszcze Z", to zawsze trzeba to traktować jak guess, luźny pomysł, luźną drogę; coś co zawsze się może zmienić. Rób jedną rzecz która aktualnie ma największy priorytet, i przygotuj się na to że następne zadanie może się okazać zupełnie inne niż zaplanowane. Może się nawet okazać że zadanie które aktualnie robisz przestaje być aktualne i trzeba je wyrzucić do kosza. Dlatego warto robić feature'y małymi krokami.

Riddle napisał(a):

• Biznes, na podstawie miarodajnych sprintów, ma powiedzieć "teraz róbcie X" albo "teraz róbcie Y" (to jest pomocne, taka bliska komunikacja biznesów z programistami jest jednym z powodów czemu takie zespoły tak wydajnie pracują).
• Biznes nie ma używać sprintów, żeby zaplanować że za N dni X będzie zrobione (to nie jest pomocne).

Tylko dlaczego biznes ma do tego używać jakichś kompletnie debilnych wskaźników takich jak velocity czy story pointy, jak po prostu może mieć tabelkę priorytetów i ewentualnie porozmawiać z kimś z zespołu na temat poukładania tego w rozsądnej kolejności - jeśli jest taka potrzeba. Krótka rozmowa jest warta więcej niż 1000 Burdown chartów.

Riddle napisał(a):

Ale z tego co pamiętam, to jednym z filarów SAFe jest "predictibility". I jeśli moja dedukcja działa dobrze to nie można można mieć jednocześnie predictibility i reagowania na zmiany. Jeśli reagujesz na zmiany, to siłą rzeczy to musi być unpredictable.

Zmiany... ale które?
Jak często zachodzi potrzeba reagowania na nie?

yarel napisał(a):

Pytanie do praktyków, jak SAFe w organizacji wpływa na Waszą sytuację w zespole agile'owym? Jaka jest zasadnicza różnica vs sytuacja w zespole agile'owym ale bez SAFe?

No w zespołach agile'owych do tej pory był zapieprz i brak efektów, bo nigdy się nie dowoziło. Teraz nie ma zapieprzu, dowozi się zawsze, do tego 1 na 5 sprintów jest całkiem luźny. Irytujące jest za to czasem to planowanie, na którym trzeba być, a w sumie i tak wszystkie klocki układa TL i PO z pomocą SM. Niemniej jednak, sumarycznie i tak jest mniej spotkań.

jarekr000000 napisał(a):

Krótka rozmowa jest warta więcej niż 1000 Burdown chartów.

No tak, tylko jak każdy zespół ma swoją tabelkę, którą poukłada wg swoich priorytetów, to może się to okazać niewykonalne. No chyba, że między zespołami w ogóle nie ma zależności.

somekind napisał(a):

No tak, tylko jak każdy zespół ma swoją tabelkę, którą poukłada wg swoich priorytetów, to może się to okazać niewykonalne. No chyba, że między zespołami w ogóle nie ma zależności.

Kiedyś pracowałem w SAFe i jak na planowaniu inkrementu wyszło, że mamy zależności to po miesiącu i tak się okazywało, że inne zespoły nie zrobią nam tych zmian co potrzebujemy, bo mają większe problemy.
Teraz nie pracuje w SAFe i jak się dogadam z innymi zespołami to też po miesiącu okazuje się, że nie zrobią tego co potrzebujemy, bo mają większe problemy.
Szczęście, że teraz nie pracuje w Agilnej organizacji, więc jak czegoś naprawdę potrzebuje, to wbijam w cudze repo i sam implementuje, ku przerażeniu danego zespołu.

jarekr000000 napisał(a):

Szczęście, że teraz nie pracuje w Agilnej organizacji, więc jak czegoś naprawdę potrzebuje, to wbijam w cudze repo i sam implementuje, ku przerażeniu danego zespołu.

No ja generalnie też tak robię. Tylko inner sourcing to jest praktyka w ogóle niezależna od wszelkich metodyk prowadzenia projektów.
A, no i IS to jest bardzo agilne podejście. :P

Pracuję w SAFe - wg mnie jest to nienajgorsze podejście bo wymusza/umożlwia jednak pewną koordynację planowania developmentu czy weryfikacji na poziomie większego solution. Mamy ten ART który ma dowieźć jakąś funkcję(czy zestaw funkcji) złożoną z kilkunastu komponentów, czasem nawet wchodzą w to rzeczy nieprogramistyczne no i trzeba dużo klocków z grubsza poskładać wychodząc od jakiś high-level requirementów. Jak robimy kompletny produkt (w moim wypadku samochód) no to tym bardziej potrzeba jakiegoś ustruktyrozwanego podejścia do planowania z "widokiem" z góry, gdzie możemy sobie te ART-y jakoś synchronizować. Zwykły Scrum w takim projekcie i tak trzeba wyskalować, więc firma musiałaby zrobić jakieś wewnętrzne procesy, natomiast waterfall ma trochę za dużą bezwładność jak na dzisiejsze czasy i otoczenie rynkowe, konkurencja zrobi coś nowszego a my zostajemy z tyłu - w SAFe można ten klocek w danym PI przerobić, w Waterfallu musimy zaorać i przejść całą ścieżkę od nowa.

@Oggy2 Zgodnie z SAFem, ARTy tworzone są na poziomie programu, więc na poziomie teamu nie powinno być zbyt dużego narzutu (dla pojedynczego zespołu) jeśli chodzi o aktywności planistyczno-synchronizacyjne. Czy faktycznie tak jest w praktyce? Czy u Was RTE ogarnia zależności między teamami i czy jest to dedykowany do tego ziomek, czy może pełni też inne role?

@yarel Rolą RTE u nas nie jest tak za bardzo ogarnianie zależności na poziomie technicznym - oni raczej facylitują te aktywności, pilnują progresu Fault Reportów, zarządzają ryzykami, pilnują żeby nam nie zapewnić zasoby(np. hardware do testów), nadzorują procesy QA[czy się odbywają, nie jakoś tak tecnicznie), trackują progres funkcji wchodzących do danego releasu itp. Jak chodzi o samo planowanie to u nas jest tak że mamy team "systemowców" który wymyśla feature i dokonuje dekompozycji requirementów. Oni mają swojego PO który ustala backlog i priorytety dla nich. Potem oni przychodzą do mojego teamu developerów(ja jestem TL) i pracujemy nad tym czego potrzeba w kodzie żeby się ta ich funkcja 'wydarzyła', często z TL z innych zespołów, potem razem z PO ustalamy jakie jest capacity, tworzymy backlog i deklarujemy ile możemy im dowieźć. Zwykle jest tak że ja i PO ogarniamy wszystkie zależności - czasem podpytuję zespołu jeżeli nie jestem w czymś biegły ale generalnie to impactu planistycznego na team prawie nie ma.

Riddle napisał(a):

• Biznes, na podstawie miarodajnych sprintów, ma powiedzieć "teraz róbcie X" albo "teraz róbcie Y" (to jest pomocne, taka bliska komunikacja biznesów z programistami jest jednym z powodów czemu takie zespoły tak wydajnie pracują).
  Jak biznes Ci powie "potem chciałbym dodać jeszcze Z", to zawsze trzeba to traktować jak guess, luźny pomysł, luźną drogę; coś co zawsze się może zmienić. Rób jedną rzecz która aktualnie ma największy priorytet, i przygotuj się na to że następne zadanie może się okazać zupełnie inne niż zaplanowane. Może się nawet okazać że zadanie które aktualnie robisz przestaje być aktualne i trzeba je wyrzucić do kosza. Dlatego warto robić feature'y małymi krokami.

kiedy i przede wszystkim kto robi analizę która pozwoli stwierdzić zależności i zidentyfikować części wspólne dla X Y i Z ?

Miang napisał(a):

Riddle napisał(a):

• Biznes, na podstawie miarodajnych sprintów, ma powiedzieć "teraz róbcie X" albo "teraz róbcie Y" (to jest pomocne, taka bliska komunikacja biznesów z programistami jest jednym z powodów czemu takie zespoły tak wydajnie pracują).
  Jak biznes Ci powie "potem chciałbym dodać jeszcze Z", to zawsze trzeba to traktować jak guess, luźny pomysł, luźną drogę; coś co zawsze się może zmienić. Rób jedną rzecz która aktualnie ma największy priorytet, i przygotuj się na to że następne zadanie może się okazać zupełnie inne niż zaplanowane. Może się nawet okazać że zadanie które aktualnie robisz przestaje być aktualne i trzeba je wyrzucić do kosza. Dlatego warto robić feature'y małymi krokami.

kiedy i przede wszystkim kto robi analizę która pozwoli stwierdzić zależności i zidentyfikować części wspólne dla X Y i Z ?

• Kto: Klient (czy tam Product Owner, biznes, zwał jak zwał - osoba decyzynja, która podejmuje decyzje o tym jakie feature'y wprowadzić a jakie nie).
• Kiedy: jak tylko się da. Im szybciej tym lepiej, żeby mieć najmniejszy feedback loop. Najlepiej za każdym razem jak programiści dodadzą nową zmianę, czyli idealnie co kilka godzin lub codziennie, w najgorszym wypadku co tydzień.

Poza tym, to wcale nie identyfikowanie zależności jest tutaj celem. Klient po prostu ma zdecydować które feature'y warto dodać teraz (razem lub osobno), a które później (i czy w ogóle).

Powodem czemu w wielu miejscach nie udaje się wprowadzić Agile (lub wprowadza się jego karykaturę), jest to że programista widzi backlog, i traktuje to jak wyrytą w kamieniu prawdę. Że te rzeczy które tam są trzeba będzie zrobić, i że tak będzie wyglądał program z x miesięcy/lat — i jak do tego podejdziesz, to nie będziesz Agile. Bycie agile polega na tym, żeby zrozumieć że taki backlog to jest tylko aktualna wizja/snapshot tego co klient myśli, że chce. Należy się nastawić że możliwe ze 90% tych feater'ów może nigdy nie wejść, że plany się mogą obrócić o 180°, że czasem task który robisz w połowie może się okazać że już jest niewarty robienia, że być może najważniejszy feature który trzeba dodać jeszcze nie trafił na tą listę. Backlog w naszych głowach powinien bardziej przypominać staw lub coś płynnego, zmiennego; nie jak plan. (Specjalnie nie mówię rzekę, żeby nie zasugerować że to ma być sekwencyjne).

Riddle napisał(a):

Miang napisał(a):

Riddle napisał(a):

• Biznes, na podstawie miarodajnych sprintów, ma powiedzieć "teraz róbcie X" albo "teraz róbcie Y" (to jest pomocne, taka bliska komunikacja biznesów z programistami jest jednym z powodów czemu takie zespoły tak wydajnie pracują).
  Jak biznes Ci powie "potem chciałbym dodać jeszcze Z", to zawsze trzeba to traktować jak guess, luźny pomysł, luźną drogę; coś co zawsze się może zmienić. Rób jedną rzecz która aktualnie ma największy priorytet, i przygotuj się na to że następne zadanie może się okazać zupełnie inne niż zaplanowane. Może się nawet okazać że zadanie które aktualnie robisz przestaje być aktualne i trzeba je wyrzucić do kosza. Dlatego warto robić feature'y małymi krokami.

kiedy i przede wszystkim kto robi analizę która pozwoli stwierdzić zależności i zidentyfikować części wspólne dla X Y i Z ?

• Kto: Klient (czy tam Product Owner, biznes, zwał jak zwał - osoba decyzynja, która podejmuje decyzje o tym jakie feature'y wprowadzić a jakie nie).
• Kiedy: jak tylko się da. Im szybciej tym lepiej, żeby mieć najmniejszy feedback loop. Najlepiej za każdym razem jak programiści dodadzą nową zmianę, czyli idealnie co kilka godzin lub codziennie, w najgorszym wypadku co tydzień.

Poza tym, to wcale nie identyfikowanie zależności jest tutaj celem. Klient po prostu ma zdecydować które feature'y warto dodać teraz (razem lub osobno), a które później (i czy w ogóle).

identyfikowanie ma chociażby wpływ na pracochłonność, jeżeli nie bierzemy pod uwagę wpływu zależności w systemie to sobie spaghetti gotujemy

Powodem czemu w wielu miejscach nie udaje się wprowadzić Agile (lub wprowadza się jego karykaturę), jest to że programista widzi backlog, i traktuje to jak wyrytą w kamieniu prawdę. Że te rzeczy które tam są trzeba będzie zrobić, i że tak będzie wyglądał program z x miesięcy/lat — i jak do tego podejdziesz, to nie będziesz Agile. Bycie agile polega na tym, żeby zrozumieć że taki backlog to jest tylko aktualna wizja/snapshot tego co klient myśli, że chce. Należy się nastawić że możliwe ze 90% tych feater'ów może nigdy nie wejść, że plany się mogą obrócić o 180°, że czasem task który robisz w połowie może się okazać że już jest niewary robienia. Backlog w naszych głowach powinien bardziej przypominać staw lub coś płynnego, zmiennego; nie jak plan.

no właśnie poprzez brak planowania w połowie roboty ląduje ona w /dev/null

Miang napisał(a):

identyfikowanie ma chociażby wpływ na pracochłonność, jeżeli nie bierzemy pod uwagę wpływu zależności w systemie to sobie spaghetti gotujemy

To jest prawda, i dlatego to programiści oceniają jak bardzo coś jest pracochłonne, w postaci jakieś bezjednostkowej wartości — nie klient. Taką bezjednostkowa wartością mogą być np. popularne story-pointy. Można też wybrać "łatwe", "średnie", "trudne", czy jakikolwiek inny sposób żeby uzmysłowić klientowi które zadanie jest jak trudne (Raczej nie polecam jednostkowych wartości, jak np liczenie czasu w godzinach).

Klient widzi na jaką trudność zostało ocenione zadanie, widzi że są święta, widzi ile rzeczy udało się zrobić w ostatnim sprincie — i biorąc pod uwagę pracochłonność tego zadania, oraz tego które zadanie jest dla niego najistotniejsze — podejmuje decyzję, które zadanie wykonać teraz.

Miang napisał(a):

Riddle napisał(a):

Powodem czemu w wielu miejscach nie udaje się wprowadzić Agile (lub wprowadza się jego karykaturę), jest to że programista widzi backlog, i traktuje to jak wyrytą w kamieniu prawdę. Że te rzeczy które tam są trzeba będzie zrobić, i że tak będzie wyglądał program z x miesięcy/lat — i jak do tego podejdziesz, to nie będziesz Agile. Bycie agile polega na tym, żeby zrozumieć że taki backlog to jest tylko aktualna wizja/snapshot tego co klient myśli, że chce. Należy się nastawić że możliwe ze 90% tych feater'ów może nigdy nie wejść, że plany się mogą obrócić o 180°, że czasem task który robisz w połowie może się okazać że już jest niewary robienia. Backlog w naszych głowach powinien bardziej przypominać staw lub coś płynnego, zmiennego; nie jak plan.

no właśnie poprzez brak planowania w połowie roboty ląduje ona w /dev/null

To też jest prawda, i zgadzam się że połowa roboty ląduję w /dev/null, i jest to duży problem - ale nie przez brak planowania. Dzieje się tak, przez to że naszła konieczność zmiany, oraz kiedy zaczęliśmy pracę, to nie mieliśmy mieć perfekcyjnej wiedzy, nt tego co klient będzie chciał (i mieć nie mogliśmy).

Rozwiązaniem na to jest wprowadzać zmiany bardzo małe, takie na 1-2h pracy, nie na 1-2 tygodnie pracy. Więc jak zaczniesz zmianę która trwa 1-2h, i okaże się że jest do wyrzucenia to stracisz najwyżej 1-2h, a nie 1-2 tygodnie. To jest właśnie bycie agile.

Riddle napisał(a):

Klient widzi na jaką trudność zostało ocenione zadanie, widzi że są święta, widzi ile rzeczy udało się zrobić w ostatnim sprincie — i biorąc pod uwagę pracochłonność tego zadania, oraz tego które zadanie jest dla niego najistotniejsze — podejmuje decyzję, które zadanie wykonać teraz.

Rozwiązaniem na to jest wprowadzać zmiany bardzo małe, takie na 1-2h pracy, nie na 1-2 tygodnie pracy. Więc jak zaczniesz zmianę która trwa 1-2h, i okaże się że jest do wyrzucenia to stracisz najwyżej 1-2h, a nie 1-2 tygodnie. To jest właśnie bycie agile.

tylko że ja tu cały czas nie widzę pracy analitycznej czy projektowej