소프트웨어 개발에서 일상적인 작업의 양과 추정에 미치는 영향

소프트웨어 개발에있어 일상적인 작업의 양은 무시할 수 없을 정도로 상대적으로 적어야하며, 이는 소프트웨어 추정의 근본적인 문제라고 확신합니다.

이 결론에 도달하는 방법을 설명하고 논증에 심각한 결함이 있는지 알려주십시오.

1. 높은 정확도로 추정 할 수있는 모든 것은 일상적인 작업이므로 이전에 수행 된 작업을 의미합니다. 연구와 창의력과 관련된 다른 모든 종류의 작업은 적어도 +/- 20 %의 정확도로 추정 할 수는 없습니다.

2. 소프트웨어 개발은 ​​반복적 인 작업을 피하는 것입니다. 기본 원칙 중 하나는 DRY입니다 (반복하지 마십시오). 프로그래머가 스스로 반복적 인 일을 할 때마다이 반복을 피하는 추상화를 찾아야 할 때입니다. 이러한 추상화는 반복 된 코드를 함수로 추출하거나 루프에 넣는 것과 같은 간단한 작업 일 수 있습니다. 또한 도메인 별 언어를 만드는 것처럼 더 복잡 할 수도 있습니다. 어쨌든 그것들을 구현하려면 연구 (이전에 해본 적이 있습니까?) 또는 창의성이 필요합니다.

이 두 가지 점에서 위의 결론을 도출합니다.

실제로 나는이 관계가 다른 모든 토론, 블로그 게시물 또는 소프트웨어 추정에 관한 기사에서 언급되지 않은 이유에 대해 꽤 오랫동안 궁금해하고 있습니다. 너무 이론적입니까? 내 가정이 잘못 되었습니까? 아니면 너무 사소한 일입니까?하지만 왜 내가 아는 대부분의 개발자가 +/- 20 % 이상의 정확도로 견적을 수행 할 수 있다고 생각합니까?

주어진 단일 프로젝트에서 이것은 사실 일 수 있습니다. 그러나 여러 회사에서 여러 회사에 대해 여러 개의 유사한 프로젝트를 수행하는 경우 약간의 차이만으로도 기본적으로 동일한 문제를 여러 번 '해결'할 수 있습니다.

예를 들어 데이터 액세스 계층을 여러 번 작성 했으므로 이제는 인기있는 ORM을 사용하는 대신 '긴 손'을 선호합니다. 타사 구성 요소의 새로운 문제를 찾아서 해결하는 것보다 알려진 솔루션으로 '일상적인 문제'를 처리하는 것이 더 빠르고 쉽습니다.

분명히 다른 사람의 시스템에서 알 수없는 단점을 추가하지 않고 반복 코드를 단순화하기 위해 자체 ORM을 작성할 수는 있지만이 코드는 당시 근무했던 회사에 속할 것이며 다른 개발자는 이처럼 기발한 것을 발견 할 것입니다 기타 타사 ORM.

마찬가지로 내 경험상 대부분의 프로그래밍은 비즈니스 프로세스의 자동화이며 각 비즈니스는 프로세스가 고유하다고 생각하기를 원하지만; 실제로는 그렇지 않습니다.

추정이 쉽다는 것은 말할 것도 없습니다! 더 쉽지만 요즘 추정 문제는 코딩 시간보다 요구 사항이 부적절하기 때문입니다.

요구 사항은 세 가지 범주로 분류되는 경향이 있습니다.

1. 모호한 세부 사항은 개발자에게 남았습니다.

"웹 사이트를 만들어주세요. 멋지고 위젯을 판매해야합니다."

예상치 못한 어려운 문제가 발생했을 때 요구 사항을 기능적으로 동등한 것으로 변경하고 문제를 피할 수 있으므로 추정하기가 가장 쉬운 경향이 있습니다.

2. 매우 구체적

"헤더 배경색을 # ff1100으로"

매우 빠르게 수행하고 다시 한 번 추정하기 쉽습니다. 그러나! 요구 사항은 변경 될 수밖에 없습니다. "음, 아니 다른 생각을 해보자"또는 "잠깐만! 나는 한 페이지에서만 의미했다!" "헤더 색상에 만족할 때까지의 시간"의 실시간 범위는 코딩 추정치와 관련이 없습니다.

3. 모호한 세부 사항 가정

"페이스 북처럼 웹 사이트를 만들어 줘"

여기에 여러 가지 언급되지 않은 가정, "물론 다른 로고를 원할 것", "무한 스크롤이 있어야합니다", "10 억 사용자까지 확장 가능해야합니다!" 추정을 효과적으로 제어합니다. 개발자는 모든 것을 생각하고 예상을 "1 meeelion man hours"를 넘어서게하거나, 기본 기능 만 필요하다고 생각하고 가정하며 너무 낮은 추정치를 제공합니다. "오, 일주일에 두 번, ibook에 페이스 북을 넣고 싶다고 생각하십니까?"

경험이 있으면 코딩 속도는 매우 빠르지 만 설계 요구 사항은 (일반적으로) 하드 비트이며, 이는 비코 더로 점점 더 밀려납니다. 민첩한 방법론으로 개발자가 아닌 '비즈니스'로이 책임을 옮겨 코딩 속도를 높입니다.

왜 내가 아는 대부분의 개발자는 +/- 20 % 이상의 정확도로 추정을 수행 할 수 있다고 생각합니까?

실제 문제보다 문제에 대한 인내심을 추정하기 때문입니다.

튀는 공에 애니메이션을 적용하려면 하루, 일주일, 한 달 또는 1 년 동안 공을 보내면서도 튀는 공의 애니메이션을 볼 수 있습니다. 바라건대 내가 더 많은 시간을 할애하는 것이 좋을 것입니다. 그러나 어떤 시점에서 나는 말도 안됩니다.

볼 바운스를 만드는 데 얼마나 많은 노력을 기울이는가는 시간을 절약 할 수있는 기능입니다. 내 기술 수준이 잘리지 않으면 거기에 앉아있는 공이 생길 수 있습니다. 그러나 마감 시한이되었을 때 마감 시한이 미끄러지거나 화면에 공이 들어가야합니까? 폭포는 볼 바운스를 주장하고 일정이 미끄러졌다. 애자일은 공을 꺼내라고 말합니다. 적어도 우리는 사람들이 수신 거부에 대해 얼마나 신경을 쓰는지 알게 될 것입니다. 그래서 품질이 떨어졌습니다.

나는 공이 튀어 오를 수 있도록 노력하지만 마감일이 다가 오면 아무것도 아닌 것보다 정적 공을 만드는 것이 좋습니다. 따라서 대안에 대해 이야기하기 전에 문제에 대해 합당한 시간을 소비 한 것으로 보이는 시간을 기준으로 시간을 추정합니다. 때로는 공이 튀지 않을 수도 있습니다. 때로는 괜찮습니다. 한 달 동안 사라지는 것은 괜찮습니다.