소프트웨어 스케줄을 정의하기 어려운 이유는 무엇입니까?

내 경험상 엔지니어가 완료해야 할 작업을 정확하게 예측하고 결정하게하는 것은 이빨을 당기는 것과 같습니다. 약 2 ~ 3 주 또는 3 ~ 6 개월의 스왑 추정치를 제공하는 대신 소프트웨어 스케줄을 정의하는 가장 간단한 방법은 무엇입니까? 예를 들어 고객 A는 2011 년 2 월 1 일까지 기능을 원합니다. 진행 중에 다른 버그 수정이 필요할 수 있으며 추가 엔지니어링 시간이 걸리는 것을 알고이 기능을 구현할 시간을 어떻게 예약합니까?

친숙한 도구와 친숙한 팀을 사용하여 수행 한 다른 프로젝트와 거의 동일한 프로젝트를 작성하고 있고 엄격한 서면 요구 사항이 제공되는 경우 적절한 추정이 가능해야합니다.

이것은 화가, 카펫 설치자, 조경사 등이 정기적으로 경험하는 조건입니다. 그러나 많은 (또는 대부분의) 소프트웨어 프로젝트에는 적합하지 않습니다.

요구 사항이 바뀌는 등 새로운 도구, 기술을 사용하는 프로젝트를 추정해야하는 경우가 종종 있습니다. 이것은 과거 경험에 대한 보간보다 알려지지 않은 것에 대한 외삽입니다. 따라서 추정이 더 어려워지는 것은 당연합니다.

내 개인적인 경험에 따르면, 그것은 Pemdas가 말한 것과 정확히 반대입니다 . 실제로, 작업이 얼마나 많은 시간이 필요한지 추정하는 것은 완전히 불가능하다는 것을 이해했습니다. 소프트웨어 개발 경력이 시작될 때 종종 "45 일", "5 주"등과 같은 견적을 내린 후 시간을 끝내기 위해 열심히 노력했습니다. 몇 년 후, 나는 "약 1 개월", "5-7 주"등과 같이 덜 정확한 견적을 제공하기 시작했습니다. 실제로, 나는 견적을하지 말라고하거나 고객에게 자신의 견적을하도록 요청합니다. 또는 마감일 또는 가능한 한 대략적인 견적을 제공합니다.

추정이 어려운 이유는 무엇입니까? 실제로 전체 소스 코드를 작성하기 전에 전체 소스 코드를 작성하는 방법을 아는 것은 거의 불가능하기 때문에 다른 사람들이 작업하거나 동기를 부여하는 등의 작업이 무작위로 수행되기 때문에 가능한 이유에 대한 자세한 목록은 다음과 같습니다.

1. 그것은 알고 쉬운 일이 아니다 특히 정확하게 제품을해야 할 필요가 무엇인지, 그리고 어떻게 그것을 할 . 며칠 동안 일한 후 나의 첫 번째 접근 방식이 잘못되었다는 것을 이해하고 일을 수행하는 더 좋고 현명한 방법이 있다는 것을 이해하는 것보다 종종 응용 프로그램의 일부를 시작했습니다.

2. 약간의 문제가 발생할 수 있습니다 . 예를 들어, 작업을 시작하기 위해 컴퓨터에 멋진 SQL Server를 설치해야하고 설치에 실패하고 지원이없는 경우이 문제를 해결하는 데 몇 주가 소요될 수 있습니다.

3. 요구 사항은 종종 명확하지 않지만 처음에 요구 사항 을 읽은 후 요구 사항 이라고 생각합니다. 때로는 평균 'A'를 이해하고 구현을 시작한 후에는 'B'를 의미 할 수 있습니다.

4. 변화의 요구 사항과 같은 고객은 당신은 단지 관련 부분을 마친 정확히 왜 당신이해야 할 두 개 더 주 $ 2000 요구하고, 그들은 정말 이해가되지 않는 작은 사람들이 볼하지 않기 때문에, 변화를 작은 변화가 필요 다른 것들을 바꾸어야하는 다른 것들을 바꾸는 것 등

