Agile 개발방법론은 패키지 제품개발과 SI프로젝트에 Silver bullet이 될수 있는가?

[longtail]

안녕하세여!
아주가끔 xper모임에 참석했던 다우기술에서 품질관련 업무를 담당하고 있는 이승호 라고 합니다.

김창준 대표님과 채수원 차장님과는 인연이 좀 있습니당. ^^

제가 받은 미션은 회사에서 내년에 SI 공공 프로젝트에 사업 기회를 넓히려고
하다보니 관련하여 품질관리 체계를 요구하고 있다는 것입니다.

회사 패키지 제품에 대한 개발 방법은 Agile의 철학과 Practice들을 개발자들이 도입 및
활용해 가면서 조금씩 내재화해 나가는 단계에 있고 개선할 사항에 대해서는 협업과정을 통해
피드백과 개선을 개발방법에 지속적으로 적용하도록 하고 있습니다. 더불어 측정할수 있는 것들은
개발자 스스로 확인하고 개선해 나가도록 환경을 구성해주고 있습니다. 하지만
SI프로젝트는 경험이 없어서 과도한 관리프로세스와 다양한 방법론 수립 및 프로젝트
수행조직에 품질 교육을 요구하고 있고 실 프로젝트에 참여하여 산출물과 프로세스를 검토하는
활동들을 요구하고 있습니다.

제가 궁금한 사항은 혹 몸담고 계시는 회사의 품질관리 조직이 패키지 제품과 SI프로젝트의
품질관리 체계를 각각 어떻게 운영해 나가고 계시는지 또는 SI 프로젝트를 지원하기 위해 필요한
역량을 어떻게 개발해 가고 있는지 알고 싶어서 글을 올려봅니다.

xper모임에서 다루기에 주제가 적당한지 모르겠네여.

[글뻥]

안녕하세요? 글뻥입니다.

패키지 쪽보다는 SI쪽 PM을 장기간 했었었습니다.

현재도 게임쪽에 몸담고 있지만, SI성 개발도 같이 하고 있구요.

(자다가 일어나서 횡설 수설될 것 같아요.)

SI와 게임이라는 패키지를 둘다 개발하고 있는 입장에서 말씀드리자면, 

SI와 패키지 둘다 같은 개발이기에 별도의 프로세스가 있지는 않습니다.

단지 프로젝트 스폰쉽이 내게 있는가? 아니면 외부 큰손에게 있는가의 차이점 정도일까요?

(너무 잘 아시는 내용일테니 요점만 말씀드리면 )

* SI프로젝트 관리 = 인재 + 일정 + 예산 + 품질 + 커뮤니케이션 5가지를 관리하구욤.

* 패키지 프로젝트 관리 = 인재 + 일정 + 예산 + 품질 + 커뮤니케이션 + 마케팅 6가지를 관리하는 정도라고 생각합니다.

물론 SI프로젝트의 경우 마케팅이 사전 프로젝트 범위에 들어가는 정도가 다를까요? 

품질에만 집중한다고 하면 www.kdb.or.kr/info/info_01_07_download.php?dbnum=61 에서와 같이 법률에 의거 SI관리는 FM으로 하게 되어 있습니다.

그중 핵심 관리 영역은

1. 사업관리 (공통)

2. 시스템아키텍쳐

3. 응용시스템

4. 데이터베이스

5. 시험활동

6. 운영준비

로 반드시 문서로 작성되어 활동 내역을 증빙해야 합니다.

(이 영역은  패키지라고 한들 다른 형태가 될 뿐 틀리지는 않다고 생각됩니다.)

정확하게는 국가에서 2가지 방법론을 인정하고 있는데.

정보공학방법이라면 168(페이지), 181, 196, 206, 219, 234, 244, 256, 267, 282 에 있는 문서 목록들이 개발에 관련된 문서들이며,

CBD, OOP라면 292, 302, 314, 324, 338, 361, 378, 388, 400, 에 있는 문서들이 개발문서

공통인 품질관리 411,  426, 438, 448, 460 (분석,설계,구현,시험,전개 단계별로...) 또하나의 공통인 사업관리는 563, 580 에 있는

관리 문서가 Full Package 입니다.

엄청 머리아프죠 -_-;;

그래서 일반적으로 SI에서는 빠져나갈 구멍을 만들어 놓습니다. 구체적으로 설명드리면, 

제안요청서 (고객) -> 제안서 (업체) -> 입찰후 우선순위 협상 (쌍방) -> 계약 (쌍방) ->

