직원이 이슈 트래커를 업데이트하는 것이 왜 그렇게 어려운가?

나는 항상 회사와 직장에서 사람들이 자신의 문제를 업데이트하도록 노력했습니다. 나는 사람들이 실제로 그들의 마음의 선함에서 그것을 할 때 몇 가지 경우가 있었지만 ~ 70 %의 시간은 사람들을 쫓아 내야합니다.

일반적으로 일부 또는 다른 형태의 관리를 수행하는 사람이기 때문에 (나는 가장 먼저 개발자입니다), 주려고하는 주된 이유는 사람들을 쫓아 가고 진행 상황에 대한 쿼리를 중단하고 싶지 않기 때문입니다. 결국 사람들은 많은 질문을받는다고 생각합니다. 드물고 극단적 인 경우에 티켓을 업데이트하게됩니다 (보고서를 작성해야 할 때).

이 문제에 부딪 쳤습니까? 개발자가 문제 추적기를 자주 업데이트하도록 어떻게 권장 했습니까? 어느 정도의 성공을 거두었습니까?

그 이유는 그들이 말한 사실과는 별도로 이슈 트래커를 업데이트해야하는 이유를 알지 못 하기 때문입니다.

왜 그런가요? 내 생각에 추적기를 업데이트해도 의미있는 방식으로 작업에 영향을 미치지 않으므로 실제로 작업을 더 잘 수행하는 데 도움이되는 추적 시스템을 구현하는 것입니다.

직원 들은 이슈 트래커 업데이트가 중요하지 않다고 분명히 느끼기 때문에 어렵습니다 . 당신은 그것을 바꿔야하지만, 캐치가 있습니다. 의사 소통이 어렵다. 효과적인 의사 소통은 실제로 어렵습니다. 생각보다 어렵습니다. 너무 어렵습니다 . 우연히 그 통신은 실패합니다 .

보여주지 마 예 : 하지 말 것을 당신 (또는 상사) 보고서의 데이터가 필요합니다. 보기 에서 직원의 최신 이슈 트래커가 영향을 미치고이를 데 어떻게 도움이되는지 관점.

예를 들면.

저는 개발자이며 우리가 작업중인 이슈 트래커를 사용하기 위해 고심하고 있습니다. 나는 그들이 일을 조직적으로 유지하기 때문에 모두 불행하다. 현재 나의 해결책은 개인 추적 도구를 사용하여 일상적인 스크럼에서의 진행 상황에 대해 이야기하는 것입니다.

트래커를 항상 사용하게하는 이유는 다음과 같습니다.

• IDE 및 소스 제어와의 완벽한 통합 라이센스가 이미 구입 되었기 때문에 약간의 웹앱을 사용합니다. 작업을 생성 / 업데이트하는 데는 시간이 오래 걸리고 혼란스러운 UI 기능이 있습니다. 불행히도 이것을 사용하는 것은 우리 팀의 통제 범위를 벗어납니다.

• 간단. 이것은 단지 작업을 추가하기 위해 수동으로 채워진 10 개의 필드를 사용하지 않는 것을 의미합니다. 프로젝트 / 컴포넌트 등을 수동으로 입력하는 시간별 예상 시간 대 완료 시간 여러 분야 등에서 시간의 양을 늘리십시오.

• 하나만 이것이 얼마나 일반적인지 잘 모르지만 프로젝트 관리는 하나의 도구를 사용하고 지원은 다른 도구를 사용하며 개발은 세 번째 도구를 사용합니다. 하나가 업데이트되지 않으면 확실히 세 가지가 업데이트되지 않았으며 그들 사이의 동기화가 자동화되지 않을 것입니다.

우선 : "진행 상황을 업데이트하는 사람들"은 무엇을 의미합니까?

"현재 평가를 업데이트하는 개발자"또는 "문제를 해결하지 않은 개발자"또는 "해결 된 문제를 해결하지 않은 고객 / 테스터"또는 모두를 의미합니까?

개발자의 관점에서 보면 사고 방식과 문화가 혼합되어 있습니다.

