레거시 코드베이스에서 시간 비용 추정

최근에 아주 오래된 단일 응용 프로그램이 마이크로 서비스 기반 아키텍처로 마이그레이션되는 프로젝트를 시작했습니다.

레거시 코드베이스는 매우 혼란스럽고 ( '스파게티 코드') 종종 단순한 함수 (예 : "multiplyValueByTen")는 나중에 "3 개의 서로 다른 스키마에서 10 개의 테이블을 포함하는 수천 개의 유효성 검사 코드 행"으로 나타납니다.

이제 상사는 새 아키텍처에서 기능 X를 작성하는 데 걸리는 시간을 추정하도록 요구하고 있습니다. 그러나 나는 현실적인 평가를 내리는 데 어려움을 겪고 있습니다. 자주 상당히 때문에 내가 위에서 언급 한 이유로 작업을 과소 평가하고 내가 시간에 완료 할 수 없기 때문에 자신을 당황하게.

현명한 것은 실제로 코드에 들어가서 모든 브랜치를 기록하고 다른 함수를 호출 한 다음 시간 비용을 추정하는 것처럼 보일 수 있습니다. 그러나 이전 코드를 문서화하는 것과 실제로 새 버전을 작성하는 것 사이에는 약간의 차이가 있습니다.

이와 같은 시나리오에 어떻게 접근해야합니까?

레거시 코드 리팩토링 작동 방식을 완벽하게 이해하고 있지만 제 질문은 "리팩터링 / 재 작성 방법"에 관한 것이 아닙니다. "파트 X를 리팩토링 / 재 작성하는 데 시간이 얼마나 걸립니까?"

Bob Martin의 "Clean Coder"(및 "Clean Code")를 읽으십시오. 다음은 메모리에서 가져온 것이지만 직접 구매 하는 것이 좋습니다.

당신이해야 할 일은 3 점 가중 평균입니다. 각 작업에 대해 세 가지 추정을 수행합니다.

• 가장 좋은 시나리오-모든 것이 올바르게 진행된다고 가정하면 (a)
• 최악의 시나리오-모든 것이 잘못되었다고 가정하면 (b)
• 실제 추측-아마도 당신이 생각할 것 (c)

그러면 당신의 추정치는 (a + b + 2c) / 4입니다

• 아니요, 정확하지 않습니다. 더 나은 추정 방법이 있지만이 방법은 빠르고 이해하기 쉽고 최악의 경우를 고려함으로써 낙관론을 완화합니다.
• 예, 코드에 익숙하지 않으며 관리자가 코드를 조사 할 때마다 오랜 시간을 소비하지 않고 견고하고 정확한 평가를하기에는 너무 예측할 수 없다고 관리자에게 설명해야합니다. 며칠이 더 걸릴지 확실하게 추정하려면 n 일이 필요하다고 가정하십시오. "JuniorDev"인 경우 합리적인 관리자에게 허용됩니다.
• 또한 최상의 경우, 최악의 경우 및 가능한 경우를 기준으로 추정치의 평균을 내고 관리자에게 오류 막대를 제공하는 수치를 제공해야합니다.
• 견적에 대해 협상하지 마십시오-관리자가 모든 견적에 대해 최상의 사례를 사용하려고 시도하는 경우 (그들은 바보입니다.하지만 나는 그런 식으로 만났습니다) 마감 시간을 맞추려고 노력하는 사람들을 괴롭 히거나 동기를 부여합니다. 때때로 실망 할 것입니다. 추정치에 대한 이론적 근거 (최고의 경우, 최악의 경우 및 가능한 경우)를 계속 설명하고 가중 평균에 가까워 지므로 괜찮을 것입니다. 또한 자신의 목적을 위해 예상치 스프레드 시트를 유지하고 완료되면 실제 값을 추가하십시오. 그러면 견적을 조정하는 방법에 대한 더 나은 아이디어가 제공됩니다.

편집하다:

내가 대답했을 때의 가정 :

