Rozproszone zwinne tworzenie oprogramowania

Rozproszone zwinne tworzenie oprogramowania to obszar badawczy, który rozważa skutki zastosowania zasad zwinnego tworzenia oprogramowania w globalnie rozproszonym środowisku programistycznym, w celu przezwyciężenia wyzwań w projektach rozproszonych geograficznie.

Zasady zwinnego tworzenia oprogramowania zapewniają struktury promujące lepszą komunikację, która jest ważnym czynnikiem pomyślnej pracy w środowisku rozproszonym. Jednak brak bezpośredniej interakcji odbiera jedną z podstawowych zasad zwinności. To sprawia, że rozproszone zwinne tworzenie oprogramowania jest trudniejsze niż zwinne tworzenie oprogramowania w ogóle.

Historia / Badania

Rosnąca globalizacja za pomocą nowych możliwości zapewnianych przez technologiczną wydajność Internetu skłoniła firmy tworzące oprogramowanie do przeniesienia swoich wysiłków rozwojowych do bardziej atrakcyjnych ekonomicznie obszarów. Zjawisko to rozpoczęło się w latach 90., a jego strategiczne znaczenie zostało zrealizowane w latach 2000. Większość wstępnych badań pokrewnych również pochodzi z tego okresu.

W tym czasie wydano Manifest Agile , który reprezentuje ewolucję od dominujących podejść wagi ciężkiej do tworzenia oprogramowania. To naturalnie doprowadziło do pytania: „Czy tworzenie oprogramowania rozproszonego może być zwinne?”. Jeden z pierwszych kompleksowych przeglądów próbujących odpowiedzieć na to pytanie został przeprowadzony w 2006 roku. Badając trzy organizacje, odkryli, że „staranne włączenie zwinności do rozproszonych środowisk programistycznych jest niezbędne do sprostania kilku wyzwaniom związanym z komunikacją, kontrolą i zaufaniem w rozproszonych zespołach. ”. Później, w 2014 r., przeprowadzono systematyczny przegląd literatury (SLR), aby zidentyfikować główne problemy związane z uzyskaniem zwinności do pracy w sposób rozproszony. W 2019 została wykonana podobna lustrzanka. Ponadto dokonano ogólnego przeglądu na ten temat w r. Wyniki niektórych z tych badań zostaną omówione w części Wyzwania i zagrożenia.

Ogólnie rzecz biorąc, zwinne tworzenie rozproszonego oprogramowania pozostaje bardzo dynamiczną dziedziną. Nadal prowadzone są badania nad wszystkimi jego aspektami, które wskazują, że oferuje wyjątkowe możliwości i zalety w porównaniu z bardziej tradycyjnymi metodami, ale nie bez narzucania własnych wyzwań i zagrożeń.

Możliwości

W środowisku rozproszonym można mieć trudności ze śledzeniem obciążenia pracą i wkładem wszystkich osób w produkt końcowy. Dzięki przyjęciu zwinnych zasad i praktyk widoczność jest wyraźniejsza, ponieważ istnieje wiele iteracji, w których można zwizualizować problemy lub krytyczne punkty na początkowych etapach projektu. Ciągła integracja kodu programowania, która jest jednym z głównych elementów zwinnego tworzenia oprogramowania, dodatkowo służy ograniczeniu konfiguracji problemów wykonawczych. Przyjęcie zwinnych zasad wydaje się pozytywnie wpływać na korespondencję między grupami, ponieważ postęp w cyklach ułatwia członkom dostrzeżenie celów krótkoterminowych. Przeglądy sprintu mogą być postrzegane jako potężna metoda usprawnienia zewnętrznej korespondencji, podczas gdy pomagają udostępniać dane o funkcjach i warunkach wstępnych między partnerami lub interesariuszami. Zwinne praktyki pomagają również w budowaniu zaufania między różnymi zespołami związanymi z procesem poprzez stymulowanie spójnej komunikacji i przekazywania wyników programowania. Jak wykazało badanie przeprowadzone przez Passivarę, Durasiewicza i Lasseniusa, jakość oprogramowania i korespondencja uległy poprawie, a komunikacja i skoordynowane działania są stosunkowo bardziej regularne w wyniku podejścia Scrum zastosowanego w przedsięwzięciu. Dodatkowo uznano, że inspiracja kolegów się rozszerzyła. W związku z tym przyjęcie zwinnych praktyk w środowisku rozproszonym okazało się cenne dla jakości projektu i jego realizacji. Tak więc można je postrzegać jako niektóre z korzyści uzyskanych dzięki połączeniu zwinności w rozwoju rozproszonym, jednak lista jest wyczerpująca. Główne korzyści można wymienić w następujący sposób:

