코드와 프로젝트 보드가 서로 대화해야 하는 이유

코드를 작성한다면 하루가 아마 이런 식일 것입니다. 프로젝트 관리 도구를 열어 무엇을 해야 하는지 확인합니다. 그다음 GitHub을 열어 실제 작업을 합니다. 브랜치를 만들고, 코드를 작성하고, 커밋을 푸시하고, 풀 리퀘스트를 엽니다. 머지가 되면 프로젝트 도구로 돌아가 태스크를 수동으로 "완료"로 옮깁니다. 이걸 주에 50번 한다고 상상해보세요. 모든 태스크마다 서로에 대해 아무것도 모르는 두 도구 사이를 전환해야 합니다. GitHub 저장소는 프로젝트 마일스톤이 뭔지 모릅니다. 태스크 보드는 어떤 풀 리퀘스트가 어떤 태스크와 연관된지 모릅니다. 여러분이 모든 것을 연결하는 접착제 역할을 하고 있고, 그것은 뇌의 낭비입니다. 이 단절은 단순히 불편한 것이 아닙니다. 실제 맹점을 만들어냅니다. 프로젝트 매니저는 개발자에게 업데이트를 요청하지 않으면 개발 진행 상황을 볼 수 없습니다. 개발자는 태스크 보드와 코드베이스가 다른 이야기를 하기 때문에 우선순위를 놓칩니다. 일들이 틈새로 빠집니다.

모든 팀이 처음에는 수동 방식을 시도합니다. "PR 완료하면 태스크 업데이트해." "커밋 메시지에 이슈 번호 추가해." "머지되면 팀 채팅에 링크 올려." 일주일 정도는 잘 됩니다. 그러다 누군가 보드 업데이트를 잊습니다. 다른 누군가가 GitHub 이슈를 닫았는데 해당 태스크는 여전히 "진행 중"으로 표시됩니다. 프로젝트 매니저가 보드를 확인하고 작업이 실제로 완료됐는데 일정이 뒤처졌다고 생각합니다. 아니면 더 나쁜 경우, 완료되지 않았는데 완료됐다고 생각합니다. 수동 동기화는 완벽한 사람의 행동에 의존하는데, 그것은 절대 확장되지 않습니다. 팀이 클수록 더 빨리 무너집니다. 솔로 개발자도 결국 게을러집니다. 기능을 완성하고 PR을 닫고, 이미 다음 일을 생각하고 있어서 태스크 보드 업데이트를 잊습니다. 인간의 본성입니다.

해결책은 간단합니다. 두 도구를 연결해서 정보를 자동으로 공유하도록 하는 것입니다. GitHub 이슈를 프로젝트 보드와 동기화하면 모든 이슈가 보이는 태스크가 됩니다. 다른 작업들과 함께 칸반 보드에서 볼 수 있습니다. 우선순위를 지정하고, 마감일을 설정하며, 다른 모든 것에 사용하는 동일한 워크플로우로 추적할 수 있습니다. 이는 일부 작업이 외부 기여자로부터 GitHub 이슈로 시작되는 오픈 소스 프로젝트나 팀에 특히 유용합니다. GitHub을 별도로 확인하는 대신 해당 이슈들이 프로젝트 뷰에 나타납니다. 작업 공간을 떠나지 않고 분류하고, 할당하고, 추적할 수 있습니다. 핵심 이점은 가시성입니다. 프로젝트 매니저가 개발팀이 무엇을 작업하는지 보기 위해 Git을 배울 필요가 없습니다. 그냥 보드를 보면 됩니다. 그리고 개발자들은 해야 할 것들의 별도 목록 두 개를 관리할 필요가 없습니다.

