On 12/19/2011 02:16 PM, Andrzej Jarzabek wrote:
>> > 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.

Jaka jest rola architektów w Agile? Pytam, bo nie wiem.

Co do dużych zespołów - x >> 50, powiedzmy 500 - też się stosuje Agile,
nie ma takiego wymagania, żeby komponenty były autonomiczne. To znaczy,
w pewnej mierze są: projektuje się na różnych poziomach (to chyba
te skróty LLD, HLD), programista zazwyczaj też projektuje to, co ma
napisać, tyle, że tak się tego zazwyczaj nie określa. Więc nawet nie
jeden team to projektuje, każdy swoje i wespół w zespół, przynajmniej z
takim modelem się zetknąłem, pomimo tego, że role są jak najbardziej
określone. A Agile wydaje mi się pod tym względem słaby.

Mam wrażenie, że dyskusja jest pomiędzy "projektem określającym
sekwencję ruchów palców programisty" a Agile, co jest trochę bez sensu.
Bez sensu imo jest też to:

> 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ć.

Z mojego doświadczenia właśnie tak nie należy robić. To jakaś epoka
kamienia łupanego. Projekt można wyrazić słowami, UMLem, rysunkami,
czymkolwiek, można wyrazić zarówno ogólną konstrukcję, jak i niektóre
rzeczy bardzo szczegółowo, jeżeli jest taka potrzeba. Nie czaję,
dlaczego musi być "tylko szkic komponentów i koniec" i zero
elastyczności. Akurat pod tym względem dla mnie nie ma żadnej różnicy,
czy to Agile czy Up Front, to raczej kwestia kultury organizacyjnej,
rozumienia ról swoich i innych.

Edek