최대한 활용하는 방법 MotioCI 입증된 관행 지원
MotioCI Cognos Analytics 보고서 작성을 위한 통합 플러그인이 있습니다. 작업 중인 보고서를 잠급니다. 그런 다음 편집 세션이 끝나면 체크인하고 주석을 포함하여 수행한 작업을 기록합니다. 외부 결함 추적 또는 변경 요청 시스템의 티켓에 대한 참조를 주석에 포함할 수 있습니다.
사이의 연결을 설정하는 방법에 대한 추가 세부 정보를 찾을 수 있습니다. MotioCI 및 귀하의 제XNUMX자 발권 시스템 MotioCI 사용 아래의 관리자 안내서 MotioCI 제XNUMX자 발권 시스템을 사용합니다. 키워드(수정, 닫기) 티켓 번호와 함께 티켓을 닫습니다. 또는 다음과 같은 키워드를 사용하여 참조 플러스 티켓 번호는 발권 시스템에 체크인 코멘트를 작성하고 티켓을 열어 둡니다.
Atlassian® JIRA, Microsoft Windows™ Trac 등과 같은 티켓팅 시스템을 사용하면 특정 작업, 문제 및 해결 방법을 추적하여 프로젝트 관리에 도움이 됩니다. 티켓은 작성자 또는 보고서 개발자와 최종 사용자, 테스트 팀 및 기타 이해 관계자 간의 의사 소통 수단을 제공합니다. 티켓팅 시스템은 또한 결함을 추적하고 보고서를 프로덕션으로 승격하기 전에 해결되었는지 확인하는 방법을 제공합니다.
보고서 개발을 위한 일반적인 워크플로
명확히 하자면 통합 MotioCI 발권 시스템을 사용하는 것이 팀이 발권 시스템과 상호 작용하는 유일한 방법은 아닙니다. 일반적으로 첨부된 워크플로 다이어그램에 설명된 대로 Cognos Analytics 환경에서 보고서 개발 프로세스는 다음을 사용합니다. MotioCI 다음과 같을 수 있습니다. 
- 백 로그. 새 티켓이 생성됩니다. 비즈니스 분석가는 새 보고서에 대한 비즈니스 요구 사항을 문서화하고 티켓을 만들어 티켓 시스템에 직접 입력합니다. 그는 티켓을 주문 잔고 (주).
- 개발. 백로그 티켓은 다양한 방식으로 우선 순위를 지정할 수 있지만 궁극적으로 티켓은 보고서 개발자에게 할당되고 그녀의 이름으로 태그가 지정됩니다. 티켓 상태는 다음으로 변경될 수 있습니다. in_dev. 그녀는 새 보고서를 만들 것입니다. 그녀는 Cognos Analytics에서 보고서를 개발할 때 변경 사항을 체크인하고 "새 보고서를 만들었습니다. 초기 버전; 추가된 프롬프트 페이지 및 지원 쿼리, 참조 #592”. 또는 "사실 쿼리 및 교차 분석이 추가되었습니다. 필터 및 서식, 참조 #592.” (안에 MotioCI, 해시태그 번호는 티켓으로 직접 연결되는 하이퍼링크가 됩니다.) 그녀는 보고서를 확인하고 변경한 다음 며칠 동안 여러 번 티켓 참조로 다시 확인할 수 있습니다.
- 개발 완료. 보고서 개발자가 보고서를 완료하고 이를 벤치 테스트한 후, 그녀는 티켓팅 시스템의 티켓에 QA에서 테스트할 준비가 되었고 상태가 다음에서 변경되었음을 기록합니다. in_Dev 에 Ready_for_QA. 이 상태는 플래그입니다. MotioCI 보고서가 테스트를 위해 QA 환경으로 마이그레이션할 준비가 되었음을 알리는 관리자 또는 Cognos 보고서 승격을 담당하는 역할입니다.
- 찬성motion 품질보증. 관리자는 보고서를 승격하고 상태를 다음으로 변경합니다. in_QA. 이 상태를 통해 QA 팀은 보고서를 테스트할 준비가 되었음을 알 수 있습니다.
- 테스트. QA 팀은 비즈니스 요구 사항에 대해 보고서를 테스트합니다. 보고서는 테스트를 통과하거나 실패합니다. 보고서가 QA 테스트에 실패하면 티켓에 데브에서 상태, 수정을 위해 보고서 개발자에게 돌아갑니다.
- 테스트에 성공했습니다. 보고서가 통과되면 QA 팀은 관리자에게 레이블을 지정하여 프로덕션으로 승격할 준비가 되었음을 알립니다. 생산 준비 (주).
- 찬성motion에서 생산으로. 보고서를 생산할 준비가 되면 최종 승인을 받고 출시 일정을 잡을 수 있으며 다른 완성된 보고서와 함께 묶을 수도 있습니다. 관리자는 보고서를 Cognos Production 환경으로 승격합니다. 그는 티켓을 선택한다 개발 및 테스트가 완료되어 프로덕션으로 이동되었음을 나타내는 상태입니다. 이렇게 하면 티켓이 닫힙니다.
보고서 개발 프로세스 관리
이 티켓 관리 프로세스는 다음을 의미하고 입증된 관행에 따라 다음과 같이 지시합니다.
- 모든 새 보고서에는 보고서를 디자인할 비즈니스 요구 사항이 포함된 티켓이 있어야 합니다.
- 모든 결함에는 보고서에 버그나 문제를 기록할 수 있는 티켓이 있어야 합니다.
- 보고서를 수정할 때마다 MotioCI 체크인 설명에는 주소가 지정된 티켓 번호가 포함되어야 합니다.
- 개발자에서 QA로 승격되는 모든 보고서에는 관리자가 개발이 완료되었으며 QA 환경으로 이동할 준비가 되었음을 확인할 수 있는 관련 티켓이 있어야 합니다.
- QA에서 프로덕션으로 승격되는 모든 보고서에는 개발이 완료되고 QA를 통과했으며 필요한 모든 관리 승인을 받았으며 승격되었음을 보여주는 기록이 있는 티켓이 있어야 합니다.
- 프로덕션 환경의 모든 보고서에는 digital 개념에서 테스트, 수정, 해결, 승인 및 프로에 이르기까지 종이 추적motion.
이 마지막 요점은 감사자가 검증하기 좋아하는 것입니다. 그녀는 "프로덕션 환경의 모든 보고서가 문서화된 티켓팅 및 승인 프로세스를 준수했는지 어떻게 확인하는지 보여줄 수 있습니까?"라고 물을 수 있습니다. 감사자에게 응답하는 한 가지 방법은 마이그레이션된 모든 보고서 목록을 제공하고 그녀가 티켓을 살펴보고 귀하의 프로세스와 일치하지 않는 보고서를 찾도록 하는 것입니다.
또는 더 이상적으로는 다음을 수행하는 보고서 목록을 제공할 수 있습니다. 지원 귀하가 정의한 개발 및 발권 절차를 준수하십시오. 바로 이 보고서가 유용할 것입니다. “티켓 없이 프로모션된 보고서". 다음을 포함하는 보고서 목록의 예외 보고서입니다. 지원 모든 보고서 변경 사항이 티켓에 연결되도록 하는 모범 사례 준수. 이것은 비우고 싶은 몇 안 되는 보고서 중 하나입니다. 승격된 모든 보고서에 연결된 티켓이 있는 경우 기록이 없습니다. 즉, 보고서가 프로덕션 환경에 있고 승격된 보고서가 설명의 티켓 번호를 참조하지 않은 경우에만 목록에 표시됩니다. 
혜택이 있는 프로세스
프로세스의 이점은 무엇이며 조직에서 이를 수행해야 하는 이유는 무엇입니까?
- 개선된 팀 협업: 티켓팅 시스템은 실제로 일반적으로 의사 소통하지 않을 수 있는 역할에 개인을 모을 수 있습니다. 예를 들어 보고서 작성자와 최종 사용자 또는 프로젝트 관리자와 QA 팀. 티켓 추적은 개발 중인 보고서인 공유 리소스에 대해 소통할 수 있는 공통 장소를 제공합니다.
- 비용 절감 :
- 결함이 더 빨리 포착되고 수정되면 생산 단계로 넘어가는 것보다 훨씬 저렴합니다.
- 효율성 향상 – 보고서 작성자는 항상 잘 정의된 작업 명세서인 티켓으로 작업합니다.
- 수동 프로세스 자동화를 통한 시간 단축
- 향상된 문서화: 이 프로세스는 결함 및 해결 방법에 대한 자체 문서화 지식 기반이 됩니다.
- 향상된 예측 및 분석: 이제 핵심 성과 지표를 추적하고 서비스 수준 계약과 비교할 수 있습니다. 대부분의 티켓팅 시스템은 이러한 유형의 분석을 제공합니다.
- 개선된 내부 지원: 지원 팀, 다른 보고서 개발자(그리고 미래의 자신까지!)는 과거에 유사한 결함이 어떻게 해결되었는지 조회할 수 있습니다. 이 공유된 지식 기반은 결함의 신속한 해결로 이어질 수 있습니다.
- 최종 사용자 만족도 향상: 티켓팅 시스템을 통해 개발자에게 직접 액세스하여 사용자는 시스템을 통해 요청된 보고서의 진행 상황을 모니터링할 뿐만 아니라 빠른 결함 해결을 기대할 수 있습니다..
결론
이것은 입증된 관행을 따르고 잘 정의된 프로세스를 따르는 것의 가치에 대한 풍부한 보상의 한 예입니다. 나아가, 새로운 MotioCI "티켓 없이 홍보된 보고서" 보고서는 감사자의 질문을 해결하거나 단순히 기업 표준 준수를 위한 내부 모니터링에 큰 도움이 될 수 있습니다.
