On Dec 19, 12:54 am, bartekltg <b...@g...com> wrote:
> W dniu 2011-12-18 13:14, Andrzej Jarzabek pisze:
>
> > 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,
>
> Jednym słowem, najpierw trzeba wszytko dobrze i poprawnie wszytko
> zaprojektować, następnie do klocków które nam powstały podesłać
> programistów mówiąc 'róbta XP'.

Nie wiem, co rozumiesz przez "dobrze i poprawnie wszystko
zaprojektować". Jeśli "wszystko" oznacza faktycznie wszystko, tzn.
cały system, każdy z jego komponentów, każdy z podkomponentów tych
komponentów i tak dalej przez wszystkie poziomy, to odpowiedź brzmi
"nie". W wielu przypadkach nie potrzebujesz literalnie wszystkiego
(albo nawet w grubym przybliżeniu wszystkiego) projektować, żeby
stworzyć listę czterech czy pięciu "loosely coupled" komponentów, z
których składać się będzie system - a o tylu mowa, skoro dzielimy 50-
osobowy zespół na zespoły maksymalnie 16-osobowe (licząc tylko
programistów), przy czym być może mamy jeden zespół nie tworzący
żadnego komponentu tylko zajmujący się integracją produktu.

Jeśli "wszystko zaprojektować" znaczy "zaprojektować system jako
całość" - bez wdawania się w szczegóły, to tak.

Jeśli według ciebie "zaprojektować dobrze i poprawnie" znaczy "na
najwyższym możliwym poziomie abstrakcji", czyli powiedzmy narysować na
tablicy pięć prostokątów, reprezentujących logiczne komponenty
projektowanego systemu, wypunktować w każdym w kilku punktach po
jednym zdaniu czym te komponenty mają się zajmować, i ewentualnie
połączyć je jakimiś kreskami czy strzałkami oznaczającymi zależności,
to tak, należy "zaprojektować dobrze i poprawnie". Ale też właśnie XP
(i Agile jakoś tam w ogólności) twierdzi, że takie projektowanie jest
właśnie dobre i poprawne i tak należy robić.

Jeśli "zaprojektować dobrze i poprawnie" dla ciebie oznacza co innego,
to przykro mi, nie potrafię odpowiedzieć na to pytanie, bo umiem
czytać w myślach.

> Bo sensowność mi umyka. Zwłaszcza, że wyrzucamy
> pracowicie zrobiony projekt i nie kodujemy wg jego założeń, ale
> wg tego, co druga grupa z nami konsultuje.

Jaki projekt? Jeśli chodzi o ten projekt, na którym narysowano
prostokąt i napisano w nim powiedzmy "interfejs do systemu SWIFT", to
niby dlaczego zespół robiący interfejs do systemu SWIFT miałby go
wyrzucić?

Uprzedzając: zanim napiszesz, że "czasem się nie da bez zrobienia
dużego, szczegółowego projektu, stwierdzić, jak można sensownie
podzielić system na komponenty tworzone przez autonomiczne zespoły",
to odpowiem - być może czasem się nie da. W takich przypadkach po
prostu nie należy stosować XP. Z mojego doświadczenia wynika, że w
bardzo wielu przypadkach się da, a nawet że często jest to i tak
robione, nawet jeśli nie stosuje się żadnej metodologii agile. To
raczej monolityczne zespoły z 50 programistami są rzadkością, nawet
przy tworzeniu względnie dużych systemów.