현재 고객의 입장으로 진행하고 있는 프로젝트에서 '스크럼' 방법론을 도입하고 있습니다.
역시나 프로젝트 실 수행자(개발팀)의 입자에서 준비하고, 실행되고 있기 때문에 고객의 입장(수행팀)에서는 상대적으로 커뮤니케이션의 사각 지대에 있거나 (솔직히) 스크럼의 효과에 대해 다시 한 번 생각해보는 계기가 됐습니다.
물론 제가 스크럼 전문가도 아니며, 일부 프로젝트의 경험을 바탕으로 적은 것이므로 일반화하기는 어렵습니다.
다만 저도 다음 번에는 (당연히..) 프로젝트 실 수행자의 입장에 설 것이므로 이번 경험을 타산지석의 기회로 삼으려는 것일 뿐입니다. (오해 방지를 위해서...)
먼저 결론을 내려보자면,
"모든 활동은 고객과의 긴밀한 커뮤니케이션을 통해서 이루어지는 것이 좋다"
입니다.
- 현재 컨텍스트를 인지하기 어려움
현재 개발 상태를 인지하기 어려움
고객과 밀접하게 스프린트 상황을 공유하면 안 되는 것인가? 프로젝트 후반으로 갈 수록 이런 경향은 심해짐.
검토 프로세스를 정립해서 발행된 이슈(일감)에 대해 즉각적으로 피드백을 줄 수 있다는 점은 좋지만,
반대로 이슈가 올라오기 전에는 해당 작업의 현황을 알기 어렵다는 점
이슈가 정리가 되야 올라오므로 해당 이슈에 대해 검토할 시간이 상대적으로 적다.
이건 이슈를 얼마나 적당히 잘라서 관리하느냐가 중요.
- 스프린트 별 요구사항 분류의 어려움
좀더 정확히 하자면 의미 있는 스프린트 구분의 어려움.
스트린트를 나누기는 했지만 실제로는 워터풀 방식의 일정(설계-개발-테스트)을 단순히 스프린트로 쪼개 놓았을 뿐. 진정한 반복이 되려면 각 스프린트의 결과가 해당 스프린트 종료 시점에서 온전히 검증되어야 함. 그렇지 않고 테스트와 검증을 뒤로 미루면 별다른 게 없다.
- 스프린트 종료 시 해당 작업의 일감을 모두 마쳐야 하는 데 그렇지 못하는 경우
사람이다 보니 스프린트가 끝나고 프로젝트 일정이 남아 있게 되면 뒤로 미루게 되는 경향이 있음.
스프린트는 종료 되었어도 프로젝트 기간은 남아있기 때문에.. 스프린트 종료에 대한 명확한 인식이 필요함.
- 대시 보드의 부제
고객과 개발팀 간, 개발팀 내에서도 정보 공유가 제한적. 프로젝트 현황에 대한 공통된 인식을 공유할 수 있는 좋은 방법을 활용하지 않음.
단순히 개인이나 회의실 일정을 공지하는 수준으로만 사용...
이로 인해서 현재 프로젝트 상황에 대한 인식을 공유할 수 있는 좋은 수단을 놓침.
- 주간 보고 때 실제로 얻고자 하는 정보는?
상세 작업은 이미 개별 파트별로 공유하고 있기 때문에 전체적인 요약 정보와 스프린트 상태가 궁금.
현재 상황에 대한 신뢰 가능한 요약 정보를 제시하지 못하는 경우 현황 파악이 어려움.
전체 통계치를 제시하기는 하지만, 작업 지연에 따라 이 수치에 의문을 품게되다보니 시간이 지날수록 관심을 갖지 않게 됨
개발팀 내에서는 다양한 회의를 통해 커뮤니케이션 향상을 불러올 수는 있을지 몰라도 고객과는 기민한 회의가 없다.
아침 회의에 고객이 참여하는 건 어떨까?
- 스크럼을 적용했다고, 애자일스럽게 프로젝트를 진행했다고 해서 결과물의 품질이 우수해 지지는 않는다.
일 하는 방식을 변경했다고 해서 그 결과를 보장하는 건 아니다.
- CI를 돌린다고 통합적인 사고를 하는 건 아니다.
내 일은 일 대로 CI는 무엇이냐하는 분위기. 초반 세팅 시에만 신경쓰며 시간이 지날수록 무시. 이를 확인하고 적극적인 운영 계획이 필요.
- 테스트 케이스는 로컬 환경에서 작성하지만, 실행은 꼭 로컬에서만 하는 건 아니다.
CI와 같은 통합 환경에서 회귀 테스트가 가능한 형태로 작성해야 한다. 또한 이를 고려해서 테스트 케이스의 성공/실패에 대한 가시정을 확보해야 함. 예를 들어, 하나의 테스트 케이스 메서드에 다양한 검증 로직을 포함하는 것보다는 각각을 별도의 테스트 케이스로 뽑아 내여 구성함
- 스프린트 계획 회의의 참석 대상과 진행 방식에 대한 의문
스프린트 계획 회의에서 고객 참여를 배제해야 하는 건가? 일의 우선 순위 결정 시 아무리 백로그를 기준으로 한다고 해도 고객의 의견을 반영하는 것이 종단에는 불필요한 작업을 없앨 수 있는 하나의 방법으로 생각 됨.
- 명확하지 않은 스프린트 산출물 정의
스프린트의 산출물이 명확하지 않을 때는 일정이나 그 작업 결과물 자체가 모호할 경우가 있음. 이럴수록 명확히 정의하고 넘어가야 함.
Prev
Rss Feed