Zwiększona różnorodność międzykulturowa i wewnątrzkulturowa

Rozproszone środowisko daje poczucie globalnego sposobu myślenia nad lokalnym sposobem myślenia, w którym zespół może wymieniać i akceptować pomysły, spostrzeżenia, kulturę, estetykę itp. Członkowie z różnych kultur mają możliwość zdobywania i dzielenia się wiedzą od swoich współpracowników, z alternatywnego punktu widzenia. W ten sposób mogą wdrażać nowe plany do zadania, rozważając je po wyjęciu z pudełka.

Elastyczne plany pracy

Członkowie zespołu mogą cieszyć się dużą swobodą i możliwościami w sposobie pracy, której jedynym celem jest wykonywanie zadań i terminowe oddanie produktów. Pozwala to również rozszerzyć zakres obowiązków wobec organizacji. W ten sposób pracownicy mogą zrównoważyć zarówno swoje życie zawodowe, jak i osobiste, a co za tym idzie, równowagę między życiem zawodowym a prywatnym można osiągnąć również w ten sposób.

Przemierzanie stref czasowych

Zespoły mogą obejmować wiele stref czasowych, w ten sposób uzyskując dostęp tak długo, jak długo można osiągnąć limit 24-godzinny. Zwiększa to produktywność, ponieważ ludzie są zatrudniani na całym świecie. Zadanie do wykonania nigdy nie zostaje zatrzymane, ponieważ zawsze jest ktoś, kto może zająć się problemem. Zapewnia to również, że praca jest wykonywana 24 godziny na dobę, 7 dni w tygodniu wokół słońca i prawie nie ma przestojów. Ponieważ środowisko rozproszone koncentruje się bardziej na produktywności i wydajności, przekazanie pracy pomaga w wykonaniu zadania.

Osoby niepełnosprawne i z ograniczeniami ruchowymi

Jak wspomniano, rozproszone, zwinne środowisko kładzie większy nacisk na produktywność i wydajność niż na obecność. Jest to korzystne dla osób niepełnosprawnych, ponieważ mają one swobodę pracy w wygodnym dla nich środowisku i przyczyniają się do osiągania rezultatów. Ten scenariusz ma również zastosowanie, gdy pracownik nie może być obecny w biurze i rejestrować godzin, może pracować z domu, aby wykonać zadania, nie wpływając tym samym na produkt końcowy.

Zwiększony poziom dobrobytu

Praca w rozproszonym, zwinnym środowisku zapewnia wyższy poziom dobrobytu i dobrego samopoczucia, zarówno jednostek, jak i całej firmy. Dzieje się tak dlatego, że nie ma dużego stresu dla tylko jednej osoby, aby ukończyć pracę, ponieważ praca jest dystrybuowana do wielu osób na całym świecie. W ten sposób zapewnia dobre samopoczucie fizyczne i psychiczne. Ponadto, ponieważ wiele osób wnosi swój wkład i przechodzi przez wiele iteracji, poprawia się końcowa jakość pracy, co jest korzystne dla firmy. Jest to więc sytuacja korzystna zarówno dla firmy, jak i jej pracowników.

Zredukowane koszty podróży

Praca w środowisku rozproszonym często wiąże się z koniecznością dyskusji i spotkań na temat celów, terminów, pracy itp. Jednak to przyjęcie zwinnych zasad i praktyk w środowisku rozproszonym pomaga zredukować koszty podróży, ponieważ otwiera platformę dla komunikować się za pośrednictwem wideokonferencji i innych możliwych opcji. To przełamuje potrzebę fizycznej obecności i wzmacnia ideę interakcji twarzą w twarz, dzięki czemu spotkania mogą być prowadzone z dowolnego miejsca na świecie i dostępne dla innych członków zespołu.

Iteracyjna koncepcja zwinności

Ponieważ postęp prac ma charakter iteracyjny, można regularnie sprawdzać stan rezultatu i czy wszyscy członkowie są na tym samym poziomie zrozumienia. Ponadto ten sposób ułatwia identyfikację błędów i usterek oraz może być poprawiany na wcześniejszych etapach, gdy proces przechodzi przez wiele iteracji. Zwiększony wkład na każdym etapie pracy skutkuje poprawą jakości produktu końcowego.

