애자일 제품 개발 프로세스
전통적인 기계 제품에 더 많은 전자 하드웨어와 소프트웨어가 통합됨에 따라 제조업체는 엔지니어링 분야에 걸쳐 설계 활동을 통합하는 더 나은 방법을 모색하고 있습니다. 결과적으로 많은 설계 및 개발 관행이 교환됩니다. 이러한 이니셔티브 중 하나 인 애자일 제품 개발에는 기계 설계,전기 설계 및 광범위한 제품 개발에 애자일 방법론의 적용이 포함됩니다. …
애자일 제품 개발 프로세스 자세히 보기”
더 많은 전자 하드웨어와 소프트웨어가 전통적인 기계 제품에 통합됨에 따라 제조업체는 엔지니어링 분야 전반에 걸쳐 설계 활동을 통합하는 더 나은 방법을 모색하고 있습니다. 결과적으로 많은 설계 및 개발 관행이 교환됩니다. 이러한 이니셔티브 중 하나 인 애자일 제품 개발에는 기계 설계,전기 설계 및 광범위한 제품 개발에 애자일 방법론의 적용이 포함됩니다.
하드웨어에 대한 애자일 정의
애자일 방법론이 제품 개발에 어떻게 적용되는지 이해하기 시작하기에 좋은 곳은 애자일 소프트웨어 개발에 대한 위키백과의 항목이다.
애자일 소프트웨어 개발은 반복 및 증분 개발을 기반으로 한 소프트웨어 개발 방법 그룹으로,자체 조직화 및 교차 기능 팀 간의 협업을 통해 요구 사항과 솔루션이 발전합니다. 그것은 적응 계획,진화 개발 및 전달,그리고 시간 박스 반복적 인 접근 방식을 촉진하고,변화에 신속하고 유연한 대응을 권장합니다. 그것은 개발주기 전반에 걸쳐 예측 상호 작용을 촉진하는 개념적 프레임 워크입니다.
출처:애자일 소프트웨어 개발에 대한 위키 백과 항목
흥미롭게도 이러한 특성은 10 년 전에 많은 소프트웨어 개발 방법에서 그랬던 것처럼 기존의 제품 개발 접근 방식과 직접적인 대조를 이룹니다. 제품 요구 사항은 종종 초기에 동결. 엔지니어링 조직은 종종 명확한 권한으로 엄격하게 구성됩니다. 개발 일정은 종종 사전에 멀리 배치됩니다.
그러나 애자일 소프트웨어 개발은 광범위한 성공을 거두었습니다. 오늘날 대부분의 소프트웨어 개발 조직은이 프레임 워크의 일부 변형을 사용합니다. 그러나 제품 개발에 대한 적용 가능성은 약간의 번역이 필요합니다. 아래 표 1 에서 왼쪽 열은 애자일 소프트웨어 개발에 대한 위키피디아 항목 당 애자일 선언문의 핵심 원칙을 보여줍니다. 오른쪽 열에는 이러한 원칙이 민첩한 제품 개발로 변환된 내용이 나와 있습니다.
민첩한 선언문 원칙 |
애자일 제품 개발에 동등 |
프로세스 및 도구에 대한 개인 및 상호 작용. 개인과 상호 작용:애자일 개발에서는 공동 위치 및 쌍 프로그래밍과 같은 상호 작용과 마찬가지로 자기 조직과 동기 부여가 중요합니다. |
협업 및 문제 해결은 특정 프로세스 또는 절차를 따르는 것보다 더 중요합니다. 메카트로닉스 문제는 분야에 걸쳐 있기 때문에 엔지니어는 최고의 팀으로 구성해야합니다. 또한 이러한 팀은 문제를 추구하고 해결할 수있는 권한을 부여 받아야합니다. |
포괄적 인 문서를 통해 소프트웨어를 작업. 작업 소프트웨어:작업 소프트웨어는 단순히 회의에서 고객에게 문서를 제시하는 것보다 더 유용하고 환영 할 것입니다. |
물리적 및 디지털 모두 작동하는 프로토 타입은 결국 설계 릴리스에서 전달 될 엔지니어링 결과물보다 더 중요하다. 성능 및 기타 특성에 대한 요구 사항을 충족시키는 데 중점을 두어야합니다. |
계약 협상에 대한 고객 협업. 고객 협력:소프트웨어 개발 주기가 시작될 때 요구 사항을 완전히 수집 할 수 없으므로 지속적인 고객/이해 관계자 참여가 매우 중요합니다. |
고객 또는 이와 동등한 내부 담당자는 개발 프로세스에 밀접하게 관여해야합니다. 메카트로닉스 제품을 설계하는 동안 여러 번 문제가 발생하기 때문에 검증 및 검증 단계가 필요합니다. 이로 인해 개발 과정에서 메카트로닉스 요구 사항이 개선됩니다. |
계획에 따라 변화에 대응. 변화에 대한 대응:민첩한 개발은 변화에 대한 신속한 대응과 지속적인 개발에 중점을 둡니다. |
강조는 특정한 과정 또는 절차에 고착하는 그것의 기능에 발달 문제점에 반응하는 조직의 기능에 두어야 한다. 따라서 조직은 민첩하고 유연한 방식으로 메카트로닉스 개발 문제에 대응할 수 있어야합니다. |
애자일
에 의해 해결 과제 분명히,애자일 제품 개발에서 발생하는 몇 가지 흥미로운 의미가있다. 그러나 그것을 채택하는 것은 아래에 언급 된 두 가지 과제를 직접 해결합니다.
트렌드 |
해결 된 도전 |
제공되는 이점 |
엔지니어링 운영에 대한 가시성 위임 |
엔지니어링 관리자는 잘 설계된 제품의 진행 상황을 측정하는 새로운 설계 기반 메트릭을 도출해야합니다. |
결과물에 대한 프로토 타입 작업에 대한 강조는 결과물 기반 메트릭에 대한 경영진의 생각을 변화시킵니다. 이 강조는 새로운 디자인 기반 메트릭을 정의하는 단계를 설정합니다. |
엔지니어링 인재를위한 다가오는 전쟁 |
엔지니어링 관리자는 금전적 보상 이외의 혜택을 사용하여 세대 엔지니어를 모집 할 수있는 방법을 찾아야합니다. |
세대-예르는 본질적으로 협력적인 세대 집단이며 즉각적인 영향을 미치기를 원합니다. 상호 작용에 대한 강조는 자연스러운 경향에 호소합니다. 이 프레임 워크에 기여할 수있는 기회는 그들이 즉시 영향을 미칠 수 있습니다. |
애자일을 추구하는 단계
애자일 방법론을 배포하는 방법에 대한 광범위한 지침을 제공하는 게시된 보고서 및 컨설턴트가 있습니다. 그러나 이러한 지침 원칙의 대부분은 메카트로닉스 제품을 개발하는 엔지니어링 조직이 아닌 소프트웨어 개발 조직의 요구를 해결합니다. 많은 단계가 비슷하지만 몇 가지 중요한 차이점이 있습니다:
- 더 많은 이해 관계자 참여: 사람들의 관점에서 볼 때,메카트로닉스 제품의 개발은 기계,전기 및 소프트웨어 엔지니어뿐만 아니라 제조,품질,소싱 및 서비스 조직의 참여가 필요합니다. 이는 주로 소프트웨어 개발자,테스트 등으로 구성된 애자일 소프트웨어 개발에 참여하는 사람들보다 훨씬 더 다양한 기술 집합입니다. 엔지니어링 관리자는 이러한 필요한 조직의 복잡성을 인식하고 팀이 자체 구성 할 때 지원해야합니다.
- 자기조직 구조: 언뜻 보면 애자일 제품 개발이 공식적인 프로세스를 자체 구성하고 강조해야 할 필요성으로 인해 혼란 스럽다고 가정 할 수 있습니다. 그러나 공식적인 프로세스가 없기 때문에 애자일 제품 개발이 구조화되지 않았 음을 의미하지는 않습니다. 현실은 확실히 반대 이다. 이 구조에도 불구하고 공식화 된 프로세스에서 멀어지는 전환이 있습니다. 엔지니어링 관리자는 이러한 전환을 통해 엔지니어를 활성화해야합니다.