업무 프로세스 흐름
전체적인 업무의 흐름은 위와같이 흘러갑니다.
대부분의 조직들이 위와같은 흐름으로 업무를 진행할것입니다. 이 포스팅에서는 각 단계마다 수행되고 있는 일들에 대해서 이야기할 예정입니다.
[기획]
Feature채널
Slack에서 각각의 피쳐채널을 만듭니다. 채널 이름은 ‘ftr-피쳐이름’으로 만들어 줍니다.
Jira에서는 해당 피쳐의 이슈를 만들어줍니다.
저희의경우 기획(FTR), 안드로이드(HDA), 아이폰(HDW), 웹(HDI), 서버(HDS) 각각 프로젝트로 만들어져 있으며 각각의 프로젝트에서 해당 피쳐 이슈를 생성합니다.
또한 Jira에서 제공해주는 Kanban Board를 활용해서 각 이슈들의 현재 상태를 한눈에 살펴볼 수 있습니다.
피쳐 논의
해당 피쳐채널에서 관련된 내용들을 공유하고 논의합니다.
기획서는 PDF, PPT파일로 만들어서 공유하며, 간단한 기획의 피쳐일 경우는 별도의 문서없이 잘 정리된 텍스트만으로도 작업합니다.
기획서는 완전 목업형태가 아닌 어느정도 완성된 디자인이 입혀진 상태의 기획서로 만들어져서 공유됩니다.
추가적으로 클라이언트-서버 개발자끼리, 기획자-디자이너끼리의 논의가 필요하다면 별도의 회의를 갖고 회의내용을 공유합니다.
클라이언트와 서버개발자는 논의를 통해 API 호출/응답 형태와 방식에 대해 논의하거나 필요한 개발사항등을 정의하게 됩니다.
[디자인]
Sketch-Zeplin
디자이너는 스케치로 디자인작업을 한뒤 Zeplin을 이용해 클라이언트 개발자에게 배포합니다.
Zeplin에서 개발자는 각 View의 위치나 크기등 설정해야하는 속성에 대해서 파악할 수 있습니다.
오른쪽에서는 해당 View에 대한 xml코드까지 만들어줍니다.(물론 그대로 다 복사해서 사용하지는 않습니다.)
Colors & Text Styles
Styleguide탭의 Colors & Text Styles을 활용해서 자주쓰이는 color, text style들을 value에 정의해줍니다.
위와 같이 안드로이드에서 Headline, Multi Headline등의 텍스트 스타일을 코드에 정의해놓습니다.
실제 코드에서는 해당 스타일의 이름만 적어주면 되므로 많은 코드 타이핑 필요없이 효율을 향상시킬 수 있습니다.
Components
Components탭에서는 자주쓰는 Style, CustomView를 컴포넌트로 만들어 재사용할 수 있도록 해줍니다.
실제 개발에서는 해당 Component에 맞는 CustomView로 만들어서 재사용합니다.
각 Component를 선택하면 해당 Component가 어디서 사용되고 있는지의 Usage도 확인해볼 수 있습니다.
이 기능은 Zeplin 2.0부터 새로 나온 기능이며 해당버전에서 추가된 다른 유용한 내용도 확인해보시면 도움이 됩니다.
Material Theme Editor Plugin
Material Design을 더 쉽고 빠르게 디자인할 수 있도록 Google에서 스케치용 플러그인을 만들어서 제공합니다.
이 플러그인을 사용해서 전체적인 컨셉을 쉽게 잡고 색상, 기울기, 아웃라인 등 디자이너가 원하는 세세한 부분도 쉽게 변경할 수 있습니다.
더 자세한 소개와 사용방법은 아래 영상을 참고하세요
[개발]
이 포스팅에서 개발적인 관련된 내용은 안드로이드팀의 프로세스가 소개됩니다.
Snippets
각 개발팀에서는 snippet채널을 만들어서 각자의 업무를 공유합니다.
퇴근전에 각자 오늘 완료한 업무와 내일 예정된 업무에 대해서 공유합니다.
이런 스니펫은 관리자가 구성원들을 감시하고 관리한다는 관점보다는 함께일하는 동료들에게 본인의 업무를 공유하고 인지시켜줍니다.
또한 Confluence의 개인문서에 스니펫전용 문서를 만들어두고 각 날짜별 스니펫 히스토리를 작성해둡니다.
이렇게 작성된 스니펫을 통해 본인 스스로를 되돌아보고 다음할일에 대해서 정리할 수 있게됩니다.
물론 이 스니펫을 작성하는데 너무 많은 시간을 낭비하지 않도록 유의해야합니다.(자칫하면 문서를 위한 문서가 될 수 있기 때문)
문서화
Confluence에 개발에 필요한 사용법, 설계, 기타 문서들을 작성하고 관리합니다.
상시적으로 문서를 추가하고 관리하여 별도의 인수인계문서를 작성하지 않고 팀문서를 Wiki처럼 활용될 수 있도록 노력합니다.
Meeting
각각의 팀에서는 Daily/Weekly 미팅을 갖습니다.
Snippet에 작성된 내용을 기반으로 업무와 개발 애로사항등에 대해 이야기하고 비슷한 경험이 있었던 사람들에게 도움을 주거나 받고 서로 영감을 주기도 합니다.
Daily미팅은 같은 클라이언트팀끼리, Weekly미팅은 전체 개발팀이 한자리에 모여서 공유합니다.
Style Guide
개발하면서 제일 어려운것은 이름 짓기, 코드 포맷관리 등 Style Guide에 대한 고민입니다.
안드로이드팀에서는 Style Guide문서를 작성하고 이를 공유하여 이 문서에 기반해서 코드를 작성합니다.
이 문서는 GitHub에 오픈소스로 배포하여 누구나 참고해서 활용할 수 있으며, 필요하다면 추가/수정하여 PR을 올려주시면 검토후 Merge됩니다.
Git Flow
개발은 Git Flow에 기반한 피쳐개발 및 배포를 진행합니다.
각 피쳐별로 branch를 생성하고 GitHub에 Pull Request를 작성한뒤 develop으로 merge합니다.
배포시점에 develop을 base로 release branch를 생성하고 충분히 테스트를 거친뒤 master branch로 최종 merge해주게 됩니다.
Commit
Branch의 이름과 Commit의 이름은 항상 Jira의 이슈번호로 시작합니다.
- Branch: feature/HDA-123-aaa-bbb
- Commit: HDA-123 커밋내용
이러한 이슈번호 관리를 통해서 어떤 코드에 대해서 History를 확인했을때 해당 코드가 어떤 피쳐와 이슈로 인해서 수정되었는지 직접 해당 티켓에 가서 확인할 수 있습니다.
[코드리뷰]
Pull Request
피쳐개발을 완료한뒤 GitHub에 PR을 작성할때는 위와 같은 기본 PR작성 템플릿을 따릅니다.
GitHub Template을 이용하여 .github/ 폴더 경로아래에 기본으로 하고자 하는 내용을 넣어주면 항상 PR을 작성할때 기본으로 템플릿이 적용되도록 할 수 있습니다.
Label
Lebel을 활용하여 각각의 PR마다 효율적으로 상태를 관리하도록 합니다.
- Review Needed: PR을 올렸을때, 피드백을 수정했을때 리뷰어가 리뷰해주어야 하는경우
- Answer Needed: 리뷰어가 리뷰를 완료해서 PR을 올린 담당자가 코드를 수정하거나 답변을 해주어야 하는 경우
- In Review: 리뷰어가 리뷰를 시작했을때
- In QA: 해당 피쳐가 QA중일때
- Merge Needed: 리뷰어가 리뷰를 완료하고 Approve해주어 merge해도 문제가 없을때
- Simple: 간단한 코드수정으로 리뷰어가 빠른시간내에 리뷰할 수 있을경우
각 PR 상태에 맞게 라벨을 관리해주면 PR목록에서 각 PR들이 어떤작업이 필요한지 한눈에 파악할 수 있습니다.
CI(Continuous Integration)
각 PR마다 Jenkins가 자동으로 빌드하고 테스트를 수행합니다.
- 성공: GitHub의 해당 PR의 상태를 pass 처리
- 실패: Slack의 관련 채널로 실패했음을 알림
정적분석(Static Analysis)
SonarQube가 해당 PR내용을 리뷰하여 각 코드에 Comment를 남기고 종합적으로 리뷰결과를 Report해줍니다.
SonarQube는 프로그램을 실제 실행하지않고 코드를 분석합니다.
보통은 PMD, CheckStyle, Findbugs등을 사용하지만 SonarQube에 별도의 PRND way rule을 만들어서 개발팀에서 정한 rule에 맞는 코딩스타일대로 코드를 리뷰합니다.
Merge 조건
PR을 develop으로 Merge하기 위해서는 아래와 같은 조건이 모두 충족되어야 합니다.
- 최소1명의 리뷰어 approved
- Jenkins 빌드 success
- SonarQube 리뷰결과 pass
최종 Merge가 가능한 상태라면 위와같은 화면을 보게 될것입니다.
[QA]
피쳐 테스트
피쳐개발이 완료된뒤 QA 테스트를 하기위해 담당자에게 공유합니다.
테스트 APK파일은 별도의 첨부파일로 전달하지않고 링크로 전달합니다. (Jenkins에서 해당 PR의 QA용 APK파일을 만들어서 다운로드 가능한 형태로 만듭니다.)
QA피드백
QA 테스트를 완료하고나서 오류, 보완점, 수정요청사항등의 여러 피드백에 대해서 작성하고 전달합니다.(Google SpreadSheet 활용)
[배포]
릴리즈 공지
QA테스트까지 완료하고 앱을 배포할때 배포채널에 배포되는 앱에 대한 정보를 공유합니다.
배포되는 버전의 주요 변경사항과 상세한 릴리즈노트, 설치파일경로를 전달합니다.
릴리즈 노트
Jira의 릴리즈 버전관리를 통해 해당버전으로 배포될 모든 이슈목록과 진행상태를 파악할 수 있습니다.
만약 해당버전에서 배포되어야 하는 이슈가 아직 완료되지 않았다면 신속히 처리하도록 하거나 다음버전으로 배포되도록 합니다.
릴리즈
최종 배포까지는 아래의 단계를 거치게 됩니다.
- 릴리즈 테스트: 실제 운영서버를 대상으로 헤이딜러 서비스의 핵심기능이라고 정의한 기능들에 대해서 테스트를 합니다.
- 베타 테스트: 베타사용자(신청자 혹은 사내 직원)를 대상으로 앱을 배포하고 실제 스토어 환경에서 테스트를 합니다.
- 50% 배포: 50% 사용자에게 대상으로 앱을 배포합니다.
- 전체배포: 50% 배포의 오류를 모니터링한 뒤, 문제가 없을경우 전체배포를 진행합니다.
[오류]
오류 모니터링
Firebase의 Crashlytics를 통해 앱에서 발생하는 오류를 상시 모니터링합니다.
앱이 죽는 오류는 아니지만 자체적으로 오류로 의심되는 상황에 Back Log를 남겨 오류이지만 오류가 아닌 오류에 대해서 모니터링 합니다.
오류조치
오류모니터링 도중 심각한 오류가 발생했을경우, 이를 즉각적으로 관련자들에게 알리고 조치합니다.
Hotfix branch를 만들어 문제를 수정하고 배포한뒤, master/develop branch로 각각 merge해줍니다.
[A/B 테스트]
PRND에서는 항상 여러 피쳐, 기능, 텍스트에 대해 가정하고 실험하고 측정해서 더 좋은 결과를 선택할 수 있도록 노력합니다.
A/B 테스트중인 것들에 대해서 회사 모두가 볼 수 있는곳에 현황과 결과를 공유합니다.
성공한 테스트도 있고 실패한 테스트도 있지만, 여러 테스트를 거쳐 왜 잘됐는지, 안됐는지에 대해서 고민하고 연구해서 더 좋은 방향으로 나아갈 수 있도록 노력합니다..
피쳐뿐만 아니라 Store의 소개 이미지, 텍스트들에 대해서도 최적화 실험을 거쳐 더 많은 사용자의 획득과 만족을 시킬 수 있도록 노력합니다.
회고
아직 저희 회사에서는 각 피쳐마다 회고를 하고 있지는 않습니다.
앞으로는 피쳐개발을 종료한뒤, 해당 피쳐의 참여자들이 모여서 좋았던점, 아쉬웠던점, 개선방안등에 대해 회고하는 시간을 가졌으면 합니다.
아래 내용은 스포카의 회고방식입니다.
마치며
이상 헤이딜러 서비스를 운영중인 PRND에서 일하는 프로세스에 대해서 소개해보았습니다.
현재 일하고 계신곳에서 사용하고 있는 업무방식과 비슷한것들도 있고 다른것들도 있을것입니다.
또는 더 좋은 업무방식으로 일하고 계신분들도 계실것입니다.
여러 피드백들을 댓글로 남겨주시고 서로 공유한다면 더 좋은 업무환경을 만들어가는데 서로에게 도움이 될것 같습니다.
감사합니다.