Bogata pula HR

Ponieważ ta sama praca jest wykonywana w różnych częściach świata, zwiększa to zakres umiejętności grupy poprzez dotarcie do szerszej puli zasobów ludzkich na całym świecie. Wprowadza to potrzebę, aby wszystkie działy HR działały jako jeden umysł, aby egzekwować współpracę i podejmować decyzje w różnych pionach i poziomach w organizacji, a także komunikować się z interesariuszami i ustalać priorytety wyników.

Zmniejsza powierzchnię biurową

Rozproszone, zwinne środowisko wzmacnia ideę pracy zdalnej, dzięki czemu nie jest już potrzebna rozbudowa przestrzeni biurowej, aby pomieścić więcej pracowników. Również różne rzeczy związane z pracą, takie jak elektryczność, komputery, parkingi samochodowe itp., Nie stanowią większego problemu, ponieważ pracownicy mają swobodę pracy w wybranym przez siebie środowisku. Jest to w pewnym sensie korzystne, ponieważ pomaga zaoszczędzić ogromną ilość pieniędzy, które w przeciwnym razie zostałyby wydane na te koszty ogólne. Iteracyjne doskonalenie z ciągłym dostarczaniem do klienta jest centralną praktyką w zwinnym ulepszaniu oprogramowania i taką, która zasadnie identyfikuje jedną z istotnych trudności związanych z obrotem wydarzeń na morzu: zmniejszoną dostrzegalność statusu projektu. Regularne fizyczne spotkania pozwalają liderom zespołów, kierownikom projektów, klientom i klientom śledzić postępy projektu na podstawie uzyskanej miary działającego oprogramowania.

Wyzwania i zagrożenia

Rozwój oprogramowania rozproszonego wiąże się z nieodłącznymi wyzwaniami wynikającymi z różnic przestrzennych, czasowych i społeczno-kulturowych między rozproszonymi zespołami. Połączenie tego z zasadami i praktykami zwinnymi z kolei zwiększa dotkliwość związanego z tym ryzyka, ponieważ obie metody są ze sobą w bezpośrednim kontraście. Zwinne tworzenie oprogramowania zostało pierwotnie zaprojektowane do użytku przez kolokowane zespoły, ponieważ opiera się na nieformalnej komunikacji i ścisłej współpracy. Rozwój rozproszony wymaga jednak formalnej komunikacji, jasnych standardów, ustalonych wytycznych i sztywnej struktury. W tej sekcji opisano zagrożenia i wyzwania związane ze zwinnym tworzeniem rozproszonego oprogramowania w wyniku wyżej wymienionych problemów ze zgodnością.

Wyzwania

W wyniku niezgodności, z jaką mamy do czynienia przy łączeniu zasad i praktyk zwinnych w środowisku rozproszonym, niektóre z wyzwań, które mogą się pojawić, są następujące:

Dokumentacja

Organizacje offshore preferują projektowanie oparte na planach, w ramach którego szczegółowe wymagania są wysyłane do budowy na morzu. Jest to sprzeczne z powszechną praktyką zespołów zwinnych, które nadają dokumentacji niższy priorytet. Rezultatem tej sytuacji jest to, że dużo częściej dochodzi do nieporozumień.

Programowanie par

Programowanie w parach, w którym dwóch programistów pracuje obok siebie nad konkretnym problemem, jest powszechną praktyką zwinną. Wykazano, że daje lepsze produkty w krótszym czasie, przy jednoczesnym utrzymaniu treści programistów w procesie. Ze względu na odległość między zespołami jest to o wiele trudniejsze do osiągnięcia.

Różne strefy czasowe

W zależności od strefy czasowej każdego rozproszonego zespołu trudniej jest umówić się na spotkanie w czasie, gdy oba zespoły są dostępne. Łatwo może dojść do sytuacji, w której jeden członek zespołu jest dostępny, a drugi nie jest na spotkania. Jest to szczególnie problem, jeśli bezpośrednie zadanie ma elementy programu, które są ściśle powiązane, w takim przypadku jeden zespół nie byłby w stanie kontynuować bez informacji zwrotnej drugiego.

Nauczanie

