Programowanie parami: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Infobox update)
 
(LinkTitles.)
Linia 16: Linia 16:




Programowanie w parach jest jedną z podstawowych technik wytwarzania kodu w programowaniu ekstremalnym. Stosujące je zespoły '''organizują pracę w dwuosobowych grupach''' składających się z programistów, którzy siedzą przy jednej stacji roboczej. Zazwyczaj jeden z nich pisze kod a drugi przygląda się temu procesowi. '''Obaj cały czas debatują na temat kodu'''. Pozwala to na '''redukcje błędów''' (cały czas dwie pary oczu szukają nieprawidłowości) '''oraz zmęczenia''' (gdy jeden programista poczuje znużenie, drugi może przejąć pisanie kodu). Tryb pracy w parach pozwala również na '''zwiększenie efektywności''' poprzez ciągłe omawianie pomysłów, co w efekcie powoduje nieustanną burze mózgów. Dodatkową korzyścią jest '''wzajemna kontrola''' pod kątem korzystania z dobrych praktyk (jednej osobie łatwiej jest podjąć decyzje o zastosowaniu nieeleganckiego rozwiązania - na pewno zrezygnuje z niego jeśli inny programista patrzy na jego kod).
[[Programowanie]] w parach jest jedną z podstawowych technik wytwarzania kodu w programowaniu ekstremalnym. Stosujące je zespoły '''organizują pracę w dwuosobowych grupach''' składających się z programistów, którzy siedzą przy jednej stacji roboczej. Zazwyczaj jeden z nich pisze kod a drugi przygląda się temu procesowi. '''Obaj cały czas debatują na temat kodu'''. Pozwala to na '''redukcje błędów''' (cały czas dwie pary oczu szukają nieprawidłowości) '''oraz zmęczenia''' (gdy jeden programista poczuje znużenie, drugi może przejąć pisanie kodu). Tryb pracy w parach pozwala również na '''zwiększenie efektywności''' poprzez ciągłe omawianie pomysłów, co w efekcie powoduje nieustanną burze mózgów. Dodatkową korzyścią jest '''wzajemna [[kontrola]]''' pod kątem korzystania z dobrych praktyk (jednej osobie łatwiej jest podjąć decyzje o zastosowaniu nieeleganckiego rozwiązania - na pewno zrezygnuje z niego jeśli inny programista patrzy na jego kod).


== Historia ==
== Historia ==
Linia 22: Linia 22:
Z biegiem lat większa liczba osób zgłębiała to pojęcie aż do roku 1995, kiedy to Larry Constantine wprowadził termin "Dynamic Duos" a Jim Coplien napisał o programowaniu w parach. Termin przyjął się powszechnie od momentu pojawienia się manifestu agile..
Z biegiem lat większa liczba osób zgłębiała to pojęcie aż do roku 1995, kiedy to Larry Constantine wprowadził termin "Dynamic Duos" a Jim Coplien napisał o programowaniu w parach. Termin przyjął się powszechnie od momentu pojawienia się manifestu agile..
<google>t</google>
<google>t</google>
== Rotacja członków zespołów ==  
== [[Rotacja]] członków zespołów ==  
Rotacja par jest często używaną praktyką w projektach ze średnimi lub dużymi zespołami. W niektórych przypadkach bardziej wydajnym sposobem jest podział na programistę wiodącego, który cały czas zajmuje się tym samym zadaniem oraz programistę pomocnika, który przesiada się co jakiś czas do innych programistów wiodących (te role także, po zakończeniu zadania, można zamieniać).  
Rotacja par jest często używaną praktyką w projektach ze średnimi lub dużymi zespołami. W niektórych przypadkach bardziej wydajnym sposobem jest podział na programistę wiodącego, który cały czas zajmuje się tym samym zadaniem oraz programistę pomocnika, który przesiada się co jakiś czas do innych programistów wiodących (te role także, po zakończeniu zadania, można zamieniać).  
Zaletami takiego podejścia są:
Zaletami takiego podejścia są:
Linia 32: Linia 32:
Programowanie w parach jest efektywne tylko w przypadku, kiedy przestrzeń pracy zorganizowana według poniższych wytycznych:
Programowanie w parach jest efektywne tylko w przypadku, kiedy przestrzeń pracy zorganizowana według poniższych wytycznych:
* swobodna i komfortowa możliwość obsługi klawiatury oraz myszki przez jednego programistę, podczas gdy obaj programiści tak samo dobrą widoczność na kod. Zaleczany jest taki układ, który w przypadku zmiany programisty wiodącego pozwala na podanie klawiatury i myszki a nie wymusza przesiadanie się,
* swobodna i komfortowa możliwość obsługi klawiatury oraz myszki przez jednego programistę, podczas gdy obaj programiści tak samo dobrą widoczność na kod. Zaleczany jest taki układ, który w przypadku zmiany programisty wiodącego pozwala na podanie klawiatury i myszki a nie wymusza przesiadanie się,
* przestrzeń prowokująca kontakt pomiędzy parami programistycznymi (jest to efekt oczekiwany) - w takiej sytuacji układ stanowisk pracy ułatwia kontakt wizualny oraz głosowy bez potrzeby przemieszczenia się
* przestrzeń prowokująca kontakt pomiędzy parami programistycznymi (jest to efekt oczekiwany) - w takiej sytuacji układ stanowisk pracy ułatwia kontakt wizualny oraz głosowy bez [[potrzeby]] przemieszczenia się


