[애자일 개발 프로세스가 변화해야 한다는 5가지 신호] 많은 플랫폼 기업뿐만 아니라 대기업들도 너도나도 애자일 프로세스를 도입하여 실행하고 있다. 그러나 단순히 흉내만 낼뿐 제대로 도입되어 기업 문화화되는 곳이 얼마나 있을까? 릴리즈 일정만 빨라졌거나 무분별하게 백로그(요구사항)만 쌓고 회의만 주구장창 하고 있을 수도 있다. 이 글은 잘못된 애자일 프로세스가 어떤 것인지 잘 설명하고 있는데, 번역이 자연스럽진 않지만 맥락을 파악하시는데는 충분할 것 같네요!^^ 각각에 대해 제 의견을 드리오니 제대로된 애자일 프로세스를 도입하시려는 분들은 참고하세요. 1. 적은 백로그와 불충분한 계획 애자일 초보들이 가장 많이 저지르는 실수인데, 스프린트 시작일에 가까워서야 부랴부랴 사용자 스토리를 작성하고 이에 대해 스크럼 팀 내에 충분한 검토, 상호 이해 없이 개발을 시작하는 것이다. 이렇게 개발이 시작되면, 충분한 아키텍처 설계 및 시스템 영향도 검토 없이 스프린트 종료일에만 맞춰 프로덕트가 개발됨으로 오류가 많은 프로덕트가 나올 수 밖에 없다. 더욱 최악은 비즈니스 이해 관계자가 목표 결과물이나 중장기 로드맵에 대한 이해가 부족한 경우인데, 이는 이들과 지속적으로 커뮤니케이션하고 공감하여 이들의 이해력을 높이는 것이 리더의 중요한 역할이다. 2. 스프린트와 릴리즈가 약속을 지키지 못한다 개발팀이 사용자 스토리 구현을 스프린트 내에 지속적으로 완료를 하지 못할 경우, 이는 애자일 프로세스에 문제가 있다는 반증이다. 단순히 더 적은 수의 백로그를 개발하는 것이 해결 방법이 아니며, 근본적인 문제점을 찾아 개선해야 한다. 예를 들면, 개발하는 사용자 스토리가 스크럼 팀이 생각하는 고객 니즈를 충분히 반영하지 못했을 수도 있고 중장기 로드맵에 따른 충분한 공감을 얻지 못했을 수도 있다. 혹은 시스템 아키텍처의 기술적 문제로 인해 사용자 스토리를 현 시스템에 반영하기 어려울 수도 있다. 3. 참석률이 높은 리뷰 없이 스프린트 종료 스프린트 계획 시에는 많은 회의를 하는데, 종료 시에는 회고를 포함한 충분한 회의를 하지 않고 지나가는 경우가 많다. 스프린트 리뷰는 완성된 사용자 스토리를 프로덕트 이해 관계자에게 시연하고 피드백을 수집하는 것이 목적으로, 스프린트 리뷰는 참석자가 많을수록 좋고 보여줄 것이 많을수록 좋다. 그래야 참석자들이 충분한 의견을 낼 수 있으며, 충분한 토론이 가능해져서, 결과적으로 양질의 결과를 얻을 수 있다. 이는 스크럼 팀을 더욱 발전시킬 것이다. 4. 프로덕션(상용)에서 발생하는 결함 증가 프로덕션에서 발견하는 결함이 증가한다면, 근본 원인을 논의하고 해결책을 찾아야 한다. 대부분의 경우, 백로그를 사전에 꼼꼼히 계획하고 개선하며, 테스트 자동화에 투자하고, 다양한 테스트 데이터를 늘리거나, 지속적인 테스트를 수행하는 모든 단계는 프로덕션 결함을 줄이는데 도움이 된다. 사용자 스토리에 따라 다양한 테스트 방법을 도입하고, 이에따라 테스트를 자동화하고, CI/CD 파이프라인을 구성하며, 인프라를 코드로 배포해 릴리즈의 안정성을 개선하는 등 성숙한 DevOps 환경을 도입하는 것도 프로덕션 결함을 줄이는데 꼭 필요하다. 5. 애자일 팀이나 이해 관계자의 불만족 불만족은 지나치게 높은 기대치나 낮은 배포 품질, 애자일 팀과의 협업을 벗어난 작업 현실로 인해 발생할 수 있다. 리더는 어느 부분에 문제가 있는지 정확히 빠르게 찾아내어 이를 적극 해결해야 한다. 애자일 프로세스 전반 그리고 사업 목표, 중장기 로드맵, 고객 니즈 등이 현실과 너무 괴리되어 있는지, 애자일 팀 내 협업이나 커뮤니케이션 문제가 있는지, 혹은 구성원들의 역량 또는 리소스 문제인지 등등 불만족 원인을 파악하고 이를 함께 개선하여야 한다.