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ł
  • Odpowiedz
@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.
  • Odpowiedz
@AshByeBye: U mnie w kontraktowniowym scrumie mamy fixed scope umowy z klientem xD
Dodajmy do tego że w proces ktoś wcisnął project managera i w ogóle dostaje się cyrk na kółkach. W wyniku tego scrum master staje się sekretarką od spisywania notatek z niepotrzebnych spotkań. No ale można przylepić nalepkę "so much edżajl wow"
  • Odpowiedz
@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ł
  • Odpowiedz
@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
  • Odpowiedz
@yhbgrobdoivbvwamsv: do izolacji to bym się po części przyczepił bo zespoły powinny być transparentne ale niezależne. :)


@shpoora: Izolacja to może złe słowo, chodziło mi dokładnie o to co napisałeś.
Po prostu zaczęto widziałem scrum jako daily + darcie ryja co dwa tygodnie ze coś co sobie góra wymyśliła nie jest zrobione.
  • Odpowiedz
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).
  • Odpowiedz
@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".
  • Odpowiedz