개발자가 Excel 매크로로 수행 한 작업량 추정을 수용해야합니까?

새 프로젝트에서 친구는 개발자가 아닌 개발자 관리자가 작성한 Excel 매크로로 계산에 필요한 시간을 계산하는 테스트를 작성해야했습니다.

그러한 상황에서 개발자는 계산 된 시간에 테스트를 작성하고 실행해야 할 책임을 받아 들여야합니까? 이 테스트 결과는 신뢰할 수 있습니까?

정보를 얻기 위해 친구는 자신이하지 않은 추정에 대해 책임을지지 않고 다른 프로젝트를 성공적으로 수행하도록 요청했으며 경험이 부족한 학교 밖 예스맨으로 대체되었습니다.

개발자에게 얼마나 현명하게 보이는지, 그리고 어떤 데이터 / 논리에 기초하는지에 달려 있습니다. (그들은 수도 얼마나 많은 시간을하는 것이 요구되었다에 대해 몇 년 동안 수집 한 통계 자료를 기반으로 -이 개발자 자신 및 / 또는 다른 사람에 의해 - 과거에 유사한 작업을 해결하기 위해 ... 또는 그들이 할 수 완전히 그의 매니저의 기반으로 - 정확하거나 잘못-가정.)

이상적으로는 관리자와 다른 사람이 추정 한 업무에 합당하게 책임을지고 책임을 질 수 없다고 논의해야합니다.

추정치에 대한 확고한 거부는 실제로 그의 즉각적인 교체로 이어질 수 있으므로, 더 부드러운 접근 방식을 사용하고 가능한 경우 직접 대면을 피하는 것이 좋습니다.

아마도 매크로가 일종의 입력 데이터에서 작동하는 것 같습니다. 난수 생성기가 아닙니다. 따라서 귀하의 질문에 대답하기 위해 입력 데이터가 무엇인지, 매크로가 무엇을하는지 알아야합니다. 이것이 없으면 어떤 대답도 의미가 없습니다.

또는 관련 경험이 부족한 관리자가 산출 한 견적을 수락하는 것에 대한 질문입니까? 이 경우 대답은 '아니오'입니다. 귀하 (또는 친구)는 자신의 견적을 작성하여 관리자에게 제출해야합니다. 두 수치가 일치하지 않으면 최선의 방법을 찾아 내기 위해 함께 노력해야합니다. 적은 수의 테스트를 작성하기로 동의하거나 모두 작성하는 데 시간이 더 걸릴 수 있습니다.

포인트 블랭크 거부는 누구에게도 도움이되지 않으며 만날 수없는 타임 스케일로 작업하는 것도 재미가 없습니다. 솔루션은 전문적인 접근 방식을 취하고 작업을 진행할 수있는 타협에 있습니다.

가장 그렇습니다.

작은 프로그램, 심지어 크고 복잡한 프로그램이라도 프로그래밍 작업에 걸리는 시간을 추정 할 수 없습니다. 그 이유는 소프트웨어 추정에 대한 수학적 한계를 참조하십시오 . 더 길고, 동료 검토 논문 인 소프트웨어 추정에 대한 한도 도 사용할 수 있습니다.

또한 문제의 관리자에 대한 나의 의견을 다시 생각해 볼 것입니다. 과거에 소프트웨어 작업 기간을 추정하기 위해 다른 모든 것이 시도되었지만 과거에 스프레드 시트 매크로가 시도되지 않았다고 생각하는 이유는 무엇입니까?

어!

이것은 거대한 "직업 냄새"입니다. 그것은 놀라운 미세 관리입니다.

직원이 추정치로 직원을 신뢰할 수 없다면 다른 무엇을 신뢰하지 않습니까?

절대 안돼.

관리자가 자신의 Excel 매크로가 정확하게 예측을 예측할 수 있다고 생각하지 않기를 약속합니다. 알고리즘에서 이와 같은 것을 정확하게 예측하기에는 너무 많은 변수가 있다는 잘 알려진 사실이 무엇인지 논쟁조차하지 않습니다. 그가 그러한 알고리즘을 발명했다면 특허를 받아야하고 내 생각에 수백만을 만들어야한다.

여기서 실제로 일어나고있는 일은 관리자가이 추정 된 Excel 매크로를 얇고 가려운 변장으로 사용하여 개발자에게 비현실적인 기대와 과도한 압력을 가하고 있다는 사실을 숨기고 있다는 것입니다.

