On Dec 21, 7:26 pm, Edek <e...@g...com> wrote:
> On 12/21/2011 06:40 PM, Andrzej Jarzabek wrote:
>
> > 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.
>
> O kurde. Mamy inne doświadczenia.

Moje doświadczenie w ogóle jest takie, że "architekt" znaczy różne
rzeczy w różnych organizacjach.

Natomiast jeśli masz coś do powiedzenia na temat swoich doświadczeń w
kwestii tego, co napisałem, to nie krępuj się i wal prosto z mostu.

> >> 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?
>
> 30MLOC to ile osób? Tak naprawdę to źle użyłem słowa zespół: dział,
> albo i większa struktura.

No więc to trochę jakby robi różnicę. Dla uwagi jeszcze należałoby
ustalić, czy te 500 osób to programiści lub zespoły developerskie
złożone głównie z programistów, czy wliczają się w to też supportowcy,
obsługa data centre, handlowcy, office management i tak dalej.

> > 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.
>
> To w specyficzny sposób wspiera tezę z mojego pierwszego posta: dzięki

Nie mam pojęcia o jaką tezę ci chodzi. Możesz przypomnieć?

> Agile odkryliśmy abstrakcję API. Kiedyś odkryjemy, że API to jeszcze nie
> wszystko i warstwy muszą działać razem.

Kiedyś może odkryjecie, że do tego właśnie służy abstrakcja API.

> Dziękujemy o Agile za odkrycie warstw abstrakcji i testów. Ja tu nie
> widzę żadnej różnicy pod względem metodyki, ale to pewnie zależy od
> punktu, z jakiego się startuje zmieniając religię na zwinniejszą.

Różnicy między czym a czym?