Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Jeśli ostatnia dekada "transformacji Agile" nauczyła nas czegoś, to tego, że nie istnieje jedno uniwersalne rozwiązanie do przyjęcia lub wdrażania podejścia Agile. Każda organizacja ma różne potrzeby, ograniczenia i wymagania. Ślepe podążanie za przepisem nie doprowadzi do sukcesu.
Ruch Agile polega na ciągłym znajdowaniu sposobów ulepszania praktyki tworzenia oprogramowania. Nie chodzi o doskonały codzienny standup lub retrospektywę. Zamiast tego chodzi o tworzenie kultury, w której właściwa rzecz dzieje się częściej niż nie. Działania takie jak standupy i retrospektywy mają swoje miejsce, ale nie zmienią kultury organizacji.
W tym artykule szczegółowo opisano podstawowe elementy, które każda organizacja potrzebuje, aby stworzyć sposób myślenia i kulturę Agile. Zalecenia nie powinny być przestrzegane ślepo. Każda organizacja powinna stosować to, co ma sens w danym środowisku.
Harmonogram i rytm
Nie ma idealnej długości sprintu. Zespoły odniosły sukces z długościami sprintu, które wahają się od jednego do czterech tygodni. Najważniejszą sprawą jest spójność.
Wybierz długość sprintu, która działa dla kultury organizacji, produktu i chęci organizacji do dostarczania aktualizacji. Na przykład, dział Developer Tools w firmie Microsoft (około 6000 osób) pracuje w trzytygodniowych sprintach. Zespół kierowniczy nie wybrał długości sprintu, ale wynika ona z bezpośrednich opinii zespołów inżynieryjnych. Cały dział działa według tego trzytygodniowego harmonogramu sprintu. Sprinty od tego czasu stały się pulsem organizacji. Teraz każdy zespół maszeruje w rytm tego samego bębna.
Ważne jest, aby wybrać czas trwania sprintu i trzymać się jego. Jeśli istnieje wiele zespołów Agile, wszystkie powinny używać tej samej długości sprintu. Jeśli opinie napędzają zmianę, bądź otwarty. Stanie się jasne, kiedy obowiązują właściwe terminy.
Kultura wysyłki
Peter Provost, główny menedżer programów grupy w firmie Microsoft, powiedział: "Nie można oszukiwać w dostarczaniu." Prostota i prawda tego stwierdzenia stanowią fundament kultury Agile. Peter chce powiedzieć, że dostarczanie oprogramowania nauczy Cię rzeczy, których nie jesteś w stanie zrozumieć, chyba że faktycznie dostarczysz swoje oprogramowanie.
Ludzka natura ma opóźniać lub unikać robienia rzeczy, dopóki nie będzie to absolutnie konieczne. To nie może być bardziej prawdziwe, jeśli chodzi o tworzenie oprogramowania. Zespoły odkładają usuwanie usterek do końca cyklu, nie rozważają konfiguracji ani uaktualnienia, dopóki nie będą zmuszone, i zazwyczaj unikają takich aspektów jak lokalizacja i ułatwienia dostępu, kiedy tylko jest to możliwe. Gdy ten wzorzec się pojawi, zespoły tworzą dług techniczny, który będzie musiał zostać wypłacony w późniejszym czasie. Wysyłka wymaga zapłaty wszystkich długów. Nie można uniknąć wysyłki. Aby ustanowić kulturę Agile, zacznij od próby wydania produktu na końcu każdego sprintu. Na początku nie będzie łatwo, ale gdy zespół spróbuje tego, szybko odkryje wszystkie rzeczy, które powinny się dziać, ale się nie dzieje.
Zespoły w dobrej kondycji
Nie ma przepisu dla idealnego zespołu Agile. Jednak kilka kluczowych cech znacznie ułatwia osiągnięcie sukcesu.
Współlokuj zespoły zawsze, gdy jest to możliwe
Czy zespół może znaleźć sukces z ludźmi rozmieszczonymi w różnych lokalizacjach geograficznych? Tak, ale jest to trudniejsze. Gdy ludzie znajdują się w tym samym miejscu i siedzą w tym samym pokoju, odpowiednie rozmowy po prostu się odbywają. Nadal można odnieść sukces z zespołami znajdującymi się na całym świecie i w różnych strefach czasowych. Ale czy ten sam zespół nie ma przewagi bez tych wszystkich przeszkód?
Utrzymuj zespoły w niezmienionym składzie przez rozsądny okres czasu
Umożliwia zespołom opanowanie sztuki tworzenia oprogramowania razem. Gdy zespoły są przemieszane, każda chemia zespołowa, którą wypracowali, zostaje zakłócona. Czasami właściwe jest zreorganizowanie, ale zespoły są zazwyczaj bardziej produktywne, gdy otrzymują czas, aby dowiedzieć się, jak współpracować. Zgodnie z wytycznymi, staraj się zachować zespoły nienaruszone przez co najmniej 12 miesięcy.
Równoważenie obciążenia pracy, a nie osób
Czasami zespoły stoją w tyle i potrzebują pomocy. Typową taktyką rozwiązania tego problemu jest wypożyczenie osoby od jednego zespołu do drugiego. Może to być jednak nieproduktywne. Lepszym rozwiązaniem jest przekazanie zadań do innego zespołu, a nie równoważenie obciążenia pomiędzy zespołami. Ściąganie osoby z jednego zespołu, aby pomóc innemu, zakłóca pracę obu zespołów i może sfrustrować osobę przenoszoną, nawet jeśli zmiana jest tymczasowa. Wszystko to wpływa na produktywność zespołu i, co jest bardziej prawdopodobne niż nie, negatywnie wpływa na zdolność powrotu do harmonogramu.
Równoważenie obciążenia pracy zamiast ludzi pozwala ustalonemu zespołowi wkroczyć i pomóc. Zamiast rozmowy o ludziach, koncentrujemy się na priorytetach.
Pozwól zespołom na przypisanie odpowiedzialności za obszary funkcji, zamiast warstw architektury
Staraj się tworzyć zespoły pionowe, które odpowiadają za obszary funkcji. Te zespoły są odpowiedzialne za całą pracę wymaganą do dodawania funkcji do ich obszaru, od bazy danych do zmian interfejsu użytkownika. Zespół ma uprawnienia aby dostarczać i zarządzać całym procesem od początku do końca.
Gdy zespoły poziome posiadają warstwy architektury, żaden zespół nie jest odpowiedzialny za kompleksowe środowisko pracy. Dodanie funkcji wymaga, aby wiele zespołów koordynowało i wymaga wyższego poziomu zarządzania zależnościami. Rozwiązywanie usterek wymaga, aby wiele zespołów zbadało, czy jest właścicielem kodu wymaganego do naprawienia usterki. Usterki są przekazywane między zespołami, gdy zespoły określają, że nie jest to ich usterka i przypisują je innemu zespołowi.
Zespoły funkcji nie mają tych problemów. Własność i odpowiedzialność są jasne. Może istnieć miejsce dla niektórych zespołów opartych na architekturze. Jednak zespoły skoncentrowane w pionie są bardziej skuteczne.
Dalsze kroki
Gdy zespoły rozpoczynają własną transformację Agile, pamiętaj o tych podstawowych zasadach. Pamiętaj, że nie ma jednego przepisu, który będzie działać dla każdej organizacji. Przekształcenia Agile to podróż. Wprowadź zmiany i naucz się od nich. W miarę upływu czasu organizacja opracuje potrzebną kulturę Agile.
Firma Microsoft jest jedną z największych firm Agile na świecie. Dowiedz się więcej o tym, jak firma Microsoft przyjęła kulturę Agile na potrzeby planowania metodyki DevOps.
Dowiedz się, jak usługa Azure DevOps umożliwia zespołom wdrażanie i skalowanie kultury Agile.