Czego większość "guru" Agile nie rozumie w rozwoju sprzętu

Metodyka Agile, zakorzeniona w świecie rozwoju oprogramowania, została okrzyknięta siłą transformacyjną w branży technologicznej. Jednak, gdy wkraczamy w świat rozwoju sprzętu i elektroniki, pozornie płynna adaptacja zasad Agile napotyka labirynt wyzwań i nieporozumień. W naszej pierwszej części tej trzyczęściowej eksploracji, analizowaliśmy wyzwania Agile wynikające z różnic między rozwojem sprzętu a oprogramowania. W tym artykule badamy mity rozpowszechniane przez "guru" Agile.

Zanim zagłębimy się w zawiłości Agile w rozwoju sprzętu elektronicznego, ważne jest, aby wyjaśnić, że naszym celem nie jest dyskredytowanie trenerów i konsultantów Agile. Doceniamy ich dobre intencje i entuzjazm do pomocy klientom w czerpaniu korzyści z metodologii Agile. Chociaż niektóre krytyki mogą wynikać z ograniczonego zrozumienia niuansów sprzętu, intencją nie jest krytykowanie, ale skuteczne dostosowanie zasad Agile, aby sprostać specyficznym wymaganiom rozwoju sprzętu. Naszym celem jest dostosowanie taktyk Agile, aby wykorzystać jego korzyści w tym unikalnym kontekście, modyfikując podejście, ale zachowując zasady.

Mit #1: Musisz pozostać elastyczny i dostosowywać się

Eksperci Agile słusznie wychwalają zalety iteracyjnego wykonania, pętli sprzężenia zwrotnego, i szybkiej adaptacji, które odniosły sukces w cyfrowym świecie oprogramowania. Jednakże, przeniesienie tych zasad do namacalnego krajobrazu sprzętu i elektroniki wprowadza warstwę złożoności, której nie znajdziemy w czysto cyfrowym spektrum. Fizyczne rozwiązania, w przeciwieństwie do ich oprogramowaniowych odpowiedników, muszą być "gotowe" do zamawiania części, wytwarzania form i spełniania rygorystycznych wymagań produkcyjnych. Wezwanie Agile do ciągłej zmiany koliduje z nieubłaganą naturą sprzętu, gdy nawet drobne zmiany są wymagane na późnym etapie.

W odpowiedzi, dostosowanie Agile do rozwoju sprzętu wymaga zmiany paradygmatu. Nie chodzi o nieustanne modyfikacje, ale o świadome, strategiczne adaptacje i prototypowanie. Opierają się one na szybkich cyklach uczenia się i wykonania, których celem jest maksymalizacja wartości w ramach ograniczeń czasu, budżetu i zasobów. Taneczny krok między zwinnością Agile a wymaganiami finalności fizycznego produktu wymaga bardziej świadomego planowania iteracji i głębokiego zaangażowania w redukcję ryzyka na przestrzeni całego projektu.

Mit #2: Musisz opracować działający prototyp w każdym sprincie

Podczas gdy rozwijanie w pełni funkcjonującego prototypu co dwa do trzech tygodni w ramach "sprintu" jest często propagowane przez purystów Agile jako uniwersalny "mus" bycia Agile, praktyczna wykonalność tego podejścia rozpada się w obliczu rzeczywistości rozwoju sprzętu i elektroniki (oraz budżetu). Pomysł, aby coś zbudować, zademonstrować postęp i wykorzystać ten wynik do uzyskania cennych technicznych i komercyjnych informacji zwrotnych, które poinformują Twoją następną iterację, jest słuszny. Jednak każdy projekt sprzętowy to odrębna jednostka ze swoimi celami, zależnościami, ograniczeniami czasu realizacji, obszarami wymaganej innowacji i ryzykiem. I każdy projekt zasługuje na własne unikalne podejście do prototypowania i uczenia się.

