소프트웨어 엔지니어가 시간을 추적하도록 장려

동료가 문제 해결 및 기능 구현에 소요되는 시간을 추적하도록 어떻게 격려 할 수 있습니까? 이 작업을 수행 할 소프트웨어가 있지만 숫자 만 입력하지는 않습니다.

과거 견적과 실제 소요 시간을 비교하여 팀이 프로젝트 견적을보다 잘 제공하기를 원합니다. 동료들은 종종 프로젝트 일정에 관여하지 않기 때문에 개인적인 이익을 보지 못할 것으로 생각됩니다.

동료들은 종종 프로젝트 일정에 관여하지 않기 때문에 개인적인 이익을 보지 못할 것으로 생각됩니다.

고칠 수 있습니다.

예약에 참여 시키십시오.

Joel Spolsky는 Evidence Based Scheduling 에 관한 기사를 작성하여 몇 가지 주장을 찾는 데 도움을 줄 수 있습니다.

더 나은 평가 기술이 더 나은 소프트웨어를 생산하는 데 도움이 될 수 있음을 동료에게 확신시켜야합니다. 작업 시간 추적에 유리한 점은 다음과 같습니다.

• 임의의 관리 설정 마감일이있는 경우 적절한 평가를 통해 해당 시간에 실제로 달성 할 수있는 내용을 알 수 있습니다 . 보너스로 당신은 당신이 무슨 말을하는지 관리자에게 확신시키는 멋진 그래프를 가지고 있습니다.
• 프로젝트를보다 신중하게 생각해야합니다. 내가 연결 한 기사는 "일정을 몇 시간 안에 측정 할 수있는 매우 작은 작업으로 나누어야 한다"고 말합니다. 프로젝트의 모든 측면에 대해 생각 했으므로 ( 사양을 작성하는 것이 좋습니다!) 생각하지 않은 것에 놀랄 가능성이 훨씬 적습니다.
• 그것은 당신을 더 나은 개발자로 만듭니다. 시간이 지남에 따라 과소 평가하는 경향이있는 작업을 볼 수 있으므로 맹목적으로 최적화 하는 대신 특정 작업 에서 더 나은 시간을 보낼 수 있습니다 .

당근과 스틱과 같은 표준 방법 으로이 작업을 수행 할 수 있습니다.

이 경우 당근은 "우리의 현재 속도를 이해함으로써 미래의 예측을 향상시킬 수 있습니다". 그러나 당신은 따라야합니다.

그들이 프로젝트 일정에 자주 관여하지 않는다는 귀하의 의견은 이것을 어려운 판매로 만들 수 있습니다.

그중에서 가장 높은 기능, 특히 PSP 추종자가있는 경우 더 잘 작동하도록 돕는 것입니다.

가장 일반적인 막대기는 (당근을 때리고 당근을 붙들 지 않고) "필수적입니다."입니다. 동기 부여는 많지 않지만; 적어도 위치는 분명하다.

마지막으로, 사용중인 소프트웨어가 그 기억에 기여하고 있습니까? 어색합니까? 시스템 A에서 시간 코드를 찾아보기 전에 시스템 B에서 시간 코드를 찾아야합니까? 너무 세분화되어 있고 "off"시간을 허용하지 않으며 하루 8 시간의 회계를 요구합니다. 채택에 도움이되도록 가능한 한 마찰이없는 상태로 만드십시오.

행운을 빕니다

내 경험상 다음은 대부분의 시간 추적 소프트웨어의 문제입니다.

• 개발자는 작업을보다 쉽게 ​​예측 가능한 하위 작업으로 분류 할 수있는 권한이나 권한이 없습니다.
• 소프트웨어 개발 및 디버깅에 항상 등장하는 상황에서 작업을 시작할 때까지 알지 못한 하위 작업을 처리하는 좋은 방법은 없습니다 .
• 작업에 얼마나 많은 노력을 기울 였는지, 회의에 얼마나 많은 노력을 기울 였는지, 동료의 질문, 동료 검토 및 기타 간접비를 정확히 기억하기가 어려울 때 소요 시간이 입력됩니다.
• 추적되지 않은 작업을 처리하는 좋은 방법은 없습니다. 하루가 끝나면 6 명은 회의 등을 처리하는 데 소비되었지만 8 시간을 줄입니까?
• 추정치에서 불확실성을 설명하고 의사 소통하는 좋은 방법은 없습니다.

