Ithink.pl - Dziennikartstwo Obywatelskie
Pierwsze badania na temat programowania w parach
dodano 02.01.2009
Od przeczytania książki Agile - Programowanie zwinne jestem fanem programowania zwinnego, programowania w parach, programowania ekstremalnego itp. Dlaczego tylko fanem?
Kiedyś szukałem jakichś badań. No ale jak się okazało, była to wtedy jeszcze za młoda dyscyplina żeby wspierać się badaniami. Jednak dzisiaj udało mi się znaleźć dokument dzięki Sir programiście Siddharta. A w jego wpisie znalazłem link do wyników badań opracowanych przez zespół Adrew Begel - Nachiappan Nagappan. Zresztą ciekawe czy ta liczba autorów - 2 wskazuje na to, że publikacja też została napisana zwinnie? :)
Nim przejdę do wniosków z badań jeszcze może napiszę, co to jest programowanie w parach. W książce powyżej jest nawet przydługawy przykład tej metody. W skrócie wygląda ona w ten sposób: 1 monitor, jedna klawiatura, jedna mysz, dwóch programistów. Oszczędności na sprzęcie i oprogramowaniu? Autorzy metodologii agile uważają, że nie tylko :) Uważają, że w myśl zasady “co dwie głowy to nie jedna” takie programowanie jest lepsze. Produkuje się więcej funkcji, mniej błędów i nie można iść sobie na skróty.
Wyniki badań zawierają kolorowe wykresy. Kolory czerwone to odpowiedź: TAK, a niebieskie: NIE. Biały to neutralny. Programiści po sesjach w parach są pytani jak oceniają programowanie w parach i czy popierają argumenty twórców metodologii.
Pierwszy rzut oka na wykresy: dużo osób nie widzi różnicy (dużo białego), ale przewaga tych na TAK jest dosyć duża nad tymi na NIE. Efekt “nowości” pewnie tutaj działa. Hype na takie programowanie przecież działa i ma wpływ na takie wyniki. A liczba osób, które nie widzą różnicy, mówi sama za siebie.
Dosyć dużo osób jest przekonanych że przez programowanie w parach powstaje mniej błędów. Tu bym się zgodził. Lepiej się programuje kiedy ktoś Ci pomaga. I masz się kogo zapytać. To jest tak, że jak samemu się wejdzie już w jakiś projekt, to po paru miesiącach samotnego pisania kodu nie ma już nawet kogo się poradzić, jak nie siebie. Dokumentacja idzie na bok a projektowanie ginie gdzieś między terminem końcowym a jakością.
W konsekwencji programista zostaje sam ze wszystkimi problemami i całą odpowiedzialnością. Taka sytuacja nigdy nie odbija się dobrze na jakości. Dlatego programowanie w parach ma tutaj tą przewagę, że wszystko jest podzielone na 2. Odpowiedzialność, znajomość zagadnień itd. Masz kogo się zapytać i poradzić. Widać tutaj, że metodologia Agile jest dosyć praktyczna: wszystko inne może nawalić, ale wciąż 2 osoby w teamie wiedzą dokładnie o co chodzi w projekcie.
DODAJ SWÓJ KOMENTARZ
REKLAMA
ARTYKUŁY O PODOBNYM TEMACIE
zobacz więcej
5 NAJLEPIEJ OCENIANYCH ARTYKUŁÓW