주니어 프로그래머로서의 평가 다루기

나는 두 달 동안 (특정 후배가 아닌 일반 인구를 위해) 작업을 추정하는 회사에서 일한 다음 우리는 작업을 받고 해결하고 두 번의 테스트를 거쳐야합니다. 다소 만났다.

일부 견적은 내가 충족하기가 불가능하기 때문에 나는 스트레스를 넘어서고 있습니다. 나는 여전히 전체 시스템을 알지 못하기 때문에 (아주 실질적이기 때문에) 때로는 절반의 시간이 내가해야 할 일을 찾는 데 소비되는 시간과 끝날 때까지 때로는 견적이 끝나고 여전히 테스트가 진행됩니다. 완료 (및 실수가있는 경우 수정).

두 번째로 비슷한 기능을 처리해야 할 때 훨씬 더 빨리 작동하지만 지금까지는 프로그래밍에 익숙하지 않은 것 같습니다.

막 시작했을 때이 단계를 극복하는 데 도움이 된 일이 있습니까? 때로는 코딩하는 데 시간이 얼마나 걸리지 않아서 때로는 내가하고있는 일에 제대로 집중할 수 없어서 더욱 악화됩니다.

• 관리 경험이 거의없는 많은 개발자는 팀에서 "최상의"개발자의 속도 또는 속도를 사용하여 작업을 예측합니다.

• 속도는 경험에 따라 다릅니다. 선임 개발자는 동일한 문제를 해결하는 데 2 ​​영업일이 걸리면 무언가를 해결하는 데 3 시간이 걸릴 수 있습니다.

• 새로운 일을 할 때 스트레스를 거의 피할 수 없습니다. 몇 달이 지나면 충분한 일을하고 많은 관련 질문을한다고 가정하면 일반적으로 더 좋아집니다.

• 선배들은 당신이 견적에 대해 어떻게 느끼는지 알지 못할 수 있으므로, 그들이 당신에게 무엇을 기대하는지 물어 보는 것이 중요합니다.

내 경험에서 :

• 선임 개발자 또는 관리자는 티셔츠 크기 (XL, L, M, S, XS)로 사용자 스토리 (비즈니스 요구 사항)를 추정 할 수 있어야한다고 생각합니다.

• 사용자 스토리를 더 작은 작업으로 나누고 추정하는 것은 개발자의 임무입니다. 대규모 작업을 수행하는 데 일주일 내내 수석 개발자가 하루가 걸릴 수 있습니다.

• 실제로 작업을 완료하는 데 걸린 시간을 기록하는 것이 매우 중요합니다.

• 훌륭한 프로젝트 관리자 또는 선임 개발자는 지속적으로이 통계를 수집합니다. 생산성이 향상되면 생산성을 인식하고 더 많은 작업을 보내 게됩니다.

이것은 당신의 인생을 덜 스트레스로 만들뿐만 아니라, 부서가 그들의 자원을 효과적으로 관리 할 수있게 해줄 것입니다.

이를 팀장, 프로젝트 관리자 및 / 또는 추정하는 사람과 함께 가져 오십시오. 우리가 아닙니다. 사람들은 일이 모든 사람에게 같은 양의 노력을 기울이지 않는다는 것을 이해하며, 과제가 배정 될 때 추정치를 조정하거나 검토 기간에 대한 두려움을 최소한으로 완화 할 수 있습니다.

이것이 제 의견으로는, 작업을 배정 된 사람들 (리드 / 피어의 의견 / 협력)에 의해 견적이 이루어져야하는 이유입니다. 작업에 실제로 사람들이 소요되는 시간에 대한 더 정확한 추정치를 얻을 수 있습니다.

물론 개발자가 당신에게 도전하기 위해 노력하지 않는 한, 주니어 개발자를 유지할 수 없다는 기대를하는 것보다 더 나쁜 입장을 상상할 수는 없습니다. 추정치에 미치지 못하는 실제 영향이 있습니까?

먼저, 당신이 스스로 추정하는 법을 배워야한다는 것이 중요합니다. 당신이 할 일이 주어지면, 당신이 생각하는 바에 따라 즉시 그 일을 추정 한 다음, 둘 사이의 델타를 찾기 시작하십시오. 나는 초기의 짧은 견적에서 품질이 희생되고 있다고 거의 확신 할 수 있습니다. 그들이 당신이 할 수있는 것보다 더 빨리 아이템을 디자인하고 개발할 것이라고 기대한다면, 문제를 해결하기 위해 누군가와 대화를해야 할 수도 있습니다.

