Rozproszony Scrum
David Starr jest głównym technologiem oprogramowania w Scrum.org, gdzie koncentruje się na doskonaleniu zawodu dewelopera oprogramowania.Założył również internetową społeczność techniczną ElegantCode.com.
Lipiec 2012 r.
Rozproszone zespoły napotykają problemy z komunikacją spójną, skuteczną i terminową.Warto zobaczyć, jak scrum stanowi kontener, w którym różnego rodzaju rozproszone zespoły mogą poprawić rezultaty i odnieść sukces.
Środowisko Scrum nie mówi nic o rozproszonych zespołach rozwojowych.Scrum nie wymaga, aby wszyscy członkowie zespołu Scrum lub nawet członkowie zespołu rozwoju pracowali w tym samym pokoju, budynku, mieście lub w jednej strefie czasowej.Zespoły scrum aktywnie pokonują przeszkody w celu zwiększania produktywności, a kiedy komunikacja napotyka przeszkody, Scrum dokładnie to uwidacznia.
Gdy członkowie zespołu fizycznie nie pracują razem, komunikacja w zespole jest bardziej złożona i takie też jest oprogramowanie opracowane przez ten zespół.W 1968 r. Melvin Conway napisał:
Organizacje projektujące systemy są ograniczone do tworzenia projektów, które są kopiami struktur komunikacyjnych tych organizacji.
Prawo Conway'a okazało się więcej niż pustym powiedzeniem; trafnie mierzy dynamikę w zespołach deweloperów oprogramowania.Jedno z badań potwierdziło działanie prawa Conways przez pomiar wyników dystrybucji zespołu w architekturze systemu.Gdy członkowie zespołu są rozproszeni, deweloperzy oprogramowania zwykle tworzą więcej warstw abstrakcji w kodzie, starając się izolować się od siebie[1].
Omówienie
Jak zobaczyć zespół w kodzie
Stella jest programistą w zespole Scrum, który konsekwentnie wykonuje prace zgodnie z prognozami dla każdego Sprint.Jej zespół ma reputację do tworzenia wysokiej jakości oprogramowania, nawet jeśli ich kod jest dość trudny do zrozumienia, kiedy inni go czytają.
Pracuje w domu i w innej strefie czasowej niż pozostała część jej zespołu.Do omówienia pracy w każdym ze sprintów używają poczty e-mail, drogiego systemu zarządzania wymaganiami i systemów wideokonferencji.Używają Scrum zgodnie z dziennym scrumem zaplanowanym, aby pomieścić harmonogramy wszystkich osób.Nie widząc twarzy członków zespołu, uczestniczy w planowaniu spotkań i dziennego obciążenia przez telefon.Ona również nie słyszy rozmów prowadzonych przed i po każdym dziennym scrumem.
Stella tworzy warstwę abstrakcji w swoim kodzie, więc jej pracę można łatwiej odizolować i przetestować.Jej nowa klasa abstrakcyjna oddziela jej implementację z interfejsu, którą zadeklarowała i udostępniła innym członkom swojego zespołu.Ona twierdzi, że tego rodzaju system wykorzystujący wtyczki prowadzi do architektury systemu rozdzielonego. „Korzystanie z interfejsów jako granicy implementacji jest po prostu dobrym obiektowym projektowaniem,” przypomina sobie.Jej nowy model plugin umożliwi jej pracę tylko w jej sekcji kodu i nie zakłóca członkom zespołu pracy w innych obszarach.
Jak przewidziało prawo Conway'a, kod teraz odzwierciedla jej komunikację z zespołem: luźno zintegrowany.Jej projekt zastępuje rozmowy, które może ona prowadzić z zespołem, a system staje się niepotrzebnie skomplikowany.Taki poziom niepotrzebnej złożoności jest odzwierciedleniem jej relacji z innymi członkami zespołu.Ostatecznie te decyzje pociągną za sobą skutki finansowe ze względu na większą liczbę linii kodu, większą liczbę poziomów pośrednich do przyswojenia przez przyszłych programistów i większą liczbę testów do wykonania, które udowodnią prawidłowe działanie funkcji.
Stella nie zrobiła nic złego.W rzeczywistości doskonale wykorzystała ona przewagę wynikającą z dobrych i właściwie zorientowanych praktyk projektowych, aby wyizolować obszar problemu w systemie.Niestety problem, który wyizolowała, był jej własnym problemem komunikacyjnym, a rozwiązanie zezwala na jeszcze rzadszą komunikację.Niestety system, który zmieniła podczas adresowania problemu, był oprogramowaniem.Bardziej skutecznym sposobem na zajście się tą kwestią może być uproszczenie komunikacji z zespołem programistów.
Gdy członkowie zespołu pracują w jednym miejscu, zamieniają zwyczajne wymiany zdań na trudniejsze i bardziej formalne rozmowy.A nie szybkie i wydajne dyskusje na temat drobnych decyzji taktycznych, kolejki tematów i czekanie na późniejsze omówienie.Często, później nigdy nie przychodzi.Mniej komunikacji między osobami oznacza przesyłanie komunikatu do innych rzeczy, takich jak specyfikacje, bilety pracy lub nawet kod.ISomeInterfaces pokrywa dysfunkcje zespołów, które je tworzą.
Niezamierzona złożoność dystrybucji zespołu
Decyzje podjęte poza zespół scrumowym są tymi, które najbardziej prawdopodobnie spowodują wzrost złożoności.Zespoły deweloperów oprogramowania rzadko mają prosty skład lub zadania, a Scrum ustanawia granice, w ramach których zespół Scrum manewruje i pracuje w celu zmniejszenia złożoności.Mimo to złożoność faktycznego pisania kodu oraz dostarczanie oprogramowania czasami blednie w porównaniu ze złożonością kultury organizacyjnej i procesów stojących na drodze zespołu programistów.
W związku z tym decyzja o stworzeniu zespołu scrumowego z członków, którzy mieszkają w różnych strefach czasowych, rzadko jest podejmowana przez osoby faktycznie wykonujące pracę.Decyzje o utworzeniu rozproszonego zespołu scrumowego najczęściej pochodzą od liderów, którzy tworzą zespół wysoko wykwalifikowanych specjalistów lub (bardziej prawdopodobne) próbują obniżenia kosztów produkcji poprzez angażowanie zewnętrznych wykonawców do opracowania oprogramowania za mniej pieniędzy.Mimo że te modele mogą zmniejszyć początkowy koszt rozwoju oprogramowania, zwykle nie biorą pod uwagę kosztów rutynowej konserwacji i dodanej złożoności w związku z problemami komunikacyjnymi zespołu deweloperskiego.
Bez względu na to, jak i dlaczego są tworzone rozproszone zespoły, istnieją one realnie i nie zostaną usunięte.Nawet w zespołach rozproszonych scrum pozostaje doskonałym środowiskiem do zarządzania planowaniem i realizacją dostarczania produktów oprogramowania.Członkowie zespołu muszą po prostu bardziej dbać o poprawę istniejących kanałów komunikacji i chronić przed optymalizacją podrzędną, taką jak opisana w powyższym przykładzie.
Rzeczywistość rozproszona
Rozproszone zespoły mogą zapewnić możliwości zatrudniania odpowiednich osób do pracy niezależnie od miejsca ich zamieszkania lub dla niektórych osób życia tam, gdzie wybrali, zamiast tam, gdzie ma siedzibę firma.Chociaż argumentowanie przeciwko rozproszonym zespołom jest łatwe, ekonomika outsourcingu, insourcingu, near sourcingu i rural sourcingu pozostaje atrakcyjna dla wielu organizacji.
Przewodnik Scrum, opublikowany w Scrum.org, kodyfikuje Scrum i jest to zbiór zasad do stosowania w środowisku Scrum.O ile Przewodnik Scrum milczy w kwestii rozproszonych zespołów i nie zawiera żadnych szczególnych wytycznych przeznaczonych dla nich, narzędzie Scrum unaoczni oczywiste spowolnienia komunikacyjne i problemy, które istnieją w zespołach, których członkowie nie mogą rozmawiać ze sobą bez urządzeń elektronicznych.
Zaufanie się liczy
Większość tego, co ludzie do siebie mówią, jest przekazywane przez język ciała.Informacje zgromadzone przez obserwację kogoś podczas dyskusji nad projektem mogą być równie cenne, jak informacje napisane na tablicy.W związku z tym wiele wysiłków w niwelowania luki między pracownikami rozproszonymi skupia się na pokonaniu bariery języka ciała.
Steve McConnell napisał, „Okres połowicznego zaniku zaufania trwa około 6 tygodni”. [2] Uwzględnia to, że deweloperzy pracujący i współpracujący ze sobą każdego dnia zwiększają poziom wzajemnego zaufania.Ilość zaufania różni się jak w przypadku dowolnej relacji, ale potencjał dla zaufania jest największy, gdy często widzą się nawzajem i współpracują ze sobą.
Kiedy współpracownicy przestają kontaktować się ze sobą codziennie i nie działają w bliskim sąsiedztwie, po około sześciu tygodniach poziom zaufania w relacji spada o ½.Pozostałe krótki ogon zaufania zmniejsza się szybko w miarę upływu czasu.
Nie jest tak, że osoby zaangażowane nie mają pozytywnego wpływu w zakresie wzajemnego wzglądu lub szacunku, ale efektywność i zaufanie zespołu zostaną utracone.Bez zaufania zmniejszy się poziom współpracy i zwiększy się dystans między członkami zespołu.Te granice są często odzwierciedlane w kodzie.
Aparaty fotograficzne, telekonferencje, komunikatory, czaty wideo, udostępnianie ekranu i inne narzędzia współpracy pomagają zbudować pomost pomiędzy członkami zespołu. Narzędzia takie jak te muszą być powszechne jak powietrze, aby rozproszone zespoły mogły być wysoko wydajne.W przypadku częstej komunikacji wideo trzeba będzie przejść długą drogę w celu odbudowy zaufania.
Niezależnie od używanych narzędzi rozproszone zespoły mogą zwiększyć ich skuteczność dzięki wykorzystaniu możliwości wysokiej jakości komunikacji.Krótko mówiąc, głos na żywo jest preferowany dla wiadomości błyskawicznych, które są preferowane dla wiadomości e-mail i tak dalej.Zmniejszenie czasu między interakcjami jest jeszcze lepsze.
Stopień oddalenia
Istnieje wiele sposobów rozdziału członków zespołu oraz wiele powtarzających się typów dystrybucji zespołów.Jak wzorce znalezione w innych środowiskach (np. projektowania oprogramowania), wzorce zespołu dystrybucji mogą wystąpić celowo lub przypadkowo.Przypadkowe wzorce występują, takie jak nieświadome odpowiedzi na istniejące naciski, i zamierzone wzorce są celowo wdrażane w celu kontrolowania złożoności.
Rozproszone wzorce Scrum opisane tutaj mogą być zalecane lub niezamierzone.Może być inspirowane decyzjami spoza zespołu Scrum lub mogą być wynikiem wewnętrznej organizacji zespołu Scrum wokół konkretnych problemów.Bez względu na to, skąd pochodzą, następujące wzorce dystrybucji są powszechne w środowisku naturalnym.
Zdalne zespoły rozwojowe współpracują ze sobą, ale są fizycznie oddzielone od reszty firmy.
We wzorze Członek zespołu zdalnego jedna osoba działa w innym miejscu niż reszta zespołu, do którego należy.
W zespołach rozproszonych poszczególni członkowie zespołu pracują wspólnie nad osiągnięciem tego samego celu, ale każdy z odrębnej lokalizacji.
Zdalnie pracujący zespół rozwoju
Niektóre zespoły deweloperów lub, co gorsza, ich właściciele produktu są geograficznie oddzieleni od ich większej organizacji nadrzędnej.Jest to częste, gdy jedna spółka przejmuje inną lub gdy następuje fuzja dwóch spółek.Jeśli zespół opracowujący musi pracować zdalnie, Scrum to idealny sposób na zarządzanie pracą i komunikacją tego zespołu z szerszą organizacją.Wiele zespołów skutecznie korzysta dzisiaj z tej formuły.
Chociaż sytuacje różnią się, zdalne zespoły programistyczne często czują się marginalizowane, niedoceniane i odcięte od głównej organizacji.Członkowie zespołu zdalnego mogą czuć się ignorowani i oderwani od firmy macierzystej (często nieumyślnie), która może traktować taki zespół jako mniej ważny niż ten znajdujący się w siedzibie firmy.
Te zdalne zespoły programistyczne nie przestają znajdować powodów, aby nie integrować własnej pracy z pracą innych zespołów.Staje się to łatwe do wyjaśnienia, dlaczego ta integracja Sprint nie jest ważna, niezbędna czy możliwa.Uraz jest coraz większy, co powoduje, że zespół opracowujący do wyświetlania wymaga kodu integracji z szerszą organizację w sposób „nieuzasadniony”, „daleki od rzeczywistości”, „niepotrzebnie” lub „nieodpowiednio do naszych potrzeb”.
To czy żadne, czy wszystkie z tych wrażeń są prawdziwe, nie ma znaczenia.Zdalnie pracujący zespół rozwoju musi czuć, że wszyscy nawzajem się rozumieją i umieją wysłuchać, podobnie jak musi rozumieć własną wartość w ramach szerszej organizacji.To łatwo zapomnieć, że jedna jest częścią czegoś większego od siebie przy wysyłaniu do zdalnego ogłoszenia.
Mistrz Młyna pracujący w innym miejscu niż zespół programistów to prosta droga do porażki.Wzorców scrum nie mogą skutecznie wykonać obowiązków w zakresie szkolenia, ułatwienia skutecznych zdarzeń Scrum i stewardingu Scrum z dużej odległości.Odległość między zespołem programistów i a Mistrzem Młyna utrudnia komunikację i wprowadza zbyt dużo ryzyka do zespołu scrumowego.Znajomość jest wymagana dla zaufania, a mocne wzajemne zaufanie ma podstawowe znaczenie dla powodzenia projektowania w scrumie.
Wzorce scrum pracują w tej samej lokalizacji co ich zespoły deweloperów.
Aby zespół programistów dobrze służył właścicielowi produktu, wymaga także niehamowanej i jasnej komunikacji.Właściciel produktu musi być dostępny dla zespołu rozwoju w ramach każdego sprintu, aby odpowiadać na pytania i wyrażać opinię na temat prac w toku.Taka interakcja jest możliwa w zdalnych sytuacjach, należy wybrać niezawodną metodę na utrzymywania komunikacji.
Nieobecny właściciel produktu jest jedną z najbardziej destrukcyjnej sił, jaka może wystąpić w zespole scrumowym.Zaniedbany zespół programistów jest zmuszony do podjęcia decyzji dotyczących funkcjonalności i priorytetów.Ta grupa często ma najmniejsze możliwości dokonywania dobrych wyborów dotyczących funkcji, ponieważ ma mniej informacji o potrzebach konsumentów niż właściciel projektu.
Właściciele produktu przekazują uwagi i opinie do działu rozwoju w całym Sprint.
Niestety nieobecni lub rzadko dostępni właściciele produktu są częstym problemem dla zespołów Scrum, nawet w środowiskach umieszczonych w jednym miejscu.Aby wykorzystać potencjał zespołu Scrum, musi on funkcjonować jako jednostka — konieczne są spójne działania, zaufanie i współpraca. Powinien też być regularnie monitorowany przez dedykowanego właściciela produktu.
Zdalnie pracujący członek zespołu
Niektórzy deweloperzy są odizolowani od członków swojego zespołu, którzy znajdują się i pracują razem w udostępnionej lokalizacji.Klasycznym przykładem jest deweloper, który pracując w domu, sumiennie współpracuje z zespołem z domowego biura.Chociaż powody takiego układu różnią się, jest on coraz bardziej powszechny.
Alistair Cockburn ukuł termin osmotyczna komunikacja[3] do identyfikowania typu komunikacji wewnętrznej w pomieszczeniu zespołu.
Komunikacja osmotyczna oznacza, że informacje wpadają do podstawowego przesłuchania członków zespołu, tak aby można było wyodrębnić istotne informacji na zasadzie osmozy.Zwykle można to osiągnąć przez posadzenie ich w tym samym pomieszczeniu.Następnie, gdy jedna osoba zadaje pytanie, inne osoby będące w pokoju mogą dołączyć się do dyskusji lub kontynuować swoją pracę.
Komunikacja osmotyczna nie jest ograniczona do zespołów deweloperów oprogramowania.Osoby odwiedzające serwis informacyjny dużych gazet i innych mediów często znajdują dokładnie taką sytuację.Nawet oddziały dochodzeniowe na posterunkach policji na świecie używają pomieszczeń zespołów, aby zwiększyć zbiorowe rozumienie podczas badania przestępstw.
Utrata komunikacji osmotycznej to utrata świadomości sytuacyjnej w zespole.Gdy deweloper oprogramowania nie jest świadomy zmian wprowadzanych do oprogramowania przez jego współpracowników, dochodzi do utraty spójności i kontekstu w ramach zespołu.Skoncentrowany, pracujący zdalnie członek zespołu nie ma dostępu do wiedzy, która powstaje w pokoju zespołu.Dzięki temu nie będzie uczestniczyć w dyskusjach ad-hoc dotyczących projektu i innych decyzji podejmowanych płynnie danego dnia.
Trend do dostarczania oprogramowania szybciej z krótszymi okresami pomiędzy wydaniami wymaga od zespołu projektowego jeszcze większej świadomości sytuacyjnej.W przypadku członka zespołu zdalnego bez obecności w pomieszczeniu zespołu, rozpoznawanie sytuacyjne jest po prostu utracone.
Rozwiązania telekonferencji stają się coraz bardziej powszechne, aby rozwiązać ten problem.Proste rozwiązania telekonferencji mogą być emitowane przy użyciu niedrogich komputerów przenośnych, kamery i głośników.Ten system określania położenia w sali zespołu może zapewnić otwarty kanał komunikacji dla dewelopera pracującego zdalnie, który może po prostu pozostawić kanał otwarty przez cały dzień.
Wideo i telekonferencje pomagają pokonać barierę mowy ciała.
Oznaki wskazujące na dewelopera zdalnego, który próbuje rzeczywiście być częścią zespołu, obejmują:
Korzystanie z komunikacji pisemnej takiej jak wiadomości e-mail lub wiadomości błyskawiczne do omówienia złożonych zagadnień.
Definiowanie stałych interfejsów jako kontraktów w kodzie zamiast prowadzenia regularnych dyskusji z innymi programistami.
Żąda prywatnego lub osobistego kodu odgałęzienia w kontroli wersji.
Okresowe wizyty są bardzo pomocne, aby zniwelować występujące między zdalnym deweloperem a resztą zespołu.Połączenia wideo są lepsze niż rozmowy telefoniczne.Rozmowy telefoniczne są lepsze niż wpisywanie, a opieranie się na wiadomościach e-mail to katastrofa, która czeka, aby się zdarzyć.
Zespół rozproszony
W zespole Scrum rozproszone osoby wspólnie pracują nad realizacją tego samego celu Sprint, a każdy członek zespołu działa w innej lokalizacji.Typowym przykładem architektury jest projekt typu open source, którego autorzy mieszkają w różnych miejscach na świecie.Mimo iż problemy z komunikacją są znaczne, model ten posiada wyraźne zalety.Komunikacja w zespole tego typu koniecznie jest kwestionowana, ale jest coraz częściej używana, ponieważ technologia wciąż zmniejsza barierę języka ciała.
Gdy członkowie zespołu znajdują się w różnych lokalizacjach, oprogramowanie udostępniania ekranu ma zasadnicze znaczenie dla skutecznego dyskutowania na temat projektu i kodu.W związku z kodem, chyba że obie strony w konwersacji widzą to samo, dyskusja zawiera zbyt wiele założeń.Na szczęście udostępnianie oprogramowania na ekranie jest bardzo skuteczne i łatwo dostępne.Członkowie zespołu, którzy nie są w tym samym pomieszczeniu, powinni znajdować się na ekranach współdzielonych z innymi osobami z zespołu po kilka razy dziennie.
Udostępnianie ekranu może być bardzo skutecznym narzędziem współpracy i parowania.
Znalezienie pretekstu, aby sprawdzić kod, elementy zaległości lub inne artefakty razem, jest wspaniałym sposobem utrzymywania wysokiej świadomości sytuacyjnej w rozproszonych zespołach.Inną skuteczną techniką jest dodawanie prostej reguły weryfikacji dla każdego elementu dostarczonego jako część sprintu.Reguła dwóch części to:
Każdy element musi zostać zweryfikowany w środowisku integracyjnym, aby został uznany za gotowy.Osoba wykonująca weryfikację nie musi być osobą, która wykonała pracę.
Zespoły deweloperów przyjmujące tę prostą zasadę uzyskują lepszego zbiorowe zrozumienie pracy, jaka jest wykonywana w całym zespole.
Od autoraPracowałem z zespołem programistów, którego członkowie pracowali w tym samym budynku, ale różnych pomieszczeniach. To był powód do dumy dla zapewnienia prywatnych biur dla wszystkich pracowników firmy. Zespół opracowujący postanowił ostatecznie stworzyć wirtualne pomieszczenie zespołu, w którym każdy członek zespołu może się pojawić, korzystając z kamery, mikrofonu i głośników. Wirtualny pokój zespołu pozostawał cały czas otwarty. Członkowie zespołu wchodzili do niego podczas pracy nad tym samym produktem.Po krótkim czasie, zespół zaczął doceniać wirtualny pokój. Zamiast chodzić i osobiście oglądać zawartość ekranów współpracowników, zaczęli korzystać z funkcji udostępniania ekranu, która pozwala zaoszczędzić czas. Zespół zaczął całymi dniami korzystać z wirtualnego pokoju zespołu, mimo że jego członkowie siedzieli w swoich biurach, które były oddzielone od siebie cienkimi ścianami.Ostatecznie, jeden z członków zespołu przez kilka dni nie przychodził do biura, wykonując swoją pracę bezpośrednio z domu. W trakcie retrospektywy sprintu zespół programistów zgodził się, że wirtualny pokój zespołu sprawił, że nie ma znaczenia, czy osoba była kilka drzwi dalej na tym samym korytarzu czy w domu. Wirtualny pokój zespołu sprawdził się dużo lepiej niż pojedyncze biura.
Narzędzia i wskazówki
Wiele zamieszania wiąże się zespołami Agile korzystającymi z narzędzi niewymagających i Hi-Fi do zarządzania pracą.Po dodaniu do mieszanki złożoności rozmieszczenia geograficznego wielu zespołów deweloperów, zwykłe karty indeksów i markery po prostu nie zdają egzaminu tak dobrze, jak rozwiązania bazujące na oprogramowaniu.Doprowadziło to do powstania dużej ilości narzędzi zarządzania przeznaczonych dla zespołów Scrum lub agile. Wielu dostawców tych narzędzi obiecuje, że „nasze narzędzi ułatwi pracę”.
Mylenie narzędzi z praktykami
Oczywiście żadne narzędzie nie zastąpi zręczności zespołu.Prawdziwą dynamikę zapewniają kultura, postawy i zachowania osób tworzących i dostarczających oprogramowanie.W związku z tym manifest zwinnego projektowania[4] wyraża wartość dla „osób i interakcji nad procesami i narzędziami”.
Typowe powiedzenie we wspólnocie programistów zwinnych to „Ludzie przed procesami, a procesy przed narzędziami”.
Wspólne powiedzenie pragmatyków to „Narzędzia wyznaczają zasady”.
Oba te powiedzenia mówią o relacjach użytkowników z oprogramowaniem używanym do komunikacji, współpracy i zarządzania pracą.Narzędzia śledzenia pracy są przeznaczone do zmniejszenia złożoności komunikacji i poprawy zrozumienia, a mimo to może dojść do odwrotnej sytuacji.Nie jest to nietypowe, że osoby wpadają w rutynę niepotrzebnego raportowania wad zamiast na przykład je naprawiać.
Od autoraCennym zasobem dla tych, którzy badają kwestię równowagi między narzędziami, procesami i praktykami, jest oficjalny dokument Kent Beck Narzędzia zwinnego programowania. Dzisiejsze dokumenty są tak samo wnikliwe, jak w 2008 roku, kiedy napisał to Beck.
Wzorce Scrum i członkowie zespołu rozwoju są podatni na lament, "Narzędzie jest nieaktualne," kiedy dane w pracy lub systemie śledzenia funkcji nie są aktualne.Ta opcja odrzuca Twoją wiedzę intuicyjną:
Celem jest zapewnienie aktualnych informacji zespołowi, nie aktualizowanie narzędzia.Czasami narzędzie może w tym pomóc.
Scrum jest specjalnie zaprojektowany w celu zwiększenia świadomości sytuacyjnej w zespole Scrum.Scrum milczy na temat formatu dla wymagań, utrzymania czasowego, podziałów pracy, jednostek oceny lub śledzenia czasu.Zespoły mogą uważać te rzeczy za przydatne i mogą pracować w ramach kontekstu Scrum.Ale zespoły używające tych dodatkowych praktyk robią tak oprócz scrumu, nie z jego powodu.
Wspieranie praktyk narzędziami
Najlepiej, aby każde narzędzie używane przez zespół scrumowy było wybrane w celu wspierania praktyki wybranej przed narzędziem.Oznacza, że to zdrowe zespoły Scrum celowo pracują nad poprawą.Zrobienie tak oznacza wybór nowej praktyki lub techniki do wypróbowania, ponieważ zespół chce się poprawić w określonym obszarze.Użycie narzędzia do obsługi nowych praktyk może nastąpić po sprawdzeniu podstaw.W skrócie:
Najpierw wybierz najlepszych ludzi.Jako samodzielnie działający zespół, wybierają swoje własne praktyki, a na koniec wybierają narzędzie do wsparcia praktyk, które wybrali.Ceń ludzi ponad procesami i procesy ponad narzędziami.
(Aby uzyskać więcej informacji na temat narzędzi do wspierania Twoich działań w programie Microsoft Visual Studio 2012, zobacz Współpraca (dokładniejsze wyszukiwanie) (przekierowane), Współpraca (przekierowane) i sekcję Informacje w portalu Zapraszamy w usłudze Visual Studio Online).
To, jak członkowie zespołu współpracują ze sobą, ma niezaprzeczalny i oczywisty wpływ na tworzone przez nich oprogramowanie.Gdy komunikacja jest prosta i efektywna, odzwierciedla ją przygotowane oprogramowanie.I odwrotnie, kiedy zespoły mają trudności z komunikowaniem się wewnętrznie lub z osobami, dla których pracują, oprogramowanie produkowane przez zespół będzie odzwierciedlać napotykane przeszkody.
Cykle regularnej inspekcji i adaptacji Scrum mogą oznaczać długą drogę w kierunku udzielania pomocy zespołom rozproszonym.Określone zdarzenia wymuszania komunikacji Scrum mogą występować, ale niekoniecznie mają wpływ na formę komunikacji.
Wspólny pokój zespołu pozostaje najprostszym technicznie, najbardziej wiarygodnym i najbardziej skutecznym sposobem, w jaki zespół wspólnie może tworzyć złożone oprogramowanie.Ale zespoły zdalne pozostaną.Motywowane często sytuacją osobistą, korzyściami gospodarczymi lub brakiem wykwalifikowanych osób, coraz więcej zespołów Scrum pracuje w taki sposób, że członkowie zespołu nie są fizycznie w jednym pomieszczeniu.
Zadbanie o odpowiednią komunikację zespołu rozdzielonego fizycznymi granicami przyniesie dywidendę w postaci wyższej jakości, mniejszego zamieszania, większej szybkości pracy i bardziej zadowolonych osób.Rozkład będzie działać prawidłowo, gdy przyłoży się uwagę do narzędzi i praktyk w zespołu.Może nawet bardzo dobrze pracować.
Odniesienia
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond (Architektury, koordynacja i odległość: prawo Conwaya i nie tylko).Oprogramowanie IEEE, 7
McConnell, S. (2009).Ograniczenia podróży i zamorski rozwój.
Cockburn, A. (2008).Komunikacja osmotyczna.