Mob programming

Z Encyklopedia Zarządzania
Wersja z dnia 22:34, 10 gru 2023 autorstwa Zybex (dyskusja | edycje) (cleanup bibliografii i rotten links)

Mob Programming - jest to styl programowania w którym cały zespół znajduje się w jednym pomieszczeniu i skupia się na wykonaniu jednego zadania. Zespoły, które miały okazję pracować w ten sposób zauważyły, że wiele problemów, powstających podczas normalnej pracy nie występują w tej formie pracy dzięki lepszej komunikacji oraz nauki od pozostałych. Owoc pracy zespołu wykorzystującego Mob Programming jakim jest kod charakteryzuje się lepszą jakością.[1].

TL;DR

Mob Programming to styl pracy, w którym cały zespół skupia się na jednym zadaniu, co prowadzi do lepszej komunikacji i wyższej jakości kodu. Zaleca się pracę w grupie 4-5 osób, rotację miejsc co kilka minut, oraz retrospekcje po każdej sesji. W Mob Programmingu wszyscy członkowie zespołu aktywnie pracują nad zadaniem, a osoba korzystająca z klawiatury ma zakaz myślenia. Celem jest osiągnięcie najlepszej jakości kodu, a nie wykonanie jak największej ilości pracy. Mob Programming pozwala na wyłapywanie błędów na bieżąco i wykorzystanie różnych umiejętności członków zespołu. Mimo oporu, Mob Programming może prowadzić do większej efektywności i lepszej jakości kodu.

Mob Programming w kilku krokach

Nie istnieją sztywne wytyczne pasujące do wszystkich przypadków dlatego warto spróbować poniższe, proponowane przez użytkowników na początkowe:

  • wielkość zespołu: 4 do 5 osób,
  • obecność oraz udział są dobrowolne,
  • wygodne urządzanie pomieszczenia, łatwe do odtworzenia,
  • postępowanie zgodnie z modelem kierowca/nawigator,
  • rotacja miejsc co 4-5 minut,
  • praca tylko nad zadaniem,
  • co tydzień po 2-3 godziny lub dziennie od 1 do 2 godzin,
  • każdy zainteresowany jest mile widziany,
  • przeprowadzić retrospekcje po każdej sesji[2]

Model driver/navigator

Osobą kierująca w Mob Programming jest osoba, która obsługuje klawiaturę. Wiele osób uważa, że to oznacza, że pozostali członkowie zespołu patrzą na pracę jednej osoby. Jest to błędne myślenie, ponieważ osoba, która korzysta z klawiatury ma zakaz myślenia. To oznacza, że nie można mieć ludzi w zespole, którzy tylko patrzą jak ktoś pisze. W Mob Programming cały zespół pracuje wspólnie, korzystając z jednego komputera, za pomocą jednej klawiatury, co pozwala aby myśli oraz spostrzeżenia wszystkich osób mogły zostać uchwycone dla danego zadania[3].

Jakość, nie ilość

Potocznie uważa się, że jeśli jedno zadanie wykonuje 5 do 8 osób to jest to nieefektywne oraz jest to marnotrawstwo czasu. Efektywność była by większa jeśli każdy pracował by osobno. W przypadku Mob Programingu chodzi o coś innego, mianowicie nie szukana jest odpowiedź na pytanie jak najwięcej osiągnąć może zespół a jak można osiągnąć najlepsze z zespołu. Proces ten został odkryty przez Wood’iego Zuill’a oraz jego zespół w Hunter Industries poprzez ciągłe przywiązywanie uwagi do aktualnie wykonywanych czynności oraz robienie więcej niż wymagała sama praca w sobie. W przedsiębiorstwach często dochodzi do sytuacji gdzie pracownicy zostają zebrani w grupę w celu zmierzenia się z jakimś problemem. W przypadku gdy jest to wyjątkowo trudny problem jest to jedyna możliwa droga do rozwiązania go. Gdy już do tego dochodzi, różnica polega na tym, że w pozostałych stylach po rozwiązaniu problemu wraca się do stanu sprzed zebrania, a w Mob Programmingu poszukuje się odpowiedzi na pytanie: "Byliśmy bardzo efektywni, jak możemy utrzymać ten poziom?" [4]

