Zwinny sprzęt z wbudowanym tworzeniem oprogramowania

Tworzenie złożonych ekosystemów sprzętowych i programowych, które dopasowują produkt do rynku, jest trudnym zadaniem. Podczas gdy większość startupów sprzętowych ostatecznie upada, ponieważ kończą im się pieniądze, według raportu CB Insights, największym podstawowym powodem jest brak popytu na ich produkty. To tylko podkreśla znaczenie roli menedżera produktu dla startupów sprzętowych, ponieważ ich głównym celem jest określenie potrzeb klientów i problemów w celu dostarczenia udanego produktu.

Ostatnia firma, którą prowadziłem, stworzyła ekosystem aplikacji webowych, mobilnych, wbudowanych oraz urządzeń sprzętowych dla branży parkingowej. Strategia dotycząca produktów sprzętowych była częścią mojej codziennej pracy, co doprowadziło mnie do eksperymentów z różnymi przepływami pracy przy opracowywaniu produktów sprzętowych. Pomimo pracy z produktami sprzętowymi przez 10 lat i posiadania licencjata z elektroniki i telekomunikacji, wciąż musiałem się wiele nauczyć w pracy. Stworzyłem poniższy przewodnik w nadziei, że będziesz mógł szybciej niż ja szybciej zająć się zarządzaniem produktami na sprzęcie z osadzonym oprogramowaniem.

Wyzwania związane z zarządzaniem produktami sprzętowymi

Podczas gdy SaaS i aplikacje mobilne można łatwo tworzyć przy użyciu zwinnych frameworków, wyjątkowe warunki w rozwoju oprogramowania wbudowanego i urządzeń sprzętowych znacznie utrudniają stosowanie zasad zwinnych. W tej pierwszej sekcji omówimy cechy rozwoju sprzętu, które tworzą złożoność. Nie wszystkie z nich mają proste rozwiązania, ale istnieją sposoby na zmniejszenie trudności poprzez zastosowanie określonych strategii rozwoju sprzętu, które zostaną omówione w następnej sekcji.

Wyspecjalizowany talent techniczny trudno znaleźć lokalnie

Tworzenie nowych produktów sprzętowych jest znacznie trudniejsze niż iterowanie na istniejących. Wiąże się to z dużą kreatywnością i doświadczeniem w prototypowaniu, czego rzadko uczy się na uczelniach. Niektóre uczelnie nie mają nawet obiektów prototypowania lub narzędzi niezbędnych do rozwijania tych umiejętności, a takie doświadczenie zdobywa się prawie wyłącznie w większych korporacjach sprzętowych, które posiadają centra badawczo-rozwojowe. Znalezienie lokalnych specjalistów z odpowiednią wiedzą może być zatem bardzo trudne, w wyniku czego wielu założycieli startupów sprzętowych musi poszerzyć swoją pulę talentów poprzez zatrudnianie zdalne.

Systemy kontroli wersji nie są przystosowane do konstrukcji sprzętu

Większość systemów kontroli wersji (VCS) jest zorientowanych na obsługę formatu tekstowego, ponieważ zostały one stworzone do wspólnej pracy nad tworzeniem oprogramowania. W projektach dotyczących rozwoju sprzętu informacje są zamiast tego pakowane w pliki projektowe tworzone za pomocą specjalnych narzędzi, takich jak OrCAD. Niektóre z tych narzędzi obsługują tylko pliki binarne, które nie są nawet zoptymalizowane do użycia w systemach VCS. CADLAB to stosunkowo nowa próba stworzenia VCS kompatybilnego ze sprzętem i miejmy nadzieję, że w niedalekiej przyszłości pojawi się więcej takich narzędzi.

Zakłady produkcji sprzętu są przeniesione

Zakłady produkcji sprzętu są często zlokalizowane w innym regionie, kraju lub kontynencie. Komunikacja między producentem sprzętu a producentem wymaga szczególnej uwagi i jest kluczem do udanej dostawy produktu. Skuteczna komunikacja wymaga bardziej strategicznych ram, aby zapewnić jakość produktu i zapewnić, że poradzi sobie ze zmianami na etapie dynamicznej walidacji produktu na rynku. Aby to osiągnąć, producent sprzętu musi stworzyć wiele szczegółowych specyfikacji przesyłanych do producenta. Ramy współpracy muszą zapewniać szybkie dostarczanie informacji i zarządzanie cyklem życia specyfikacji, ponieważ mogą one łatwo szybko stracić aktualność.

Zmiany sprzętowe są mniej elastyczne

Popularny model operacyjny w start-upach oprogramowania poświęca jakość na rzecz szybkości na wczesnych etapach. Nawet Facebook od dłuższego czasu głosił mantrę „poruszaj się szybko i psuj rzeczy”. Innym znanym podejściem jest „udawaj, aż ci się uda”. Działa to w przypadku uruchamiania oprogramowania ze względu na niskie koszty infrastruktury i usprawnione struktury programistyczne, które umożliwiają programistom codzienne wdrażanie aktualizacji kodu.

