Longflow - anty-scrum

https://github.com/Nax/longflow-manifesto/blob/master/README.md

Co sądzicie?

Dobre, ale może zadziałać tylko jeśli firma robi produkt, a nie usługę.

Jest też pewne ryzyko, że programiści będą w nieskończoność ulepszać kod dążąc do perfekcji i nigdy nie zrobią kolejnego wydania.

Eh.. Mam wrażenie że powstało jako wyraz frustracji źle zarządzaną firmą pod płaszczykiem metodyki wytwórczej Scrum. Ogólnie niedobre i długo by mówić czego nie uwzględnia. Poza tym Scrum to nie jest remedium na wszystkie problemy świata :-/

Bez estymowanych czasów programiści mają tendencję do opierdalania się. Taka metodologia może by miała sens w "młodym, dynamicznym zespole" ale raczej nie z seniorami, którzy i tak często opierdalając się zrobią daną rzecz szybciej niż ambitni młodzi.

W scrumie i tygodniowych sprintach podoba mi się to, że jednak jest widoczny progress w postępie projektu i daje to jakieś poczucie posuwania się do przodu. Kwestia dobrego przygotowania tasków. Co tydzień aktualny sprint się czyści i widać co wyszło / co nie wyszło ile dodatkowych bugów weszło. Średnio przy estymacjach dodaję do niej 20% na bugi i do tej pory to się sprawdza. Klienci gratulują i chwalą terminowości.

problem w tym, że u nas Scrum często jest traktowany jak te spotkania coachingowo sprzedażowe, jest super fajnie, jesteśmy zespołem, jesteśmy najlepsi jest super więc o co ci chodzi
natomiast Scrum nie sprawdzi się w każdym projekcie i w każdym zespole, nie z każdym managerem, masterem, często wręcz wprowadza niepotrzebny stres, bo przecież na codziennych czy tygodniowych spotkaniach musisz się wykazać często "na siłę" i często to wygląda jak jakieś biedne callcenter ze jakimiś prezentacjami historyjkami i taki logiczny, dorosły człowiek zastanawia się "co ja tutaj do wuja robię?"
Scrum to był zbiór luźnych zasad a nie pismo święte o tym też należy pamiętać ;)

Co do szacowania - szacowanie trzeba robić mądrze.

Taski co najwyżej można podzielić na:

1. trywialne (np. literówka w helpie albo coś nie może znaleźć pliku, bo jest źle podana ścieżka itp. - zwykle programisa widząc tytuł błędu od razu wie, gdzie szukać i co popsuł)
2. średnie / nudne - programista wie mniej więcej co trzeba zrobić i jak, tylko musi to zakodować, przy czym robił podobne rzeczy wcześniej (np. naklepać nową formatkę, albo dodać nowe pole do istniejącej formatki)
3. trudne - programista nie wie w ogóle co trzeba zrobić albo nie wie jak to zrobić i musi dopiero się nauczyć / zapytać na 4p albo zdebugować (pod to podpdają też wszelkie błędy w stylu "dzieje się tylko podczas prezentacji u klienta")
4. długie, choć niekoniecznie trudne - wiadomo co i jak trzeba zrobić, ale wiadomo, że spowoduje to trzęsienie ziemi w projekcie (np. zmiana modelu bazy danych, jakiś większy refaktoring)

Zadania typu 1. i 2. są dość proste w szacowaniu. 3. jest niemożliwe do oszacowania bez posiadania kryształowej kuli, 4. wiadomo że zajmie bardzo dlugo, ale nie wiadomo, ile rzeczy po drodze popsuje, więc należy je traktować jako "długo do bardzo długo, a może nigdy".

Ja zawsze tak to przedstawiam managerom i nigdy nie miałem problemów. Natomiast nigdy nie mówię, że coś mi zajmie np. tydzień, a coś innego godzinę, bo to prawie nigdy nie działa i później wszyscy są wkurzeni - manager, że świeci oczami przed swoim przełożonym, a programista, że zawiódł managera.

BTW: My mamy w trackerze specjalny stan każdego ticketu nazwany "triage", gdzie właśnie oceniamy wstępnie trudność ticketu, zanim ktoś się zobliguje do wykonania. Wtedy też można zaplanować do której wersji coś wchodzi.