협업을 위한 작은 발버둥

협업 방식의 중요성을 깨달았다

우리 회사의 독특한 조직문화

입사 6 개월 차, 이 회사는 굉장히 독특한 조직 문화가 있다. 그것은 바로 아무런 문화가 없어 보인다는 점이다. 흔히들 체계가 없다고 말하는데, 우리 회사는 disorder나 mess의 의미가 아니라 그냥 없다. undefined에요.

초반에는 어떤 체계를 만들어가던지 회사 차원에서 시도라도 했으면 좋겠다.라고 생각했었는데, 지금은 오히려 깨끗한 상태라서 팀원 레벨에서 이러한 시도를 할 수 있으니 다행이라고 생각한다. 그리고 이번 TF팀의 동료 개발자분들도 적극적으로 참여해주었다 :)

불편했던 협업 과정, 특히 파편화된 커뮤니케이션 채널

우리 회사는 구두, 구글 행아웃(업무용 메신저), 각종 문서를 통해 협업한다. 모든 회사가 이 정도 채널들을 쓸 것이다.

문제는 프로젝트에서 다양한 팀의 업무 관계자들이 함께 보는 요구사항, 테스트케이스, 버그리포트조차 파편화되어 관리가 되었다는 점이다. (ㅂㄷㅂㄷ)

이번에 개발팀/타팀과 협업을 진행하면서 느꼈던 불편 사항은 다음과 같다.

• 각 요구사항의 변경이 구두/행아웃/구글문서를 통해 일어나는데, 일부는 구글문서에 반영이 안됨
• 즉, 요구사항 정의서가 항상 최신의 상태를 보장하지 않음
• 각 개인이 인지하고 있는 정보가 어느 순간 불일치하게 됨(모두가 일관되게 바라볼 수 있는 문서가 없음)
• 요구사항 변경 추적의 어려움
• 코드의 변경사항이 어떤 요구사항에 의해, 왜 일어난 것인지 추적이 어려움 (비즈니스 히스토리 파악X)
• 개발 일정 지연 사유가 명확하지 않기 때문에 개발자에게 부담이 됨
• 변경된 요구사항이나 버그리포트 등을 행아웃으로 그때그때 관리하니 개발팀의 유휴와 랙 자원 파악이 안됨

느낀 점 요약

아 그거 어디써있더라? 아 이거 회의때 나온 내용이었나? 어 이거 언제 바뀌었지? 이 문서를 보면 되는건가? 뭐해야했더라?

---

협업을 위한 작은 발버둥

개발팀 내에서 진행되는 프로젝트 중 하나에 참여한 팀원 레벨에서 가능한 업무 방식의 변화를 시도해봤다. 사실 팀원 레벨에서 할 수 있는 시도는 다른 팀의 업무에 영향이 가지 않는 선에서 팀원들끼리의 약속을 만드는 수준이다.

다만 파편화된 커뮤니케이션 채널/문서를 통합하는 것은 타부서(여기서는 기획자)의 동의가 필요했다. 이 부분은 사전에 양해를 구했고, 최대한 타부서(기획자)의 기존 업무 방식에 변화를 주지 않도록 주의했다.

일반적으로 사람들은 좋고 새로운 것 보다는 익숙한 것을 선호한다. 심지어 Jira를 커뮤니케이션 채널로 쓴다는 것이 좋다고 명확하게 검증된 것도 아니다. 우리 팀, 우리 프로젝트, 우리 회사에는 맞지 않을 수도 있다. 지금은 그저 Jira의 커뮤니케이션 채널로 쓰는 것을 검증하고 보완점을 찾고, 장점을 찾는 단계이다.

1. Jira를 이용한 커뮤니케이션 채널 통합

• 요구사항의 최신 보장 및 변경 관리

  1. 요구사항 백로그를 생성하고, 해당 요구사항 충족을 위한 세부 기능은 하위 이슈로 정의

     

     하위 이슈에 진척률과 진행 상황이 표시됨

  2. 하위 이슈의 본문에는 화면 설계서와 최초의 요구사항을 명시

     

  3. 댓글에는 변경된 요구사항 및 협의된 내용을 기재 (문의는 @멘션을 통해 소환)

     

  4. Github와 Jira 연동을 통한 요구사항(비즈니스)과 코드의 연관 맺기

     아래 2.Jira와 Github, 커밋메시지 참고

   

