The Pontiff napisał(a):
Czemu w żadnej innej metodologii nie jest potrzebne dedykowane stanowisko które polega na bronieniu tej metodologii przed otoczeniem? Jak to jest że w innych metodologiach nie trzeba facylitować spotkań i nadzorować czy metodologia jest właściwie wdrażana?
Może ze scrumem jest coś mocno nie tak skoro nikt go nie chce i wszyscy rzucają mu kłody pod nogi?
Bo scrum to nie jest metodologia, ani framework. To religia. I jak każda religia potrzebuje kapłanów
Ja na twoim miejscu bym wybadał czy ten SM ma wartościowe kontakty w branży (wśród leadów, HRów, osób decyzyjnych). Jeśli tak - broń go nawet wobec zespołu. Jak nie - cut the corners.
Ha ha ha czyli co robi? Big picture robi? xd
Fajny artykuł tak w ogóle:
https://www.agilearena.net/the-scrum-master-role-sm/
1- Clearing obstacles: The scrum master should support the teams and should clear obstacles,
one of these obstacles is the work environment
Czemu w waterfallu nie jest potrzebna osoba która usuwa przeszkody?
2-Facilitates the team’s progress towards team goals: this is one of the most important
things that the scrum master has to do is facilitating and to update or improve the team
performance and help the team to focus on daily tasks or goals
To robi lider zespołu i PM
3-Facilitates meetings: the Daily Stand-up to be only 10 to 15 min, Iteration Planning,
and Iteration Review to be to the main point not to be out of context.
Daily standup zespół robi sobie sam bo certified scrum master g... rozumie z tego co developerzy mówią. Reszty spotkań nie ma w metodologiach poza scrumem.
4-Coordinates with other teams and the Product Owner: the scrum master
should be supportive not only the team but also should support the (PO) and coordinate the tasks,
Daily Stand-up, and other processes between team and product owners.
To robi PM.
5-Acting as a Coach for Team Development: the scrum master must teach the team
how to read the stories and let them focus on the sprint goals, and set up a physical task board
and shows the team how to use it.
Taa jasne xd
Sc(r)um to sekta.
Kiedyś zostałem obrzucany (oczywiście nie pozostałem dłużny i zrobiła się gruba awantura) za to, że nie wrzuciłem do Jiry i NIE WYESTYMOWAŁEM (najważniejsze przecież) zadania które przejąłem po koledze który poszedł na urlop. Trzeba było je dokończyć bo blokowało całą resztę roboty w projekcie. Niewiele brakowało do mordobicia tego dnia.
To, że wiedza techniczna jest scum masterowi niepotrzebna to też brednie. Zmarnowałem w życiu mnóstwo czasu na tłumaczenie dlaczego coś musimy zrobić w taki a nie inny sposób. Do tego tysiące niczego nie wnoszących spotkań robionych sztuka dla sztuki.Big picture? Od tego jest analityk.
"To co panowie, estymujemy?". Kolejna brednia, że wszystko da się wyestymować. Oczywiście nigdy scrum master który miał zapewniać usuwanie przeszkód nie zapewnił nam dedykowanego czasu na zapoznanie się z tym co mamy robić. No ale każą szacować to nie ma wyjścia i trzeba zachowawczo dodać bufor 100 albo i 200% bo nie wiadomo na jakie bagno się trafi.
Gardzę scrumem i jego formułą. Moim marzeniem jest obudzenie się któregoś dnia ze świadomością, że wszyscy scum masterzy zostali zwolnieni z pracy oraz że scum został zdelegalizowany
https://medium.com/@sngyuchao/scrum-why-it-doesnt-work-b9d193942a42
Sama prawda. A czemu autor doszedł do takich wniosków?
WRITTEN BY
YuChao Sng
Follow
I work in the financial sector specializing in trading systems, was a professional trader in both a macro hedge fund and an HFT firm.
Bo pracuje w obszarze gdzie chodzi o zarabianie pieniędzy a nie owocowe czwartki.
Scrum mastera jest od mówienia: "To nie temat na daily"
Kanban który jest faktycznie agile bez sekciarskiej otoczki scruma.
Kanban nie jest metodą agile'ową. Kanban jest metodą Lean. Optymalizuje inne rzeczy.
Czemu w żadnej innej metodologii nie jest potrzebne dedykowane stanowisko które polega na bronieniu tej metodologii przed otoczeniem? Jak to jest że w innych metodologiach nie trzeba facylitować spotkań i nadzorować czy metodologia jest właściwie wdrażana?
Po pierwsze, inne metodologie mogą optymalizować inne rzeczy. Po drugie, błędnie zakładasz, że w waterfallu nie ma facylitacji spotkań albo nie ma tam miejsca dla zadań które mogłyby zostać oddelegowane Scrum Masterowi.
Nie chce mi się szukać innych błędnych tez postawionych w wątku. Ktoś na przykład napisał, że rolę Scrum Mastera może pełnić PO. Scrum Master to jest pozycja, która jest w opozycji do PO. Jeżeli celem PO jest dowiezienie jak największej ilości historyjek, tak celem Scrum Mastera jest obrona zespołu przed przeładowaniem, żeby zespół miał więcej czasu na poprawne wykonywanie zadań, a nie na tym, żeby dostarczać jak najwięcej bezużytecznego kodu.
Jak zmierzyć wartość dodaną przez SM? Po pierwsze, trzeba mieć doświadczenie w pracy w różnych zespołach gdzie był SM oraz w zespołach gdzie go nie było. Po drugie, trzeba mieć zdefiniowane pewne metryki, wg których oceniamy cały zespół przed przyjściem Scrum Mastera i po.
Pracowałem w kilku projektach gdzie szefostwu (ciężko ich było nazwać product ownerami albo analitykami biznesowymi) wydawało się, że robili dobrą robotę tworząc tickety w Jirze gdzie w rzeczywistości nie potrafili wyspecyfikować co powinno być zrobione w poszczególnych zadaniach, nie potrafili też zrozumieć dlaczego ten gość, który jest złotą rączką i napisał połowę architektury firmy jest blokerem dla tej firmy. Dobry Scrum Master potrafi identyfikować problemy w komunikacji w zespole i zaproponować pewne czynności, które sprawią, że obłożenie pracą zostanie równomiernie rozłożone w całym zespole, a także potrafi identyfikować zewnętrzne problemy i proponować realne rozwiązania tych problemów. I np. retrospektywa jest jednym z narzędzi, które w tym pomaga, ale nie jedynym. Można się śmiać z wielu innych rzeczy obecnych w scrumie, np. z powyższego: "To nie temat na daily". Wyobraźmy sobie, że na daily jest 10 osób, każda mówi co dzisiaj robiła i każda osoba zaczyna temat, który może być wałkowany godzinami. W takich warunkach daily nigdy by się nie skończyło i nie dowiedzielibyśmy się czy pozostali uczestnicy mają jakieś problemy, które można szybko zidentyfikować. Czas na pozostałe dyskusje jest np. po daily, natomiast samo daily ma konkretną funkcję do spełnienia.
Komuniści też pięknie opisywali jak ich system będzie działać i dlaczego jest najlepszy.
Nie bez powodu mamy "Manifest komunistyczny" i "Manifest Agile".
twoj_stary_pijany napisał(a):
tworząc tickety w Jirze gdzie w rzeczywistości nie potrafili wyspecyfikować co powinno być zrobione w poszczególnych zadaniach
Zespól sam może powiedzieć, że coś nie jest odpowiednio wyspecyfikowanie. Nie potrzebuje do tego Scruma Mastera.
Wyobraźmy sobie, że na daily jest 10 osób, każda mówi co dzisiaj robiła.
Co mnie obchodzi co kto robił? Będę chciał to wiedzieć to popatrzę na boarda.
W takich warunkach daily nigdy by się nie skończyło i nie dowiedzielibyśmy się czy pozostali uczestnicy mają jakieś problemy, które można szybko zidentyfikować.
Jak ktoś ma problem to od razu komunikuje odpowiednim kanałami. Mam daily o 10:00, problem pojawił się o 10:30. Mam czekać do następnego dnia żeby poprosić o pomoc?
twoj_stary_pijany napisał(a):
Po pierwsze, inne metodologie mogą optymalizować inne rzeczy. Po drugie, błędnie zakładasz, że w waterfallu nie ma facylitacji spotkań albo nie ma tam miejsca dla zadań które mogłyby zostać oddelegowane Scrum Masterowi.
W waterfallu jest bardzo dużo spotkań, ale obywają się bez scrum mastera. Jak to mozliwe?
Jak zmierzyć wartość dodaną przez SM? Po pierwsze, trzeba mieć doświadczenie w pracy w różnych zespołach gdzie był SM oraz w zespołach gdzie go nie było. Po drugie, trzeba mieć zdefiniowane pewne metryki, wg których oceniamy cały zespół przed przyjściem Scrum Mastera i po.
Ja bym raczej oceniał przed przejściem na scruma i po. SM służy do rozwiązywania problemów które scrum tworzy.
Pracowałem w kilku projektach gdzie szefostwu (ciężko ich było nazwać product ownerami albo analitykami biznesowymi) wydawało się, że robili dobrą robotę tworząc tickety w Jirze gdzie w rzeczywistości nie potrafili wyspecyfikować co powinno być zrobione w poszczególnych zadaniach, nie potrafili też zrozumieć dlaczego ten gość, który jest złotą rączką i napisał połowę architektury firmy jest blokerem dla tej firmy.
Ale to nie ma nic wspólnego ze SM. Ja też spotkałem się z bardzo wieloma analitykami którzy nie potrafili pisać wymagań bo przyszli z ulicy. I z paroma którzy potrafili doskonale wyspecyfikować co trzeba zrobić, łącznie z dogadaniem komunikatów między systemami. Bo mieli głowę jak encyklopedia i byli bardzo dobrzy w tym co robią. Żaden nie potrzebował scrum mastera. Pracowali głównie w wordzie i excelu a potem ewentualnie przepisywali do jiry.
Dobry Scrum Master potrafi identyfikować problemy w komunikacji w zespole i zaproponować pewne czynności, które sprawią, że obłożenie pracą zostanie równomiernie rozłożone w całym zespole, a także potrafi identyfikować zewnętrzne problemy i proponować realne rozwiązania tych problemów. I np. retrospektywa jest jednym z narzędzi, które w tym pomaga, ale nie jedynym.
Ale tym się zajmuje lider zespołu, taki odpowiednik sztygara albo kaprala. Tak jest w każdym zawodzie zespołowym. Nie jest do tego potrzebny osobny człowiek dodany odgórnie do zespołu.
Można się śmiać z wielu innych rzeczy obecnych w scrumie, np. z powyższego: "To nie temat na daily". Wyobraźmy sobie, że na daily jest 10 osób, każda mówi co dzisiaj robiła i każda osoba zaczyna temat, który może być wałkowany godzinami. W takich warunkach daily nigdy by się nie skończyło i nie dowiedzielibyśmy się czy pozostali uczestnicy mają jakieś problemy, które można szybko zidentyfikować. Czas na pozostałe dyskusje jest np. po daily, natomiast samo daily ma konkretną funkcję do spełnienia.
Brzmisz jak urzędnicy z zusu którzy twierdzą że to dzięki nim firma może prowadzić działalność, bo bez nich składki przestałyby się zgadzać.
mechanix napisał(a):
Jak ktoś ma problem to od razu komunikuje odpowiednim kanałami. Mam daily o 10:00, problem pojawił się o 10:30. Mam czekać do następnego dnia żeby poprosić o pomoc?
Tak z innej beczki to był u nas kiedyś zespół który w co drugi piątek odrzucał wszystkie spotkania i nie odpowiadał na maile bo "we have a planning on Friday" :D
Komuniści też pięknie opisywali jak ich system będzie działać i dlaczego jest najlepszy.
Nie bez powodu mamy "Manifest komunistyczny" i "Manifest Agile".
Brzmisz jak urzędnicy z zusu którzy twierdzą że to dzięki nim firma może prowadzić działalność, bo bez nich składki przestałyby się zgadzać.
Brzmicie jak ewangeliści waterfalla. Rzeczywistość jest jednak taka, że z jakiegoś powodu wszyscy przerzucili się na metodologię agile, a ludzie, którzy się nie potrafili dostosować dzisiaj śpią z dinozaurami albo liczą straty. Pracowałem kiedyś z jednym gościem z którym było się ciężko dowiedzieć czegokolwiek bo agresywnie reagował. Ten sam gość właśnie był pierwszym do krytykowania roli Scrum Mastera nie wiedząc, że Scrum Master został właśnie zatrudniony do radzenia z sobie z takimi osobnikami jak on. Nie wiem czy z wami jest tak samo, choć się domyślam.
twoj_stary_pijany napisał(a):
Komuniści też pięknie opisywali jak ich system będzie działać i dlaczego jest najlepszy.
Nie bez powodu mamy "Manifest komunistyczny" i "Manifest Agile".Brzmisz jak urzędnicy z zusu którzy twierdzą że to dzięki nim firma może prowadzić działalność, bo bez nich składki przestałyby się zgadzać.
Brzmicie jak ewangeliści waterfalla.
To tak nie działa. Nie możesz nam powiedzieć, że tylko scrum albo tylko waterfall - to nie rewolucja hiszpańska żebym musiał wybierać pomiędzy komunizmem a faszyzmem.
Rzeczywistość jest jednak taka, że z jakiegoś powodu wszyscy przerzucili się na metodologię agile, a ludzie, którzy się nie potrafili dostosować dzisiaj śpią z dinozaurami albo liczą straty. Pracowałem kiedyś z jednym gościem z którym było się ciężko dowiedzieć czegokolwiek bo agresywnie reagował. Ten sam gość właśnie był pierwszym do krytykowania roli Scrum Mastera nie wiedząc, że Scrum Master został właśnie zatrudniony do radzenia z sobie z takimi osobnikami jak on. Nie wiem czy z wami jest tak samo, choć się domyślam.
No to kolejne podobieństwo, komuniści też mieli gości do radzenia z sobie z takimi osobnikami jak on :D
Chyba nie zrozumiałeś mojego przekazu. Gdyby ten system rzeczywiście tak idealnie działał w praktyce jak obiecywano, to byłbym bardzo szczęśliwy.
part napisał(a):
To tak nie działa. Nie możesz nam powiedzieć, że tylko scrum albo tylko waterfall - to nie rewolucja hiszpańska żebym musiał wybierać pomiędzy komunizmem a faszyzmem.
W opozycji do waterfalla to bardziej stoi już cała metodologia agile, a scrum jest tylko jego jedną z wielu implementacji. Ja osobiście nie jestem zwolennikiem scrumu bo większość projektów, które realizuję nie jest powtarzalna i ciężko jest je estymować. Natomiast jeżeli nie podobają wam się pewne rzeczy ze scrumu to zawsze można się zorientować i negocjować ze Scrum Masterem czy część spotkań jest w ogóle potrzebna i jaki jest ich cel. Być może w waszym aktualnym teamie nie jest potrzebny SM bo zespół jest wyważony i ta rola jest rozłożona po zespole, a być może za rok kiedy zmienisz zespół zauważysz wiele mankamentów od strony komunikacyjnej gdzie jedynym sposobem na ich rozwiązanie byłaby pomoc SM. Natomiast warte uwagi jest też to, że jeżeli nie widzisz problemów komunikacyjnych w zespole nie znaczy, że ich tam nie ma. Czasami takie rzeczy warto oddelegować specjaliście. Z tym, że jak w każdej branży, są specjaliści i naciągacze, i trzeba pewnej wiedzy, żeby odróżnić jednych od drugich.
twoj_stary_pijany napisał(a):
Natomiast jeżeli nie podobają wam się pewne rzeczy ze scrumu to zawsze można się zorientować i negocjować ze Scrum Masterem czy część spotkań jest w ogóle potrzebna i jaki jest ich cel.
Jasne że w teorii możesz negocjować...
Być może w waszym aktualnym teamie nie jest potrzebny SM bo zespół jest wyważony i ta rola jest rozłożona po zespole, a być może za rok kiedy zmienisz zespół zauważysz wiele mankamentów od strony komunikacyjnej gdzie jedynym sposobem na ich rozwiązanie byłaby pomoc SM.
Jeżeli widzę problem, to nie będę czekać na magika tylko sam go poruszę i postaramy się rozwiązać w teamie. Zresztą trudno mi sobie wyobrazić problemy, w których jedynym sposobem na ich rozwiązanie byłaby pomoc SM - możesz podać przykład takiego problemu?
Natomiast warte uwagi jest też to, że jeżeli nie widzisz problemów komunikacyjnych w zespole nie znaczy, że ich tam nie ma.
W sumie dziwne, żeby ani programiści, ani klienci, ani managerowie nie zauważyli problemów, a sm miał taką moc. Jest jakieś specjalny rytuał na to?
part napisał(a):
Jeżeli widzę problem, to nie będę czekać na magika tylko sam go poruszę i postaramy się rozwiązać w teamie. Zresztą trudno mi sobie wyobrazić problemy, w których
jedynym sposobem na ich rozwiązanie byłaby pomoc SM- możesz podać przykład takiego problemu?
Właśnie SM powinien być od tego, by zobaczyć problem, jeśli Wy go nie widzicie. Możecie robić coś dobrze i nie zastanawiać się nigdy nad tym, a SM zobaczy, że może da się to jeszcze usprawnić.
możesz podać przykład takiego problemu?
Przykładowe problemy:
Oczywiście nie twierdzę, że te problemy nie mogą być rozwiązane przez aktualnych członków zespołu natomiast czasami lepiej skupić się na swojej robocie i negocjacje pozostawić zawodowym negocjatorom.
twoj_stary_pijany napisał(a):
- ogólne problemy związane z komunikacją między członkami zespołu,
?
- problemy w komunikacji na linii PO - zespół,
To chyba dziwny ten PO, że nie zauważył problemów komunikacyjnych z teamem.
- problemy w stworzeniu standardów komunikacji i wzajemnej współpracy w zespole,
W jakim sensie? Wybierze mi komunikator? Nauczy jak używać gita?
- problem związany z niedostatecznym komunikowaniem rzeczy do zrobienia, które PO zleca zespołowi, historyjki są niejasne, nie mają jasno określonych definicji ukończenia przez co nie da się stwierdzić, że zostały zrobione lub też nie,
I niby nietechniczny scrum master ma to ocenić?
- problem związany ze zbyt dużym obłożeniem zespołu przez zadania zlecone przez PO,
No tak, programiści nie zauważą, że mają za dużo roboty. PO pewnie też nie zauważy, że programiści nie dowożą.
- problemy związane z rozwiązywaniem zadań zleconych przez zewnętrzne zespoły,
Jakie niby problemy?
- problemy związane z blokerami spowodowanymi przez zewnętrzne zespoły, procedury oraz negocjacja kontraktów odpowiedzialności pomiędzy zespołami.
No to u mnie to się rozwiązuje po prostu linkując innego ticketa do obecnego i tyle. Nie rozumiem gdzie niby miałby tu scrum master pomóc.
part napisał(a):
- problemy w stworzeniu standardów komunikacji i wzajemnej współpracy w zespole,
W jakim sensie? Wybierze mi komunikator? Nauczy jak używać gita?
gorzej. Wymyśli szablon dokumentu na 6 strona i każe go używać ;)
- problem związany z niedostatecznym komunikowaniem rzeczy do zrobienia, które PO zleca zespołowi, historyjki są niejasne, nie mają jasno określonych definicji ukończenia przez co nie da się stwierdzić, że zostały zrobione lub też nie,
I niby nietechniczny scrum master ma to ocenić?
no obrazki w historyjkach nie będą ładne
twoj_stary_pijany napisał(a):
Kanban nie jest metodą agile'ową. Kanban jest metodą Lean. Optymalizuje inne rzeczy.
No niemniej jednak w świecie inżynierii oprogramowania jest powszechnie zaliczana do metod agile'owych.
Prawdopodobnie dlatego, że jest zdecydowanie bardziej zwinna niż tak powszechnie forsowany scrum, czyli ciężka metodyka sprzeczna z Manifestem.
Jeżeli celem PO jest dowiezienie jak największej ilości historyjek, tak celem Scrum Mastera jest obrona zespołu przed przeładowaniem, żeby zespół miał więcej czasu na poprawne wykonywanie zadań, a nie na tym, żeby dostarczać jak najwięcej bezużytecznego kodu.
No to ambitny cel zważywszy na fakt, że SM nie ma wiedzy merytorycznej aby tego dokonać, bo jest nietechniczny.
Jak zmierzyć wartość dodaną przez SM? Po pierwsze, trzeba mieć doświadczenie w pracy w różnych zespołach gdzie był SM oraz w zespołach gdzie go nie było.
No tyle, że to nie będzie miarodajne, bo skoro jest SM, to znaczy, że jest scrum, więc wydajność z definicji niższa niż w normalnej pracy.
Pracowałem w kilku projektach gdzie szefostwu (ciężko ich było nazwać product ownerami albo analitykami biznesowymi) wydawało się, że robili dobrą robotę tworząc tickety w Jirze gdzie w rzeczywistości nie potrafili wyspecyfikować co powinno być zrobione w poszczególnych zadaniach
SM przed tym wcale nie broni.
Dobry Scrum Master potrafi identyfikować problemy w komunikacji w zespole i zaproponować pewne czynności, które sprawią, że obłożenie pracą zostanie równomiernie rozłożone w całym zespole, a także potrafi identyfikować zewnętrzne problemy i proponować realne rozwiązania tych problemów. I np. retrospektywa jest jednym z narzędzi, które w tym pomaga, ale nie jedynym.
Problem juniorów. Zespół doświadczonych ludzi sam się równomiernie pracą obłoży i żaden SM w tym nie pomoże (ani nie przeszkodzi).
Można się śmiać z wielu innych rzeczy obecnych w scrumie, np. z powyższego: "To nie temat na daily". Wyobraźmy sobie, że na daily jest 10 osób, każda mówi co dzisiaj robiła i każda osoba zaczyna temat, który może być wałkowany godzinami.
W takim przypadku problemem jest zbyt duży zespół, i nie trzeba żadnego certyfikatu, aby to stwierdzić.
somekind napisał(a):
twoj_stary_pijany napisał(a):
Można się śmiać z wielu innych rzeczy obecnych w scrumie, np. z powyższego: "To nie temat na daily". Wyobraźmy sobie, że na daily jest 10 osób, każda mówi co dzisiaj robiła i każda osoba zaczyna temat, który może być wałkowany godzinami.
W takim przypadku problemem jest zbyt duży zespół, i nie trzeba żadnego certyfikatu, aby to stwierdzić.
Nietechniczny scrum master na daily tylko przeszkadza. Osobiście zawsze dbałem o to, żeby daily było jak najkrótsze i każdy kto chce pogadać o czymś konkretnym robił to z osobami zainteresowanymi już później. Okazało się, że można w taki sposób zrobić daily zespołu 8 osobowego w trzy minuty (co i tak było za długo) a nie 15 jak ze scrum masterem. No ale jak scrum master (nietechniczny) się pojawiał to już trzeba było właśnie tłumaczyć mu dlaczego coś jest problemem i jak to powinniśmy rozwiązać...
twoj_stary_pijany napisał(a):
możesz podać przykład takiego problemu?
Przykładowe problemy:
- ogólne problemy związane z komunikacją między członkami zespołu,
- problemy w komunikacji na linii PO - zespół,
- problemy w stworzeniu standardów komunikacji i wzajemnej współpracy w zespole,
- problem związany z niedostatecznym komunikowaniem rzeczy do zrobienia, które PO zleca zespołowi, historyjki są niejasne, nie mają jasno określonych definicji ukończenia przez co nie da się stwierdzić, że zostały zrobione lub też nie,
- problem związany ze zbyt dużym obłożeniem zespołu przez zadania zlecone przez PO,
- problemy związane z rozwiązywaniem zadań zleconych przez zewnętrzne zespoły,
- problemy związane z blokerami spowodowanymi przez zewnętrzne zespoły, procedury oraz negocjacja kontraktów odpowiedzialności pomiędzy zespołami.
Oczywiście nie twierdzę, że te problemy nie mogą być rozwiązane przez aktualnych członków zespołu natomiast czasami lepiej skupić się na swojej robocie i negocjacje pozostawić zawodowym negocjatorom.
Ale to wszystko nie jest specyficzne dla scruma (wystarczy zastąpić PO jakimś reprezentantem klienta/biznesu). Dlaczego więc tylko w scrumie chcecie zatrudniać dedykowaną osobę?
Bo trzeba znaleźć nieogarniętemu znajomemu jakąś ciepłą posadkę bez specjalnych wymagań. No i taką, żeby się biedaczek nie przepracował.
part napisał(a):
twoj_stary_pijany napisał(a):
- problemy w komunikacji na linii PO - zespół,
To chyba dziwny ten PO, że nie zauważył problemów komunikacyjnych z teamem.
Mówi się: "Najciemniej jest pod latarnią" albo "Nikt nie może być sędzią we własnej sprawie". Jeżeli Developerzy nie mogą porozumieć się z PO i PO ma być niezależnym moderatorem, który rozwiązuje te problemy z komunikacją to życzę powodzenia. Od razu możesz zacząć rozsyłać CV na LinkedInie.
The Pontiff napisał(a):
Ale to wszystko nie jest specyficzne dla scruma (wystarczy zastąpić PO jakimś reprezentantem klienta/biznesu). Dlaczego więc tylko w scrumie chcecie zatrudniać dedykowaną osobę?
A dlaczego chcesz zatrudniać do czegoś dedykowanego QA, albo dedykowanego SRE, albo DevOpsa, albo Java Developera? Nie wystarczy Developer? Czy musi być koniecznie Java Developer? Java Developerzy bohatersko bronią swoich posad matacząc, że inni developerzy nie mogą wykonywać takiej roboty jaką oni wykonują. To samo z JavaScript Developerami.
Ja jestem zwolennikiem tego, żeby na drodze między mną, a innymi było jak najmniej osób i większość rzeczy staram się załatwiać sam. Natomiast pewne osoby celowo chowają się w piwnicach i utrudniają kontakt, wtedy warto poprosić Scrum Mastera o reakcję, żeby pomógł nam zorganizować takie spotkanie i był niezależnym moderatorem. Również nie jestem zwolennikiem Scrum Mastera na pełny etat, natomiast warto mieć dobrego Scrum Mastera w firmie, którego można poprosić o pomoc, żeby przeszkolił kolegów jeżeli ktoś stwierdzi, że jest taka potrzeba.
somekind napisał(a):
twoj_stary_pijany napisał(a):
Kanban nie jest metodą agile'ową. Kanban jest metodą Lean. Optymalizuje inne rzeczy.
No niemniej jednak w świecie inżynierii oprogramowania jest powszechnie zaliczana do metod agile'owych.
Prawdopodobnie dlatego, że jest zdecydowanie bardziej zwinna niż tak powszechnie forsowany scrum, czyli ciężka metodyka sprzeczna z Manifestem.
Nie wiem gdzie to wyczytałeś, ale chyba powinieneś wrócić do źródeł. Agile jest metodologią skupiającą się na interakcji z klientem i tym, żeby robić to za co klient płaci, a nie zamykać się w piwnicy na pół roku z kontraktem i po tym czasie pokazywać klientowi, że jest głupi bo naiwnie skonstruował umowę, a my to wykorzystaliśmy. W metodologii Agile podpisując umowę na produkt X można dostarczyć produkt Y bo w trakcie dostarczania produktu klient może pod wpływem ekspertyzy zleceniobiorcy zgodzić się na inną ścieżkę rozwoju produktu, ale jesteśmy na tyle elastyczni, że zachowując odpowiednie kontakty z klientem jesteśmy w stanie ustalić nowe warunki umowy, w trakcie jej trwania, żeby obie strony wyszły z tego zadowolone.
Metodologia Lean polega na optymalizacji procesu produkcji. Możesz optymalizować zasoby ludzkie lub inne zasoby, żeby zmaksymalizować zysk. Należy też pamiętać o tym, że Lean to nie jest tylko i wyłącznie Kanban i jest to cała filozofia pracy polegająca na ciągłym udoskonalaniu procesu, zaczynając od maszyn, kończąc na samodoskonaleniu.
Mówienie, że Agile i Lean są tożsame to porównywanie jabłek do samochodów.
twoj_stary_pijany napisał(a):
Ja jestem zwolennikiem tego, żeby na drodze między mną, a innymi było jak najmniej osób i większość rzeczy staram się załatwiać sam. Natomiast pewne osoby celowo chowają się w piwnicach i utrudniają kontakt, wtedy warto poprosić Scrum Mastera o reakcję, żeby pomógł nam zorganizować takie spotkanie
Od spotkań mających znaczenie dla projektu jest PM
warto mieć dobrego Scrum Mastera w firmie, którego można poprosić o pomoc, żeby przeszkolił kolegów jeżeli ktoś stwierdzi, że jest taka potrzeba
Przeszkolił w zakresie odpowiadania na maile? Wiązania sznurówek i mycia kubków też?
SM to rola - wydmuszka. Na papierze wygląda super - człowiek orkiestra. W realiach niestety jeśli ta rola jest pełniona przez osobę spoza zespołu projektowego to:
twoj_stary_pijany napisał(a):
Mówienie, że Agile i Lean są tożsame to porównywanie jabłek do samochodów.
Nie napisałem, że są tożsame, tylko że Kanban jest zaliczany powszechnie do praktyk agile'owych. Powszechnie, przez specjalistów od Agile. Więc jeśli to jest niepoprawne, to tylko świadczy o fetyszystach sruma. :P
Mam tylko nadzieję, że nie używasz kanban boarda. Nie wolno, To nie agile.
Jeśli ktoś twierdzi, że problemy które w Scrumie adresuje SM są sztuczne lub nie występują w ogóle, chyba nie wie o istnieniu świata poza klawiaturą własnego kompa. Jak czytam niektóre komentarze, to łapię się za głowę :)
Charles_Ray napisał(a):
Jeśli ktoś twierdzi, że problemy które w Scrumie adresuje SM są sztuczne lub nie występują w ogóle, chyba nie wie o istnieniu świata poza klawiaturą własnego kompa. Jak czytam niektóre komentarze, to łapię się za głowę :)
No, problemy do których adresował Marks też nie były sztuczne. To nie zmienia faktu, że zaproponowane przez niego rozwiązanie było średniawe.
Ja się łapię za głowę, gdy czytam o adresowaniu problemów.
Weźcie zdajcie wreszcie matury, bo nie da się dyskutować z takim poziomem znajomości języka polskiego.
Praca w zespole to ewentualne problemy międzyludzkie. Nie unikniesz tego, czysta biologia. Scrum Master w tym momencie się przydaje, jako obiektywny arbiter. Z praktyki