Wpis z mikrobloga

  • 4
@OpowiedzMiCos:

Dla mnie jest to fenomen, który obserwuję po rozmowach w korporacjach z programistami, wypowiedziach po forach, konferencjach.

Sprinty, które z założenia miały służyć programistom i usprawniać ich pracę, stały się narzędziem do swego rodzaju uciemiężania ich. Mam nadzieję, że jakieś prace naukowe na ten temat powstaną, a za 50 lat ludzie o tym będą czytać w książkach.
  • Odpowiedz
Sprinty, które z założenia miały służyć programistom i usprawniać ich pracę, stały się narzędziem do swego rodzaju uciemiężania ich


@Ksiega_dusz: sprinty stawiają na minimalizację wydajności programistów kosztem dowiezienia konkretnej funkcjonalności na koniec iteracji. Ma to sens, gdy nie wiemy co robić i bardzo liczymy na feedback klienta

W większość przypadków nikt nie dba o feedback klienta (albo klient nie wie co chce), tylko o wydajność pracy, więc scrum to po
  • Odpowiedz
sprinty stawiają na minimalizację wydajności programistów kosztem dowiezienia konkretnej funkcjonalności

@Saly: jeśli programiści nie dowiozą konkretnej funkcjonalności, to ich wydajność jest równa 0 ( ͡° ͜ʖ ͡°)

Problem ze zwinnymi metodykami jest inny. One w założeniu miały dać programistom niezależność - przez 2 tygodnie robią to co ustalili z managementem/klientem, a na koniec sprintu pokazują co zrobili, pytają o opinię i wspólnie decydują o dalszych priorytetach.
  • Odpowiedz
@zobq: dlatego użyłem słowa "konkretnej". Może szybciej dowieziesz konkretne taski, ale narzut metodologii i brak możliwości pracy ciągłej obniża wydajność w dłuższym okresie czasu

To problem analogiczny do throughput vs latency problem
  • Odpowiedz