포모 도로 (Pomodoro) 기술을 사용하기 시작하여 이러한 많은 문제를 해결했습니다. 한 작업에서 25 분 동안 중단없이 작업하면 바로 기록되며 중단되지 않은 간격으로 견적이 수행됩니다. 나는 여전히 불확실성을 전달하기 위해 증거 기반 일정을 통합하고 있으며, 내 자신의 세밀한 추적을 PM이 좋아하는 대략적인 일정 추정치로 변환하려고 노력하고 있지만 지금까지 확실히 개선되었습니다.

좋은 방법

실제로 Mylyn처럼 쉽고 투명하게 만드는 소프트웨어를 사용하십시오. 예를 들어 시간 번 다운 차트와 같은 도구와 결합하십시오.

나쁜 방법

프로젝트, 작업, 정확한 날짜 및 시간 등을 수동으로 지정해야하는 지루한 작업 표를 작성하도록합니다.

팀 리더 / PM이 아닌 경우이 팀과 싸우려고합니다. 사람들은 절대적으로 필요한 것보다 더 많은 일을해야하는 경우 동료의 말을 듣지 않습니다 (어쨌든 내 경험상). 팀 리더 나 PM에게 맡기십시오. 사례에 동의하면 시간 로깅을 의무화 할 수 있습니다 (현재 작업중인 상황).

팀장 / PM 인 경우 역할을보다 강력하게해야합니다. 이러한 사람들은 자신이 말한 것을 효과적으로 수행해야하며, 업무를 수행하기 위해 더 많은 정보가 필요하면 직원에게 제공해야합니다. 정보. 그들이 유용한 정보를 얻는 데 도움이되지 않는다면 정보가 유용한 이유를 이해하지 못했기 때문에 정보를 얻는 데 도움이되지 않는 경우, 프로젝트 일정을 벗어나는 방법 / 과대 평가 된 결과 / 무엇이 원인인지 설명하기 위해 그들과 대화 해보십시오. 당신은 문제, 당신이 그들을 돌릴 수 있는지보십시오!

시간을 추적하거나 지급받지 마십시오. 수백만의 사람들이 (컨설턴트, 변호사 등) 왜 그렇게 할 수 없습니까?

어떤 사람들은 이것이 드라코 니안이라고 생각할 수도 있지만 그렇지 않습니다. 스타 벅스에서 일하는 경우 화장실을 청소해야합니다 . 은행에서 일하는 경우 매일 양복을 입고 일하고 넥타이를 달고 시간을 추적해야하는 팀의 소프트웨어 엔지니어 라면 그렇게하십시오 !

때로는 우리가 싫어하는 일을해야 할 때가 있습니다. 우리는 모두 큰 소년과 소녀입니다. 처리 할 수 ​​있어야한다고 생각합니다.

분명히 최선의 대답은 전적으로 팀의 심리적 혼합에 달려 있습니다. 그들은 경쟁력이 있습니까? 우승자가 시스템에 시간을 투자 한 것에 대해 보상하는 반복 경연 대회를 디자인하십시오. 플레이어가 공정하고 재미 있다고 생각할 수 있도록 컨테스트를 조정하고 조정하십시오. 그것을 게임으로 만드십시오.

아마도 그들은 실제로 작업을 수행하는 데 걸린 시간에 투명성 이 있다면 부정적인 결과가 발생할 것이라고 우려하고 있습니다. 나는 익명의 "노력 추적 도구"를 설계하고 개별 기여자가 따를 수 없었던 여러 개인이 각 버킷에 노력한 지출 금액을 쏟을만큼 충분히 높은 수준의 버킷 인 "노력 추적 도구"를 설계하는 것에 대해 항상 궁금했습니다. 높은 수준의 프로젝트 버킷에 대해보다 정확한 노력 비용을 얻는 것조차 프로젝트 계획 및 전체 팀 속도에 유용한 데이터 일 수 있지만 "OMG를 피할 수 있습니다. . "또는 사람들이 전통적인 시간 추적 시스템으로보고하기를 두려워한다는 점이 무엇입니까?

나는 이것이 단지 두 가지 예라고 생각하지만 실제로 팀의 심리적 구성을 잘 이해하면 노력 비용 정보에 인센티브를 주거나 격려하는 방법에 대한 올바른 대답을 줄 것입니다.

그들이이 요청에 잘 응답하지 않는 이유를 생각해보십시오 . 그들이 게 으르거나 노력을 피한다고 가정하지 마십시오.

증거 생성을 피하는 개발자는 대개

• 사용 및 / 또는 사용 방법에 대해 걱정
• 데이터의 유효성에 대한 우려

이것이 최근 포인트 기반 추정 및 셔츠 크기 조정 이 시작된 이유 입니다. 이는 추정 과정의 매우 불확실한 특성을 고려하고 "매직"(일명 불확실성 평균)이 스케줄링을 제어 할 수있게합니다.