Efektywność zespołu

Mod Programming ma na celu utrzymywanie jak najwyższej efektywności dzięki wykorzystaniu zespołu do jednoczesnego wykonywania jednego zadania. Kiedy jedna osoba tworzy kod, znajdują się w nim części napisane kiedy jego stan był lepszy czy gorszy, co przekłada się na jakość kodu, która może czasami odbiegać od wymaganej normy. Kiedy zespół pracuje nad tym samym, ale każdy osobno, wszystkie czynniki pozytywne jak i negatywne mogą przekładać się na jakość kodu. Ostatecznie, tylko to co ma wpływ na kod, ma znaczenie. [5]. Pracując w zespole, występują lepsze i gorsze momenty, które przekładają się na efektywność kodu. Jednakże, nie powoduje to w mniej efektywnych momentach przerw w pisaniu kodu. Kod jest pisany nieprzerwanie, a jednocześnie gorsze chwile przekładające się na gorszą jakość kodu nie mają miejsca w kodzie, ponieważ to odwrotna sytuacja jest pożądana i w Mob Programming jedynie taka właśnie przekłada się na kod. To może być szczególnie pomocne dla członków zespołu, których umiejętności programowania nie są na najwyższym poziomie. W wielu zespołach, niektóre pomysły pochodzą od członków, którzy w wyniku braków mają problemy z przekształceniem tych pomysłów oraz spostrzeżeń do kodu produktu. Jeśli pracowali by w pojedynkę, bądź nawet w zespole ale niezależnie, ich pomysły oraz spostrzeżenia przepadły by w wyniku nieumiejętności ich wdrożenia, a w zespole działającym według Mob Programming rozkwitną i zostaną wykorzystane dzięki umiejętnościom pozostałych członków zespołu[6]

Jakość kodu

Błędy podczas pisania kodu są na porządku dziennym. Czasami wynikają z niezrozumienia bardzo małych szczegółów wymagań. Wielkość określana przez słowo "mały" może być różnie wyobrażana. Czasami coś może zostać uznane za nieistotne i zostać pominięte oraz zapomniane. Błąd popełniony w poniedziałek, niezauważony do czwartku wieczorem, będzie przez cały tydzień powielany, bądź kolejne prace wykonywane w oparciu o wcześniejszy błąd, a w przypadku znalezienia błędu poniedziałkowego przez inną osobę, przez wzgląd na ilość pracy oraz wysiłku włożonego w pracę od poniedziałkowego incydentu będziemy starali się bronić poniedziałkowego błędu. Pracując w Mob’ie takie błędy są wyłapywane w chwili ich wystąpienia. Głównie ponieważ członek zespołu dysponuje odpowiednią wiedzą oraz czasami ktoś po prostu o to zapyta[7].

Opór przed Mob Programming

Posiadanie wiedzy w odpowiednim momencie niesie ze sobą znaczące korzyści. W przypadku większości opóźnień, ich koszt pozostaje ukryty oraz nie zostaje ujęty w arkuszach kalkulacyjnych. Gdyby wszystkie zmarnowane godziny programistów na poprawę błędów, które sami stworzyli w wyniku niewystarczającej wiedzy bądź zrozumienia wytycznych zostały oszacowane oraz zobrazowane spowodowały by mniejszy opór przed Mob Programmingiem. Potocznie uważa się, że pięć osób pracujących samodzielnie pracuje najlepiej gdy pracuje niezależnie. Jest to wyjątkowo rzadka sytuacja. Zespół jazz’owy będzie grać lepiej muzykę jeśli wszyscy będą grać wspólnie czy efekty każdego z nich będą nagrywane i łączone w całość ?[8].


Mob programming — artykuły polecane
Jidoka — Prawo Parkinsona — Redundancja — Refactoring — Rywalizacja — Afirmacja — Koncentracja uwagi — Daily scrum — Programowanie parami

Przypisy

  1. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 3.
  2. ↑ Zuill W. (2016). Mob Programming, A Whole Team Approach, Leanpub, s. 5.
  3. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
  4. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
  5. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
  6. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 5.
  7. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 6.
  8. ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 6-7.

Bibliografia


Autor: Szczepan Konik


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