작업일지에 들어가며
프로젝트 2일차에 들어가서 우리 팀은 우리가 구현할 서비스에 필요한 기능들과 화면단에 대해 진득하게 회의를 진행하였다. 우선 필수로 개발해야할 화면단 구성은 이전글에 포스팅하였다.
이제 남은 것은 기능 정의서 작성과 DB 설계, Flow Chart 작성, WBS 작성 등이 남아있다.
이전 일지에서도 계속 말했듯이 개발 시작 전 문서화 작업은 매우 중요한 일이라는 것을 알게되었고,
이전 프로젝트에는 내가 따로 문서화 작업을 진행하지 않아 어쩌면 이번 기회에 조금이라도 진정한 현업 실무에 기반한 프로젝트를 할 수 있어서 꽤나 다행이라고 생각한다.
이번 일지에서는 기능 정의서를 작성하는 과정을 기록해보도록 하겠다.
기능 정의서 작성
💡 기능 정의서란?
고객의 요구사항을 보며, 각각의 기능에 대해 정의를 내리고 개발요건 등을 담은 설명을 통해 어떻게 구현되어야 하는지를 기재한 문서이다.
💡 왜 기능 정의서를 작성해야할까?
기능 정의서는 기획한 기능에 대해 개발자와 소통하기 위함이다. 개발자와 소통을 통해 좋은 서비스를 만들어 내기 위한 방향성을 잡아주는 역할을 한다. 그렇기에 개발을 요청한 고객과의 검증 과정이 아주 효과적일 뿐만 아니라 프로젝트 진행 시 팀원들과의 소통 비용을 낮추는 효과도 있을 것이다.
기능 정의서를 작성하기 전 여러 블로그를 참조했을 때 약간씩만 다르고 거의 비슷한 구조를 지니고 있었다.
그래서 본격적으로 우리 팀의 기능 정의서를 작성하기 전 내 나름대로 기능 정의서를 간단히 한번 만들어보았다.
No : 기능별 No를 작성한다.
기능 코드 : 요구 사항 정의서의 코드를 참조하여 각 기능별로 코드를 적어준다.
기능명 : 각 기능들은 Depth를 나누어 점점 더 상세화하는 방법으로 작성한다.
구현 대상 : 구현 대상에 맞게 Web 또는 App을 적어주면 되겠다. 우리는 웹 페이지 개발을 목적으로하니 Web을 적어주었다.
상세 기능 정의 : 마지막으로는 상세 기능 정의로 우리는 고객이 없지만 사실 우리가 고객의 역할도 대신하고있어 회의때 진행한 내용을 기반으로 상세히 작성하였다.
비고 : 각 기능별로 특이 사항을 적어주면 되겠다.
팀 문서 양식에 기반하여 작성한 기능 정의서 중 일부를 첨부하겠다.
작업일지를 마치며
✨ 나의 생각
이번에 기능 정의서를 처음 작성해보며 느낀 점은
어쩌면 문서화 작업 자체가 프로젝트를 진행하는데에 있어 기능 개발만큼 힘든 일이 아닐까 생각했다.
그렇다고해서 문서화 작업을 건너뛰고 주먹구구식으로 개발을 진행한다면
개발 과정이 매우 힘들어진다는 것을 알기에 대충할 수는 없었고 스스로 생각하기에
그렇게 잘 작성된 것 같진 않지만 최선을 다해 작성했다고 생각한다.
앞으로 실무 경험을 쌓으면서 계속해서 작성해보면 어느샌가 익숙해지지 않을까? 하는 막연한 생각이 든다!
Reference
'Project > Team' 카테고리의 다른 글
프로젝트 작업일지 : 회원가입 (폼 만들기_React Hook Form) (0) | 2024.12.23 |
---|---|
프로젝트 작업일지 : DB 테이블 설계, ERD 작성 (2) | 2024.12.14 |
프로젝트 작업일지 : 화면 정의서 작성 (1) | 2024.12.12 |
프로젝트 작업일지 : 주제 선정 (1) | 2024.12.11 |
프로젝트 작업일지 : 소스 컨벤션 (1) | 2024.12.11 |