임베디드 소프트웨어 개발을 통한 애자일 하드웨어

제품/시장 적합성을 찾는 복잡한 하드웨어 및 소프트웨어 생태계를 구축하는 것은 어려운 작업입니다. CB Insights의 보고서에 따르면 대부분의 하드웨어 스타트업은 궁극적으로 자금 부족으로 실패하지만 가장 큰 근본적인 이유는 실제로 제품에 대한 수요 부족입니다. 이는 하드웨어 스타트업의 주요 목표가 성공적인 제품을 제공하기 위해 고객의 요구 사항과 문제점을 파악하는 것이기 때문에 제품 관리자 역할이 하드웨어 스타트업에 얼마나 중요한지를 강조할 뿐입니다.

내가 마지막으로 운영한 회사는 주차 산업을 위한 웹, 모바일, 임베디드 소프트웨어 애플리케이션 및 하드웨어 장치의 생태계를 만들었습니다. 하드웨어 제품 전략은 제 일상 업무의 일부였으며, 이로 인해 다양한 하드웨어 제품 개발 워크플로를 실험하게 되었습니다. 10년 동안 하드웨어 제품과 함께 일하고 전자 및 통신에서 학사 학위를 받았음에도 불구하고 직장에서 여전히 배울 것이 많았습니다. 저보다 더 빨리 임베디드 소프트웨어 공간이 있는 하드웨어 내에서 제품 관리에 대한 속도를 높일 수 있기를 바라는 마음에서 아래 가이드를 만들었습니다.

하드웨어 제품 관리의 과제

애자일 프레임워크를 사용하여 SaaS 및 모바일 앱을 쉽게 개발할 수 있지만 임베디드 소프트웨어 및 하드웨어 장치 개발의 고유한 조건으로 인해 애자일 원칙을 적용하기가 훨씬 더 어렵습니다. 이 첫 번째 섹션에서는 복잡성을 만드는 하드웨어 개발의 특성을 다룰 것입니다. 그들 모두가 간단한 솔루션을 가지고 있는 것은 아니지만 다음 섹션에서 다룰 특정 하드웨어 개발 전략을 사용하여 어려움을 줄이는 방법이 있습니다.

전문 기술 인재는 현지에서 찾기 어렵습니다.

새로운 하드웨어 제품을 만드는 것은 기존 제품을 반복하는 것보다 훨씬 어렵습니다. 그것은 대학에서 거의 가르치지 않는 프로토타이핑에 대한 많은 창의성과 경험을 포함합니다. 일부 대학에는 이러한 기술을 개발하는 데 필요한 프로토타이핑 시설이나 필요한 도구조차 없으며 이러한 경험은 거의 독점적으로 R&D 센터가 있는 대규모 하드웨어 회사에서 얻을 수 있습니다. 따라서 관련 전문 지식을 갖춘 현지 전문가를 찾는 것은 매우 어려울 수 있으며, 그 결과 많은 하드웨어 스타트업 창업자가 원격 고용을 통해 인재 풀을 확장해야 합니다.

버전 제어 시스템은 하드웨어 설계에 적합하지 않습니다.

대부분의 버전 제어 시스템(VCS)은 소프트웨어 개발 공동 작업을 위해 만들어졌기 때문에 텍스트 형식을 지원하는 데 중점을 두고 있습니다. 하드웨어 개발과 관련된 프로젝트에서 정보는 대신 OrCAD와 같은 특수 도구를 사용하여 생성된 설계 파일에 포함됩니다. 그리고 이러한 도구 중 일부는 VCS에서 사용하도록 최적화되지 않은 바이너리 파일만 지원합니다. CADLAB은 하드웨어 호환 VCS를 만들기 위한 비교적 새로운 시도이며 가까운 장래에 이와 같은 도구가 더 많이 있기를 바랍니다.

하드웨어 생산 시설이 현지화되지 않음

