대부분의 애자일 "구루들"이 하드웨어 개발에 대해 잘못 이해하는 것

소프트웨어 개발의 세계에서 뿌리를 둔 애자일 방법론은 기술 산업에서 변혁적인 힘으로 칭송받아 왔습니다. 그러나 하드웨어 및 전자 개발로 나아가면서, 애자일 원칙의 겉보기에는 순조로운 적용이 도전과 오해의 미로에 부딪힙니다. 이 세 부분으로 구성된 탐구의 첫 번째 설치에서, 우리는 하드웨어와 소프트웨어 개발 간의 차이에서 비롯된 애자일 도전을 분석했습니다. 이 글에서는 애자일 "전문가들"이 퍼뜨린 신화를 검토합니다.

전자 하드웨어 개발에서 애자일의 복잡성에 대해 논의하기 전에, 우리의 의도가 애자일 코치와 컨설턴트를 비난하는 것이 아님을 명확히 하는 것이 중요합니다. 우리는 그들의 좋은 의도와 애자일 방법론의 혜택을 고객이 누릴 수 있도록 돕고자 하는 열정을 인정하고 감사합니다. 일부 비판은 하드웨어의 미묘한 차이에 대한 이해가 부족에서 비롯될 수 있지만, 의도는 비판이 아니라 하드웨어 개발의 특정 요구를 충족시키기 위해 애자일 원칙을 효과적으로 적용하는 것입니다. 우리의 초점은 이 독특한 맥락에서 애자일 전술을 맞춤화하여 그 혜택을 활용하는 것이며, 접근 방식을 수정하되 원칙은 보존하는 것입니다.

신화 #1: 유연하게 적응해야 한다

애자일 전문가들은 반복 실행, 피드백 루프, 그리고 소프트웨어의 디지털 영역에서 번성한 빠른 적응성의 미덕을 정확하게 찬양합니다. 그러나 이러한 원칙들을 하드웨어와 전자기기의 구체적인 영역으로 전환하는 것은 순수 디지털 스펙트럼에서 발견되지 않는 복잡성의 층을 도입합니다. 물리적 솔루션은 소프트웨어 대응물과 달리 부품을 주문하고, 몰드를 제작하며, 엄격한 제조 요구 사항을 충족시켜야 "완성"되어야 합니다. 애자일의 지속적인 변화에 대한 요구는 게임 후반에 마지막 순간의 변경이 필요할 때조차도 사소한 변경이 하드웨어의 무자비한 파급 효과와 충돌합니다.

이에 대한 대응으로, 하드웨어 개발을 위한 애자일 수정은 패러다임의 전환을 요구합니다. 이것은 끊임없는 수정에 관한 것이 아니라, 빠른 학습과 실행 주기를 기반으로 한 시간, 예산, 자원의 제약 내에서 가치를 극대화하려는 목표를 가진 정보에 입각한 전략적 적응과 프로토타이핑에 관한 것입니다. 애자일의 민첩성과 물리적 제품의 최종성 사이의 댄스는 더욱 신중한 반복 계획과 프로젝트 전반에 걸친 위험 감소에 대한 깊은 헌신을 요구합니다.

신화 #2: 매 스프린트마다 작동하는 프로토타입을 개발해야 합니다

매 2~3주마다 완전히 기능하는 프로토타입을 개발하는 것이 애자일 순수주의자들에 의해 애자일을 실천하기 위한 보편적인 "필수"로 종종 제시되지만, 하드웨어 및 전자 개발(그리고 예산)의 현실을 마주하면 이 접근법의 실용성은 무너집니다. 무언가를 만들고, 진행 상황을 보여주며, 이 결과를 사용하여 귀중한 기술적 및 상업적 피드백을 얻어 다음 반복을 위한 정보를 제공하는 아이디어는 옳습니다. 그러나, 각 하드웨어 프로젝트는 자체 목표, 의존성, 리드 타임 제약, 혁신이 필요한 영역, 그리고 위험을 가진 독특한 실체입니다. 그리고 각 프로젝트는 프로토타이핑과 학습에 대한 자체적인 독특한 접근 방식을 받을 자격이 있습니다.

