On Dec 20, 9:42 pm, Edek <e...@g...com> wrote:
> On 12/19/2011 02:16 PM, Andrzej Jarzabek wrote:
>
> Jaka jest rola architektów w Agile? Pytam, bo nie wiem.

Bez powtarzania disklejmerów po raz dziesiąty: nie jest określona. W
XP w zespole nie ma takiej roli, w Scrum masz rolę "członka zespołu" -
zespół organizuje się sam i podział pracy w zespole wyznaczany jest
wewnętrznie i jeśli sobie taki zespół wytypuje kogoś, do robienia
"architektury" (cokolwiek by to nie znaczyło), to będą mieli.

Oczywiście zespoły agile mogą funkcjonować w kontekście istnienia
architekta poza zespołem - jeśli np. jest kilka zespołów tworzących
różne "produkty", architektem można nazwać kogoś, kto decyduje ite
tych "produktów" ma być i w jaki sposób funkcjonalność będzie dzielona
między nimi, jak również może decydować o rzeczach typu Unix czy
Windows, Oracle czy Sybase itd.

> Co do dużych zespołów - x >> 50, powiedzmy 500 - też się stosuje Agile,

500-osobowy zespół? Stosujący agile? Masz jakieś przykłady? Jakie
metodologie się w tych zespołach stosuje?

> nie ma takiego wymagania, żeby komponenty były autonomiczne. To znaczy,

W XP i XP-podobnych wariantach Scrum jest takie wymaganie.
Oragnizacyjnie, nie może być tak, że zespół nie może zrefaktoryzować
swojego kodu i wywalic np. jakieś funkcje czy klasy, bo inny zespół z
nich korzysta. Każdy komponent musi tylko udostępniać dobrze
zdefiniowane i obwarowane acceptance testami interfejsy, i ci, którzy
korzystają z tych interfejsów to "klienci" danego zespołu.
Implementacja tych interfejsów jest własnością zespołu i zespół musi
mieć na tyle autonomii, żeby sobie tę implementację móc zmieniać
według potrzeb. To miałem na myśli pisząc "autonomiczne komponenty",
oczywiście nie chodzi o to, żeby każdy z nich mógł być używany bez
pozostałych.

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

Może faktycznie jest słaby pod względem działania w 500-osobowym
zespole. W życiu się z takim kołchozem jednak nie spotkałem.

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

Bo w ten sposób pilnujesz tego, żeby projekt na każdym poziomie był
prosty. Żeby np. pilnować abstrakcji w ten sposób, że każdy komponent
projektowany jest w oderwaniu od tego, jakie są jeszcze inne
komponenty. Metoda jest ogólnie taka, że po stworzeniu nieformalnego
projektu (w co sę wlicza również UML) wykonać formalny projekt, który
przyjmuje postać kodu źródłowego programu i testów. Mając w ten sposób
sformalizowany zapis projektu całości, można się zająć projektowaniem
i implementowaniem poszczególnych części.