과업내역서 (고객) -> 사업수행계획서 (업체) -> 사업시작 (쌍방, 요구사항>설계>개발>단위테스트>인수시험 단계별)

-> 이행 (쌍방) -> 종료선언(쌍방)

의 단계에서 SI의 경우는 "테일러링 내역서"라는 걸 사업수행계획에 한 단원으로 껴놓거나 별도의 문서로 작성해 둡니다.

테일러링 내역은 감리기준을 완화하기 위해 고객과 합의한 산출물의 형태 및 품질을 정의해 놓는 문서로

향후 모든 산출물을 추적할 수 있는 추적매트릭스의 근원이 되는 "문서"입니다.

제 경우는 이를 활용 모든 문서를 UML로 통합해서 작성하였었습니다.

기타 필요한 내용은 Wiki에 기록하고 Jira에서 진행관리를 했구요.

따라서, 별도의 오프라인 문서가 거의 작성되지 않았던 덕에 현재 가지고 있는 문서의 수도 거의 없는 상태입니다. =)

일전에 정리했던 문서 산출물의 종류입니다.

http://www.wolfpack.pe.kr/597 

부언하면, (중요한건 V모델입니다. http://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8)

- USE CASE : 1개의 요구사항이 1개의 USE CASE가 됩니다.

- Activity Diagram : 1개의 USE CASE는 1개의 Activity Diagram이 됩니다. Activity Diagram은 USE CASE를 테스트할 수 있으며 V모델에 따라 인수시험 테스트 계획서로 사용됩니다. 또한 이렇게 Method와 Activity 중심으로 분해하면 Class Diagram에 직접적인 영향으로 줍니다. 

- Class Diagram : Activity Diagram에서 분해된 Method와 Entity를 토대로 업무영역별로 재 분류한 형태입니다. 이걸 우리는 설계서라고 하죠. 개발팀은 Class Diagram으로 코드를 생성합니다.

- Sequence Diagram : Class Diagram과 직접적인 연관관계로 V모델에 따라 Unit Test 계획서가 됩니다. 

결국 코드와 관련된 문서는 4가지 UML로 통합이 가능합니다.

=) 현재 게임도 변형된 UML산출물로 개발하고 있습니다.

좋은 결과 있으시길 바랍니다.

궁긍하신 점이 있으시다면 vicvi...@gmail.com이나 vicv...@live.co.kr로 부탁드립니다. =)

2012년 7월 10일 화요일 오후 4시 35분 46초 UTC+9, longtail 님의 말:

[longtail]

안녕하세여! 정말 디테일하게 많은 얘기를 써주시고 관련 자료까지 제공해 주시니

많은 도움이 된것 같습니다. 앞으로도 궁금한 사항은 제공해주신 메일로 문의드리겠습니당 ^^

그런데 한가지 이해 않되는 부분이 있습니다.
내용중에 " 모든 문서를 UML로 통합해서 작성" 하였다고 하는 부분에서 모든 문서라함은
설계문서를 얘기하시는 건지 아니면 개발단계 전체 문서를 의미하는 것인지 전체문서라면
그것을 어떻게 UML로 작성했는지가 이해가 좀 않됩니다.

감사합니다.

On 7월10일, 오후10시07분, 글뻥 <vicvipe...@gmail.com> wrote:
> 안녕하세요? 글뻥입니다.
> 패키지 쪽보다는 SI쪽 PM을 장기간 했었었습니다.
> 현재도 게임쪽에 몸담고 있지만, SI성 개발도 같이 하고 있구요.
> (자다가 일어나서 횡설 수설될 것 같아요.)
>
> SI와 게임이라는 패키지를 둘다 개발하고 있는 입장에서 말씀드리자면,
> SI와 패키지 둘다 같은 개발이기에 별도의 프로세스가 있지는 않습니다.
>
> 단지 프로젝트 스폰쉽이 내게 있는가? 아니면 외부 큰손에게 있는가의 차이점 정도일까요?
> (너무 잘 아시는 내용일테니 요점만 말씀드리면 )
>
> * SI프로젝트 관리 = 인재 + 일정 + 예산 + 품질 + 커뮤니케이션 5가지를 관리하구욤.
> * 패키지 프로젝트 관리 = 인재 + 일정 + 예산 + 품질 + 커뮤니케이션 + 마케팅 6가지를 관리하는 정도라고 생각합니다.
>
> 물론 SI프로젝트의 경우 마케팅이 사전 프로젝트 범위에 들어가는 정도가 다를까요?
>

> 품질에만 집중한다고 하면www.kdb.or.kr/info/info_01_07_download.php?dbnum=61에서와 같이