5. 당신은 당신의 동기를 추정 할 수 없습니다 . 몇 시간 동안 일하고 성공할 수있는 날이 있습니다. 10 줄의 코드를 작성한 후 Programmers StackExchange로 전환하고 몇 가지 질문에 대한 답변을 읽는 데 몇 주가 걸립니다.

6. 추정치가 다른 사람에게 의존 할 때 상황이 정말 나빠 집니다 . 예를 들어, 2 개월 동안 한 프로젝트에서 디자이너가 내 작업을 마치기 위해 자신의 작업을 수행 할 때까지 기다려야했습니다. 이 디자이너는 사용할 수없는 쓰레기를 배달하기까지 3 개월이 걸렸습니다. 물론 프로젝트는 늦었다.

7. 견적은 고객에 따라 다릅니다 . 메일을 받기 전에 몇 주를 소비 한 고객이있었습니다. 답변을 기다려야 할 때 일정에 실제로 영향을 줄 수 있습니다 (예 : 정확한 요구 사항을 요구하는 경우).

당신은 무엇을 할 수 있나요?

1. 더 큰 일정을 제공하십시오 . 2 주 안에 업무를 수행 할 수 있다고 생각되면 한 달 안에 업무를 수행한다고 가정하십시오.

2. 명확해야 합니다. 디자이너, 다른 개발자 등에 게 의지한다면 말하십시오. "3 개월 안에 제품을 배송 할 것"이라고 말하는 대신 "디자이너가 PSD 파일을 제공 한 후 2 개월 안에 제품을 배송 할 것"이라고 말합니다.

3. 요구 사항이 매일 바뀌면 프로젝트가 제 시간에 전달되지 않을 것이라고 설명합니다.

4. 일정을 슬라이스하십시오 . 대규모 프로젝트의 일부를 제 시간에 제공하는 것이 더 쉽습니다.

5. 잘 모르는 제품을 사용할 때, 특히 다른 사람의 소스 코드로 작업 할 때 견적을 제공하지 마십시오. 이해하고 복사하여 Daily WTF에 복사하여 붙여 넣습니다.

매우 유사한 질문은 "이 크로스 워드 퍼즐을 해결하는 데 얼마나 걸립니까?"입니다.

다음과 같은 수많은 것들을 볼 때까지 대답 할 수 없습니다.

• 익숙한 언어로되어 있습니까? (스페인어 대 영어 대 중국어)
• 이전에 해결 한 유형 중 하나입니까? (예 : 잡지에서 실행되는 시리즈 중 하나)
• 리드가 이해되기 전에 추가 지식이 필요합니까?
• 당신의 지식에 따라 추가 작업이 필요한 퍼즐 부분이 있습니까?

프로젝트에는 일반적으로 몇 가지 새로운 것이 있기 때문에 (그렇지 않으면 프로젝트가 아닐 수 있음) 매우 신중하게 검토 할 때까지 해결하는 데 시간이 얼마나 걸리는지 알 수 없습니다. 어쩌면 더 많거나 적은 것을 해결하더라도, 당신은 여전히 ​​당신이 그들을 생각하지 않은 놀라움이나 두 가지가 있는지 확신하지 못합니다.

또한 가능한 한 저렴하게 수행해야한다는 강한 압력이 가해 지므로 가능한 빨리 처리해야하며 너무 낮은 견적에 대한 책임은 프로젝트 관리자에게 압력을 가하는 것이 아니라 개발자에게 견적을 제공하는 것입니다. 개발자가 이것을 잡는 데 많은 반복이 필요하지 않으며 절대 숫자를 제공하는 것이 매우 피곤합니다.

엔지니어가 정확한 견적을 제공 할 수없는 가장 확실한 이유는 불가능하다는 것 입니다.

물론 집에서 일하는 데 걸리는 시간은 +2 분 정도입니다. 자동차를 운전하는 방법, 교통량 및 기타 외부 요인을 평가할 수 있습니다.

런던에서 바르셀로나까지 운전하는데 시간이 얼마나 걸리는지 알려주세요. 물론 고급 GPS 계획 도구가 없습니다. 우리가 여전히 소프트웨어 추정에서하는 것처럼 좋은 오래된 방법을 사용합니다. 경험적 추정 및 예측 .