진정으로 Agile 하드웨어 제품 개발을 받아들이기 위해서, 팀은 일률적인 사고방식을 버려야 합니다. 대신, 프로젝트의 필요성을 신중하게 검토한 다음 창의적인 학습 및 프로토타이핑 전략을 도출하기 위해 협력해야 합니다. "프로토타입"이란 예비 브로셔에서부터 폼 목업(스티브 잡스의 유명한 iPod 목업처럼 "주머니에 1000곡을 넣을 수 있음")에 이르기까지, 부분적으로나 완전히 기능하는 프로토타입을 포함하여 어떤 시연 가능한 결과물이 될 수 있다는 것을 인식하는 것이 중요합니다.

신화 #3: 백로그에 스토리를 추가하고 그냥 시작하라

애자일 방법론의 내재된 강점은 전통적인 워터폴 방식보다 프로젝트를 훨씬 빠르게 시작할 수 있는 능력에 있습니다. 실제로, 애자일 하드웨어 전자 프로젝트의 경우, 개념 식별에서 개발 시작까지의 기간이 크게 단축되었습니다. 전통적인 단계적 접근 방식에서는 종종 몇 달이나 심지어 몇 년이 걸렸던 이 기간이 애자일 방법을 사용함으로써 몇 주나 며칠로 단축되었습니다. 물론, 이러한 극적인 결과의 일부는 우리가 "개발 시작"을 어떻게 정의하는지에 달려 있습니다.

소프트웨어의 경우, 이는 간단합니다. 애자일 전문가들은 사용자 스토리를 작성하여 소프트웨어 기능을 정의하고, 백로그에 우선 순위를 지정하며, 스프린트를 시작하도록 권장합니다. 그러나 하드웨어에서는 적어도 프로젝트를 올바른 방향으로 안내하기 위해 아키텍처, 주요 원하는 속성, 제약 조건 및 기타 요소에 대한 이해와 함께 최소한의 사전 계획이 필요합니다. 이러한 사전 노력은 "작동하는 소프트웨어가 진행 상황의 주요 척도"와 "개발이 늦더라도 변경 사항을 환영한다"는 애자일 원칙과 상충될 수 있습니다.

화해는 제품 개발 초기에 일반적으로 이해되는 애자일 전술을 적응시켜 균형을 찾는 데 있습니다. 하드웨어를 위한 애자일 프로젝트 관리는 전통적인 접근 방식보다 훨씬 더 많은 미지의 요소를 받아들이면서 프로젝트의 전략적 의도에 맞춰 신속한 시작을 허용합니다. 그런 다음 팀은 애자일의 반복 학습을 사용하여 최적의 솔루션을 정의하고, 제품 가치를 향상시키는 전략적 변경에 열린 마음을 가지고, 일정 및 자원 제약 내에서 유지하면서 협력할 수 있습니다.

신화 #4: 모든 작업 항목을 사용자 스토리로 정의하라

많은 애자일 전문가들이 주장하는 중요한 지침 중 하나는 모든 개발 작업을 사용자 스토리로 정의해야 한다는 것입니다. 이 조언은 시스템 구성 요소, 인터페이스, 다른 엔지니어 등도 "사용자"로 취급해야 한다고 계속해서 말합니다. 이 조언은 대부분의 전자 및 하드웨어 개발자들이 고개를 갸우뚱하게 하고 준수하기 어렵게 만듭니다.

