나는 항상 민첩한 방법을 실제로 복잡한 복합 시스템 소프트웨어 (100+ 엔지니어)에 적용하는 방법을 궁금해했습니다. 펌웨어 개발에는 애자일하기 어려운 고유 한 특성이 있습니다 (즉, 개발주기 후반까지는 하드웨어를 사용할 수 없습니다. 제품이 출시되면 펌웨어를 쉽게 업데이트 할 수 없습니다.
이러한 종류의 개발에서 표준은 두꺼운 문서와 거친 동료 리뷰입니다. 2-3 개의 서명없이 변수 이름을 바꾸는 것과 같은 간단한 코드 수정을 얻을 수 없습니다. (나는 조금 과장하지만 이것은 일반적입니다. 또한 많은 사람들이 지름길을 취하고 프로젝트 관리자는 특히 어려운 시장 마감일에 직면하여이를 승인합니다.)
펌웨어 개발 프로젝트에 민첩한 방법론을 채택하는 방법에 대한 팁이나 지침을 듣고 싶습니다.
답변
두 가지 기술이 핵심이라고 생각합니다.
-
실제 하드웨어가있는 것처럼 소프트웨어를 개발할 수 있도록 하드웨어에 대한 완벽한 시뮬레이터 또는 테스트 환경을 개발하십시오. 좋은 시뮬레이터 를 개발하면 효과 가 있습니다.
-
쓰기 많은 시뮬레이터에 대한 단위 테스트.
일단 이런 일이 일어나고 사람들이 시뮬레이터와 단위 테스트가 하드웨어와 어떻게 작동하는지에 대한 정확한 아이디어를 줄 것이라고 확신하면 다른 민첩한 기술 (짧은 반복, 끊임없는 리팩토링 등)을 채택하는 것이 더 쉬울 것입니다 .
답변
여러 공급 업체와 관련된 개발 프로세스에 대한 Agile의 영향은 회사가 JIT를 수행 할 때 발생하는 상황과 비교할 수 있습니다.
JIT를 제공하기 위해 회사의 각 공급 업체는 JIT를 제공해야합니다.
function deliversJIT( company ) {
return company.isJIT() && map( deliversJIT, company.suppliers() );
}
마찬가지로 애자일 방법론에 따라 복잡한 제품을 개발하려는 경우 체인의 모든 하위 그룹이 그렇게 작동 할 수 있어야합니다.
‘증분’개발 (일명 15 년 전 Tracer Bullets ) 측면에서 볼 때 이는 ‘핵심’이 곧 드라이버 담당자에게 릴리스되고 기본 드라이버가 통합 자에게 제공되고 GUI가 하나의 버튼과 편집 상자로 동시에 개발하십시오.
어려운 부분은 탄탄한 사고 선행 엔지니어링 분야에서 온 하드웨어 디자이너가 우리의 땜장이 사회에 참여하도록 설득하는 것입니다.
두 번째로 어려운 부분은 3 주 전에 하드웨어 인쇄를 주문해야하는 세계에서 점진적 개발을 가능하게하는 방법을 찾는 것입니다. 에뮬레이터를 생각하고 있습니다. fpga가 여기 있습니다. 나는 하드웨어 사람이 아닙니다.
증분 하드웨어 개발을 기꺼이 포기하려는 경우 JIT 체인의 경계와 마찬가지로 Agile 팀이 발전 할 수있는 버퍼링 메커니즘을 예측할 수 있습니다.
맹인하지 말자 : 애자일은 무거운 프로세스도 처리해야합니다! 다음 스프린트에서 애자일 팀에게 Java 코드 기반을 파이썬으로 리팩토링하도록 요청하지 마십시오. 일부 부품이 실제로 안정적이기 때문에 애자일 움직임을 그 위에 춤을 출 수 있습니다.
답변
민첩한 선언 : http://agilemanifesto.org/
“프로세스 및 도구에 대한 개인 및 상호 작용”
- 더 만나보세요. 용지를 적게 밀어 넣습니다.
“포괄적 인 문서에 대한 작업 소프트웨어”
-
프로토 타입 및 빌드 기술은 일찍 그리고 자주 급증합니다.
-
사양에 대한 까다로운 준수를 계속 구축하는 대신 사용자의 실제 문제를 해결하십시오 . 이것은 진화 솔루션을 의미 합니다. 다시 만들 수 없기 때문에 제대로 만들어야한다는 생각은 잘못되었습니다. 반복 계획. 마케팅 및 롤아웃 전략의 일부로 만드십시오.
“계약 협상을 통한 고객 협업”
-
초 복잡한 변경 제어 프로세스는 고객에게 “아니오”라고 말하는 방법입니다.
-
아래로 잠금 모든 앞까지 요구하고 당당한 변경 제어하는 것은 “아니오”라고 말하는 또 다른 방법입니다.
-
둘 이상의 릴리스를 이미 계획 한 경우 요구 사항을 이후 릴리스로보다 쉽게 연기 할 수 있습니다. 고객에게 내장 소프트웨어가 포함 된 장치가 있으면 다음 릴리스에서 우선 순위가 변경됩니다.
“계획에 따라 변경에 응답”
- 복잡한 통합에는 복잡한 계획이 필요하지만 전반적인 “프로그램”(또는 일련의 프로젝트)을 너무 일찍 구체화 할 수는 없습니다.
완전히 민첩한 방법론 (즉, 스크럼)은 임베디드 시스템에 적합하지 않을 수 있습니다.
그러나 애자일 선언문은 단순한 혼돈을 허용하지 않고 변경이 가능하도록하는 방법을 제공합니다.
답변
임베디드 시스템에서 스크럼에 대한 나의 문제는, 특히 초기 단계에서해야 할 많은 작업이 있다는 것입니다. 우리는 개발 보드, OS, 디스플레이, 시리얼 통신 등으로 시작했습니다. 6 개의 스프린트를위한 디스플레이가 없었습니다.
RTOS 시작 및 실행 작업 작성 네트워크 및 직렬 드라이버 작성 버튼, 통신 등을위한 인터럽트 루틴 작성 기본 데이터베이스 클래스 및 메소드 작성 직렬 디버그 메뉴 작성
이러한 작업의 대부분은 사용자 스토리에 적합하지 않습니다. 실제로 전체 시스템에 대한 유일한 인터페이스는 스프린트 3에 내장 된 직렬 디버그 메뉴 였으므로 스프린트의 끝에는 아무 것도 보여주지 않았습니다. 직렬 메뉴조차도 최종 사용자가 아닌 내부 용이었습니다.
물론, 우리가 작성하는 각 클래스에는 연관된 단위 테스트가 있으며 모든 테스트 실행을 자동화하기 위해 단위 테스트 프레임 워크를 사용합니다.
우리는 “개발자로서 …”와 같은 “사용자 스토리”문구를 작성했습니다.이 주제는 만족스럽지 않지만 Target Process (www.targetprocess.com)를 사용할 때 백 로그 항목에 대한 개념은 없습니다. 작업이나 집안일.
다른 사람들이 이러한 상황을 어떻게 처리했는지 듣고 싶습니다.