[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 을 지원하는 툴로써 현 시대 제품들을 평가해본 결과이다.
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 들을 비교해볼까 하다가 너무 길어져서 생락한다.