W środowisku rozproszonym minus braku możliwości ćwiczenia bliskiej komunikacji jest najbardziej odczuwalny w przypadku niedoświadczonych programistów, którzy muszą przejść fazę szkolenia. Szkolenie pracowników, którzy nie znajdują się w tej samej lokalizacji, jest trudne, pomyśl o różnicach w pochodzeniu i różnicach kulturowych, które utrudniają przyspieszenie tych niedoświadczonych członków zespołu. Z tego powodu należy rozważyć alternatywne sposoby nauczania.

Dystrybucja pracy

Jeśli chodzi o dystrybucję pracy, chcemy uniknąć architektury odzwierciedlającej geograficzne rozmieszczenie zespołu poprzez dystrybucję pracy w oparciu o lokalizację. Lepiej rozdzielić zadania związane z jedną historyjką użytkownika na cały zespół, myśląc w kategoriach historii, a nie komponentów. Nadmierna specjalizacja według lokalizacji geograficznej i/lub komponentu jest oznaką, że Twój zespół źle radzi sobie z wyzwaniami komunikacyjnymi stawianymi rozproszonym zespołom. Ta nadmierna specjalizacja ma niezamierzoną konsekwencję w postaci zmiany produktu w celu dostosowania go do rozwoju, a nie wymagań klienta.

Ryzyka

Badanie przeprowadzone w 2013 roku próbowało skonsolidować literaturę na temat zarządzania ryzykiem w rozproszonym rozwoju Agile. W bardziej kompleksowym badaniu podjęto próbę skategoryzowania czynników ryzyka dla rozproszonych projektów Agile, wykorzystując zarówno literaturę naukową, jak i rzeczywiste doświadczenia trzynastu organizacji IT. Ze względu na zwięzłość pominięto pełną listę 45 czynników ryzyka wraz z odpowiadającymi im technikami zarządzania. Zamiast tego podano krótkie podsumowanie głównych kategorii i ogólnych technik zarządzania.

Cykl życia oprogramowania

Ta kategoria obejmuje czynniki ryzyka związane z różnymi czynnościami związanymi z tworzeniem oprogramowania, takimi jak specyfikacja wymagań klienta oraz planowanie, modelowanie, budowanie i wdrażanie aplikacji. Wiele czynników ryzyka w tej kategorii wynika z nieefektywnego dzielenia się wiedzą. Niejasne cele, wymagania, różnice w praktykach standardowych procesów lub niespójności między projektami, by wymienić tylko kilka. Wiele z tych zagrożeń można kontrolować, upewniając się, że wiedza jest skutecznie udostępniana. Mówiąc dokładniej, upewnij się, że cel projektu jest jasny dla wszystkich zespołów, podobnie jak wymagania. Zautomatyzuj i ustandaryzuj jak największą część cyklu programistycznego, aby każdy zespół pracował z tym samym stosem technologii i infrastrukturą. Krótko mówiąc, upewnij się, że wszyscy są na tej samej stronie.

Zarządzanie projektami

Zarządzanie projektami odnosi się do zadań, takich jak planowanie projektu, organizowanie projektu, personel projektu, kierowanie projektem i kontrola. Ta kategoria obejmuje ryzyka związane z interakcjami między działaniami deweloperskimi a działaniami zarządczymi. Przyjęcie rozproszonego programowania Agile zmieni sposób, w jaki projekt musi być zarządzany. Jeśli nie zostanie to zrobione ostrożnie, ryzyko może obejmować niższą prędkość początkową, reorganizację zespołów w każdym sprincie lub brak jednolitości w możliwościach zespołu wielooddziałowego.

Świadomość grupowa

Czynniki ryzyka związane z brakiem świadomości grupy są zgrupowane w tej kategorii. Świadomość grupy wymaga intensywnej komunikacji, koordynacji, współpracy i zaufania między członkami grupy. Zespoły zlokalizowane w tej samej lokalizacji łatwiej osiągają tę świadomość, ponieważ wynika ona bardziej naturalnie z przebywania w tej samej fizycznej lokalizacji. Aby zarządzać ryzykiem związanym z brakiem świadomości grupy, rozproszone przestrzennie zespoły będą musiały zastosować bardziej zdyscyplinowane podejście w komunikacji z wykorzystaniem najnowszych narzędzi technologicznych. Praktyki, takie jak początkowo wspólna lokalizacja, aby wytyczyć ścieżkę projektu, okazały się skuteczne w zarządzaniu ryzykiem.

Współpraca interesariuszy zewnętrznych

