2016년 7월 12일 화요일
솔루션 개발을 위한 프로세스 개선 활동
소프트웨어를 만드는 회사가 어느 정도 안정기에 도달하면 개발과 품질 프로세스에 대해 관심이 많아지는 것이 일반적이다. 완성된 소프트웨어가 계속 누적된다면 프로세스에 대한 필요성을 더 느끼게 된다. 좀 더 체계적인 형태로 소프트웨어를 만들고 관리하면 불필요한 요소가 줄어들고 품질이 더 향상될 것이라는 기대감 때문이다. 이처럼 소프트웨어 개발 프로세스에 대한 요구는 날로 증가하고 있지만 실제 적용을 통해 성공한 사례는 많지 않은 경우도 사실이다. 반드시 필요한 부분이기도 하지만 이로 인해 발생하는 관리적인 요소도 많다는 것이 적용 해봤던 회사들의 의견이다. 이번 회에서는 소프트웨어 개발 프로세스를 올바르게 적용해서 성공할 수 있는 방법이 무엇인지에 대해 사례를 보며 살펴보기로 한다. 사례 적용에 참여했던 ㈜Coocon의 한용만 박사를 만나 자세한 사항을 들어본다.
Q: 사례를 살펴보기 전에 소프트웨어 개발에 프로세스가 필요한 이유에 대해 간략히 설명해 주시죠.
소프트웨어를 개발하기 전에 준비하는 것은 생각보다 많습니다. 일반적으로, 요구사항과 인프라 환경, 그리고 제반 사항이 모두 적힌 RFP나 제안서를 보면서 준비를 하게 되는데요. 프로세스가 필요한 이유를 두 가지 관점으로 말한다면 먼저, RFP나 제안서에 적힌 요구사항대로 잘 만들고 있는지 계속 확인을 하면서 진행을 하기 위해서입니다. 아무래도 오랫동안 개발 일정이 지나고 많은 개발 작업을 하다 보면 본의 아니게 놓치는 경우가 당연히 생겨납니다. 이러한 경우를 방지하기 위해 사용하게 되고요. 또 한가지는 개발되는 과정을 체계적으로 정리하려는 목적도 있습니다. 이렇게 정리된 것으로 품질이나 나중에 재사용에서 유용하게 쓸 수 있습니다. 정리하자면, 고객 관점에서도 필요하고 개발팀 관점에서도 필요한 것이기 때문에 프로세스는 소프트웨어 개발에서 반드시 필요한 요소입니다. 각 회사의 개발 노하우나 프로세스를 표준화 한 것이 개발방법론입니다.
Q: 프로세스는 소프트웨어 개발에서 매우 중요한 요소로 보이는데요. 그런데, 많은 개발자들이 프로세스나 개발방법론에 대해 거부감을 나타내는 경우가 많습니다. 그 이유는 무엇일까요?
한마디로, 프로세스나 개발방법론에 문서 작업이 많기 때문입니다. 대개의 개발자들은 소프트웨어 개발만 하기를 소망합니다. 개발자들에게 프로세스나 개발방법론은 문서 작업만 하는 불필요한 일이라고 생각할 수 밖에 없지요. 많은 학자나 전문가들이 이를 해결하기 위해 많은 노력을 했지만 개발자 입장에서는 해결할 방법이 없는 것이 맞는지 모릅니다. 그래도, 최근에는 애자일과 같은 다양한 방법들이 나오면서 조금씩 해소가 되는 중이라고 볼 수 있습니다.
이러한 거부감을 해결할 포인트는 개발자에게 불필요한 것을 하지 않게 하는데 있습니다. 매우 어려운 문제이기도 하지만 프로세스나 개발방법론을 적용해야 한다면 불필요한 문서 작업만 줄여도 개발자의 불만은 매우 줄어들 겁니다. 개발자 입장에서도 문서 작업이나 개발 외 작업이 필요하다라는 공감대를 갖도록 하는 것이지요.
사용자 스토리 워크샵 사례 연구 - 비전 수립 & 피쳐 정의 편
사용자 스토리 워크샵(User Story Workshop)은 사용자(고객)와 개발자 간의 커뮤니케이션을 강조하면서 서로 원하는 것이 무엇인지 빠르고 정확하게 찾아내려 한다. 그리고, 그 중에서 가장 강조하는 부분은 공감대 형성이다. 사용자 스토리 워크샵에서는 만들고자 하는 소프트웨어의 비전과 비즈니스 목적에 대해 공감대를 가져야 한다. 이전의 개발 프로젝트에서 많은 프로세스와 산출물로도 커뮤니케이션이 잘 되지 않았던 가장 큰 이유가 바로 공감대 형성의 시간이 없었기 때문이다. 이번 회에서는 사용자 스토리 워크샵의 비전 수립과 비즈니스 목적을 정의하는 방법과 이 것이 피쳐 정의에 어떤 영향을 미치는지 살펴보기로 한다. 명확한 비전 공유로 애자일 기반 프로젝트의 성공률이 높아지기를 기대한다.
사례 연구 전 확인 사항
비전 수립의 필요성
공감대를 형성한다는 것은 같은 목표를 가지고 같은 방향으로 나아간다는 것을 의미한다. 하나의 목표와 방향을 비전으로 나타낼 수 있다(그림1). 이렇게 정해진 비전은 소프트웨어 개발 프로젝트가 종료될 때까지 가급적 변해서는 안 된다. 비전이 변경된다는 것은 개발 프로젝트 구성원들의 공감대가 깨진다는 것을 의미하기 때문이다.
피드 구독하기:
글
(
Atom
)