하드웨어 생산 시설은 종종 다른 지역, 국가 또는 대륙에 있습니다. 하드웨어 생산자와 제조업체 간의 커뮤니케이션은 특별한 고려가 필요하며 성공적인 제품 배송의 핵심입니다. 성공적인 커뮤니케이션을 위해서는 제품의 품질을 보장하고 역동적인 제품-시장 검증 단계의 변화에 ​​대처할 수 있도록 보다 전략적인 틀이 필요합니다. 이를 달성하기 위해 하드웨어 생산자는 제조업체에 보내는 많은 세부 사양을 생성해야 합니다. 협업 프레임워크는 정보의 빠른 전달과 사양 수명 주기 관리를 보장해야 합니다. 사양은 쉽게 구식이 될 수 있기 때문입니다.

하드웨어 변경의 유연성이 떨어짐

소프트웨어 스타트업에서 인기 있는 운영 모델은 초기 단계에서 속도를 위해 품질을 희생합니다. 심지어 페이스북도 꽤 오랫동안 "빨리 움직이고 일을 깨라"는 만트라를 옹호했습니다. 또 다른 친숙한 접근 방식은 "할 때까지 가짜"입니다. 이는 개발자가 매일 코드 업데이트를 배포할 수 있도록 하는 저렴한 인프라 비용과 간소화된 프로그래밍 프레임워크로 인해 소프트웨어 스타트업에 적합합니다.

개발에 대한 이러한 접근 방식은 하드웨어 공간에 서서히 스며들었지만 하드웨어 변경 사항을 만들고 배포하는 것이 훨씬 더 어렵기 때문에 이 분야에서는 불행한 추세입니다. 개발 비용은 빠르고 빈번한 릴리스를 통해 얻은 가치를 상쇄하므로 실제로는 건전한 하드웨어 아키텍처를 만들기 위해 설계 단계에 더 많은 투자를 하는 것이 훨씬 더 바람직한 전략입니다.

크라우드펀딩의 함정

많은 신생 기업은 성공적인 하드웨어 크라우드 펀딩 캠페인을 시작하는 것이 시장 검증과 동일하다는 생각에 사로잡혀 있습니다. 크라우드 펀딩은 하드웨어 구성 요소가 포함된 제품에서 가장 성공적인 경향이 있습니다. 특히 물리적 개체와 관련된 무의식적인 소유 욕구 때문에 그렇습니다. 그러나 크라우드 펀딩은 대규모로 제품을 검증하기 위한 것이 아니라 초기 단계 제품 개발 자금을 조달하는 민주적인 방법입니다. 불행한 현실은 성공적인 크라우드 펀딩 캠페인을 가진 많은 회사들이 규모에 맞게 시장을 검증하지 않았기 때문에 생산 규모를 확장하는 것이 어렵거나 거의 불가능하다는 것을 알게 되었다는 것입니다.

인증, 규정 및 승인

모든 하드웨어 제품을 판매하려면 일종의 인증이 필요합니다. 하드웨어 제품을 시장에 출시하는 초기 단계에서 가장 간과되는 단계 중 하나입니다. 인증 제약은 제품 계획 및 개발에 적용되는 프레임워크에 어떤 영향을 미칩니까? 인증 및 기타 승인을 프로젝트 이정표로 사용하여 프로젝트의 초기 단계를 계획한 다음 조건부로 시작 단계로 역추적하는 것은 드문 일이 아닙니다. 대신 제품 관리자는 보다 폭포수 같은 접근 방식으로 규정, 종속성 및 제품 계획 전략적 의사 결정 게이트웨이를 주의 깊게 분석할 수 있습니다.

하드웨어 제품 관리의 기회

임베디드 소프트웨어 분야의 하드웨어에 존재하는 몇 가지 문제를 다루었으므로 이제 하드웨어 개발의 고유한 어려움을 상쇄하기 위해 개발 프로세스를 보다 능률적이고 예측 가능하게 만드는 방법을 살펴보겠습니다.