Czynniki te dotyczą współpracy z klientami, dostawcami i zewnętrznymi programistami. Zarządzanie ryzykiem sprowadza się do upewnienia się, że koordynacja i komunikacja z podmiotami zewnętrznymi przebiegają sprawnie i przejrzyście.

Konfiguracja technologii

Czynniki ryzyka, które powstają w wyniku niewłaściwego użycia narzędzia, są zgrupowane w tej kategorii. Na przykład brak struktury komunikacji można rozwiązać, zapewniając zespołom środki do prowadzenia wideokonferencji. Poza tym ważny jest wybór odpowiednich narzędzi do wykorzystania podczas projektu. Może się to różnić w zależności od projektów, zespołów i przypadków użycia, dlatego zaleca się uprzednią analizę narzędzi, których należy użyć.

Narzędzia i najlepsze praktyki

Komunikacja

Jednym z najważniejszych czynników w pokonywaniu wyzwań stojących przed rozproszonym, zwinnym tworzeniem oprogramowania jest poprawa komunikacji. Oznacza to minimalizację czasu potrzebnego do skonfigurowania i przerwania sesji komunikacyjnej oraz preferowanie wideokonferencji zamiast konferencji głosowych, jeśli są dostępne.

Należy zachęcać do bezpośredniego kontaktu z całym zespołem, aby pomóc w budowaniu relacji. Korzystne jest zrobienie tego na początku, aby ustalić plan, którego zespół może przestrzegać przez cały czas trwania projektu. Ponadto jest to również korzystne w kilku ostatnich iteracjach przed wydaniem końcowego produktu.

Różnice stref czasowych

Jedną z możliwości rozwiązania problemu dostępności na spotkania ze względu na strefy czasowe jest wyznaczenie przedstawiciela zespołu, który pełni rolę pośrednika między dwoma zespołami, które nawiązały dobry kontakt z obydwoma. Inną opcją jest użycie zagnieżdżonego Scruma z wielopoziomowym raportowaniem i wieloma codziennymi spotkaniami Scrumowymi.

Rozwiązaniem pozwalającym organizować spotkania Scrumowe w zespołach, które radzą sobie z różnicami w strefach czasowych, jest rozróżnienie między lokalnymi spotkaniami zespołów a globalnymi spotkaniami Scrumowymi. Każdy zespół ma spotkanie lokalne na początku dnia i spotkanie globalne o innej porze dnia. Jest to możliwe tylko wtedy, gdy ich dni pracy nakładają się na siebie.

Nadążanie za zwinnymi praktykami

Ze względu na rozproszony charakter zespół może odejść od solidnie ustalonych praktyk zwinnych. Dlatego powinien być ktoś z rolą trenera, który utrzymuje zespół na właściwej drodze. Powinni również wziąć na siebie przemyślenie alternatyw dla rozproszonego środowiska pracy przy użyciu zwinnych praktyk.

Aby każdy członek zespołu był na bieżąco informowany o przyjętym podejściu zwinnym, ważne jest prowadzenie dokumentacji projektu. Poprawia to współpracę grupową przy stosowaniu zwinnych zasad i praktyk w rozproszonym środowisku tworzenia oprogramowania. W tym celu można wykorzystać różne narzędzia, które wspierają zespół w prowadzeniu dokumentacji.

Używanie narzędzi

Do poprawy komunikacji w środowisku rozproszonym można wykorzystać różne narzędzia i platformy. Są one nawet ważniejsze niż w środowisku nierozproszonym, aby zminimalizować wirtualną odległość między rozproszonymi zespołami.

Komunikacja

Dostępne są różne narzędzia wspierające komunikację w rozproszonym tworzeniu oprogramowania . Narzędzia asynchroniczne, takie jak poczta e-mail, narzędzia synchroniczne, takie jak oprogramowanie do konferencji audio i wideo, oraz narzędzia hybrydowe, takie jak komunikatory, zapewniają członkom zespołu środki do organizowania niezbędnych spotkań i komunikacji. Innym przykładem są narzędzia obsługujące sieci społecznościowe w celu tworzenia wspólnych doświadczeń między członkami zespołu w różnych lokalizacjach.

Zarządzanie projektami

Aby pokierować projektem i upewnić się, że wszystkie zespoły i członkowie zespołu mają jasną wizję pracy do wykonania, należy korzystać z platform do zarządzania projektami, takich jak narzędzia do zarządzania problemami.

Narzędzia programistyczne

