비 프로그래머가 개발 프로세스를 이해하도록하기

주로 프로그래밍 회사가 아닌 회사를위한 프로젝트를 시작할 때 기대되는 것 중 하나는 모든 버그가없는 완성 된 제품이 있으며 즉시 필요한 모든 것을 수행한다는 것입니다. 그러나 거의 그렇지 않습니다.

소프트웨어 개발이 다른 유형의 제품 개발과 어떻게 다른지 기대치를 관리하고 비 프로그래머에게 설명하는 몇 가지 방법은 무엇입니까?

요즘 컴퓨터를 가진 모든 사람들은 "버그"라는 개념을 접하게되므로 시작할 수 있습니다. "응용 프로그램이 실패한 가장 성가신 방법은 무엇입니까? 10을 곱하면 테스트 및 유지 관리에 충분한 리소스를 할당하지 않으면 사용자 경험이 향상됩니다."

프로그래머가 아닌 사람과 좋은 관계를 맺는 것의 가치를 과소 평가하지 마십시오. 만약 당신의 판단을 신뢰할 수 있다고 확신 할 수 있다면, 당신이 당신의 추론을 완전히 이해하지 못한다고해도 Y 발음을하지 않으면 X가 크게 실패 할 것이라는 경고를 들으면 진지하게 받아 들일 것입니다.

내가 찾은 한 가지 접근법은 다음과 같습니다.

우리 모두는 컴퓨터가해야 할 일만 정확하게 수행한다는 것을 알고 있습니다.

프로그래밍은 우리가 컴퓨터를 말할 방법입니다 지금 우리가 무엇을 무엇을 나중에 .

이것은 당신의 행동이 지금 행동하는 방식이 당신 의 컴퓨터에서 실행되는 코드를 작성한 모든 사람들의 의도 때문 이라는 것을 의미합니다 . 운영 체제, 드라이버, 프로그래밍 환경, 라이브러리 등의 복잡성을 고려할 때 대부분의 시스템에는 2 천만 명 이상이 참여해야하며 100 만 명 이상이있을 수 있음을 쉽게 알 수 있습니다.

각 사람이 작성한 코드는 자신의 이해, 동기 부여, 의도 및 능력을 반영합니다. 시스템의 완벽한 동작을해야 감안할 때 모든 이 20K 사람이 작성한 코드의 오류없이 상호 작용 - 것을 모든 코드가 의미하고 필요한 행동의 해석에 동의해야는 의외의 사실은 우리가 버그를 가지고 아니라, 우리는 그들 중 몇이 없습니다.

IMO는 민첩한 프로세스 (예 : 스크럼, 크리스탈 등)가 제공하는 투명성이 개발이 일반 이해 관계자에게 어떻게 작동하는지 보여주기 위해 먼 길을가는 것을 발견했습니다.

은유에 의한 설명은 누출되는 추상화이지만 다음은 종종 저에게 효과적입니다.

이 설명 중 어느 것도 조잡한 일을 용서하지 않습니다.

컴퓨터 프로그램을 모든 변수가 움직이는 부분 인 기계라고 생각하십시오. 그것은 사소한 프로그램조차도 수백 개의 움직이는 부분으로 구성된 기계로 만듭니다.

그것이 실패하면, 나는 프로그램에 오류가 없다는 것을 수학적으로 증명할 수는 있지만 많은 시간이 걸리고 노력할 가치가 없다는 사실로 돌아갑니다.

마지막으로 인텔과 Microsoft가 버그를 피할 수 없는지 묻습니다. 어떻게해야합니까?

비슷한 질문 에 더 자세히 대답 했지만 요점은 "프로그래밍은 공장이나 조립 라인을 구축하는 것과 같습니다."입니다.

이를 나타내는 전통적인 방법은 프로젝트 관리 삼각 지대입니다. 범위, 비용 및 일정의 세 가지 경쟁 기준; 일반적으로 "저렴하고 빠르며 좋습니다. 두 개를 선택하십시오."

디자인, 개발 및 배포 프로세스 가 끝날 때 제품에 디자인 결함이없고 특정 기능으로 작동한다는 기대는 완벽하게 합리적입니다. 동일한 기대는 프로젝트, 프로세스 또는 직업과 관련하여 완전히 불합리합니다.

과학에 기반을 둔 전문가가 어렵거나 부드럽지만 탐구 과정을 거치지 않고, 정확하지 않은 (또는 단순한 틀린) 전술에 따라 부정확하고 부정확 한 개념을 형성하고 시행 착오를 통해 작동하는 것을 발견하고 자원이 고갈되거나 충분한 수준의 성능에 도달 할 때까지 계속해서 처리합니까?

