Pierwsze badania na temat programowania w parach
Pierwsze badania na temat programowania w parach
autorem artykułu jest Tomasz Smykowski
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 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.
Przy okazji chciałbym zwrócić uwagę na temat wiedzy na temat projektu. Programowanie to nie budowanie domu. Budowa domu składa się z 2 wydzielonych części: projektu i budowy (z grubsza). Kiedy masz już projekt domu możesz go powierzyć każdemu budowlańcowi z odpowiednim doświadczeniem, a on w każdej chwili dokończy budowę. Tj. jeżeli jeden nawali, możesz go zwolnić, a inny go poprawi i zbuduje do końca.
W programowaniu… no cóż. Jeżeli mamy 2 części: projekt i budowa, to wszystko jest ok. Natomiast kiedy zespół nie ma już czasu na zakładanie pasów bezpieczeństwa może zdarzyć się wszystko! Jeżeli główny programista danej podgrupy zachoruje albo odechce mu się pracować, projekt leży. No więc warto sobie uświadomić że agile zabezpiecza przed taką sytuacją. Więc akceptując wszystkie wady programowania, można zaprosić Agile i dać mu szansę.
W treści raportu poza wykresami są też tabelki. Przytoczę parę ciekawych wyników.
Po pierwsze, odpowiedzi na pytanie na co wpływa programowanie zwinne (agile, w parach, ekstremalne itp.):
1. mniej błędów
2. rozprzestrzenia zrozumienie kodu
3. wyższa jakość kodu
4. można nauczyć się czegoś od partnera
5. lepszy projekt
6. ciągła analiza kodu
7. dwie głowy to nie jedna (a nie mówiłem ;)
8. kreatywność i burze mózgu
9. lepsze testowanie i debugowanie
10. zwiększone morale
Po tych wynikach można założyć Greenpeace programistyczne i zorganizować pikiety przed firmami informatycznymi, które zmuszają programistów do pracy nie-Agile. Ale zaraz, zaraz. Jeszcze są wymienione minusy programowania Agile:
1. Koszty
2. Czas
3. Rozdwojenie jaźni ??? (personality clash)
4. Nieporozumienia
5. Różnica umiejętności
6. Różnice w stylu programowania
7. Trudno znaleźć partnera
8. Indywidualne różnice stylu
9. Rozproszenia
10. Mizantropia
11. Zła komunikacja
12. Ciężko rozdzielić nagrody
Ok, zwinąć jednak te transparenty? Pikiety nie będzie?
Może jednak nie. Wszystko oprócz 1 i 2 punktu może być efektem zmuszania programistów do pracy w niehumanitarnych warunkach. No, nie oszukujmy się, ile czasu spędzasz w pracy przed komputerem a ile przed drugim człowiekiem. Niehumanitarne = mało kontaktu z innymi ludźmi. Nie będę bronił tej teorii, pewnie i tak pojawi się parę osób, które napiszą że mają dużo kontaktu i że ich praca taka nie jest. Ok, ale nie piszę o wyjątkach ale o regułach. Regułach, które trzeba rewidować i naprawiać.
A żeby naprawiać potrzebnych jest jeszcze więcej badań, mnie brakuje takich jak nad tym zdziczałym chłopcem. Pamiętacie historię tego chłopca, który wychował się w dżungli? No, to właśnie o takie badania mi chodzi. Badania nad zespołem który powstał ze studentów, którzy od razu po studiach zaczęli pracować według metodologii Agile. Pracują 10 lat, a po tym czasie robi się badania. Badania dadzą wtedy wyniki bez całego tego nakładu złych przyzwyczajeń i nawyków, które nabywa się w pracy.
Niestety przytoczone badania takie nie są, są za to jak badanie zadowolenia pani Gertrudy z księgowości 2 dni po przeinstalowaniu jej Windowsa XP na Windowsa Vista, a Office’a z 2000 na 2007 :).
Reasumując: badania ciekawe i jedne z pierwszych i czekam na kolejne. Zachęcam też do samodzielnego zapoznania się z dokumentem. Ten wpis jest tylko przyczynkiem do napisania paru słów przemyśleń i dyskusji.
--
Źródło: polishwords.com.pl/blog
Autorem artykułu jest Tomasz Smykowski. Programista, twórca strony Polishwords oraz Ulubiona Książka. Prywatnie miłośnik muzyki punk, rock i klasycznej.
Artykuł pochodzi z serwisu www.Artelis.pl
Zobacz takze:
Jak napisać dobre CV.
Postanowienia noworoczne, jak sprawić żeby działały na
Programy partnerskie receptą na sukces.
Lecz się muzyką
Pokaż mi swój pulpit a powiem Ci kim jesteś!