• 사고 방식 : 문제를 해결하도록 설정하면 문제가 해결되었으며 버그가있는 경우 책임을집니다
• 문화 : 회사 전체가 그러한 도구를 사용하고 싶지는 않지만 다른 조직 전략을 선호하는 경우

내 경험은 : 최소한 올바른 방향으로 향하도록 문화가 필요하다는 것입니다. 다음에 도움이되는 것은 DoD ( '완료'의 정의)를 정의하는 것입니다. 개발자 (다른 역할에도 적용됨)가 전체 목록을 충족한다고 말할 수 있으면 문제가 해결되었다고 표시하고 필요없이 계속 진행할 수 있습니다 뒤돌아 보려고

티켓이 닫힐 때까지 크레딧이 제공되지 않을 때까지 코딩 진행에 대한 질문을 중지하십시오 (일반적으로 얇은 공기에서 임의의 비율로 뽑아냅니다). 측정 한 주요 항목이 닫힌 티켓 수인 경우 개선됩니다.

그러나 보완적인 측정 항목으로 팀을 구성 할 때 모든 측정 항목이 게임 화되고 측정 항목이 더 잘 작동하는 경향이 있습니다. 예를 들어, 재개 된 문제가 조기 종료됨을 의미하므로 다시 열어야 할 수도 있습니다.

다른 답변에서 지적했듯이 올바른 질문은 아마도 문제 추적기가있는 이유입니다. 문제 추적 시스템이 실제로 작동하고 정기적으로 업데이트되도록하려면 관리 관점뿐만 아니라 개발자 관점에서도이 질문에 대한 정답이 필수적입니다.

많은 회사에서 이슈 추적 시스템은 주로 관리보고 도구로 사용됩니다. 관리자가 보고서를 실행할 수 있도록 프로그래머가 문제를 업데이트하도록하는 것은 효과가 없습니다. 프로그래머가 문제를 업데이트하도록 강요해도 문제가 해결되지 않습니다. 업데이트 된 문제가있을 수 있지만 데이터에 질문해야합니다.

내 경험상 실제로 개발자 (및 테스터, 관리자 등)가 효과적으로 이슈 추적 시스템을 사용하게하는 유일한 방법은이를 개발 프로세스에 통합하는 것입니다. 이는 프로세스의 한 부분의 출력이 프로세스의 다음 부분에 대한 입력이됨을 의미합니다.

버그 추적 시스템 권한을 부여하려면 다음을 제안합니다.

• 개발자는 이슈 트래커에 기록 된 버그 / 기능에 대해서만 작업하며 그 밖의 작업은 수행하지 않습니다. 모든 아이디어, 리팩토링 프로젝트, 새로운 기능, 개발할 사용자 정의 도구 등도 기록해야합니다.
• 문제는 우선 순위에 따라 진행됩니다. 우선 순위는 부분적으로 경영진이 결정해야하지만 개발자는 우선 순위를 결정할 때 반드시 언급해야합니다. 유지 관리 및 리팩토링 문제와 관련하여 특히 그렇습니다.

처리 할 때 다음과 같은 것을 사용할 수 있습니다.

• '신규'상태는 개발자가 아직 문제를 해결하지 않았으며 우선 순위가 지정된 문제의 대기열에 있음을 나타냅니다.
• '할당 됨'상태는 개발자에게 할당되었음을 나타냅니다. 이는 개발자 또는 팀 리더와 같은 다른 사람이 수행 할 수 있습니다. 각 개발자에게 몇 가지 문제가 할당되고 일반적으로 새로운 기능과 같은 '무거운 리프팅'과 간단한 버그 또는 간단한 유지 보수 작업과 같은 쉬운 선택이 혼합되어있는 것이 좋습니다. 이를 통해 개발자는 기분에 따라 작업을 선택할 수 있습니다.
• '진행 중'상태는 개발자가 문제를 해결하고 있음을 의미합니다. 개발자마다 한두 가지 문제 만 '진행 중'이어야합니다.
• 문제가 해결되면 개발자는 문제 상태를 '테스트 필요'로 변경하고 소유자를 테스터로 변경할 수 있습니다. 이것은 테스터의 작업 대기열이기도하기 때문에 중요한 단계입니다.
• 테스터는 상태를 '실패한 테스트'로 변경하고 소유권을 개발자로 다시 변경할 수 있습니다. 즉, 개발자의 대기열 맨 위로 이동하거나 상태를 '배포 준비'로 변경할 수 있습니다.
• 그런 다음 '배포 준비 완료'상태의 문제는 릴리스를 담당하는 사람이 릴리스주기에 따라 병합 및 릴리스 할 수 있습니다.