소프트웨어 팀이 애자일 관행을 쉽게 채택한 주된 이유 중 하나는 전통적인 요구 사항 문서와 상세한 사용 사례를 문서화하는 것이 매우 낭비적이었고 팀에 거의 가치를 더하지 않았기 때문입니다. 왜 사용자가 하려고 하는 것을 그냥 선언하고, 기능을 문서화하기 위해 사용자 스토리를 작성한 다음, 이를 개발 작업으로 취급하지 않겠습니까? 이것은 자체 문서화뿐만 아니라, 이러한 스토리가 지속적으로 우선 순위가 지정되고 고객과 함께 검증된다면, 변화에 대응하고 가치를 최적화하기 위한 완벽한 폐쇄 루프 시스템을 가지게 됩니다. 좋네요!

하드웨어 개발을 위한 작업 항목으로 사용자 스토리를 직접 작성하고 이를 가치 있는 고객 결과와 연결하려는 이 시도는 많은 하드웨어 팀에게 애자일의 분기점이 되곤 합니다. 하드웨어를 정의하는 것은 소프트웨어를 정의하는 것과는 다릅니다. 전통적인 제품 요구 사항 문서(PRDs)와 기능 사양은 하드웨어 개발자에게 안정감을 주는 것뿐만 아니라 그들의 작업을 분해하고 제공하는 데 필요한 세부 사항을 제공합니다. 개발자에게 "처리 단위로서, 깨끗한 입력을 보장하기 위해 전압 조절이 필요합니다..."와 같은 사용자 스토리를 작성하도록 요청하는 것은 사용자 스토리를 통해 고객 가치를 포착하는 목적을 무효화하고 소프트웨어 개발자들이 애자일 원칙으로 제거하고자 했던 비가치 폐기물을 추가합니다.

소프트웨어를 위한 애자일의 초기 사상 리더인 마이크 콘(Mike Cohn)이 정의한 바와 같이: "사용자 스토리는 그 기능을 필요로 하는 사람의 관점에서 말한 짧고 간단한 기능 설명입니다." 여기서 핵심 단어는 "사람"입니다. 하드웨어 팀은 사용자 스토리를 작성함으로써 상당한 가치를 얻을 수 있지만, 작업 항목을 정의하는 대신 사람들의 고객 요구를 포착하는 데 사용해야 합니다. 이러한 스토리는 그런 다음 원하는 결과를 만족시키는 제품 속성과 관련 작업 항목으로 변환되어야 하며, 하드웨어 개발자에게 의미 있는 기술을 사용해야 합니다.

신화 #5: 전담 팀원이 있어야 합니다

Vitality Chicago의 LinkedIn 설문조사에 따르면 애자일 실무자의 54%가 전담 스크럼 또는 애자일 팀(전담 팀원을 의미)이 필수적인 애자일 규칙이라고 말합니다. 애자일 선언에서는 전담 팀에 대한 논의가 없지만, 애자일 전문가들은 이를 규칙으로 여기며, 프로젝트에 100% 집중하는 팀원이 있으면 많은 이점이 있을 것이라고 주장하는 것은 어렵지 않습니다. 약속을 지키지 못할 변명이 거의 없고, 성공을 방해하는 것이 없으며, 아무도 "이번 주에는 다른 프로젝트가 우선순위가 더 높습니다!"라고 말하지 않을 것입니다. 번역:

하지만, 하드웨어 개발 환경에서 일해본 적이 있다면, 전담 팀원을 두는 것이 대부분의 조직에서 감당하기 어려운 사치라는 것을 알고 있을 것입니다. 하드웨어 개발의 특성상, 아키텍트, 주요 디자이너, 그리고 다른 주제 전문가(SME)들이 종종 여러 프로젝트에 필요합니다. 회사는 전문성이 필요할 때마다 호출되는 한 명의 무선 주파수 전문가를 가질 수 있고, 핵심 시기에 필요한 레이아웃 전문가 등을 가질 수 있습니다. 하드웨어 개발 팀은 여전히 애자일 방법을 받아들이고 활용할 수 있지만, 전담 팀원을 두는 것은 일반적으로 선택사항이 아닙니다. 따라서, 애자일 지원 리소스 관리 접근 방식을 갖는 것이 장기적인 애자일 성공에 있어 중요합니다.

