Dooray 서비스를 이용한 서비스 개발조직 협업 개선

요즘 일상에서 가장 많이 쓰는 도구는 Dooray 서비스다. 지난 번에 지극히 개인적인 활용을 다룬 글을 올리긴 했지만, 두레이의 일반적인 쓰임새는 개인 작업 관리용이 아니라 협업 도구다. 약 19개월정도 써온 사용자1)로서 두레이를 쓰면서 이 점은 좋으니 널리 알리고 싶다거나 이렇게 써보면 좋겠다고 느낀 내용을 몇 가지를 써본다.
  • 화면 기획서를 공유하며 다자간 협업 이끌어내기
  • 하위 작업을 통해 주 단위 작업 흐름 만들기
  • 태그 그룹을 이용해 개발 단계 표현하기
  • 사용자 스토리User Stroy 작성에 응용하기

화면 기획서를 공유하며 다자간 협업 이끌어내기

파일 첨부 기능을 써서 쉽게 화면 기획 내용을 공유할 수 있다. 아래 그림과 같은 식이다.
presentation
두레이를 이용한 UI 요구사항 전달
중문으로 쓰여진 내용은 '사용자 추가 화면 개선'의 의미인데, 필자의 실제 사례를 공유하기 위해 그대로 차용했을 뿐, 이 글을 이해하기 위해서 중문이나 한자를 알 필요는 없다. 다른 동료중에는 파일 첨부 대신 moqups같은 별도의 UI 기획 협업 도구를 써서 두레이 작업에 링크를 연결하기도 하고, 또 다른 기획자는 화면 덤프를 하고 글을 쓰는 식으로 두레이에 내용을 모두 포함시키는 경우도 있다. 각자 장단이 있으니 선호에 따라 동료들이 다양한 방식으로 쓰고 있다.

협업툴에서도 유효한 CC

필자가 여기서 특히 강조하고 싶은 부분은 메일의 참조와 같은 의미인 CC를 이용해서 다자간 협의를 이끌어내는 방법이다. 위 작업에 첨부한 PDF 파일의 기획서는 필자가 이미 담당 개발자 즉, To에 기록한 사람과 소통하여 그가 수용Accepted Responsibility2)한 내용을 사후에 문서로 기록한 내용이다. 따라서, 구두 전달 사항이 누락될 것을 방지하는 의미로 문서를 쓰긴 했지만, 정작 두레이 작업Task을 만든 중요한 이유는 본문에 기술한 내용이다.
'아래 이유로 다른 분들께서 cc 합니다'라고 설명하고 각 이해관계자별로 그들에게 영향을 줄 수 있는 사항을 요약해서 보냈다. 보냈다고 표현한 이유는 두레이가 협업도구지만, 메일과 흡사하게 쓸 수 있는 점을 강조하려는 표현이다. 메신저를 설치하면 메신저로 통지가 가서 Slack처럼 쓸 수 있지만, 굳이 메신저를 설치하지 않아도 두레이에 내가 등록한 글이나 담당자(to)가 나로 지정되어 있거나 내가 참조(cc)된 글은 메일로 통지가 나간다.

원격으로 자연스레 협업하기

서울에 있던 CTO님이 바로 반응을 한다. 그는 관련 서비스의 시니어 개발자이기도 하다.  두레이 메신저를 이용하니 바로 통지가 온다.
presentation
두레이봇을 이용한 메신저 알림
통지 받은 내용의 답은 휘발성인 메신저보다는 저장소 역할3)을 하는 두레이에 기록한다. 해당 작업 관련한 사람은 아마도 자기가 원하는 형태로 변경 통지를 받거나 댓글을 확인할 것이다.
presentation
원격지 비동기 협업 사례

하위 작업을 통해 주 단위 작업 흐름 만들기

