[개발 공부 38일차] 프로젝트 발표 완료 | 협업 시스템 정리

 

햐 드디어 News Feed 프로젝트가 끝났다.

14시부터 발표 시작인데 발표 순서 룰렛 돌린 결과, 내가 첫 번째 발표라 기뻤다. 나중에 할수록 순번 기다리면서 지치고 또 다른 팀 발표 내용과 피드백이 머리에 잘 안 들어오기 때문이다. 이번에도 운이 좋았던 나

 

 

< 목차 >

1. 우리 팀 발표 Feedback 내용

2. 프로젝트 관리 및 협업 시스템 개념 정리

   ① 업무분류 체계(Work breakdown structure, WBS)

   ② 업무 분류 체계의 2가지 유형

   ③ 칸반 보드

   ④ 프로젝트 매니저

3. 금일 소감 및 KPT 회고

 

 

 

1. 우리 팀 발표 Feedback 내용

[칭찬]

큰 글자로 설정한 것 좋고, 취소 버튼 클릭 시 내용이 초기화되는 불상사가 발생할 수 있는데 그것을 미연에 방지함으로써 UX적인 측면에서도 좋았다고 하셨다.

 

[피드백]

로그인을 했을 때 Confirm창이 아니라 Alert창이 나와야 하는데 떠야 한다. 그리고 일정량 이상 내용을 작성하면 ...(말줄임표) 처리가 되게끔 하는 게 좋다고 하셨다. 안 그러면 내용의 overflow 현상이 생길 수 있다. 글 작성할 때 영어로 할지, 한글로 할지 일관성을 유지하는 게 좋다고 하셨다. My page에서는 본인 글을 Filtering 할 때, 서버에서 필터링할 수 있는 코드를 알아내서 적용하는 것 추천하셨다.

 

 

 

2. 프로젝트 관리 및 협업 시스템 개념 정리

업무 분류 체계의 3가지 계층

 

 

   ① 업무 분류 체계(Work breakdown structure, WBS)

: 종속 관계를 바탕으로 프로젝트 결과물을 여러 계층으로 나눠, 프로젝트를 시각적으로 분류한 체계

 

기본적으로 업무 분류 체계는 프로젝트 계획을 시각적 형태로 표현한 것이다. 업무 분류 체계의 가장 상단에는 프로젝트 목표가 있고 그 아래에는 종속 관계가 있으며 그 밑에는 하위 종속 관계가 있다. 업무 범위에서부터 시작하는 업무 분류 체계는 결과물이 결과물을 만들어 내는 프로젝트로 이어지는 과정을 보여준다.

 

 

 

 

   ② 업무 분류 체계의 2가지 유형

• 결과물 기반 업무 분류 체계: 업무의 계층 구조를 결과물 지향적인 방식으로 나누는 것. 포괄적인 프로젝트 범위를 살펴보고 이러한 범위를 구성하는 결과물로 업무를 나눈다는 것을 의미한다. 이러한 접근 방식은 연간 수익 보고서를 작성하는 것처럼 명확한 결과가 있는 단기적인 프로젝트에 가장 좋다.
• 단계 기반 업무 분류 체계: 이 방식에서는 일군의 작업을 하나로 묶는 업무 패키지를 만들기 위해 프로젝트 단계를 사용한다. 그런 다음 이러한 작업 그룹을 단계별로 완료한다. 단계 기반 업무 분류 체계는 향후 3년간 고객 유지율을 20%로 끌어올리려는 경우와 같이 결과를 명확하게 정의하기 어려운 장기 프로젝트에 사용하는 것이 좋다.

 

 

 

 

업무 분류 체계는 시각적으로 표시되므로 워크플로 관리 소프트웨어와 프로젝트 관리 프레임워크를 조합하여 만들 수 있다. 이러한 수단에는 타임라인, 칸반 보드, 캘린더가 포함된다.

 

 

 

   ③ 칸반 보드

: 업무 단계를 나타내는 열로 구성된 가상 보드

 

'칸반'은 팀이 수행해야 하는 업무와 각 팀원이 맡을 수 있는 작업량 간에 균형을 맞추는 수단이다. 프로젝트에서 누가 어떤 업무를 수행하고 있는지, 업무가 어떤 단계에 있는지, 모든 업무가 언제 마감되는지 항상 파악할 수 있도록 업무를 쉽게 시각화하는 방법 중 하나!

 

