👣 To List 시각화의 중요성
협업하기 위해선 작업들을 규정하고
어떤 작업들이 서로 의존적인지 확인해야 한다.
그렇기 위해서는 팀원들과 어떤 업무가 있는지
어떤 업무끼리 연관성이 있는지
해당 업무의 진행 상황은 어떤 정도에 있는지를 파악해야 한다.
당연히 간단한 프로젝트에 대해서는 단순히 무엇무엇을 누구누구가 맡아주세요
수준에서 해결이 되고 또 그것이 더 간단하게 끝날 수 있다.
처음에는 To Do List에 대한 당위성에 의심을 하여 사용하지 않는 경우도 발생한다.
성과 평가의 합리성
하지만 프로젝트 도중 추가적으로 작업들이 생겨나고
각자의 처리속도가 다르다면 작업 할당에 합리성이 떨어지고
Team 관계는 극악으로 치닫게 된다. 차후 성과에 대한 평가도 어려워지고
일 잘하는 사람은 일을 더하는데 그에 대한 보상이
적절히 지급되지 않는다는 분위기가 형성되면 능력있는 사람은
의도적으로 자신의 능력을 감추려고 하고 낮은 퍼포먼스를 보이게 된다.
작업 사이의 의존 관계 파악 - 잦은 회의 감소
꼭 성과 평가 면에서만 중요한 것도 아니다.
혼자서 작업을 한다면 작업 사이의 의존 관계를 계산할 필요가 없다.
굳이 DB 스키마를 결정하지 않아도 Controller 코드를 작성할 수 있다.
왜냐하면 도중에 결정해야 하는 사안이 있으면 자유롭게 내가 알아서 정하고
이전의 결과물들에 반영하면 되기 때문이다.
하지만 협업을 한다면 바로 옆에서 작업하는 것이 아니기 때문에 이와 같이
결정해야 하는 사안이 있다면 회의를 거처서 결정해야 하기에
시간적, 에너지적 소모가 다소 큰 편이다.
업무의 중요도, 긴급함의 정도 시각화
세 번째로 업무 사이의 중요도, 긴급함의 정도를 쉽게 파악할 수 있다.
최종 단계까지의 큰 그림을 보지 못한다면 DeadLine이 다가와도
필수 기능을 추가하지 못하는 경우가 빈번하게 발생하는데
만약 부가적인 기능을 개발하다가 주요 기능을 개발하지 못하면
대참사가 일어나게 된다. To Do List를 작성하면 다소 이런 일을 예방할 수 있다.
👣 github KanBan Board를 사용하는 이유
이것을 시각화하는 도구들은 여러 가지가 있겠지만
개발자들은 쉽게 접근할 수 있는 github를 이용해서 업무 진척도를 시각화 할 수 있다.
다소 아쉬운 점은 각 작업 사이의 의존 관계를 표현할 방법이 없다는 점이 있는데
이것을 제외한다면 Pull Request Accept할 때, 자동으로 이슈의 상태를 변화시킬 수 있다는 장점이 있다.
[Pull Request auto issue close]
해당 KanBan Board를 사용하면 자동으로 이슈를 작성하게 된다는 점도 있고
이를 통해 Commit으로는 표현할 수 없던 시각자료, 음성자료 등등을 사용할 수 있다.
👣 KanBan Board 사용하는 방법
우선 KanBan Board는 Git Organization의 기능이므로 이것을 먼저 만들어야 한다.
Free Plan을 선택하고
단체의 이름을 결정하고
Contact Email을 입력하면 생성할 수 있다.
이 후, 초대하고 싶은 팀원을 입력해 합류시키면 Organization 만들기는 끝이 난다.
이 후, 해당 organization 페이지의 상단 탭 중 Projects 탭을 누르면
새로운 프로젝트를 만들 수 있다.
왼쪽 네비게이션 바에서 Board 를 선택하고 Create를 누르면
드디어 KanBan Board를 만들 수 있게 된다.
아래 입력창에 업무 이름을 적으면 초안이 작성되고
해당 초안을 Convert To issue로 이슈로 만들면 기존의 Issue로서 작동한다.
Issue로 바꾸면 해당 업무를 책임질 사람, 해당 업무의 상태 등등을 확인할 수 있다.