W dniu 2012-07-24 15:24, AK pisze:
> Użytkownik <l...@g...com> napisał:
>
>> Myślę, że to dobra metodyka, zwłaszcza w zespołach o małym doświadczeniu.
>
> IMHO jest dokladnie odwrotnie.
> Naprawde doswiadczone osoby (mimo wszelakich Agiles i innych SCRUMow)
> zwykle sie dogadaja.
> W zespolach niedoswiadczonych taki kolejny "socjalizm" (niczym GPL:)
> gdzie to deccyduje
> "wiekszosc wyborcza" moze wylac dziecko z kapiela, bo czasenm to wlasnie
> ten jeden
> doswiadczony ma racje, a nie cala "demokratyczna" reszta.

Jest nawet takie założenie w Scrumie - kompetencje zespołu muszą być
wystarczające. Czyli w praktyce - wysokie.

> IMHO jesli juz to SCRUM nadaje sie do utrzymania _juz gotowego wyrobu_,
> czyli mowiac po ludzku - poprawy bledow (bo tu niekedy wprzega sie
> przeintelektualizowane stare metodyki z calym ich nadmiarowym bagazem).
> W tworzeniu nowych powaznych produktow/systemow to cale
> "spryciarstwo" IMHO w szerszej czasowo perspektywie zwyczajnie sie nie
> nadaje.

Z doświadczenia - nie ma znaczenia. Nawet nieco odwrotnie - utrzymywanie
aplikacji, która ma błędy wyskakujące jak diabełek z pudełka,
a dodatkowo kiepsko napisanej (czytaj - trudnej do zmiany) jest
w Scrumie trudne. Z definicji nie da się takich zdarzeń zaplanować,
również planowanie poprawek jest kiepskie, nawet w horyzoncie krótkich
sprintów.

W długiej perspektywie tworzenia projektu - znów z doświadczenia -
okazuje się, że wiele biznesowych "must to have" po miesiącu (na
początku następnego sprintu) okazuje się być już nie takie "must" 8-)
A to znaczy, że nie pisaliśmy kodu do szuflady.

--
Paweł Kierski
n...@p...net