리팩토링의 잠재적 가치를 측정하는 방법

기술 부채가있는 오래된 대규모 프로젝트에서 리팩토링 코드의 이점을 어떻게 안정적으로 추정하거나 측정 할 수 있습니까?

예를 들어, 이전 언어로 작성된 소프트웨어 스택 솔루션 내에 일부 구성 요소가 있고 최신 언어로 작성된 일부 구성 요소가 있다고 가정하십시오. 개발 팀은 새로운 기능과 버그 수정을이 솔루션에 지속적으로 추가하고 있습니다.

개발자는 기존의 오래된 언어 구성 요소를 새 버전으로 교체하는 것이 '좋은 일'이라고 제안하지만이 작업으로 추가 기능이 추가되지 않으며 x dev-days 비용이 소요됩니다.

영업 사원이 '새로운 기능'을 추가 할 것을 제안합니다. 회사는 공식을 사용하여 제안의 가치를 측정합니다. 즉. 그것은 x dev-days 일의 비용으로 t 년 동안 회사 F 백만 파운드를 벌 것입니다

회사는 어떻게 리팩토링 제안에 의미있는 비용을 지불 할 수 있습니까? 어떤 상황에서 회사에 가장 수익성이 높은 옵션이 될 수 있습니까?

그것은 x dev-days 일의 비용으로 t 년 동안 회사 F 백만 파운드를 벌 것입니다

유지 보수 비용, 지원 비용, 판매 / 마케팅 비용을 무시하고 시장에서 기능이 어떻게 채택 될 것인지에 대해 많은 가정을합니다.

그러나 무엇이든; 당신의 질문은 당신이 찾고있는 것에 대해 충분히 분명합니다.

리팩토링을위한 비즈니스 사례를 어떻게 만들 수 있습니까?

가장 중요한 것은 시간이 돈과 같다는 것입니다. "5 명의 개발자 2 주 = 80 시간 * 5 명의 개발자 * $ 50 / hr-> $ 20,000"으로 바로 갈 수 있으며 이는 비즈니스 사람들에게 적합합니다. 현명한 비즈니스 사람들은이 5 명의 개발자가 어느 쪽이든 지불을 받는다는 점에 주목할 것입니다. 당신은 20,000 달러를 소비 / 절약하지 않고-2 만 달러를 가장 수익성이 높은 방식으로 사용하고 있습니다. 어쨌든, 목록과 함께.

• 효율성 -아마도 VB6보다 C #으로 더 많은 작업을 수행 할 수 있습니다. 더 나은 툴링, 더 나은 라이브러리 등 최신 기술은 이전 기술보다 더 나은 경향이 있습니다. 더 적은 시간에 일을 할 수 있다면 회사 비용을 절약 할 수 있습니다.
• 오버 헤드 -코딩은 소프트웨어의 유일한 비용이 아닙니다. Windows 2020이 나올 때 어떤 일이 발생하는지 고려하십시오. VB6 앱을 작동시키는 데 얼마나 많은 시간과 노력을 듭니까? C # 앱보다 시간과 노력이 얼마나 더 많이 있습니까? 그것은 회사 돈을 절약하고 있습니다.
• 품질 -아마도 VB6보다 C #에서 더 높은 품질로 작업하거나 더 깔끔한 아키텍처 또는 리팩토링 대상이 무엇이든 할 수 있습니다. 품질이 높을수록 버그가 줄어 듭니다. 버그가 적다는 것은 버그를 수정하는 데 드는 비용, 문제를 해결하는 데 필요한 고객 지원 비용, 품질 문제로 인한 고객 손실 감소, 품질에 대한 명성으로 인한 매출 증대 등 모든 비용을 의미합니다.
• HR 저축 -사실을 직시하자 : 아무도 그 뻔뻔스런 VB6 앱으로 작업하기를 원하지 않습니다. 그것은 더 많은 사람들이 회사를 떠나서 그들을 대체하기 위해 시간과 돈을 소비한다는 것을 의미합니다. 이는 신입 사원을 고용하는 데 더 많은 시간과 비용이 소요됨을 의미합니다. 무엇보다도, 그것은 당신이 VB6 앱을 사용하여 커리어 자살에 전념하는 훌륭한 개발자를 보유하고 있음을 의미합니다. 그 개발자들은 품질 문제의 죽음의 소용돌이를 서두르고 있습니다. 이직률과 고용 시간을 줄이면 회사 비용이 절약됩니다. 만족스럽고 냉담한 개발자를 멀리하면 회사가 절약됩니다.
• 사기 -마찬가지로, 이미 존재하는 프로그래머는 VB6에서 작업하는 것을 싫어합니다. 그들은 그렇게 할 것이고, 심지어 잘 할 수도 있습니다. 그러나 짜증나. 어쩌면 모든 사람을위한 것이 아니라 확실히 일부를위한 것일 수도 있습니다. 이는 동기를 되찾기 위해 웹을 탐색하는 데 더 많은 시간을 소비 함을 의미합니다. 더 긴 점심을 의미합니다. 프로그래머가 짜증나는 작업에서 복구하는 데 시간이 오래 걸리는 동안 작업이 줄어드는 것을 의미합니다.
• 기능 -기술 기반 리 팩터에는 적용이 적지 만 아키텍처 종류의 리 팩터에 적용됩니다. 특정 코드 문제로 인해 엄청난 기능을 제공하는 멋진 기능 X를 제공 할 수 없습니다. 아마 당신은 확장 할 수 없습니다. 아마도 멋진 정보를 얻기 위해 데이터를 얻지 못할 수도 있습니다. 어쩌면 코드는 쥐의 둥지일지도 모르지만 실제로 작업하는 것은 엄청나게 어렵습니다. 도대체 무엇이. 때로는 그 시점에 있고 때로는 그 시점으로 직진하고 있습니다. 비즈니스 말하기로 번역하기는 어렵지만 "이 문제로 인해 X, Y 및 Z 기회를 활용할 수 없게됩니다"라는 강력한 힘을 얻을 수 있습니다.

