🚀 go-pugleaf

Dnia Wed, 01 Mar 2006 20:28:19 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> > Dnia Wed, 01 Mar 2006 08:25:32 -0600, A..L. skrobie:
> >
> >> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany.
> >
> > W to nie wątpię.
> >
> > W wychwalaniu vattenfalla nie należy też zapominać, że częściej jest
> > obchodzony, niż stosowany.

> Waterfall wyklucza zrównoleglenie prac.

Zrównoleglenie prac to przede wszystkim wykluczają zależności poszczególnych
czynności wykonywanych w projekcie.

Zatem to, ile uda nam się zrównoleglić, zależy od tego, jak wyglądają
zależności poszczególnych czynności. Można oczywiście zmniejszać zależności,
ale to może przy braku dobrej ekspertyzy prowadzić to powiększania "rozkurzu"
(czynności, których efekty bezpośrednie pójdą do kosza).

Jeśli np. założymy, że musimy miec w całości wykonany projekt i dopiero
zabieramy się za implementację (mówię o projekcie wysokiego, a nie niskiego
poziomu, oczywiście), to tych czynności zrównoleglić, jak wiadomo, nie można,
ale to właśnie z uwagi na zależności. Natomiast nikt nam nie każe robić
projektu implementacji jako konkretnego etapu. Takie coś może być robione np.
poprzez komentarze doxygenowe lub projektowanie schematyczne z generacją kodu.
Wtedy kod istnieje równolegle z dokumentacją.

Podobnie, tworzenie implementacji nawet jednego modułu, czy obszaru
funkcjonalnego można skutecznie rozłożyć na kilka osób, jeśli jest się w
stanie wyznaczyć rozkład zależności. Jeśli ktoś tego nie potrafi wyznaczyć, no
to trudno - sadzamy jednego człowieka, który sam to wszystko pisze. Jeśli
potrafimy, to wtedy jeden gościu pisze tylko krótki plik z interfejsem, i
spokojnie dwóch ludzi może pisać oddzielnie kod z tego samego obszaru
funkcjonalnego, tylko po prostu inne fragmenty kodu.

Taki projekcik zresztą prowadziłem ostatnio osobiście. Problem był
następujący: na otrzymane żądanie od odpowiedniego "serwera", zapytać wskazane
urządzenie o liczbę używanych obiektów i ich konfigurację, po czym wysłać je
z powrotem do serwera. Ja pisałem część związaną z odebraniem żądania i
wysłaniem wyników, a kolega pisał część związaną z wysłaniem żądania do
urządzenia i odebrania odpowiedzi (kod na drugim urządzeniu to już pisał
gościu zza bajora i woleliśmy na niego poczekać z uwagi na tzw. problemy
komunikacyjne i czasostrefowe) i przekazania mi jej. Określiliśmy tylko
interfejs tej funkcji, która miała się tym zajmować, oraz używane struktury. I
tyle było naszego "pair programming"; potem ja pisałem otoczkę, odebranie
danych i ich sformatowanie, a on implementację. Interfejs oczywiście się
zmieniał (klient trzykrotnie zmieniał wymagania w międzyczasie, albo o
niektórych sprawach nie pomyśleliśmy) - nie stanowiło to problemu; dzwonię do
gościa i mówię: potrzebna jest taka-a-taka zmiana w interfejsie. Potem szybka
synchronizacja, znów 5 minut na "pair programming" i spowrotem split.
Projekcik trwał raptem trzy tygodnie a zmian w interfejsie było dokładnie 1.

Kwestia zastosowania vattenfall nie ma tu nic do rzeczy - pod warunkiem
oczywiście, że proces nie ma wpisane na sztywno np. tego, że do każdej
najdrobniejszej pierdoły (typu dodanie 10 linijek kodu) wymagany jest
"dizajn", a bez dizajnu nie ruszamy z miejsca, a po przebramkowaniu dizajnu
dizajn jest nietykalny aż do zakończenia przedsięwzięcia.

> W sumie najlepszy model to
> ten, który dobry menedżer zaprojektuje do konkretnego przedsięwzięcia.
> Jak mawia mój obecny szef, 'jak coś jest do wszystkiego, to jest 
> do niczego'.

Bardzo słusznie mówi.

Zarówno vattenfall, jak i ajil mogą być takimi "wzorcami procesów", z których
proces oficjalny może czerpać tyle, na ile uważa to za stosowne. Nie ma to jak
proces autorski. Ale żeby taki proces zrobić, trzeba się na jakimś wzorcowym
procesie oprzeć - a trzeba przyznać, vattenfall to jest jednak jedyny proces,
którego definicję można uważać za "stabilną" - a także trzeba mieć swój własny
"proces ulepszania procesu". Tzw. "Quality" powinno się zatem zajmować nie
tylko tym, czy proces jest dotrzymywany, ale również wszelkimi zgłoszeniami
opinii i wniosków nt. tego, jakie czynniki utrudniają wykonywanie czynności
związanych z danym projektem, co utrudnia ludziom pracę, jak można by to
ulepszyć. Proces nie jest kodeksem absolutnym, tak samo jak prawo nie jest
prawem absolutnym; jeśli jest złe, to trzeba je zmienić.

Problem w tym, że to wymaga wielu istotnych czynników: procesu ulepszania
procesu oraz posiadania pomysłowych i "twórczo-leniwych" ludzi w zespole.
Proces ulepszania procesu nie jest trudny do napisania, tylko trzeba chcieć to
zrobić, a ludzi "twórczo-leniwych" wcale nie jest mało, tylko trzeba chcieć
ich słuchać. Z tą chęcią jest niestety zwykle mizernie.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"