On 12/21/2011 06:40 PM, Andrzej Jarzabek wrote:
> 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.

O kurde. Mamy inne doświadczenia.

>
>> 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. Scrum, CI, reszta bardzo różnie. Podobno
ze swoimi 30MLOC doszli do cyklu godzinnego CI i drugiego "przez noc".
Pomijam już, że na poziomie gry słów Agile + 30MLOC = zwinne sterowanie
lotniskowcem.

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

To w specyficzny sposób wspiera tezę z mojego pierwszego posta: dzięki
Agile odkryliśmy abstrakcję API. Kiedyś odkryjemy, że API to jeszcze nie
wszystko i warstwy muszą działać razem. I różne techniki
testowania, też dzięki Agile. Oh, well.

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

Większość znam nie z własnych doświadczeń; są kołchozy i kołchozy.

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

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

Edek