무엇이 프로젝트를 크게 만드는가? [닫은]

호기심만으로도 중소형 프로젝트의 차이점은 무엇입니까? 코드 라인이나 복잡성으로 측정됩니까?

물물 교환 시스템을 구축하고 있으며 지금까지 로그인 / 등록을 위해 약 1000 줄의 코드가 있습니다. 비록 LOC가 많지만 이것이 첫 프로젝트이므로 그렇게 복잡하지 않기 때문에 큰 프로젝트로 생각하지 않을 것입니다. 어떻게 측정합니까?

복잡성.

복잡성이 높을수록 프로젝트의 모든 것을 배우기가 더 어렵습니다.

대략 내가 어떻게 일을하는지-이것은 다소 임의적이라는 것을 명심하십시오. 복잡성, 소스 코드 라인, 기능 수 / 비즈니스 가치 등과 같은 다른 요소들의 조합에서 프로젝트의 "크기". 아주 작은 제품은 많은 양의 가치 등을 전달할 수 있습니다.

• 2m + sloc 은 규모가 크거나 큰 프로젝트입니다. 이것들은 일반적으로 너무 복잡해서 어떤 사람들이 전체 시스템에서 '유창한'사람은 거의 없습니다. 오히려 코드 구조에 따라 책임이 모듈화되는 경향이 있습니다. 이러한 프로젝트는 종종 엄청난 비즈니스 가치를 제공하며 미션 크리티컬 할 수 있습니다. 또한 때로는 기술 부채 및 기타 기존 문제에 대한 부담이 큽니다.

• 100k-2m sloc 은 중간 규모의 프로젝트입니다. 이것은 나의 중간 근거입니다.이 프로젝트는 전문가의 지식이 필요할 정도로 복잡하며 어느 정도의 기술 부채가 발생했을 것입니다. 또한 어느 정도의 비즈니스 가치를 제공 할 것입니다.

• 10k-100k 는 소규모 프로젝트이지만 전문가가 고려할 정도로 복잡하지 않을 정도로 작지는 않습니다. 오픈 소스 인 경우 신뢰하는 사람들이 커밋을 검토하도록하십시오.

• 10k 슬로 미만의 작은 것은 실제로 작습니다. 그렇다고 전혀 가치를 제공 할 수 없으며, 매우 흥미로운 많은 프로젝트에는 아주 작은 각인이 있습니다 (예 : 캠핑, 소스가 ~ 2kb (!) 임). 비전문가는 일반적으로 도메인에 대해 너무 많이 알 필요없이 가치 문제를 해결 (버그 수정 및 기능 추가) 할 수 있습니다.

프로젝트의 크기는 유지 관리 수준에 따라 측정됩니다.

몇 가지 방법으로 추정 할 수있는 복잡성 :

1. 예산. 예산이 $ 10,000,000 + 인 프로젝트는 아마도 예를 들어 $ 10,000 미만인 프로젝트와는 상당히 다를 수 있습니다. 여기에는 인건비, 소프트웨어, 하드웨어 및 프로젝트 수행에 따른 기타 비용이 포함될 수 있습니다.
2. 프로젝트 완료를위한 인적 근무 시간. 백만 시간이나 다른 것이 필요할까요? 이것은 또한 일주일이 채 걸리지 않는 다른 프로젝트에 비해 몇 년이 걸리는 프로젝트가 타임 라인 요소로 보일 수 있습니다. 직원 시간을 두 배로 늘려서 프로젝트 시간을 두 배로 늘리면 일정이 절반으로 얇아 질 수 있으므로 직원 시간이 잘못 될 수 있습니다.
3. 프로젝트가 구축하는 것을 사용하는 하드웨어, 기타 시스템 및 사람들의 양. 무언가가 101 시스템에 묶여 있다면, 혼자 있고 다른 것에 묶이지 않으면 더 복잡 할 수 있습니다.

요구 사항은이를 측정하는 좋은 방법처럼 들릴 수 있지만, 비 폭포 방법론을 가정하여 프로젝트가 완료 될 때 더 많은 요구 사항이있을 수 있습니다.

프로젝트 크기는 시스템의 요구 사항 수에 따라 가장 잘 측정되며 요구 사항을 더 이상 줄일 수 없습니다.

물론, 더 많은 요구 사항은 대부분 복잡성을 의미하지만, 항상 그런 것은 아니다.

전체 프로젝트를 하나의 큰 그림으로 보는 것이 얼마나 어려운지에 따라 프로젝트의 크기를 측정합니다. 예를 들어, 작업중인 머신 러닝 문제에 대한 탐색 / 프로토 타이핑 코드베이스가 있습니다. 5k 줄의 코드이지만 거대한 프로젝트처럼 느껴집니다. 예측할 수없는 방식으로 상호 작용하는 수많은 구성 옵션이 있습니다. 코드베이스 어딘가에 알려진 모든 디자인 패턴을 찾아서 모든 복잡성을 관리 할 수 ​​있습니다. 디자인은 진화에 의해 많이 성장했으며 자주 리팩터링되지 않기 때문에 차선책입니다. 나는이 코드베이스에서 작동하는 유일한 사람이지만, 사물이 어떻게 상호 작용하는지 종종 놀랍습니다.

