스프린트 4 시작

전체 ZIMS 개발 과정에서 중간을 말하라면 스프린트 4가 될 것입니다. 스프린트 4에서는 개인과 단체의 가입 화면, 식별자, 트랜스폰더, 형태분석학, 측정 방법(동물의 무게 또는 껍질 길이 등) 등을 작업합니다.

이들은 ZIMS 사용자가 가장 자주 사용할 화면입니다. 전체 7 개 스프린트 중 중간인 스프린트 4에 이들 화면을 작업하는 것은 결코 우연이 아닙니다. 이들 화면은 가장 복잡한 코드로 구성되어 있기 때문에 개발 과정이 원활하게 진행되고 있는지 확인한 다음 이 작업을 진행하자고 계획한 것입니다.

ZIMS 프로젝트는 현재까지 매우 원활하게 진행되고 있으며 큰 문제 없이 중요한 45개 화면을 모두 개발할 수 있을 것으로 예상됩니다. 다른 스프린트와 마찬가지로 이번에도 2주간의 계획 단계부터 시작합니다. (이번 주 미네소타에서 우리와 함께 작업했던 인도 팀원 3명이 인도로 돌아갔습니다.) 그리고 다음 주부터는 스프린트 4의 코드 작성 작업을 시작합니다.

전체 스프린트 일정을 확인하려면 여기를 클릭하세요.

스프린트 3: 일정대로 완료

“스프린트 3” ZIMS 화면의 테스트 작업을 끝내고 버그 수정 작업도 거의 막바지에 이르렀습니다. 7주 간의 개발 기간 (스프린트)에 70개 이상 되는 ZIMS 화면을 개발했습니다. 스프린트 3에서는 우리와 수족관 생명유지장치 관련 화면을 주로 작업했습니다. 아래는 스프린트 3에서 개발한 일부 화면입니다. 각 화면을 클릭하면 크게 볼 수 있습니다. 각 화면을 확인한 다음 인터넷 브라우저의 “뒤로” 버튼을 클릭하면 원래 ZIMS 블로그로 돌아올 수 있습니다.

스프린트 3: 인도에서 일하는 영역별 전문가

위 사진은 영역별 전문가 에이드리안 밀러와 던컨 볼턴, 제이슨 크릭톤이 ZIMS 화면 초안을 제작했던 UI 전문가 라즈니쉬 바트나가르와 함께 새로운 ZIMS 화면에 대해서 논의하는 모습입니다.

제이슨은 수족관 전문가이며 던컨과 에이드리안은 각각 큐레이터와 기록원의 관점에서 전문 지식을 제공합니다. ZIMS는 ISIS의 기존 소프트웨어보다 훨씬 다양한 방법으로 동물원과 수족관에 필요한 서비스를 제공해야 하기 때문에 여러 분야의 전문가들과 함께 작업하고 있습니다.

일반적으로 소프트웨어는 두 개 언어를 동시에 구사해야 합니다. 하나는 개발자가 ZIMS를 만들 때 사용하는 기술적 언어입니다. 일반 사용자는 이 언어를 보거나 들을 수 없지만 이는 성공적인 ZIMS 개발에 꼭 필요한 언어입니다. 다른 하나는 여러분이 날마다 일하면서 사용하는 언어로 우리끼리는 주쿠아리움(zooquarium)이라 부르기도 합니다. 이는 회계, 금융, 자선모금, 법학 등 전문적인 비즈니스 소프트웨어를 가지고 있는 수백여 개 산업 분야가 모두 그러하듯 각 분야에서 사용하는 전문 언어입니다.

인도와 미네소타에서는 약 50여명의 개발자가 ZIMS의 기술적인 부분에 필요한 코드를 작성하는 가운데, 영역별 전문가는 일반 사용자의 입장에서 ZIMS이 제대로 작동하는지 그렇지 않은지 확인합니다. 영역별 전문가는 소프트웨어 언어를 모르기 때문에 동물원과 수족관 분야를 모르는 개발자들에게 자기 의견이 정확히 전달됐는지 계속해서 확인해야 하므로 자연스럽게 긴장감이 조성됩니다. 동시에 영역별 전문가의 아이디어가 모두 탄탄한 소프트웨어 개발 규칙에 맞는 것은 아니기 때문에 편안하게 생각할 수도 있을 것입니다. 그래서 모든 협동 작업이 그러하듯이 이 과정에서도 자연스러운 긴장감이 흐릅니다.

