!FrAgile Thinking

Ostatnio wywiązała się bardzo ciekawa dyskusja na liście mailingowej altdotnet na temat doświadczeń związanych z programowaniem w parach. Wszystkie osoby zainteresowane tą praktyką zachęcam do przeczytania wątku poświęconego tej dyskusji.

Najbardziej interesującym aspektem w zamieszczonych wypowiedziach jest zgodność co do tego, że programowanie w parach nie jest złotym środkiem i nie warto programować w parach przez cały czas pracy, bowiem występują czasami zadania na tyle łatwe, że programowanie w parach jest po prostu nieefektywne. Patrząc na zamieszczone w wątku przykłady, takie jak tworzenie prostych widoków, wydaje mi się to bardzo rozsądnym argumentem.

Poruszony został także temat ping pong programming, o którym pisałem także w poprzednim poście. Jak widać z wypowiedzi, wiele osób chwali sobie wykorzystanie tej praktyki w celu nauczania w zespole TDD, które nie tylko moim zdaniem jest bardzo trudne w obyciu i wymaga dłuższego okresu nauczania.

Jimmy Bogard wspomniał również o wykorzystaniu par w procesie projektowania. Z mojego doświadczenia wynika, że jest to bardzo skuteczna metoda. Należy jednak zwrócić uwagę na to, że projektowanie w metodologiach zwinnych eliminuje tak zwanny “upfont design” poprzez  nieustanne  projektowania. Stosując więc projektowanie w parach każda para rozpoczynając implementację kryterium akceptacyjnego tzw. “user story“, korzystając na przykład z UMLa, może wyznaczyć i przedyskutować proponowaną przez nią architekturę. Największą zaletą tego rozwiązania moim zdaniem jest to, że zostaje wymuszany proces projektowania, które często zostaje pomijane w przypadku, gdy nad danym zadaniem pracuje tylko i wyłącznie jedna osoba. Poza tym mam nadzieję, że każdy jest świadom tego, “że co dwie głowy to nie jedna” i w efekcie końcowym zapewnia to, w stosunkowo krótkim czasie, powstanie “lepszej” architektury. Projektując w parach żadna z zaangażowanych osób się nie nudzi, o czym nie zawsze można powiedzieć w przypadku większej liczby osób. Oczywiście występują również sytuacje, w których wymagany jest udział większej liczby osób, gdyż dyskutowane rozwiązanie nie dotyczy tylko jednego kryterium akceptacyjnego. Tych faz projektowania jest jednak stosunkowo mało.