일정 및 작업 관리

프로젝트 발표자료 팀원소개란

 이번프로젝트에서는 팀장으로서 팀이 프로젝트를 성공적으로 마무리 할 수 있도록 어떤 순서로 작업을 하고, 인원배분은 또 어떻게 해야할지에 대해서 많은 고민을 했다.

 


공동 작업

 여러명이서 함께하는 팀 프로젝트인 만큼 작업내용을 구체화해서 작업시간과 인원을 배분하면 좋겠다고 생각했고, 이렇게 구체화한 작업들을 관리하기 위해서 칸반보드를 사용해서 현재 프로젝트의 진행상황이 어떤지, 작업 중에 어떤 문제를 마주쳤고 어떻게 해결했는지 확실하게 남기고자 했다.

칸반보드
칸반보드를 통해 관리한 이슈들 목록

 팀 규칙, 주제 선정, 시스템 설계 작성 등 프로젝트 진행에 대해 전체적인 방향성 해결해야할 문제에는 팀원 모두가 함께 머리를 맞대 최대한 빠르게 합리적인 결론을 도출하고자했다. 그리고 아래처럼 토의의 내용과 결과를 issue 탭에 기록해 issue 탭에 기록한 내용을 바탕으로 프로젝트의 다음단계를 진행했다.

시스템 리소스 설계 중 토의내용 일부발췌
업무 분배 및 순서 토의내용 일부발췌

 

 실제 구현파트의 작업분배는 팀원들 각각의 강점을 고려해서 분배했고, 나는 POC로서 각 일정들이 제시간에 마무리 될 수 있도록 각 파트를 오가며 작업상황을 체크하고 작업을 도와서 최대한 빨리 작업을 마무리할 수 있게끔 하는 역할을 맡았다.

 

이땐 알지 못했다..ㅠ 작업파트를 정하지 않았다는 것이 얼마나 많은 노동을 의미하는지...


파트 분배 작업

 각자 파트를 나눠 작업해야하는 구간에서는 각 파트의 진행사항을 확인하고, 작업을 도왔다. 그래서 프론트 부분의 로직과 인프라, 백엔드 부분의 로직과 인프라 작업 모두에 참여했다.

 그리고 진행상황을 최대한 쉽게 파악하기 위해 각 파트에서 해야할 일의 프로세스를 정해서 체크리스트로 만들었다.

이슈 탭 진행상황 체크리스트

물론 작업 중에 이슈를 마주쳤을 때 아래처럼 해당 이슈에 대한 기록도 남겨 내가 어떤문제를 마주했고 어떻게 해결했는지 팀원들도 알 수 있도록 했다.

이슈 기록 중 일부 발췌

 

오류에 대한 해결방법을 보고싶다면 아래 게시글을 확인해주면 된다.

2023.06.20 - [DevOps] - [DevOps] 최종 프로젝트 회고 - 구현(클라우드 리소스)

 

[DevOps] 최종 프로젝트 회고 - 구현(클라우드 리소스)

아키텍처는 이미 앞서 설계 부분에서 소개를 했기 때문에 구현과정 중 트러블 슈팅에 대한 내용을 위주로 작성했다. 트러블 슈팅에 대한 내용을 말하기 전에, 우리 아키텍처가 더 나아지기 위해

dratini.tistory.com

 

Final Project 시작

DevOps부트캠프의 파이널 프로젝트가 시작됐다.

프로젝트의 첫단계인 시나리오 선정과 요구사항 분석, 설계에 대해서 정리했다.

 

시나리오 선정 및 요구사항

팀원들과 의논하는 과정을 거쳐서 우리는 작업 관리 시스템 시나리오를 선택했다. 

시나리오 분석

DDD 설계 

 

 엔지니어님의 조언과 요구사항을 참고해 도메인 이벤트를 붙이고 이후에 액터, 커멘드 포스트잇을 붙여서 프로젝트를 구현할 때 어떤 부분에 대해서 미리 팀원들간의 토의를 해야하는지 파악하고 기록해뒀다. 
 외부시스템은 사용하지 않을 것이기에 제외했고, 에그리거트와 정책으로 도메인들을 분리하고 연결했다.

 

그렇게 사용자의 인증을 담당하는 User Management, 작업을 관리하는 Task Management Service, 그리고 작업과 시스템의 변동사항을 기록하고 변동사항에 알맞는 알림을 보내주는 Log Mornitoring System으로 분리했다.

 

ERD 설계

각 분리된 서비스 별로 사용할 데이터베이스의 기술 스택을 정했다.

 Log Mornitoring System와 User Management 파트에서는 차후 유연성 및 분산환경에서 확장성, 내결함성을 더 잘 지원할 수 있는 NoSQL을 사용하고,

 사용자로부터 가장 많은 요청을 처리해야하는 Task Management Service 파트에서는 MySQL을 사용하기로 결정했다.

 

 ERD를 작성하면서 Task에 반영되는 User 역할을 어떻게 구분할 것인가에 대한 논의를 한 결과 Task에서 Supervisor_email과 PIC_email 속성을 만들어 User table을 참조하도록 만들기로 했다.

 그리고 우린 백엔드 프로젝트를 진행하는 것이 아니기 때문에 Users 테이블에는 인증을 위한 최소한의 데이터만 사용도록 했다.

 

기술 스택

CRUD 문서 작성

 엔지니어께 CRUD 문서를 작성해 실제 구현단계에서의 실수를 방지하는 것이 좋다는 조언을 듣고, 구현할 api의 CRUD 문서를 작성했다. 문서를 팀원들과 정리하며 정말 필요한 기능이 무엇인지 생각해볼 수 있었고, 정말 필요한 기능들이 무엇인지 파악해 CRUD문서를 작성했다. 


요구사항 분석, 설계를 진행하며..

2023.04.05 - [DevOps] - [DevOps] 부트캠프 1차 팀프로젝트 회고

 이전 1차 팀프로젝트를 진행하면서 깨달은 초반 프로젝트 방향성을 확실하게 정리해야한다는 점을 마음에 세기고 도메인 주도 설계, 시나리오 분석을 하는 과정에서 팀원들과 최대한 많은 논의를 거쳐 프로젝트의 구조를 구체화 시키고 그 내용을 팀원들과 나누려고 노력했다.

 그 결과 GitHub에서는 최대한 코드 충돌을 줄이기 위해서 추후 CI/CD를 해야할 부분별로 브랜치를 나눠 Task, Auth, Front, Log 4개 Branch로 나눠 개발을 진행한 후 브랜치를 병합할 때 코드리뷰를 진행해 혹시모를 불상사를 예방하기로 했다.

 그 뒤에 1차적인 코드구현이 끝나고 클라우드 리소스에서 구상한 서비스가 작동하고있는 상태가 되면, 기존 브랜치들을 통합한 뒤에 실제 서비스 제공의 목적을 가진 production 브랜치와 개발되고있는 서비스의 코드가 올라가는 dev브랜치로 분리하기로 했다.

+ Recent posts