Q: 분석과 설계를 온-사이트에서 하는 방법도 괜찮지 않을까요?
설계서에는 프로그램명세서가 있어서 개발만 하면 더 편할 수 있을 것 같은데요? 옳은 지적입니다. 그런데, 내부적인 회의에서 개발자가 업무를 모르면 유지보수가 어렵다는 이야기가 나왔습니다. 분석과 설계를 하지 않았기 때문에 업무를 이해하기는 당연히 어렵고, 업무 설명을 위해 한국에서 중간 관리자를 보내는 방안도 고민했는데, 이러다 보니, 아키텍트도 보내고, 품질담당자도 보내고, 인프라 담당자도 보내야 하고, 마치 해외 프로젝트를 하는 것과 똑같더라고요. 본질이 바뀐 겁니다. 그래서, 가장 기본이 되는 것으로 다시 생각하자고 의견을 모았습니다.
<그림3> 원격 개발센터의 이상적 모델의 예
출처: 한국정보화진흥원
그림3은 원격 개발센터의 이상적인 모델인데, 온-사이트에서는 요구사항만 명세화하고 원격 개발센터에서 프로젝트를 수행하는 모델입니다. 이러한 모델은 고객이 개발하는 곳을 볼 수 없기 때문에 부가적인 업무가 없어지고 개발자들은 개발에 전문성을 높일 수 있습니다. 하지만, 요구사항 명세서 하나만으로 개발에 필요한 정보를 모두 알 수 없기 때문에 실제 적용하기는 조금 어려운 부분이기도 하지요. 최근에는 이러한 모델에 소프트웨어공학 요소를 포함시켜 해결을 해보자는 노력도 있기는 합니다(그림4).
<그림4> 소프트웨어공학적 요소가 적용된 원격 개발센터
Q: 그림4의 경우는 어떠한 요소가 들어갔는지 설명을 부탁 드립니다.
그림3이 적용되기 어려운 이유는, 첫째 온-사이트와 원격 개발센터 간의 의사소통이 문서만 왔다갔다 하면서 끝난다는 것이고, 둘째는 요구사항 명세서가 매우 불명확할 것이라는 것, 마지막으로 원격 개발센터가 테스트를 마쳐도 온-사이트에서 잘 돌아갈 것인가 하는 것입니다. 이런 부분을 보완하기 위해 애자일을 도입해서 커뮤니케이션과 반복, 점진을 통해 원활한 의사소통이 이루어지도록 하고, 사용자 스토리 워크샵을 적용해 요구사항을 온-사이트와 원격 개발센터 모두에서 이해할 수 있도록 수준을 높이고, 마지막으로 TDD(Test Driven Development)를 통해 온-사이트와 원격 개발센터의 테스트 케이스를 동일화하여 문제 발생 여지를 줄이는 노력을 하게 됩니다.
댓글 없음 :
댓글 쓰기