반응형
프로젝트 진행을 하다보면 문제가 발생하더라도 당장 큰 지장이 없다면
처리를 다음으로 넘기고 오픈을 하는 경우가 많이 있습니다.
이렇게 연기된 이슈들이 하나둘 쌓이다보면 일정에 구멍을 만들고
개발자들이 행복한 저녁시간을 만들지 못하는 원인이 되기도 하지요.
마찬가지로 플렉스 SDK 개발팀에서도 개발막바지에 가서는
처리못한 이슈들을 계속 뒤로 미룬다고 하네요.
이번시간에는 제기된 이슈가 연기됐을경우 어떻게 대처를 할 수 있는지
그리고 사랑받는(?) 버그가 되기 위한 조건에 대해 알아봅니다.
http://butterfliesandbugs.wordpress.com/2009/02/08/flex-jira-tips-part-v-what-does-it-mean-when-my-bug-is-deferred/
버그를 잡기 위한 이벤트가 오프라인에서도 진행되고 있습니다.
국내에서도 28일 어도비 커뮤티니 컨퍼런스에서도 이슈시스템에 대한 소개가 있었던것으로
들었습니다.
그리고 좀 더 적극적인 대응으로 이벤트가 진행되더군요.
'Bug Quash'라는 행사인데요.
http://www.bugquash.com/
3월 28일 하루동안 버그에 대해 여러 가지로 찔러보는 행사인듯 합니다.
Quash 라는 단어가 '〈반란 등을〉 진압하다, 억누르다, 누르다 (suppress)'라는 의미를 가진다고 합니다.
캐릭터도 닌자로 하는등....ㄷㄷ
시애틀에 계시는 분들은 직접 참석하셔도 괜찮을것 같구요.
그렇지 않다면 원격으로 참석도 가능하다고 합니다.
어떻게 진행되는지는 자세히 몰라서 일단 등록만 해놓았습니다.
등록할때 SDK에 대한 숙달도에 대한 질문이 있는데 I'm a baller 라는 항목이 있네요.
순서상으로는 Expert 위의 내용인데
검색을 해보니 '막나가는 갱스터'정도로 번역이 되던데요. ㅎㅎ
그런 의미는 아니겠죠. 하여간 잘나간다 뭐 그런 의미..
처리를 다음으로 넘기고 오픈을 하는 경우가 많이 있습니다.
이렇게 연기된 이슈들이 하나둘 쌓이다보면 일정에 구멍을 만들고
개발자들이 행복한 저녁시간을 만들지 못하는 원인이 되기도 하지요.
마찬가지로 플렉스 SDK 개발팀에서도 개발막바지에 가서는
처리못한 이슈들을 계속 뒤로 미룬다고 하네요.
이번시간에는 제기된 이슈가 연기됐을경우 어떻게 대처를 할 수 있는지
그리고 사랑받는(?) 버그가 되기 위한 조건에 대해 알아봅니다.
http://butterfliesandbugs.wordpress.com/2009/02/08/flex-jira-tips-part-v-what-does-it-mean-when-my-bug-is-deferred/
사용자들이 제기한 버그를 처리할 일정이 미루어졌다는 것을 이야기하는 것은 껄끄러운 부분이다.
처리되지 못한 버그 때문에 누군가는 맘 편히 지내지 못한다는 것 때문이다.
제기된 이슈가 "연기된 Deferred" 상태가 됐다는 것은 지금 작업하고 있는 릴리즈에 포함되지 않는다는 것이다.
즉, 현재 "연기된" 상태라는 것은 아마도 Flex 4(Gumbo)에서 처리되지 못한다는 것이다.
솔직하게 이야기하면 앞으로 언제까지 그것을 해결할지는 모른다.
매번 릴리즈시에 우리는 미루어둔 버그를 다시 보게 된다.
릴리즈에 포함하도록 다시 진행할 이슈를 선택을 위한 리뷰를 한다.
이런 과정은 몇 차례 반복해서 일어나고 주로 다음과 같은 경우에는 다시 검토대상이 될 가능성이 높다.
1. 회귀 - 이전 빌드에서 넘어오면서 무언가 잘못됐을 때(회귀테스트에서 실패하는 경우).
2. 추천 - 많은 수의 추천을 얻은 이슈.
3. 개발 막바지에 미루어진 것- 개발 막바지가 되면 버그처리를 연기하는 것에 둔감해지기 때문에 좀 더 많은 버그가 미루어진다. 그래서 릴리즈 몇 달 내에 미루어진 것은 다시 한번 살펴보게 된다.
4. 사람들에 의해 이슈가 되면 다시 관심을 받게 된다. 만약 블로그에 이슈를 올리고 이 글이 퍼지게 되거나 어도비지원팀에 의해 주목받게 된다면 우리에게 전달된다.
그래서 "연기된" 상태에서 다시 검토가 진행될 수 있게 하기 위한 팁으로 우리가 버그를 연기하는 몇 가지 사유를 이야기해보고자 한다. 물론 다른 많은 이유가 있고 나의 의견이 팀내 공통적인 의견은 아니다(이 글은 어도비의 공식적인 의견이 아님을 기억하자).
우리가 버그로 처리하지 않는 이유는 다음과 같다.
1. 회피방법이 있는 경우이다. 물론 이러한 것을 싫어할 수도 있겠지만 우리는 다른 방법이 없고 도저히 개발을 진행할 수 없는 버그를 먼저 수정할 것이다.
2. 추천이 없는 경우. 만약 아무도 버그에 대한 의견이나 추천이 없다면 많은 사람들이 이 버그에 대해 신경을 쓰지 않는다고 생각한다.
3. 예외적인 경우로 보일 때. 우리는 종종 재현하기 힘든 버그를 만난다. 특정인에게 해당하는 특별한 경우에만 발생하기 때문이다. 다른 말로는 "발견될 가능성"이 희박하다는 것이다. 모든 버그는 간단하게 재현할 수 있어야 한다는 것은 중요한 것이다. 그래야 버그를 쉽게 알아낼 수 있다.
4. 2번 항목과 관련해 이미 몇 차례 릴리즈 되어 잘 사용하고 있는 경우.
5. 제품개발주기에서 이미 늦었고 위험한 경우.
QA팀에 있다보면 수많은 버그와 다른 것을 보고하게 된다. 우리의 버그리포팅도 종종 연기된다. 기분 좋은 일만은 아니다. 개발자들은 자신이 발견한 모든 버그를 수정해줄것이라 바라고 있지만 현실은 그러기에는 너무 벅차다. 내가 알기로는 이슈를 오픈할지 연기할지를 결정해야 하기 때문에 내부 리뷰에 적재된 일만으로도 충분히 많다. 누군가에게 버그가 바로 수정되지 못한다는 것을 이야기하는 것이 얼마나 힘들다는것은 알고 있다.
처리되지 못한 버그 때문에 누군가는 맘 편히 지내지 못한다는 것 때문이다.
제기된 이슈가 "연기된 Deferred" 상태가 됐다는 것은 지금 작업하고 있는 릴리즈에 포함되지 않는다는 것이다.
즉, 현재 "연기된" 상태라는 것은 아마도 Flex 4(Gumbo)에서 처리되지 못한다는 것이다.
솔직하게 이야기하면 앞으로 언제까지 그것을 해결할지는 모른다.
매번 릴리즈시에 우리는 미루어둔 버그를 다시 보게 된다.
릴리즈에 포함하도록 다시 진행할 이슈를 선택을 위한 리뷰를 한다.
이런 과정은 몇 차례 반복해서 일어나고 주로 다음과 같은 경우에는 다시 검토대상이 될 가능성이 높다.
1. 회귀 - 이전 빌드에서 넘어오면서 무언가 잘못됐을 때(회귀테스트에서 실패하는 경우).
2. 추천 - 많은 수의 추천을 얻은 이슈.
3. 개발 막바지에 미루어진 것- 개발 막바지가 되면 버그처리를 연기하는 것에 둔감해지기 때문에 좀 더 많은 버그가 미루어진다. 그래서 릴리즈 몇 달 내에 미루어진 것은 다시 한번 살펴보게 된다.
4. 사람들에 의해 이슈가 되면 다시 관심을 받게 된다. 만약 블로그에 이슈를 올리고 이 글이 퍼지게 되거나 어도비지원팀에 의해 주목받게 된다면 우리에게 전달된다.
그래서 "연기된" 상태에서 다시 검토가 진행될 수 있게 하기 위한 팁으로 우리가 버그를 연기하는 몇 가지 사유를 이야기해보고자 한다. 물론 다른 많은 이유가 있고 나의 의견이 팀내 공통적인 의견은 아니다(이 글은 어도비의 공식적인 의견이 아님을 기억하자).
우리가 버그로 처리하지 않는 이유는 다음과 같다.
1. 회피방법이 있는 경우이다. 물론 이러한 것을 싫어할 수도 있겠지만 우리는 다른 방법이 없고 도저히 개발을 진행할 수 없는 버그를 먼저 수정할 것이다.
2. 추천이 없는 경우. 만약 아무도 버그에 대한 의견이나 추천이 없다면 많은 사람들이 이 버그에 대해 신경을 쓰지 않는다고 생각한다.
3. 예외적인 경우로 보일 때. 우리는 종종 재현하기 힘든 버그를 만난다. 특정인에게 해당하는 특별한 경우에만 발생하기 때문이다. 다른 말로는 "발견될 가능성"이 희박하다는 것이다. 모든 버그는 간단하게 재현할 수 있어야 한다는 것은 중요한 것이다. 그래야 버그를 쉽게 알아낼 수 있다.
4. 2번 항목과 관련해 이미 몇 차례 릴리즈 되어 잘 사용하고 있는 경우.
5. 제품개발주기에서 이미 늦었고 위험한 경우.
QA팀에 있다보면 수많은 버그와 다른 것을 보고하게 된다. 우리의 버그리포팅도 종종 연기된다. 기분 좋은 일만은 아니다. 개발자들은 자신이 발견한 모든 버그를 수정해줄것이라 바라고 있지만 현실은 그러기에는 너무 벅차다. 내가 알기로는 이슈를 오픈할지 연기할지를 결정해야 하기 때문에 내부 리뷰에 적재된 일만으로도 충분히 많다. 누군가에게 버그가 바로 수정되지 못한다는 것을 이야기하는 것이 얼마나 힘들다는것은 알고 있다.
버그를 잡기 위한 이벤트가 오프라인에서도 진행되고 있습니다.
국내에서도 28일 어도비 커뮤티니 컨퍼런스에서도 이슈시스템에 대한 소개가 있었던것으로
들었습니다.
그리고 좀 더 적극적인 대응으로 이벤트가 진행되더군요.
'Bug Quash'라는 행사인데요.
http://www.bugquash.com/
3월 28일 하루동안 버그에 대해 여러 가지로 찔러보는 행사인듯 합니다.
Quash 라는 단어가 '〈반란 등을〉 진압하다, 억누르다, 누르다 (suppress)'라는 의미를 가진다고 합니다.
캐릭터도 닌자로 하는등....ㄷㄷ
시애틀에 계시는 분들은 직접 참석하셔도 괜찮을것 같구요.
그렇지 않다면 원격으로 참석도 가능하다고 합니다.
어떻게 진행되는지는 자세히 몰라서 일단 등록만 해놓았습니다.
BugQuash, release your inner Ninja!
등록할때 SDK에 대한 숙달도에 대한 질문이 있는데 I'm a baller 라는 항목이 있네요.
순서상으로는 Expert 위의 내용인데
검색을 해보니 '막나가는 갱스터'정도로 번역이 되던데요. ㅎㅎ
그런 의미는 아니겠죠. 하여간 잘나간다 뭐 그런 의미..
728x90
