#01 - Scrum w dziale Hardware R&D

Czym rozwój sprzętu różni się od rozwoju oprogramowania? Prawie wszystkim. Czy to oznacza, że nie da się rozwijać produktów sprzętowych w Scrumie? Da się i jest kilka firm, które są na to świetnym dowodem. Co prawda agile jest software-native, ale po odpowiednim dostosowaniu dobrze sprawdza się również w hardwarze. Problemem jest to, że jak na razie niewiele produktów nie-software’owych jest rozwijanych w Scrumie. Dla oprogramowania jest masa doświadczonych Scrum Masterów, konsultantów i masa materiału, z którego można czerpać pełnymi garściami. W hardware takich osób można szukać ze świecą. A eksperymenty ze zwinnością często trzeba okupić własną krwią.

Transcript

Czym rozwój sprzętu różni się od rozwoju oprogramowania? Prawie wszystkim. Czy to oznacza, że nie da się rozwijać produktów sprzętowych w Scrumie? Da się i jest kilka firm, które są na to świetnym dowodem. Co prawda agile jest software-native, ale po odpowiednim dostosowaniu dobrze sprawdza się również w hardwarze. Problemem jest to, że jak na razie niewiele produktów nie-software’owych jest rozwijanych w Scrumie. Dla oprogramowania jest masa doświadczonych Scrum Masterów, konsultantów i masa materiału, z którego można czerpać pełnymi garściami. W hardware takich osób można szukać ze świecą. A eksperymenty ze zwinnością często trzeba okupić własną krwią.

Jakie są najważniejsze różnice?

Zmiana funkcjonalności z czasem staje się bardzo trudna i kosztowna

Załóżmy, że chcesz, żeby urządzenie działało na jednej baterii tydzień. W toku prac dowiadujesz się od użytkowników, że oni spodziewaliby się raczej dwóch tygodni na jednej baterii. Niby drobna zmiana funkcjonalna, a oznacza duże zmiany w źródle zasilania, elektronice i obudowie. Często oznacza to zaprojektowanie wszystkiego niemal od zera. Albo jeżeli nagle orientujemy się, że nasze urządzenie musi być wodoodporne, a mamy już gotowe formy wtryskowe, niezbędne do przygotowania obudów, które zupełnie nie uwzględniają możliwości zastosowania technologii niezbędnej do zapewnienia szczelności. Setki tysięcy złotych właśnie zostały wyrzucone do kosza.

Nie da się co Sprint stworzyć produktu, który będzie choćby potencjalnie gotowy do wydania

Spróbuj polecieć samolotem, gdy zespół odpowiedzialny za skrzydła, jeszcze nie skończył swojej roboty. Produkt sprzętowy wymaga co najmniej kilku miesięcy pracy, żeby być gotowym do tego, żeby zapewnić użyteczność klientom. W branżach regulowanych, takich jak medyczna, dochodzą jeszcze miesiące na certyfikację i dopuszczenie produktu do sprzedaży.

Zakończenie pracy w R&D nie oznacza wdrożenia produkcyjnego

Rzadko kiedy zakończenie prac w dziale badawczo-rozwojowym oznacza, że jesteśmy gotowi przekazać klientowi produkt do użytkowania. Tak może być przy produkcji pojedynczych sztuk, ale nie przy produkcji masowej. W takim wypadku czeka nas jeszcze wdrożenie produkcyjne - niezależnie od tego, czy będzie wykonywane naszymi siłami, czy skorzystamy z podwykonawców. Zazwyczaj produkcja pierwszych kilkudziesięciu urządzeń też różni się od produkcji kolejnych tysięcy. 

Testowanie produktu z użytkownikami jest trudne

Skoro pierwszy sprzęt potencjalnie gotowy do przekazania użytkownikom dostaniemy dopiero po kilu miesiącach, to jak możemy wcześniej testować nasz produkt? Bo chyba nie muszę nikogo przekonywać, że rozpoczęcie testów dopiero w tym momencie nie jest najlepszym pomysłem. Jest na to kilka sposobów, o czym za chwilę.

Błędów czasami nie da się naprawić

Trzeba zrobić na nie obejście. W IT powszechnie stosowane są obejścia dla znanych problemów, ale najczęściej jest to rozwiązanie tymczasowe - do pojawienia się kolejnej wersji produktu lub wypuszczenia łatki. W sprzęcie czasami naprawienie błędu jest na danym etapie zbyt kosztowne lub wręcz niemożliwe - wynikające z błędu w jakimś komponencie dostarczanym przez firmę zewnętrzną. Warto więc mieć świadomość takich obejść i prowadzić ich spis.

Jest bardzo dużo zależności zewnętrznych - wewnątrz firmy i poza nią, których nie da się łatwo usunąć

