Pierwsze badania na temat programowania w parach

Programowanie zwinneOd przeczytania książki Agile – Programowanie zwinne jestem fanem programowania zwinnego, programowania w parach, programowania ekstremalnego itp. Dlaczego tylko fanem? Dlatego, że jeszcze za mało jest danych na temat tego jak takie progamowanie sprawdza się w praktyce. Tj. jak by wyglądała praca całkowicie przekształcona na Agile. Dlatego zazwyczaj korzysta się z fragmentów metodologii Agile tak jak zresztą Robert i Micah piszą w swojej książce. Piszą żeby wdrażać te elementy które się da i które się przydają.

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.

Czytaj podobne  Pierwsza aplikacja na GG.pl !?

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.

Czytaj podobne  Miliardy Wycieków Z Aplikacji Facebooka

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

Czytaj podobne  Kiedy nie warto używać DataSet Designera

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.

Przeczytaj też

Najlepsza książka do Pythona Nie wiesz, z jakiej książki/ebooka uczyć się programowania w języku Python? Postanowiłem zrobić zestawienie 10 książek z Heliona na ten temat, abyś mó...
Komplet 28 ebooków i kursów, aby zostać programist... Od jakiegoś czasu dostaję zapytania na temat tego jakie książki, kursy i ebooki polecam. W związku z tym postanowiłem przygotować dzisiaj zestaw, któr...
120 tapet programistycznych za darmo do pobrania Trochę mi się nudziło, więc przygotowałem zestaw 120 tapet dla programistów. Możesz go pobrać. Tapety są w rozdzielczości 1366x768. Podzielone ...
10 fiszek do nauki programowania w Pythonie Uczysz się programowania w Pythonie? Pobierz te 10 fiszek, które ułatwią Ci zapamiętanie funkcji wbudowanych* w Pythona! Programowanie potrafi ...
Napisano w Kolumna Tagi: , , , , , , , , , , , , ,
One comment on “Pierwsze badania na temat programowania w parach
  1. McWolf pisze:

    Polecam artykuły związane z programowaniem w parach na stronie metodyki
    xPrince. Nie są to może jakieś wielkie badania, ale także dają do myślenia. Poza tym polecam zapoznać się z samą metodyką. http://xprince.net/xprince_folder/artyku142y

Menu