펌웨어 / 임베디드 시스템 소프트웨어 개발을 위해 민첩한 방법론을 채택하는 방법은 무엇입니까?


17

나는 항상 민첩한 방법을 실제로 복잡한 복합 시스템 소프트웨어 (100+ 엔지니어)에 적용하는 방법을 궁금해했습니다. 펌웨어 개발에는 애자일하기 어려운 고유 한 특성이 있습니다 (즉, 개발주기 후반까지는 하드웨어를 사용할 수 없습니다. 제품이 출시되면 펌웨어를 쉽게 업데이트 할 수 없습니다.

이러한 종류의 개발에서 표준은 두꺼운 문서와 거친 동료 리뷰입니다. 2-3 개의 서명없이 변수 이름을 바꾸는 것과 같은 간단한 코드 수정을 얻을 수 없습니다. (나는 조금 과장하지만 이것은 일반적입니다. 또한 많은 사람들이 지름길을 취하고 프로젝트 관리자는 특히 어려운 시장 마감일에 직면하여이를 승인합니다.)

펌웨어 개발 프로젝트에 민첩한 방법론을 채택하는 방법에 대한 팁이나 지침을 듣고 싶습니다.


최종 하드웨어는 개발주기 후반까지 사용할 수 없지만 프로토 타입 또는 디버그 하드웨어, 개발 보드 또는 테스트 할 벤더의 시뮬레이터는 없습니까? 아니면 처음부터 시작합니까?
Kevin Vermeer

3
임베디드 작업에 대해 민첩한 개발자와 이야기하고있었습니다. "6-8 주마다 릴리스!?!?" 그는 말했다. "정말 오랜만이야" "아니, 당신은 저를 엉망으로 만들었습니다." "6 개월 에서 8 개월입니다 "
AShelly


2
100 명 이상의 임베디드 엔지니어가있는 제품 유형이 궁금합니다.
Pemdas

@reemrevnivek-일반적으로 사용할 수있는 이전 프로젝트의 평가 보드가 있습니다. 때로는 새 제품과 충분히 유사합니다. 그럼에도 불구하고 실제로 최종 장치에서 펌웨어를 실행할 때 모든 테스트가 평가 보드를 통과하더라도 하드웨어 사용자가 마지막 순간에 추가하기로 결정한 새로운 요소가 있었기 때문에 테스트가 중단되는 경우가 종종 있습니다. 처음에 우리에게 언급하지 않았다 ....
hopia

답변:


10

두 가지 기술이 핵심이라고 생각합니다.

  • 실제 하드웨어가있는 것처럼 소프트웨어를 개발할 수 있도록 하드웨어에 대한 완벽한 시뮬레이터 또는 테스트 환경을 개발하십시오. 좋은 시뮬레이터 개발하면 효과 있습니다.

  • 쓰기 많은 시뮬레이터에 대한 단위 테스트.

일단 이런 일이 일어나고 사람들이 시뮬레이터와 단위 테스트가 하드웨어와 어떻게 작동하는지에 대한 정확한 아이디어를 줄 것이라고 확신하면 다른 민첩한 기술 (짧은 반복, 끊임없는 리팩토링 등)을 채택하는 것이 더 쉬울 것입니다 .


또한 칩 제조업체가 시뮬레이터 코드의 관련 부분을 제공하게하십시오.
rwong

경쟁 업체가 이미 배송 한 것들을 가지고있을 때
Bill

엔지니어가 100 명 이상인 경우 경쟁 업체가 제공하는 것보다 적은 시간 안에 유용한 시뮬레이터를 만들 수 있습니다. 경쟁 업체가 하드웨어를받을 때까지 소프트웨어를 테스트 할 방법이없는 경우 특히 그렇습니다.
Kristopher Johnson

예, 시뮬레이터가 핵심이라는 데 동의합니다. 따라서 시스템을 테스트 가능한 구성 요소로 얼마나 효율적으로 분리 할 수 ​​있는지에 따라 처음부터 전체 시스템을 설계합니다. 이제 모든 사람들이 민첩하게
행동

@bill 매우 가능성이 높습니다. 그러나 이것은 아마도 테스트되지 않은 열등한 제품을 배송했음을 의미하며 OP의 제품은 제품을 물 밖으로 날려 버릴 것입니다. 글쎄요, 적어도 그렇게되어야합니다.
Julio

2

여러 공급 업체와 관련된 개발 프로세스에 대한 Agile의 영향은 회사가 JIT를 수행 할 때 발생하는 상황과 비교할 수 있습니다.

JIT를 제공하기 위해 회사의 각 공급 업체는 JIT를 제공해야합니다.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

마찬가지로 애자일 방법론에 따라 복잡한 제품을 개발하려는 경우 체인의 모든 하위 그룹이 그렇게 작동 할 수 있어야합니다.

'증분'개발 (일명 15 년 전 Tracer Bullets ) 측면에서 볼 때 이는 '핵심'이 곧 드라이버 담당자에게 릴리스되고 기본 드라이버가 통합 자에게 제공되고 GUI가 하나의 버튼과 편집 상자로 동시에 개발하십시오.

어려운 부분은 탄탄한 사고 선행 엔지니어링 분야에서 온 하드웨어 디자이너가 우리의 땜장이 사회에 참여하도록 설득하는 것입니다.

두 번째로 어려운 부분은 3 주 전에 하드웨어 인쇄를 주문해야하는 세계에서 점진적 개발을 가능하게하는 방법을 찾는 것입니다. 에뮬레이터를 생각하고 있습니다. fpga가 여기 있습니다. 나는 하드웨어 사람이 아닙니다.

증분 하드웨어 개발을 기꺼이 포기하려는 경우 JIT 체인의 경계와 마찬가지로 Agile 팀이 발전 할 수있는 버퍼링 메커니즘을 예측할 수 있습니다.

맹인하지 말자 : 애자일은 무거운 프로세스도 처리해야합니다! 다음 스프린트에서 애자일 팀에게 Java 코드 기반을 파이썬으로 리팩토링하도록 요청하지 마십시오. 일부 부품이 실제로 안정적이기 때문에 애자일 움직임을 그 위에 춤을 출 수 있습니다.


기본 재료가 철저히 설계 / 완료 되었기 때문에 민첩한 경우에만 +1.
Bill

1

민첩한 선언 : http://agilemanifesto.org/

"프로세스 및 도구에 대한 개인 및 상호 작용"

  • 더 만나보세요. 용지를 적게 밀어 넣습니다.

"포괄적 인 문서에 대한 작업 소프트웨어"

  • 프로토 타입 및 빌드 기술은 일찍 그리고 자주 급증합니다.

  • 사양에 대한 까다로운 준수를 계속 구축하는 대신 사용자의 실제 문제를 해결하십시오 . 이것은 진화 솔루션을 의미 합니다. 다시 만들 수 없기 때문에 제대로 만들어야한다는 생각은 잘못되었습니다. 반복 계획. 마케팅 및 롤아웃 전략의 일부로 만드십시오.

"계약 협상을 통한 고객 협업"

  • 초 복잡한 변경 제어 프로세스는 고객에게 "아니오"라고 말하는 방법입니다.

  • 아래로 잠금 모든 앞까지 요구하고 당당한 변경 제어하는 것은 "아니오"라고 말하는 또 다른 방법입니다.

  • 둘 이상의 릴리스를 이미 계획 한 경우 요구 사항을 이후 릴리스로보다 쉽게 ​​연기 할 수 있습니다. 고객에게 내장 소프트웨어가 포함 된 장치가 있으면 다음 릴리스에서 우선 순위가 변경됩니다.

"계획에 따라 변경에 응답"

  • 복잡한 통합에는 복잡한 계획이 필요하지만 전반적인 "프로그램"(또는 일련의 프로젝트)을 너무 일찍 구체화 할 수는 없습니다.

완전히 민첩한 방법론 (즉, 스크럼)은 임베디드 시스템에 적합하지 않을 수 있습니다.

그러나 애자일 선언문은 단순한 혼돈을 허용하지 않고 변경이 가능하도록하는 방법을 제공합니다.


0

임베디드 시스템에서 스크럼에 대한 나의 문제는, 특히 초기 단계에서해야 할 많은 작업이 있다는 것입니다. 우리는 개발 보드, OS, 디스플레이, 시리얼 통신 등으로 시작했습니다. 6 개의 스프린트를위한 디스플레이가 없었습니다.

RTOS 시작 및 실행 작업 작성 네트워크 및 직렬 드라이버 작성 버튼, 통신 등을위한 인터럽트 루틴 작성 기본 데이터베이스 클래스 및 메소드 작성 직렬 디버그 메뉴 작성

이러한 작업의 대부분은 사용자 스토리에 적합하지 않습니다. 실제로 전체 시스템에 대한 유일한 인터페이스는 스프린트 3에 내장 된 직렬 디버그 메뉴 였으므로 스프린트의 끝에는 아무 것도 보여주지 않았습니다. 직렬 메뉴조차도 최종 사용자가 아닌 내부 용이었습니다.

물론, 우리가 작성하는 각 클래스에는 연관된 단위 테스트가 있으며 모든 테스트 실행을 자동화하기 위해 단위 테스트 프레임 워크를 사용합니다.

우리는 "개발자로서 ..."와 같은 "사용자 스토리"문구를 작성했습니다.이 주제는 만족스럽지 않지만 Target Process (www.targetprocess.com)를 사용할 때 백 로그 항목에 대한 개념은 없습니다. 작업이나 집안일.

다른 사람들이 이러한 상황을 어떻게 처리했는지 듣고 싶습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.