• 테스트케이스와 버그리포트

  1. 기획자는 시나리오별로 백로그 생성하고, 세부 테스트케이스는 하위 이슈로 생성

     

     하위 이슈를 클릭하면 상세 정보 화면으로 이동한다

  2. 테스트케이스에 대한 버그 발생 시, 새로운 버그 백로그를 생성하여 본문에 테스트데이터와 상황을 자세히 설명하고 연관된 테스트케이스와 링크. (담당자를 모를 경우 공란으로 비워두면 개발팀에서 알아서 매핑)

     

     버그 백로그를 생성하여, 연관된 TC와 링크를 건다. 본문에는 테스트한 방식에 대한 자세한 설명과 테스트데이터를 입력한다.

      

• Jira 활용 시도 시 장점

  1. 투명한 업무 현황 공개
  2. 비즈니스 히스토리 파악 용이 (인수인계 및 업무 파악)
  3. 요구사항별 커밋된 소스파악 용이
  4. 변경된 요구사항으로 인한 개발 지연에 대해 부담이 덜해짐
  5. 유휴 자원 및 랙 자원 파악 용이
  6. Jira에서 실시간 업무 현황 파악 가능

• Jira 활용 시도 시 단점

  1. 모두 동의하고 이해하는 업무 방식이 아니라면, 개발팀만 투명하게 혼날 수 있음
  2. 중간 관리자의 기존 리소스 관리 방식의 변화가 필요함
  3. 추가적인 관리 필요
  4. 업무 체계가 잡히기 전 까지 많은 시도와 노력 필요(혼란 야기) ⇒ 그래서 팀원레벨에서만 시도해봄

---

2. Jira와 Github, 커밋메시지

Jira 이슈와 연결될 수 있도록 커밋메시지 혹은 브랜치명에 Jira이슈번호를 기재해야함

JIRA이슈번호 [유형]제목

[예시]
HHP-111 [기능] 퀴즈 | 조회화면 추가
HHP-112 [수정] 퀴즈 | 상세조회 시, 작성자 항목 추가
HHP-113 [버그] 퀴즈 | 상세조회 시, 등록일자가 보이지 않던 현상 수정

• Jira와 Github 연동(Jira 이슈에 Github 커밋내용을 연결할 수 있도록 연동 설정) => https://support.atlassian.com/jira-cloud-administration/docs/integrate-with-github/

• Jira에 Development 설정 => https://support.atlassian.com/jira-software-cloud/docs/reference-issues-in-your-development-work/

• IDEA와 Jira 연동 (이슈번호를 바로 확인할 수 있도록) => https://jojoldu.tistory.com/260

---

3. 코딩 컨벤션

처음에는 코딩 컨벤션에 대한 생각조차 하지 않고, 각자 기능 개발에 급급했다. 어느 덧 한숨 돌리고 서로의 소스를 보니 전혀 읽을 수 없었다. 소스를 천천히 읽고 나서야, 서로 동일한 기능을 다른 방식으로 구현했다는 것을 깨달았다. 코딩 컨벤션이 없으니 개발자마자, 페이지마다, 기능마다 이름조차 제각각이었다. 그래서 최소한의 약속을 정하기 시작했던 게 어느 덧 코딩 컨벤션이라고 이름 부를 수 있게 되었다. 겨우 뼈대만 생긴 상태지만, 개발을 하며 조금씩 살을 붙여가며 보완하는 중이다.

이후에는 다른 팀원의 제안으로 들여쓰기, 세미콜론, 따옴표 등 코드 스타일에 대한 부분을 관리해주는 Prettier 플러그인을 적용하기로 했다. IDEA 마다 혹은 설정마다 스타일이 달라서 코드 정리 시 불필요한 변경사항이 발생했다. 이제 IDEA를 통해 코드 정리를 해도 모든 팀원들이 동일한 코드 포맷을 사용한다.

---

팀원 레벨에서 개발팀으로, 개발팀에서 여러 팀으로 전파되다보면 모든 조직원이 통일된 하나의 커뮤니케이션 채널에서 협업할 수 있는 날이 오지 않을까?

꼭 jira라는 도구가 아니어도 되고, 애자일이든 뭐든 혁신적인 방법론이 아니어도 되니까 회사에 맞는 일관된 협업 방식이 생겼으면 좋겠다.

 

---

연관된 글

팀문화를 위한 작은 발버둥 : prohannah.tistory.com/116

팀문화를 위한 작은 발버둥