소프트웨어에서는 더 나쁘다 :

1. 견적은 종종 약속 이되므로 판단이 수정됩니다.
2. 동일한 작업에 대한 Bob과 Karl의 추정에는 큰 차이 가있을 수 있습니다 .
3. 불확실성 은 매우 흔하며, 우리 중 얼마나 많은 사람들이 어리석은 버그 나 하드 드라이브 충돌에 갇혀서 좋은 추정치를 파괴 하는가.
4. 회의, 전화 통화, 동료 지원 등 프로그래밍 이외의 다른 모든 작업 은 일반적으로 잊어 버립니다 .
5. 인간의 뇌는 제한적 입니다. 장기 실행 작업을 추정하도록 설계되지 않았습니다.

따라서 고객에게 2011 년 2 월 1 일에 배송 할 수있는 내용을 정확하게 알려주고 2011 년 1 월 1 일을 잊어 버리는 것이 불가능한 이유입니다.

이러한 모든 문제를 해결하기 위해 Planning Poker (면책 조항 : 이것은 내 웹 사이트 중 하나임) 및 Velocity 계산을 사용한 반복 개발 과 같은 고급 예측 기술을 사용하는 것이 좋습니다 .

• 처음 두 가지 문제는 Planning Poker를 사용하여 해결되었습니다. 견적은 집단적이며 팀은 개인보다는 소유합니다.
• 마지막 세 번째 문제는 Velocity and Iterative Development를 사용하여 해결됩니다. 속도 (이력을 기반으로 한 추정에 적용 할 요소)를 알면보다 확실하게 릴리즈를 계획 할 수 있습니다. 반복 개발은 제대로 수행되면 가장 중요한 기능을 맨 위에 가져오고 사용자에게 가치를 조기에 제공하는 데 도움이됩니다.

소프트웨어 개발은 ​​정의상 발견과 발명의 행위입니다. 항상 알려지지 않은 것을 포함해야합니다.

소프트웨어 개발과 관련된 모든 것이 알려진 유일한 시점은 소프트웨어가 완료된 시점입니다.

알려지지 않은 기술이나 비즈니스 기능이없는 유일한 시점은 다운로드 준비가 완료된 패키지 솔루션 일 때입니다.

새로운 소프트웨어를 작성하는 이유는 새로운 기능이나 새로운 기술 또는 둘 다를 가지고 있기 때문입니다. 새로운 것은 새로운, 알 수없는, 예측할 수없는 것을 의미합니다.

소프트웨어 개발에는 참신함이 필요하기 때문에 개발 노력을 예측할 수 없습니다.

솔직히 말하면 연습이 필요하다고 생각합니다. 충분한 코드를 작성하면 "정직하게"정확해야합니다. 첫 번째 상사는이 기술이 내가 구현 한 모든 기능 / 프로젝트에서 비공식적으로 연습하도록 요청하기에이 기술이 충분히 중요하다고 믿었습니다. 각 프로젝트 후 우리는 추정치를 검토하고 내가 어디로 잘못되었는지 알아 내려고 시도했습니다. 결국, 당신은 그것의 걸림돌을 얻는다.

결코 쉬운 일이 아닙니다. 당신은 그것을 더 잘하려고합니다.

제공 가능한 코드를 더 작은 조각으로 나누면 얻을 수있는 이점 중 하나는 고객이 예상 할 내용과 예상시기를 이해할 수 있다는 것입니다. 이제 기준으로 사용할 기준이 있습니다.

정의 된 시간에 필요한 기능에 대한 엄격한 정의가있는 경우 추가 요청이이 요청에 할당되어야한다는 것을 알아야합니다. 그들은 발생하는 버그의 심각성과 버그를 수정하지 않고 얼마나 오래 갈 수있는 위험에 처해 있습니다. 중요한 것이 나오면 고객에게 돌아가서 결정을 내립니다. 버그를 수정하거나 새로운 기능에 대한 마감 시한을 설정합니까? 정보에 입각 한 결정을 내릴 수 있도록 충분한 정보를 제공하십시오.

