FishEye, Crucible 4.4 버전이 릴리스 되었습니다. 자세한 사항은 FishEye 4.4 릴리스노트 를 참조하십시요..
블로그

블로그

Confluence 6.1.2 버전이 릴리스 되었습니다


Confluence 6.1.2 버전이 릴리스 되었습니다.


Confluence 6.1.2 다운로드 페이지에서 다운로드 하실 수 있으며 자세한 릴리스 노트는 Confluence 6.0 Release Notes 문서를 참조하세요.

 

개요

  • 루프트한자 항공의 사내 및 외부 고객 요구사항 등에 대한 전반적인 프로젝트 관리를 Atlassian JIRA, Confluence, FishEye, Crucible 등을 이용하여 관리
  • 78명의 개발자가 모든 전세계 업무와 관련된 일을 처리
  • 필요한 기능은 마켓플레이스를 통해 구매하여 기능을 확장

 

참고

  • 국내 환경은 아직도 SW 개발 기업 위주로 Atlassian 제품을 구매 사용하고 있습니다.
  • 하지만 해외의 경우 이미 SW 기업 뿐 아니라 내부적으로 SW 를 사용하고 관리하는 모든 회사들이 Atlassian 툴을 도입해 사용하고 있습니다.
  • 국내에서도 SW 개발 뿐 아니란 다른 분야의 회사들도 Atlassian 툴이나 유사한 ALM 툴을 도입해 사용한다면 한층 경쟁력이 강화될 것입니다.
  • 국내 항공사 (대한항공, 아시아나) 는 어떻게 고객요구 혹은 사내 요구 관리를 하는지 궁금하네요.

 

 

APRA|AMCOS 정보

APRA|AMCOS는 작곡가, 작사가, 출판사의 음악 작품이 언제 어디서 재생, 연주, 복제되든지 간에 이들이 보상받을 수 있도록 합니다.

또한, 호주와 뉴질랜드 음악 소비자들이 세계의 음악 곡목에 접근할 수 있도록 지원합니다.

APRA(호주 공연 권리 협회)와 AMCOS (호주 녹음 저작권자 협회)는 별개의 비영리 조직입니다. 하지만 많은 회원이 둘 모두에 속해 있어서 AMCOS는 일상적인 운영을 관리하도록 1997년에 APRA를 관리 업체로 임명했습니다.

 

수신 정보 처리

 

APRA는 회원이 작곡한 노래와 음악 작품의 공연 데이터를 수집합니다.

저는 최근에 솔루션 및 지원 관리자인 Mark Atkins와 함께 수년 자체 제작한 도구를 사용하다가 JIRA 이동한 이유에 대해 이야기를 나누었습니다.

Mark의 새로운 JIRA는 2012년 5월 18일 금요일에 오스트레일리아와 뉴질랜드 전역에서 전체 220명의 직원에게 배포되었습니다.

Mark, 현재 개발 팀에서는 어떤 작업을 진행 중입니까?

 

“대량의 데이터가 들어오면 우리는 그 데이터를 처리하고 돈을 주인, 즉 작곡자에게 분배해야 합니다. 우리의 최대 규모 데이터 피드 중 하나는 iTunes에서 구매가 이루어지는 노래입니다.

이 모든 데이터를 관리하기 위해 우리는 지난 15년 동안 사내에서 자체 시스템을 개발했습니다. 시스템은 타당한 수준으로 복잡하다 보니 시스템에는 자연적으로 추가된 기능, 버그 등 잡다한 것들이 많았습니다.”
그러면 작업을 어떻게 추적하십니까?

 

"즉, JIRA에서는 '문제'라고 표현하는 AR(지원 요청)을 추적하려고 예전에 Lotus Notes 데이터베이스를 개발했습니다.

문제는 해당 도구에서 작업이 조직되는 방식으로는 AR을 잘 찾거나 우선 순위를 정하거나 특정 AR의 상태를 쉽게 추적할 수 없었습니다. 우리와 같은 관리자는 다양한 팀의 작업 부하를 정확하게 이해하기가 매우 어려웠습니다.”

 

그래서 뭔가 조처를 취하기로 결정했고 그래서 JIRA로 전환한 것입니다. 저는 다른 직장에서도 일했었고 Bugzilla 같은 도구도 봤었는데 바로 이전 직장에서 사용하던 게 JIRA였습니다.

 

우리는 여기서도 Confluence를 사용하고 있습니다. JIRA와 Confluence가 잘 연동되는 것을 아니 결정을 내리기가 쉬웠습니다. 우리는 또 개발 팀을 위해서는 Crucible과 FishEye도 검토 중입니다. IT 작업의 3분의 2는 개발자가 대규모 시스템에서 진행하는 일일 텐데, 이러한 개발자와 비즈니스 요구 사항을 충족하기 위해 필요한 변경 작업의 양을 관리하기란 어렵습니다.

 

그래서 JIRA를 도입돼서 이런 부분에서 지원을 해주니 아주 만족스럽고 기쁩니다.

 

 

APRA|AMCOS가 JIRA를 택한 이유는 무엇인가요?

다른 도구나 문제 추적기도 고려해 보셨습니까?

 

“아니요. 안 해봤죠. 저는 제품 선택 프로세스를 담당이었습니다. 전에 JIRA를 사용해 본 적이 있어서 뭐 생각할 것도 없었죠.

JIRA 평가판을 다운로드해서 최신 버전으로 사용해보고 관리자 관점에서 알아보고 나니 확실한 선택이었습니다.

그랬던 거죠. 특히 이미 마음먹고 실행하던 Confluence도 있었기 때문에 더 그랬습니다. 둘 사이의 통합은 아주 훌륭했고 둘 사이에서 문제를 만들 수 있다는 것도 아주 좋았습니다.”

 

“또 한 가지를 말하자면 저는 몇 년 동안 Crucible과 코드 검토를 보아 왔습니다. JIRA ID를 Crucible의 커밋 태그에 넣고 자동으로 링크를 걸게 만들고 JIRA에서 특정 코드와 연관된 소스 코드를 인식하게 만드는 것, 이런 게 환상적인 기능들이죠.

Atlassian 임직원들은 뉴욕 엠파이어 스테이트 빌딩 꼭대기에 올라가서 크게 소리 지를 자격이 있습니다.”

APRA의 개발 작업에 대해 다른 말을 하실 것이 있나요? 애자일 방법을 사용하십니까?

 

“우리는 폭포수보다는 애자일 방법 쪽에 더 기울어 있습니다. 소스 코드 측면에서 FishEye와 Crucible를 통합 중이고 Subversion을 사용 중입니다.

또한 Single Sign-On용으로 Crowd를 사용 중인데 이것도 아주 놀랍더군요. Crowd는 Active Directory의 지원을 받으므로 여기서는 위임된 인증을 사용합니다.

저는 Crowd를 우리가 구축할 미래의 응용프로그램에 인증 도구로 사용할까 생각 중입니다. 이것은 80년대 Single Sign On 때부터 나온 약속과 비슷한데 실제로 잘 작동하는 것 같습니다.”

 

“APRA 비즈니스의 특성은 아주 복잡합니다. 특히 다른 사람들의 돈을 받고 있기 때문에 정확해야만 합니다. 그래서 품질을 강조하고 여러 가지가 적절한 방식으로 수행되도록 검토를 많이 합니다.

아직은 애자일 방법이라고 할 수 없지만 점점 더 애자일 방향으로 나아가고 있습니다.”

 

JIRA에서 관리자의 임무를 맡은 건 어땠습니까?

 

“네, 거의 할 일이 없는 편입니다. 워크플로를 정해서 프로젝트를 구성하고 나니 더 할 일이 없습니다. 아 그리고 이 부분은 설명서 없이 저 혼자 힘으로 사용법을 터득했습니다.

그 정도로 간단합니다. 알아서 돌아가는 거죠. 우리는 백업과 이런저런 비즈니스를 자동화했고 알아서 잘 돌아갑니다. 관리와 관련해서 투입되는 시간은 0에 가깝습니다.

특히 Crowd를 사용한 덕분이죠. 관리 부문에서 사용자 관리가 필요 없어집니다. 정말 큰 이점입니다.”

 

 

보고 및 메트릭

 

저는 Mark에게 현재 처리되는 티켓 양과 팀에서 SLA와 회원들의 기대치를 얼마나 잘 충족하고 있는지 물어보았습니다.

 

“글쎄요, 그쪽 정보도 잘 모르겠네요. 제가 아는 건 기존 시스템에서 JIRA의 뛰어난 가져오기 도구 때문에 현재 이미 1,200개의 티켓을 내보냈고 이 티켓들은 JIRA로 가져와서 새 시스템으로 넘겨질 거라는 것뿐입니다.”

 

“우리가 관심을 갖는 주된 사항은 처리량입니다. 우리가 가진 작업량 때문에 그렇습니다. 우리는 지금 기존 시스템에서 평균적으로 문제가 해결되는 데 소요된 시간 등의 수치도 모르고 있습니다.

JIRA에서 제공하는 시간이나 상태 보고, 그러니까 문제가 여기에 얼마나 오래 있었는지 다른 곳에는 얼마나 있었는지 승인 대기나 동료 검토 대기 등의 자세한 정보는 특히 더 그렇습니다.

 

표면 아래에서 일어나는 일을 확인할 수 있다면 정말 좋겠네요. JIRA는 팀을 위해 리소스를 설정하고 비즈니스에 대한 기대치를 설정하는 데도 도움이 될 수 있습니다.

저는 최종 사용자와의 연락 담당자라서 그들이 훨씬 더 많이 참여하고 최종 사용자의 작업을 수행하는 방법에 대해 더 만족하기를 바랍니다.

 

“JIRA는 매우 유연하기 때문에 분명히 워크플로를 사용자 지정했습니다. 동료 검토, 테스트, 최종 검토 등으로 복잡한 워크플로를 적합하게 만들었습니다.

어디에서 문제가 오래 걸리고 병목 현상이 어디에 있는지 보여주는 JIRA의 상태 내 보고서를 비롯한 이 정도의 관리 및 제어 수준은 이전에는 한 번도 사용해 보지 못하던 정보였습니다. 이제는 동료 검토에서 병목 현상이 있는지 살펴보고 거기에 리소스를 좀 추가하거나 어떤 교육을 하고 우리가 가진 이 대규모 워크로드의 측면에서 회사 내 팀으로부터 최대한의 성과를 끌어낼 수 있다고 생각합니다.”

 