1. OP는 주니어 개발자입니다 (선택한 사용자 이름을 기반으로 함). 따라서 어떠한 조언도 개발 환경의 성숙도에 따라보다 정교한 추정을 수행 할 수있을 것으로 예상되는 프로젝트 관리자 또는 팀장의 관점에서는 아닙니다.
2. 프로젝트 관리자는 제공하는 데 몇 달이 걸리는 상당히 많은 작업으로 구성된 프로젝트 계획을 만들었습니다.
3. OP는 프로젝트 계획에 참여하고 진행 상황을 추적하기 위해 합리적으로 정확한 숫자 (확률 곡선이 아님)를 원하는 프로젝트 관리자가 할당 한 작업에 대한 많은 추정치를 제공하도록 요청 받고 있습니다.
4. OP는 각 추정치를 생성하는 데 몇 주가 걸리지 않으며 지나치게 낙관적 인 추정치를 제공하여 화상을 입었고, 특히 코드가 비열한 경우를 제외하고는 공중에 손가락을 대고 "2 주"라고 말하는 것보다 더 정확한 방법을 원합니다. 이상".

이 경우 3 점 가중 평균이 잘 작동합니다. 비 기술적으로 빠르고 이해할 수 있으며 몇 가지 추정치 이상이 정확도에 근접한 것으로 평균화되어야합니다. 특히 OP가 견적 및 실제 기록을 유지하는 것에 대한 조언을받는 경우. 실제 "가장 큰 사례"와 "최상의 사례"가 어떻게 보이는지 알면 실제 예상치를 미래 추정치에 제공하고 최악의 경우가 생각보다 나쁜 경우 프로젝트 관리자의 추정치를 조정할 수도 있습니다.

효과적인 예제를 보자.

• 가장 좋은 경우는, 가장 빠른 경험을 통해 일주일에 시작하는 것이 매우 간단했습니다 (5 일).
• 최악의 경우, 경험상 어디에서나 링크가 있었고 6 주 (30 일)가 걸리는 시간이있었습니다.
• 실제 견적, 아마도 2 주 (10 일)가 걸릴 것입니다

5 + 30 + 2x10 = 55

55/4 = 13.75는 PM에게 말하는 것입니다. 아마도 14 일로 반올림 할 수도 있습니다. 시간이 지남에 따라 (예 : 10 가지 작업) 평균을 내야합니다.

공식을 조정하는 것을 두려워하지 마십시오. 작업의 절반이 악몽으로 끝나고 10 % 만 쉬울 수 있습니다. 그래서 당신은 estmate를 a / 10 + b / 2 + 2c / 5로 만듭니다. 당신의 경험으로부터 배우십시오.

PM의 품질에 대해서는 가정하지 않습니다. 나쁜 PM은 프로젝트 보드에 짧은 견적을 제공하여 승인을 얻은 다음 프로젝트 팀을 괴롭 히고 자신이 저지른 비현실적인 마감일에이를 것입니다. 유일한 방어책은 기록을 유지하여 추정치를 제공하고 가까이 다가오는 것을 볼 수 있습니다.

이것은 준 민첩한 접근 방식을 도입하기에 좋은 순간입니다. 시간 / 일로 추정하는 대신 피보나치 유형 척도를 할당하고 각 작업의 크기에 따라 값을 지정했습니다.

• 0-순간
• 0.5-빠른 승리
• 1-간단한 변화
• 2-몇 가지 간단한 변경
• 3-더 도전적인
• 5-에 대한 약간의 생각이 필요합니다
• 8-상당한 양의 작업
• 13-아마도 분해해야 할 큰 작업 덩어리
• 20-분명히 분해 해야하는 거대한 작업 덩어리

그런 다음 이와 같은 많은 작업을 예상하면 작업을 수행합니다. 민첩한 환경에서 1 주일 동안 달성 한 점수의 척도 인 '속도'를 개발합니다. 몇 주 동안 테스트 및 학습을 완료 한 후 (이 과정의 일부로 관리자에게 판매 할 수 있습니다- "몇 주 동안 테스트를 거쳐 예상 프로세스를 이해하는 법을 배우게됩니다") 매주 얼마나 많은 포인트를 얻을 수 있는지에 대한 자신감이 높아져서 포인트 견적을 더 쉽게 시간에 맞게 변환 할 수 있습니다.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

