개발 기간 동안 사양을 변경해서는 안되는 이유를 설명하고 싶습니다.

개발 기간 동안 새 계획 부서 직원에게 사양을 변경해서는 안되는 이유를 설명하고 싶습니다.

가장 단순한 프로젝트를 제외하고는 개발 중에 사양이 거의 항상 변경됩니다.

그 이유는 다음과 같습니다.

• 프로젝트의 개발 또는 통합 테스트를 통해 엣지 케이스에서 주요 패싯에 이르기까지 원래 사양을 수행 할 때 눈치 채지 못한 사항이 발견되었습니다. 예를 들어 개발자는 잘못된 메시지 확인 메시지가 도착할 수 있음을 알았습니다.

• 사양을 결정하는 실제 조건은 동결되지 않습니다. 예를 들어, 직통 처리 사양에 추가해야하는 새로운 금융 상품이 생성됩니다.

• 최종 기한 압력으로 인해 기능이 정리됩니다.

• 프로젝트에 대한 추가 이해 관계자가 발견됩니다 (예 : 프로젝트의 중간 단계에서 유사한 프로젝트가 다른 영역에서 발견되고 공통 하위 시스템이 중앙 집중식 / 공유되어야 함). 이는 2 년 동안 진행된 프로젝트의 중간 단계에서 발생하여 주요 재조정으로 이어졌습니다. 아키텍쳐).

• 프로젝트의 추가 스폰서는 새로운 사양 요구 사항을 갖습니다 (가장 유명한 예 중 하나는 Bradley Fighting Vehicle 개발 이력입니다).

사양 변경이 악영향을 미치는 이유에 대해 (거의 많은 이유, 제어 할 수없는 모든 이유 및 많은 이유가 있기 때문에 "발생하지 않아야 함"이라고 말할 수 없음)-

• 스펙 변경으로 인해 코드가 변경되어 아직 작성되지 않은 프로젝트 부분을 완료하지 못하게됩니다 (Joel Spolsky가 알다시피 초점 변경은 개발자에게 매우 좋지 않습니다).

• 일부 사양 변경 (때로는 매우 사소한 것으로 보임) 으로 인해 사양에서 취한 가정을 기반으로 두 아키텍처 중 하나를 선택했기 때문에 시스템을 완전히 리엔지니어링 / 재 설계해야 할 수 있습니다 .

• TDD의 경우 테스트에 투입된 많은 양의 작업이 무효화 될 수 있습니다.

• 위에서 언급 한대로 사양 변경 사항이 추가 이해 관계자로부터 나온 경우 기존 사양과 모순되어 제품 품질이 크게 저하 될 수 있습니다 (Bradley 파이팅 차량 참조).

• 스펙 변경은 체인저 / 요청자가 알지 못했거나 돌보지 않았을 수있는 기존 비즈니스 요구 사항을 위반할 수 있습니다 (이는 실제로 마지막 글 머리 기호와 동일 함).

이 모든 것들은 물론 프로젝트의 납품 일을 연장하고 (때로는 상당히) 결함 가능성을 높입니다.

사양의 사소한 변경으로 인해 극도의 문제가 발생할 수있는 가장 좋은 예를 들어, 3 글자가 있습니다.

Y2K .

그들이 한 것은 " 2000 년 이후에 작동해야한다 "라는 사양을 바꾸는 것이었다 .

또한, 일부 상황에서이 사양하는 경우 참 MUST은 ( "이유없이 변경하지 마십시오"반대)은 변경되지는 :

• 사양의 일부는 반드시 인터페이스되어야하는 외부 시스템의 사양입니다.

• 사양의 일부는 시스템이 구현되는 하드웨어입니다.

• 고객과의 계약 요구 사항 (단, 변경 사항과 달리 고객과의 변경을 먼저 수행하지 않고 계약을 변경하지 않고 사양을 변경하는 것에 대한 제한이 엄격하지만 제한 사항 임)

• 시스템은 고객 선호도에 관계없이 특정 법적 또는 규제 요구 사항을 충족해야 할 수 있습니다. 예 : 신용 카드 암호화, 세금 데이터 보호.