Chociaż takie podejście do rozwoju powoli wkradło się w przestrzeń sprzętową, jest to niefortunny trend w tej dziedzinie, ponieważ znacznie trudniej jest wprowadzać i wdrażać zmiany sprzętowe. Koszty rozwoju zrównoważyły ​​wartość uzyskaną dzięki szybkim i częstym wydaniom, więc w rzeczywistości o wiele bardziej pożądaną strategią jest inwestowanie więcej w fazę projektowania w celu stworzenia dźwiękowych architektur sprzętowych.

Pułapka crowdfundingu

Wiele startupów wpada w pułapkę przekonania, że ​​uruchomienie skutecznej kampanii crowdfundingowej sprzętu jest równoznaczne z weryfikacją rynkową. Finansowanie społecznościowe odnosi największe sukcesy w przypadku produktów zawierających komponent sprzętowy, szczególnie z powodu naszego nieświadomego pragnienia posiadania własności fizycznej obiektu. Jednak finansowanie społecznościowe nie ma na celu walidacji produktu na dużą skalę, ale raczej demokratyczny sposób finansowania rozwoju produktu na wczesnym etapie. Niefortunna rzeczywistość jest taka, że ​​wiele firm z udanymi kampaniami crowdfundingowymi stwierdziło później, że skalowanie produkcji było trudne lub prawie niemożliwe, ponieważ nie zwalidowały swojego rynku na dużą skalę.

Certyfikaty, Przepisy i Aprobaty

Wszystkie produkty sprzętowe wymagają pewnego rodzaju certyfikacji, aby były sprzedawane. Jest to jeden z najczęściej pomijanych kroków na bardzo wczesnych etapach wprowadzania produktów sprzętowych na rynek. W jaki sposób ograniczenie certyfikacji wpłynie na plan produktu i ramy stosowane do rozwoju? Nierzadko planuje się wczesne fazy projektu z certyfikacją i innymi zatwierdzeniami jako kamień milowy projektu, a następnie warunkowo cofa się do fazy początkowej. Menedżerowie produktu mogą zamiast tego dokładnie analizować przepisy, zależności i bramy decyzji strategicznych planu produktu w podejściu przypominającym kaskadę.

Możliwości zarządzania produktami sprzętowymi

Teraz, gdy omówiliśmy już niektóre wyzwania występujące w sprzęcie z oprogramowaniem wbudowanym, przyjrzyjmy się teraz, jak sprawić, by proces rozwoju był bardziej uproszczony i przewidywalny, aby zniwelować nieodłączne trudności związane z rozwojem sprzętu.

Włącz Agile do rozwoju sprzętu

Doświadczeni menedżerowie produktów są świadomi wyzwań związanych z tworzeniem produktów sprzętowych z wbudowanym oprogramowaniem, które stara się wykorzystać szansę rynkową, jaką stwarzają nowe osiągnięcia technologiczne. Uczą się równoważyć przyspieszenie czasu wprowadzenia produktu na rynek bez narażania prawdopodobieństwa sukcesu produktu już na etapie planowania. W większości przypadków przybiera to formę podejścia typu water-scrum-fall.

Faza tworzenia pomysłów na produkt rozszerza zasady produktu, cele i funkcje na wysokim poziomie w tak wielu szczegółach, jak to możliwe. Świetni menedżerowie produktu spędzają więcej czasu na dopracowywaniu rezultatów tej fazy: wizji, misji, oceny możliwości, celów sprzętowych i funkcji. Jest to północna gwiazda produktu, która musi być wystarczająco wyraźna przed rozpoczęciem pracy nad jakimkolwiek prototypem sprzętu, dlatego zalecane jest podejście kaskadowe.

Niezbędne jest posiadanie dobrze udokumentowanych wymagań i specyfikacji funkcjonalnych produktów sprzętowych, a także dobrej architektury technicznej dla oprogramowania wbudowanego napędzającego produkt sprzętowy. Zmiany w wymaganiach i specyfikacjach powinny być karane, a nie zachęcane po ich podpisaniu przez cały zespół.

Podczas tworzenia oprogramowania wbudowanego można zastosować standardową metodologię scrum. Dostosowanie i udoskonalanie implementacji oprogramowania w celu pracy z predefiniowaną architekturą sprzętową jest mniej kosztowne pod względem czasu i pieniędzy niż na odwrót.

Ostateczne testy integracyjne i testy akceptacyjne użytkownika powinny być przeprowadzane w warunkach kaskadowych. Na tym etapie faza rozwoju jest zakończona, a nowe funkcjonalności i brakujące funkcje są rejestrowane jako dodatkowe zlecenia pracy na kolejny okres planowania.

