GitHub의 issue에서 정보 시스템 작업을 관리하게 되면

최근 겸업 상황이 시작되었다.그때 임무 관리 도구를 만들었는데 순조롭게 진행되고 있어서 그 견해를 남겼다.나는 몇 편의 보도를 쓰고 싶은데, 이번에는 개론적인 이야기다.
또한 이 글은 작업 관리에서 GitHub를 사용한 일련의 글 중 하나입니다.

GitHub의 issue로 정보 시스템을 관리하는 작업이 진전되었습니다. ← 여기

일반 프로젝트 관리 도구로 GitHub 사용

구글 클라우드 기능(Python)을 사용해 봤습니다.

저는 GitHub App을 만들어서 Python에서 API를 두드려 봤습니다.

Google Apps Script에서 Google Cloud Functions의 HTTP 트리거하기

배경

현재 일하고 있는 회사는 개발 업무 외에 정보시스템(이하 정보시스템) 담당도 겸임하고 있다.정보 시스템의 임무는 여러 가지 측면과 관련된다. 그 중에서 반드시 빈번하게 진행해야 하는 것은 각종 서비스의 계좌 발행과 AWS·GCP의 IAM 관리 등이다.이런 임무는 하나하나가 매우 작지만 주요 개발 업무의 틈새에 각양각색의 사람들이 신청할 것이다.
정서스 담당자는 현재 두 사람이다.전임자가 있던 곳은 스스로 분배됐고, 전임자가 멈추면서 또 다른 책임자가 분배됐다.

원시 시스템

원래 시스템은 구글 폼에 의뢰인이 입력하면 그 내용이 구글 폼에 기록되고 메일을 통해 업데이트되었다고 알려준다.여기까지는 구글의 메커니즘을 이용했다.

문제점

자신이 분배되기 전에 전임자 혼자서 정서스의 임무를 수행했기 때문에 이 구조는 개발 시간이 많지 않아도 시스템을 만들 수 있는 좋은 생각이라고 생각합니다.다만, 멤버가 두 사람이 됐기 때문에 누가 그 의뢰를 맡을지 가시화할 필요가 있다고 생각합니다.
또한 메일을 보고 스프레드시트의 해당 부위를 확인하여 Slack에 자신이 책임을 지고 실제 업무를 수행한다고 선언한 후 종료 후 메일과 Slack으로 의뢰자에게 전달하는 등의 운용은 업무 중 손실이 발생하여 매번 집중이 흐트러지기 때문에 점점 힘들어진다.
정순임무는 소박한 것이 많아 성과를 가시화하기 어렵기 때문에 그런 폐쇄적인 운용을 하면 상황에 따라 게으름을 피울 수도 있다.

GitHub issue를 사용하는 이유

따라서 이번에는 GitHub의 issue를 사용하여 작업을 관리하기로 했습니다.GitHub을 사용하는 이유는

메일이나 Slack을 사용하지 않아도 issue에서 의뢰인과 교류할 수 있음

Backlog 또는 Trello의 경우 계정을 새로 만들어야 하지만 GitHub에는 계정이 있습니다.

제품 코드가 GitHub용 전용 저장소

대부분의 의뢰인은 기술자

분배ee를 설정할 수 있기 때문에 누가 일하고 있는지 안다

GitHub의 Project와 함께 사용하면 현재 진행 상황을 파악할 수 있다(다른 일에도 적혀 있다)

Organization 등록자는 저장소를 볼 수 있으므로 시각화 작업

하계

아키텍처

이것은 이번에 공책에 쓴 디자인이다.
실제로 만들어진 것은 다소 다르지만 대략 이런 느낌일 것이다.

구글 테이블에서 입력

구글 Apps Script에 양식 제출 마운트

구글 클라우드 기능의 HTTP 트리거

HTTP 트리거는 단점만 알면 누구나 불을 붙일 수 있기 때문에 token

을 전달한다

확인

OK

Goolge Cloud Functions에서 GitHub의 API 호출

API 인증은 GitHub Apps를 이용하여 개인 계정과 연결되지 않음

GitHub API를 통해 다음 작업을 수행합니다.

issue 제작

issue에 의뢰인과 작업자 분배

표시 issue

프로젝트에 issue 추가

생성된 issue URL

을 반환합니다.

동상

동상

구글 Apps Script를 통해 issue의 URL을 의뢰인과 정보 시계 방향 목록으로 보내기

Google Cloud Functions를 사용하는 이유는 GitHub의 API에서 JWT 인증을 할 때 Google Apps Script에서 키 관리와 설치가 어려울 것 같다는 것입니다.

조작하다

아래 그림처럼 구글 폼이 의뢰되면 Bot이 issue를 만들 것입니다.일설에 따르면 중단 임무가 5분 안에 끝나면 집중이 흐트러지지 않기 때문에 즉시 확인, 대응, 연락, 결산을 해야 한다.물론 손이 비지 않을 때도 있기 때문에 그때 다른 멤버를 청하거나 손이 비었을 때 한다.(24시간 정도 대응 가능하다고 방송)

의뢰자가 메일을 받을 수 있기 때문에 issue가 구축된 것을 파악할 수 있습니다.
issue를 구축하는 동시에 Bot은 issue를 프로젝트의 To do 위에 놓고 작업할 때 작업자가 in progress 로 이동하고 끝난 후에 issue를 닫으면 프로젝트의 기능이 Done 로 자동으로 이동합니다.이렇게 되면 의뢰인과 팀원들은 현재 그 임무의 진행 상황이 어떤지 알 수 있다.
또 매달 제작Done열을 작성하면 그 달에 누가 얼마나 많은 일을 했는지 가시화할 수 있기 때문에 개발 임무를 추정할 때도 정보 시스템 방면의 임무를 고려할 수 있어 추정하기 쉽다.

입사 대응과 같이 위탁을 촉발하지 않는 임무에 대해서는 issue 템플릿에서 대조표를 작성하고 필요할 때 수동으로 issue를 작성하십시오.

결과

아직 시험 운용 중이지만 위에 적힌 문제점이 사라져 업무 효율화를 초래했다고 생각합니다.
돈이 많이 남는 회사나 다른 조직이라면 고기능 서비스의 허가증을 사면 되지만 돈을 쓰지 않아도 습관적으로 사용하는 도구를 조금만 고치면 효율을 높일 수 있기 때문에 우리 같은 작은 회사에겐 좋은 방법이다.
가장 중요한 것은 이런 물건을 만드는 것이 매우 무드가 있다는 것이다.