잘하면 당신은 함께 일한 역사가 충분하고 신뢰할 수있을만큼 자신을 확립하기를 바랍니다. 개발 프로세스를 완전히 이해할 것으로 기대할 수는 없지만 정직한 노력을 기울이고 지식이 부족하다는 점을 느끼지 못하게 할 수 있습니다.

스케줄을 너무 일찍하기 때문입니다. 예비 거친 일을 한 다음 나중에 더 나은 것에 관한 Construx의 기사 를 참조하십시오 . 또한 당신이 이전의 추정치에서 어떻게했는지 추적하지 않으면 더 나아지 기가 어렵습니다. FogBugz는 [무료 고객, 다른 이해 상충 없음]의 고객입니다.

나는이 책에서 많은 것을 배웠다 :

소프트웨어 견적 : 블랙 아트의 미스터리

더 나은 추정 결과를 얻으려면 다음과 같이하십시오.

1. 사소한 작업을 제외한 모든 작업은 한 명 이상의 사람이 추정합니다 (이 경우에는 두 명).
2. 우리는 작업을 작은 작업으로 나눕니다. 더 많은 일을할수록 당신의 추정은 더 좋을 것입니다-내가 부를 올바르게 기억한다면 많은 수의 법칙
3. 우리는 최악의 시나리오와 가장 가능성이 높은 시나리오를 추정합니다. 때때로 우리 각자는 이러한 트리 시나리오를 완전히 다르게 추정합니다. 그것은 우리가 이야기해야한다는 것을 의미하며 보통 우리 중 하나가 그 과제를 이해하지 못했음을 알게됩니다. 한 사람이 과제 만 추정했다면 잘못 추정되었을 것입니다.
4. 우리는 위의 점에서 3 개의 숫자를 방정식에 넣고 추정값을받습니다.

작업이 완료되고 추정치가 잘못되면 이유를 찾으려고 노력합니다. 그리고 우리는이 지식을 다음 추정 프로세스에 통합합니다. 지금까지 이것은 더 큰 작업을 추정하는 데 사용한 최고의 프로세스입니다. 제가 할 일은 약 50-500 시간이 걸리는 작업을 의미합니다.

참고 : 이것은 시간 단위로 요금을 청구하는 프로젝트와 고정 / 플랫 요금에 대해서만 실제로 적용됩니다.

나는 일반적으로 일정을 계획하여 본질적으로 SCRUM 스프린트 (SCRUM 사용 여부에 관계없이)로 구성됩니다. 일정을 만들 때 각 스프린트의 길이와 프로젝트의 기능을 결정합니다. 일반적으로 먼저 수행해야 할 몇 가지 기능이 있으므로 해당 기능에 대해 최적의 견적을 제공하려고 시도하고 (최적화와 혼동하지 말 것) 프로젝트가 끝날 예정인 기능은 일반화 된 견적을 갖습니다. 스프린트에 기능을 맵핑 한 후 프로젝트의 마지막 끝에 1 ~ 2 개의 스프린트를 추가하여 올바르게 슬라이드하는 기능과 원래 요구 사항 수집에서 간과 한 기능을 설명합니다.

이것의 핵심은 클라이언트 에게이 모든 것을 투명하게 만들어서 마지막 두 스프린트가 비어 있거나 드문 드문 이유를 이해하는 것입니다. 적어도 지금까지 내가 작업 한 고객은 일정 / 재정에 약간의 쿠션이 있다는 것을 알고 있기 때문에 이것을 좋아했다. 대부분의 사람들은 SW 추정치가 구체적이지 않다는 것을 알고 있기 때문이다. 또한 우리는 마지막 스프린트가 필요하지 않으면 청구하지 않는 시간이라는 것을 알고 있습니다. 일정 작성 방식의 투명성과 프로젝트 실행 중 진행 상황에 대한 정기적 인 피드백으로이 작업을 수행 한 모든 클라이언트가 매우 만족했습니다.