결국, "이것은 우리가 일을 더 잘하는 데 도움이 될 것입니다. 우리가 일을 더 잘하면 더 많은 돈을 벌 수 있습니다."

스스로 물어봐야 할 질문은 영업 사원이이 기능을 사용하여 개발자의 작업 시간 x 일 이 소요된다는 것을 어떻게 알 수 있는지 입니다 . 수년간의 전문적인 경험을 가진 훌륭한 프로젝트 관리자조차도 종종이를 알 수 없기 때문에 영업 담당자가 제공 한 이러한 데이터는 매우 투기적인 것처럼 보입니다 .

내 경험에 따르면, 영업 사원은 일반적으로 견적을 내리지 않지만 경영진 이나 고객에게 너무 많은 금액을 추측 합니다. 경영진이 50 남자 주일의 노동을 지불 할 준비가되어 있지만 75 남자 주를 절대적으로 거부한다면 이 기능은 재협상 (실제 추정에 의문의 여지가없는)을 55 man-week까지 준비하는 동안 70 man-weeks 가 소요됩니다.

• 한편, 당신은 예상치 같은 것을 말하는 IT 전문가에 의해 수행을 :

  이 특정 감사에 따르면 최신 기술을 사용하는 비슷한 규모의 유사한 프로젝트와 비교할 때 구식 기술을 사용하여 하루 8 천 달러를 낭비하고 있습니다. 또한 전체 코드베이스를 마이그레이션하는 데 50-80 주가 소요될 것으로 보입니다. 이 기간 동안 새로운 기능이 릴리스되지 않았습니다. 또한 특정 구성 요소를 마이그레이션하면 20-30 시간의 추가 인력이 발생할 수 있습니다.

• 다른 한편으로, 당신은 그들이 확신해야 할 사람과 협상 할 때 그들의 레버리지에 기초하여, 판매원에 의해 추측 한 것이 있습니다 .

그것은 당신이 회사에 얼마나 영향력이 있는지에 관한 것입니다. 의사 소통이 핵심이며, 영업 담당자가 관리 (또는 고객)에게 기능의 이점을 설명 할 때 일반적으로 IT 전문가를이기는 곳입니다.

과거에 추정치가 정확하다면 평판과 영향력을 얻습니다. 추정치가 항상 틀렸다면 경영진이 제안을 무시할 것입니다.

추정에 관해서는 고려해야 할 매개 변수가 많기 때문에 여기서 가치있는 것을 만드는 것은 극히 어렵습니다. 다른 것들 중에서 :

• C # 팀이 VB6에 비해 얼마나 능숙한 지 실제로 알고 있습니까? 실제 측정을 기준으로합니까 아니면 추측 만합니까?

• 이 팀이 C #으로 대규모 프로젝트를 개발 했습니까? 그들은 사용해야하는 도구 (IDE, 디버거, 프로파일 러 등)를 알고 있습니까? 추가 라이센스가 필요합니까 (Microsoft의 경우 컴퓨터 당 수천 달러를 의미 함)?

• 현재 프로젝트가 완전히 명확하고 마이그레이션 할 때 놀라움이 없음을 보장 할 수 있습니까? 모든 것을 , 모든 기능 을 다시 작성하는 것이 간단 합니까, 아니면 놀라움이 있습니까?

