블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


ALM 에서 각 기능들은 필수인가?

ALM | 2009. 7. 3. 10:07 | Posted by 조대협

KX사의 프로젝트에서는 Bugzilla
S사의 프로젝트에서는 JIRA + Hudson + xUnit
H사의 프로젝트에서는 JIRA + Confluence + Bamboo + xUnit 
또다른 H사의 프로젝트에서는 JIRA + Hudson + xUnit + Mantis
S사의 프로젝트에서는 Confluence + Hudson + xUnit
K사에서는 DokuWiki
지금 K사의 프로젝트에서는 Trac 

매번 프로젝트마다 ALM 툴셋을 바꿔가면서 사용해보고 있습니다. 제품들을 실제 경험해봄으로써 최적의 조합을 찾기 위함입니다.

그런데, 프로젝트를 하면서 ALM을 적용하면서 깨달은것중의 하나가, ALM의 4개의 Module을 꼭 모두 적용할 필요가 없다는 것입니다. 프로세스나 사상을 기반으로 하되 프로젝트의 특성에 따라서 필요한 모듈만 사용하면 된다는 것입니다.

Issue Tracker를 이용한 Task Management의 경우, 팀의 규모가 적어도 5인 이상이 되고, 이슈가 많을 경우 즉 추적성을 많이 필요로 하고 Task에 대한 공유가 도구 없이 통제할 수 있는 범위를 벗어나는 경우에만 도입하는 것이 유리합니다. 그렇지 않을 경우 Task Logging하는 것 자체가 Burden이 될 수 있습니다. 특히나 Issue Logging에 대해서는 일정기간 개발자들이 시스템에 익숙해지는 Learning Curve에 대한 시간이 필요하기 때문에, 그 전에는 Excel 을 이용한 Scrum 방법론 기반의 팀 운영 방식이 가장 효율적입니다. 

빌드 자동화의 경우 개발이 있는 경우는 대부분 긍정적입니다. 투자되는 시간대비 효과가 좋습니다. 단 이는 개발 중심의 프로젝트인 경우입니다. EAI와 같은 솔루션 기반의 시스템 개발의 경우 코딩 보다 솔루션의 기능을 사용하는 경우가 많기 때문에 이러한 경우에는 CI의 필요성이 반감됩니다.

테스트 자동화의 경우도 마찬가지입니다. In-House 개발의 경우에는 효과가 좋습니다. 그리고 팀원이 많을수록 품질관리에 대한 요구 사항은 올라가기 마련이지만 소규모 팀의 경우 Sprint (주기)를 짧게 나눠서 Short Release를 하면서 매번 테스트를 하는 것이 단위 테스트 구현이나 테스트 자동화 보다 훨씬 효율적입니다. JUnit을 만든 Kent Beck역시 JUnit Max를 만들면서 단위테스트가 모든 프로젝트에서 필요하지 않다는 것을 언급한적이 있습니다.
 제가 제시하는 방안은 시스템에서는 몇가지 대표적인 구현 패턴이 존재합니다. 이런 패턴들을 프로젝트 초기에 Prototyping을 하고 아키텍쳐 검증이라는 이름으로 테스트를 진행해서 해당 패턴의 아키텍쳐 적인 특성을 검증합니다. 이 단계에서는 기능적인면보다는 성능,장애,안정성에 대한 비기능적 테스트를 위주로 함으로써 아키텍쳐의 위험성을 초기에 검출하여 해결안을 찾아내고 RISK를 조기에 없앱니다. 검증된 패턴에 대해서 개발자들이 찍어내기식의 개발을 하게 되는데, 이미 검증된 아키텍쳐이기 때문에, 비기능적 요건에 대해서는 테스트를 할 필요가 없고, 기능적으로 되냐 안되냐만 검증을 하면 됩니다. 필요할 경우에만 기능 위주의 단위 테스트를 적용하도록 합니다.

모든 기술과 이론은 "꼭 이래야 한다" 라는 것은 없는 것 같습니다. 상황과 조건에 따라서 적절하게 사용해야 그 효과가 극대화 되는 것 같습니다.

다음 프로젝트에서는 Polarion을 도입해서 사용해봐야 겠습니다.




'ALM' 카테고리의 다른 글

관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14
Trac  (2) 2009.04.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG

댓글을 달아 주세요

  1. Green 2009.07.03 11:32  댓글주소  수정/삭제  댓글쓰기

    글 잘 읽었습니다.
    상황에 맞는 최적의 조합을 찾기가 매우 어려운것 같습니다.
    지적허영심이나 과시욕에 의해 방해를 받기도 하구요..
    필요한 경우에만 단위테스트를 적용한다는 내용도 신선한 것 같습니다.
    단위테스트도 실제로 쓰다보면 과도한 부담이 되는 경우가 많거든요..
    그 필요한 경우의 시각차가 클수도 있겠지만요..
    테스트 커버리지의 범위도 생각을 해야 할 것 같습니다.

    • 조대협 2009.07.03 11:49 신고  댓글주소  수정/삭제

      특히 커버러지는 Middleware같이 각각의 모듈이 기능적으로 유일한 경우에는 80% 이상 가는 것이 맞겠지만 일반적인 엔터프라이즈 애플리케이션이나 웹애플리케이션의 경우 아키텍쳐적인 특성이 대부분 동일하기 때문에 주요 업무 30~40%만 커버해도 충분하리라 생각됩니다. (사견입니다.)