그는 자신이 BS라는 것을 알고 신경 쓰지 않으며 리소스를 초과 예약하고 모든 "무가치 한"개발자를 영구히 "늦게"만들어서 더 빠르게 일을 처리 할 수있는 변명입니다.

이 관리자는 착취적인 바보처럼 들립니다.

새 프로젝트에서 친구는 개발자가 아닌 개발자 관리자가 작성한 Excel 매크로로 계산에 필요한 시간을 계산하는 테스트를 작성해야했습니다.

있다 매개 변수 추정 모델 소프트웨어 프로젝트를 포함하여 프로젝트의 완료 시간을 추정가. 일반적으로 견적은 프로덕션 코드에 대한 것이지만 테스트 코드를 작성하는 데 걸리는 시간을 추정하기 위해 추정 할 수없는 이유는 알 수 없습니다. 그러나 이러한 추정치는 제공된 데이터만큼만 좋습니다.

사용 된 방법이 유효한 추정 모델이고 데이터가 정확하고 유효하다고 가정하면 개발자가 아닌 관리자가 작성한 Excel 매크로에서 좋은 추정치를 얻을 수없는 이유는 없습니다.

그러한 상황에서 개발자는 계산 된 시간에 테스트를 작성하고 실행해야 할 책임을 받아 들여야합니까?

어떤 상황에서도 맹목적으로 추정해서는 안됩니다. 생성 방법에 관계없이 완벽한 견적은 없습니다. 견적을 검토하고, 잠재적 문제를 식별하고, 그 영향을 평가하고, 필요에 따라 견적을 논의하고 수정하는 것은 엔지니어의 책임입니다.

이 테스트 결과는 신뢰할 수 있습니까?

테스트는 테스트를 디자인하고 구현하는 데 드는 노력만큼이나 좋습니다. 테스터가 품질이 낮은 테스트를 생성하면 테스트를 통해 결함이 발생하여 프로젝트의 이후 단계로 넘어갑니다. 일정 압력으로 인해 품질이 낮은 테스트로 이어질 수 있으므로 적절한 테스트 사례를 설계하고 구현하는 데 시간이 충분하지 않은 경우 테스트가 유용하지 않을 수 있습니다.

두 가지 다른 질문을하는 것 같습니다.

이 테스트 결과는 신뢰할 수 있습니까?

Excel은 우리가 작업하는 다른 도구와 같은 도구이며 계산이 작성된 것이 실제로 알고리즘 결과에 영향을 미치지 않아야합니다. 추정치가 Excel 매크로에서 나온다는 사실은 계산 결과 (예 : 추정치의 유효성)가 유효한지 여부와 관련이 없습니다. 기본 모델에 잘못된 가정이있는 경우 기본 가정이 잘못되어 계산을 수행하는 데 사용하는 것은 중요하지 않습니다.

그러한 상황에서 개발자는 계산 된 시간에 테스트를 작성하고 실행해야 할 책임을 받아 들여야합니까?

개발자가 표시된 시간에 작업을 수행해야하는 요구 사항이 연락처에있는 경우 추정치가 합리적이라면 그와 관련하여 논의 할 수있는 일은 많지 않습니다. 다음 시점으로 연결되는 계산 : 합리적인 시간을 계산하고 개발자가 제공 한 추정치와 비슷한 경우 지정된 타임 라인에 이의를 제기 할 이유가 없습니다. 실제로 임의의 타임 라인이 제공되는 경우와 달리 모듈에서 사용되는 가정에 영향을 줄 수 있으므로 개발자에게 유리할 수 있습니다.

필요한 작업량으로 타임 라인을 실행할 수없는 것으로 보이면 분명히 이러한 우려를 제기하고 관리자와 협력하여보다 현실적인 타임 라인을 확보하려고 노력해야하지만 타임 라인이 실현 가능한 경우 이의 제기를 거부하는 데 어려움을 겪게됩니다.

프로젝트 관리 및 예상 일정과 관련하여 그렇습니다. 그러나 수행 할 수있는 작업의 성격에 따라 크게 달라집니다. 테스트 코드가 작성되는 사용 사례에 대해 새 코드를 작성하는 것보다 단위 테스트 코드를 작성하는 데 필요한 시간 (개발자가 프레임 워크를 이해하고 이전에 작성했다고 가정)에 대해 더 정확한 추정치가 제공 될 수 있습니다. 에 대한.