> 부언하면, (중요한건 V모델입니다.http://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8)

> - USE CASE : 1개의 요구사항이 1개의 USE CASE가 됩니다.
> - Activity Diagram : 1개의 USE CASE는 1개의 Activity Diagram이 됩니다. Activity
> Diagram은 USE CASE를 테스트할 수 있으며 V모델에 따라 인수시험 테스트 계획서로 사용됩니다. 또한 이렇게 Method와
> Activity 중심으로 분해하면 Class Diagram에 직접적인 영향으로 줍니다.
> - Class Diagram : Activity Diagram에서 분해된 Method와 Entity를 토대로 업무영역별로 재 분류한
> 형태입니다. 이걸 우리는 설계서라고 하죠. 개발팀은 Class Diagram으로 코드를 생성합니다.
> - Sequence Diagram : Class Diagram과 직접적인 연관관계로 V모델에 따라 Unit Test 계획서가 됩니다.
>
> 결국 코드와 관련된 문서는 4가지 UML로 통합이 가능합니다.
> =) 현재 게임도 변형된 UML산출물로 개발하고 있습니다.
>
> 좋은 결과 있으시길 바랍니다.
>

> 궁긍하신 점이 있으시다면 vicvipe...@gmail.com이나 vicvi...@live.co.kr로 부탁드립니다. =)

[글뻥]

안녕하세요?

- 감리 해설서 18페이지를 보시면 위의 이미지가 보일겁니다.

- 사업유형/감리시점 : 시스템 개발 (SD), 김리영역은 "시스템아키텍쳐", "응용시스템", "데이터베이스", "시험활동", 감리관점/점검기준은 산출물에 대해 UML통합이 가능합니다.

- 사업관리와 품질보증활동은 따로 설명드릴께요.

시스템 개발사업은 2가지 사업유형으로 나뉩니다.

"구조적/정보공학적 모델 (Waterfall)"과 "OOP, CBD기반 모델" (21, 22페이지, 상세하게는 26~28페이지, 29~30페이지) 에 있는 산출물을 UML로 통합이 가능하다고 말씀드린겁니다.

- 품질관리활동은 

 . 사업목표가 수립되었는가? (사업수행계획서로 증명)

 . 방법론 절차수립 (테일러링 내역서로 증명)

 . 방법론 맟 절차준수 했는가? (인스펙션(동료검토) 내역으로 증명)

 . 품질보증활동계획, 수행했는가? (인스펙션 내역으로 증명)

 . 반복계획 수립, 평가, 계획 (인스펙션 내역으로 증명)

 . 총괄시험 계획 (이건 UML에 Activity Diagram으로 증명)

 . 요구사항추적 (UML을 USE Case Driven으로 그리면 해결됨)

 . 전환계획 (이행계획이라고도 하며 이것 역시 고객과의 회의록을 남겨 놓으면 되요)

 . 사업목표달성 (인수시험서로 해결가능)

 . 교육계획/사용자교육 (이건 보안/시스템사용 2가지 측면에서 계획과 수행을 합니다.)

 . 인수운영조직 (이건 고객에 요청했다는 증빙만 있으면 됩니다.)

- 남은 사업관리는 

 . 범위/변경관리 (사업수행계획서의 버전관리 또는 UML의 USE CASE 버전관리)

 . 일정관리/진척관리 (WBS를 작성하되 주의점은 1개의 Task는 2Weeks 이하로 작성되어야 합니다.)

 . 자원관리/인력관리 (사업수행계획서에 챕터로 넣어두시면 됩니다.)

 . 의사소통관리 (이것도 사업수행계획서에 의사소통계획으로 인스펙션(동료검토)로 통합 )

 . 위험관리 (이건 인스펙션(동료검토)로 통합)

 . 품질관리 (이건 단위테스트 계획과 통합(인수)시험 계획으로 대체)

이렇게 통합하고 안하겠다고 한 과정을 기록하는게 "테일러링 내역서"입니다.

요걸 고객에게 도장 받으면 최종적으로 작성하셔야 할 문서와 이를 Agile의 반복 개선을 적용하면 

위와 같이 정의가 가능합니다.

잦은 중간보고와 노란색 영역을 반복하면 됩니다.

애자일 하기 싫다면 노란색 부분을 반복하지 않으면 됩니다.

시간이 허락하면 더 많은 정보를 드리고 싶습니다만.. 저는 이만... =)

2012년 7월 12일 목요일 오후 1시 40분 4초 UTC+9, longtail 님의 말: