운영 작업을 즐겁게 (민첩하게)하는 메커니즘을 생각해 보았습니다.

우선 개발 방법의 특징에 대해 간단히 써 둡니다.

Agile

계획은 개발주기별로 상황에 따라 검토 (스프린트)

스프린트 단위로 사이클을 돌려 개발

스프린트로 구분하여 팀 개발 속도를 알고 되돌아 오는 타이밍을 설정하기 쉽다

워터폴

약속은 요구 사항 정의부터 릴리스까지 모두 처음으로 설정됩니다

.

선행 불투명 한 부분이 있더라도 견적 담당자 및 현장 기술자의 경험을 바탕으로 계획을 세운다

스케줄에서 늦어지면 즉시 알 수 있습니다.

운영을 Agile에서 시도한 소감

· 사용한 도구
- 메신저(HipChat)
- 작업 관리 (JIRA)

※여기에서의 운용 작업은 사내 시스템 관련 프로젝트에서의 운용 예입니다. toC등의 프로젝트에서는 조금 또 달라진다고 생각합니다.
운영 태스크 예
시스템 고장 조사, 기능 확장 견적, 데이터 패치, 데이터 추출, 데이터 일괄 업데이트, 라이브러리 등의 버전 업 등

사전 준비 (작업 발생을 감지 할 수있는 구조 만들기)

사용자가 직접 기표 할 수있는 JIRA (칸방) 만들기

사용자가 Kanban에 기표하면 Hipchat에 알림을 보내도록 설정

다음을 수시로 태스크가 온 타이밍에 실시한다

운영 작업에 완료 날짜 설정

스프린트에 작업 가져 오기

돌발 작업 등이 있어 소화할 수 없는 것 같을 때는, 팀 멤버나 혹은 운용 작업의 완료일을 조정한다.

운영을 왜 Agile?
작업이 적은 동안은 칸방에서의 관리로 충분. 작업량이 많아지면 다음과 같은 문제가 발생한다.

더 이상 관리할 수 없음
작업이 채워지거나 무엇을해야하는지 같은 작업이 있습니다.

운영 담당자의 정신적 부담
태스크가 산만큼 있으면 그 태스크 모두를 소화할 수 있는 생각이 들지 않는다···

상기 문제의 대책으로서, 칸방에서의 관리도 실시하면서, 그것과는 별도로 스프린트 단위에 떨어뜨려 대응해 나가는 것으로, 눈앞의 타겟을 명확하게 할 수 있다
운용 작업은 끝이 보이지 않기 때문에 힘든 일도 있었습니다만,
Agile에서 돌리게 되면 팀 내 동기부여도 올라 효율적으로 작업을 소화할 수 있게 되었습니다. 근본 해결은, 운용이 발생하지 않는 시스템 만들기입니다만, 거기에 향하기 위한 입구로서 이런 방법도 있다고 하는 참고가 되면 좋다고 생각합니다.