임베디드 시스템에서 Scrum으로 작동하지 않는 작업을 어떻게 처리합니까?

임베디드 시스템에서 Scrum에 두 가지 문제가 있습니다. 첫째, 특히 초기 단계에서해야 할 일이 많으며, 이는 입증 할 수없는 일입니다. 우리는 개발 보드, OS, 디스플레이, 직렬 통신 등으로 시작했습니다. 6 개의 스프린트를위한 디스플레이가 없었습니다.

처음 4 개의 스프린트는 다음과 같습니다.

• 얻기 RTOS를 하고 실행할 수
• 네트워크 및 직렬 드라이버 작성 작업 작성
• 버튼, 통신 등에 대한 인터럽트 루틴 작성
• 기본 데이터베이스 클래스 및 메소드 작성
• 직렬 디버그 메뉴 작성

이러한 작업의 대부분은 사용자 스토리에 적합하지 않습니다. 실제로 전체 시스템에 대한 유일한 인터페이스는 스프린트 3에 내장 된 직렬 디버그 메뉴 였으므로 스프린트의 끝에는 설명 할 것이 없습니다. 직렬 메뉴조차도 최종 사용자가 아닌 내부 용이었습니다. 그럼에도 불구하고 저는 여전히 Scrum을 통해 이러한 개발 활동을 추적하고 관리하고 싶습니다.

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

둘째, 릴리스 및 테스트를 어떻게 처리합니까? 테스터들에게 하드웨어 디버거가 없기 때문에 우리에게는 정말 고통 스럽습니다. 따라서 우리는 코드의 플래시 버전을 빌드하고 개발 보드에서 테스트하여 테스트해야합니다. 테스터는 기술적으로 개발자만큼 선명하지 않으며 초기 단계 (보드 재설정, 직렬 통신 연결 등)에서 작업을 수행하거나 출력을 이해하는 데 많은 지원을 필요로합니다.

마지막으로 완료의 정의와 관련하여 모든 스토리가 완료 될 때까지 스프린트를 완료 할 수 없습니다. 테스터가 검증 할 때까지 모든 스토리는 완료되지 않습니다. 테스터들에게 "강도적인"개발자 시간을 피하는 방법은 없습니다. 다시 말해, 스프린트에서 마지막 3 개의 사용자 스토리를 테스트하는 데 5 일이 걸리는 경우 스프린트가 끝나기 5 일 전에 코드를 작성하고 단위 테스트를 수행해야합니다. 개발자는 무엇을해야합니까? 그만 일해?

나는 뻔뻔 스럽지만 규칙을 준수하는 것은 진짜 문제입니다. 자, 나는 규칙을 구부릴 수는 있지만 문제는 테스트 할 때까지 수행 된 작업을 표시 할 수 없다면 모든 번 다운 메트릭을 망쳐 놓는 것입니다.

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

IMHO와 호환되지 않는 제품에서 방법을 사용하고 있습니다.

대부분의 사람들이 민첩성을 정의하는 방식으로, 우선 순위 변경, 재주문 가능 또는 교체 가능에 따라 모든 작업을 협상 할 수 있습니다.

대부분의 사람들이 폭포를 정의하는 방식은 처음에 상당한 건축 노력에서 작업이 미리 순서대로 배치된다는 것입니다.

위에 나열된 작업은 매우 폭포처럼 보입니다. 그들은 특정한 순서로 있어야하며 협상 할 수 없습니다.

나는 당신이 어떤 프로세스에 대한 다른 사람의 견해를 따라야한다고 말하지는 않지만 적어도 이러한 작업을 위해 당신은 나에게 민첩하지 않은 프로젝트에있는 것처럼 보입니다. 그것을 민첩한 프로세스에 쏟아 부 으려고 노력하는 것은 기껏해야 딱 맞지 않을 것입니다.

프로젝트의 나머지 부분이 민첩하기에 적합하다면 초기 설정이 적합하지 않은 것에 대해 너무 걱정하지 않지만 RTOS 및 개발 보드를 언급한다는 사실로 인해 모든 것이 더 나아질 것입니다. 폭포처럼 (길이가 긴 의존성).

저는 임베디드 시스템을 구축하는 것에 대해 아무것도 알지 못하지만, 스크럼이 그러한 개발에 부적절하게 만들 수있는 것은 아무것도 없습니다. 실제로 사용자가 직면 한 기능이없는 것에 대해 걱정하기 쉬우므로 사용자가있는 "사용자 사례"를 작성하기가 어렵습니다. 사용자 스토리는 실제로 Scrum의 일부가 아니며 종종 Scrum과 함께 사용되지만 실제로는 도구로 사용됩니다.

