레드마인 사용시 담당자란?

[Sungje]

안녕하세요.

이곳에 글을 올리는건 처음이네요.

저희 회사에서는 ITS로 레드마인을 사용하는데 보고자와 담당자를 기술지원팀과 개발자로 구분하여 사용하고 있습니다.

이슈(일감)의 상태는 신규, 수정, QA, 완료 와 같이 4가지 단계로 구분되어 있구요.

기술지원팀(고객지원팀)이 이슈(일감)를 접하면 신규로 작성하고 담당자를 개발자로 지정합니다.(보고자를 수정하는게 레드마인에서는 불가하더군요)

그리고 개발자가 수정하면 QA로 상태를 변경하고 테스트가 이상이 없으면 이슈(일감)상태롤 완료로 선택하여 이슈를 완료처리합니다.

그런데 문제는 상태를 변경할때 마다 담당자를 변경하자는 이야기 하는 사람이 있습니다.

즉 QA로 이슈 상태를 변경하면 담당자를 개발자가 아니라 QA 테스터로, 완료시에는 담당자를 최초 보고한 기술지원팀 으로

전 담당자는 변경하지 않는게 좋다라는 입장입니다.(레드마인에서 제공하는 리포트 기능에도 보고자, 담당자에 대한 요약 리포트가 쓸만합니다)

딱히 이게 정답이다 라는건 없겠지만 다른 분들은 어떻게 사용들을 하시는지 궁금합니다.

하면서 느끼는 거지만 설득하고 이해시키고 막상 준비되서 하려고 보면 이런 저런 말도 많고. 싫다는거 억지로 강요할 필요가 있나 싶기도 하고.

무슨 오지랖이 넓어 내가 이러나 싶기도 하고. 내가 잘하고 있나 라는 생각이 불현듯 나는군요.

[Youngrok Pak]

담당자를 바꿔주면 자기 담당인 이슈로 검색해서 볼 수 있기 때문에 편리하긴 하죠. 개발자가 여럿일 때도 담당자를 넘겨가면서
작업할 수 있구요. 변경하는 것이 더 좋다고 봐요.

나의 iPhone에서 보냄

2012. 10. 26. 오전 9:23 Sungje <sun...@gmail.com> 작성:

[sMiLo]

저희 팀에서도 담당자는 해당 일감을 실제로 담당하시는 분으로 정하고 있습니다.

레드마인에서 담당자 별로 sorting해서 주간 회의를 진행하기 때문에 나름 관리도 잘 되는 편이구요. (본인이 담당자로 지정된 일감이 다른 사람에 비해 너무 많으면 안되겠죠? -_-)

해당 일감의 내용 중 본인이 작업하던 부분을 완료 후 다른 사람에게 '담당자'를 이관하는게 자연스러운 상황입니다.

레드마인을 적용하기 위해 준비하던 단계부터 '담당자 개념'에 대해 계속 주지시켜놨기 때문에 큰 불편 없이 사용하고 있습니다.

2012/10/26 Youngrok Pak <pak.yo...@gmail.com>

[booil jung]

Sungje님 말씀에 공감합니다.

담당자는 변경하지 않는게 좋습니다.

담당자란 소스나 데이터에 변경을 가하는 사람으로 해야 합니다.

그리고 QA는 소스의 변경에 대해 해당 이슈만 테스트하는 것이 아니라, 전반적인 테스트를 하기 때문에, 담당자로 지정하기에 부적합합니다.

이는 리포터도 마찬가지입니다.

일감의 상태를 커스터마이징 해서 쓰는 군요.

이슈트래커는 소프트웨어에 강한 문화권에서 오랫동안 사용된 경험의 산물입니다.

이슈트래커를 고쳐서 쓴다면 그것이 오히려 절차가 잘못 운영되고 있는 것입니다.

새창이 추가되는 새 기능을 작업하기로 했다는 예를 들어 보이겠습니다.

새로운 창을 기능으로 넣어야 한다면...

1. 회의를 통해 변경을 가할지 결정하고 요구사항서에 변경을 가하는 작업.

2. 설계에 변경을 가하는 작업.

3. UI 디자이너가 UI 문서와 파일을 생성하는 작업.

4. DB담당자가 데이터베이스에 항목들을 추가하는 작업.

5. 개발자가 UI에 해당하는 기능을 다른 코드와 연동시키는 작업.

이것들은 별도의 이슈로 두어야 하며  2, 3, 4, 5번은 1번 이슈에 종속된 이슈죠.

이 단계들을 건너 뛸때마다 담당자를 바꾸는게 아닙니다.

워크플로우에 대한 자세한 내용들은 버그질라(비록 버그트래커지만) 문서들을 보면 잘 정리 되어 있습니다.

