2016년 12월 1일 목요일

원격 개발센터의 장단점 분석

Q: 분석과 설계를 온-사이트에서 하는 방법도 괜찮지 않을까요? 

설계서에는 프로그램명세서가 있어서 개발만 하면 더 편할 수 있을 것 같은데요? 옳은 지적입니다. 그런데, 내부적인 회의에서 개발자가 업무를 모르면 유지보수가 어렵다는 이야기가 나왔습니다. 분석과 설계를 하지 않았기 때문에 업무를 이해하기는 당연히 어렵고, 업무 설명을 위해 한국에서 중간 관리자를 보내는 방안도 고민했는데, 이러다 보니, 아키텍트도 보내고, 품질담당자도 보내고, 인프라 담당자도 보내야 하고, 마치 해외 프로젝트를 하는 것과 똑같더라고요. 본질이 바뀐 겁니다. 그래서, 가장 기본이 되는 것으로 다시 생각하자고 의견을 모았습니다.


<그림3> 원격 개발센터의 이상적 모델의 예 





출처: 한국정보화진흥원 


그림3은 원격 개발센터의 이상적인 모델인데, 온-사이트에서는 요구사항만 명세화하고 원격 개발센터에서 프로젝트를 수행하는 모델입니다. 이러한 모델은 고객이 개발하는 곳을 볼 수 없기 때문에 부가적인 업무가 없어지고 개발자들은 개발에 전문성을 높일 수 있습니다. 하지만, 요구사항 명세서 하나만으로 개발에 필요한 정보를 모두 알 수 없기 때문에 실제 적용하기는 조금 어려운 부분이기도 하지요. 최근에는 이러한 모델에 소프트웨어공학 요소를 포함시켜 해결을 해보자는 노력도 있기는 합니다(그림4). 


<그림4> 소프트웨어공학적 요소가 적용된 원격 개발센터 


Q: 그림4의 경우는 어떠한 요소가 들어갔는지 설명을 부탁 드립니다. 

그림3이 적용되기 어려운 이유는, 첫째 온-사이트와 원격 개발센터 간의 의사소통이 문서만 왔다갔다 하면서 끝난다는 것이고, 둘째는 요구사항 명세서가 매우 불명확할 것이라는 것, 마지막으로 원격 개발센터가 테스트를 마쳐도 온-사이트에서 잘 돌아갈 것인가 하는 것입니다. 이런 부분을 보완하기 위해 애자일을 도입해서 커뮤니케이션과 반복, 점진을 통해 원활한 의사소통이 이루어지도록 하고, 사용자 스토리 워크샵을 적용해 요구사항을 온-사이트와 원격 개발센터 모두에서 이해할 수 있도록 수준을 높이고, 마지막으로 TDD(Test Driven Development)를 통해 온-사이트와 원격 개발센터의 테스트 케이스를 동일화하여 문제 발생 여지를 줄이는 노력을 하게 됩니다. 




DevOps 환경 을 위한 시스템 & 프랙티스

빌드/배포 시스템

배포 솔루션


JARVIS 모듈 아키텍처




애자일과 전통적 개발방식의 조화

SW 개발에서 나타나는 전형적인 이슈와 문제점

1.프로젝트일정및태스크공수추정의신뢰성부족
2.업무성과및품질불량으로관리자와팀원간의갈등발생
3.수동적인팀원들의자세및낮은사기
4.프로젝트및팀구성원들간의소통및협력부족
5.요구사항의불확실성과잦은변경
6.개발산출물및업무회의과다
7.고객및사용자의참여부족
8.진척상황의불투명성

1. 프로젝트일정및태스크공수추정의신뢰성부족

•전형적인일정및공수추정형태
–소수의개발리더(전문가)를중심으로단독추정
–경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발

•문제점
–리더가본인이나잘하는사람을기준으로공수를추정하다보니항상프로젝트공수가부족
–개인의편차가심하며공수추정의신뢰성이떨어짐
–알려지지않은(Unknown)리스크를고려한일정버퍼가부족

•애자일해법
–전문가집단추정(Planning Poker )기법을활용하여평균공수를추정함으로써추정의신뢰성을향상
–평균공수추정에따른일정산정과알려지지않은(Unknown)리스크를고려한일정버퍼삽입

2. 업무성과및품질불량으로관리자와팀원간의갈등발생

•전형적인갈등상황
–팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완료기준이서로상이함
–태스크초기일정미준수에따른비난이나질책이발생
–팀원이수행한태스크점검시결함이자주발생하는것에실망

•애자일해법
–스프린트계획시고객및리더, 팀원이함께토론하여해당업무혹은요구사항에대한완료기준을명확하게설정함(Test Driven)
–리더는태스크일정수행의불확실성을인식하고태스크장애요소해결에집중
–업무수행에대한책임을개인책임보다는팀책임으로설정하고
–완료조건에크로스및QA테스트검증포함