대규모 프로젝트를 개발할 때 가장 큰 병목 현상은 무엇입니까? [닫은]

우리 회사가 MS Word의 복제본을 개발했다고 가정 해 보겠습니다 (예를 들어). 사용 가능한 무한 현금과 Microsoft와 같은 조직이 있다고 가정하면 개발 프로세스의 병목 현상은 무엇입니까? 다시 말해, 그러한 소프트웨어를 빠르게 개발할 때 가장 일반적인 장애는 무엇입니까? 모든 사양이 제자리에 있고 조직이 완벽하게 작동한다고 가정하여 제품을 출하 할 준비가 될 때까지 소프트웨어 개발에 중점을 둡니다. 일부 대안은 다음과 같습니다.-코드 작성-테스트 작성-최종 제품 수동 테스트-처음에는 열악한 디자인으로 코드 다시 작성-코드 설계-숙련 된 개발자가 수행 한 코드 검토-GUI 설계-알파를 기반으로 GUI 재 설계 / 베타 사용자 피드백-사용자의 피드백 처리-알파 / 베타 사용자 피드백을 기다리는 중

답변에 참고 문헌을 사용하거나 주제에 대한 경험을 말하십시오.

내 경험상 주요 "병목 현상"은 학습 과정 입니다. 가상의 회사가 다음 Microsoft Word를 개발하려고 할 때 알아야 할 것과 실제로 알고있는 것 사이에 큰 차이가 있습니다. 격차의 크기는 많은 요소에 따라 다르며 기술이나 도메인에있을 수 있습니다. 디자인, 사용자 피드백 등과 같은 질문에서 이러한 문제 중 일부를 다루었습니다. Microsoft Word는 현재 30 년 동안 개발되어 왔으며, 역사, 코드, 도구 및 사람들 사이에 많은 지식이 있습니다.

따라서이 작업을 수행하려고하면 기술 및 관리 분야에서 경험이있는 최고의 직원을 고용하려고합니다. 현장에서 사용 가능한 모든 문헌을 사용해보십시오. 또한 가능한 빨리 고객 피드백을 얻으려고 노력합니다. 가장 큰 문제는 당신이 모르는 중요한 것들이며 프로세스가 늦게 발견 될 수 있습니다.

그건 그렇고, 소프트웨어 프로젝트에 고유하지 않습니다. 새로운 일을하려는 모든 대규모 프로젝트에 적용됩니다. 예를 들어 보잉 드림 라이너를보십시오. 이것에 관한 많은 책이 있습니다. 신화의 달은 하나입니다.

모든 사양이 갖추어져 있고 조직이 완벽하게 작동한다고 가정 해 봅시다.

소프트웨어 개발 프로세스에서 가장 큰 두 가지 병목 현상이 존재하지 않는다고 가정했습니다 (개인 경험으로는).

가설적이고 완벽한 세상에서도 볼 수있는 몇 가지 문제가 있습니다.

아마도 내 관점에서 볼 때 가장 중요한 것은 고객을 다루는 것입니다. 내 경험상, 사업은 프로젝트가 개발되는 동안 자주 변경하려고하는 고객을 다루어야합니다. 어떤 경우에는 돈을 지불하지 않기 위해 변경 요청을 버그 수정으로 해결하려고했습니다. 이로 인해 많은 관료주의가 발생하여 프로젝트를 지연 시키거나 코드의 빠른 해킹으로 이어질 수 있으며 기술 부채가 줄어 듭니다. 나는 호흡하는 것만 큼 쉽게 이러한 문제를 다루는 팀을 읽고 들었습니다.

두 번째 문제는 적절한 도메인 모델이 없다는 것입니다. Eric Evans는 자신의 저서 인 Domain Driven Design에서 이에 대해 잘 설명 합니다. 좋은 도메인 모델이 없으면 버그 찾기와 같은 글렌의 답변에서 강조된 몇 가지 문제가 발생합니다. 깔끔한 도메인 모델이 없으면 코드를 탐색 / 디버그하여 문제를 격리하고 해결하는 데 시간이 오래 걸릴 수 있습니다. 좋은 도메인 모델을 사용하면 응용 프로그램을 유지 관리하고 확장 할 때 훨씬 더 쉽게 인생과 디버깅을 할 수 있다고 주장합니다.

위에서 언급 한 문제로 즉각적인 문제는 발생하지 않지만이 제품을 장기간 유지 관리해야하는 경우 다시 귀사와 팀을 괴롭힐 수 있습니다.

"조직이 완벽하게 작동하고있다"는 것이 무엇을 의미하는지 잘 모르겠지만 환상적인 조직에서도 규모가 큰 프로젝트의 가장 큰 병목은 커뮤니케이션입니다. Mythical Man Month는 프로젝트 팀이 성장함에 따라 커뮤니케이션 조합이 폭발하여 오류와 누락 된 정보를 거의 보장하는 방법을 지적합니다.

지금까지 내가 본 일에서 보았을 때, 병목 현상의 큰 원인은 단순히 버그와 그로 인한 인적 오류에서 비롯됩니다. 코드를 디버깅하고 문제에 대한 해결책을 찾은 다음 새로운 솔루션을 다시 테스트하는 데 걸리는 시간을 생각하십시오. 이제이 수정으로 인해 또 다른 미묘한 버그가 발생했다고 상상해보십시오. 그것은 큰 고통의 흐름이 될 수 있고 따라서 전반적인 발달 속도를 늦춘다.

브랜든 모 레츠가 가장 좋은 답변이라고 생각합니다. 그러나 큰 프로젝트에서 첫 번째 버전을 얻는 것이 그렇게 어려운 것은 아니라고 덧붙이고 싶습니다. 나는 개인적으로 그렇게하지 않았습니다.

내가 실패한 것은 두 번째, 세 번째 등 버전 및 버그 수정 및 / 또는 사소한 기능 향상을 적시에 제공 할 수있는 방식으로 첫 번째 버전을 만드는 것입니다.

예, 위의 사항에 동의하며 소프트웨어 모델을 따라야합니다. 내 지식에 따라 주요 사항은 다음과 같습니다.

1. 시간 관리 2. 팀 효율성 및 팀 관리 3. 팀 조정 및 4. 고객과의 더 나은 이해

우리가 위의 4 가지를 가지고 있다면, 우리는 개성과 소프트웨어 측면에서 성공과 많은 개선으로 새로운 세계로 옮길 수 있습니다.

요구 사항, 디자인, 구현, 배포 등의 잠재적 결함 소프트웨어 개발이 모든 새로운 버그가 가장 최근의 변경으로 인해 발생했다고 상상해보십시오.