회사 직원들이 이슈트래커의 개요를 정확히 파악하는 것이 먼저일 것같습니다.

Sungje님 말씀이 맞습니다.

[장준성]

저희 회사에서도 담당자를 바꿔가면서 씁니다.

작업자 입장에서 자신에게 할당된 (자신이 담당자로 지정된) 일감에만 신경을 쓰고
해당 영역에 대한 처리를 끝냈다고 생각할 때 이후에 작업할만한 담당자에게 작업을 넘깁니다.

그런 식으로 진행하게 되면 진행이 결정된 업무에 대해서는 관리의 부담이 줄기 때문에
작업자 입장에서의 관리 부담을 줄어들 것이라 생각합니다.

물론 큰 업무를 좀 더 작은 단위 업무로 나누고 그에 따라 담당자를 분리하는 것도 합니다.
그 외에 이슈트래커의 영역 밖의 영역은 이슈 트래커와는 다른 방법으로 관리되는 부분도 있고요.

다만, 이후에 작업이 완료되거나 하게 되면 담당자를 구현자로 바꾸는 작업을 합니다.
프로그래머 중심의 업무라 그런지 완료 후 보고 자료 등을 위해 담당자로 구현자를 해 놓고
이후에 관련 업무가 있을 때 다시 살펴보거나 하는 경우 쓰이더군요.

2012년 10월 26일 오전 10:55, booil jung <tedfr...@gmail.com>님의 말:

[Sungje Hong]

Youngrok Pak, sMiLo, 장준성님 세분께서는 담당자를 바꿔 사용하시고

booil jung 님께서는 바꾸지 사용하지 않으시는군요.

일단 저도 바꾸지 않아 사용하자는 쪽입니다.

booil 님 말씀처럼 담당자를 바꾸어야 하는 경우 종속된 이슈(일감)을 새로 만드는게 관리면에서 더 낫다고 생각되네요.

기본적으로 레드마인이 Report와 AssingnedTo 와의 대화(소통?)를 전제하는 도구라는 생각이 드는군요.

(UI나 요약 리포트등을 보면 더욱 그렇구요. 혹 영어원문 Assigned To 을 담당자로 했기 때문에 바꿔서 사용하게 되지 않았나 생각해봅니다.)

그런데 다른 분들은 담당자를 바꾸는 경우가 많이 있으신가요?

저희 회사는 테스터 말고 아무리 생각해도 담당자를 바꿀경우가 없는데 말이죠.

booil님 말씀처럼

일단 보고자, 담당자를 두고 이슈(일감)를 진행하고

추가적인 문제들(테스터....말고 딱히 생각나는게 없네요)은 하위 이슈로 등록하고 그곳에 담당자를 두는게 좋겠다는 생각이 듭니다.

그걸로 일단 설득해볼까 합니다.

준성님 말씀에 보면 이슈(일감)에 해당영역이 끝난 경우에 다른 담당자에게 넘기신다고 하셨는데

저희는 1버그,1수정,1커밋 을 적용할 생각입니다. 그래서 한 이슈에 담당자의 영역 모두 완료 되기때문에 담당자가 변경될 일이 없겠네요.

다른 분들 말씀 감사합니다.

[Daeny Lee]

안녕하세요...

담당자를 바꾸던 바꾸지 않던 운용하시는 곳의 특성에 맞게 잘 운용하시면 된다고 생각합니다.

다만, 레드마인의 툴도 실제 생활에서 일어 날 수 있는 상황과 비슷하게(?) 운용하는게 좋다고 생각합니다,

실제 개발이나 고객 지원 시, 간혹 개발 담당이나 지원 담당자는 바뀔 수 있습니다.
그렇게 때문에 레드마인에서도 담당자가 바뀔 수 있어야 하는 것이 더 실재적이지 않나 생각됩니다.

감사합니다.

2012/10/26 Sungje Hong <sun...@gmail.com>:

[gyehong park]

안녕하세요. 박계홍입니다.

메일을 읽다가 조금... 모랄까 좀 우려스러운 부분이 있어서 말씀을 드립니다.

Sungje Hong 님을 잘 모르니 제가 오해했을지도 모릅니다. 그렇다면 살짝 넘어가주시면 좋겠습니다.

애자일 실천법 같은 것을 도입할 때 "무엇이 옳은가?"하는 논쟁은 조심해야 됩니다.

저는 이 메일을 읽으면서 이런 생각이 들었습니다.

'아 이슈관리를 할 때 크게 2가지가 있을 수 있겠구나.'

'나는 어떻게 사용했지?'

'그러면 서로 어떤 장단점이 있지?'

그런 생각들을 하고 있는데. Sungje Hong 님의 이번 메일에서 무엇인가 확인을 했고, 결론을 내린 것 같은 느낌을 받았습니다.