== Tworzenie par ==
== Tworzenie par ==
Każdy z programistów może zostać sklasyfikowany jako ekspert lub początkujący. W zależności od konfiguracji stwarza to pewne szanse oraz ryzyka:
Każdy z programistów może zostać sklasyfikowany jako ekspert lub początkujący. W zależności od konfiguracji stwarza to pewne [[szanse]] oraz ryzyka:
* Początkujący - Początkujący - Jest zalecany do stworzenia łatwej części kodu. Pozwala na naukę dla obu programistów - tym bardziej efektywną im bardziej odległe są obszary, które programiści pokrywają swoją wiedzą. Jest to metoda pozwalająca na ograniczenie nadzoru nad wdrażającymi i uczącymi się programistami, ale nie na jego eliminację.
* Początkujący - Początkujący - Jest zalecany do stworzenia łatwej części kodu. Pozwala na naukę dla obu programistów - tym bardziej efektywną im bardziej odległe są obszary, które programiści pokrywają swoją wiedzą. Jest to [[metoda]] pozwalająca na ograniczenie nadzoru nad wdrażającymi i uczącymi się programistami, ale nie na jego eliminację.
* Ekspert - Początkujący - Jest najlepszym sposobem na wdrożenie nowego programisty oraz szybkim sposobem podnoszenia jego kwalifikacji. Często postrzegana jest jako marnotrawienie czasu eksperta, natomiast im częściej początkujący wskazuje możliwe błędy eksperta, ten zaczyna przekonywać się do takiej formy pary. Dodatkowo początkujący może wprowadzić świeże spojrzenie na prace, która musi zostać wykonana. Warunkami, pod jakimi taka para ma możliwość zadziałać są: cierpliwość oraz chęć nauczania eksperta, nieprzerośnięte ego eksperta, które pozwala na słuchanie początkującego. Z drugiej jednak strony, początkujący programista może być za mało pewny siebie.  
* Ekspert - Początkujący - Jest najlepszym sposobem na [[wdrożenie]] nowego programisty oraz szybkim sposobem podnoszenia jego kwalifikacji. Często postrzegana jest jako marnotrawienie czasu eksperta, natomiast im częściej początkujący wskazuje możliwe błędy eksperta, ten zaczyna przekonywać się do takiej formy pary. Dodatkowo początkujący może wprowadzić świeże spojrzenie na prace, która musi zostać wykonana. Warunkami, pod jakimi taka para ma możliwość zadziałać są: cierpliwość oraz chęć nauczania eksperta, nieprzerośnięte ego eksperta, które pozwala na słuchanie początkującego. Z drugiej jednak strony, początkujący programista może być za mało pewny siebie.  
* Ekspert - Ekspert - Jest to najlepszy wybór w przypadku skomplikowanych problemów lub takich, w przypadku których defekt kodu powoduje błędy krytyczne. Ten rodzaj pary powoduje znaczne przyśpieszenie procesu tworzenia kodu, ponieważ posiada bardzo mały udział wyjaśniania tworzonego kodu w całym procesie jego tworzenia. Istnieje również bardzo niskie prawdopodobieństwo "zablokowania" się programistów w przypadku napotkania na trudny problem.  
* Ekspert - Ekspert - Jest to najlepszy wybór w przypadku skomplikowanych problemów lub takich, w przypadku których [[defekt]] kodu powoduje błędy krytyczne. Ten rodzaj pary powoduje znaczne przyśpieszenie procesu tworzenia kodu, ponieważ posiada bardzo mały [[udział]] wyjaśniania tworzonego kodu w całym procesie jego tworzenia. Istnieje również bardzo niskie [[prawdopodobieństwo]] "zablokowania" się programistów w przypadku napotkania na trudny problem.  