“최근 몇 년 간 일반 비즈니스 담당자들이 불만을 토로하던 것 중 하나는 티켓을 만들어 놓으면 그냥 사라져 버린다는 것입니다.

다른 얘기도 듣지 못하고 티켓을 찾지도 못하고 어떻게 진행되고 있는지 쉽게 알 수도 없었던 것이죠. 이 부분에서 JIRA가 발휘하는 능력은 정말 놀랍습니다. 앞으로도 기대하고 있습니다.”

 

출시

 

Mark의 팀은 몇 년 동안 직접 제작한 추적기를 사용했지만 JIRA로의 데이터 마이그레이션은 간단했습니다.

 

“우리는 CSV 내보내기를 사용했습니다.

 

JIRA의 가져오기 도구에서 우선 순위와 법규 매핑 등은 정말 환상적이어서 모든 것을 정확하게 제가 원하는 방식대로 설정할 수 있었습니다.

 

기한일인 18일이 되면 최종적으로 가져오기를 하고 하루 동안 작업 우선 순위를 다시 매긴 다음 새롭게 시작하기 위해 필요한 사항을 점검할 겁니다. 가져오기 도구는 탁월합니다. 우리는 이전 시스템을 병렬로 실행하지 않고 그냥 꺼버릴 생각입니다. 그래서 데이터를 가져오는 겁니다. 바로 원하는 대로 작업할 수 있도록 말입니다.”

채택 현황은 어떻습니까?

 

“우리는 구현 팀을 합쳐서 작업 중에 시간을 할애해서 우리를 위해 많은 문제를 생성해 달라고 요청했습니다. 우리는 JIRA용으로 기록자 역할, 서명자 역할 등과 같은 어떤 포괄적인 역할을 생성했고 이 역할이 모두 시스템에 액세스하도록 했습니다.

이 역할을 맡은 사람들은 계속 문제 추가 작업을 실험하고 있습니다. 그래서 '아, 이건 또 새로운 거네. 귀찮은데.'하는 느낌을 극복한 다음부터는 모두가 거의 전반적으로 마음에 들어 했고 앞으로 사용하기를 기대하고 있습니다."

업데이트: 최종 마이그레이션을 완수한 다음에 Mark가 보낸 이메일이 이번 주에 도착했습니다.

 

“최종 데이터 가져오기는 원활하게 잘 되었으며 거기 나온 것들을 보고 깜짝 놀랐습니다. 이미 JIRA 대시보드에는 다양한 정보가 나와 있었죠.

다양한 개발자의 워크로드부터 시작해서 티켓을 가장 많이 생성하는 부서, 문제 유형, 문제가 얼마나 오래 되었는지(붉게 표시) 같은 정보가 보였습니다.

할당 작업을 수행하고 우선 순위를 설정함에 따라 이메일이 이리저리 날아옵니다. 사용자 불만 사항 중 하나는 커뮤니케이션 부족이었는데 지금은 확실하게 해결되었습니다!”

 

 

왜 JIRA를 택하셨습니까?

 

기존 버그 추적기에서 JIRA로 전환한 경우 이유를 말해주시면 도움이 됩니다. JIRA를 선택한 가장 큰 이유를 트위터로 알려주세요.

 

[이것이] 내가 [내 이전 버그 추적기]를 버리고 JIRA를 선택한 이유 - http://atlss.in/GoJIRA

 

 

설립: 1827년
본부: 캐나다 토론토
직원: 교수 및 관리 직원 6,882명
제품: Confluence

 

토론토 대학의 교육학 교수인 Jim Slotta는 대학에서 사용하는 Confluence가 얼마나 유용한지 칭찬하기 위해 Atlassian에 연락을 취했습니다. 
그는 “우리는 연구의 전 분야에서 이 제품을 사용합니다. 자료 설계, 기록 보관, 기술 개발, 인가 작성 지원, 파트너십 관리부터 시작해서 실질적으로 K12나 대학생들을 한 곳으로 집결시켜 콘텐츠를 모으는 것까지 모두에 사용합니다.”라고 말했습니다.
 
우리의 wiki 소프트웨어에 그런 열정적인 반응을 보고는 이런 기회를 그냥 흘려 보낼 수 없었습니다. 저는 연락을 취해서 최대한 빠른 시기로 인터뷰 일정을 잡았습니다.
 
Jim과 대학 연구에 대해 이야기를 나누면서 토론토 대학이 1827년 상부 캐나다의 고등 교육을 위해 설립된 최초의 기관이라는 사실이 흥미로웠습니다. 
대학은 원래 영국 국교회의 관리하에 있었고 특성과 역사가 다르고 자율성을 유지하는 12개의 단과 대학으로 구성되어 있습니다. 
Jim은 음악, 예술, 인문, 과학, 공학, 법률을 비롯한 많은 분야의 연구에 대해 토론토 대학만큼의 기량을 가진 대학이 많지 않다고 귀띔했습니다.
 
JIm은 교육 및 기술 부문에서 캐나다 연구 위원회 소속으로 연구비를 받고 있습니다. 그는 다수의 프로젝트와 많은 수의 박사 과정 학생들을 관리할 것으로 기대를 모으고 있으며 토론토 대학의 연구 역량을 대표하는 국제적인 예이기도 합니다. 
CRC(캐나다 연구 위원회)는 10년 전 캐나다에서 시작한 프로그램입니다. 
캐나다는 이 프로그램에 200억 달러를 투입했고 Jim에 따르면 이 프로그램은 진정한 성과를 거두었다고 합니다. 
Jim의 위원회는 연구비로 기술 분야에서 6~8개의 프로젝트를 운영했었습니다. 
무엇보다도 그는 K12 교육 분야에서 wiki의 가능성을 주시했습니다. 교실을 가득 메운 어린이들이 창의적이고 의미 있는 콘텐츠를 공동 작업을 통해 만들고 그런 콘텐츠를 학습에 사용할 방법을 모색했습니다.

 

Confluence는 어떻게 알게 되었습니까?

2002년으로 거슬러 올라가서 처음에는 연구 활동을 조정하기 위해 wiki가 필요했습니다. 그때 처음으로 Confluence를 접했습니다. 
저는 당시 캘리포니아 대학교 버클리 캠퍼스에 있었고 교육 및 기술 관련 연구 프로젝트를 공동 지휘하고 있었습니다. 
제가 속한 팀은 오래된 웹 기반 조사 환경을 대체할 새로운 Java 플랫폼을 개발하고 있었습니다. 
이 개발 작업에는 많은 양의 Java 코딩, 많은 수의 문제 추적, 프로젝트 관리, 전 세계적인 공동 작업이 필요한 것으로 판단되었습니다. 
우리는 이때 당시 새로 등장한 wiki가 아이디어와 설계를 수집하고 조정하는 데 유용할 것이라고 바로 느꼈습니다.
 
우리는 MediaWiki, TWiki 등 당시 사용 가능하던 모든 wiki 옵션을 평가했습니다. 하도 오래 전 일이어서 전부 기억나지는 않네요. 
그 결과 Confluence가 우리에게 가장 잘 맞는다고 생각했고 9년이 지난 지금까지 아주 만족스러운 고객으로서 사용하고 있습니다. 
하지만 학습 및 교육용 웹 2.0 연구의 일부분으로, 수업에서 wiki가 할 수 있는 능력을 파악하게 된 것은 최근 3~4년의 일입니다. 
새로운 형태의 교육은 wiki를 통해 가능하며 지식에 대한 공동 작업 편집 및 유지 관리를 통해서 할 수 있습니다.

 

 

이 양식의 메타 데이터 집합 및 작성 권한이 수반된 Confluence 페이지를 작성하는 스크립트
 ("제출" 시 시작됨)가 포함된 Ruby on Rails 기반의 웹 페이지

 

 

토론토 대학에서 엔터프라이즈 wiki가 어떻게 사용되었습니까?

버클리를 떠난 다음 저는 토론토에서 바로 Confluence를 설치했고 몇 개의 wiki 프로젝트를 진행하게 되었습니다. 
저는 Confluence를 응용프로그램으로 사용하는 ENCORE(Educational Network and Community for Open Resource Exchange)를 시작했습니다. 
저는 코딩 담당자 중 한 명에게 Confluence용 Ruby-on-Rails 프런트 엔드를 구축하도록 지시하여 템플릿 프로세스를 자동화했습니다. 그리고 Confluence를 기반으로 전체 온라인 커뮤니티를 만들었습니다. 
그러자 제 학생 중 일부가 저 Ruby 양식 기능과 Confluence로 박사 과정 연구를 진행하기 시작했습니다. 그 결과는 대성공이었습니다. 3개의 박사 논문과 몇 개의 아주 훌륭한 교육 과정과 이론적 아이디어가 여기에서 탄생했습니다.

 

Confluence를 선택한 이유는 무엇이었습니까?

 

저는 공간의 그룹화와 권한 설정 그리고 오픈 소스에 대한 Atlassian의 지원이 가장 큰 이유였다고 생각합니다. 
오픈 소스에 대한 지원은 우리도 줄곧 강력하게 지지하던 것이라 우리의 철학적인 방향과도 잘 맞았습니다. 기능도 훌륭합니다. 
이건 무료로 엔터프라이즈급 소프트웨어를 얻을 수 있는 기회였습니다. 우리는 오픈 소스 교육 프로젝트를 진행하는 거니까요. 
어떻든 간에 버클리와 토론토 모두에 딱 들어맞았습니다. 버클리에서도 지금 거의 10년째 Confluence wiki를 사용 중입니다.
 

우리의 공동 작업 소프트웨어는 어떻게 사용하십니까?

 
우리가 wiki를 사용하는 방법에는 몇 가지가 있습니다. 교수로서 제가 사용하는 방식은 지식 구축을 위한 구조를 만드는 것입니다. 온톨로지 같은 것으로 생각하면 됩니다. 
가령 저는 시간이 지나면서 저나 제 팀원들이 채워나갈 공간을 만듭니다. 그리고 안에 아이디어를 채울 상자와 휴지통을 만듭니다. 
여기에서 구조를 확장하고 콘텐츠를 반영하고 재 반영하며 개선하거나 시간이 경과함에 따라 교체할 수도 있습니다. 예를 들어, 현재 SAIL Smart Space라는 오픈 소스 스마트 교실을 구축 중에 있습니다. 
이것은 다양한 기술적, 교육적 차원을 포함하는 복잡한 소프트웨어 프레임워크인 기술 인프라입니다. 여기에는 XMPP 네트워크, 지능형 에이전트 프레임워크, 온갖 종류의 장치와 디스플레이 패러다임이 들어갑니다. 
그래서 그룹의 이 프로젝트 전체에 대한 생각을 발전시키고 지원하기 위해 SAIL Smart Space의 사양, 사용 사례, 모형 등의 정보를 가지고 있는 다른 페이지에 대한 링크가 포함된 마스터 wiki 페이지를 작성하려고 합니다. 
일종의 설계 모드로 사용 중이지만 지식 캡처 모드로 사용하기도 합니다. 그래서 모든 관련 프로젝트, 리소스, 무작위 아이디어와 미결 질문을 모두 추적합니다. 
최종적으로 제 목표는 해당 페이지(또는 공간)가 진화해 나가는 그룹 지식과 연구자로서 제 개인적 지식을 표현하게 하는 것입니다. 이렇게 wiki는 제 작업의 지식 캡처 공간이며 제 그룹에서 지식을 한데 모아두는 공간입니다.
 