Duże firmy, które tworzą wiele podobnego do siebie sprzętu, mogą pozwolić sobie na zakup wszystkich niezbędnych technologii i zatrudnienie ludzi ze wszystkimi niezbędnymi kompetencjami. W mniejszych firmach i w firmach, w których technologie wykorzystywane w produktach bardzo się różnią, niemal nigdy nie uda się zgromadzić wszystkich technologii u siebie.

Aby stworzyć produkt hardware’owy potrzeba wielu różnych specjalistów i wielu różnych kompetencji

Wiem, że w IT również bywają zespoły, które wymagają wielu kompetencji, ale i tak zazwyczaj udaje się zbudować krosfunkcjonalny zespół ograniczony do 9 osób, który może faktycznie zrealizować produkt od pomysłu do wdrożenia. W hardware jest to możliwe tylko przy naprawdę nieskomplikowanych produktach lub wspierając się w dużej części podwykonawcami i składając tylko wszystko w całość.

Wiedza o Scrumie wśród inżynierów poza IT jest niemal zerowa

Kiedy w IT przychodzi do pracy nowy inżynier, to niemal na pewno miał styczność ze Scrumem. Gdy w hardwarze do pracy przychodzi nowy inżynier, to prawie na 100% nie miał styczności nie tylko ze Scrumem, ale również z ideą zwinności. OK w IT też rzadko można spotkać dobrego Scruma, ale gdy zatrudniasz nową osobę do IT, to chociaż nie trzeba jej tłumaczyć kim jest Product Owner i Scrum Master oraz co to jest Backlog.

Czego nauczyłem się pracując z zespołami hardware’owymi?

Dobry podział na zespoły jest kluczowy do efektywnej pracy i rzadko kiedy będą to zespoły w pełni krosfunkcjonalne. Takie rozwiązanie byłoby dobre, ale bardzo ciężko będzie złożyć zespół, który posiada wszystkie niezbędne kompetencje. Co więcej, niektóre kompetencje będą kluczowe dla pracy każdego takiego zespołu, ale tak naprawdę rzadko potrzebne. To oznacza szkolenie wielu osób z czegoś, co przydaje się dwa razy do roku. Innym problemem jest konieczność stworzenia gildii dla każdej z takich specjalizacji, aby osoby te mogły wymieniać wiedzę i doświadczenia przy różnych projektach. Dlatego w hardwarze dużo bardziej sprawdzają się zespoły komponentowe.

Wadą takiego rozwiązania jest dosłownie generowanie zależności pomiędzy zespołami. Dlatego tak ważna jest prawdziwa samoorganizacja zespołów i dobra współpraca międzyzespołowa. Te zespoły - tak jak zresztą w IT - powinny raczej być stałe, dlatego tak kluczowy jest ich podział, żeby co produkt nie musieć modyfikować składów zespołów. I tu dochodzimy do problemu dobrej synchronizacji pracy wszystkich zespołów zaangażowanych w rozwój jednego produktu.

Skalowanie w IT najczęściej wynika z chęci przyspieszenia prac nad produktem, choć jeden zespół - w dłuższej perspektywie - mógłby sam zrealizować wszystkie prace. W hardware jest to konieczność, ponieważ w pracę nad jednym produktem musi być zaangażowanych kilkanaście, kilkadziesiąt, a nawet kilkaset osób. Tu pojawia się konieczność posiadania jednej osoby - nazwijmy ją Chief Product Ownerem (CPO), która spina cały produkt. 

Co więcej - planowanie w długim terminie jest kluczowe dla sukcesu produktu. W przypadku produktów hardware’owych planowanie nawet 2-3 Sprinty naprzód, to zdecydowanie za mało. Rolą Product Ownerów jest posiadanie ogólnego planu na cały produkt i myślenie bardzo do przodu. Scrum Masterów uczy się wymagania od Zespołów Deweloperskich, żeby najpierw domykali tematy, które już rozpoczęli. W produktach sprzętowych nie zawsze się to uda. Czasami dany element trzeba najpierw wybrać, zamówić próbkę i przetestować, żeby później czekać 12 tygodni na dostarczenie kilkudziesięciu sztuk, niezbędnych do złożenia prototypów.

Z tego i innych powodów, wiele rzeczy trzeba przewidzieć wprzód. Część rzeczy robi się też nadmiarowo, bo gdy się jednak okaże, że będą potrzebne, bardzo trudno będzie je dodać na etapie, gdy mamy już obudowę dopasowaną do elektroniki znajdującej się w środku. Tutaj od razu przypomina mi się, że w projekcie nie powinno się wykorzystywać elementów, które są Not Recomended for New Design (NRND), a tym bardziej takich, które mają zaplanowany termin End of life (EOL). Prawie na pewno będzie to oznaczało - jeszcze przed końcem projektu - konieczność zmiany tego elementu na inny lub zakup “na magazyn” dużej partii tych elementów na potrzeby produkcji seryjnej.