위는 처음 사진에서 영역별 전문가와 UI 전문가가 살펴보던 화면으로 통계조사 관련 화면입니다. 바트나가르가 목업(mock up) 화면을 만들어 질문과 코멘트를 적으면 영역별 전문가는 다음 초안을 작성할 수 있도록 돕습니다. (다음 ZIMS 팟캐스트에서 이 과정에 관해 자세히 설명해드리겠습니다.)

영역별 전문가와 개발 팀 간 이런 신속하고 효율적인 상호 작용이 바로 저희가 영역별 전문가를 인도에까지 파견한 이유입니다. (영역별 전문가는 누구인가요?)

새로운 ZIMS 화면 = 해피

현재 저희는 새로운 ZIMS 화면을 보여주고 주변의 반응과 피드백을 받고 있습니다. 지난 주에는 교육 및 지원 팀의 엘리자베스 헌트 국장이 약 40분간 웹엑스를 통해 어얼리 어답터 기관 직원 60명에게 ZIMS를 시연해 보였습니다. 그리고 그 반응은 매우 뜨거웠습니다. 그 뜨거운 반응을 확인하려면 여기를 클릭하세요.

새로운 ZIMS 화면 중 하나를 확인하려면 여기를 클릭하세요. 이는 분류학의 “기본 정보 추가” 화면입니다. ZIMS 화면의 왼쪽 메뉴를 보면 가장 멋진 디자인 기능을 보실 수 있습니다. 각각의 파란색 버튼을 클릭하면 드롭다운 메뉴가 나타나서 해당 영역을 매우 간편하게 탐색할 수 있습니다. 다음 비디오 팟캐스트에서는 “탭의 기능”과 더불어 이 기능에 대해서도 더욱 자세히 알려드리겠습니다. 예, 이런 기능에 열광하다니 매우 컴퓨터 광스럽지만 저희가 바로 컴퓨터 광이랍니다. (지난 ZIMS 팟캐스트를 확인하려면 여기를 클릭하세요.)

지금은 개발 초기 단계라서 동물들과 직접 접하는 작업자용이 아니라 각 기관의 ZIMS 관리자용 화면 밖에 보여드릴 수 없어서 그다지 재미가 없을 수도 있습니다. 그러나 디자인 요소(UI, 사용자 인터페이스)는 ZIMS 프로그램 전체에 걸쳐, 동물원 주소 입력 화면이나 동물 관련 정보 입력 화면이나 모두 동일합니다

새로운 ZIMS 팟캐스트: 위험

대규모 프로젝트는 작업이 잘되고 있는지 확인하고 잘못되지 않도록 미리 방지하는 위험 식별 및 완화 계획을 수립해야 합니다.

이번 비디오 팟캐스트에서는 약 7분에 걸쳐 ZIMS 프로젝트의 위험 완화 방법을 일부 소개합니다.

아래 화면에서 “재생” 화살표를 클릭하면 비디오를 확인할 수 있습니다. 여기를 클릭하면 유튜브에서 더욱 큰 화면으로 비디오를 감상할 수 있습니다.

ZIMS 중간 검토

이미지: Superstock.com

작년 여름 ISIS 이사회는 ZIMS 프로젝트를 본격적으로 시작하기에 앞서 외부 전문가를 초청해 ZIMS 개발 계획을 검토하도록 했습니다. 그리고 프로젝트를 진행하는 중에도 주기적으로 중간 검토를 수행하도록 했습니다. ISIS는 ZIMS가 계획대로 진행되고 있는지 확인하는 첫 번째 중간 검토를 수행하기 위해 인포테크 리서치 그룹을 다시 고용했습니다.

