Mob programming: Różnice pomiędzy wersjami
m (Dodanie TL;DR) |
m (cleanup bibliografii i rotten links) |
||
| (Nie pokazano 13 wersji utworzonych przez 2 użytkowników) | |||
| Linia 1: | Linia 1: | ||
'''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ą.'''<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 3.</ref>. | '''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ą.'''<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 3.</ref>. | ||
| Linia 20: | Linia 4: | ||
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 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 == | ==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: | 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 : | * wielkość zespołu: 4 do 5 osób, | ||
* obecność oraz [[udział]] są dobrowolne, | * obecność oraz [[udział]] są dobrowolne, | ||
* wygodne urządzanie pomieszczenia, łatwe do odtworzenia, | * wygodne urządzanie pomieszczenia, łatwe do odtworzenia, | ||
| Linia 30: | Linia 14: | ||
* co tydzień po 2-3 godziny lub dziennie od 1 do 2 godzin, | * co tydzień po 2-3 godziny lub dziennie od 1 do 2 godzin, | ||
* każdy zainteresowany jest mile widziany, | * każdy zainteresowany jest mile widziany, | ||
* przeprowadzić retrospekcje po każdej sesji | * przeprowadzić retrospekcje po każdej sesji<ref>Zuill W. (2016). ''Mob Programming, A Whole Team Approach'', Leanpub, s. 5.</ref> | ||
<google> | |||
<google>n</google> | |||
== Model driver/navigator == | ==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 | 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<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 4.</ref>. | ||
== Jakość, nie ilość == | ==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 | 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?"''' <ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 4.</ref> | ||
== Efektywność zespołu == | ==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ą | 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'''. <ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 4.</ref>. | ||
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 | 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<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 5.</ref> | ||
== Jakość kodu == | ==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 | 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<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 6.</ref>. | ||
== Opór przed Mob Programming == | ==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 | [[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ść ?<ref>Pyhäjärvi M. (2016). ''The Mob Programming Guidebook'', Leanpub, s. 6-7.</ref>. | ||
{{infobox5|list1={{i5link|a=[[Jidoka]]}} — {{i5link|a=[[Prawo Parkinsona]]}} — {{i5link|a=[[Redundancja]]}} — {{i5link|a=[[Refactoring]]}} — {{i5link|a=[[Rywalizacja]]}} — {{i5link|a=[[Afirmacja]]}} — {{i5link|a=[[Koncentracja uwagi]]}} — {{i5link|a=[[Daily scrum]]}} — {{i5link|a=[[Programowanie parami]]}} }} | |||
==Przypisy== | |||
<references /> | |||
==Bibliografia== | ==Bibliografia== | ||
*Hohman | <noautolinks> | ||
*Pyhäjärvi M. (2016) | * Hohman M. (2001), ''Mob Programming and the Tansition to XP'', AC Slocum, First XP Universe Conference | ||
*Wilson A. (2015) | * Pyhäjärvi M. (2016), ''The Mob Programming Guidebook'', Leanpub | ||
*Zuill W.(2014) | * Wilson A. (2015), ''[https://link.springer.com/content/pdf/10.1007%2F978-3-319-57633-6.pdf Agile Processes in Software Engineering and Extreme Programming]'', Unruly, London, UK | ||
*Zuill W. ( | * Zuill W. (2014), ''[https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf Mob Mob Programming, A Whole Team Approach]'', Agile 2014 Conference, Orlando, Florida | ||
* Zuill W. (2014), ''[https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf Mob Mob Programming, A Whole Team Approach]'', Agile 2014 Conference, Orlando, Florida | |||
< | </noautolinks> | ||
{{a|Szczepan Konik}} | |||
[[Kategoria:Techniki zwinne]] | |||
{{ | {{#metamaster:description|Mob Programming - styl programowania, w którym cały zespół pracuje razem nad jednym zadaniem. Lepsza komunikacja i wymiana wiedzy prowadzą do wyższej jakości kodu.}} | ||
Aktualna wersja na dzień 20:06, 8 sty 2024
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]
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
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 3.
- ↑ Zuill W. (2016). Mob Programming, A Whole Team Approach, Leanpub, s. 5.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 4.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 5.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 6.
- ↑ Pyhäjärvi M. (2016). The Mob Programming Guidebook, Leanpub, s. 6-7.
Bibliografia
- Hohman M. (2001), Mob Programming and the Tansition to XP, AC Slocum, First XP Universe Conference
- Pyhäjärvi M. (2016), The Mob Programming Guidebook, Leanpub
- Wilson A. (2015), Agile Processes in Software Engineering and Extreme Programming, Unruly, London, UK
- Zuill W. (2014), Mob Mob Programming, A Whole Team Approach, Agile 2014 Conference, Orlando, Florida
- Zuill W. (2014), Mob Mob Programming, A Whole Team Approach, Agile 2014 Conference, Orlando, Florida
Autor: Szczepan Konik