== Problemy ==
== Problemy ==
Poza korzyściami wynikającymi ze stosowania programowania w parach istnieją trudności związane z takim podejściem, takie jak:  
Poza korzyściami wynikającymi ze stosowania programowania w parach istnieją trudności związane z takim podejściem, takie jak:  
* zsynchronizowanie czasu dwóch programistów na wspólne zadanie,
* zsynchronizowanie czasu dwóch programistów na wspólne [[zadanie]],
* niezgodność charakterów współpracujących programistów - może ona powodować trudności komunikacyjne oraz rozbieżność w poglądzie na problem a w konsekwencji niemożność znalezienia wspólnego rozwiązania,
* [[niezgodność]] charakterów współpracujących programistów - może ona powodować trudności komunikacyjne oraz rozbieżność w poglądzie na problem a w konsekwencji niemożność znalezienia wspólnego rozwiązania,
* niektórzy pracownicy preferują pracę samodzielną - wtedy albo znajdą oni sposób na poradzenie sobie z programowaniem w parach, albo manager nie powinien zmuszać ich do takiego tryby pracy,  
* niektórzy pracownicy preferują pracę samodzielną - wtedy albo znajdą oni sposób na poradzenie sobie z programowaniem w parach, albo [[manager]] nie powinien zmuszać ich do takiego tryby pracy,  
* przyzwyczajenie programistów do pracy w parach, co powoduje, że przy pracy w pojedynkę programista taki może utknąć przy prostym problemie - można powiedzieć, że niejako rozleniwił się przy programowaniu parami przez co ciężko znaleźć mu motywację do pracy samemu.
* przyzwyczajenie programistów do pracy w parach, co powoduje, że przy pracy w pojedynkę programista taki może utknąć przy prostym problemie - można powiedzieć, że niejako rozleniwił się przy programowaniu parami przez co ciężko znaleźć mu motywację do pracy samemu.


Wersja z 05:42, 21 maj 2020

Programowanie parami
Polecane artykuły


Programowanie w parach jest jedną z podstawowych technik wytwarzania kodu w programowaniu ekstremalnym. Stosujące je zespoły organizują pracę w dwuosobowych grupach składających się z programistów, którzy siedzą przy jednej stacji roboczej. Zazwyczaj jeden z nich pisze kod a drugi przygląda się temu procesowi. Obaj cały czas debatują na temat kodu. Pozwala to na redukcje błędów (cały czas dwie pary oczu szukają nieprawidłowości) oraz zmęczenia (gdy jeden programista poczuje znużenie, drugi może przejąć pisanie kodu). Tryb pracy w parach pozwala również na zwiększenie efektywności poprzez ciągłe omawianie pomysłów, co w efekcie powoduje nieustanną burze mózgów. Dodatkową korzyścią jest wzajemna kontrola pod kątem korzystania z dobrych praktyk (jednej osobie łatwiej jest podjąć decyzje o zastosowaniu nieeleganckiego rozwiązania - na pewno zrezygnuje z niego jeśli inny programista patrzy na jego kod).

Historia

Programowanie parami wywodzi się z naturalnego procesu tworzenia oprogramowania, w którym jedni programiści prosili innych o ocenę ich pracy. Wynikało to ze świadomości ludzi, że nikt nie jest bezbłędny. W roku 1953 Fred Brooks zdał sobie sprawę z zalet programowania w parach, kiedy wraz z Williamem Wrightem, jego kolegą ze studiów, napisał około 1500 linii kodu, które działały poprawnie za pierwszym razem i nie były obarczone błędami. Z biegiem lat większa liczba osób zgłębiała to pojęcie aż do roku 1995, kiedy to Larry Constantine wprowadził termin "Dynamic Duos" a Jim Coplien napisał o programowaniu w parach. Termin przyjął się powszechnie od momentu pojawienia się manifestu agile..

Rotacja członków zespołów