더 높은 품질 수준에 무조건 접근 할 수 있지만 프로세스에는 결함이 없습니다.

전술에는 종종 추측과 프로토콜이 포함되는 의료 분야에서도 마찬가지입니다. 대부분의 활동은 기본적으로 대부분의웨어웨어 시스템을 디버깅하는 것입니다. 새로운 엔지니어링 재료의 응용 분야를 현장에서 검증해야하고 표준을 엄격하게 준수하더라도 수년간의 서비스를 수행 한 후에 갑자기 실패 할 수있는 토목 공학 및 건축은 사실입니다. 적용되는 엔지니어링 또는 수리 서비스의 결함없이, 작동 조건의 수명과 변화가 일반적으로 장애 지점까지의 성능에 영향을 미치는 자동차 분야에서도 마찬가지입니다. 소프트웨어 개발은 이러한 점에서 이러한 직업과 근본적으로 다르지 않으며 , 목적이있는 참신한 기계를 고안하는 데 초점을두고 있습니다.

원자로 제어, 우주 통신 또는 의료용 임플란트 장치 등과 같은 Hi-rel 소프트웨어 개발에 익숙한 경우 해당 수준의 Priject Management 및 QA에 대한 비용 및 배송 시간 구조를 설명 할 수 있습니다. 일반적인 비즈니스가 소프트웨어 프로젝트에 제공 할 수있는 것보다 훨씬 큰 규모 일 수 있습니다.

그들이 볼 수있는 것과 비교할 수 있고 가능하면 매일 사용하십시오.

예를 들어 자동차입니다. 자동차는 오늘날보다 훨씬 덜 세련되고 안정적인 장치를 시작했습니다. 자동차는 100 년 넘게 만들어졌지만 소프트웨어는 아마도 그 절반 정도일 것입니다. 자동차는 상당한 사용자 정의가 가능하며 일부는 가격에 포함 (색상 선택과 같은), 엔진 크기, 변속기 유형, 휠 / 타이어, 트림 레벨과 같은 일부는 상당한 비용이 소요됩니다.

자동차 및 소프트웨어를위한 많은 기능, 품질 및 비용 드라이버가 있습니다. 그런 다음 소프트웨어 기술, 전문 기술의 가용성, 그것이 구축 된 곳에서도 큰 차이를 만드는 방법에 대해 논의 할 수 있습니다. 적절한 개발주기 (예를 들어, 작은 변화가있는 매년 모델, 3 년마다 차체 / 엔진 / 플랫폼 변화)는 고객의 요구와 복잡한 설계 프로세스의 조합에 의해 이루어집니다. 일부 제품은 작고 엉성하게 보이기 시작하지만 (혼다 어코드 생각) 매년 최고 등급을받을 때까지 향상됩니다.

자동차는 부품리스트 변경 (버그 수정)을 변경하는 방식으로 리콜 (일반적으로 소프트웨어 업그레이드보다 비용이 많이 듭니다) 및 점진적 개선이 이루어졌으며 종종 장기적인 지원이 필요합니다 (역방향 / 역방향 호환성). 자동차 비용은 집으로 운전 한 후 발생합니다. 고객이 업데이트 및 업그레이드 할 때 소프트웨어 릴리스의 대부분은 초기 제품 릴리스 이후에 발생합니다.

경우에 따라 소프트웨어 또는 기타 소프트웨어 제품이 포함 된 잘 알려진 제품을 참조 할 수 있습니다. 예를 들어, 전화기에는 릴리스주기가 있으며 초기 판매 후 더 많은 수익을 창출하기 위해 기능을 추가하는 업데이트 및 방법이 있습니다. 전화는 순방향 / 역방향 호환성을 잘 보여줍니다. 너무 많아서 사람들은 오래된 것을 버리고 새로운 것을 사지 않을 것입니다. 너무 작아서 고객은 계약이 끝나기 전에 미워하지 않을 전화를 갖고 싶어합니다.

Windows, Microsoft Office, 웹 브라우저 및 웹 페이지와 같은 제품은 모두 토론에 사용할 수있는 소프트웨어입니다. 매년 또는 3 년 주기로 업데이트되었지만 자동 업데이트가 더 자주있을 수 있습니다. 여기에는 고객에게 다양한 정도로 영향을 미치는 버그 및 보안 허점이 있지만 최선의 노력에도 불구하고 환경의 일부입니다. 고객은 픽스를 무료로받을 수 있지만 일반적으로 번들, 개별 모듈 또는 라이센스 키를 통해 향상 비용을 지불합니다.