그러면서 걱정이 들었습니다. Sungje Hong 님의 결론을 다른 분들은 잘 받아들이고, 잘 진행될 수 있을까하는 생각이 들었습니다.

Sungje Hong 님의 결론이 더 좋은 방법일 수록 실제로 적용은 더 잘 안될 수 있습니다.

애자일의 어떤 방법이든 회사와 팀에 맞게 진행해야 보다 더 잘 됩니다.

그래서, 어떤 결론을 내리기 전에, 

다른 분들도 관련 문제에 대해서 고민하고, 조사하고, 

관련 정보를 같이 공유한 후에 팀에서 같이 결론을 내리는 방법은 어떨까 싶습니다.

어떻게 진행하느냐 보다 어떻게 정했느냐가 더 중요한 경우가 많습니다.

이 부분도 같이 고민해 보시면 좋겠습니다.

잘 되기를 바랍니다. 좋은 하루되세요~

2012년 10월 26일 오후 2:21, Sungje Hong <sun...@gmail.com>님의 말:

[임용섭]

저희 회사에서도 담당자를 바꿔가면서 사용합니다.

시스템 도입 초기에는 실제 사용자 개개인의 편의성 향상에 집중하는게 좋다고 생각합니다.

그리고 저희는 3년 넘게 사용하고 있지만, 담당자를 고정시켜야할 필요성을 못느끼고 있습니다.

[booil jung]

안녕하세요.

Sungje Hong 님께 첨언 드리자면...

Assigned To가 바뀌는 경우가 있습니다.

자세한 내용은 역시 버그트래커 문서들에 보면 나와 있습니다.

(아시겠지만... 기존에 작업 했는데 다시 Open되는 경우, 테스터가 Feedback을 했는데 개발자가 바뀌는 경우... 등이죠)

이슈 트래커 사용 목적을 보면

책임을 명확히 하고, 협업의 혼란을 줄이며, 커뮤니케이션 비용을 줄이고, 이슈 기록 자체가 문서 역할을 하기 때문입니다.

이슈 트래커는 최초 보고자가 직접 자신의 계정으로 이슈를 추가하는 것이 원칙입니다.

전화 접수, 메일 접수 후 타인이 기록하는 것은 배제하는 것을 원칙으로합니다. (고객의 전화는 접수자가 기록해야 합니다. ^^)

이 원칙을 지키면 작성자는 이슈에 Author로 이미 기록이 되어 있고, 이를 기준으로 소트식을 만들면 확인이 가능합니다.

그래서 리포터를 Assigned To로 변경할 필요가 없다는 생각입니다.

QA는 '일괄 테스트'를 시행하고...

Resolved 상태의 이슈들을 Closed로 바꾸게 됩니다.

특정 이슈 하나를 두고 테스트를 하지 않기 때문입니다.

일단 다른 이슈트래커, 버그트래커, 애자일카드도구등의 제품들을 종합적으로 살펴보는것이 좋습니다.

^^/

[Deokjune Yi]

안녕하세요, 제 경험도 공유하기 위해 글을 씁니다.

 

저도 담당자를 바꾸지 않는 쪽을 선호합니다.

 

품질 업무는 모든 기능 개발 및 결함 조치 업무 흐름에 포함됩니다.

(추가로 통합, 릴리즈도 비슷합니다.)

 

해당 프로젝트의 품질 담당자 역할을 맡는 사람이 있고, 개발 업무 흐름 중

품질 검증 단계를 포함시켜 품질 담당자의 확인 없이 업무가 종료될 수 없도록

하는 방식이 보편적인 것으로 알고 있습니다.

 

담당자는 해당 기능 개발(결함 수정)을 담당하는 사람입니다. 그 역할을 하는

사람이 바뀔 수도 있습니다. 그 때는 당연히 담당자를 바꿔야합니다. 하지만

품질 담당자가 해당 기능 개발 담당자로 일시적이라도 시스템에 등록되는

것은 적절치 않다고 생각합니다.

 

레드마인을 비롯한 대부분의 이슈 트래커가 지원하는 Custom Query 기능을

이용해서 검색식을 만들어 놓기만 해도 편의성에서 큰 무리가 없습니다.

 

하지만,

 

개발 담당자, 품질 담당자, 빌드 담당자, 릴리즈 담당자 등의 역할이 명확히

구분되지 않고 모호한 개발 조직이라면 얘기가 달라질 수도 있겠다는 생각도

합니다.

 

감사합니다.

이덕준 드림

 

2012/10/26 booil jung <tedfr...@gmail.com>

[Sungje Hong]

여러 염려에 대한 말씀과 경험에 관한 말씀들 감사합니다.