#신화 6: 애자일은 정의된 역할, 의식, 행사 및 어휘의 합이다

한 회사에서 두 팀이 나란히 일하고 있습니다: 전통적인 워터폴 방식을 사용하는 하드웨어 팀과 스크럼 방법을 사용하는 소프트웨어 팀. 하드웨어 개발자가 소프트웨어 개발자들이 원을 그리며 모여 있는 회의실을 지나가다가 듣습니다, "좋아요, 우리의 스탠드업에 오신 것을 환영합니다. 지난 스프린트 동안 우리는 사용자 스토리 포인트 추정과 수용 기준에 어려움을 겪었습니다. 우리의 스크럼 마스터가 최신 번업 차트를 공유하고 백로그 정리에서의 문제를 해결하기 위해 회고를 주도했습니다. 이로써 우리는 속도를 높일 수 있습니다. 변화에 대해 어떻게 생각하는지 피스트-투-파이브로 표현해 봅시다." 다양한 주먹과 손가락 구성이 빠르게 솟아오릅니다.

하드웨어 개발자는 비록 흥미롭다고 느끼지만, 이러한 이상한 의식과 낯선 용어들의 풍부함에 의해 다소 혼란스러워 할 수밖에 없습니다. 이 Agile 방법론이 어떻게 그의 눈에 보이는 하드웨어 개발 세계로 옮겨질 수 있는지 궁금해하며, "내가 어떤 종교 집단에 들어선 건가?!"라고 스스로에게 생각합니다.

종종, 애자일 전문가들은 소프트웨어를 위한 애자일의 언어와 문화에 너무 깊이 빠져서 하드웨어 팀도 진정으로 "애자일하다"고 하려면 동일한 의식, 역할, 도구, 그리고 언어를 채택해야 한다고 믿습니다. 아이러니하게도 애자일 선언문의 첫 번째 원칙은 "프로세스와 도구보다 개인과 상호작용"이라고 말합니다. 이를 바탕으로 더 나아가 "프로세스, 도구, 의식, 그리고 교리보다 개인과 상호작용"이라고 말할 수 있다고 생각합니다. 언어, 회의 형식, 그리고 애자일 마인드셋과 체계적인 작업 방식을 구축하기 위한 특정 활동에 대한 합의는 모두 성공에 매우 중요하지만, 소프트웨어를 위한 스크럼이나 애자일의 특정 의식과 어휘를 채택하는 것은 아닙니다. 하드웨어 팀은 각 애자일 요소, 의식, 그리고 역할의 목적과 의도를 살펴보고 각각이 그들의 필요를 어떻게 가장 잘 충족시킬 수 있는지 결정해야 합니다.

애자일-하드웨어 간격 메우기

하드웨어 및 전자 개발 노력에 Agile 접근 방식이 적합한지 고민하면서, 선의로 전파된 기존의 "지혜"는 물리적 제품 개발에 필요한 더 미묘하고 적응적인 접근 방식을 안내하는 데 종종 부족합니다. 하드웨어에서 성공적인 Agile 구현으로 가는 길은 유연성, 사전 준비, 반복 계획 및 가능한 가장 가치 있는 솔루션으로 최단 시간 내에 수렴하는 데 대한 세심한 접근 방식의 신중한 혼합을 포함합니다.

세 부분으로 구성된 시리즈의 마지막 부분에서, 우리는 전자 하드웨어 개발을 위한 수정된 애자일의 이점을 활용하는 방법을 더 깊이 탐구할 것입니다. 이 모든 것은 애자일 방법론의 핵심 원칙을 유지하면서 진행됩니다. 이 주제에 대해 더 자세히 탐구하고 싶으신가요? 웨비나를 시청하세요!