[u] Story 의 naming convention 을 Story 방식으로 변경함.
팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.
RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.
덤으로..
추가로..
스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.
혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.
최근 조사 결과를 바탕으로 간략히 현 시대의 소프트웨어 개발 프로세스와 툴의 현황을 공유해본다.
먼저 소프트웨어 개발에 활용중인 프로세스들의 비중을 살펴보자.
다음은 조직내에서 Agile 이 어느 정도 받아들여지고 있느냐에 대한 설문이다.
마지막으로.. Agile 을 지원하는 툴로써 현 시대 제품들을 평가해본 결과이다.
When you develop an Android application on Emulator, you probable encounter a tiny problem. The default screen size of Emulator is generally too large to work on small laptop. For instance, 13″ macbook only supports screen size 1280*800. And you want to develop an application looks perfect on Motorola Droid, which supports 480×854. It exceeds your laptop’s real estate.
In this case, you may want to resize (or scale down) the Emulator’s screen. Here’s the solution what you’re looking for.
In face, Android AVD Manager’s shipped with the feature built-in. Let’s check one by one.
I prepared one AVD which supports WSVGA1024. Really big. Mostly suitable for tables, but not phones. Anyway..
Your emulator on your display will have the exactly same size you just set at step 5. In above case, the emulator’s screen will cover 7″ in your display.
OK.. Enjoy programming!
RTC 를 처음 시작하려는 사람들에게 좋은 자료들을 정리해보았다.
한 팀에서 처음으로 RTC 를 사용해 과제를 진행해보고자 한다면, 팀원들을 한 자리에 모아놓고 아래대로 쭉~ 학습해보자. 중간중간 대화와 검색 등의 시간을 합쳐 총 2시간 정도의 workshop 이면 충분할 것이다. 물론 최소 1명은 RTC를 직접 사용해본 경험자가 필요하다.
1. (10분) 다음은 RSSOwl 이라는 오픈소스 프로젝트에서 RTC 를 사용하는 모습을 아주 간략히 보여주는 동영상이다. RTC 가 도대체 무엇을 제공해주는 툴인지, 그 전반을 짧은 시간 내에 훑어보기에 좋다.
2. (15분) 다음으로는 직접 RSSOwl 사이트를 방문하여 위의 짧은 동영상에서 놓친 세세한 부분들을 점검해보자.
RSSOwl – Reader for RSS | RDF | Atom Newsfeeds
데시보드도 훑어보고, 각 반복주기별 태스크 관리, 소스 코드와 결함, 빌드 상황들이 어떻게 보이고 관리될 수 있는지 체크해보자.
* 참고로, 포럼은 오픈 소스 프로젝트 운영에 필수 요소 중 하나이지만 RTC 가 제공하지는 않고 있다. 포럼이 필요하면 취향에 맞는 프리 포럼을 찾아 설치하자.
3. (1시간) 이제 아름프로님이 제작해주신 동영상 강의를 들어보자. 아래의 강의를 시작으로 총 7편, 약 1시간 분량이다.
툴 세팅에서 시작해 프로젝트를 만들고 일정 계획, 작업 내용 작성, 팀원에게 분배하고 과제를 진행하기 직전까지의 내용을 다룬다. 즉, 이 동영상을 잘 따라갔다면 RTC와 함께 과제를 시작할 준비까지 된 상태가 된다.
* 위 동영상은 Scrum 에 맞춰 작성되어 Scrum 에 익숙치 않은 사람들은 용어가 낯설 수 있다. 하지만 툴의 활용성을 파악하는데는 지장이 없을 터이니 걱정하지 말자.
4. (20분) 마지막으로 팀에서 작업할 실제 환경에서 RTC 클라이언트를 설치하고 서버에 연결하는 과정을 직접 시연 & 수행해보게 하자. 간략히 이곳저곳 기능을 살펴보며 궁금한 것들을 답해주자.
5. (10분) 작업 서버에 바로 붙어 이것저것 테스트해보기 부담스러워하는 팀원들이 있다면 누구나 테스트해볼 수 있는 Sandbox 사이트를 소개해주자.
Rational Team Concert Sandbox
미리 실제 과제 환경과 유사하게 프로젝트를 세팅해두면 좋고, 처음부터 다 해보고 싶은 사람은 직접 새로운 사이트를 만들어볼 수 있다. (풍차님의 설명 참조)
자~ 이 정도면 빠르게 시작하기 위한 기본은 어느정도 공유가 될 것이다. 이후부터는 사용해보면서 하나하나 배워나가는 기쁨을 누려보도록 하자.
새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].
최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.
그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.
기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.
팀 내의 커뮤니케이션이 제대로 이루어지지 않으면 팀의 생산성에 치명적인 영향을 미침은 모두가 잘 인지하고 있는 사실이다.
제때 피드백을 받지 못해 엉뚱한 일을 하거나, 잘못 (혹은 부족하게) 전달된 정보로 인해 엉뚱한 방향으로 진행되어 낭비하는 시간은 오히려 가볍게 여겨진다.
조직이 커질 수록 다른 문제들이 더 크게 부각되는데, 얘를 들면 이러하다. 관리자는 자신의 역할(관리)를 충실히 하기 위해 수시로 현황 보고를 요청하고, 개발자들은 산재한 정보들을 취합해 보고용 자료를 만드느라 일할 시간일 뺏긴다. 작성해 놓은 정보가 검색이 안되어 사람들이 매번 물어본다. 메일 공지로도 뿌리고 직접 설명해주지만, 당장 필요한 사람이 아니면 귀담아 듣지 않아 같은 일이 무한 반복된다.
이런 문제들을 미연에 방지하기 위해 우리는 다양한 협업 툴들을 활용한다. 하지만 이 툴들을 잘못 선택하면 득보다 해가 되는 경우도 심심치 않으니 많이 알아보고 신중히 정하는 것이 좋다. 당장 사용할 인프라가 급하다면 할 수 없지만, 지속적으로 시장을 모니터링하여 더 나은 솔루션을 발견하면 언제든 변경할 수 있다는 자세를 유지하는 것이 좋다.
툴 선택을 잘못했을 시 발생할 수 있는 문제를 실례를 바탕으로 살펴보자.
다음 표는 A Team 에서 선택해 사용하던 툴들과 Rational Team Concert (RTC) [1] 사용을 고려중인 팀의 상황을 비교하고 있다.
* 파란색은 비교 우위, 적색은 반대를 의미한다. (by feature/usability)
보다시피 A 팀은 제대로 연동되지 않는 10여개의 툴들을 사용하고 있고, 더욱이 각각의 툴의 사용성 또한 좋지 않은 경우가 많다.
여기서 쉽게 예상되는 사태는 ‘정보 분산’ 과 ‘분산된 정보를 취합하기 위한 엄청난 노력’ 이다. 그 노력의 대부분은 당연히 실무자들의 몫이다. 관리자들은 ‘상황을 정리해서 보고하라’ 는 말 한 마디로 보기 좋게 정리된 보고서를 받아볼 수 있다. 관리자의 의욕이 불탈수록 실무자들은 보고를 위해 정작 중요한 업무 진도는 못나가는 사태가 벌어진다.
심각한 문제가 하나 더 있다. Excel 에 정리되어 있는 요구사항은 몇 달에 한 번 꼴로 꺼내어 보고, 태스크는 체계적으로 관리되고 있지 못하다. 업무 부하량도 측정할 길이 없으니 위에서는 생각나는데로 새로운 일을 꽂아준다. 이렇게 일이 진행되다 보면 내가 이 일을 왜 하고 있는지, 옆 사람은 지금 저 일을 왜 하고 있는지 점점 오리무중이 되어간다. 실무자들은 context-unaware 상태에서 수명 업무만을 처리하는 수동적인 자세로 변해간다.
반면 RTC 를 사용하려는 팀은 2~3 개 정도의 툴만으로 훨씬 많은 요소들을 커버하고 있다. 대부분의 데이터는 하나의 DB 에 통합 관리되며사용성 또한 월등히 뛰어나다. 실무자들은 보고에 신경쓰지 않고 열심히 일에 집중한다. 관리자들은 개발자를 방해할 필요 없이 언제건 툴에서 실시간으로 자동 생성해주는 비주얼한 리포트들을 볼 수 있다.
나아가 내가 작업하고 있는 태스크는 어떤 요구사항에서 나왔는지, 관련된 일은 무엇무엇이 있고, 진척률은 어느 정도이고, 우선 순위는 어떻게 되는지 등 자신이 하고 있는 일의 위치를 항시 정확하게 파악할 수 있다. 어떤 요구사항에 결함이 몇 개 있고, 어떤 빌드에 수정본이 반영되어 있는지까지 쉽게 쉽게 추적이 가능하다.
케이스 별로 자세한 work flow 들을 비교해볼까 하다가 너무 길어져서 생락한다.
RTC/Jazz 를 사용하면서 아쉬웠던 것 몇 가지를 뽑자면, 어설픈 통합 메신저와 텍스트 위주의 빈약한 편집 기능이었다.
Lotus Sametime 등 별도 외부 메신저를 쓸 수 없는 사람들을 고려해서 자체 메신저를 좀 더 보강해준다면 더 없이 좋을 터인데.. 그쪽은 아직 우선순위가 높지 않은 듯 하다.. 한창 3.0 계획중이니 요구사항을 올려봐야겠다.
편집 역시 Wiki 정도의 풍부한 표현력을 보여준다면 한층 호응도를 높일 수 있을 것이다. Project Plan 등에서 이미 Wiki 를 사용하고 있어서 이를 work item 편집에도 반영해달라는 요청이 몇 번 있었는데, 이러저런 이유로 당시엔 거절했었다.
아무튼.. Google Wave 소개 동영상을 보고 있자니 RTC 의 단점들을 보완해줄 훌륭한 기술들이 확실해 보인다. 문제는 다른 회사이고 아직은 서로 자신들의 일에 집중하느라 벌써부터 협업을 바라기에는 무리이지 싶다.
IBM Rational 도 소셜 개발이라는 측면을 전혀 고려하지 않는 것은 아니다. RTC 3.0 계획에 이미 OpenSocial 연동 등이 item 으로 잡혀 있고, 지난 8월 25일에 있었던 “Working smarter:Enriching the Jazz environment with social software” (mp3, transcript)라는 텔레컨퍼런스에서도 관련 주제로 이야기가 오갔다. IBM 에선 당연하게도 자사 제품인 Lotus Connections 를 1차 대상으로 삼고 있다.
Google Wave 가 어찌될 진 모르겠지만.. Connections 는 아무래도 상용 제품이다보니 RTC/Jazz 와 잘 융합된다해도, 나와같은 사람은 그 혜택을 얼마나 누릴 수 있을지 짐작하기 쉽지 않다. 또한, Connections 는 Blog, Wiki, Profile 등 기존 유명 소셜 기능들을 잘 묶어놓았다는 느낌 정도이지만, Wave 는 혁신을 함께 수반한 훨씬 멋진 제품이 될 것 같다.
결론은.. 오픈 프로젝트를 하는 사람들이 참 부럽다. 좋은 툴들은 부담없이 사용해볼 수 있고, 접목할 수 있으니.. 나처럼 손가락만 빨고 있을 필요는 없지 않은가. ^^
드디어 RTC 2.0.0.1 이 릴리스되었다.
버전 넘버로만 봐서는 아주 작은 변화이지만, 여타 소프트웨어의 0.0.0.1 변화와는 차원이 다른 진보를 보여준다(New and Noteworthy). 기능적인 변화들도 물론 훌륭하지만, 그 중 내 눈에 가장 들어오는 것은 바로 라이선스 정책의 변화이다.
기업에 이를 적용하려 시도할 때 가장 큰 걸림돌이 바로 라이선스 비용이었다. 심지어 이것 때문에 툴이 얼마나 유용한가 테스트(trial)도 안해볼 정도로 보수적이다. 아래는 이번 릴리스에서 완전 공짜 버전인 Express-C 를 사용할 경우의 라이선스이다.
위 조건이면 소규모 개발팀에서는 프로젝트에 필요한 거의 모든 솔루션이 RTC 하나에 다 묶여 있다는 의미이다. Contributer 라이선스가 무제한이기 때문에, 이를 인터넷에 오픈하면 그대로 고객/개발자간 소통의 장이 된다. 심지어 대규모 개발팀에게도 직접적인 개발을 제외한 기능들이 다 포함되게 된다. 물론 공짜로 말이다.
현 우리 팀에도 다시 한 번 홍보를 해볼 생각이다. 워낙 보수적이고 발등에 떨어진 일 처리에만 급급해서 정말 도입되리란 기대는 많이 않지만 ‘아쉽지~’ 라는 생각은 해볼 수 있게 될 듯.. ^^ 우리 팀에 적용되면 다음과 같은 일들을 처리할 수 있다.
물론 위에 나열한 모든 항목들 각각이 지금 우리 팀에서 사용하고 있는 것보다 훨씬 효율적이고, 서로 유기적으로 연동되어 있다.
Ref: Rational Team Concert 2.0.0.1 released!
WolfPoker 라는 RTC/Jazz 용 Planning Poker 플러그인을 소개해본다.
아직 개발 단계이고, 또 1.x 대 버전만 지원하고 있어서 직접 테스트는 해보지 않았지만 재미있을 듯 하다. 직접 마주 앉아 게임을 진행하는 것이 의사소통면에서 훨씬 빠르고 효율적이므로, 위 플러그인은 아무래도 개발자들이 물리적으로 떨어져 있는 상황이 아니면 크게 활용되진 않을 것 같다. ^^
RTC 2.0 은 Eclipse 3.5 와 거의 같은 시기에 출시되었는데, 아쉽게도 이전 버전인 Eclipse 3.4 버전을 기반으로 하고 있다. 또한 OS X 는 레퍼런스 플랫폼이 아니라 공식적인 지원이 없는 상태이다.
하지만 Linux/Solaris 등 Unix 계열 플랫폼을 이미 지원하고 있고, 다행히도 Eclipse 3.5 와 3.4 의 호환 수준도 높아 몇 가지 간단한 수정만으로 둘 모두와 연동시킬 수 있다.
두 개의 레퍼런스가 있는데, 서로 커버하는 영역이 조금 달라서 모두 소개한다.
크게 보면 위의 것이 둘 모두를 다르고 있지만, repotools 동작 문제에 대해 다루지 않고 있다. 나도 처음에 위의 아티클을 따라 설치 후 사용하고 있었으나, 방금 repotools 수행에서 막혀 정보를 찾아보던 중 두 번째 자료를 발견했다.