이런 지식을 활용하는 연구나 설계 작업을 수행해야 한다면 Confluence와 같은 지식 관리 소프트웨어를 통해 작업자가 헤매지 않게 해주고 다른 사람도 구축할 수 있도록 확실히 보이게 합니다. 
제 학생들은 이 점을 알고 여기의 지식을 사용하여 자신의 논문 작업을 하고 자신의 말 속에서 활용하고 지식을 여기에 더 축적합니다. 그야말로 지식 구축 커뮤니티인 셈입니다. 그것이 wiki와 관련한 저의 역할입니다. 
이런 페이지나 공간을 구축하고 구조적인 컨테이너로 나타내는 것입니다.
 
저는 또한 Confluence를 사용하여 수많은 워크숍과 행사를 조직하고 조정했습니다. 제가 하는 업무에서는 결국 워크숍과 회의를 조직하고 운영하는 일이 반드시 포함되는데 Confluence가 그 점에 있어서는 정말 환상적입니다. 
특히 도와줄 수 있는 학생들이 있다면 아주 훌륭합니다. 세부 정보, 참여자, 회의실 준비 등을 우리 모두가 파악할 수 있는 공통의 장소가 필요합니다. 
저는 아마도 지난 10년에 걸쳐 다양한 규모로 20~30개 워크숍을 운영했는데 모두 Confluence를 사용했습니다.

 

 

학생들도 Confluence를 같은 방식으로 사용합니까?

 

학생들은 종종 스마트 교실 물리학 프로젝트와 같은 프로젝트 지도에 참여하게 됩니다. 그러면 교사와 과학 기술 전문가와 긴밀하게 협력하여 작업하고 규격, 도면 및 기타 기술을 실제로 다뤄야 합니다. 
그러기 위해서 Google Docs와 SketchUp을 사용하는데 wiki 페이지를 사용해서 이런 요소들에 링크를 연결합니다. 
이런 경우에 학생들은 보통 wiki를 사용하여 연구실의 지식 기반에 다시 연결되도록 만듭니다. 공동 작업 소프트웨어는 일종의 구조 페이지가 됩니다. 
우리는 이것을 '너저분한 공간'과 '깨끗한 공간'이라고 부릅니다 wiki가 너무 어수선하면 사람들이 아무것도 찾을 수 없으므로 wiki는 대체로 깨끗한 공간인 편입니다. 
즉, 우리는 Google Docs를 너저분한 공간으로 사용합니다. 
정보를 정리한 후에 그것을 Confluence는 여태 본 것 중 최고입니다.
 
wiki로 이동하고 거기에서도 계속해서 작업을 이어갑니다. 계속 진화하는 프로세스죠! 신기술은 언제나 왔다가 가곤 합니다. 학생들은 Confluence를 실제로 활용하는 연구 설계 공간이자 모든 리소스를 추적하는 공간으로 사용합니다.
 
어떤 학생들은 Confluence를 연구 기술 환경으로 사용해서 실제로 100명의 고1 학생을 모은 다음 6주 간의 기간에 걸쳐 온타리오 지역의 생물 다양성에 대해 wiki를 공동으로 채우게 했습니다. 
그래서 그 자체로 설계 작업에 대한 큰 화제가 되었던 대규모 교육 활동이 있을 예정입니다. 해당 페이지의 템플릿은 무엇입니까? 
그 페이지에서 어떻게 그룹화합니까? 재그룹화는 어떻게 합니까? 해당 페이지의 콘텐츠에 대한 색인을 사용하는 그룹 내 프로젝트는 어떻게 구축합니까? Confluence가 교육 연구의 매개체가 되었던 연구가 몇몇 있었습니다. 
하지만 아마도 2/3에 해당하는 시간 동안 Confluence는 더 하이테크 매개체에서 진행될 작업을 설계한 공간으로 사용되었습니다.

 

사용법, 리소스, 정책 등을 관리하는  사용된 ENCORE Lab 관리

 

다른 부서나 학과에서도 wiki 적용해 보셨습니까? 

 

제 Confluence 인스턴스에서 공간을 내주었습니다. 예를 들어, 저는 토론토 대학에서 간호 교육의 혁신 및 우수성 센터(Center for Innovation and Excellence in Nursing Education)에 공간을 만들어 주었습니다. 
제 강의를 듣는 학생 중에 간호학을 공부하는 학생들이 있었는데 그 학생들이 그 공간을 꽤 사용했다고 생각합니다. 
저는 또 공중 보건 분야의 연구를 수행하는 동료가 있고 wiki가 그들에게 정말 도움이 될 수 있다라고 생각해서 글로벌 보건 연구의 공동 작업 프로그램을 위한 공간도 만들었습니다. 
또 하나는 해양 과학 교육 연구인데 제 동료 하나와 그의 학생들을 위해 wiki 공간을 만들어 주었습니다. 이것이 제 연구실인 ENCORE가 수행하는 일 중 하나입니다.
그래서 약 50개 정도의 wiki 공간이 있고 그 중 10~15개 정도가 다른 그룹에서 적극적으로 사용합니다. 하지만 저나 제 그룹이 사용하는 정도는 아닙니다.
 

교수님이나 학생들이 Confluence를 사용해 본 느낌이 어떻습니까?

 

Confluence가 없다면 아주 아쉬울 겁니다. 우리 연구실에는 Drupal 사이트가 있는데 우리가 계속 업데이트하고 있는 공용 웹 페이지입니다. 
그러나 지식을 확장시키고 사람들에게 액세스하도록 하며 페이지를 신속하게 만들거나 해당 페이지를 반영하고 다시 반영하는 편의성을 생각해보면 모두가 wiki에 만족하고 있습니다.
wiki는 우리가 사용하는 설계와 관리 기술을 전체 '원 그래프'로 표현해서 봤을 때 안정적인 한 부분을 차지하고 있습니다. 
이 지식 공간은 공동 작업의 결과이자 지속적이고 활발한 표현 방식이라고 우리 그룹에서는 생각하고 있습니다. 전에 왔던 사람들과 그 뒤에 오는 사람들 모두를 위해 우리가 남겨둘 아이디어와 결과물의 표현입니다. 
이것은 그룹의 "지식 기반"이고 "지식 커뮤니티"와 관련하여 우리가 작업하는 이론적 공간의 일부라고 느낍니다.
Confluence를 갖고 있는 상태에서는 사용을 그만두기가 어려워집니다. 예를 들어 지난 2일 동안 30페이지가 업데이트된 것을 보았습니다. 그러니까 아주 활발하게 사용되고 있다는 것이죠.

 

새로운 학생들은 Confluence에 어떻게 적응시킵니까?

 

일 년에 학생을 몇 명만 받기 때문에 자주 있는 일은 아니지만 새로운 사람들이 연구실에 들어오긴 하죠. 올해 4~5명 들어왔습니다. 같이 일하는 사람들은 기술 능력이 좋은 사람들입니다. 
그냥 wiki를 알려주고 계정을 만들게 합니다. 아주 마음에 들어 하더군요. 아니면 적어도 만족하는 편이라고 말할 수 있겠죠. 간단하거든요. 페이지를 곧바로 만들 수 있습니다. 연구실의 일부이고 그래서 그룹을 운영하는 방법이기도 합니다.

 

예상치 못한 방식으로 Confluence를 사용하는 사람들이 있습니까?

 

학생 중 한 명은 개인 공간에 3,500페이지에 달하는 내용을 올려서 좀 놀랐습니다. 흥미롭더군요!

 

엔터프라이즈 wiki를 사용해서 얻은 결과를 수치화할 수 있습니까?

 

wiki가 없었으면 지난 6년 동안 했던 일들을 절대로 할 수 없었을 겁니다. 다른 wiki 제품을 가지고 더 잘했거나 더 못했을 거다라고 말하기는 어렵지만 wiki가 없었다면 결과가 더 안 좋았을 겁니다. 
Confluence는 아주 믿음직했습니다. 저한테는 그룹 권한과 공간, 템플릿을 다룰 수 있는 기능이 가장 중요합니다. 
새 사용자를 그룹으로 데려와 필요한 권한을 부여하는 작업에 대한 편의성이 수년 간 저에게 가장 중요한 기능이었습니다. 페이지 작성과 조직, 반영 및 재반영의 유연성과 신속함이 중요했죠. 그게 작업 수행에 도움이 되는 빌딩 블록 패러다임입니다.

 

Confluence를 고려하는 다른 대학에 조언하실 말이 있습니까?

 

어려운 질문이네요. 저에게는 아주 밀접한 도구라서요. 제 그룹은 그룹 자체의 성장과 이 지식 리소스가 매우 긴밀하게 연결되어 있습니다. 
만일 생산적인 디지털 활동과 생산성을 싹트게 할 수 있는 도구를 선택해서 설치하는 일을 맡게 된 관리자라면 말이죠, 
도구의 사용법, 사용자 계정 관리, 템플릿과 공간 만들기 등에 대한 오버헤드를 줄이고 아주 훌륭한 wiki를 만드는 일에 관해서는 Confluence가 지금껏 제가 본 것 중에 최고라고 말씀 드리겠습니다.


감사합니다, Jim! 

여기 블로그의 독자 분들은 이미 잘 아시겠지만 Atlassian은 많은 동영상을 제작하고 있습니다!

우리의 YouTube 채널은 모든 회사 이벤트와 제품 릴리스가 나올 때마다 규모가 커지고 있는데, 화면 캡처 스타일의 제품 데모에 사용하는 도구가 바로 Telestream이 만든 Screenflow입니다.

Screenflow는 정말 훌륭하죠. 근데 최근에 Telestream에서 사례 연구에 참여하겠다고 요청했습니다.