중간 검토는 올바른 작업 과정이기도 하지만 처음 개발 실패로 자신감이 떨어지고 걱정이 많아진 결과이기도 합니다. ZIMS 개발 자금은 여러분이 보내준 성금이기 때문에 우리는 하루빨리 자신감을 되찾기를 바라고 있습니다. 그리고 ISIS 직원 입장에서 보면 새로운 ZIMS 개발 과정은 아직 초기 단계지만 문제 없이 진행되고 있습니다.

향후 몇 주간 인포테크 팀은 지금까지 우리가 사용해온 작업 과정과 그 결과를 면밀하게 검토할 예정입니다. ISIS 이사회는 아래와 같이 이번 검토 작업에 반드시 확인해야 할 사항을 정했습니다.

1. 스프린트1과 2는 일정 내에 완료됐는가?
2. 스프린트3는 일정대로 완료될 것인가?
3. 각 마일스톤에 정해진 작업량을 모두 완료했는가 또는 정해진 작업량 이상을 작업했는가?
(작업량은 계획한 화면 수, 일정에 따라 실제로 작성한 코드)
4. 프로젝트의 모든 위험 요소에 대해 유효한 완화 전략을 갖췄는가?
5. 잘못됐거나 불안정한 작업 과정에 대해 유효한 완화 전략을 갖췄는가?
6. 프로젝트에 심각하게 영향을 미칠 정도로 오프쇼어팀과 온쇼어팀 간 소통이 단절되어 있는가?
7. 버그가 쌓여서 향후 스프린트 일정에 영향을 주는 일이 없도록 이어지는 스프린트에 확인 안된 버그를 수정할 시간을 충분히 배치해두었는가?

기관 주소 입력, 직원 연락 정보, 분류 관련 화면 등을 만드는 스프린트 1~3은 ZIMS 개발 과정 중에서도 지루한 부분에 속해서 지금이 외부 검토를 수행하기에는 최적의 시기입니다. 향후 2주 내에 시작할 스프린트 3에서는 우리 이름, 치수, 물펌프 제작사 이름과 같이 일상적인 정보 입력 화면을 만듭니다.

반면 미네소타의 ISIS 팀은 스프린트 1~3 기간에 전체 ZIMS 프로그램에 걸쳐 두루 재사용될 화면 구성 150개 중 대부분을 작업합니다. 이는 사용성을 높여서 ZIMS를 성공적으로 개발하는데 반드시 필요한 작업입니다. 따라서 지금이 객관적인 평가가 이뤄지기 적당한 시기입니다.

인포테크에서 첫 번째 중간 검토를 끝내면 그 결과를 고지하겠습니다.

버그 수 관리

여러분 중에 곤충학자가 있다면 죄송하지만 소프트웨어 분야에서는 아무도 버그를 좋아하지 않습니다. 소프트웨어에서 버그란 코드에 사소한 결함이 발생해 소프트웨어가 오작동하는 오류를 가리킵니다. 스프린트 2의 테스트 작업이 이제 막 완료되어 앞으로 11일 동안은 테스트 작업 중 찾은 버그를 수정할 예정입니다. 다행스럽게도 스프린트 2에서는 스프린트 1에 비해 발견한 버그 수가 반으로 줄었습니다. 이는 처음에 계획했던 대로 각 스프린트를 진행할수록 점점 능숙해지고 있다는 증거입니다. 각 스프린트를 진행할수록 개발팀의 프로세스 이해도가 향상되고 팀원들간의 소통도 원활해지고 있습니다.

이는 또한 어느 소프트웨어 개발 과정에서나 발생할 수 있는 위험, 즉 프로젝트를 진행하면서 수정하지 못한 버그가 쌓여서 나중에는 적정 시간 내에 처리하지 못할 정도로 버그가 많이 쌓이는 위험을 낮추는데도 도움이 됩니다. 우리는 이미 처음 개발 과정에서 이를 경험해봐서 그 끝이 어떠한지 잘 알고 있습니다. 그리고 지금까지 새로운 개발 과정에서는 당초 계획한대로 위험 관리가 잘 이뤄지고 있는 것 같습니다.

(사실인지 확실치는 않으나 버그라는 표현은 IBM에서 펀치카드 컴퓨터를 개발할 때 실제 곤충이 기계 장치 안으로 들어가 문제가 발생한 것에서 유래됐다고 합니다.)