Jako że pierwszą wersję gotowego produktu dostajemy często dopiero po kilku miesiącach i często jest już za późno na duże zmiany, sprzęt testuje się inaczej. Testy prowadzi się na wybranych elementach produktu, w oderwaniu od reszty. Np. testy klapki i złącz baterii prowadziliśmy ostatnio na uproszczonych wydrukach 3D ze specjalnie spreparowaną elektroniką w środku. W testach z użytkownikami wiele rzeczy się fejkuje (np. drukując ekrany, czy symulując reakcję na dotyk lub ruch). W IT też jest to też dość popularne, ale tam raczej są to tylko wczesne prototypy, w hardware jest to na porządku dziennym nawet w późnych fazach projektu. A testować trzeba, bo wiele założeń technicznych może się okazać błędnych. Kto by na przykład pomyślał, że nadruk UV na poliwęglanie (PC) ma dużą trwałość, a z polietylenu (PE) można go zdrapać paznokciem…?

Nie wszystko da się sformułować w formie historyjek użytkownika i nie każde wymaganie może przynosić bezpośrednią wartość użytkownikowi. W ten sposób można rozwijać firmware i software, ale już nie hardware. Wymagania różnią się też istotnie od siebie, dlatego większość wymagań znajdziemy w kryteriach akceptacji, a tylko niewielką wspólną część w Definition of Done (DoD). Część wymagań będzie bardzo techniczna i będzie wymagała wiedzy fachowej. Jasne, zawsze można zostawić Product Ownerowi tylko wizję i spięcie całości, a Zespół Deweloperski zaprząc do tworzenia wymagań, ale zazwyczaj się to nie sprawdza. Dlatego w zespołach sprzętowych w roli Product Ownerów dużo lepiej sprawdzają się inżynierowie. Zdarza się, że łączą w ten sposób pracę Product Ownera i Dewelopera, jednak i tak kończy się to na tym, że praca PO wypełnia im niemal całe Sprinty.

A Sprinty te będą raczej dłuższe niż w IT. Większość zespołów w IT, które widziałem, pracowało w 2-tygodniowych Sprintach, rzadziej w 1-tygodniowych. Sprinty dłuższe niż 2-tygodniowe w softwarze to obecnie rzadkość. Przy pracy nad sprzętem, 2 tygodnie to często za mało, żeby ogarnąć wszystkie zależności zewnętrzne i stworzyć coś wartościowego. Krótsze Sprinty wymagają dzielenia wymagań na nielogiczne części i dokładają tylko pracę zespołowi. Więc jeżeli nie ma wyraźnych przesłanek dla krótszych Sprintów, spokojnie można zostać przy 3-4 tygodniowych. Niektóre firmy mówią nawet, że w ich przypadku działają dopiero 6-tygodniowe przebiegi. Odrębnym tematem jest synchronizacja Sprintów pomiędzy zespołami pracującymi nad jednym produktem, która jest bardzo pożądana, bo ułatwia planowanie długoterminowe i integrację na poziomie całego produktu.

Ostatnim tematem, który chcę dzisiaj poruszyć jest dokumentacja. Tak często pogardzana i pomijana w przypadku software’u, tutaj okazuje się kluczowym elementem. Jest niezbędna, bo pozwala odtworzyć i wdrożyć produkcyjnie to, co zaprojektowaliśmy - nie wystarczy skopiowanie kodu na kolejny serwer. Dlatego warto ją rozwijać na bieżąco. Pomocne będzie tu dodanie takiego zapisu do Definition of Done.

Czy to nadal jest czysty Scrum? Nie sądzę. Nie ma potencjalnie dostarczalnego przyrostu co sprint, a Zespół Scrumowy nie jest samowystarczalny. Czy to oznacza, że mamy tu Scrumbut? Raczej nie. To nie jest sytuacja, w której wybiórczo stosujemy to, co nam pasuje. To poprostu specyfika wytwarzania sprzętu.

Jeżeli chcesz wdrożyć Scrum w zespole hardware’owym, to weź pod uwagę te rzeczy, a także to, w jakiej branży działa Twoja firma. Inne elementy okażą się kluczowe w branży automotive, a inne przy produkcji zabawek dla dzieci. Na decyzje wpływ będzie miała też wielkość produkcji - jednostkowa lub masowa, a także sposób samej produkcji - manufaktura, produkcja własna, a może zlecona do realizacji w fabryce w Chinach.