Telestream도 Atlassian의 고객이라서 어떻게 보답을 할까 자문한 결과, Telestream 사례 연구를 진행하기로 했습니다!

최근에 저는 Telestream QA 팀장인 Reuben Cohn과 엔지니어링 팀장인 Silas Brown과 이야기를 나누며 Telestream에서 JIRA와 FishEye를 사용하여 QA 응답 시간을 줄이고 개발을 조직의 다른 부문에 연결한 방법에 대해 자세히 알아보았습니다.

Telestream 소개

 

Telestream은 비디오 콘텐츠를 생성, 배포 또는 시청하는 방법에 상관없이 모든 청중에게 비디오 콘텐츠를 보여주는 제품 전문 업체입니다. Silas는 최대 규모 엔지니어링 팀을 이끌고 있고 Reuben은 Episode 제품의 QA 팀을 이끕니다.

“저는 사실 제품을 회사 제품의 품질뿐만이 아니라 프로세스, 테스트 패키지, 절차의 품질도 측정하는 도구로 보고 있습니다. 사람들과 논쟁하거나 직접 말하지 않고도 경영진이 해당 정보를 얻고 높은 수준의 관점에서 많은 정보를 있습니다. 직원들이 계속 작업할 있고 관리단에서는 실제 작업을 방해하지 않으면서 직원이 작업하고 있는 것을 확인할 있습니다.


발단

 

몇 년 전 Telestream은 TestTrack을 사용하고 있었습니다. 하지만 엔지니어링 팀은 이 도구가 제한이 많다고 느꼈습니다.

도구를 확장하고 유지 관리하기 어려웠고 사용하기가 '어렵게' 느껴졌습니다. 그리고 유연성이 부족해서 유연성이 최고 우선 순위로 올라갔습니다. 기존 도구 집합은 회사로서 성장하는 것을 굉장히 어렵게 만들고 있었습니다.

 

Reuben: “저는 Excel 스프레드시트, 액세스 데이터베이스를 사용하는 QA 부문에서 근무해왔습니다. 저는 열려 있는 버그 몇 개 이외에는 백 엔드로부터 어떤 정보도 얻기가 어려운 시스템을 보았습니다. JIRA 없이는 작업을 수행하기가 매우 어려울 겁니다. 다른 도구로는 특정 문제의 상태를 관리하거나 작업을 할당하기가 훨씬 어렵습니다.”

 

수정

 

Silas는 원래 이전에 사용하던 몇 가지 도구를 교체하기 위해 JIRA를 도입했습니다.

몇 가지 문제 추적기를 평가하는 동안 그가 시험해 본 것은 각 후보에 ‘이게 되면 좋겠네'라고 물으며 기능을 조사하는 것이었는데 Silas 매번 그런 생각이 때마다 JIRA 그것을 해낸다는 것을 발견했습니다.

유연성, 성장 잠재성, 저장된 정보의 풍부함이 모두 중요한 요인이었습니다. Silas는 '지원이 잘 되고 상업용이지만 가격이 적당한' 제품을 찾고 있었는데 JIRA가 가장 적합했습니다.

JIRA를 보완하는 다른 Atlassian 제품을 추가하는 작업은 그의 개발자들에게 수월한 작업이었습니다.

Silas는 처음에는 JIRA와 FishEye로 Telestream을 시작했고 최근에는 헬프데스크 백로그 관리용으로 JIRA Agile (구 GreenHopper)를 추가했습니다. Reuben는 매일 JIRA를 사용하고 있고 QA 팀은 FishEye 통합을 일종의 '버그 수정 탐색기'로 즐겨 사용합니다.:

 

Reuben: “링크 기능이 참 멋집니다. 해결되어야 하는데 해결되지 않은 버그가 있으면 FishEye 보기로 가서 코드에서 변경된 부분이 무엇인지 실제로 확인할 수 있습니다.

체크인이 제대로 되지 않았거나 뭔가 잘못 수행되었음을 알 수도 있겠죠. 실제로 누가 수정을 하려 했는지 알 수 있어서 담당 엔지니어에게 직접 이메일을 보내서 수정 사항의 이유나 목적에 대해서 질문할 수 있습니다.

저는 실제 코드 자체를 보고 무슨 일이 발생했는지 확인할 수 있다는 것이 아주 훌륭하다고 생각합니다.

왜냐하면 어떤 때는 엔지니어가 '버그를 수정했다'고 말하고 뭘 어떻게 수정했는지 얘기하지 않을 수도 있으니까요.

그런 다음 다시 그 문제로 돌아가서 어떻게 수정하려 했는지를 확실히 파악하고 나면, 버그를 다시 열거나 버그를 테스트하거나 버그에 대해 엔지니어와 대화할지 어떻게 할지를 결정하기가 수월해집니다.

이번에도 이렇게 해서 정말 많은 시간이 절약됩니다. 담당자 자리로 찾아가서 묻고 따지지 않아도 되니까요. 저나 엔지니어 모두 시간이 절약되고 말썽거리도 사라집니다.”

 

영향

 

Silas는 JIRA가 고객을 대면하는 팀에 대한 가시성을 높이고 엔지니어링이 하는 일에 대한 이해력을 높여주며 팀이 문제를 쉽게 수정하거나 기능을 개선할 수 있게 한다는 점을 얘기했습니다. Reuben은 Telestream에 미치는 JIRA의 영향을 다음 3가지로 정리했습니다.

  • 커뮤니케이션, 투명도, 가시성의 향상
  • '엄청난' 시간 절약
  • 제품 및 프로세스의 품질 제고

 

Reuben은 원격 엔지니어와의 커뮤니케이션이 향상된다는 점도 얘기했습니다.

엔지니어링 부서가 북부 캘리포니아 사무실과 스톡홀름 사무실로 나뉘어 있어서 JIRA가 없었으면 시간대 차이로 인해 멀리 떨어진 엔지니어들 간의 커뮤니케이션이 어려웠을 것입니다.

Silas는 JIRA의 영향에 대해 이렇게 생각을 정리했습니다. “저장된 정보의 풍부함이 주된 장점입니다. JIRA는 고객 질문에 답하고 고객 요구 사항을 처리하는 중요한 핵심 제품입니다.”

 

시간 절감

 

다양한 매개체 사이에 흩어진 정보를 추적하는 데 발생하는 많은 시간 손실과 골칫거리를 정확히 측정할 수는 없겠지만 JIRA는 하나의 단순한 중앙 위치에 모든 것을 유지하여 Telestream의 시간과 비용을 절감하고 커뮤니케이션 손실을 방지했습니다.

Reuben: “엔지니어링 부서와 QA 부서 사이의 작업이 엄청나게 향상되었습니다.

복도를 따라 걷고 구현할 새 기능에 대해 이야기할 시간을 많이 절약했습니다. 이제는 그저 JIRA에 직접 정보를 넣고 일반 워크플로로 '설정하면 끝'입니다.

수없이 많은 작업, 회의 시간을 절약했고 복도를 걸으며 서로 말을 주고 받는 시간을 절약했습니다. 저는 우리가 이전 도구로 작업하면서 엔지니어링에 소요된 시간에 비하면 아마도 수백만 달러는 절감했을 거라고 생각합니다.”

 

“우리 스톡홀름 팀의 경우 QA 관점에서 보자면 하루 전이나 간밤에 있었던 일에 대한 정보를 수동으로 정렬하는 데 시간을 들일 필요가 없어서 매일 2시간가량이 절약됩니다. 한 팀에서만 일주일에 10시간의 생산성 손실을 막는 것입니다. 우리는 3개월마다 특정 제품을 릴리스하는데, 릴리스당 절약되는 시간이 업무일로 15일이고 여러 제품 하나에만 연간 절약되는 시간이 업무일로 45일입니다.”

 

“JIRA는 '소셜 네트워킹' 느낌의 측면에서 봤을 때 많은 도움이 됩니다. 사람들의 상호 작용을 추적할 수 있어서 말입니다. 저는 JIRA와 함께 살고 JIRA를 사랑하며 매일 JIRA를 사용합니다. JIRA가 없으면 저는 작업을 거의 효율적으로 할 수가 없습니다. 어떤 경우에는 JIRA 없이는 아예 작업을 못 할 수도 있습니다.”

 

마지막 말

 

Silas와 Reuben은 JIRA가 QA, 엔지니어링, 고객 대면 팀에 유용한 도구라는 데 동의합니다.

하지만 JIRA는 그런 개별 사용자를 뛰어넘어 관리를 위한 강력한 정보 센터 역할도 합니다. JIRA는 조직의 상태를 전체로서 통찰할 수 있게 하는 제품 개발 부문에서만 중심 위치에 있는 것이 아닙니다.

JIRA는 전체 회사에서의 가장 중심에 있으며 관리 및 경영진에까지 제품 개발에 대한 정보를 제공합니다.

 

Reuben: “저는 JIRA를 주로 ‘품질 관리’ 시스템으로 생각합니다.

제가 경영진이 여기에서 얻었으면 좋겠다고 생각하는 것은 경영진이 JIRA 사용하여 수명 주기와 품질 관점 측면에서 다양한 제품의 현황에 대해 높은 차원의 개요를 얻을 있다는 점입니다.

우리는 십여 개(최소)의 개발 프로젝트를 진행하고 있어서 상황을 파악하기 위해 아주 상세한 수준까지 들어가기가 어렵습니다.

사용자는 JIRA 대시보드를 보고 신속하게 각 프로젝트가 진행되는 상황과 입력된 버그 수, 완료된 작업, 주어진 릴리스에서 보류 중인 작업을 신속하게 평가할 수 있습니다.

그래서 엔지니어링 팀과 이 팀이 어떻게 작업 중인지, 누가 작업하는지, 얼마나 시간을 쓰고 있는지에 대해 신속히 알 수 있게 합니다.

그렇지 않으면 정보를 얻기가 매우 어려울 것이고 어쩌면 불가능할지도 모릅니다.

마치 블랙홀 같은 미지의 영역이 수도 있겠죠. JIRA 정말로 문제를 드러내어 QA 엔지니어링 그리고 고객 지원 면에서 진행 상황을 매우 투명하게 보여줍니다.”

 

ShopLocal-Logo-RGB.jpg

설립: 1999년
사무실: 일리노이주 시카고에 본사
산업: 다중 채널 마케팅 서비스
직원 : 약 225명
사용 도구: Confluence, JIRA

 

저는 2주 전쯤에 ShopLocal의 제품 개발 담당 선임 이사인 Brendan Flynn과 함께 ShopLocal에서 API 문서 개발 및 출판을 위해 Confluence를 표준화한 방법에 대해 이야기를 나눌 기회가 있었습니다.

 

