Wpis z mikrobloga

@elf_pszeniczny: Dodatkowo największe łamagi organizacyjne nazywają wtedy to swoje dzieło "skramem", i biedne mirki potem krzyczą, że cała ta zwinność polega na "#!$%@? w sprintach", gdy tak naprawdę żaden z elementów ich "procesu" nie podlega negocjacji ani nawet dyskusji... A jak zapytać potem takiego, gdzie w ich procesie jest miejsce na "transparentność, wgląd i adaptację" to odpalą tylko "z tym scrumem to jak z hehe komunizmem, bo wicie, to nie był
@AshByeBye: Widziałem dosłownie wszystko. Włącznie z przeliczaniem punktów wyestymowanych przez inny zespół na "roboczo-godziny" (ktoś inny estymował, ktoś inny miał wykonać prace, ale według managera estymata się nie zmienia). Przelicznik był "mid robi 2 story pointy na dzień, senior 3". Firma rozliczała z nie spełniania tych wymagań, kończyło się to poważną rozmową z managerem.
@elf_pszeniczny: Dodatkowo największe łamagi organizacyjne nazywają wtedy to swoje dzieło "skramem", i biedne mirki potem krzyczą, że cała ta zwinność polega na "#!$%@? w sprintach", gdy tak naprawdę żaden z elementów ich "procesu" nie podlega negocjacji ani nawet dyskusji... A jak zapytać potem takiego, gdzie w ich procesie jest miejsce na "transparentność, wgląd i adaptację" to odpalą tylko "z tym scrumem to jak z hehe komunizmem, bo wicie, to nie był
@Krolik: głównym celem podejścia każdego agile jest szybkość feedbaku jaki możesz otrzymać od klienta. Im szybszy feedback tym szybciej jesteś w stanie zareagować na zmiany w wymaganiach, które, nie oszukujmy się, zawsze będą.

Niesety większość firm wprowadzając takiego scruma kompletnie zapomina do czego tak naprawdę służy i wykorzystują go do częstrzej weryfikacji pracy dewelopera (często się spotkałem z podejściem gdzie np PO na codziennym daily truje dupe, gdzie daily jest dla
głównym celem podejścia każdego agile jest szybkość feedbaku jaki możesz otrzymać od klienta. Im szybszy feedback tym szybciej jesteś w stanie zareagować na zmiany w wymaganiach, które, nie oszukujmy się, zawsze będą.


@shpoora: W porządku, zgadzam się, że to jest bardzo ważne, ale to można mieć bez scrum. Po prostu można wykonywać robotę po kawałku i spotykać się często z klientem jeśli tylko zachodzi taka potrzeba (np. osiągnięto kolejny kamień milowy).
@yhbgrobdoivbvwamsv: znowu, przecież do tego nie jest potrzebny scrum, tylko management który ma zaufanie do zespołu i pozwala im się zorganizować, zarazem pomagając im priorytetyzować zadania (choć to zwykle developerzy sam świetnie umieją robić jak rozumieją sens biznesowy projektu). Nie pracuję w scrumie ani nawet w kanbanie, a mam niezależność w doborze zadań. Nazywa się to generalnie - "weź kolejne zadanie z backlogu, które uważasz że jest ważne i je zrób".