I na ko\u0144cu, ale nie mniej wa\u017cne:<\/p>\n\n\n\n
- \n
- Punkt widzenia tester\u00f3w \u2013 w jaki spos\u00f3b przetestowa\u0107 rozwi\u0105zanie? Jakie czekaj\u0105 na nas pu\u0142apki?<\/li>\n<\/ul>\n\n\n\n
Z artyku\u0142u dowiecie si\u0119, jaka jest rola ka\u017cdego z 3 Amigos, czy warto, aby w spotkaniach bra\u0142 udzia\u0142 kto\u015b jeszcze i czego w rezultacie mo\u017cecie si\u0119 po nich spodziewa\u0107.<\/p>\n\n\n\n
Pierwszy Amigo \u2013 Product Owner<\/strong><\/h2>\n\n\n\n
Na spotkaniu powinien pojawi\u0107 si\u0119 przede wszystkim Product Owner \u2013 osoba po stronie biznesu, kt\u00f3ra dba o backlog oraz wizj\u0119 Produktu. To w\u0142a\u015bnie biznesowy punkt widzenia winien by\u0107 przedstawiony podczas rozm\u00f3w, tak aby Developerzy mogli go zdekomponowa\u0107 na wymagania techniczne. Na tym etapie dobrze jest ju\u017c mie\u0107 utworzone User Story ze wst\u0119pnym opisem, \u017ceby m\u00f3c rozpocz\u0105\u0107 dyskusj\u0119.<\/p>\n\n\n\n
Dopuszczalne jest r\u00f3wnie\u017c zaproszenie na spotkanie kluczowego Interesariusza odpowiedzialnego za konkretny element naszego Produktu. Wtedy ten ekspert biznesowy dzia\u0142a wsp\u00f3lnie z Product Ownerem.<\/p>\n\n\n\n
Drugi Amigo \u2013 Developer<\/strong><\/h2>\n\n\n\n
Ta osoba powinna dok\u0142adnie zrozumie\u0107 wymagania biznesowe. Dzi\u0119ki temu mo\u017cliwe b\u0119dzie rozpocz\u0119cie danego zadania, dalsze budowanie przyrostu Produktu lub te\u017c rozwi\u0105zanie problemu.<\/p>\n\n\n\n
Developer powinien tak\u017ce by\u0107 odpowiedzialny za jedn\u0105 dodatkow\u0105 rzecz. Jest ni\u0105 przekazanie informacji o poruszonych tematach pozosta\u0142ym Developerom pracuj\u0105cym w projekcie. Pomaga\u0107 mog\u0105 w tym nast\u0119puj\u0105ce aktywno\u015bci:<\/p>\n\n\n\n
- \n
- spisanie meeting notes,<\/li>\n\n\n\n
- nowy wpis na Confluence,<\/li>\n\n\n\n
- dok\u0142adniejszy opis konkretnego elementu backlogu produktu,<\/li>\n\n\n\n
- komentarz w tym\u017ce<\/li>\n\n\n\n
- lub po prostu poinformowanie reszty zespo\u0142u na chatcie np. w Teamsach.<\/li>\n<\/ul>\n\n\n\n
Trzeci Amigo \u2013 QA Tester<\/strong><\/h2>\n\n\n\n
Trzeci\u0105 osob\u0105 z tego tria, powinien by\u0107 kto\u015b z szeroko poj\u0119tego \u015bwiata QA. Zadaniem Testera jest oszacowanie poziomu skomplikowania test\u00f3w, wskazanie mo\u017cliwego ryzyka, jakie wi\u0105\u017ce si\u0119 z wdra\u017caniem danej koncepcji. QA Tester mo\u017ce dopytywa\u0107 o specyfikacje techniczne tudzie\u017c elementy designu Produktu. A wszystko po to, aby zapewni\u0107 wysok\u0105 jako\u015b\u0107 rozwi\u0105zania.<\/p>\n\n\n\n
Czwarty Amigo? Pi\u0105ty Amigo?<\/strong><\/h2>\n\n\n\n
Oczywi\u015bcie, na spotkaniu mo\u017cemy mie\u0107 wi\u0119cej Amigos. Nie nale\u017cy ogranicza\u0107 si\u0119 tylko do trzech os\u00f3b. Wszak\u017ce, gdy w Produkcie zaanga\u017cowani s\u0105 kluczowi stakeholderzy, warto r\u00f3wnie\u017c w\u0142\u0105czy\u0107 ich do dyskusji. W g\u0142\u00f3wnej mierze chodzi o to, aby przedstawi\u0107 przynajmniej 3 punkty widzenia.<\/strong><\/p>\n\n\n\n
Zwykle Scrum Master<\/strong> powinien odpowiada\u0107 za:<\/p>\n\n\n\n
- \n
- facylitacj\u0119 spotkania,<\/li>\n\n\n\n
- dok\u0142adne opisanie jego celu,<\/li>\n\n\n\n
- rozpisanie agendy.<\/li>\n<\/ul>\n\n\n\n
Cz\u0119sto bywa, i\u017c w jego gestii le\u017cy r\u00f3wnie\u017c zaktualizowanie odpowiednich element\u00f3w backlogu produktu w Jirze tudzie\u017c innym narz\u0119dziu.<\/p>\n\n\n\n
Dobr\u0105 praktyk\u0105 jest zadawanie dodatkowych pyta\u0144 przez Scrum Mastera:<\/p>\n\n\n\n
- \n
- Jaki wp\u0142yw na przyrost produktu b\u0119dzie mia\u0142o to zadanie?<\/li>\n\n\n\n
- Czy jeste\u015bmy w stanie oszacowa\u0107 poziom skomplikowania tej aktywno\u015bci?<\/li>\n\n\n\n
- Czy implementacja zadania b\u0119dzie wi\u0105za\u0142a si\u0119 z jakimi\u015b ryzykami?<\/li>\n<\/ul>\n\n\n\n
Scrum Master powinien uczestniczy\u0107 w kilku pocz\u0105tkowych spotkaniach typu 3 Amigos. Niemniej, po pewnym czasie mo\u017ce usun\u0105\u0107 si\u0119 w cie\u0144 po to, aby inny cz\u0142onek zespo\u0142u scrumowego dba\u0142 o wy\u017cej wymienione elementy.<\/p>\n\n\n\n
![\"oferty](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/12\/praca-m-6.jpg\")
<\/a><\/figure>\n\n\n\nTimebox<\/strong><\/h2>\n\n\n\n
Czas, kt\u00f3ry po\u015bwi\u0119cimy na rozmow\u0119, zale\u017cy od ustale\u0144 konkretnego zespo\u0142u. Dobrze jest po prostu poruszy\u0107 ten temat na najbli\u017cszej Retrospektywie i ustanowi\u0107 sta\u0142e ramy dla 3 Amigos. 30-minutowy timebox powinien w zupe\u0142no\u015bci wystarczy\u0107.<\/p>\n\n\n\n
Oczywi\u015bcie niekt\u00f3re dyskusje mog\u0105 si\u0119 przed\u0142u\u017ca\u0107 i mo\u017cemy nie osi\u0105gn\u0105\u0107 celu spotkania w te p\u00f3\u0142 godziny. Wtedy nale\u017cy takowe wydarzenie zako\u0144czy\u0107, postara\u0107 si\u0119 o jakiekolwiek wnioski i spr\u00f3bowa\u0107 ustawi\u0107 kolejn\u0105 sesj\u0119.<\/p>\n\n\n\n
Rezultat spotkania<\/strong><\/h2>\n\n\n\n
Najcz\u0119\u015bciej celem spotkania jest doprecyzowanie biznesowych wymaga\u0144 oraz dok\u0142adniejszy opis zadania (cz\u0119sto w formie przyk\u0142ad\u00f3w). Prowadzi to zatem do lepszego zrozumienia wewn\u0105trz zespo\u0142u<\/strong> Scrumowego i wsp\u00f3lnej wizji.<\/p>\n\n\n\n
Dodatkowym benefitem jest bardzo wczesne identyfikowanie nieporozumie\u0144 i niejasno\u015bci.<\/p>\n\n\n\n
Istnieje te\u017c mo\u017cliwo\u015b\u0107, i\u017c potrzebne b\u0119dzie dodatkowe zbadanie sprawy. Tutaj przydaje si\u0119 metoda Spike<\/strong>, kt\u00f3ra wspiera poznanie zagadnienia bardziej dog\u0142\u0119bnie.<\/p>\n\n\n\n
Metoda Spike<\/strong><\/h2>\n\n\n\n
Jest to zwykle zadanie w formie taska lub story, kt\u00f3re zesp\u00f3\u0142 Scrumowy dodaje do Backlogu Sprintu. Spike najcz\u0119\u015bciej stara si\u0119 odpowiedzie\u0107 na dwa problemy, kt\u00f3re s\u0105 bol\u0105czk\u0105 ka\u017cdego zespo\u0142u:<\/p>\n\n\n\n
- \n
- Niedob\u00f3r wiedzy niezb\u0119dnej do podj\u0119cia decyzji.<\/li>\n\n\n\n
- Konieczno\u015b\u0107 zredukowania ryzyka poprzez weryfikacj\u0119 kluczowych za\u0142o\u017ce\u0144.<\/li>\n<\/ul>\n\n\n\n
Bardzo wa\u017cn\u0105 kwesti\u0105 przy pracy ze Spike\u2019ami jest ustalenie odpowiedniego timeboxa. Najcz\u0119\u015bciej s\u0105 to po prostu 4 godziny. W Spike\u2019ach skupiamy si\u0119 na rozwi\u0105zaniu konkretnego (ma\u0142ego) problemu. Zatem po up\u0142ywie 4 godzin powinni\u015bmy podj\u0105\u0107 decyzj\u0119, co dalej.<\/p>\n\n\n\n
Musimy odpowiedzie\u0107 na pytanie, czy mo\u017cemy wr\u00f3ci\u0107 do dyskusji o naszym rozwi\u0105zaniu (posiadamy ju\u017c wi\u0119ksz\u0105 wiedz\u0119), czy te\u017c potrzebny jest nam kolejny Spike. Bardzo cz\u0119sto po zako\u0144czeniu Spike\u2019a b\u0119dziemy te\u017c w stanie spr\u00f3bowa\u0107 estymacji danego zadania.<\/p>\n\n\n\n
Spotkania typu 3 Amigos oraz metod\u0119 Spike mo\u017cna dowolnie \u0142\u0105czy\u0107. Po spotkaniu 3 Amigos mo\u017cemy zdecydowa\u0107, i\u017c potrzebujemy Spike\u2019a. Czasem te\u017c rezultatem Spike b\u0119dzie konieczno\u015b\u0107 dodatkowego spotkania i poznania r\u00f3\u017cnych perspektyw cz\u0142onk\u00f3w zespo\u0142u.<\/p>\n\n\n\n
Podsumowanie<\/strong><\/h2>\n\n\n\n
Wsp\u00f3\u0142praca os\u00f3b, kt\u00f3re maj\u0105 r\u00f3\u017cne perspektywy, daje nam mo\u017cliwo\u015b\u0107 zdefiniowania, co dok\u0142adnie nale\u017cy zrobi\u0107 oraz ustalenia, w jaki spos\u00f3b zadanie b\u0119dzie wykonane. Mo\u017cna stwierdzi\u0107, i\u017c 3 Amigos to cz\u0119\u015b\u0107 procesu backlog refinementu<\/strong>.<\/p>\n\n\n\n
Warto zaznaczy\u0107, i\u017c 3 Amigos nie powinno sta\u0107 si\u0119 kolejnym cyklicznym Scrumowym wydarzeniem. Chodzi raczej o pewien spos\u00f3b my\u015blenia maj\u0105cy na celu uwzgl\u0119dnianie r\u00f3\u017cnych perspektyw w dyskusjach na temat konkretnych etap\u00f3w pracy.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Je\u015bli interesuje Ci\u0119 zarz\u0105dzanie projektami, zajrzyj koniecznie r\u00f3wnie\u017c do innych artyku\u0142\u00f3w naszych specjalist\u00f3w<\/a> \ud83d\ude42 <\/p>\n\n\n