하드웨어 개발에 애자일 통합

경험 많은 제품 관리자는 새로운 기술 개발로 창출된 시장 기회를 이용하려는 임베디드 소프트웨어로 하드웨어 제품을 구축하는 데 따르는 어려움을 알고 있습니다. 그들은 계획 단계에서 제품 성공 가능성을 손상시키지 않으면서 시장 출시 시간을 단축하는 균형을 배웁니다. 대부분의 경우 이것은 워터 스크럼 낙하 방식을 통해 형성됩니다.

제품 구상 단계는 제품 원칙, 목표 및 높은 수준의 기능을 가능한 한 많은 세부 사항으로 확장합니다. 훌륭한 제품 관리자는 비전, 사명, 기회 평가, 하드웨어 제품 목표 및 기능과 같은 이 단계의 결과물을 개선하는 데 더 많은 시간을 할애합니다. 이것은 모든 종류의 하드웨어 프로토타입 작업을 시작하기 전에 충분히 명확해야 하는 제품의 북극성이므로 폭포수 접근 방식을 권장합니다.

하드웨어 제품에 대한 잘 문서화된 요구 사항 및 기능 사양은 물론 하드웨어 제품을 구동하는 임베디드 소프트웨어에 대한 우수한 기술 아키텍처를 갖는 것이 중요합니다. 요구 사항 및 사양의 변경은 패널티를 받아야 하며 전체 팀이 승인한 후에는 권장하지 않습니다.

임베디드 소프트웨어를 개발할 때 표준 스크럼 방법론을 사용할 수 있습니다. 사전 정의된 하드웨어 아키텍처로 작업하기 위해 소프트웨어 구현을 조정하고 개선하는 것은 그 반대의 경우보다 시간과 비용 면에서 저렴합니다.

최종 통합 테스트 및 사용자 승인 테스트는 폭포수 조건에서 수행해야 합니다. 이 단계에서 개발 단계가 완료되고 새로운 기능과 누락된 기능이 다음 계획 기간에 대한 추가 작업 요청으로 기록됩니다.

애자일을 임베디드 소프트웨어 개발에 통합

임베디드 소프트웨어로 복잡한 하드웨어 제품을 구축하면 기존 소프트웨어 개발 방법론이 적용되는 방식에 영향을 미칩니다. 개인용 컴퓨터에서 실행되는 소프트웨어를 생산하는 데 사용되는 많은 시스템은 리소스 부족과 훨씬 더 긴 개발 수명 주기에 대한 제약이 있기 때문에 임베디드 소프트웨어 개발에 적합하지 않습니다.

브라질의 학계 및 전문가 그룹이 다음과 같은 잠재적 솔루션을 제안했습니다. 임베디드 제어 시스템을 위한 플랫폼 기반 소프트웨어 설계 방법론: 애자일 툴킷 . 이 방법론은 애자일 원칙을 임베디드 소프트웨어 개발에 통합합니다. 다음은 방법론에 대한 간략한 요약이지만 하드웨어 제품 관리자는 실제에 적용하기 전에 전체 설명을 읽는 것이 좋습니다.

이 방법론과 관련된 역할은 다음과 같습니다.

• 플랫폼 소유자 – 품질, 계획 및 비용 목표 정의 책임
• 제품 리더 – 제품의 구현, 통합 및 테스트를 담당합니다.
• 기능 리더 – 하위 시스템 프로젝트를 관리하고 기능 결과물의 진행 상황을 추적하는 책임이 있습니다.
• 개발팀 – 제품 개발 작업

방법론은 임베디드 소프트웨어 개발을 세 가지 프로세스 그룹으로 나눕니다.