그것은 의식을 포함하지 않을 것이기 때문에 진정으로 민첩하지는 않지만 OP가 그가 스스로하고 있다는 아이디어를 얻습니다. 이 접근법이 좀 더 자신감을 가질 수 있기를 바랍니다.

가장 먼저해야 할 일은 지금 어떤 일을하는 데 걸리는 시간에 대한 데이터 수집을 시작하는 것입니다. 팀 성과에 대한 데이터가 많을수록 좋습니다. 그것은 온 보드가 될 것이지만 지금은 그것에 대해 걱정하지 마십시오. 그것은 진실이며 당신의 상사 현실을 보여줘야합니다.

그런 다음 몇 권의 책을 사러 갈 것입니다.

1. 소프트웨어 추정 : Steve McConnell의 검은 예술의 미스터리
2. Michael Feathers의 레거시 코드로 효과적으로 작업

McConnell의 책은 데이터 수집을 시작한 다음 더 정확한 추정값을 얻는 방법을 설명합니다. 항상 3 포인트 견적을 제공하십시오! 항상. 코드 품질이 좋지 않을 경우 예상치를 떨어 뜨리는 방법에 대해 설명하는이 책의 일부를 강조하십시오. 상사에게 보여주세요.

회사에 정확한 견적이 중요하다면 Feather 's book에서 배우고있는 것들을 적용해야한다고 설명하십시오. 빠르고 매끄럽고 예측 가능하게 진행하려면 코드 리팩토링을 시작하여 테스트 하네스로 가져와야합니다. 나는 네가 옳았다. 무엇을 깨뜨릴 수 있을지 모르기 때문에 개발 시간은 완전히 예측할 수 없습니다. 테스트 하네스로 가져옵니다. 이러한 테스트를 실행하는 CI 서버도 아프지 않았습니다.

마지막으로, 상사에게 상황이 여전히 예측할 수 없을 것이라고 설명하십시오. 아마 몇 년 이겠지만, 그 개발은 매일 쉬워지고 더 많은 데이터를 가지고 코드가 좋아질수록 견적이 더 정확해질 것입니다. 이것은 회사를위한 장기 투자입니다. 나는 이것을 최근에 겪었고, 거의 예측 가능해지기까지 거의 2 년이 걸렸습니다.

나는 추정보다 코드 개선에 대해 더 많이 이야기했지만, 사실은 기존 코드베이스를 길들이기 전까지는 추정치가 커질 것이라는 것이 어려운 사실입니다. 그 동안 역사적인 성능을 사용하여 시간이 얼마나 걸리는지 측정합니다. 시간이 지남에 따라 추정치의 사양에 맞게 코드를 이미 얻었는지 여부를 고려해야합니다.

이제 상사는 새 아키텍처에서 기능 X를 작성하는 데 얼마나 오래 걸 렸는지 예상 할 수 있습니다. 그러나 나는 현실적인 평가를 내리는 데 어려움을 겪고 있습니다. 종종 위에서 언급 한 이유로 인해 과업을 과소 평가하고 제 시간에 끝내지 못해 자신을 부끄럽게하는 경우가 종종 있습니다.

당신은 아마 하나의 견적 을 제출하는 상자에서 생각하고 있습니다. 레거시 코드로 작업해야하며보다 공식적인 추정을 할 때 일반적으로 2 ~ 3 개를 만듭니다 .

1. 기본 견적-파기 위해 약간의 시간을 소비해야하지만 아키텍처가 원하는 변경을 허용한다고 가정
2. Angelic Estimate-모든 것이 투명하고 찾기 쉬운 것으로 가정하고 약간만 변경하면됩니다 (이것은 때때로 나가는 것입니다 ... 특히 특정 코드베이스에 악마 만 있음을 알고있는 경우)
3. Abyssal Estimate-레거시 코드의 기본 구조가 요청 된 기능과 호환되지 않으며 일을 수행하기 위해 주요 리팩토링을 수행한다고 가정합니다.

