On 17/12/2011 22:43, A.L. wrote:
>
> Nie ma sie Pan co obawiac. To jest "metodologia Agile". Ponoc jedynie
> sluszna.
>
> Ciekawe jak "agilowcy" wyobrazaja sobie projekt w ktorym pracuje,
> powiedzmy, 50 programistow, i owi programisci nigdy nie kontaktuja sie
> z przyszlym uzytkownikiem systemu?

Po pierwsze, nie ma czegoś takiego jak "metodologia Agile". Można
ewnetualnie rozpatrywać konkretne metodologie jak XP czy Scrum, albo
zastanawiać się nad ogólnym podejściem Agile do tego tematu - ale w tym
drugim przypadku trzeba wziąć pod uwagę, że istnieją metodologie czy
procesy, które mieszczą się nadal w ogólnym nurcie Agile, ale stosują
pewne rozwiązania spoza tego nurtu.

Więc po pierwsze temat kontaktów z przyszłym użytkownikiem: generalnie
nie jest konieczny. XP zaleca, żeby w miarę możliwości "on-site
customer" był przedstawicielem typowego użytkownika systemu, ale nie
jest to jedyna możliwość. Podstawą jest to, żeby ludzie występujący w
rolach "customer representative" albo "product owner" rozumieli potrzeby
użytkownika, ewentualnie mieli możliwość szybkiego dowiedzenia się jakie
one są w szczególnym przypadku.

Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
je zastosować do większych projektów, pod warunkiem, że da się podzielić
zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
(komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,
albo ma się zespół zajmujący się integracją systemu i ten zespół pracuje
z końcowym klientem i podaje wymagania zespołom wykoującym poszczególne
komponenty. Czasem jest to niemożliwe albo niepraktyczne, i w takich
sytuacjach po prostu nie należy stosować tych metodologii.