Aby naprawdę przyjąć zwinny rozwój produktów sprzętowych, zespoły muszą porzucić mentalność "jedno rozwiązanie dla wszystkich". Zamiast tego, muszą dokładnie zbadać potrzeby projektu, a następnie współpracować, aby wypracować kreatywną strategię uczenia się i prototypowania. Ważne jest, aby rozpoznać, że "prototyp" może być dowolnym demonstracyjnym wynikiem, począwszy od wstępnego prospektu, przez makietę z pianki (jak słynny prototyp iPoda Steve'a Jobsa, który mieści "1000 piosenek w twojej kieszeni"), aż po częściowo lub w pełni funkcjonujące prototypy.

Mit #3: Dodaj historie do backlogu i po prostu zacznij

Jedną z zasadniczych zalet metodyk zwinnych (Agile) jest ich zdolność do szybszego rozpoczęcia projektu niż tradycyjne podejścia typu waterfall. W rzeczywistości, dla projektów elektronicznych opartych na Agile, zaobserwowaliśmy znaczące skrócenie okresu od identyfikacji koncepcji do rozpoczęcia rozwoju. Ten okres, który często trwał wiele miesięcy, a nawet lat w tradycyjnym, fazowym podejściu, został skrócony do kilku tygodni lub dni dzięki metodom Agile. Oczywiście, część tej dramatycznej zmiany wynika z tego, jak definiujemy "rozpoczęcie rozwoju".

Dla oprogramowania jest to proste. Guru metodyki Agile promują pisanie Historii Użytkownika, aby zdefiniować funkcje oprogramowania, ustawić je w kolejności priorytetów w backlogu i rozpocząć Sprint. Jednak w przypadku sprzętu, przynajmniej minimalne wstępne planowanie jest konieczne, aby poprowadzić projekt we właściwym kierunku, zrozumieć architekturę, kluczowe pożądane atrybuty, ograniczenia i inne czynniki. To wstępne wysiłek może wydawać się sprzeczny z zasadami Agile, że "działające oprogramowanie jest głównym miernikiem postępu" oraz "witaj zmieniającym się wymaganiom, nawet późno w rozwoju."

Pojednanie polega na znalezieniu równowagi poprzez dostosowanie powszechnie zrozumiałych taktyk Agile do początkowej fazy rozwoju produktu. Zarządzanie projektem Agile dla sprzętu pozwala na szybkie rozpoczęcie, dostosowując się do strategicznych intencji projektu i akceptując znacznie więcej nieznanych niż tradycyjne podejścia. Zespoły mogą następnie współpracować, używając iteracyjnej nauki Agile do zdefiniowania optymalnego rozwiązania, w połączeniu z nastawieniem otwartym na strategiczne zmiany, które zwiększają wartość produktu, jednocześnie pozostając w ramach ograniczeń harmonogramu i zasobów.

Mit #4: Definiuj wszystkie swoje zadania jako Historie Użytkownika

Jedną z kluczowych zasad, którą wielu guru Agile głosi, jest to, że cała praca nad rozwojem powinna być definiowana jako Historie Użytkownika. Rada ta mówi dalej, że komponenty systemu, interfejsy, inni inżynierowie itp., powinni być traktowani jako "Użytkownicy". Ta porada sprawia, że większość deweloperów elektroniki i sprzętu drapie się po głowie i ma trudności z jej zastosowaniem.

Jednym z głównych powodów, dla których zespoły programistyczne tak chętnie przyjęły praktyki Agile, jest to, że dokumentowanie potrzeb klienta za pomocą tradycyjnych dokumentów wymagań i szczegółowych przypadków użycia było niezwykle marnotrawne i dodawało niewiele wartości dla zespołu. Dlaczego więc nie zadeklarować, co użytkownik próbuje zrobić, napisać Historię Użytkownika, aby udokumentować funkcję, a następnie traktować to jako zadanie rozwojowe? To nie tylko samo-dokumentujące się, ale jeśli te historie są konsekwentnie priorytetyzowane i weryfikowane z klientami, mamy idealny zamknięty system do reagowania na zmiany i optymalizacji wartości. Super!

Próba bezpośredniego zapisywania Historii Użytkownika jako elementów pracy w rozwoju sprzętu, jednocześnie odnosząc je do wartościowych rezultatów dla klienta, często stanowi punkt, w którym wiele zespołów zajmujących się sprzętem łamie zasady Agile. Definiowanie sprzętu jest po prostu inne niż definiowanie oprogramowania. Tradycyjne Dokumenty Wymagań Produktu (PRD) oraz specyfikacje funkcjonalne nie tylko dają poczucie komfortu deweloperom sprzętu, ale również dostarczają szczegółów niezbędnych do podziału i realizacji ich pracy. Prośba do deweloperów o napisanie Historii Użytkownika takiej jak: "Jako jednostka przetwarzająca, potrzebuję regulacji napięcia, aby zapewnić czyste wejście..." mija się z celem uchwycenia wartości dla klienta poprzez Historie Użytkownika i dodaje zbędne marnotrawstwo, które deweloperzy oprogramowania byli tak zdesperowani, aby usunąć z zasad Agile.

Jak definiuje Mike Cohn, wczesny lider myśli w zakresie Agile dla oprogramowania: "Historia Użytkownika to krótki, prosty opis funkcji, opowiedziany z perspektywy osoby." Kluczowym słowem tutaj jest "osoba". Agile dla zespołów zajmujących się sprzętem może czerpać znaczącą wartość z pisania Historii Użytkownika, ale musi używać ich do uchwycenia potrzeb klientów od ludzi, a nie do definiowania elementów pracy. Te historie muszą następnie być przekształcane na atrybuty produktu i powiązane elementy pracy, które zaspokajają pożądane rezultaty za pomocą technik, które mają sens dla deweloperów sprzętu.

Mit #5: Musisz mieć dedykowanych członków zespołu

Ankieta na LinkedIn przeprowadzona przez Vitality Chicago pokazała, że 54% praktyków Agile twierdzi, że posiadanie dedykowanego zespołu Scrum lub Agile (co oznacza dedykowanych członków zespołu) jest istotną zasadą Agile. Chociaż w Manifeście Agile nie ma dyskusji na temat dedykowanych zespołów, guru Agile często traktują to jako regułę i trudno jest argumentować, że nie byłoby wielu korzyści z posiadania członków zespołu skupionych w 100% na projekcie. Byłoby niewiele wymówek dla nieosiągania zobowiązań, nic by nie odwracało uwagi od sukcesu, i nikt by nie mówił: "Ten inny projekt ma w tym tygodniu wyższy priorytet!"

Jednakże, jeśli kiedykolwiek pracowałeś w środowisku rozwoju sprzętu, wiesz, że posiadanie dedykowanych członków zespołu byłoby luksusem, na który niewiele organizacji może sobie pozwolić. Specyfika rozwoju sprzętu polega na tym, że architekci, główni projektanci i inni eksperci (SME) są często potrzebni w wielu projektach. Firma może mieć jednego eksperta od częstotliwości radiowych, który jest wzywany, gdy potrzebna jest jego wiedza, specjalistę od układów, który jest potrzebny w kluczowych momentach itp. Zespoły zajmujące się rozwojem sprzętu mogą nadal korzystać i wykorzystywać metody Agile, ale posiadanie dedykowanych członków zespołu zazwyczaj nie jest opcją. Dlatego posiadanie podejścia do zarządzania zasobami wspierającego Agile jest kluczowe dla długoterminowego sukcesu Agile.

#Mit 6: Agile to suma jego zdefiniowanych ról, rytuałów, ceremonii i słownictwa

Dwa zespoły pracują obok siebie w firmie: zespół zajmujący się sprzętem, korzystający z tradycyjnego podejścia wodospadowego, oraz zespół programistów, używający metod Scrum. Deweloper sprzętu przechodzi obok sali konferencyjnej, gdzie programiści zbierają się w kręgu i słyszy: "Ok, witamy na naszym spotkaniu. Podczas ostatniego sprintu mieliśmy problemy z oszacowaniem punktów historii użytkownika i kryteriami akceptacji. Nasz scrum master podzielił się z nami najnowszym wykresem spalania i przeprowadził retrospekcję, aby rozwiązać problemy w naszym przygotowaniu backlogu, abyśmy mogli zwiększyć prędkość. Zróbmy 'pięść-do-pięciu' jak się czujemy w związku ze zmianami." Szybko pojawia się szereg konfiguracji pięści i palców.

Deweloper sprzętu, choć zaintrygowany, nie może oprzeć się uczuciu lekkiego zakłopotania tym dziwnym rytuałem i obfitością nieznanych terminów, zastanawiając się, jak te metodyki Agile mogłyby być możliwe do zastosowania w jego świecie namacalnego rozwoju sprzętu. "Czy ja przypadkiem nie wtrąciłem się do jakiegoś kultu?!" zastanawia się w duchu.

Często guru Agile są tak zanurzeni w języku i kulturze Agile dla oprogramowania, że wierzą, iż zespoły zajmujące się sprzętem muszą przyjąć dokładnie te same ceremonie, role, narzędzia i język, aby naprawdę "być Agile". Ironią jest, że pierwsza zasada w Manifeście Agile brzmi: "Indywidualności i interakcje ponad procesami i narzędziami". Myślę, że możemy na tym budować i dalej stwierdzić, "Indywidualności i interakcje ponad procesami, narzędziami, rytuałami i dogmatami." Chociaż zgoda na język, formaty spotkań i konkretne działania, aby zbudować mentalność Agile i systematyczny sposób pracy są kluczowe dla sukcesu, przyjmowanie konkretnych rytuałów i słownictwa Scruma czy Agile dla oprogramowania nie jest konieczne. Zespoły zajmujące się sprzętem muszą przyjrzeć się celowi i intencji każdego elementu Agile, ceremonii i roli oraz określić, co i jak każdy z nich może najlepiej spełnić ich potrzeby.

Łączenie luki między Agile a sprzętem

Gdy zastanawiasz się, czy podejście Agile jest odpowiednie dla twoich działań związanych z rozwojem sprzętu i elektroniki, konwencjonalna "mądrość" propagowana przez dobrze intencjonowanych guru Agile często okazuje się niewystarczająca, aby poprowadzić bardziej zniuansowane, adaptacyjne podejście wymagane przez rozwój fizycznych produktów. Droga do udanej implementacji Agile w sprzęcie obejmuje przemyślane połączenie elastyczności, przygotowań wstępnych, iteracyjnego planowania oraz świadomego podejścia do zbiegania się na najbardziej wartościowe rozwiązanie możliwe w najkrótszym czasie.

W zakończeniu naszej trzyczęściowej serii, zagłębimy się dalej w wykorzystywanie zalet zmodyfikowanej metodyki Agile dla rozwoju sprzętu elektronicznego, jednocześnie przestrzegając podstawowych zasad metodyki Agile. Czy jesteś zainteresowany(a) bardziej szczegółowym zbadaniem tematu? Obejrzyj webinar!