필기 테스트를 다운 플레이하고 싶지 않지만 프로젝트에 여러 개발자가 작성한 적이 있습니다. 추정치가 이러한 데이터를 기반으로하는 경우 친구가 추정 한 것보다 정확할 수 있습니다. 친구가 프로젝트를 떠났으므로 반대 추정치를 만들거나 예상대로 완료 될 수 있는지 확인하지 않았으므로 알 수 없습니다.

그가해야 할 일은 견적이 얼마나 정확한지 확인하기 위해 한두 번의 테스트를 완료하고 정당한 주장으로 매니저에게 돌아 오는 것입니다. 추정치의 신뢰성 또는 뒤 떨어진 결과에 대한 피드백을 제공 할 수있는 다른 팀원이있을 수 있습니다. 때때로 한 관리자는 모든 사람을 행복하게하기 위해 상사에게 '무언가'를 주어야합니다. 개발자는 이것을 잘못된 보안 감각으로 간주합니다. 개발자가 예상치를 제공하고 일을 완수하려는 의지를 보여 주려는 움직임이 있었다면 경영진은 더 많은 신뢰를 가질 수 있습니다.

내가 추측하는 것은, 만약 그가 더 짧은 시간 안에 시험을 완료 할 수 있다면, 그는 그것에 대해 아무 말도하지 않을 것입니다. 그런 다음 다시는 자신이 믿지 않는 실천에서 자신을 변명하면 높은 수준의 무결성을 나타낼 수 있습니다.

쉽고 짧은 답변 :

추정치가 어디에서 나오는지 상관하지 않습니다.

실제로 신경 쓰는 것은 추정 자체입니다. 그것에 동의하거나 동의하지 않으며, 왜 그리고 얼마 를 추정 할 것인지 설명하십시오 . 그것이 가장 중요합니다.

이론적으로 개발자는 다른 사람이 어떻게 도착했는지에 상관없이 다른 사람의 추정치를 절대 받아들이지 않아야합니다. 한 가지 이유는 관리자가 편한 것보다 더 긴 견적을 제공하면 잠재적 인 일정 문제 또는 수행 할 작업 범위에 대한 오해가 즉시 노출되기 때문입니다.

사람들은 일반적으로 프로그래밍 시간 추정이 프로그래밍 자체보다 훨씬 어렵다는 것을 알고 있으므로 관리자가 Excel 매크로를 작성하여 해당 문제를 해결할 수 있다면 매크로를 작성하여 코드를 작성할 수 있습니다.

이제 실제로 작업을 이해하고 추정치가 합리적으로 보이면 통과하는 방법론에 대한 우려를 간단히 표현한 다음 충족시킬 수 있는지 잠정적으로 동의하는 것이 좋습니다. 나중에 작업이 예상보다 오래 걸리는 경우 가능한 한 빨리 관리자의주의를 환기시켜야합니다. 실제 구현 경험에 따라 정확한 이유를 논의 할 준비를하십시오. 이 시점에서 관리자는 부당한 것이 아니며 기계적으로 생성 된 추정치에 대한 작업을 계속 주장해야합니다.

가장 최신의 소프트웨어 개발 방법 중 하나 는 민첩 하며 잘 알려진 민첩 프레임 워크 중 하나는 스크럼 입니다. 그러나이 방법론에서 개발자 (스크럼 팀)는 작업을 수행하거나 사용자 스토리를 구현하는 데 필요한 시간을 계산해야합니다.

나는 확실히 아니오 라고 말합니다 . 때문에:

1. 개발자가 아닌 관리자는 작업 수행에 필요한 시간을 예측할 수 없습니다
2. 어떤 작업을 수행하는 데 필요한 시간을 추정하려면 Excel에는없는 인간의 지능이 필요합니다
3. 이러한 작업 관행을 수용함으로써 관리자는 추정 시간에 개발자를 점차적으로 대체하는 데 익숙해집니다. 재앙이 발생할 수 있습니다. 관리자가 말하는이 시나리오를 고려하십시오.

온라인으로 자전거를 판매하기위한 새로운 프로젝트를 시작하고 싶습니다. 나는 당신과 존이 그것을 달성하는 데 3 주가 걸린다는 것을 알고 있습니다.