다중 채널 마케팅 서비스의 선두주자인 ShopLocal은 광고주와 소비자를 온라인/오프라인(점포)으로 연결해주는 혁신적이고 완전한 디지털 솔루션 패키지를 제공합니다.

ShopLocal의 업계를 선도하는 SmartProduct 비즈니스 솔루션(SmartCircular, SmartCatalog, SmartDelivery)은 Target, Best Buy, Home Depot, CVS, Albertsons, Sears를 비롯한 전국 상위권 소매업체 중 100개 이상의 업체에서 온라인 안내문, 디스플레이 광고, 검색, 소셜 미디어, 옥외 디지털 및 모바일 경로를 통해 쇼핑객에게 고도로 상호적이고 대상이 지정되고 지역화된 프로모션을 수행할 수 있게 합니다. ShopLocal은 Gannett Co., Inc.가 전체 지분을 소유한 PointRoll의 소매 부문을 담당합니다.

 

인터뷰


Confluence 대해서 어떻게 들으셨습니까?


이전 회사에서 Confluence를 사용한 적이 있습니다. 꽤 초기였던 Confluence 1.10 버전 때부터 사용하기 시작했습니다. Confluence는 정확히 원하는 것을 제공합니다.

우리는 아주 빠른 속도로 기존 콘텐츠를 모두 변환하고, 하나의 조직으로서의 공동 작업 방식을 실질적으로 변화시킬 수 있었습니다.

wiki는 조직의 생명선으로 API 문서에서 정책과 프로세스와 같은 수많은 내부 계획까지 모든 것에 wiki를 사용합니다.

wiki는 우리 조직의 지식 기반입니다. PointRoll에서 ShopLocal을 인수했을 때 우리는 Universal Wiki Converter를 사용하여 PointRoll의 SocialText wiki를 Confluence로 쉽게 마이그레이션할 수 있었습니다. 2010년 9월 기준으로 우리 wiki는 12,000페이지 이상 그리고 58,000페이지 버전 이상을 보유하고 있습니다.

 


Thumbnail image for ShopLocal-Developer-Center-Home.png


API 문서와 관련해서 누가 문서를 작성하고 누가 봅니까?

 

문서 작성은 제품 관리와 개발자의 공동 작업입니다. 이론상으로는 조직의 누구나 새 문서를 편집하거나 작성할 수 있지만 실제로는 편집하는 게 핵심 개발자밖에 없었습니다.

우리는 권한을 제한하여 고객은 페이지를 편집할 수 없지만 메모를 남길 수는 있게 만들었습니다.

 

우리는 애자일 개발 작업장이라 사용자 스토리를 취합하여 높은 수준의 릴리스 정보로 변환하는 일이 원활합니다. 우리는 여러 응용프로그램에서 일관성을 유지하고 싶었습니다.

모든 API 호출에는 XML 및 JSON 형식으로 된 예상 출력 외에도 짤막한 설명과 필수, 옵션, 조건부 매개 변수와 URL 예가 포함됩니다. 다양한 기업에서 본사 API를 사용하여 소매업체(Target, the Best Buy, Staples, 전 세계의 Home Depot)와 이들의 개발 에이전시를 포함한 다양한 매개체를 통해 로컬 거래를 독립 응용프로그램 개발자에게 배포하고 있습니다.

우리는 다양한 개발자, 에이전시, 소매업체와 작업합니다. 문서의 주된 목적은 사람들이 API를 채택하고 즉시 응용프로그램을 구축하는 일을 쉽게 만들기 위해서입니다.

 

wiki 전에는 문서화 작업에 무엇을 사용하셨습니까?


Confluence를 사용하기 전에는 API 문서를 배포하기 위해 100페이지 짜리 Microsoft Word를 사용했습니다. 회사 문서에 Word를 사용하면 의도하지 않은 문제가 많이 발생했습니다.

예를 들어 우리는 우리의 API를 버전화해서 거의 매 분기에 새 릴리스를 내놓습니다. 아시다시피 Word 문서를 서로 주고받다 보니 가끔 개발자가 최신 정보를 얻지 못해 이전 릴리스로 개발하거나 잘못된 명명법을 사용하는 일이 있었습니다.

또 변경 사항을 알리기도 아주 어려웠습니다. 업데이트를 배포하는 것은 이메일을 수단으로 삼았습니다.

어떤 경우에는 개발자가 문서를 마지막으로 요청한 때가 1년 전이었던 경우도 있었습니다. 여러 버전의 문서를 넘나드는 Word에 비해 wiki를 사용해서 가장 좋았던 건 제대로 된 원본이 항상 하나라는 점입니다.

 


Example-API-Calls.png


Confluence로의 콘텐츠 마이그레이션에 대해 말씀해 주세요.

 

Confluence로 바꾸고 나서 Word 문서를 다시 만드는 것보다 더 많은 일을 해보고 싶었습니다. wiki만이 제공할 수 있는 고유한 기능을 활용해보고 싶었습니다. 우리가 정한 첫 번째 목표는 어떻게 하면 사람들이 쉽게 사용하게 만들까였습니다. wiki를 사용하여 페이지를 서로 연결하고 코드 스니핏(snippits)을 삽입하고 SLA 정보를 지원하고 사용 약관을 게시할 수 있었습니다.

우리의 목표는 개발자가 API를 쉽게 사용하게 만드는 것이었습니다. 개발자에게 코드 사용 방법에 대한 정보와 예를 제공하고 싶었습니다. wiki는 우리가 정보를 강화할 기회를 주었습니다.

 

문서에 플러그인도 사용하십니까?

 

아니요, 사용 안 합니다. Confluence는 우리에게 알맞는 바로 사용 가능한 무료 플러그인과 매크로를 함께 제공하며, 우리는 현재 문서화 테마를 사용하고 있습니다.

일관성을 위해서 Confluence의 페이지 템플릿을 사용하고 있습니다. API 호출은 모두 일관된 모양으로 되어 있고 정보의 종류도 페이지에 상관없이 일관성이 있습니다.

그리고 레이블별 콘텐츠 매크로를 꽤 많이 사용합니다. 예를 들어, FAQ에 사용합니다. 이 매크로에 API FAQ에 태그를 붙인 다음 매크로를 사용하여 페이지가 동적으로 작성되게 합니다.

또한, 코드 매크로도 꽤 많이 사용합니다. 아마도 제가 가장 많이 사용하는 것 중의 하나는 포함 라이브러리(include 관련 매크로)일 것입니다. 저는 사실 포함 라이브러리의 광팬입니다. 루트 수준에 정보를 넣고 페이지 포함으로 다른 페이지에 콘텐츠를 삽입할 수 있습니다. 그 한 가지 예가 버전 관리입니다. 우리가 가진 API 버전이 여러 개이기 때문에 "이전 버전 참조"라는 부분을 최신 버전 링크와 함께 포함시킵니다. 한 곳에서 변경하면 사항이 해당 포함 페이지를 가진 페이지가 모두 업데이트되기 때문에 포함 라이브러리는 절감해주는 시간은 막대합니다.


문서에 wiki 사용하는 따르는 혜택은 무엇입니까?

 

우리가 추가적으로 경험한 혜택으로는 문서 일관성도 있습니다. 이제 개발자는 항상 최신 버전의 문서를 가질 수 있고 최신 버전을 어디서 받을지도 알고 있습니다. 개발자는 페이지를 지켜보기 때문에 변경 사항이 생기면 알림을 받게 됩니다. 메모를 사용해서 질문을 하거나 문서에 대한 피드백을 제공할 수 있습니다. 이렇게 되면 제품 관리자는 피드백을 얻기가 수월해 집니다. 현재 구축 대상의 상태를 확인하는 데 도움이 되기 때문입니다.

 

지금까지 본 것 중 최고의 API 문서는 사람들이 응용프로그램을 구축하는 일을 간편하게 만들어 주었습니다. 그렇게 만드는 것이 우리의 목표였습니다. 우리는 예전에 비해 많은 진전을 이루었습니다. 분명히 Confluence가 여기에 큰 몫을 했습니다.

 

생각지도 못했던 혜택 중 한 가지는 고객과 문서를 통해 대화하는 시간이 줄었다는 것입니다. 이제는 문서에 대해 설명할 필요 없이 고객이 구축하기 원하는 응용프로그램에 대해 바로 이야기를 할 수 있게 되었습니다.



감사합니다, Brendan!

(사례 연구) Atlassian의 도구들을 이용한 애자일 개발 실행 및 교육

 

본사: 폴란드 브로츠와프
직원 : 102명
설립: 2004년
사무실: 2곳(폴란드의 본사와 제슈프 부서)
제품: JIRA, JIRA Agile, Confluence, Crucible

 

애자일 개발, 지식 관리, 프로젝트 추적은 많은 회사에서 고심하는 세 가지 영역입니다. 우리 도구는 회사에서 이 세 가지 영역을 모두 해결하도록 돕는데 바로 PGS Software가 이를 위해 Atlassian의 제품을 적극적으로 채택한 회사입니다.

소프트웨어 개발과 정보 기술 아웃소싱 회사인 PGS는 애자일 프로세스를 능률적으로 만들어 모든 클라이언트에게 혁신, 품질 응용프로그램, 모범 사례, 방법론을 제공합니다. 이 회사는 유럽 기업에게 주변국 아웃소싱 솔루션을, 미국에서는 역외 서비스를 제공합니다. 기술 전문성을 갖추고 신흥 비즈니스를 잘 이해하는 PGS는 사용자 지정 응용프로그램 개발, 통합 솔루션, 제품 엔지니어링을 비롯한 다양한 아웃소싱 서비스를 제공합니다.

Atlassian은 PGS가 거의 전체에 해당하는 응용프로그램 개발 소프트웨어용 Atlassian 제품군을 사용한다는 소식을 듣고 무척 고무되었습니다. 저는 PGS의 Marcin Stawarz를 소개받아 Atlassian의 소프트웨어 개발 도구의 사용법에 대해 논의했습니다. 대화를 나누면서 PGS가 탁월한 소프트웨어 제품, 서비스, 사용자 지정 서비스를 제공하는 데 열정이 있다는 사실을 확연히 느꼈습니다. 이런 집중력을 보면 PGS가 작업에 사용 가능한 최고의 도구가 필요하다는 사실이 놀랍지 않습니다.

인터뷰

PGS 소프트웨어가 무엇인지 설명해주시겠습니까?