Microsoft, Apple, Google 및 Amazon과 같은 업계 리더는 모두 비교적 저렴한 고객을 사용자에게 제공합니다. 그러나 이러한 제품을 구현할 수있는 엄청난 비용이 있습니다. 그들의 경험에 따르면 소프트웨어는 비싸지 만 귀중하고 수익성이 있습니다. 그들은 종종 품질, 원하는 모든 기능을 갖추고 타이밍이 맞을 때 시장에 진입합니다. 그들이 만드는 모든 제품이 성공한 것은 아니며 때로는 이름을 바꾸거나 마케팅 및 판매를 개선하거나 손실을 줄이고 이후 제품에서 배운 것을 사용하여 개를 승자로 만듭니다.

아마도 일대일 또는 소그룹으로 이상적으로 살펴보고 개발해야 할 소프트웨어 사례를 사용하십시오. 사용 사례를 설명 할 때 예상치 못한 상황이 아닌 다른 상황이 발생할 수있는 상황을 파악하십시오. 그것들을 열거하기 시작하고, 설명을 요구하고, 결정되거나 해결되어야 할 모든 결정과 방향, 그리고 그에 따른 트레이드 오프를 설명하십시오. 그들이 쿵쾅 거리며 대답 할 수 없을 때까지 계속 가십시오. 그들과 함께 지금하고있는 일은 하루 종일, 아마도 자신이 직접하는 일이며, 과정을 결정하고 코드를 작성하는 방법은 수백 또는 수천에 달합니다. 다른 사람이 배치하거나 배치하지 않을 수있는 사용 사례. 그리고 때 당신이 생각하지 않은 경우에, 당신은 프로그램이 무엇을하는지 보증 할 수 없습니다. 어쩌면 그것은 "올바른"일을 할 수도 있습니다. 이것이 바로 버그입니다. 이것이 소프트웨어 작성에 시간이 걸리는 이유입니다. 시간이 짧을수록 고려하고 수용 할 기회가 적어지고 알 수없는 상황에서 프로그램이 "올바른"일을하지 않을 가능성이 높습니다.

비용과 시간.

시각

X를 Y 단위로 제공 할 것이라는 기대치를 설정하십시오. 더 이상 아무것도 없을 것입니다. 그런 다음 몇시에 다음 버전의 내용을 알려주세요. 처음에는 X 제작에 Y 시간이 걸린다는 사실에 놀랐을 것입니다. 여기에서 소프트웨어 제작에 소요되는 시간과 복잡성을 설명 할 수 있습니다. 그들이 놀라지 않는다면, 당신은 매우 적은 시간을 예상했거나 소프트웨어 구축에 대해 생각하는 것보다 더 잘 알고있었습니다.

비용

Steve McConnel의 Code Compete 책 (메모리에서 인용하므로 동일한 효과로 전달할 수 없으면 용서해주십시오)-고객이 새로운 기능을 쉽게 요청할 수 있습니다. 제품 관리자는 고객의 요구에 대해 말해서는 안됩니다. 새로운 기능을 구축하는 데 얼마나 많은 노력과 비용이 필요한지 추정해야합니다. 그들은 새로운 기능이 실제로 돈 / 시간의 가치가 없거나 또는 심지어 그것을 필요로하지 않는다는 것을 천천히 이해할 것입니다. 나는 당신이이 무기를 사용하여 그들을 놀라게하라고 제안하지는 않지만, 정직하게 사용하면 포인트를 집으로 운전하는 데 도움이 될 수 있습니다.

은유는 누출 된 추상화이지만 이해에 더 가까이 다가 갈 수있는 작은 단계입니다.

필자는 소프트웨어를 구축하는 것이 종종 집을 건축하는 것과 유사한 프로세스라는 점이다. 그러나 일부 매개 변수를 기반으로 사용자 정의 아키텍처 청사진을 인쇄하고 각 사용자마다 다른 청사진을 작성하는 시스템을 만드는 것으로 생각하는 것이 더 정확합니다. 괴짜 대화에서 메타 아키텍처입니다.

코드 작성의 의미를 보여줄 때 실제로 도움이 될 수 있음을 발견했습니다. 이해 관계자와 함께 작업중인 코드베이스를 보여줍니다. 좋은 변수와 메소드 이름을 선택하더라도 대부분의 사람들은 일종의 흑 마법을 사용한다고 생각할 것입니다. 아마도 그들은 소프트웨어에 새로운 기능을 구현하기 위해 "며칠 이상"필요한 이유를 이해할 것입니다.