그리고 논리적으로 보이지는 않지만 적어도 시간별 또는 일별 시스템뿐만 아니라 대부분 작동합니다. 임의의 방식으로 수행되면 한 달 만에 달성 한 결과로 팀이나 개인을 타격하는 것은 매우 어렵습니다.

또한 스크럼은 개발자가 속도를 제어 할 수 있도록하여 A, B 및 C 또는 A, Y 및 Z 중에서 원하는 것을 달성하겠다는 약속을하고 있음을 의미합니다. 그러나 당신이 그들에게 약속을하면 그들은 상관하지 않을 것입니다. 그것이 틀렸다면 당신의 잘못입니다.

나는 당신이 그런 식으로 재 추정을 사용하지 않겠다고 말하고 있음을 이해합니다. 그러나 팀의 개인은 얼마나 확신합니까?

프로그래머가 프로그래밍에서 더 많은 시간을 할애해야하는 도구가 반드시 좋은 것은 아닙니다. 프로그래머는 이미 오버 헤드가 많으며 5 분 간의 회의가없고 폭풍을 코딩하지 않습니다.

힘이 있다면, 그들에게 힘을 줄 수 있습니다. 그러나 지금까지 가장 좋은 해결책은 문제가없는 완벽한 도구를 만드는 것입니다. 디자인을 위해 수행하는 방법을 말할 수는 없지만 코딩을 위해 개발 환경에서 작성된 변경 사항을 기록하려고합니다. 이것은 엄청나게 높은 막대 였지만 Eclipse와 같은 것을 사용하는 경우 그다지 나쁘지 않을 수도 있습니다. 이 방법으로 각 파일 및 Java에서 각 메소드에 걸리는 시간을 측정 할 수 있습니다. 그것은 당신이 그들에게 청구서를 요청함으로써 얻는 것보다 훨씬 세밀한 정보이며, 그것은 매우 정확할 수 있습니다.

마찬가지로, 디자인을 입력하기위한 도구가 있으면 가로 챌 수 있습니다.

어떻게 그리고 왜 당신이 그들이 시간을 추적하기를 원하는지에 따라, 우리는 단지 사무실에서 시간이나 출퇴근에 시간을 계산하여 문제에 대해 생각하고 있습니까?

프로젝트 스케줄링은 어렵고 얻은 메트릭이 생각만큼 유용하지 않을 가능성이 높습니다. 두 가지 문제가 같지 않으므로 한 작업은 8 시간이 걸리고 다른 작업은 완료하는 데 32 시간이 걸릴 수 있습니다.

개발자가 작업 소요 시간을 추정 한 다음 시간이 지남에 따라 추정치가 얼마나 좋은지에 따라 증거 기반 스케줄링을 조사 할 수 있습니다. 그러나 모든 작업을 미리 알지 못할 수 있으므로 대규모 프로젝트에는 적합하지 않습니다. 대규모 프로젝트의 경우 비슷한 범위의 과거 프로젝트를 살펴보고 개별 견적을 집계하는 대신 척도로 사용하는 것이 좋습니다.

예를 들어 Pomodoro 기술 과 같은 개인 조직 시스템에 도입 해보십시오 (다른 많은 것들이 있지만 지금 시도 중입니다)

이 기술은 타이머를 사용하여 짧은 기간으로 구분 된 'Pomodori'(이탈리아 단어 'tomatoes')에서 25 분 간격으로 작업 시간을 분류합니다. 소프트웨어 설계에 사용되는 타임 박싱 및 반복 및 증분 개발과 같은 개념과 밀접한 관련이있는이 방법은 페어 프로그래밍 컨텍스트에서 채택되었습니다. 이 방법은 빈번한 휴식이 정신적 민첩성을 향상시킬 수 있다는 생각에 근거합니다.

그들이 숫자를 입력하도록 설득하는 대신, 쉽게 작동하는 소프트웨어를 사용하십시오. 나는 ScreenAware를 사용하고 있습니다 : https://www.screenaware.com/en/ 시간을 자동으로 추적하고 각 프로젝트에 할당합니다. 항상 정확하고 아무도 더 이상 추측 할 필요가 없습니다.

기존 티켓 시스템을 대신 사용해 보셨습니까? 티켓 시스템은 티켓 생성과 마감 시간 사이의 시간을 모니터링합니다. 작업에 대한 티켓을 만들고 코드를 커밋하기 위해 티켓 번호를 요구 사항으로 만들면 더 많은 돈을 벌 수 있습니다.