안녕하세요.
우선 저는 코딱지만한 회사에서 쥐꼬리만한 급여를 받으며 QA 그룹내에서 분배 받은 프로젝트에 대하여 ...
QA 및 Testing 설계/바쁠땐 수행까지 업무를 맡고 있습니다.
Agile 스크럼을 처음 도입하고 프로젝트를 진행하면서 겪었던 소감 및.. 장/단점을 한번 적어 보고자 합니다..
근 1년 정도를 진행했던 프로젝트가 몇일전에 "우선" 완료 되었습니다.
프로젝트 참여 인원은 Web / Client / Server / QA / TE 포함하여 총 40명 정도가 참여 하였습니다.
1. Agile 은 무엇인가요 ?
- Agile 은 단어 그대로 '민첩한' '날렵한' 이라는 뜻을 가지고 있습니다. 기존의 국내 프로젝트는 보통 폭포수 또는 나선형 개발론을 중심으로 진행되었었죠.. 기존 프로젝트 진행 방법은 대략적으로..
발주처에서 요구사항을 정의하고 기획에서 요구사항에 대한 전체적인 구도를 잡고 그 구도를 아키텍쳐 들이 설계를 하며, QA 는 그 아키텍쳐
산출물을 검토합니다. 그리고 그 산출물을 기반으로 개발 알고리즈머 는 개발에 대한 실 설계를 하고, QA 는 각 포지션 별로 이슈사항을 체크하며 일정 또는 이슈에 대한 조정을 합니다. 알고리즈머에게 나온 산출물로 TE 는 테스팅 방법론을 선정하고 그에 맞는 기법을 도입하여 TC 를 작성하고 V 모델에 따른 검증 수행 및 결함 도출 -> 수정 -> 재 검증 을 반복하여 최초, 발주처에 요구사항에 만족하며, 상품으로써의 최소한 기능을 하는 상태가 완료되면 납품을 합니다.
하지만 이런 방식의 진행은 문서 작성에 대한 시간 소요 및 중간에 구조설계에 대한 결함이 발견되었을 경우에는 그만큼 시간이 딜레이되는 단점이 있어 헬 of 헬을 경험할 수 있는 치명적 단점 이 있습니다.
그렇기에 시간대비 효율성이 높은 Agile 이 핫하게 떠오른 것이죠...
2. 진행방법
- 모든 담당자들은 매주 월 / 금 전체 회의를 한다.
- 각 파트별로 데일리 회의를 통하여 이슈를 공유 한다.
- 이슈관리 프로그램 (Jira , Mantis , 등) 을 적극 활용한다.
- 각 목표치로 설정한 부분에 대하여 이행 불가능할경우 사전 공지
(1) PS 0
- 최초 회의 각 파트별로 인사 및 전체 프로젝트 요구사항에 대한 PM / QM 의 설명
- 프로젝트 요구사항에 따른 각 파트별 아키텍쳐 들의 초안 다음 회의 때까지 준비
(2) PS 1
- 각 파트별 아키텍쳐들의 아키텍트 설계에 대한 공유
ㄴ 파트별로 아키텍트들의 상이 점과 기술적으로 해결할 수 없는 부분에 대한 협의 및 재 설계
ㄴ 아키텍트의 논리적 결함 발견 및 해결방안에 대한 파트 논의
- 아키텍쳐 들의 수정안 다음 회의 때까지 준비
(3) PS2
-각 파트별 알고리즈머들의 실 구현 알고리즘에 대한 기능/명세 정의
ㄴ 파트별로 Clinet - DB 간의 객체 규칙 정의
ㄴ 개발자들의 각 해당 영역 분배 및 mm으로 단위 할당
ㄴ 개발자들의 각 해당 영역은 이슈관리프로그램을 통하여 한개의 기능에 CR 매칭
ㄴ CR 에 대하여 검증팀 분배 및 분석 및 테스팅 설계
- 국제표준에 따른 준수도 각 파트별 공유
<----> 무한 반복
(4) PS L(Last)
- 각 파트별 이슈사항 공유
- 진척률 에대한 최종 합의
- 통합 및 시스템 검증에 대한 설계
(5) PS D(D-day)
- 전체 프로젝트 기간의 이슈사항 정리
- 신규 도입 또는 리펙토링한 기술에대한 공유
- 국제표준에 따른 준수도 각 파트별 최종 평가
3. 장점단점
(1) 장점
- 회의시간은 지루하지만 완성된 문서를 검토하여 - Reject 할 경우보다 시간 소요도가 훨씬 적어 조금더 양질의 최초 설계가 가능
- 각 이슈가 공유 되어 각 파트별로 대응시간이 빠름
- 통합 / 시스템 / 인수 / 시나리오 별 테스팅때 전혀 예상치 못한 심각한 결함 도출이 매우 감소 (품질향상)
- 각 이슈에 대한 누적으로 운영관리에 용이
(2) 단점
- 중간중간 QA/TE 문서 작업량이 매우 많아짐
- 매우 작은 컴포넌트 단위를 쪼개서 진행하기 때문에 TE 입장에선 버전 관리 및 형상관리가 매우 힘들어짐
- 유닛 > 컴포넌트 > 통합 단위로 갈수록 연동부분에 대한 영역 으로 인하여 재수행 관련된 케이스 증가로 검증팀의 분량은 늘어남
(유닛단계에서 PASS 라고 하여도, 연동부분에 대하여 기존 수행한 케이스에 대하여 재 수행이 필요하기때문에 [커버리지] 최종적으로
수행시간이 늘어남)
- 프로젝트 후반으로 갈수록 초반에 꽃으로 칭송받던 여직원들의 황폐/ 폐인화
4. 진행후기
Agile 스크럼 개발론 도입은 색다르기도 했고 좋은 경험을 많이 한 계기가 된 것 같습니다. 최초에 작성된 TC 라던가 자동화 부분에 있어
변경하는 구조에 따른 대응으로 인하여 일거리는 많이 있었지만
프로젝트 안전종료 목표치인 5% 를 훨씬 만족하는 전체 기능에 대한 1% 발생도를 기준으로 프로젝트가 마무리가 되었네요
다만, 가장 큰 단점은... QA / TE 활동을 입증하기에 어려움이 있다는거죠..
그리고 큰 프로젝트에 도입하기에는 여러모로 어려움이 있는 것 같습니다. ~~~
혹, Agile 을 도입해보셨던 오유인이 있다면 공유를 부탁 드립니다 :D
(CMMI 규정 준수하며 프로젝트 진행하는 분이 있다면 마찬가지로 노하우 공유 부탁드려요)
-------------------------------------------------------------------------------------------------------------------
생소하게 들릴수도 있는 QA 라던가 TE 라는 단어를 설명 드리자면...
QA : quality assurance 의 약어 이며, 품질보증 즉, 어떠한 제품이 생산 되기까지의 품질에 대하여 보증 (책임) 을 지는 업무 입니다.
IT 업계에서는 SQA..QA 등 다양하게 불리고 있고 사실 한국에서는 QA 나 TE 라 그게 그거라는 인식을 가지고 있죠..
TE : test engeneer 의 약어 이며, 보통 QA 그룹 산하에 존재 합니다. 제품이 상품으로써의 가치를 갖게되는 최소하는 기능(?) 을 만족할 수 있도록
여러 방법론을 도입하여 제품의 이상현상을 찾아내는 직군이죠.
* QA 는 쉽게 제품이 만들어지기까지의 공정에 대한것에 대하여 가장 최적의 방법론을 찾고 설계하고 도입하는 Process 에 대하여 활동을 하는 직군이고
TE 는 제품이 만들어지는 과정에서 각 과정별로 정상적으로 (요구명세서, 기능정의서 등등) 사전 정의된 기능을 만족하는지 방법론을 대입하고 해당 검증 영역 및 방법을 생각하여 사전에 발생할 수 있는 결함을 찾아내는 직군 입니다.
* 소프트웨어 공학 8장이나 6sigma(제조쪽이지만..) 를 한번 읽어보시면 이해가 빠르실 것 같습니다..~
-------------------------------------------------------------------------------------------------------------------
글쓰기