Rotacja par jest często używaną praktyką w projektach ze średnimi lub dużymi zespołami. W niektórych przypadkach bardziej wydajnym sposobem jest podział na programistę wiodącego, który cały czas zajmuje się tym samym zadaniem oraz programistę pomocnika, który przesiada się co jakiś czas do innych programistów wiodących (te role także, po zakończeniu zadania, można zamieniać). Zaletami takiego podejścia są:

  • dzielenie się wiedzą oraz doświadczeniem przez programistów,
  • pokrycie wielu obszarów wymagających programowania przez wielu deweloperów (unikane jest wtedy tworzenie tzw. programistów dziedzinowych, znających tylko jeden obszar rozwijanego systemu),
  • budowa zaufania oraz integracja zespołów.

Przestrzeń pracy

Programowanie w parach jest efektywne tylko w przypadku, kiedy przestrzeń pracy zorganizowana według poniższych wytycznych:

  • swobodna i komfortowa możliwość obsługi klawiatury oraz myszki przez jednego programistę, podczas gdy obaj programiści tak samo dobrą widoczność na kod. Zaleczany jest taki układ, który w przypadku zmiany programisty wiodącego pozwala na podanie klawiatury i myszki a nie wymusza przesiadanie się,
  • przestrzeń prowokująca kontakt pomiędzy parami programistycznymi (jest to efekt oczekiwany) - w takiej sytuacji układ stanowisk pracy ułatwia kontakt wizualny oraz głosowy bez potrzeby przemieszczenia się

Tworzenie par

Każdy z programistów może zostać sklasyfikowany jako ekspert lub początkujący. W zależności od konfiguracji stwarza to pewne szanse oraz ryzyka:

  • Początkujący - Początkujący - Jest zalecany do stworzenia łatwej części kodu. Pozwala na naukę dla obu programistów - tym bardziej efektywną im bardziej odległe są obszary, które programiści pokrywają swoją wiedzą. Jest to metoda pozwalająca na ograniczenie nadzoru nad wdrażającymi i uczącymi się programistami, ale nie na jego eliminację.
  • Ekspert - Początkujący - Jest najlepszym sposobem na wdrożenie nowego programisty oraz szybkim sposobem podnoszenia jego kwalifikacji. Często postrzegana jest jako marnotrawienie czasu eksperta, natomiast im częściej początkujący wskazuje możliwe błędy eksperta, ten zaczyna przekonywać się do takiej formy pary. Dodatkowo początkujący może wprowadzić świeże spojrzenie na prace, która musi zostać wykonana. Warunkami, pod jakimi taka para ma możliwość zadziałać są: cierpliwość oraz chęć nauczania eksperta, nieprzerośnięte ego eksperta, które pozwala na słuchanie początkującego. Z drugiej jednak strony, początkujący programista może być za mało pewny siebie.
  • Ekspert - Ekspert - Jest to najlepszy wybór w przypadku skomplikowanych problemów lub takich, w przypadku których defekt kodu powoduje błędy krytyczne. Ten rodzaj pary powoduje znaczne przyśpieszenie procesu tworzenia kodu, ponieważ posiada bardzo mały udział wyjaśniania tworzonego kodu w całym procesie jego tworzenia. Istnieje również bardzo niskie prawdopodobieństwo "zablokowania" się programistów w przypadku napotkania na trudny problem.

Problemy

Poza korzyściami wynikającymi ze stosowania programowania w parach istnieją trudności związane z takim podejściem, takie jak:

  • zsynchronizowanie czasu dwóch programistów na wspólne zadanie,
  • niezgodność charakterów współpracujących programistów - może ona powodować trudności komunikacyjne oraz rozbieżność w poglądzie na problem a w konsekwencji niemożność znalezienia wspólnego rozwiązania,
  • niektórzy pracownicy preferują pracę samodzielną - wtedy albo znajdą oni sposób na poradzenie sobie z programowaniem w parach, albo manager nie powinien zmuszać ich do takiego tryby pracy,
  • przyzwyczajenie programistów do pracy w parach, co powoduje, że przy pracy w pojedynkę programista taki może utknąć przy prostym problemie - można powiedzieć, że niejako rozleniwił się przy programowaniu parami przez co ciężko znaleźć mu motywację do pracy samemu.

Bibliografia

Autor: Joanna Szarlej

Źródło: „https://mfiles.pl/pl/index.php?title=Programowanie_parami&oldid=117009”