1. 시스템 플랫폼 프로세스 그룹. 시스템은 플랫폼 라이브러리에서 아키텍처 및 API 플랫폼의 일부가 될 시스템 구성 요소를 선택하고 해당 응용 프로그램의 제약 조건을 충족하도록 사용자 지정합니다. 사용자 정의 프로세스는 플랫폼에 통합된 디자이너 구성 가능 프로세서와 런타임 재구성 가능 로직을 프로그래밍함으로써 반복적인 사이클로 수행됩니다.
2. 제품 개발 프로세스 그룹. 제품을 구성하는 기능은 플랫폼의 하드웨어 또는 소프트웨어 요소로 분할됩니다. 방법론은 에너지 소비, 실행 시간 및 응용 프로그램 구성 요소의 메모리 크기를 고려하는 분할 알고리즘을 제공합니다.
3. 제품 관리 프로세스 그룹 은 제품 범위, 시간, 품질 및 비용 매개변수를 모니터링하고 제어합니다. 제안된 접근 방식은 주로 스크럼 애자일 방식과 애자일 패턴으로 추진되는 방식으로 구성됩니다.

하드웨어 개발 프로그램 만들기

초기 단계의 하드웨어 개발 프로그램을 구성함으로써 기업은 신속한 피벗 또는 플랜 B를 제공할 수 있었습니다. 비즈니스 관점에서는 재정적 마진을 감소시킬 수 있지만 결국 끊임없이 변화하는 시장에 대처하는 데 필요한 민첩성을 제공합니다. 경쟁사에서 출시한 제품의 조건과 앞선 기술력.

회사가 임베디드 소프트웨어가 포함된 하드웨어 제품에 대한 성공적인 크라우드 펀딩 캠페인을 실행한다고 가정합니다. 그들은 큰 회사가 비슷한 것을 발표할 때까지 첫 번째 제품 배치에 대해 훌륭하게 작동합니다. 다용성 및 출시 시간이 가장 중요하며 이러한 상황에 대한 실용적이고 민첩한 대응은 성공적인 제품의 가능성을 높입니다. 하드웨어 개발 프로그램을 마련함으로써 회사는 경쟁업체에 대한 대응으로 보다 풍부한 버전의 제품에 빠르게 적응하고 스포트라이트를 받을 수 있습니다.

임베디드 소프트웨어를 사용한 성공적인 하드웨어 테스트

애자일 소프트웨어 테스트와 달리 대부분의 하드웨어 버그는 새로운 제품 배치를 생산해야만 수정할 수 있기 때문에 테스트는 하드웨어 제품 관리의 중요한 구성 요소입니다. 화제가 되었던 Samsung Galaxy Note 7 장치는 하드웨어 테스트가 모든 제품 관리자에게 최우선 순위가 되어야 하는 이유를 보여주는 좋은 예입니다.

기능 테스트 는 임베디드 소프트웨어 제품이 있는 하드웨어에 대한 기술 검증의 핵심 목표입니다. 이러한 절차의 복잡성은 시스템의 모든 부분에서 오류가 발생할 가능성이 있다는 사실에서 비롯됩니다.

단위 테스트 는 일반적으로 각 스프린트 후에 시뮬레이션된 환경에서 발생합니다. 시뮬레이션된 하드웨어는 완벽하게 제어할 수 있다는 이점을 제공하기 때문입니다. 테스트 스크립트는 자동화될 수 있고, 실행을 감독할 수 있으며, 결과를 생성하지 못한 충돌로 보이는 테스트를 종료할 수 있습니다.

통합 테스트 는 온라인 및 오프라인 운영과 실제 운영 조건에 대한 하드웨어 제품의 제출을 ​​고려해야 합니다. 예를 들어 회사가 야외 활동 중에 머리에 장착된 뇌 모니터링 시스템을 개발하는 경우 테스트 조건은 이러한 특성을 고려해야 합니다.

시스템 테스트 에는 오류와 버그에 대해 전체 시스템을 테스트하는 작업이 포함됩니다. 이 테스트는 전체 시스템의 하드웨어 및 소프트웨어 구성요소(이전에 단위 및 통합 테스트를 거친 것)를 인터페이스하여 수행한 다음 전체적으로 테스트합니다. 이 테스트는 사용자가 예상한 시나리오, 잠재적 예외 및 극단적인 경우 조건에 대해 소프트웨어를 검사하는 블랙박스 테스트 방법 아래에 나열됩니다. 언급할 수 있는 특별한 테스트 범주:

• 이벤트 트리거 테스트: 하드웨어 제품 수명의 특정 이벤트 또는 상태 변경(예: 시작, 재설정, 종료)에 의해 시작됩니다. 그 목표는 영구적인 결함을 감지하는 것입니다.
• 시간 트리거 테스트: 시스템의 정상 작동에서 미리 구성된 시간에 시작되며 영구적인 오류를 감지하기 위해 주기적으로 수행됩니다. 중요한 테스트 트리거 이벤트가 발생하지 않는 장기간 실행되는 시스템에서 유용합니다. 시간 트리거 테스트는 간헐적 오류를 감지하는 데에도 유용합니다.

임베디드 소프트웨어가 포함된 하드웨어의 제품 승인

임베디드 소프트웨어가 있는 하드웨어 제품의 제품 가치는 일반적으로 워터 스크럼 폴 방식의 제품 승인 단계 후에 검증됩니다. 임베디드 소프트웨어 에코시스템이 있는 하드웨어는 검증 및 승인을 위해 소프트웨어보다 하드웨어를 우선시해야 합니다. 앞서 언급했듯이 하드웨어 변경은 수행하기가 더 어렵고 비용이 많이 듭니다. 제품 관리자는 하드웨어를 변경할 수 없다는 제약을 고려하고 소프트웨어 개발 분야에서 추가 반복을 선호하여 수용 문제를 해결하거나 가치를 조정하는 데 필요한 혁신적인 솔루션을 구상하는 것이 일반적입니다.

우수한 제품 관리자는 하드웨어 요구 사항을 예측하고 포함할 수 있는 올바른 기능의 우선 순위를 지정하여 비즈니스 모델이 건전하고 수용이 견고하며 사용자가 제품 사용을 즐길 수 있도록 제품 통찰력과 비전의 강력한 힘을 가지고 있습니다. 임베디드 소프트웨어를 고려할 때 하드웨어의 "장식"은 하드웨어 개발 프로세스, 인증 절차, 생산 문제 및 시장 수용에 따라 결정되는 규칙과 제약 조건을 따라야 하므로 놀라운 일이 아닙니다.

하드웨어 개발에는 관리되는 민첩성이 필요합니다.

애자일은 소프트웨어 개발의 세계를 폭풍으로 몰아넣었고 이제 하드웨어 공간으로 스며들기 시작했습니다. 그러나 임베디드 소프트웨어 개발이 포함된 하드웨어 제품의 조건은 다음과 같은 다양한 과제를 수반합니다.

• 전문 인재 부족
• 하드웨어에 적합하지 않은 버전 관리 시스템
• 비현지화된 생산 시설
• 소프트웨어에 비해 만들기 어려운 변경
• 계획 장애를 부과하는 인증 및 규정 요구 사항

이러한 문제로 인해 소프트웨어 회사와 동일한 방식으로 애자일 원칙을 적용하기가 더 어려워집니다.

이러한 문제를 해결하려면 워터 스크럼 폴 형식의 관리된 민첩성 접근 방식이 필요합니다. 임베디드 소프트웨어 개발은 ​​표준 스크럼 절차에 따라 생성되는 반면 아이디어, 사양 생성 및 테스트와 같은 다른 단계는 폭포수 설정에서 구현됩니다. 이를 통해 하드웨어 회사는 위에 나열된 다양한 제약 조건을 고려해야 하는 작동하는 제품 관리 접근 방식을 유지하면서 Agile이 제공하는 보상을 얻을 수 있습니다. 이 관리형 민첩성 접근 방식은 빠르게 변화하는 시장 상황과 지속적인 기술 개선의 맥락에서 성공적인 방법을 제공합니다.