제조 및 소프트웨어 개발 [폐쇄]

소프트웨어 산업은 제조에 비해 미성숙하다고 종종 말합니다. 특히 프로세스 중심적입니다.

질문 : 개발자로서 제조 산업의 프로세스에서 배울 수 있습니까? 프로세스를 채택하면 소프트웨어 개발의 성공률을 높일 수 있습니까?

필자의 의견 : 제품을 제조 할 때는 공정을 많이 사용한다. 각 사람이 따르는 특정 작업 세트가있는 공장이있을 수 있습니다. 작업자 (또는 로봇)는 하루 종일 나사를 조일 수 있습니다. 그런 다음 프로세스의 다음 작업은 다음 전문가가 수행합니다. 작업자 (및 로봇)는 프로세스를 방해하거나 "즉석에서"무언가를 구성하지 않습니다. 프로세스를 통해 부품이 휘어지고 출력이 완제품입니다. 그것은 잘 작동하고 회사는 99.99966 % 결함이없는 제품을 달성합니다. 회사는 시간이 지남에 따라 비 효율성을 해결합니다. 이것은 인상적이며 성숙한 산업의 징조가 될 수 있습니다.

정의 된 프로세스를 제조 할 때 말 그대로 완제품을 만들 수 있습니다. 나는 이것이 소프트웨어의 경우라고 생각하지 않습니다. 소스 제어, 코드 검토, 체크인 시트, 요구 사항 수집, SDLC 등을위한 프로세스가있을 수 있습니다. 그러나 이러한 프로세스를 실행한다고해서 완성 된 제품이되는 것은 아닙니다. 이러한 프로세스는 유리할 수 있지만 실제 생성과 직교합니다.

귀사가 범죄자의 얼굴을 찾기 위해 수백만 개의 이미지를 검색하는 소프트웨어를 작성하기로 계약했다고 가정 해보십시오. 프로세스 중심의 환경에도 불구하고 개발자는 "즉석에서"물건을 만드는 데 참여해야합니다. 즉시 작업을 수행하는 것은 제조 정신에 위배됩니다. 로봇이 생각하지 않아도 좋은 제조 공정을 실행할 수 있습니다.

아직 인간의 마음 속에 팻홈이되어 있지 않은 복잡한 알고리즘을 만들려면 즉시 물건을 만들어야합니다. 소프트웨어 개발은 ​​프로세스의 다음이 아니라 컴퓨터에 의해 실행되는 프로세스의 생성입니다. 그것은 근본적인 차이점입니다. 우리가 개발을 중심으로 얼마나 많은 직교 프로세스를 만들어도, 우리는 항상 창조 과정에서 "즉석에서"수행합니다.

내가 이야기하는 모든 사람들은 제조 사고 방식에 동의하는 것 같습니다. 내 생각에 혼자 있는가?

소프트웨어 개발과 제조의 근본적인 차이점은 소프트웨어의 경우 설계 단계가 실제로 전체라는 점입니다. 실제 생산 (기존 제조의 조립 라인 부품)은 몇 개의 파일을 복사하는 것입니다. 소프트웨어에서 제품 디자인 은 제품입니다.

그렇습니다. 우리는 제조 공정을 통해 배울 수 있지만, 생산 단계가 아닌 설계 단계를 검토해야하며 많은 생산 공정이 고가의 생산 체인의 특정 한계를 극복하기 위해 구축되었다는 점을 명심해야 소프트웨어에는 적용되지 않습니다.