명명 된 모든 것 외에도이 두 가지를 가장 큰 문제 중 하나로 봅니다. 먼저 일주일에 5 일 하루 8 시간 동안 사용할 수있는 모든 개발자를 기준으로 최종 날짜를 추정합니다. 이것은 정확하지 않으며 사소하지 않은 프로젝트에서 종료 날짜가 누락되었음을 거의 100 % 보증합니다. 사람들은 쉬는 시간, 회사 (또는 프로젝트가 아닌) 회의에 참석하거나, 건강 보험 청구에 대해 HR과 싸우거나, 휴식을 취하는 등의 일을합니다. 개발자 당 하루에 6 시간 이상의 가용성을 가정하지 마십시오.

다음 개발자들은 프로젝트, 배포, QA 지원, UAT 지원, 작문 단위 테스트, 연구, 문서화 등과 관련된 회의 및 이메일과 같은 비 개발 작업을 모두 추정하는 것을 잊어 버립니다. 이러한 유형의 작업을 평가 스프레드 시트에 추가하면 견적이 나아졌습니다.

몇 시간 이상 걸릴 수있는 작업에 대한 시간을 추정 할 때이 규칙을 사용하기 위해 최선을 다합니다.

1. 하지 마십시오 이제까지 당신이 그것에 의존하는 일이면 다른 사람들이 작업을 마칠 때 예측하려고합니다. 자신 만 말하십시오.
2. 먼저 작업을 분석 한 다음 추정하십시오. 분석한다는 것은 적어도 각각의 하위 작업 목록을 작성하고 하위 작업 목록을 작성하는 것을 의미합니다.
3. 작업이 충분히 복잡한 경우 이러한 분석 자체의 시간을 추정하십시오. 추정은 별도의 과정으로 두십시오. 당신은 또한 당신의 상사가 그것에 대해 알고 있는지 확인할 수 있습니다.
4. 압박을 받고 추정하지 마십시오. 합리적인 견적을 내리는 데 시간이 걸린다는 점을 분명히하고 "내가 일을 분석을 마치면 11 시까 지 날짜를 정할 것"과 같은 것을 알려주십시오. 일부 고객 / 관리자가 압박을 가할 수는 있지만 통과하지 못할 것입니다. 바쁜 얼굴을 쓰고 시간을 요구하십시오!
5. 추정에 커피 휴식 시간 (및 분산)을 추가하는 것을 잊었 기 때문에 필요한 것 보다 약간 더 많은 시간을 요구하십시오.
6. 큰 작업의 경우 더 많은 것을 요구하십시오-아마도 하나 이상의 커피 브레이크가있을 것입니다.
7. 실제로 추정 할 수 없거나 (과업이 너무 어렵거나 익숙하지 않은 경우) 확실하지 않은 경우 분석에 도움을 줄 수있는 사람에게 문의하십시오.

아마도 그보다 더 많은 규칙이있을 수 있지만 실제로이 규칙을 가진 포스터는 내 벽에 없습니다. 나는 방금 그것들을 공식화했지만 그들은 내 경험에서 나왔습니다 (그래서 당신에게 효과가 없을 수도 있습니다).

제가 생각할 수있는 소프트웨어 개발을 예약 할 수있는 믿을만한 유일한 방법은 증거 기반 예약 (Evidence Based Scheduling )으로, 기본적으로 몬테 카를로 (Monte Carlo) 방법입니다. 전에 성취했다. 예상 시간과 실제 시간 이외의 다른 메트릭을 사용하지 않기 때문에 기분이 좋습니다. 그러나 큰 작업을 미리 작은 작업으로 분할하려면 많은 경험이 필요하며 충분히 정확하게 작동하려면 많은 과거 데이터가 있어야합니다.

있다 "알려진 미지수"와 "알 수없는 미지가." :-)

1. 견적은 종종 마감일이됩니다.

   • 마감일을 놓치고 헤드 라인이되는 사람은 없습니다!

2. 요구 사항은 (합리적으로) 변경되며 프로그래머는 거부 할 수 없습니다.

3. 프로그래머는 다음과 같은 요소에 대한 통제력을 갖거나 갖지 못할 수 있습니다

   • 그녀가 숙달 된 코드의 가용성
   • 그녀가 의존하는 코드 품질
   • 시스템의 전체 아키텍처 및 설계
   • 시스템의 다른 부분에 액세스하기위한 API