마일스톤은 프로젝트 진행 상황을 측정하는 방법입니다. "4월까지 버전 1.0 준비." "이달 말까지 베타 출시." "사용자 테스트 전에 모든 핵심 기능 완료." 하지만 마일스톤 추적과 코드가 별도의 도구에 있으면 추측하는 것입니다. 팀이 마일스톤 달성에 얼마나 가까웠나요? GitHub을 확인하고, 머지된 PR을 세고, 커밋 메시지를 읽고, 그것을 태스크 보드에 정신적으로 매핑해야 합니다. 당연히 명백해야 하는 정보에 대한 많은 수동 작업입니다. 커밋과 풀 리퀘스트가 프로젝트와 동기화되면 실제 그림을 얻습니다. 어떤 태스크에 활발한 개발이 있는지, 어떤 것이 검토 대기 중인 열린 풀 리퀘스트가 있는지, 어떤 것이 머지되어 완료됐는지 볼 수 있습니다. 그것이 아무도 상태 업데이트를 작성하지 않아도 마일스톤 진행 상황에 직접 매핑됩니다. 인디 개발자와 소규모 팀에게 이것은 특히 가치 있습니다. 모든 것을 추적하는 전담 프로젝트 매니저가 없을 것입니다. 여러분이 개발자이자 PM입니다. 자신의 진행 상황 추적 오버헤드를 줄이는 것은 무엇이든 실제 코딩에 돌려받는 시간입니다.

대부분의 팀에서 개발자가 하는 것과 프로젝트 매니저가 보는 것 사이에는 번역 레이어가 있습니다. 개발자들은 브랜치, 커밋, 풀 리퀘스트로 생각합니다. 프로젝트 매니저들은 태스크, 마일스톤, 마감일로 생각합니다. 두 그룹은 종종 다른 도구를 사용하고 같은 작업에 대해 다른 언어로 이야기합니다. GitHub 통합이 그 간극을 닫습니다. 개발자가 커밋을 푸시하면 프로젝트 보드가 반영합니다. 풀 리퀘스트가 열리면 태스크가 업데이트됩니다. 코드가 머지되면 태스크가 앞으로 나아갑니다. 번역이 필요 없습니다. 이 투명성은 모두에게 이익입니다. 개발자들은 상태 업데이트를 작성하는 시간을 덜 씁니다. 프로젝트 매니저들은 실시간 가시성을 얻습니다. 이해관계자들은 미팅을 잡지 않고도 진행 상황을 확인할 수 있습니다. 그리고 전체 팀은 작업에 대해 이야기하는 시간을 줄이고 실제 작업을 하는 시간을 늘립니다. IndieDevBoard는 GitHub 저장소에 연결하고 이슈, 풀 리퀘스트, 커밋을 프로젝트에 직접 동기화합니다. 마일스톤, 메모, 타임라인 바로 옆 태스크 보드에서 모든 것을 볼 수 있습니다. 수동으로 관리해야 할 것이 하나 줄고 그냥 작동하는 것이 하나 더 생깁니다.

이 혜택을 누리기 위해 전체 워크플로우를 재고할 필요는 없습니다. 간단하게 시작하세요. 메인 저장소를 프로젝트에 연결하세요. 이슈가 동기화되도록 하세요. 모든 것이 한 뷰에 있는 느낌이 어떤지 보세요. 거기서부터 다듬을 수 있습니다. 아마 마일스톤에 대해 PR을 추적하기 시작할 것입니다. 아마 태스크 레이블을 사용해 기능 영역별로 GitHub 이슈를 분류할 것입니다. 아마 커밋 가시성이 더 나은 스프린트 리뷰를 작성하는 데 도움이 된다는 것을 깨달을 것입니다. 통합이 여러분과 함께 성장합니다. 목표는 GitHub을 대체하는 것이 아닙니다. 코드베이스와 프로젝트 계획을 두 개의 관련 없는 것으로 취급하는 것을 멈추는 것입니다. 그것들은 같은 작업을 다른 각도에서 본 것입니다. 도구가 이를 반영하면 관리하는 시간을 줄이고 만드는 시간을 늘릴 수 있습니다.