둘째, 품질은 스테이크 소유자, 상사, 지불하기로 결정하는 기능이라는 것을 이해하십시오. 당신이 가진 시간의 요구 사항을 충족시키기 위해 약간의 일을 희생해야 할 수도 있습니다.

어느 쪽이든, 스트레스를 제거하면 항상 나쁜 코드를 작성하는 것보다 기분이 계속 좋아지는 것은 아닙니다. 도움이 되었기를 바랍니다.

이것은 일반적입니다.

일반적으로 더 작은 것보다 더 큰 견적을 제공하는 것이 좋습니다 (대부분의 경우 추정치를 초과 할 것입니다). 작업을 가능한 한 작은 하위 작업으로 자르고 각 작업마다 4 시간을 초과하지 않는 것으로 추정하는 것이 좋습니다.

작업이 4 시간 이상 걸리는 경우 다른 하위 작업 세트로 분류하십시오. 또한 지금 예측할 수없는 작업에 대한 백분율 버퍼를 추가하십시오 (개인 선호는 작업중인 시스템에 따라 예상치 못한 작업이 각각 2-4 시간 소요되는 2 개의 예상 작업마다 예상치 못한 작업 1 개입니다).

그런 다음 테스트, 커뮤니케이션, 분석 등에 시간이 걸릴 것입니다.

우선 : 문제를 시도 할 때마다 속도가 빨라지면 나쁜 프로그래머가 아닐 수 있습니다. 그래서 그 생각을 방해하지 마십시오.

이것이 관리자의 실패라고 제안하지만 기대치를 관리하는 것은 항상 귀하의 일입니다.

비현실적인 마감일을 지키지 못해 자신을 구타하기보다는 일주일에 실제로 할 수있는 일 수를 측정하십시오. 그런 다음 팀 리더에게 비즈니스 및 소프트웨어 개발에 익숙하지 않다고 설명하고 N 주 동안 선임 개발자 작업을 표준 주에 완료해야합니다. 그들은 그것을 좋아하지 않더라도 적어도 이것을 이해해야합니다.

그들에게 계속 개선을 기대한다고 말하고 개선을 측정 할 수있는 방법을 보여주십시오. 그리고 일주일에 5 일 간의 선임 개발자 작업을 할 수있을 때까지는 선임 임금을 기대하지 않는다는 데 동의하십시오. 그러나 마찬가지로 당신은 당신이 거의 지불하지 않으면 노인과 같은 책임을 기대하지 않습니다.

이것을 더 나아 가기 위해, 나는 추정을 위해 시간 대신 이야기 포인트를 사용하는 것을 강력하게 제안하는 이유입니다. 즉. 각 직업은 많은 점수를 받고, 팀은 주어진 기간 동안 달성 할 수있는 점수를 추정합니다. 다음 기간, 추정치는 전 휴일 또는 개발자 휴가와 같은 알려진 요소에 대해 조정 된 이전 기간의 실제와 동일합니다.

관리자로서, 새로운 개발자 (주니어 또는 상급자) 가 들어 오면 처음에는 견적을 늘리지 않을 것이라는 점을 비즈니스에 분명히 알립니다. 이 개발자는 다른 개발자가 저장하는 시간만큼 많은 시간을 소비 할 것으로 예상됩니다. 새로운 개발자는 아마도 그보다 더 나은 일을 할 것입니다.하지만 약속하지 않고 과도하게 제공하는 것이 만트라입니다.

개발자는 시간이 지남에 따라 상급자보다 3 배 빠르며 팀의 "달력"(매월 예상되는 달)이 향상 될 것입니다.

침착하고 계속하십시오. 추정치에 부합하지 않는 문제가 제기 된 경우 게시물에 기록한 내용과 동일하거나 안전하지 않다면 멘토 / 팀장과 직접상의하십시오.

견적은 그저 견적 일뿐입니다. 그들은 밧줄을 배우고있을 때 더 많이 떨어져있을 수 있습니다. 그리고 주니어로서, 특정 프로젝트의 팀원, 현재 사용중인 기술을 사용하는 프로그래머 및 회사의 직원으로 로프를 배우는 경우가 많습니다. 그리고 현명한 사람들과 일하고 있다면, 그들은 당신이 추정치에서 벗어날 것이라고 기대 하고 있습니다.

