[discussion] 기능 명세를 어떻게 정리하시나요?
Closed this issue · 5 comments
토론 주제
기능 명세 정리/정의
토론 내용
특정 기능에 대한 명세를 새로 정리할 때 많은 시간을 할당하는 것 같습니다.
손으로 쓰기도 하고, 다이어그램을 그리기도 하고, 코드를 약간씩 작성해보기도 하면서 전반적인 큰 그림을 파악하여 새로운 기능이 들어갈 적절한 위치와 개념을 고민하는데요.
여러분은 기능 명세를 정의하고 정리하기 위해 어떤 노력을 하시는지, 또 좋은 방법이 있다면 공유도 부탁드리겠습니다.
새로운 기능이 추가될 때 제가 겪은 경우에는 보통 아래와 같이 진행이 됐습니다. (규모가 크지 않은 애플리케이션 제작임을 참고해주세요)
해당 팀에서는 하나의 스프린트를 2주동안 진행했으며, 그렇기 때문에 아래 과정이 2주동안 이루어진다고 생각하시면 됩니다.
- 기획 회의를 개발자와 기획자 다 같이 모여 진행을 합니다. 이 때, 어떤 기능을 추가하면 좋을지와 설계가 가능한지의 얘기가 오고 갑니다.
- 1번에 말한 회의로 공통적인 틀(대략적인 디자인 및 기능)을 정해둔 후, 추가될 기능을 적절하게 구성원들에게 분배합니다.
- 구성원들은 해당 기능에 대한 디자인, 기능 및 api 초안을 각각 figma, notion에 작성합니다.
- 다시 한 번 회의를 진행하여 서로 의견을 주고받습니다. 확정이 되면 github issues에 등록합니다.
- 기능을 개발합니다. 필요에 따라 페어프로그래밍을 진행할 수 있습니다. 만약 이 때, 추가적인 기능이나 다른 부가적인 사항이 필요로 한다면 슬랙으로 얘기하거나 데일리 회의 때 얘기합니다. (데일리 회의는 매일 있습니다.)
- 기능 개발한 PR을 날리고, 팀원들에게 코드리뷰를 부탁합니다.
- PR 머지 순서를 고려하여 머지를 진행합니다.
- 머지가 완료되면 github wiki에 해당 api를 기록합니다. 또한, 해당 팀에서는 api 문서 자동화툴로 Spring REST Docs를 활용하기 때문에 api 문서 작성이 자동으로 이루어져 관련 문서화도 완료됩니다.
요약하자면 아래와 같습니다.
- 초반에 기능 회의를 할 때에는 다같이 머리를 맞대고 손으로 쓰거나 각자 고안해온
figma,notion를 보면서 생각하며 회의. 혼자서 진행할 시 부가적 기능이나 연관관계에 있는 기능들을 고려하지 못하고 놓쳐버릴 수 있기 때문. - 중반에는 코드를 구현하면서 추가적인 이슈가 발생하면
slack으로 리뷰 또는 데일리 회의 때 안건으로 발표 - 후반부에 코드리뷰를 하면서 서로 수정 및 리팩터링 과정을 거침.
- 최종적으로
Spring REST Docs,github wiki에 등록됨.
저는 담당하는 작업에 따라 어느정도까지 고민하고 어떻게 고민할 지가 바뀌었던 것 같습니다.
난이도가 있는 작업이라면
- wiki 에 작업에 관련한 여러 상세 사항들을 정리합니다. - 기존 코드 검토, 개발 방향, 영향 범위 등등
- 팀원들과 1~2시간 정도 회의를 가져 고민한 내용들을 공유하고, 피드백을 받습니다.
(아무래도 팀이 작고, 하나의 큰 테스크에서 작게 쪼개어 가져가다 보니 작업 내용에 대한 공유가 쉽습니다.) - 생각한 시나리오대로 테스트 코드를 작성합니다. (최근 들어 시도해보고 있는데 상당히 효과가 좋습니다.) 테스트 코드를 작성함으로써 해당 클래스에 어떤 메소드만 있으면 될 지, 클래스를 어떻게 쪼개어 테스트할 지를 생각해 볼 수 있어 실제 구현하기가 매우 수월했습니다.
난이도가 적은 운영성이나 백로그 작업이라면 관성대로 구현하거나 테스트코드 정도만 먼저 작성하고 있습니다.
코드 구현 전에 테스트코드를 작성하는게 생각보다 좋았어서 요 부분을 강조드리고 싶네요..!
최근에 새로운 비지니스 과제가 들어와 기획 검토 단계에 있는데 현재 과정을 정리해보았습니다.
(구현 보다는 "기능명세" 과정에 좀 더 집중하여 작성했습니다)
- 팀원들 모두 wiki에 기획측에서 제시한 기능과 과제 상세, 요구사항들을 검토합니다.
- 이후 기획측에서 한 번 해당 위키의 내용으로 구체적인 설명을 하고 그 과정에서 1차로 질답 과정이 발생합니다.
- 2번 회의를 기반으로 현재 저희 팀에서 사용하고 있는 모델 기반으로 어떻게 확장할 수 있을지 고민합니다.
- 팀원 각자가 모두 자신이 이해한 수준에서의 모델을 만들고 서로 공유하는 회의를 합니다 (개발팀 내부)
- 또한 1,2 과정에서 발생한 지식탐구를 기반으로 팀 내에서 UL이 정의되기 시작하는 과정인 것 같습니다.
- 3번 과정에서 어느 정도 1차적인 모델이 나오면 이 과정에서 다시 기획 회의를 통해 이해 수준을 높이고 모델을 정제합니다.
- 이후 해당 모델을 통해 시스템 설계를 시작합니다.
jira 백로그 관련 코멘트를 보고 궁금한 점이 생겨서 추가 코멘트 남겨봅니다! 별도 question 이슈를 만들까 하다가, 해당 이슈의 코멘트를 보고 추가로 얘기하고 싶어진 궁금증이라 여기에 남깁니다.
최근 새로운 프로젝트에 참여하게 됐습니다. 해당 프로젝트에서는 jira, confluence, github을 사용합니다. jira 백로그를 통해 이슈 및 담당자를 할당 후, 브랜치를 해당 백로그 작업명으로 생성하여 github pr을 날립니다. 참고로 저는 이번 프로젝트를 통해 jira를 처음으로 사용해보게 됐습니다. 여기서 궁금한 점은 아래와 같습니다.
- jira 백로그와 github issue를 같이 사용하는 팀이 있을까? github issue와 jira 백로그는 사실상 거의 동일한 것 같은데 둘 다 운영하는 팀이 있을지 궁금해졌습니다.
- 브랜치명을 백로그 작업명으로 자동생성되게 하다보니 브랜치명이 한글로 생성된다. 브랜치명이 한글일 때, 상당히 불편한 점들이 많다. jira 백로그를 영어로 작성하는 팀이 많을지, 브랜치명을 자동생성하지 않는 팀이 많을지 궁금합니다.
Zenhub : Github 에 칸반, 에픽 등을 관리할 수 있는 플러그인. Github 를 JIRA 처럼