Aby zapewnić wspólne doświadczenie dla każdego członka zespołu, każdy członek zespołu powinien mieć dostęp do tych samych narzędzi do ich rozwoju. Posiadanie tych samych narzędzi do zarządzania konfiguracją oprogramowania połączonych z narzędziami do zarządzania projektami umożliwia programistom pracę w tym samym tempie i komunikowanie się o rozwoju w podobny sposób.

Zarządzanie wiedzą

Aby zapewnić każdemu członkowi zespołu dostęp do tej samej wiedzy na temat produktu i jego rozwoju, można wykorzystać narzędzia takie jak oprogramowanie Wiki lub bazy wiedzy.

Zgodność z Manifestem Agile

Wartości i zasady Manifestu Agile zostały zbadane pod kątem ich zastosowania w rozproszonym środowisku pracy w 12 studiach przypadków. W badaniach śledzono firmy programistyczne, które w swoich projektach zastosowały rozproszone zwinne tworzenie oprogramowania. Spośród 12 przypadków 10 spółek lądowych znajdowało się w Stanach Zjednoczonych, a siedem spółek offshore w Indiach. Wyniki podsumowano w poniższej tabeli:

Cechy promowane przez Manifest Agile	Przypadek 1	Przypadek 2	Przypadek 3	Przypadek 4	Przypadek 5	Przypadek 6	Przypadek 7	Przypadek 8	Przypadek 9	Przypadek 10	Przypadek 11	Przypadek 12
Wartości
Jednostki i interakcje ponad procesami i narzędziami	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Działające oprogramowanie ponad obszerną dokumentację	✓	✓	✓	✓	✓			✓	✓	✓	✓	✓
Współpraca z klientem ponad negocjowanie kontraktów				✓	✓	✓			✓
Reagowanie na zmiany zamiast podążania za planem	X				X	X					✓
Zasady
Wczesna i ciągła dostawa wartościowego oprogramowania	✓	✓	✓	X	X	X		✓			✓
Mile widziane zmieniające się wymagania nawet na późnym etapie rozwoju
Często dostarczaj działające oprogramowanie	✓	✓	✓				✓	✓	✓	✓	✓	✓
Ludzie biznesu i programiści współpracują ze sobą w całym projekcie	✓			✓	✓	✓			✓
Twórz projekty wokół zmotywowanych osób, wspieraj je i ufaj im				✓	✓	✓		✓
Rozmowa twarzą w twarz w zespole programistów	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Działające oprogramowanie jest podstawową miarą postępu	✓	✓	✓	✓	✓	✓	✓		✓	✓		✓
Promuj zrównoważony rozwój, aby utrzymać stałe tempo w nieskończoność		✓	✓							✓	✓	✓
Ciągła dbałość o doskonałość techniczną i dobry projekt			✓	✓	✓			✓		✓
Prostota jest niezbędna											✓
Samoorganizujące się zespoły			✓				✓			✓	✓
Zespół regularnie dostosowuje zachowanie w celu zwiększenia efektywności										✓	✓

Z tego dowiadujemy się, że wszystkie studia przypadków podkreślały pierwszą wartość Manifestu Agile, która stwierdza, że jednostki i interakcje powinny być cenione bardziej niż procesy i narzędzia. Manifest Agile przedkłada działające oprogramowanie nad obszerną dokumentację, niekoniecznie całkowicie negując dokumentację. Wartość ta znajduje również odzwierciedlenie w większości przypadków. Zidentyfikowano tylko cztery przypadki, w których podkreśla się znaczenie współpracy z klientem nad negocjowaniem umowy. Jak wyraźnie widać z tabeli, czwarta wartość została przyjęta najmniej ze wszystkich wartości przez firmy produkujące oprogramowanie: „zamiast ściśle przestrzegać powszechnie zdefiniowanych praktyk programistycznych zwinnych, firmy stale je modyfikują, aby dopasować je do zmieniających się potrzeb ich projekty”. Jeśli chodzi o zasady Agile, nie jest zaskoczeniem, że we wszystkich badaniach ceniona jest rozmowa twarzą w twarz z zespołem programistów. To było symulowane elektronicznie między zespołami lądowymi i morskimi. Żadna z firm programistycznych biorących udział w badaniu nie przedstawiła szczegółowych informacji na temat tego, czy należy być otwartym na zmiany wymagań nawet na późnym etapie rozwoju. Dzięki temu możemy założyć, że nie była ona uważana za tak ważną jak niektóre inne zasady.

Linki zewnętrzne