우리는 클라이언트에게 다양한 IT 서비스를 제공하는 아웃소싱 회사입니다. 우리는 프로젝트 및 문서를 작성하고 여러 언어 및 기술(C#, Java, PHP, Ruby, C++, ASP.NET, Flash, Mobile)로 개발하며, 작은 것부터 막대한 규모의 전 세계 클라이언트용 유럽 CRM/ERP 시스템까지 다양한 유형의 응용프로그램을 만듭니다. 비즈니스는 대부분 유럽을 중심으로 하지만 미국에도 클라이언트가 있습니다. 클라이언트 시장의 절반은 영국입니다. 우리 회사는 Wojtek Gurgul과 Pawel Gurgul 형제가 창립했고 작년에 상장되었습니다. 6년 동안 개발자 수만 0명에서 102명으로 성장했고 현재 클라이언트, 수익, 내부 프로세스 면을 감안하면 충분히 견고하게 성장한 기업입니다.

회사의 Atlassian 제품 사용 방식을 개략적으로 말씀해 주시겠습니까?

JIRA(버전 3)는 처음에 버그 추적기로만 시작했습니다. 지금처럼 애자일 프로세스를 지원하는 도구는 아니었습니다. JIRA Agile이 시장에 출시되었을 때 우리는 JIRA 최신 버전을 구입하기로 결정했습니다. 우리는 애자일 기반의 회사이기 때문에 주변국/역외 아웃소싱 회사로서 일할 수 있도록 그에 맞는 프로세스를 찾아야 했습니다. 애자일은 우리에게 완벽히 맞았습니다. 우리는 업무를 지원해주면서 프로젝트 지식 및 프로젝트 상태를 클라이언트와 공유할 수 있게 해주는 도구를 찾고 있었습니다. 투명성과 가시성은 PGS에서 굉장히 중요합니다. 애자일 팀을 지원하는 JIRA Agile은 완벽합니다. 뛰어난 도구이고 새 버전이 시장에 출시될 때마다 점점 더 개선되고 있습니다. PSG에는 11명의 스크럼 마스터가 있기 때문에 JIRA Agile이 아주 만족스럽습니다. JIRA Agile 및 JIRA로 모든 애자일 프로젝트를 수행하고 지원할 계획입니다.

다음 단계는 SharePoint를 교체하는 것이었습니다. 이전에 SharePoint를 사용하여 wiki로 몇 개의 내부 사이트를 만들려 했지만 그것은 완전히 망했죠. Atlassian의 모든 도구가 잘 통합되어 있다는 사실을 알고 나서는 Atlassian 솔루션을 더 많이 사용하기로 했습니다. 지금은 Confluence를 사용하고 있습니다. 우리는 Confluence를 기반으로 하는 내부 사이트가 있고 PGS의 모든 프로젝트에 관한 외부 연결 지식 기반이 있습니다. Confluence는 1년 반 전쯤에 구매했습니다. 작년에 프로젝트가 150개여서 KB가 아주 중요하죠.

다음으로 우리는 품질에 초점을 맞춥니다. 지금도 그리고 앞으로도 여기에 투자하려고 합니다. Crucible은 코드 검토용으로 선택되었습니다. 말씀 드렸다시피 투명성과 가시성이 우리의 목표이기 때문에 우리는 클라이언트와 정보를 공유할 수 있습니다. 프로젝트를 개발하고 클라이언트에게 제공할 경우 이제 결과가 공유됩니다. 본사의 일부 팀은 고객과 현장에서 작업하며 영국, 노르웨이, 프랑스, 스위스 같은 나라의 팀과 공동 작업합니다. 우리는 그런 환경에서 공동 작업하기 위해 JIRA, Confluence, JIRA Agile, Crucible 인스턴스를 사용합니다.

Confluence 사용 방법에 대해 자세히 알려주시겠습니까?

우리는 클라이언트용으로 별도의 wiki 공간을 마련하고 있습니다. 각 JIRA 프로젝트마다 우리는 Confluence에서 매칭 공간을 만듭니다. 그리고 이것을 스크린샷, 문서, 메모 등을 갖춘 지식 기반으로 사용합니다. 여기에서 공동 작업을 수행할 수 있습니다. 이것은 클라이언트에 대한 일반적인 인트라넷과 지식 공유 도구입니다. Confluence의 최대 이점은 회사에 뭔가를 알리고 싶을 때 버튼을 한 번 눌러서 wiki 페이지를 만들면 된다는 것입니다. 그거면 됩니다. 아주 간단합니다. 우리 회사의 신입 직원은 정보를 검색할 필요가 없습니다. Atlassian wiki 소프트웨어의 검색 엔진은 정말 훌륭합니다. 한마디로 사용하기가 쉽습니다.

사용자 지정 기능을 사용할 수 있도록 Confluence는 JIRA에도 연결된 시간 추적 및 송장 시스템을 위해 내부 보고 시스템에 연결되어 있습니다. 그 외에도 사용자 지정 브랜딩을 위해 디자인을 다양한 색상과 로고로 단순하게 바꿨습니다.

wiki 어떻게 하다 PGS Software 널리 퍼지게 되었습니까?

우리는 wiki에 귀중한 정보가 있다는 점을 사람들에게 납득시켜야 했습니다. 우리 회사에는 소프트웨어 기술을 가진 개발자만 있어서 wiki에 중요한 정보가 올라오면 바로 그 정보를 사용하기 시작하더라고요. 외부적으로는 팀장과 스크럼 마스터가 클라이언트에게 사용법을 보여줘야 했습니다. 일반적으로 도구 사용법에 대해서는 최소한의 교육을 제공합니다.

JIRA 이동하기 전에 다른 문제 추적기를 사용했습니까?

Bugzilla를 사용하려 했지만 클라이언트가 사용하기에 너무 복잡했습니다. 보고서를 제시하는 데 문제가 있어서 클라이언트에게 사용하도록 강요할 수가 없었습니다. 때로는 각 클라이언트가 익숙한 다른 소프트웨어가 있기 때문에 JIRA 이외의 문제 추적기를 사용하기도 합니다.

JIRA 인스턴스에 대해 말씀해 주시겠습니까?

우리의 JIRA 인스턴스는 연중무휴 공개되어 있으므로 클라이언트가 언제든지 프로젝트 진행 상황을 확인할 수 있습니다. 우리는 LDAP를 사용하여 권한을 부여하고 모든 내부 시스템에 액세스할 수 있습니다. 지금 JIRA에는 70개 정도 프로젝트가 있습니다. 우리는 클라이언트 이름으로 프로젝트를 그룹으로 묶습니다. 현재 사용자는 280명입니다. 모두가 활발한 것은 아니지만 적어도 이 정도의 사용자가 생성되었습니다.

이슈 추적기에서 스크린샷을 붙여 넣고 작성할 수 있는 JIRA용 플러그인이 일부 있습니다. 현재는 JIRA용 Balsamiq을 고려하고 있습니다.

JIRA Agile은 언제 도입하셨습니까?

우리는 스크럼에 JIRA Agile를 사용하기로 결정했었습니다. 애자일 Wallboard의 전자 버전이 필요했습니다. 구식 옐로카드를 사용하고 있었지만 이건 클라이언트와 공유하기가 어렵습니다. 우리는 JIRA Agile이 아직 Atlassian 제품이 아닌 플러그인이었을 때 구입했습니다.

Confluence JIRA 고려하는 개발 작업장에 하시고 싶은 조언이 있습니까?

Confluence는 정말 잘 작동됩니다! 간편합니다. 버튼 하나만 누르면 새 페이지를 작성할 수 있죠.
JIRA와 JIRA Agile은 스크럼을 수행하는 방법에 대해 클라이언트를 교육할 수 있는 훌륭한 방법이라고 말씀 드리겠습니다. 우리는 이 제품을 사용하여 프로젝트 진행 상황을 가상화하고 클라이언트에게 도구가 보기만큼 복잡하지 않다는 것을 보여주고 있습니다. 특별한 대시보드 준비와 JIRA Agile 사용은 우리가 일상적으로 수행하는 스크럼을 판매하는 데 뛰어납니다. JIRA는 이와 같은 용도에 가장 적합한 도구의 예입니다. 함께 프로젝트를 수행한 몇몇 클라이언트 중 JIRA를 구입하겠다는 클라이언트도 있었습니다!

감사합니다, Marcin!

 

 

설립: 2009년
본사: 워싱턴주, 시애틀
직원 수: 21명
제품: JIRA

 

게이미피케이션(Gamification)이란 우리가 흔히 즐기는 게임의 구성요소와 메커니즘을 게임 외적인 분야에 적용해 문제를 해결해 나가는 과정을 의미한다. 게임이 가진 즐거움이라는 요소를 다른 분야와 융합해 더욱 쉽고 재미있으며 더불어 효율성을 추구해 문제를 해결할 수 있도록 도와주는 방식인 것이다. (출처 참고)

 

게이미피케이션은 최신 경향으로 Google Trends에서도 아직 관심도가 높지는 않습니다. 많은 사람들이 게임 외 응용프로그램이나 웹 사이트로 사용자를 유인하기 위해 '펀웨어'를 시도해 봅니다. 목표는 사람들이 여러 번 사이트를 다시 방문하고 사용자가 원하는 행동을 하거나 일반적으로는 즐기지 않는 자잘한 일을 수행하도록 독려하려는 것입니다.

가장 일반적인 게이미피케이션 전략은 보상 포인트 시스템을 설정하는 것입니다. 대부분의 사람이 항공 마일리지나 신용카드의 빠른 보상 포인트 제도에 익숙합니다. 이러한 장치는 효과가 있고 고객을 참여시키며 트래픽을 증가와 함께 브랜드 인지도를 높이며 고객 유지에 도움이 되기 때문에 수년 간 사용되어 왔습니다.

저는 원래 Bigdoor.com의 마케팅 담당 이사인 Carrie Peters와 계약을 했습니다. BigDoor는 기업들이 사용자 참여와 충성도, 자본화를 높이기 위해 사이트에 포인트, 배지, 최고 점수 명단을 추가하도록 하는 무료 게이미피케이션 플랫폼입니다. 간단히 말해서, 소셜 보상을 통해 기업에서 웹 트래픽과 매출을 높이도록 돕습니다. 이들은 이 기술을 사용하여 API 호출 10억 건 이상, 게시자 250개 이상을 유치했다는 자부심을 갖고 있습니다.

Carrie와 나는 CTO 겸 공동 주거 개선자인 Jeff Mal다과 민첩한 소프트웨어 개발을 위해 JIRA Studio를 사용하는 방법에 대해 논의하고자 실시간 채팅을 준비했습니다.

인터뷰

BigDoor는 무슨 일을 합니까?

BigDoor는 게이미피케이션을 사용하여 소셜 참여와 충성도 프로그램을 지원합니다. 우리는 포인트, 배지, 최고 점수 명단, 가상 통화를 비롯한 게이미피케이션 요소를 온라인 디지털 게시자에게 제공하는 플랫폼을 보유하고 있습니다. 사이트는 무료로 BigDoor API에 액세스할 수 있고 이 API는 사용자 지정 가능한 백색 레이블 솔루션으로 모든 네트워크 장치에 액세스할 수 있습니다. 우리 플랫폼을 사용하는 온라인 게시자는 수백을 넘고 하루 API 호출이 출시 이후 1,800만 건의 수많은 API 호출을 달성했습니다.

JIRA 는 어떻게 BigDoor에 포함되었습니까?

BigDoor를 시작했을 때 저는 프로젝트 추적을 위해 다양한 도구를 조사했습니다. 이전에는 다른 무료 온라인 도구를 사용하고 있었지만 모든 옵션을 고려한 뒤 JIRA가 가장 알맞다고 생각했습니다.

아주 빠르게 작동하고 우수하고 탄탄하면서도 유연한 프로세스와 품질 코드, 코드 검토가 정신없이 빠른 속도로 계속 움직일 수 있게 해준다는 점이 매우 마음에 들었습니다.

JIRA 로 전환하기 전에는 어떤 도구를 사용했습니까?

예전에 사용한 도구(Banana Scrum)는 라이선스 정책이 변경되었고 더 이상 무료로 제공되지 않았습니다. 그 다음 Bitbucket으로 옮겼지만 일부 애자일 기능을 사용하지 못했고 당시 필요했던 프로젝트 관리 도구가 없었습니다. Atlassian이 Bitbucket을 인수했을 때 프로젝트와 문제 추적을 전부 JIRA로 옮기는 게 낫겠다고 생각했습니다. JIRA에 코드 리뷰, 연속 통합, 민첩한 프로세스 관리를 위해 제공하는 다른 통합 도구가 있다는 점도 매력적이었습니다.

JIRA 는 BigDoor에서 어떻게 사용됩니까?

Confluence(wiki)에서 Crucible(코드 검토), 문제 추적에 이르는 여러 다양한 작업에 JIRA를 사용하지만 기본적인 초점은 JIRA Agile을 위한 민첩한 프로젝트 관리입니다. JIRA Agile 작업은 우리에게 아주 중요한 작업입니다. JIRA는 주 단위로 소프트웨어를 출시하기 위해서 반드시 애자일 방법으로 이루어져야 하는 우선 순위 설정, 일정 계획, 작업 추적 기능을 제공합니다. 저는 Crucible의 검토 프로세스가 마음에 듭니다. 무척 잘 돌아갑니다. 또 JIRA 와 Google Apps 통합도 사용합니다.

BigDoor에서 민첩하게 작업하는 방법

큰 프로젝트를 시작하면 Google Docs에서 wiki 페이지와 사양을 작성하고 개발 팀의 한 주 분 작업에 맞도록 작업을 쪼갭니다. 우리는 더 작은 작업 단위를 스토리라고 부릅니다. 스토리 수준에 도달하면 JIRA에 들어갈 수 있습니다. 그 다음 스프린트를 시작하는 간단한 계획 회의를 갖습니다. 한 주가 지나면 팀은 매일 만나 짧은 시간 서서 하는 미팅을 갖고 최종적으로 한 주가 끝나는 시점에 출시를 합니다. 지난 시간을 돌아본 다음에는 다음 주를 위한 프로세스를 다시 시작합니다.

JIRA를 사용하여 결과를 수치화할 수 있습니까?

JIRA는 완료된 작업과 작업 완료에 걸린 시간을 추적할 수 있는 메트릭을 제공합니다. 목표 대비 진행 상황의 측면에서 잘 진척되어 가는지를 보여주는 정확한 측정을 제공합니다. 작업 소요 시간, 목표에 이르는 상황을 추적하고 있는지 여부, 주간 스프린트 목표를 달성할 것인지 등을 측정할 수 있다는 사실만으로도 JIRA의 성능 발휘를 수치화할 수 있습니다.

 

“JIRA는 문제 추적과 워크플로를 추가 및
편집하는 데 뛰어납니다. JIRA는 프로젝트 추적이라는 면에서 아주 강력한 도구입니다.”

 

 

소규모 개발 작업장에 해주고 싶은 조언이 있습니까?

JIRA Agile 을 사용해서 애자일을 지원하라고 말하고 싶죠. 사람들이 SVN을 사용하면 Atlassian과 통합이 아주 잘 됩니다. Atlassian으로 SVN Repo를 호스팅한다고 하면 그야말로 이상적인 상황이죠. 다른 코드 호스팅 도구는 생각하지 말라고 하겠습니다. Atlassian은 설정이 아주 잘 되고 JIRA는 문제 추적이 잘되고 워크플로를 추가하고 편집할 수 있어서 프로젝트 추적 면에서 아주 강력한 도구입니다. 정보 라디에이터(월보드) 사용을 기대하고 있습니다. 아직 거기까지는 안 되지만 사용하고 싶습니다. 또한, Atlassian의 지원이 아주 인상적이었다고 말하고 싶습니다.

Jeff, Carrie, 감사합니다!

 

성공하는 제품 관리의 비결 8가지

 

 

 

 시스템에 숨어있는 "윤초" 버그에 대해 Atlassian 어플리케이션 관리자가 알아야 할 것들

 

 

개요

 

윤초란 평균 태양시에 맞추기 위해 가끔씩 UTC (세계 협정시)의 1초를 수정하는 것입니다. 

가장 최근의 윤초는 2012년 6월 30일 23시 59분 60초에 있었는데 전세계적인 컴퓨터 시스템 고장의 원인이 되었습니다.

윤초에 대해 와이어드 (잡지)에 실린 기사 ‘Leap Second’ Bug Wreaks Havoc Across the Web를 읽어보세요.

 

다음번 윤초 수정은 2015년 6월 30일 23시 59분 60초에 있습니다. Atlassian 어플리케이션에 관한 한, 여러분은 목전에서 그 위험을 벗어나실 수 있습니다.

영향

 

Atlassian 어플리케이션들은 몇 가지 지원 플랫폼을 통해 간접적으로 이 버그에 영향을 받습니다.

기본적으로, 컴퓨터 시스템들이 항상 윤초를 대비하고 있는 것은 아닙니다. 

이 버그는 다양한 소프트웨어- 특히, 특정 버전의 자바, 리눅스 커널, 그리고 MySQL 데이터베이스 서버에 영향을 줍니다. 

Atlassian 어플리케이션이 이들에 의존하는 한, 여러분은 시스템에서 몇가지에 대해 주의를 기울여야 합니다. 

 

이 버그의 영향으로 알 수 없는 CPU 사용 및 증가, 어플리케이션 속도 저하, 어플리케이션 충돌, 시동 실패가 일어날 수 있습니다. 

비록 최근에는 이 버그가 일으키는 데이터 손실이나 변형에 관련된 어떤 이슈도 접수되지 않았지만, 이로 인해 다음의 어플리케이션/서버가 충돌한다면 그러한 결과를 불러올 수도 있습니다.

 

영향받는 환경과 제품들

 

고 객의 자체 네트워크내에서 운영되는 Atlassian 어플리케이션들은 이 버그로 인해 간적접인 영향을 받게 되므로, Atlassian 제품과 연동되는 시스템의 모든 관리자에게 (호스팅 서버, 데이터베이스 서버, LDAP 서버, 메일서버 등) 문의하십시요.

그래서 관리자가 해당 시스템의 소프트웨어 제품 벤더에게 윤초 버그에 대한 수정사항을 포함하는 제품 버전에 대해 확인할 것을 제안합니다.

 

Atlassian 어플리케이션에서 지원되는 가장 최신의 버전으로 리눅스, 자바, MySQL 을 업그레이드 하는 것은 윤초 버그에 의한 문제를 예방하는 가장 좋은 방법일 것입니다.

다른 방법으로는 호스팅 서버/VM 을 재시작하는 것이지만, 이것은 일반적으로 운영환경에서는 적절하지 않을 것입니다. 아래의 차선책을 참조해 보십시요.

 

NTP  로 동기화되는 시스템만이 영향을 받게된다는 것을 명심하십시요.

 

수정방법 제안

 

소프트웨어 벤터의 웹사이트를 확인하고 영향받는 제품의 버전을 확인하십시요. 영향을 받는 제품은 여기의 목록만은 아닐것임을 유의하십시요.

그래서 시스템 관리자와 협의하여 준비하십시요. 아래의 수정사항은 여러분의 환경에서 충분하지 않을 수 있습니다. - 로컬 분석을 수행하십시요.


 

최근의 버전들이 문제를 수정하였다고 하더라도, 문제를 최소화하는 솔루션을 준비하는 것이 언제나 최선입니다. 아래의 "차선책" 항목을 참조하십시요.

 

대안


만약 문제 발생 증상 (CPU 부하 증가, 어플리케이션 다운, 구동 실패) 이 발생한다면, 다음의 조치를 적용하는 것이 안전합니다.


이 업데이트는 문제발생 가능성이 있으며 때로는 시스템을 중지시키는 것이 필요하므로, 대안을 준비하는 것이 가장 좋습니다. Atlassian 어플리케이션에 구조적으로 연결된 모든 잠재적인 영향을 받을 수 있는 서비스 서버 (데이터베이스, 프록시 서버 등) 에 대해 구현할 것을 제안합니다.

 
  1. NTP daemon 중지 (가능하다면, 2015-07-01 00:00:00 이전)
  2. 루트사용자로 2015-07-01 00:00:01 후에 date -s “`date`” 실행
  3. NTP daemon 시작


참고: NTP 데몬이 중지되는 시간을 최소화 할 것을 권장합니다.

Source: https://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/

법적 책임

 

이 버그는 Atlassian 어플리케이션 자체가 아니라 Atlassian 어플리케이션이 인터페이스로 접속하는 플랫폼에 영향을 미치는 바, Atlassian은 이 버그를 수정할 책임을 지지 않습니다. 

저희는 잠재적 문제에 대한 인식을 높이기 위해 최선을 다할 것이지만, 모든 개별 시나리오에 대해 조언을 드릴 수는 없을 것이므로 여러분께서 자신의 시스템에 대한 영향 분석을 하시도록 제안합니다.  

 

FAQ


이 버그에 영향을 받을 지 어떻게 확인할 수 있나요? 

여러분의 시스템 관리자를 컨텍하셔서 여러분이 Atlassian 어플리케이션을 운용하는 소프트웨어가 윤초 버그에 영향을 받는지에 대해 확인하서야 합니다. 

제가 위에서 언급한 것보다 더 많은 소프트웨어들이 영향을 받을 것입니다. 

언급된 플랫폼들은 Atlassian 제품들에 가장 직접적으로 영향을 줄 것으로 예상되는 제품들입니다. 

이 글 하단에서 보시는 것과 같이 여러분이 영향을 받을 지에 대해 확인할 수 있는 스크립트와 방법을 제시하는 다양한 글들이 있습니다.

 

영향을 최소화하려면 어떻게 해야 하나요? 

소프트웨어 버전을 업그레이드 하시고 영향을 받는지 확인하시는 것이 최선의 예방법입니다만, 필요하다면 위에 제시된 차선책을 실행할 준비를 하시는 것이 좋습니다.

 

이 버그에 대해 도움이 필요할 때 Atlassian에 물어볼 수 있을까요?

Atlassian 어플리케이션은 이번 이슈에 간접적으로 관계되므로 여러분의 회사 시스템 관리자를 컨텍하시는 것이 가장 좋습니다. 그러나 여러분이 support.atlassian.com을 통해 티켓을 제시하신다면 조언을 드리는데 최선을 다하겠습니다.


이 이슈에 관해 추적된 내용은 어디서 찾을 수 있습니까? 

이 버그는 다양한 소프트웨어 판매사의 웹사이트와 온라인 문서/포럼에서 추적 가능합니다.

여러분의 소프트웨어 판매사에 연락해 보십시오.

 

Atlassian 어플리케이션은 지원 플랫폼(Linux, Java, and MySQL)을 통해 간접적인 영향을 받으므로, 저희는 윤초 버그를 공식적으로 저희 이슈 추적기에서 다루고 있지 않습니다.

다음의 지식 기반 글 JIRA Performance Problem due to System Time Settings 또한 프로그램을 실행시킬 차선책을 설명하고 있습니다. 

이는 JIRA뿐 아니라 모든 Atlassian 어플리케이션에 적용됩니다.

 


참고

 

About Peter Koczan

Originally from Hungary, currently located in Amsterdam. Working in Premier Support at the Atlassian office here, providing support for all of our products including Confluence, JIRA, Crowd, FishEye/Crucible, Bamboo, Stash and HipChat. Learning as much as possible with the goal of making support- and product experience better for all, since 2012.

View all posts by Peter Koczan »

 

당신의 삶을 편리하게 해줄 5개의 무료 Atlassian 애드온

 

 

'악마는 디테일에 있다'고들 합니다. 그 말대로 사소한 것들이 제대로 돌아가지 않을 때 여러분은 인내심의 한계를 느끼게 됩니다. 이런 것들에 시달리기엔 여러분의 일은 너무 소중합니다. Atlassian Marketplace는 매일의 성가심을 해결해 여러분이 일에 매진할 수 있도록 도와줄 유용한 무료 애드온을 다양하게 갖추고 있습니다. 

간단히 그리고 무료로 삶을 편리하게 만들어 줄 다섯 가지 방법들을 소개합니다.

 

  1.  Survey and Vote Macros for Confluence

설 문을 만들어야 하나요? 설문에 투표하거나 조사 결과를 볼 수 있는 사람들을 통제하고 싶으신가요? 이 매크로들을 사용하시면 클릭 몇 번만으로 손쉽게 설문 조사를 만드실 수 있습니다! 즉시 결과를 받을 수 있고, 하나의 질문을 평가하고, 집중 관리 섹션에서 모든 매크로를 컨트롤할 수 있습니다. 여러분의 Confluence 페이지에 설문이나 여론 조사를 추가하고 싶다면, 이 애드온이 해답이 될 것입니다.


       2.  Script Runner for JIRA

Script Runner는 JQL 기능, 리스너, 서비스, 워크플로우 기능의 집합을 제공합니다. 그리고 여러분만의 계산된 맞춤 필드를 만들 수 있습니다.


      3.   Gliffy-제품 (Confluence, JIRA 플러그인)

비지오 파일들이 보고 싶으십니까? Gliffy 는 빨리 도표를 그려 Confluence 페이지 혹은 JIRA 이슈에 넣기 쉽게 해줍니다. 그리고 더욱 편리하게도, 인터넷이 가능한 기기라면 어디서나 사용할 수 있습니다. 또한 구글 드라이브와 구글 어플리케이션들과 연동됩니다.

 

      4.   Numbered Headings for Confluence

Numbered Headings는 믿기 어려울 정도로 사용이 간단합니다. 그저 여러분의 콘텐츠를 감싸기만 하면 끝입니다! 번호 매기기가 Confluence 편집기와 매크로 브라우저 양쪽의 제목들에 추가되기 때문에 즉각적으로 피드백을 받을 수 있습니다. Confluence Server와 Confluence Cloud를 위한 Numbered Headings로 여러분의 콘텐츠 제목에 참조 표기가 쉬워집니다.


       5.  Evernote Integration for Confluence

Evernote 애드온은 여러분의 Evernote 계정으로부터 어떤 타입의 메모라도Confluence 페이지로 옮길 수 있도록 해줄 것입니다. 간편히 오디오, 동영상, 사진, 표, 텍스트 메모를 Confluence 환경 내에서 여러분의 팀과 공유할 수 있습니다. 단순히 생성 버튼을 클릭하는 것만으로 메모를 새로운 페이지에 생성할 수 있습니다. 여러분이 Confluence로 복사한 메모를 팀원들이 편집할 수 있지만, Evernote 안의 원본은 훼손되지 않습니다.


여기에 소개된 애드온들:  Survey and Vote Macros, Script Runner, Lucidchart for Cloud, Numbered Headlines, 그리고 Evernote Integration은 Atlassian Marketplace에서 만나실 수 있는 애드온들입니다.

이 애드온들은 여러분의 Atlassian 어플리케이션들을 커스터마이즈하고 향상시켜 여러분의 창의성과 생산성이 향상되도록 디자인 되었습니다.

https://marketplace.atlassian.com에서 자세한 정보와 또다른 애드온들을 찾아보실 수 있습니다.

자신만의 애드온을 만들길 원하십니까? https://developer.atlassian.com 에서 그 방법을 확인하십시오.

 

 

IT 패널: 신속하고 민첩한 IT 서비스의 비밀

 

JIRA Service Desk 고객 스토리: Halogenics

 

Gilt에게, 애자일은 모범 사례가 아닙니다
- 사고 방식 그 자체입니다


 

소프트웨어와 교육의 힘을 통한 인류애

Wesley Faulkner 글

 

지 난 주 저희는 HipChat Server를 출시했는데 왜 스타터(Starter) 라이센스는 다른 라이센스 옵션과 기준 소매 가격이 다른 지 물어보시는 몇 분이 계셨습니다. 스타터(Starter) 라이센스 - 작은 사업체를 위한 HipChat Server는 사용자 10명에 단 10불입니다. 스타터(Starter) 라이센스의 수익은 모두 Atlassian Foundation 자선 단체로 바로 전달됩니다.

 

  • 이러한 이유로 Starter 라이센스는 저희 골드피처를 통해 구매하실 수 없고 직접 Atlassian 사이트(http://www.atlassian.com/starter) 를 통해 구매하셔야 합니다.

 

Atlassian 이 작은 회사였을 때, 저희는 한 가지 선택을 했습니다. 다른 모든 이들처럼 얼굴 없는 회사가 될 것인가, 아니면 우리가 가진 자원들을 그것을 가장 필요로 하는 사람들의 삶을 바꾸는데 사용할 것인가의 선택이었습니다. 

사람에 투자하는 것, 더 좋은 세상이 되도록 돕는 것, 그것이 멋진 일이기 때문이 아니라 올바른 일이기 때문에 하는 것이 저희 회사의 문화입니다.  

그 당시, 저희는 회사 전반에 걸친 1%의 전환이라는 자선 서약을 했습니다.
저희는 저희의 자기 자본, 제품, 이익, 그리고 직원 시간의 1%를 자선 목적에 쏟고 있습니다.

저희는 이 서약을 공개하여 더욱 책임감을 갖도록 하였습니다. 

저희 약속에 번복은 없습니다

Atlassian Foundation은 저희의 자선 활동 중심 허브이며, 여기에 저희는 미래의 프로젝트 목표와 함께 성공을 전시합니다.

2011년, 저희는 Room to Read와 파트너를 맺고, 함께 캄보디아의 학생들에게 교육을 강화할 기회를 제공하였습니다. 첫 해에는 백만 달러 이상을 벌었고, 매년 예상 기부액을 상회하는 성과를 올리고 있습니다.

캄보디아에서 저희는; 교육이 다시 한 번 번성하도록 돕는 동시에, 학교를 재건하고, 도서관을 다시 보충하는 사업에 집중하고 있습니다.
크메르 루즈 집권 당시, 책들은 불태워졌고, 도서관은 철거되었으며 교육 인구는 투옥되거나 죽임을 당했는데 이는 모두 지식인들의 봉기를 억압하려는 시도였습니다.

교육이 열쇠입니다

교육은 모든 것입니다; 모든 사람은 마땅히 배우고 자랄 장소를 가질 자격이 있습니다. 학교는 가장 위대한 정신의 인큐베이터입니다. 
Atlassian은 지속하여 삶을 바꾸기 위해 실질적으로 다른 회사들, 창립자, 그리고 지도자와 파트너 육성을 염두하고 있습니다. 왜냐하면 저희는 교육이 가능한 가장 중요한 투자라고 믿기 때문입니다.

지역 비영리 단체와도 함께 일합니다

저희는 또한 많은 비영리 조직과 긴밀히 일하고 있고 HipChat Cloud와 Server 모두 자선 목적의 할인을 제공하고 있습니다. 
자선 활동은 저희의 브랜드로서의 성공에 큰 부분을 차지하고 있고, 해가 감에 따라, 저희는 계속해서 사람들에게 봉사하고 세상을 바꾸는데 일조하며 매일 더 많은 일들을 해나갈 것입니다.

“교육은 저희의 미래로 나아가는 통행증입니다.  왜냐하면 내일은 오늘 준비하는 사람들의 것이기 때문입니다. ” – Malcolm X

 

HipChat은 그룹 채팅이며 팀을 위한 IM입니다. 자세한 내용은 여기를 참조하세요.