우리 팀은 XP에서 제안한 방식을 따라 개발 주기를 1주로 잡고 있다. 그런데, QA 체계가 갖춰지지 않아 팀별로 개발자와 QA 담당자가 소통하며 개인기에 의존하는 경향이 있다. 운영 릴리즈를 1주단위로 하기 위해 QA 릴리즈 대상부터 주단위로 맞춰보기로 했다. 일종의 버퍼를 만들어서 QA 릴리즈 된 기능에 대해 사용자 도움말이나 소통을 준비하는 기간을 1주 단위로 고정하는 시도다. 이를 위해 아래와 같이 작업을 만든다.
presentation
개발 대상을 뽑는 작업
그리고 아래와 같이 담당 Product Owner 혹은 기획자에게 요청한다.
presentation
주 단위 개발 흐름 만들기 사례
동료 PO가 필자가 출장을 다녀온 사이 하위 작업으로 대상을 추려 두었다.
presentation
하위 작업으로 주별 개발 대상 혹은 백로그 관리하기
그리고 QA 담당자가 해당 항목 중에서 운영에 나가도 좋다고 품질 확인한 항목을 별도 작업으로 등록해주었다. 한 두 주 정도 이렇게 반복하면 개발자도 모두 이러한 절차에 익숙해질 것이라고 믿는다.
presentation
QA를 통과한 운영 배포 목록 선정 작업

태그 그룹을 이용해 개발 단계 표현하기

두레이에서 개발 작업 진척도를 표기하는 방법이 딱히 없어 두만사(두레이를 만드는 사람들)에 물어보니 태그 그룹 기능을 알려줬다. 아래 그림과 같이 태그Tag를 만들 때, 콜론(:)을 넣으면 자동으로 Group으로 태그를 묶어주는 태그 그룹이 생성된다.  우리는 QA: 测试(중국어로 시험)로 쓰면 개발자가 QA 담당자에게 QA 요청을 한 것으로 읽기로 했다. 그리고 QA를 통과하면 작업 상태를 완료Done으로 표기하고, 버그를 발견하면 QA 담당자가 태그 표기를 QA: Bug 로 바꾸기로 했다. 개발자에게 버그가 있으니 다시 고치라고 말하는 것이다.
presentation
태그 그룹을 활용해 QA 절차나 팀을 구분해 표기하는 방법

사용자 스토리User Stroy 작성에 응용하기

사용자가 쓰는 말로 작업 내용을 표현하는데 서투른 동료들에게 자극을 주기 위해 사용자 스토리 도입을 시도했다. 물론, 상황을 봐서 해야 하니 작업대상이 상대적으로 명확한 일에 대해 적용하고, 작업 이름을 스토리 이름을 적었다.
계정추가를 사용자가 할 수 있게 하며, 이메일을 이용한 초대로 수행
그리고 나서 내용을 두레이 작업 본문에 아래와 같이 널리 알려진 작성 형식Template에 따라 쓴다. 그리고 개발자가 할 일 외에 필자가 확인해줄 일을 TODO 형식4)으로 잊지 않도록 추가했다.
presentation
Chris Matts 템플릿을 사용한 스토리 기록
그리고, 스토리 하위작업으로 개발 후속으로 벌어질 일을 연결해둔다. 아래 그림에서 35번은 구두 회의로 진행할 작업이고, 32번은 QA 담당자에게 테스트 시나리오 갱신이 필요한 부분을 알려주려는 목적으로 만든 작업이다. 마지막으로 19번은 배포 환경을 새로 꾸려야 하기 때문에 마찬가지로 관련자에게 알린 것이다. 이러한 통지는 필자의 글 서두에 설명한 '화면 기획서를 공유하며 다자간 협업 이끌어내기'에서 설명한 내용과 같다. 자연스럽게 관계자에게 깨알같은 일상적인 변경이 필요함을 알리는 방송이다.
presentation
스토리 완결과 관련한 일을 두레이 하위 작업으로 생성

주석

1. 스스로 Program Manager에 가까운 일을 한다고 생각하지만, 개발자는 아니고통상 쓰이는 말로 풀면 기획자/관리자에 가깝다.
2. XP 2판에서 주창한 XP를 구성하는 원칙 중에 하나로 소프트웨어 개발은 당사자의 의사와 무관하게 할당한다고 책임을 지울 수는 없다는 내용이다.
3. 통지 기능을 연결해서 사용하다보면 두레이는 일종의 작업 이력에 대한 저장소 역할을 한다.
4. 두레이에서 지원하는 작업내 작업 표시 기능이다. 마크다운Markdown 문법을 활용하여 간단한 점검표 형태로 포함된 작업을 표시하고 확인/관리/추적할 수 있다.