• C #을 지원하는 인프라가 있습니까? 지속적인 통합은 어떻습니까? 빌드 서버는 어떻습니까? 스타일 가이드? 정적 체커?

• 프로덕션 환경에서 서버 (웹 응용 프로그램 인 경우) 또는 고객 PC (데스크톱 응용 프로그램 인 경우)는 사용할 것으로 예상되는 .NET Framework 버전을 실행할 수 있습니까?

그러나 가장 중요한 것은 왜 모든 것을 다시 쓰려고 하는지 아는 것입니다. 다시 쓰기를 통해 해결하려는 문제는 무엇입니까 ? 생산성 손실? 어떻게 측정합니까? 이러한 생산성 손실을 경영진에게 어떻게 보여줍니까?

VB6으로 인해 하루 8 천 달러를 낭비하고 있음을 보여준 후에 (C #으로 마이그레이션하면 매일 8 천 달러를 절약 할 수 있음) 모든 새로운 기능 개발 및 유지의 이점을 어떻게 설명 할 수 있습니까? 완전한 재 작성에 초점을 맞추고 있습니까? 새로운 기능을 제공하면서 작은 청크로 구성 요소를 하나씩 마이그레이션 하는 점진적 재 작성 과 비교하여 어떤 이점이 있습니까?

먼저, 판매 중심 기능 요청과 마찬가지로 리팩토링에 대한 개발 비용을 추정해야합니다.

큰 일이라면 정확성을 얻는 것이 까다로울 수 있지만 두 가지 기술을 충분히 경험 한 사람이 있다고 가정하면 가능합니다.

둘째, 리팩토링하지 않는 비용을 추정해야합니다. 당신이 나를 위해 견적을하고 있다면, 나는 어느 정도의 메트릭을 기대할 것입니다. 예를 들어 VB 코드와 C # 코드의 평균 개발 비용의 차이는 1/4 이상입니다. 또는 그런 것들도 있습니다. 당신이 이것을 얼마나 정확하게 추적 하느냐에 달려있을 것입니다.

이 2 개의 숫자를 사용하면 리팩토링이 제공 할 회수 기간, 즉 리팩토링이 순 비용에서 순이익으로 전환되는 시점을 추정 할 수 있습니다.

주어진 결과가 얼마나 설득력이 있는지에 대해서만 추측 할 수 있습니다. 그러나 1 년 미만인 경우 아마도 2 년 이상이 훨씬 더 길어질 수 있습니다.

또한 사례를 작성하는 데 도움이되도록 다른 측정 기준을 추가하는 것이 좋습니다. 내가 과거에 사용했던 것 중 하나는 출구 인터뷰에서 기술을 드라이버로 인용했는지를 보는 것입니다. 그렇다면 리팩토링이 직원을 유지한다고 주장 할 수 있습니다 (임원 및 교육 비용이 비싸다).

분명히, 당신은 증거를지지하지 않고 이러한 것들을 논쟁 할 수 있지만, 그것이 사건의 영향에 큰 영향을 줄 수 있다는 것을 알게되었습니다.

리팩토링의 가치는 여러 가지 방법으로 나타납니다.

나중에 다른 변경을 수행하는 데 도움이되므로 해당 기능이 수행 된 X 일은 이제 2 / 3X 일이 소요됩니다. 민첩한 용어를 사용하려면 속도가 증가합니다.

VB6 경험이있는 개발자를 더 이상 유지 관리 할 필요가없고 C # 경험이있는 개발자 만 유지 보수 할 필요가 있으므로 명시 적 변경 사항은 시간이 지남에 따라 도움이됩니다.

또한 직원 유지 및 채용과 같은 유형이 다른 다른 방법으로도 도움이됩니다. C # 및 VB6을 수행하는 작업이 C # 만 수행하는 작업보다 매력적입니까? 좋은 코드 기반이나 형편없는 코드 작업을 수행하거나 직업을 유지할 가능성이 어느 정도 있습니까?

다른 답변이 놓친 요점은 리팩토링하지 않은 수익 손실에 대해 리팩토링 비용을 측정해야한다는 것입니다.

코드 변경을위한 리팩토링은 시간 낭비입니다. 테이블에 가치를 가져와야합니다. 이 맥락에서 문제 클래스를 리팩토링하는 데 1 시간을 소비하는 것이 아니라 예제에서 사용한 다른 CLR 언어로 변경하는 것과 같은 주요 리팩토링을하는 것을 의미합니다.

• 우리가하고있는 일을 계속하면 무언가를 놓치고 있습니까? 우리가 가치를 깨닫지 못하게하는 구식의 오래된 디자인이 있습니까? 예를 들어, 기능을 추가하려는 경우 구현하는 데 100 시간, 리팩토링하는 데 50 시간, 새로운 디자인에 대해 구현하는 데 25 시간이 걸리는 것이 너무 어려울까요?

• 기존 코드 는 비용이 많이 드는 기술 부채 를 가지고 있습니까? 이 엉뚱한 오래된 코드가 버그의 근원입니까? 문제 때문에 문제를 해결하기 위해 무료로 일하게됩니까? 수익성있는 청구 가능 시간을 무료로 제공하는 것을 좋아하는 사람은 없습니다.

• 리팩토링 비용이 리팩토링하지 않는 비용과 같거나 적습니까?

• 소규모의 록 스타 팀이 가장 큰 문제를 일으키는 코드를 리팩터링하여 비용을 상각 할 수 있습니까? 릴리스간에 리 팩터를 분산시킬 수 있습니까? 사방에 작은 비 효율성이 있습니다. 우리는이 추가 작업에 대해 이야기하기 위해 "격차를 메울 수 있습니까?"

리팩토링 시스템의 장점

리팩토링에 대한 비즈니스 사례는 비즈니스 수행의 이점과 수행하지 않는 것의 비즈니스 이익을 비교하여 작성합니다. 현재 실제 비용의 감소 또는 미래의 실제 현금 유입의 증가를 의미합니다.

리팩토링의 영향을받는 주요 예산 항목은 다음과 같습니다.

• 유지 보수 비용-현재 시스템이 깨지기 쉬운 스파게티 더미이고 실제로 작은 버그 (개발 및 운영 모두)를 수정하는 데 많은 시간이 소요되는 경우 실제로 관찰 할 수 있습니다. "적절하게 재 설계된"시스템의 경우 유지 보수가 줄어 듭니다. 연간 순수 유지 보수 비용이 무엇인지, 그리고 재 작성 후에 실제로 어떻게 변할 수 있는지 살펴보십시오.

• 새로운 기능 추가 비용-다시 말하지만, 현재 시스템 설계 및 구조로 인해 새로운 기능을 작성하는 데 부당하게 시간이 걸리는 경우 다시 작성하면 비용을 절약 할 수 있습니다. 새로운 기능에 대한 계획된 예산을 살펴 보되 현실적이 되십시오. 만약 50 %의 개선이있을 것이라고 생각한다면 실제로는 이전에 2 * x man-months가 소요되었던 x man-months의 기능을 실제로 개발할 것으로 기대합니다. 그러한 약속을 지키기가 어려울 수 있습니다.

• 소프트웨어 품질이 판매에 미치는 영향-현재 시스템으로 인해 적절한 유지 관리 노력에도 불구하고 충돌이나 다운 타임과 같은 고객이 볼 수있는 문제가 자주 발생하는 경우 다시 쓰기가 해결책이 될 수 있습니다. 경우 이것은 큰 문제입니다, 다음 같은 판매 사람들은 '더 안정적인 제품'이라는 '기능'의 가치를 정량화 할 수 있습니다.

위의 세 가지 포인트가 예상되는 재 작성 비용에 도달하지 못한 경우 (그리고 그 이상 : 비 기능에 x dev 일을 소비하는 기회 비용이 x dev의 순수 비용보다 큰 해당 기능의 가치와 동일 함) -일) 그렇다면 그게 다가 될 것 같습니다-예상 절감액이 재 작성을 정당화하지는 않습니다.

또한 로드맵에 새로운 기능을 '제공 할 수있는만큼'필요가없는 경우 절감 효과는 '10 명에게 필요한 모든 작업을 수행하는 데 사용되지만 재 작성 후 '6 명만 똑같이 할 수있을 것 입니다. ' 개발자보다 더 많은 개발 프로젝트를 "판매"할 수 있다면 효율성을 개선하면 더 많은 것을 개발할 수 있지만 현재 자원을 보유한 비즈니스가 이미 추가 가치를 가져 오는 모든 것을 개발할 수 있다면 유일한 경제적 이점 더 적은 사람을 지불하거나 더 싼 사람을 가질 수 있습니다.

리팩토링의 가치는 다음과 같이 측정 할 수 있습니다. 현재 새로운 기능 x의 비용은 2 주에 5 명입니다. 이전 컴포넌트를 리팩토링하면 새로운 기능의 비용이 약 20 % 감소합니다. 따라서 새로운 기능 x는 2 주에 걸쳐 4 명의 개발자에게만 비용이 청구됩니다.

리팩토링은 향후 개발 비용을 절감하기위한 투자입니다. 리팩토링에 대해 그 주장을 할 수 없다면, 아마도 비즈니스 사례가 아닐 것입니다.