39. 애자일 방법론 적용 시 유의사항
성공적인 소프트웨어 신상품 개발가이드
마키아벨리의 어록 중 ‘조직에 새로운 제도를 도입하는 것은 어렵고 그것을 성공시키기는 더욱 어렵다’는 내용이 있다. 소프트웨어 개발 프로세스를 새로 도입 하는 것이 그렇다. 애자일을 적용해서 성공하기 쉽지 않다. 애자일 뿐만 아니라 모든 방법론이나 프로세스가 성공하려면 전제 조건들이 많은데 그 조건들을 갖추지 않은 상태에서 무리하게 추진하면 안 한 것보다 못한 결과를 초래한다.
애자일의 경우 팀원의 자질, 애자일에 대한 팀원과 관리자의 올바른 이해가 필수적인데 이 조건을 갖추지 못하면 애자일 적용 이전보다 성과가 나쁠 수 있다. 낭비를 제거하기 위해 적용한 프로세스가 또 다른 낭비를 만드는 형국이다. < 린과 애자일 개발, 2012>에서는 이런 상황을 다음과 같이 설명한다.
대규모 개발에서 피상적인 애자일 프로세스를 적용하는 상품그룹을 흔히 볼 수 있다. 이 그룹은 일일 스크럼을 하고, 팀 공간에서 일하고, 타임박스된 반복적인 개발을 하고, 속임수로 프로젝트 관리자를 스크럼 마스터로 이름을 바꾸는 등의 애자일 실천방법을 수행한다. 가짜 스크럼 마스터들은 눈에 띄게 커다란 소멸차트를 벽에 붙이고 팀에게 권한을 위임하는 새로운 시대를 선언하면서, 동시에 매주 팀의 “생산성 데이터”를 수집한다. 이것은 진정으로 기민성이 함축하고 있는 의미를 기만하는 망상이다. 가짜 스크럼 마스터들은 진심으로 조직적인 변화를 주도하기보다는 변화에 저항함으로써 점차 “애자일의 죽음”을 만들어낸다.
부작용을 최소화하고 애자일 적용목표를 달성하기 위한 유의사항을 아래에 정리하였다. 이 책을 읽는 상품관리자와 프로젝트관리자가 속한 조직에서 해당되는 부작용이 없는지 살펴보자.
이하 유의사항 중 일부는 정보통신사업진흥원(NIPA) 부설 소프트웨어 공학센터에서 출간한 <SW개발 애자일 101, 2013>의 내용을 수정 인용했다.
- 관리도구로서의 애자일(무늬만 애자일)을 적용하지 않는다.
애자일이 협업을 강화하는 것이 아니라 가시적인 진척도를 정기적으로 확인하기 위한 관리도구로 변질되면 안 된다. 목적은 잊고 수단만 남는다면 팀원들은 애자일을 관리자가 본인들을 관리하는 도구로 인식하게 된다.
- 애자일을 책임회피 수단으로 사용하지 않도록 한다.
애자일한 마음을 각자 편한 대로 해석하는 오류가 있을 수 있다. 이를테면 미리 계획을 세우지 않고 임기응변 식으로 대응하는 것을 애자일하다고 이야기하거나, 형식이나 절차를 버리고 일하는 것을 애자일 하다고 하는 것이다.
- NAH(Not Applicable Here) 신드롬에 조심한다.
NAH 는 ‘그 기법은 우리 환경에 맞지 않아요’ 라고 생각하는 자세이다. 애자일 기법 가운데 편하거나 받아들이기 좋은 것만 도입하려고 하는 현상이 있다. 하지만 적용하기 어려운 것을 도입해야 의미 있는 개선을 이룰 수 있는 상황도 많다. 대표적인 예가 ‘테스트주도 개발’이다. 쉬운 것부터 하는 것은 좋은 전략일 수 있지만, 쉬운 것만 하는 것은 좋지 못한 전략이다.
- 일일 스크럼 미팅이 실적을 챙기는 회의체로 변질되지 않도록 한다. .
스크럼 미팅이 애자일 실천법 가운데 가장 쉽게 적용할 수 있기에 잘못 적용되는 경우도 많다. 가장 흔한 오류는 일일 스크럼 미팅이 관리자가 진척을 챙기고 잔소리하는 시간으로 변질되는 것이다.
- 다른 조직과 생산성을 비교하지 않는다.
두 개 이상의 애자일 팀이 있을 때 관리자들은 소멸 차트를 가지고 생산성을 평가하고 싶어 한다. 애자일의 지표는 같은 팀을 대상으로 생산성 향상을 측정하는 용도에 적합하지만 팀 간 비교에는 적합하지 않다. 왜냐 하면 개발업무(사용자 스토리)의 규모를 측정하는 '스토리 포인트'가 기능점수(Function Point)와 같이 절대적인 기준이 있는 것이 아니라 팀 내부에서 정하는 기준이기 때문이다. 개인의 성과 평가, 승진, 인센티브와 관련된 평가지표는 왜곡 가능성을 최대한 배제해야 한다. 이런 관점에서 개발조직의 평가도 사업성과를 활용하는 것이 바람직하다. 개발에 국한된 지표로 평가하는 순간 많이 개발하고, 빨리 개발하는데 집중하여 본질과 멀어질 가능성이 높아진다.
- 단기간 이라면 필요한 야근을 피하지 않는다.
“지속 가능한 속도로 일하기(Sustainable Face)”를 잘못 오해하여 야근은 안 된다는 생각을 할 수 있다. 지속 가능한 속도로 일하기 위해서는 지속 가능한 품질과 생산성을 유지해야 한다. 예를 들어 빌드가 깨진 것을 방치하고 퇴근해서는 안 된다.
- 팀 자율을 빙자하여 나태해지면 안 된다.
팀 전체가 책임을 공유하고 팀 스스로가 해야 할 일을 결정하는 것이 애자일 팀의 특징이다. 자율적으로 목표를 정한다고 해서 최선을 다하지 않는 업무목표를 설정해서는 안 된다. 애자일은 팀원들이 최선을 다한다는 전제하에 적용하는 프로세스이다.
- 운영조직에 스크럼 적용은 유의한다.
운영만 하는 조직의 경우 백로그 관리를 위한 계획 자체가 불가능한 경우가 발생하기도 한다. 이러한 경우 백로그 기반의 스프린트 계획이 아니라 칸반과 같이 운영조직에 맞는 기법을 적용하는 것이 바람직하다.
- 은총알(silver bullet)은 없다.
'은총알'은 프레더릭 브룩스가 맨 먼스미신(Mythical Man Month)에서 소프트웨어 생산성을 극단적으로 향상해주는 도구는 없다는 의미로 사용하였다. 애자일 프로세스가 훌륭한 개념을 많이 가지고 있지만 준비된 상황에서 신중하게 적용할 때 효과를 볼 수 있다. 도깨비 방망이와 같은 효과를 기대해서는 안 된다. 그런데 애자일 흉내만 내고 적용효과가 없다고 포기하는 조직도 많다. 세상에 공짜점심은 없다.
- 어려운 도입기를 지나야 한다.
빅뱅방식으로 모든 조직을 대상으로 동시에 애자일을 적용하거나, 작게 시작해서 애자일 적용을 확대하는 두 가지 방식 모두 도입 초기에 많은 고생과 시행착오를 겪어야 한다. 정도의 차이가 있지만 한 번에 쉽게 효과를 보기는 매우 힘들다. 어려운 시기를 견뎌야 열매를 맛볼 수 있다.
- 상위 수준의 아키텍처나 디자인은 먼저 선행하는 것이 좋다.
각 스프린트에서 의미 있는 결과물을 만들려면 프로젝트 공통의 아키텍처나 디자인은 미리 준비하여 개발자들이 기다리지 않도록 하는 것이 좋다. 특히 디자인은 그 속성상 개발과 병행하기보다 약간이라도 앞서가는 것이 바람직하다.
- 과거 부정, 편 가르기, 계몽식의 캠페인을 하지 않는다.
변화관리를 한답시고 As is To Be의 비교를 통해 과거 프랙티스를 부정하고, 과거에 집착하는 사람을 변화를 거부하는 사람으로 폄하하는 캠페인은 도움이 되지 않는다. 공식적인 행사에서는 별 말을 하지 않지만, 그 동안의 새로운 툴 이나 프로세스를 적용한 경험을 통해 이 또한 잠깐 조직원들을 괴롭히다 지나갈 것이라 생각한다. 강당에 사람들을 모아서 ‘애자일 발대식’ 같은 행사를 하지 않아도 좋은 것은 확산될 것이라 믿어야 한다. 조직 내 실패의 경험이 확산되면 후배들은 애자일을 애자일이라 부르지 못하고 그냥 ‘XX 프랙티스 적용’으로 일을 추진한다.
- 상품오너(Product Owner) 역할에 유의한다.
상품오너(Product Owner)는 고객을 대변하여 백로그(개발 요구사항)의 우선순위를 정의하고 개발팀이 질문하는 백로그 내용에 답변해야 한다. 풀타임으로 그 일만 하기에도 벅차다. 그러나 상품관리자가 상대할 이해관계자가 개발팀만 있는 것이 아니다. 조직에 따라 가격, 수익성 분석, 채널, 특허, 영업, 판촉 등에 대해 상품관리자가 개입해야 하고 이런 현실은 풀타임 상품오너 역할을 하기 힘들게 한다. 이런 경우 주니어 상품관리자에게 상품오너 역할을 하게 하는 것도 방법이다. 아니면 상품관리자가 풀타임으로 개발에 참여하는 것이 아니라 파트타임으로 참여하는 방안도 생각할 수 있다.
- 상품 유지보수 시 스프린트 적용과 프로젝트 수행시 스프린트 적용은 다르다.
유지보수 업무에 스크럼을 적용하면 동일한 주기(예: 2주)에 상품을 릴리즈(업데이트)한다. 스프린트 주기와 릴리즈 주기가 동일하기에 스프린트 단위로 기획, 개발, 테스트가 이루어진다. 상품관리자는 스프린트 착수 전에 개발요건을 확정하고, 스프린트 종료 시점에 개발된 요건을 검수한다.
반면 프로젝트는 1개의 릴리즈에 N개의 스프린트가 있을 수 있다. 이 경우 최초 스프린트는 릴리즈에 포함될 전체 요구사항 협의, 개발계획 수립, 개발 표준을 공유하고 , 최종 스프린트는 릴리즈 前 통합 테스트로 적용할 수 있다. 상품관리자는 최초 스프린트와 최종 스프린트는 긴밀하게 참여하고 중간의 스프린트는 풀 타임 참여를 하지 않을 수도 있다.
- 백로그 관리는 상품관리자의 역할이며 누구에게도 위임해서는 안 된다.
상품백로그, 스프린트 백로그의 우선순위는 상품관리자가 결정하고 이해관계자와 공유해야 한다. 백로그는 수시로 변경이 발생하기에 상품관리자는 적절한 변경통제 프로세스를 적용해야 하며 툴을 활용하여 백로그를 관리하는 것도 효율적이다.
- 스프린트 결과물은 고객관점에서 의미 있어야 한다.
스프린트 결과물을 기술이나 아키텍처 관점으로 정리해서는 안 된다. 스프린트는
기술이 아닌 기능관점에서 구분해야 한다. 스프린트의 결과물은 고객가치 관점에
서 상품관리자가 확인할 수 있어야 한다.
- 신규 프로젝트 팀에 스크럼을 적용하는 경우 첫 번째 스프린트의 품질과 생산성에 유의한다.
신규 프로젝트 팀에 애자일을 적용하면 프로젝트 팀의 생산성, 품질에 대한 가정이 올바른지 첫 번째 스프린트의 결과물을 통해 확인해야 한다. 필요 시 남은 스프린트의 계획을 조정해야 한다. 스프린트마다 팀의 생산성과 품질은 확인하여 문제점을 지속적으로 개선해야 하지만, 신규로 팀을 구성하는 경우 첫 번째 스프린트는 처음 가정과 다를 가능성이 높기 때문에 특별히 유의해야 한다.
https://brunch.co.kr/@kbhpmp/160