Włącz Agile do tworzenia oprogramowania wbudowanego

Tworzenie złożonych produktów sprzętowych z wbudowanym oprogramowaniem wpływa na sposób stosowania tradycyjnych metodologii tworzenia oprogramowania. Wiele systemów używanych do tworzenia oprogramowania działającego na komputerze osobistym nie nadaje się do tworzenia oprogramowania wbudowanego, ponieważ istnieją ograniczenia związane z niedoborem zasobów i znacznie dłuższymi cyklami rozwoju.

Grupa naukowców i specjalistów z Brazylii zaoferowała potencjalne rozwiązanie: Metodologia projektowania oprogramowania oparta na platformach dla wbudowanych systemów sterowania: Agile Toolkit . Ta metodologia uwzględnia zasady Agile w tworzeniu oprogramowania wbudowanego. Poniżej znajduje się krótkie podsumowanie metodologii, ale zdecydowanie zaleca się, aby menedżerowie produktów sprzętowych zapoznali się z pełnym opisem przed zastosowaniem go w swojej praktyce.

Role zaangażowane w tę metodologię to:

• Właściciel platformy – Odpowiedzialny za określenie celów jakościowych, planistycznych i kosztowych
• Lider produktu – Odpowiedzialny za wdrożenie, integrację i testowanie produktu
• Lider funkcji – Odpowiedzialny za zarządzanie projektami podsystemów i śledzenie postępów w dostarczaniu funkcji
• Zespół programistów – Praca nad rozwojem produktu

Metodologia dzieli rozwój oprogramowania wbudowanego na trzy grupy procesów:

1. Grupa procesów platformy systemowej. System wybiera komponenty systemu, które będą częścią architektury i platform API, z biblioteki platformy i dostosowuje je do wymagań danej aplikacji. Proces dostosowywania jest realizowany w cyklach iteracyjnych poprzez programowanie procesorów konfigurowalnych przez projektanta i logiki rekonfigurowalnej w czasie wykonywania zintegrowane z platformą.
2. Grupa procesów rozwoju produktu. Funkcjonalności składające się na produkt są podzielone na elementy sprzętowe lub programowe platformy. Metodologia zapewnia algorytmy partycjonowania uwzględniające zużycie energii, czas wykonania i rozmiar pamięci komponentów aplikacji.
3. Grupa procesów zarządzania produktem monitoruje i kontroluje zakres produktu, parametry czasowe, jakościowe i kosztowe. Sugerowane podejścia składają się głównie z praktyk promowanych przez metodę Scrum Agile oraz wzorców zwinnych.

Utwórz program rozwoju sprzętu

Zorganizowanie programu rozwoju sprzętu na wczesnym etapie umożliwiło firmom zapewnienie szybkiej zmiany lub planu B. Z biznesowego punktu widzenia może to zmniejszyć marże finansowe, ale ostatecznie zapewnia elastyczność niezbędną do radzenia sobie z ciągle zmieniającym się rynkiem warunków w zakresie produktów wypuszczanych przez konkurencję oraz zaawansowanych możliwości technologicznych.

Załóżmy, że firma prowadzi udaną kampanię crowdfundingową dotyczącą swojego produktu sprzętowego z wbudowanym oprogramowaniem. Świetnie sprawdzają się przy pierwszej partii produktów, dopóki duża firma o ugruntowanej pozycji nie ogłosi czegoś podobnego. Najważniejsza jest wszechstronność i czas wprowadzenia produktu na rynek, a pragmatyczna i sprawna reakcja na tę sytuację zwiększa prawdopodobieństwo sukcesu produktu. Posiadając program rozwoju sprzętu, firma może szybko dostosować się i umieścić w centrum uwagi bogatszą wersję produktu w odpowiedzi na konkurencję.

Pomyślne testowanie sprzętu za pomocą oprogramowania wbudowanego

Testowanie jest kluczowym elementem zarządzania produktem sprzętowym, ponieważ, w przeciwieństwie do testowania oprogramowania zwinnego, większość błędów sprzętowych można naprawić jedynie poprzez wyprodukowanie nowej partii produktów. Urządzenia Samsung Galaxy Note 7, które stanęły w ogniu, są doskonałym przykładem tego, dlaczego testowanie sprzętu powinno być najwyższym priorytetem dla wszystkich menedżerów produktów.

Testy funkcjonalne są kluczowym celem walidacji technicznej sprzętu z wbudowanym oprogramowaniem. Złożoność tych procedur wynika z faktu, że błędy mogą pochodzić z dowolnej części systemu.

Testy jednostkowe zwykle odbywają się w symulowanym środowisku po każdym sprincie, ponieważ symulowany sprzęt ma tę zaletę, że jest doskonale kontrolowany. Skrypty testowe mogą być zautomatyzowane, mogą nadzorować wykonywanie i zabijać testy, które wydają się zawieszone, nie dając żadnych wyników.