개발 중에 사양 변경을 금지하는 것은 프로그래머에게 이상적이지만 실제 환경에서는 현실적이지 않습니다. 사람들은 물건을 배송 할 때에도 항상 변경을 원할 것입니다. 절대 멈추지 않습니다. 그리고 그 사람들 중 일부는 월급에 서명 할 수도 있습니다. 관심이 많을수록 더 많이 생각하므로 디자인을 더 자주 수정하려고합니다. 처음부터 다시 시작하더라도 디자인을 완료하기 전에 디자인 변경을 허용 할 수 있어야합니다.

중요한 것은 모든 사람이 설계 프로세스에 대한 현실적인 기대를 가질 수 있도록 변경 결과를 명확하게 전달하는 것입니다.

변경 사항을 적절히 논의해야하며, 해당 담당자는 변경 사항이 배달 날짜에 어떤 영향을 미치는지 명확하게 이해해야합니다. 이를 위해서는 개발자와 대화해야합니다. 그러나 변경 사항에 대한 지속적인 논의는 개발자를 침수시키고 실제 작업이 발생하지 않도록하기 때문에 변경 사항은 계획된, 가끔 발생하는 간격으로 대기하고 논의해야합니다. 물론 그것은 당신이 원하는 것입니다.

이상적으로는 사람들에게 변경하고자하는 사항을 기록하고 매주 / 매주 / 매월 / 무엇이든 조정 회의에서이를 변경하도록 지시하십시오. 회의 중에 요청 된 기능을 구현하기 위해 수행해야 할 기본 수정 사항에 대한 토론과 완료 날짜에 미치는 영향을 포함하여 각 변경 요청에 대해 논의합니다. 변경의 "비용"이 설정되면 변경을 포함할지 여부를 결정할 수 있습니다.

이 프로세스가 도입하는 중요한 점은 각 변경에 관련 비용이 있으며, 더 많은 작업을 복제해야하기 때문에 프로젝트가 진행됨에 따라 비용이 일반적으로 더 높다는 개념입니다. 개발에 종사하지 않는 사람들은 대개 변경 비용이 얼마인지 모릅니다. 그들이 말할 수있는 유일한 방법은 그것을 제안하고 당신의 반응을 측정하는 것입니다. 명확하게 정의 된 변경 검토 프로세스를 작성하면 둘 모두에게 도움이됩니다.

프로그래머는 변경이 얼마나 쉬운 지에 대해 매우 낙관적이거나 변경이 얼마나 불가능한 지에 대해 매우 비관적 인 경향이 있습니다. 원래의 추정치를 결과와 비교하여 현재 상태를 파악하고 그에 따라 조정하십시오.

아마도 유효한 변경 요청 및 프로세스없이 사양을 변경해서는 안된다고 말하는 것이 좋습니다. 사양 변경 요청은 일정과 비용에 영향을 미치므로 승인에 반영해야합니다.

적절한 변경 관리 프로세스가 있다고 가정하면 사양 변경과 관련하여 "잘못된"것은 없지만 비용이 매우 많이 들기 때문에 고객이 만족하지 못할 수 있습니다. 몇 가지 좋은 요구 사항과 사양을 미리 가져 와서 변경하지 않아도되므로 스스로 보호 할 수 있습니다.

내가 가진 가장 좋은 비유는 집을 짓는 것과 비교하는 것입니다. 설계자는 계획을 작성한 다음 견적을 내고 고객은 계획에 동의합니다. 고객이 추가 욕실을 원하면 작업이 중단되고 계획이 변경되고 새로운 견적이 수행되며 고객이 동의하거나 동의하지 않습니다.

소프트웨어 작성도 다르지 않습니다. 일단 합의가 이루어지면 (설계 및 추정 후) 변경이 필요한 경우에는 새로운 계획을 세우기 위해 작업을 중단하고 새로운 추정을 승인 한 후 승인을 받거나 그 후에 작업을 다시 시작해야합니다.

내가 말 했든 말든 새로운 변경없이 프로젝트가 진행된다는 것을 의미합니다. 물론 새로운 계획과 추정을 내놓을 시간과 자료가 항상 있습니다.