Scrum의 일부는 각 Sprint의 실제 환경에서 완벽하게 테스트되고 구현 가능한 완전한 기능을 제공한다는 아이디어입니다. 모든 종류의 프로젝트 중 첫 날에 처음 시작할 때 Sprint 1에서 제공 할 수있는 모든 기능의 실제 가치는 매우 작습니다. 모든 작은 것에는 작동하기 위해 수많은 톤의 인프라가 필요하기 때문입니다. 그러나 요점은 각 기능이 작동하도록 충분한 인프라 만 구축한다는 것입니다. 그런 다음 더 많은 기능을 추가 할 때 작성합니다.

아이디어는 시스템 외부에서 감지 할 수없는 인프라를 구축하는 데 몇 개월과 몇 달을 소비하지 않는 것입니다. 왜? 실제로 작업을 수행하는 작업을 수행 할 때까지 인프라가 무엇인지 정확히 알 수 없기 때문입니다. 시스템의 실제 기능을 구축 할 때 배우는 것들입니다. 처음에 인프라를 구축하면 시스템에 대해 가장 잘 알지 못할 때 인프라를 구축하게됩니다.

사용자 스토리를 작성하는 데 어려움을 겪었다면 사용자가 사람 일 필요는 없습니다. "CMOS 인터럽트 처리기로서 플럭 소 트로닉 컴프레서가 수동 바이 패스 언더 차지 신호를 보낼 때 빙글 whozzit 스택 변조 플래그의 상태를 감지 할 수 있어야합니다." "개발자로서 ..."사용자 스토리를 쓰지 마십시오.

매우 구체적인 영역에서 Scrum을 사용하고 모든 단계에서 가정 된 프로세스를 위반합니다. 귀하의 질문은 아마 내 환경에 더 적합한 민첩한 방법론이 있습니까? 환경에서 허용하지 않는 경우 더 나은 스크럼을 수행하는 데 도움을주기 란 매우 어렵습니다. 내가 당신의 설명에서 볼 수있는 문제 :

• 인프라 작업으로 간주 될 수있는 입증 가능한 작업이 없습니다. 비즈니스 가치로 간주되지 않는 작업을 수행하기 위해 몇 가지 스프린트가 필요한 경우 사용자 스토리가 잘못 정의되었을 수 있습니다. 비즈니스 가치를 제공 할 수있는 도구 또는 기타 도구를 구축해야하는 경우 제품을 도구 제작과 비즈니스 가치 구축의 두 부분 / 릴리스로 나눌 수 있습니다. 이 경우 개발자를위한 도구가 작성되므로 "As Developer ..."라는 사용자 스토리가 완전히 유효합니다.

  여기서 문제는 고객이 첫 번째 릴리스에 관여하지 않았기 때문에이를 고객에게 전달하는 방법입니다. 고객에게 비즈니스 가치가 없다면 어떻게 참여할 수 있습니까? 제품 소유자는 비즈니스 우선 순위를 어떻게 정의 할 수 있습니까?

  여기서 중요한 문제는 이것이 스크럼에 적합한 것이 아니라는 것입니다. 스크럼은 가장 중요한 비즈니스 기능을 먼저 제공하려고 시도하지만 첫 번째 기능을 제공하려면 두 달이 필요합니다. 스크럼과 전체 민첩성은 변화를 수용합니다. 첫 번째 기능을 제공 한 후 고객이 초기 스프린트를 거슬러 올라가는 변경이 필요한 경우 어떻게됩니까?

• 테스트. 스크럼의 팀이 여러 부서의 구성원으로 간주되기 때문에 또 다른 실패가 발생합니다. 모든 사람이 개발 및 테스트를 수행하고 최종 포인트에 설명 된 상황이 없거나 (최소한 5 일 이상) 그 의미가 없습니다. 더 복잡하고 정교한 테스트를 수행하기 위해 별도의 QA를 수행 할 수 없다는 것을 의미하지는 않지만 팀은 이미 테스트 / 검증 된 기능을 제공해야합니다. 귀하의 경우에는 실제로 스크럼이 필요하지 않은 것처럼 보입니다. 별도로 처리 및 개발 및 테스트 기능을 전달해야합니다.