Testowanie integracji powinno uwzględniać operacje online i offline oraz poddanie produktu sprzętowego do rzeczywistych warunków operacyjnych. Na przykład, jeśli firma opracuje montowany na głowie system monitorowania mózgu podczas zajęć na świeżym powietrzu, warunki testowe powinny uwzględniać te cechy.

Testowanie systemu obejmuje testowanie całego systemu pod kątem błędów i błędów. Test ten jest przeprowadzany poprzez połączenie elementów sprzętowych i programowych całego systemu (które zostały wcześniej przetestowane pod kątem jednostkowym i integracyjnym), a następnie testowane jako całość. Testy te są wymienione w ramach metody testowania czarnej skrzynki, w której oprogramowanie jest sprawdzane pod kątem scenariuszy oczekiwanych przez użytkownika, potencjalnych wyjątków i warunków brzegowych. Wymienione specjalne kategorie testów:

• Testowanie wyzwalane zdarzeniami: inicjowane przez określone zdarzenia lub zmiany stanu w okresie eksploatacji produktu sprzętowego (np. uruchomienie, reset, zamknięcie). Jego celem jest wykrywanie trwałych usterek.
• Testowanie wyzwalane czasowo: Inicjowane o wstępnie skonfigurowanych godzinach normalnej pracy systemu, wykonywane okresowo w celu wykrycia trwałych usterek. Jest to przydatne w systemach działających przez długi czas, w których nie występują żadne znaczące zdarzenia wyzwalające test. Testowanie wyzwalane czasowo jest również przydatne do wykrywania sporadycznych usterek.

Akceptacja produktu sprzętu z wbudowanym oprogramowaniem

Wartość produktu w przypadku produktów sprzętowych z wbudowanym oprogramowaniem jest zwykle weryfikowana po etapie akceptacji produktu w metodologii water-scrum-fall. Sprzęt z wbudowanym ekosystemem oprogramowania musi dawać pierwszeństwo sprzętowi przed oprogramowaniem w celu weryfikacji i akceptacji. Jak wspomniano wcześniej, zmiany sprzętowe są trudniejsze i droższe do wykonania. Menedżerowie produktu często wymyślają innowacyjne rozwiązania, wymagane do rozwiązywania problemów z akceptacją lub dostosowania wartości, biorąc pod uwagę ograniczenie polegające na niemożności zmiany sprzętu i faworyzowaniu dodatkowych iteracji w dziedzinie tworzenia oprogramowania.

Znakomici menedżerowie produktu mają przenikliwość produktu i ogromną moc wizji w prognozowaniu potrzeb sprzętowych i ustalaniu priorytetów odpowiednich dołączanych funkcji, tak aby model biznesowy był solidny, akceptacja była solidna, a użytkownicy cieszyli się z korzystania z produktu. Biorąc pod uwagę oprogramowanie wbudowane, „dekoracja” sprzętu nie powinna być zaskakująca, ponieważ musi przestrzegać zasad i ograniczeń, kierując się procesami rozwoju sprzętu, procedurami certyfikacji, wyzwaniami produkcyjnymi i akceptacją rynkową.

Rozwój sprzętu wymaga zwinności zarządzanej

Agile szturmem podbiło świat tworzenia oprogramowania i teraz zaczęło wkradać się w przestrzeń sprzętową. Jednak warunki produktu sprzętowego z oprogramowaniem wbudowanym niosą ze sobą różne wyzwania:

• Brak wyspecjalizowanego talentu
• Systemy kontroli wersji, które nie są przystosowane do sprzętu
• Zlokalizowane zakłady produkcyjne
• Zmiany, które są trudniejsze do wprowadzenia w porównaniu z oprogramowaniem
• Wymagania dotyczące certyfikacji i przepisów, które nakładają przeszkody w planowaniu

Wyzwania te utrudniają stosowanie zasad Agile w taki sam sposób, jak robią to firmy programistyczne.

Aby stawić czoła tym wyzwaniom, potrzebne jest zarządzane podejście zwinności w formie water-scrum-fall. Oprogramowanie wbudowane jest tworzone zgodnie ze standardowymi procedurami scrum, podczas gdy inne kroki, takie jak ideacja, tworzenie specyfikacji i testowanie, są wdrażane w konfiguracji kaskadowej. Pozwala to producentom sprzętu na czerpanie korzyści, jakie oferuje Agile, przy jednoczesnym utrzymaniu funkcjonującego podejścia do zarządzania produktem, które musi uwzględniać różne ograniczenia wymienione powyżej. To zarządzane podejście zwinności zapewnia udaną drogę naprzód w kontekście szybko zmieniających się warunków rynkowych i ciągłych ulepszeń technologicznych.