세 가지 추정치는 모두 그 기능 자체가 얼마나 힘든지, 일반적인 코드베이스에 대한 경험과 변경에 대한 내 감정을 고려합니다 (내가 찾은 것은 매우 정확할 수 있습니다)

이러한 추정치가 나온 후에는 관리자 가 우리가 다루고있는 것으로 보이는 최신 상태를 유지 합니다. 그것이 우리가 심연의 특징을보고있는 것으로 판명되면, 우리는 그것을 희생해야 할 수도 있습니다. 상사가 주어진 레거시 코드 덩어리에 대한 심연의 특징이 있음을 받아 들일 수 없다면 행운이 있기를 바랍니다. 매우 어렵고 실망스러운 삶을 누릴 수 있기를 바랍니다.

이런 종류의 문제에 직면했을 때, 나는 견적에 범위를 부여하는 데 의존했습니다. 나는 상사들에게 "이 코드베이스에서 커프스런 추정을하기가 어렵다. 당신이 그것을 요구한다면, 그것은 매우 넓은 추정치가 될 것이다." "3 일 ~ 3 년"을 추정치로 한 번 제공했습니다. 말할 것도없이 인기있는 견적은 아니지만 내가 준 것입니다.

이것의 핵심은 작업이 진행됨에 따라 견적을 업데이트하겠다는 계약입니다. "XYZ 구현, 얼마나 오래 걸립니까?" 내 대답은 "하루에서 4 개월 사이 일 수 있습니다. 그러나 실제로 몇 시간 동안 코드를 살펴보면 해당 창에서 불확실성을 줄일 수 있습니다." 그런 다음 코드를 살펴보고 "2-4 주"로 돌아옵니다. 그것은 여전히 ​​이상적인 창은 아니지만 최소한 관리 할 수있는 것입니다.

이것에 대한 몇 가지 열쇠가 있습니다 :

• 당신이 있기 때문에 이러한 추정이 더 나은 대화로 취급하는 상사 설득 할 작업은 당신이 작업하는 동안 어떻게 생겼는지에 대한 자세한 내용을. 이것은 상사가 그들이 단 한 번의 견적을 요청했을 때 가지고 있지 않은 정보를 가질 기회입니다.
• 어떤 거래 코드 개발 속도를 앞당기 고 견적을 향상시키는 지에 대한 옵션을 제공하십시오. 그들에게 돌릴 수있는 여분의 손잡이를주십시오. 때로는 상사가 작업을 완료해야한다는 것을 알고 때로는 야구장 견적 만 필요합니다. 다른 경우에는 작업의 장단점을 실행하고 있으며 견적을 수정하는 기능이 유용합니다.
• 가능하면 시너지 보너스도 제공합니다. 많은 작업에 도움이되는 아키텍처 개선이 종종 있습니다. "1-2 개월이 걸리지 만 업그레이드 X를 사용하면 2 주가 걸릴 것"인 10 개의 작업이 모두있는 경우 업그레이드 X에 걸리는 20 주를 판매하는 것이 더 쉽습니다.

내가 갈 때 업데이트되는 범위를받는 데 불편한 보스가있는 경우 단일 번호와 방법론을 제공합니다. 저의 방법론은 제가 젊은 개발자라고했던 경험 법칙 과 Hofstader의 법칙의 조합 입니다.

작업에 걸리는 시간을 추정 한 다음 그 수를 4 배로하여 추정값으로 제공하십시오.

과

Hofstadter의 법칙 : "Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다."

현명한 것은 실제로 코드에 들어가서 모든 브랜치를 기록하고 다른 함수를 호출 한 다음 시간 비용을 추정하는 것처럼 보일 수 있습니다. 그러나 이전 코드를 문서화하는 것과 실제로 새 버전을 작성하는 것 사이에는 약간의 차이가 있습니다.

