그 와중에 agile coach squared라는 프로그램을 발견하게 됐는데, 해당 프로그램 관련하여 웹에서 검색 중 간단하게 적용해 볼만한 risk managment 기법이 있어 한번 적용해 보려 한다.
Premortem (사전 부검)이라는 기법으로, 프로젝트의 위험 요소를 미리 예측하여 관리하는데 효과적이라고 한다. Premortem의 내용은 하기 Harvard business review 링크 참조.
Premortem의 방법은 하기와 같다.
1) 프로젝트가 이미 정말 엄청나게 완전히 망했다고 가정한다. 되도록 상세하게 가정하는게 좋다.
- 예) 어제까지 프로젝트의 최종 결과물 납기일이었는데, 납품하지 못했다. 게다가 한달의 시간이 더 걸릴 것 같아 그에 따른 엄청난 배상금을 물게 되었다.
 |
<프로젝트가 이미 실패한 미래의 그날로 시간여행을 했다고 가정해본다. 빽투더퓨처!>
|
2) 각자 5분 정도 실패의 원인을 적는다.
- 특히 평소에 말하지 못했던 잠재적인 문제들에 대해서 자세하게 실패의 원인을 적는다.
3) 적은 내용을 공유하고, 해당 내용에 대해서 계획을 세워본다.
그래서 이 방법을 지금 현재 나의 상황에 맞춰 적용해 봤다.
나의 실제 상황: 이제 곧 다가올 프로젝트의 SW freeze 날짜까지 우리 기능팀의 기능 구현/테스트를 완료해야 한다.
1) 실패 상황 가정
어제가 프로젝트의 SW freeze 날이었는데, 우리 기능팀의 문제점이 너무 많이 나와서 SW freeze를 하지 못했다. 고객사에게 SW freeze를 하지 못한 이유를 해명하기 위해 며칠간 출장을 다녀왔으며, 팀장과 SW PM에게 해당 문제들의 해결 상황에 대해서 일일보고 하라는 명령을 받았다.
2) 원인
- 인도 개발자들에게 맡긴 기능이 개발 중간에 인도 연휴로 인해 테스트 시간이 부족하여, 막판에 많은 문제점이 나왔다.
- 인도에 테스트 장비가 부족하여, 인도 개발자에게 맡긴 기능이 제대로 테스트되지 못했다.
- SW freeze 즈음하여 다른 개발자들도 테스트를 하느라 한꺼번에 몰려 lab에서 우리 기능을 테스트를 할 수 있는 자리가 없었다.
- 우리 기능 관련된 platform 문제가 발견되었는데 문제를 너무 늦게 발견하였다.
- 이번 프로젝트에 새롭게 추가된 기능이 있는데 새로운 기능에 대한 테스트 케이스를 충분히 세우지 못해 문제점을 미리 발견하지 못했다.
- 이번 프로젝트에 새롭게 추가된 기능이 있는데, 해당 기능이 추가된 줄 모르고 있다가 막판에 알게 되어 급하게 구현하느라 테스트를 충분히 하지 못했다.
- 베이스 프로젝트 대비, 변경점을 확인해 보지 않아 코드 수정을 하지 못했다.
- 기존 프로젝트에서 발생한 문제점을 해결한 코드를 적용하지 않아, 기존 문제점이 그대로 발견되었다.
- 기능 스펙에 다소 부정확한 부분이 있었는데, system engineer에게 다시 문의하지 않고 임의로 개발하여 기능에 문제가 발생했다.
- SW freeze 날짜 전에 이미 검증을 끝낸 기능이, 검증 이후에 다른 기능 코드의 수정으로 인하여 오동작하고 있었다.
정말 실패 상황을 가정하여 원인을 쓰다보니 실패 요인이 생각보다 많이 써져서 놀랐다.
원인에 대한 해결 방안을 생각해 보았다.
- 인도 개발자들에게 맡긴 기능이 개발 중간에 인도 연휴로 인해 테스트 시간이 부족하여, 막판에 많은 문제점이 나왔다.
=> 인도의 휴일을 파악하여, 인도 개발자에게 해당 휴일을 고려하여 테스트 계획을 세워 보내달라고 한다.
- 인도에 테스트 장비가 부족하여, 인도 개발자에게 맡긴 기능이 제대로 테스트되지 못했다.
=> 한국이 인도에 비해 테스트 장비가 여유가 있으니, 인도 개발자들의 테스트 중 일부를 한국에서 수행한다.
- SW freeze 즈음하여 다른 개발자들도 테스트를 하느라 막판에 우리 기능을 테스트 할 수 있는 자리가 없었다.
=> 사람들이 많이 테스트 하지 않는 날 (주말과 저녁?)에 테스트를 하여 미리 끝낸다.
- 우리 기능 관련된 platform 문제가 발견되었는데 문제를 너무 늦게 발견하였다.
=> platform에 연관된 기능 리스트를 뽑아 우선 테스트해 본다. 과거에 있었던 platform 연관된 문제점들을 테스트해 본다.
- 이번 프로젝트에 새롭게 추가된 기능이 있는데 새로운 기능에 대한 테스트 케이스를 충분히 세우지 못해 문제점을 미리 발견하지 못했다.
=> 값이 바뀌는 경계점이나 예외 케이스, negative 테스트를 중심으로 테스트 케이스를 우선 작성한다.
- 이번 프로젝트에 새롭게 추가된 기능이 있는데, 해당 기능이 추가된 줄 모르고 있다가 막판에 알게 되어 급하게 구현하느라 테스트를 충분히 하지 못했다.
=> 프로젝트의 기능 사양 중 새롭게 추가된 기능이 있는지 확인한다.
- 베이스 프로젝트 대비, 변경점을 확인해 보지 않아 코드 수정을 하지 못했다.
=> 베이스 프로젝트에서의 변경점을 중심으로 코드를 확인하고, 테스트 한다.
- 기존 프로젝트에서 발생한 문제점을 해결한 코드를 적용하지 않아, 기존 문제점이 그대로 발견되었다.
=> 기존 프로젝트의 문제점을 해결한 코드가 무엇이 있는지 목록을 만든 후, 해당 코드가 적용되었는지 확인한다.
- 기능 스펙에 다소 부정확한 부분이 있었는데, system engineer에게 다시 문의하지 않고 임의로 개발하여 기능에 문제가 발생했다.
=> 스펙에 부정확한 부분이 있을 경우, system engineer에게 반드시 물어보고 명확히 한 후에 기능을 개발한다.
- SW freeze 날짜 전에 이미 검증을 끝낸 기능이, 검증 이후에 다른 기능 코드의 수정으로 인하여 오동작하고 있었다.
=> 테스트를 미리 끝낸 후, SW freeze 2일전 integration test를 간단히 수행한다.
0 개의 댓글:
댓글 쓰기