반면에, 내 취미 프로젝트 중 하나는 약 3-4 배 많은 코드를 가지고 있지만 기본적으로 서로 직교하는 수학 함수 라이브러리이기 때문에 훨씬 작습니다. 사물은 복잡한 방식으로 상호 작용하지 않으며 각 기능을 개별적으로 이해하는 것이 좋습니다. 볼 것이 많지 않기 때문에 큰 그림을 볼 수 있습니다.

임의의 답변 : 프로젝트 소싱은 이벤트 소싱 및 SOA를 통해 처음부터 시작한 규모입니다. 또는이 시스템의 저자는 Evan의 저서 "DDD : 소프트웨어의 핵심에있는 태클 복잡성";

적합성 및 범위

복잡성과 범위 나는 프로젝트가 실제로 얼마나 큰지를 결정하는 것이라고 생각합니다. 그러나 프로젝트의 규모에도 영향을 줄 수있는 몇 가지 무형 자산이 있습니다.

요구 사항

내가 직면 한 가장 큰 몰락은 요구 사항의 부족이었습니다. 내 특별한 상황에서 영업 관리자는 요구 사항을 결정했습니다. 그의 초점은 판매에있었습니다 .. 판매를 받아야합니다. 그의 마음에 고객이 요구 한 것이 비슷한 것을 구축했기 때문에 그렇게 복잡해 보이지는 않았습니다. 모호한 요구 사항으로 인해 일자리가 저렴하고 기대치가 커졌습니다.

CCMU의 부족

CCMU는 내가 " Coo Ca Moo "(완전한 상호 이해) 라고 부르는 것 입니다. 고객과 CCMU가 있어야합니다.

CCMU가 불량한 작은 프로젝트가있는 경우 프로젝트를 2,3,4 회 이상 수행 할 수 있습니다. 따라서 간단한 20 시간 작업은 스트레스를받는 직원과 매우 불만족스러운 고객이있는 60 시간 프로젝트로 바뀝니다.

스코프 크리프

생각보다 자주 발생합니다. 고객은 이미 A, B 및 C를 수행하고 있으므로 D 또는 F를 추가하는 것이 어렵지 않아야한다고 결정합니다.이 동작을 확인하지 않으면 소규모 프로젝트를 중간 규모 프로젝트로 전환 할 수도 있습니다. 영업 관리자가 작업을 판매 한 방식에 따라 이러한 범위 크리프 기대치는 고객에게 "무료" 로 보일 수 있습니다.

이상하게 도이 답변을 많이 읽으면 프로젝트의 크기가 매우 다르게 보입니다. 아마도 그것은 대기업에서 일하고 있지만 프로젝트의 크기를 고객에게 더 큰 가시성 / 바람직하지 않은 규모로 보는 경향이 있습니다 (작업 영역에 따라 동료 또는 실제 유료 고객이 될 수 있음).

복잡성이 정답이지만 어떻게 추정합니까?

요인은 다음과 같습니다.

1. 확장 점 수
2. 모듈 계층 수 (함수, 클래스, 클래스 시스템, 라이브러리, 공유 라이브러리, 응용 프로그램, 네트워크 응용 프로그램 등)
3. 종속성 수 (플랫폼 포함)
4. 상호 의존 수를 특징으로합니다.
5. 필요한 비 코드 리소스 (그래픽 / 아트 포함, 레벨 디자인 스크립트와 같은 스크립트 구동 및 응용 프로그램 버전을 완료하는 데 필요한 기타 리소스 포함)

그것들이 많을수록 프로젝트가 더 복잡합니다.

LOC 는 많은 측정에서 부정확 한 것으로 알려져 있지만 실제로 측정 할 수있는 정확한 방법이없는 것을 측정하려고합니다. 아마도 대안은 순환 복잡성 일 수있다 .

궁극적으로 프로젝트의 "큰 규모"는 정량화하기 어렵다고 생각합니다. 개가 큰지 아닌지 어떻게 판단 하느냐와 거의 같습니다. 그것을 측정하는 여러 가지 방법 (질량, 부피 등)이있을뿐만 아니라 개인적으로는 그다지 유용하지 않습니다. 현실은 내 기준이 아마도 "어두운 골목에서 볼 때이 개에서 도망 칠 가능성은 얼마나 될까?"와 같은 것일 것입니다.

그리고 기록을 위해, 나는 일반적으로 1k 줄의 코드를 많이 고려하지 않을 것입니다. 그것은 코드의 상당한 덩어리가 될 것이다, 그러나 그것은되지 않을 것 그 사물의 웅대 한 계획에 많은. 물론 언어에 의존한다고 생각합니다. 예를 들어 1k 줄의 코드는 Pyhon과 같은 언어보다 C와 같은 언어 의 코드가 훨씬 적습니다.