이것이 귀하의 문제에 대한 해결책입니다. 요구 사항이없는 경우 추정 할 수 없습니다. 상사에게 코딩을 시작하기 전에이 작업을 수행해야한다고 말합니다. 몇 가지 기능과 모듈을 사용한 후에는 모두 일관성있게 코딩 된 것을 발견 할 수 있으므로 (이 경우에는 잘못됨) 향후 추정치를 결정할 기준이 있습니다. 코딩이 나빠질 경우 예상치를 조정하십시오.

귀하의 상사가 견적을 원한다는 것을 알고 있지만이 정보가 어떻게 사용되는지 모르면 귀하의 견적이 얼마나 정확한지 알 수 없습니다. 그와 대화하고 알아보십시오. 그가 상사에게 줄 숫자가 필요하다면, 추정치를 약간 늘리고 숫자를 제공 할 수 있습니다. 이 작업이 완료 될 때까지 코드 지불을 기다리는 고객의 경우 마감일이 큰 수익을 창출 할 수 있는지 확인하십시오.

이와 같은 상황에서 나는 좋은 추정을 할 수 있다고 생각하지 않습니다. 기본적인 문제는 종종 그것을하는 것의 큰 부분이 필요한 것을 정확히 알아내는 것입니다.

나는 그것이 수반하는 것으로 보이는 것에 기초하여 견적을 제공함으로써 놀라운 사례를 처리하지만 놀랍게도주의를 기울입니다. 레거시 코드 방식을 많이 다루지 않아도 입력을 처리하는 데 약간의 놀람이있었습니다. 몇 시간이 몇 주로 바뀌고 한 번은 이것이 불가능하다는 것을 알았습니다. 상당한 파기 나는 특정 경우에 충분한 데이터가 없다는 것을 알았습니다. 다시 그리기 보드로 돌아갔습니다.) 다행히 상사는 내가 그러한 추정을 할 때 이해합니다.

글쎄, 추정은 일부 사람들이 잘 배우지 않는 기술입니다. 좋은 평가를 내릴 수는 없지만 개발자로 쓸모가 없습니다. 아마도 팀 동료 나 경영진이 그 차이를 메울 것입니다. 나는 그것에 끔찍하다, 아직도 대부분의 팀은 나와 함께 일하는 것을 좋아했다. 침착하게 팀을 구성하고 리팩토링을 계속하십시오.

기술 부채는 당신에게 큰 어려움을 안겨주지만, 팀 정신이나 경영진에 변화가 없다면 부채를 낳은 회사 / 팀은 계속해서 부채를 낼 것입니다. 코드는 사회적 문제를 반영한 ​​것이므로 실제 문제에 집중하십시오.

우리는 재개발 프로젝트의 기능을 추정하는 휴리스틱을 사용 : 우리는 그것없이 그린 필드 프로젝트에서 해당 기능을 구현했을 시간을 추정 아무것도 이미 구현. 그런 다음이 추정값에 2를 곱하여 이미 존재하는 잔해물을 처리합니다.

이 계수는 커플 링 양과 전체 코드 크기에 따라 달라 지지만이 방법으로 일부 기능을 수행하면 실제 증거를 기반으로 해당 계수를 보간 할 수 있습니다.

나는 당신이 당신의 상사와 함께 앉아서 눈을 직접 바라보고 말해야한다고 생각합니다.

'보스 들어요! 우리는 여기서 리팩토링하고 있습니다. 제공 할 새로운 기능이 없으며 해당 기능을 기다리는 고객도 없습니다. 마감일이 없어야합니다. 시간이 오래 걸리기 때문에 우리가해야하는지 아닌지를 결정해야합니다. '

포인팅과 같은 확고한 단정 한 한순간을 사용하고 의자에 앉으십시오.

또는 당신은 그를 행복하게하기 위해 숫자를 만들 수도 있습니다. 그러나 당신이 작업을 반쯤 끝낼 때까지, 당신의 추정치가 꽤 부정확해질 때까지 직면하십시오.