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

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을 도입해서 사용해봐야 겠습니다.