소프트웨어에서는 잘 작동하지만 제품 디자인에서는 실패하는 프로세스 모델의 한 가지 예는 반복적 인 디자인입니다. 최소한의 프로토 타입으로 시작하고 각 반복마다 기능을 추가합니다. 새로운 리어 윈도우 노브 디자인이 어떤 모습인지 확인하기 위해 프로토 타입 자동차를 제작하는 것은 말도 안되는 일이지만 소프트웨어에서는 의미가 있습니다 (F5를 누르고 몇 초 기다립니다.

제품 설계 프로세스를 살펴보면 최고의 산업은 두 가지 범주로 분류됩니다.

• 상품 가격으로 생산이 실현 될 수있는 것; 예 : 음반 산업 (CD 가격의 1 % 이하가 제빵 및 인쇄 중임), 그래픽 미디어 등
• 수량이 너무 낮아서 디자인 단계가 가장 두드러진 비용 요인 (고급 제품, 고도로 맞춤화 된 제품, 틈새 시장 등)

물리적 제조에서 소프트웨어 개발에 이르기까지 프로세스를 시도하고 적용하는 것은 근본적인 오류입니다. 소프트웨어 개발은 ​​반복적이지 않으며 (직무중인 경우 다른 직업을 찾으십시오) 부분적으로 만 예측 가능하며 물리적 한계는 거의 없습니다 ( 하드웨어 속도는 하나)이며, 접근 방식과 결과는 매우 개인적 일 수 있습니다. 기본적으로 분석적이고 창의적 사고의 문제에 조립 라인 철학을 적용하면 치명적인 영향을 줄 수 있습니다.

(복사하는 것이 아니라) 동일한 정확한 소프트웨어를 반복해서 작성하려면 조립 라인을 통해 매우 효율적으로 수행 할 수 있습니다.

그러나 소프트웨어 작성은 반복적 인 작업이 아니며 각 모듈은 고유하지 않습니다. 그렇기 때문에 제조와의 비교가 유효하지 않습니다.

나는 당신이 찾고있는 대답이 여기에 적용 가능하거나 현실적이라고 생각합니다. 당신이 알고 싶어하는 것은 우리가 어떻게 프로세스를 제조업과 같게 만들 수 있는지입니다. 그 대신에 실제 질문은 "우리가 배울 수있는 양질의 제품을 만들기 위해 어떤 제조업 및 기타 산업이 무엇을하는지 아는가"라고 생각합니다. 또는 "소프트웨어 산업이 품질 향상을 위해 무엇을 할 수 있습니까?"

불행히도 소프트웨어 산업 자체가 여전히 그 답을 알지 못하기 때문에 이에 대한 대답은 불분명합니다. 이에 답하기 위해 소프트웨어 산업은 무엇이 효과가 있으며 왜 그런지 연구해야합니다. 예를 들어 TDD (Test Drive Design)가 품질을 향상 시킨다는 연구 결과가 있습니다. 생산성 문제는 여전히 답이 없거나 아직 완전히 이해되지 않은 것 같습니다. 증거가 지금까지 보여주는 것까지 :

• 코드 검토는 훌륭하고 가장 많은 버그를 발견 한 것으로 보이지만 첫 번째 검토 후 검토의 효과는 상당히 떨어집니다. 평범한 사람은 한 시간에 수백 줄의 코드 만 읽을 수 있다는 점을 감안하면 개발자가 변경 사항을 더 작은 조각으로 나눠야한다고 제안합니다.
• 버그를 찾는 데 시간이 오래 걸릴수록 더 많은 비용과 시간이 소요됩니다. 따라서 개발자가 코드를 작성하는 동안 발견하면 비용은 1이라고합니다. 단위 테스트에서 나중에 발견하면 비용은 10이고 EVT에서 발견하면 비용은 100 등입니다.
• 요구 사항이 복잡할수록 솔루션이 더 복잡하고 솔루션이 복잡할수록 버그가있을 가능성이 높다는 증거가 있습니다.

그렉 윌슨 (Greg Wilson)이라는 사람이 몇 년 전에 이것에 대해 훌륭한 이야기를했습니다. 대화에 대한 링크는 다음과 같습니다. Greg Wilson Talk

이 외에도 나는 자신의 작업을 되돌아보고 오류 유형과 어려움을 겪는 부분이있는 테마를 찾으라고 말합니다. 이러한 결과를 컴파일 한 다음 더 나은 작업을 수행 할 수 있도록 다양한 장소에서 프로세스에 삽입 할 점검 목록을 작성하십시오. 개인적으로 나는 지난 몇 년간의 작업을 되돌아 보면서 내가 소개 한 문제에 공통적 인 주제가 있음을 발견했습니다. 구체적으로 나는

• 나는 종종 모든 변형을 빌드하여 빌드를 깨뜨리는 것을 기억하지 않습니다.
• 여러 번 나는 각 변경에 대해 다음에 대해 생각하지 않습니다. 좋은 경우, 나쁜 경우 및 예외적 인 경우.
• 발생할 수있는 모든 가능한 시나리오 그것들이 많기 때문에 이것은 실제로 어렵다는 점에 유의하십시오.

내 오류에 대한 몇 가지 테마를 찾았으므로 스크립트에 삽입하여 자동으로 사용하는 체크리스트를 작성하여 이러한 문제를 해결하는 데 도움이되었습니다. 이 호출에 대해 쓰여진 "체크리스트 선언"에 관한 책이 있는데, 그것들은 그것들을 어떻게 잘 활용할 수 있는지 자세히 설명합니다. 개인적으로 나는 그것이 매우 통찰력이 있음을 알았습니다.

"그들의"프로세스를 채택하는 것이 아닙니다. 창의적인 노력을 위해 조립 라인 프로세스를 사용하는 데 일반적이고 잘 알려져있는 "일부"프로세스를 채택하는 것입니다. 여기서 주목해야 할 가장 중요한 것은 프로세스의 품질이 제품의 품질과 직접적으로 관련이 있다는 생각입니다.

그 문제에 가장 적합한 프로세스 또는 제품은 장갑을 낀 손처럼 의도 된 사용 시나리오에 맞는 프로세스입니다. 고려해야 할 것은 실제 코드 작성 부분은 거시적 수준에서 최소한 반복적 인 것이 아니라 유일한 것입니다. 버전 관리, 버그 추적, 계획, 추정, 측정 등과 같은 다른 모든 측면이 있으며, 맞춤형의 검증 된 표준 프로세스를 사용하면 최소한 이러한 영역에서 도움이 될 수 있습니다.

따라서 소프트웨어 개발 프로세스는 조립 라인 생산에 비유 할 수 없으며 "그들의 프로세스"는 좋지 않지만 제조 산업에서 제품의 생산 설계 / 제품 설계 단계는 영감을받을 수 있습니다.

질문 : 개발자로서 제조 산업의 프로세스에서 배울 수 있습니까? 프로세스를 채택하면 소프트웨어 개발의 성공률을 높일 수 있습니까?

답 : 물론입니다. 소프트웨어 개발이 창의적인 프로세스라는 사실에도 불구하고 소프트웨어 개발자가 제조에서 배울 수있는 많은 교훈이 있습니다. 소프트웨어 개발 자체는 프로세스이며 다른 많은 프로세스도 포함됩니다. 이러한 프로세스를보다 잘 정의하고 제어할수록 소프트웨어 개발 프로세스를 전반적으로 더 잘 제어 할 수 있습니다. 그렇다고 개발자가하는 모든 키 입력을 규정해야한다는 의미는 아닙니다. 이는 개발자로서 자연스럽게 특정 순서로 작업을 수행하며 이러한 작업을 관리 할 수 ​​있다는 의미입니다. 여기 몇 가지 예가 있어요.

• 결함 추적 : 버그가 관찰되거나보고되면 어떻게됩니까? 당신은 그것을 종이 조각에 적어 '조사'스파이크에 붙입니까? 나중에 스크랩을 한 번에 하나씩 제거하고 조사한 다음 결국 '해결 된'스파이크로 이동합니까? 버그 리포트를받을 때마다 반드시 실패하지 않으면 잘 정의되고 측정 가능한 프로세스를 얻게되며 매우 번잡 한 멋진 첨단 결함 추적 시스템을 보유한 사람보다 훨씬 나을 것입니다 일부 팀원은 다른 방식으로 버그를 추적하거나 전혀 추적하지 않습니다.

• 버전 관리 : 작업하는 곳에서 버전 관리를 사용할 가능성이 높으며 모든 사람이 같은 방식으로 사용할 때 버전 관리가 훨씬 더 유용합니다.

• 제품 디자인 : 포스트잇 메모로 덮인 벽에 다트를 던져 구현할 기능을 결정하십니까? 그렇다면 프로세스가 완료된 것입니다. 나는 그것이 훌륭한 과정이라고 주장하는 사람은 없다고 생각하지만 적어도 시작점입니다. 프로세스를 변경하면 이전과 이후를 측정하지 않는 한 변경 사항이 실제로 개선되었다는 것을 어떻게 알 수 있습니까? 당신은 할 수 없습니다.

• 코드 검토 : 검토 프로세스 및 코딩 기준이 각 검토마다 변경된 경우 코드 검토가 유용합니까? 당연히 아니지.

• 소프트웨어 개발 수명주기 : 전체 분석-> 디자인-> 구현-> 테스트-> 유지 보수 주기는 명확하게 정의해야하는 프로세스입니다.

이러한 각 경우에 적절한 프로세스를 통해 입력 및 출력을 측정하고 변경 사항이 의도 한 효과를 갖는지 여부를 결정할 수 있습니다. 프로세스가 제대로 갖추어져 있지 않다는 것은 업무 방식을 개선하려고 할 때 추측하는 것입니다. 이것은 실제로 제조에 관한 것이며, 적절한 경우 제조의 연속적인 정제 도구를 빌리는 것이 합리적입니다.

소프트웨어를 만들고 유지 관리하는 데 사용되는 프로세스를 정의하고 개선하는 데 전념하는 전 분야가 있습니다. 이것을 소프트웨어 엔지니어링 이라고 합니다 . CMMI에 대해 읽는 동안 개발 프로세스에 대한 질문이 있다는 것은 놀라운 일이 아닙니다. CMMI는 Software Engineering Institute 의 제품입니다 .

소프트웨어 개발은 ​​이미 많은 제조 개념을 채택했습니다.

• Eli Whitney의 교체 가능한 부품이 OOP 및 구성 요소 기반 개발 모두에 미치는 영향을 알기 어렵습니다 .

• 소프트웨어 개발에 사용되는 프로젝트 관리 기술은 제조를 위해 개발 된 기술과 크게 다르지 않습니다. 단지 두 가지 예와 같이, 소프트웨어 세계는 최근 도요타에서 수십 년 전에 개발 된 칸반 (Kanban) 개념 만 채택했으며 첫 번째 전자 컴퓨터가 만들어지기 훨씬 전에 Gantt 차트를 제조에 사용했습니다.

• 제조를 위해 개발 된 Six Sigma와 같은 품질 관리 방법론은 소프트웨어 개발에 적용되었습니다.

프로세스 중심의 환경에도 불구하고 개발자는 "즉석에서"물건을 만드는 데 참여해야합니다.

누군가 얼굴 인식 패키지에 패치를 추가하기로 스스로 결정하고 추적 시스템에서 먼저 문제를 만들지 않고 프로덕션 빌드에 추가하여 디자인을 검토하겠다고 말하고 있습니까? 코드를 버전 관리로 검사하거나 테스트 담당자가 먼저 보도록 하시겠습니까? 우리의 프로세스에는 몇 가지 이유가 있습니다. "즉시"라는 말이 "프로세스 외부"를 의미하는 경우 이는 용납 할 수 없습니다.

즉시 작업을 수행하는 것은 제조 정신에 위배됩니다.

"즉시"가 "프로세스 외부"를 의미하는 경우에도 그렇습니다. 그러나 제조에 문제를 신속하게 사고하고 창의적인 솔루션을 개발할 필요가 없다고 생각하면 잘못되었습니다. 컵 케이크에는 크림 충전이 충분하지 않고 페인트 칠한 표면이 갑자기 QA의 스크래치 테스트를 통과하지 못하고 완성 된 부품의 20 %에 중요한 고정 링이 누락되어 반죽 혼합 시스템이 고장났습니다. 중요한 부분 ...