칸반 보드에서 업무는 열로 구성된 프로젝트 보드에 표시된다. 일반적으로 각 열은 업무 단계를 나타내며, 가장 기본적인 칸반 보드에는 할 일, 진행 중, 완료와 같은 열이 있을 수 있다.

 

 

 

 

 

 

   ④ 프로젝트 매니저

: 업무 분류 체계를 사용하여 팀이 복잡한 프로젝트 범위를 분류하고, 프로젝트 및 종속 관계로 연결된 결과물을 시각화할 수 있도록 도우며, 팀원에게 할 일 목록과 대비되는 시각적인 프로젝트 개요를 제공

 

프로젝트를 처음부터 끝까지 관리하는 역할을 담당한다. 여기에는 프로젝트 수명주기 전반에 걸쳐 작업에 대한 계획, 구성, 관리 및 보고가 포함된다. 종종 프로젝트 관리자는 주요 결과물을 생성하기 위해 모두 협력하는 프로젝트 팀을 감독한다. 

 

 

 

[Conference]

https://asana.com/ko/resources/work-breakdown-structure

 

 

 

3. 금일 소감 및 KPT 회고

KPT 회고

[ K eep] 현재 만족하고 있는 부분

S.A.와 와이어프레임을 꼼꼼하게 작성하는 것이 정말 중요하다는 것을 느껴서 이것과 팀원별 프로젝트 관리로, 업무 진척도 보고 및 공유가 앞으로 더 지속되고 발전해야 한다고 생각하였다.이번에 기획과 설계의 중요성과 필요성을 절실히 느꼈고 또 이걸 처음으로 해본 시작 계기가 되어서 매우 만족하고 얻은 게 크다고 느낀다.

 

 

[ P roblem] 불편하게 느끼는 부분

항상 소통 부분이 아쉬운 것 같다. 팀장으로서 늘 팀원들이 답하지 않더라도 주도적으로 원활한 소통 환경을 조성하고 또 저부터가 그러려고 하는데, 만족할 만큼 소통하는 상황이 그려지지 않아서 이것은 추후에 좀 더 생각하고 해결책을 내릴 생각이다.

 

 

[ T ry] Problem에 대한 해결책, 당장 실행 가능한 것

실행 과정 중, 처음에 기획한 API 명세서, 와이어프레임 등 설계가 계속해서 수정되고 바뀌는 이슈가 있었다. 그리고 팀원의 코드를 바로 파악하기 어렵다는 문제가 있었다.

 

전체적인 맥락을 파악하지 못하고 팀원들이 해야 할 역할의 숙지가 매우 미흡했던 것이 원인이었던 것 같다. 앞으로는 ‘큰 그림을 그리고, 볼 줄 아는 능력’을 쌓기 위해 시야와 관점을 넓히는 습관을 가지고 기획과 설계를 할 생각이다. 넓게 봐서 파악 및 이해한 뒤, 점차 구체적으로 파고드는 것이 정말 중요한 것 같다.

 

팀원의 코드를 파악하는 데 시간이 좀 걸린 것은 앞으로 팀 프로젝트 전에 Ground Rules로 정해서 각자 팀원들이 알아보고 이해하기 쉽게끔 주석을 달아두는 것이 필요하겠다 싶었다. 나조차도 코드를 작성할 때 제가 먼저 알아보기 쉽게 주석을 많이 작성하는 편인데 이게 나름 효과가 좋은 것 같다. 그래서 모든 팀원들이 코드에 주석 다는 걸 다음 팀 프로젝트 규칙으로 정하는 게 어떨까 하여 고려 중이다.

 

 

[KPT 회고 참고자료]

https://techblog.woowahan.com/2677/

 

 

금일 소감

휴 굉장히 피곤하다. 다다음 주에도 또 팀 프로젝트 발표가 있어서 쉬지 않고 해나가야 한다. 오늘도 일찍이 쉬러 가시는 분들이 많았는데 난 부족한 공부가 많아서 좀 더 하고 잘 것 같다. 그래도 좀 피곤해서 최대한 빨리 자야지...

 

오늘 처음으로 KPT 회고를 해봤는데 생각보다 좋은 것 같다. 협업에 대한 메타인지가 좀 더 잘 되는 느낌이 들었다. KPT 회고는 앞으로 취업을 한 후에도, 혼자서라도 작성하고 회고하는 습관을 기르는 것이 중요하고 또 필요하겠다 싶었다.

 

다음 React 심화 주차에서는 프로그래밍 구현력을 엄청 끌어올릴 생각이다. 안 보고도 코드 줄줄 칠 수 있게끔 해야겠다. 파이팅!!!!!