한마디로 문제 추적 시스템을 개발 프로세스의 필수 부분으로 만들면 업데이트되지 않는 문제에 대해 걱정할 필요가 없습니다.

브라우저를 열고 로그인하여 티켓을 찾아 채우는 것이 너무 많은 일이라고 생각할 수도 있습니다. 어쩌면 당신은 후크로 그들을 격려하려고 할 수 있습니다 . 요즘에는 git / hg 메시지 [이 중 하나를 사용한다고 가정]에서 FIXED # 123과 같은 것을 입력 할 수 있으며 커밋을 푸시하면 티켓이 자동으로 변경되는 것이 일반적인 기능입니다. 그렇게하면 개발자가 별도의 지점에서 각 문제를 해결하는 경우 (이미 티켓 ID가 있음) 개발자에게는 거의 효과가 없으며 커밋 메시지에 해당 문자 몇 개를 추가 할 가능성이 높습니다. 이 솔루션으로 충분하지 않으면 티켓의 범위가 너무 커서 여러 개의 작은 티켓으로 나누어야합니까?

이것은 무엇보다도 회사 문화 문제처럼 들립니다. 추적기를 사용해야하는 사람은 누구입니까? 이것이 한 사람이나 그룹이 던져 버린 것이고 다른 사람들이 받아 들이고 사용하기를 기대합니다. 행운. 사람들이 그것이 무엇인지 이해하고, 그것을 사용하는 방법을 알고, 그것이 실제로 그들의 삶을 더 쉽게 만드는 것 (당신의 삶이 아닌 그들의 삶)을 받아들이지 않는 한, 그들은 경영진에 의해 강제되지 않으면 그것을 사용하지 않을 것입니다. 즉, 트래커를 사용하는 것이 회사의 결정이라면 관리를 통해 추적기를 시행해야합니다. 귀하의 역할에 사람들이 추적기를 사용하도록하는 책임과 권한이 없다면 (개발자라고 말한 것처럼 '아니요'라고 소리 내림), 귀하가하는 일 (사실상 IMHO)에 관계없이 멀리 가지 않을 것입니다. ).

이것은 사람들이 정기적으로 시간을 보내기 어려운 이유와 비슷할 것입니다. 지루한 직업입니다 ...

많은 이슈 트래커가 IDE와 통합됩니다. 예를 들어, TFS 작업 항목 추적기를 사용하면 체크인을 수행 할 때 작업이 해결 된 것으로 표시 할 수 있습니다. 체크인이 작업과 연결되도록 요구하는 옵션도 있습니다. 체크인 프로세스의 일부로 작업 항목을 업데이트하면 작업이 단순화됩니다. 대안은 별도의 인터페이스에서 이슈 트래커를 열어 변경을 수행하는 것입니다.

또 다른 옵션은 누군가가 추적기를 열고 사람들이 상태를 제공 할 때 작업을 업데이트하는 상태 회의 (또는 매일 대기하는 동안)입니다.

고려해야 할 한 가지는 GUI 자체가 장애라는 것입니다. 예를 들어, 일부 장애물에는 다음이 포함될 수 있습니다.

• 너무 많은 클릭
• 최적화되지 않거나 전력이 부족한 이슈 트래커 애플리케이션 서버
• 유용성 또는 접근성 불량

API를 노출하면 이슈 트래커를 기술 아티팩트 (코드 적용 범위, 단위 테스트 보고서, 빌드 상태 등)와 동일한 스크립팅을 통해 업데이트 할 수 있습니다.

참고 문헌

• Scrumwise-API

• JIRA Cloud REST API 참조

• Alfresco Content Services REST API