"아래에서 위로"받는 작업을보고있을 것입니다. 귀하의 작업은 현재 진행중인 프로젝트의 큰 그림보다 중요합니다. 이해할 수 있습니다. 당신은 추정치가 당신에게 부과 된 제한으로보고, 당신이 그것을 만나지 않을 때 분명히 불안 해지고 있습니다.

그러나 큰 그림을 보면 개발자의 '목표'보다 더 많은 추정치가 리드 / 프로젝트 관리자의 '신호'라는 것을 알 수 있습니다. 작업을 작업으로 나누고 추정하는 것은 전체 프로젝트를 관리하고 추정하는 복잡성을 줄이는 방법입니다. 실제 작업과 예상 작업을 추적하는 것은 프로젝트의 진행 상황을 추적하는 수단이지만 적용 할 수있는 메트릭 중 하나 일뿐입니다. 추정치가 정기적으로 충족되지 않으면 관리자에게 프로젝트에 문제가 있음을 나타내는 신호입니다. 그러나 합리적인 프로젝트에서 팀에 주니어 개발자가 추정을 충족시키지 못한다는 사실은 아닙니다.

두 친구 인 WAG와 SWAG를 소개하겠습니다.

즉, '야생 엉덩이 추측'과 '과학적인 야생 엉덩이 추측'

믿거 나 말거나, 나는 이것을 구성하지 않았다. 그들은 실제로 사업에서 꽤 일반적입니다. 에서 봐 이 문서 무슨 뜻인지 볼 수 있습니다.

이상적으로는, 정확한 추정치를 제시하는 것이 가장 좋지만, 그렇게 할 수 없다면 불완전한 데이터로 인해 추정치가 거칠다고 진술하는 것이 좋습니다.

열쇠는 사업은 컴퓨터 프로그래밍이 아니라는 것입니다. 기대치 관리는 정밀도보다 중요합니다. 예상치 못한 문제를 해결하기 위해 비상시 10 %를 더할 것으로 생각되는 시간을 평가하는 것이 중요합니다.

당신이 과대 평가한다면, 당신이 여분의 시간을 마칠 때 그들은 행복 할 것입니다. 과소 평가하면 마감일을 충족해도 실망하지 않거나 무언가 잘못되면 매우 실망합니다.

비즈니스는 일부 사람들이 오랜 시간 동안 직관적 인 느낌을 얻는 회색 영역입니다. 주니어 개발자에게 이러한 종류의 결정을 독립적으로 요구한다는 사실은 한 가지를 말합니다. 이러한 의사 결정을 내릴 수있는 사람이 없거나 관리자가 실패에 대해 책임을지고 싶지 않습니다.

당신이 큰 조직에서 일하고 있다면 후자에 돈을 썼습니다. 계층 적 비즈니스 모델이 충분히 커지면 맨 위가 맨 아래에서 제거되어 상위업자는 종이에서받는 것으로 만 진행 상황을 측정 할 수 있습니다. 프로모션은 일반적으로 실수하지 않기 때문에 제공되기 때문에 끔찍한 환경입니다. 그러나 판촉을받는 사람들은 다른 사람들에 대한 책임을지고 (즉, 맹목적인 무능함) 사람들의 성공을 인정하여 실패를 피합니다.

불행히도 프로그래머는 문제가 아무리 크더라도 해결책을 찾기 위해 '버스 아래'를 던지기 쉬운 목표입니다. 핵심은 솔루션을 구현하는 것보다 문제를 추정하는 방법을 결정하는 데 더 많은 시간을 소비하지 않는 것입니다.

힘든 곳입니다. 해당 파이프 라인의 "그냥 전달해야"단계에 갇힌 것처럼 들립니다.

지난 몇 년 동안 나는 추정에 대해 다음과 같은 사실을 알아 차렸다. 추정의 질은 다음 세 가지 질문에 대한 적절한 이름으로 답할 수있다.

• 누가 디자인을 했습니까?
• 누가 추정 했습니까?
• 누가 구현하고 있습니까?

추정의 질은 명명 된 별개의 개체 수에 반비례합니다. 예를 들어, 가장 좋은 추정치는 동일한 사람이 위의 세 가지 작업을 모두 수행했을 때이고, 약한 추정은 한 사람이 설계 / 추정을하고 다른 사람이 구현을 수행 할 때이고, 최악의 추정은 세 가지 질문 모두에 대한 답변입니다. 고유 한 이름.