애자일 프로젝트는 기존의 전통적인 방식인 예측형 접근 방식의 워터폴 개발 방법론의 단점을 극복하기 위해서 만들어진 개발 방밥론입니다. 따라서 기존의 전통적인 프로젝트 방식과는 다른 방식과 프로세스로 이루어져 있습니다.
프로젝트 매니저는 애자일 프로젝트 특징에 대해서 잘 이해하고 프로젝트가 만약 애자일 방식으로 진행되고 있다면 애자일 프로세스에 맞게 적용해야 할 것입니다. 애자일 개발 방법론과 애자일 프로세스로 프로젝트로 진행할 경우에도 다양한 상황을 맞이하게 되며 이 때 애자일 사상과 애자일 프로세스를 적용해서 해결해 나가야 할 것입니다. 그럼 애자일 프로젝트 대응 전략에 대해서 좀 더 자세히 알아보도록 하겠습니다.
애자일 프로젝트 데일리 스탠드업 미팅
애자일 프로젝트에는 매일 진행하는 반복 회의가 있으며 각 팀원들은 프로젝트 매니저인 스크럼 마스터과 프로덕트 오너와 함께 팀 구성원들 서로를 향해 서서 어제 무엇을 했고 오늘은 무엇을 할 것인지, 그리고 현재 어떤 장애물들이 있는지를 말하는 데일리 스탠드업 미팅을 진행합니다. 일일 스크럼은 팀 협업을 위한 프로세스입니다. 일일 반복 회의는 데일리 스탠드업 미팅이라고 부릅니다. 데일리 스탠드업 미팅은 서서 말하고 짧게 진행하는 회의입니다. 해당 회의에서 팀원들은 서로 정보를 교환하기 위한 목적으로 진행하며 스크럼 마스터에게 보고하는 회의가 아닙니다.
데일리 스탠드업 미팅은 스크럼 마스터를 중심으로 설 필요도 없습니다. 오히려 팀원들을 볼 수 있도록 서는 형태가 좋습니다. 데일리 스탠드업 미팅은 15분 정도의 시간을 정해 놓고 하는 회의입니다. 데일리 스탠드업 미팅에서 만약 프로덕트 오너가 팀 구성원들에게 작업을 지정하는 일로 시간을 15분 이상 소비하고 있으면 안됩니다. 데일리스탠드업 미팅은 팀원들이 서로의 진행 상황을 공유하는 회의이기 때문에 프로덕트 오너가 참석할 수 있지만 발언권은 없어야 합니다.
애자일의 원칙 상 그 누구도 팀원들에게 작업을 할당하면 안됩니다. 작업 할당은 팀원들의 협의로 결정되는 것입니다. 데일리스탠드업 미팅은 타임 박스 회의이기 때문에 가능하면 15분을 꼭 지켜야 합니다. 스크럼의 스크럼 회의는 단일 스크럼 프로젝트에서 작업하는 여러 팀을 조정하는 회의입니다. 스크럼 프로젝트가 커짐에 따라 여러 스크럼 팀이 업무를 협력해서 진행할 수 있습니다. 이를 위해서 일반적으로 스크럼의 스크럼이라는 접근 방식을 사용할 수 있습니다.
각 팀의 담당자들이 모여서 진행 상황을 다른 팀의 담당자와 협의하는 회의입니다. 데일리 스크럼 미팅과 마찬가지로 스크럼의 스크럼 회의는 정기적인 일정으로 진행되지만 반드시 매일 해야 하는 것은 아닙니다. 개발 팀이 매일 스크럼 회의를 한다고 하면 회의가 끝난 다음 필요에 따라 각 팀의 담당자들이 스크럼의 스크럼 회의에 참여할 수 있습니다. 참가자 팀에 영향을 주는 문제에 대해서 알게 되면 회의 후 팀의 나머지 사람들에게 이야기해야 합니다.
애자일 프로젝트 케이별 대응 전략
애자일 프로젝트에서는 애자일 선언문의 원칙이 있습니다. 그리고 린 방법론에는 단순성이 있습니다. 이는 수행하지 않는 작업량 최대화와 관련되어 있습니다. 린과 칸반은 애자일 방법론이라고 하기에는 부족한 부분이 있지만 애자일 방법론의 핵심 토대를 이루고 있습니다. 린은 군살이 없는 것처럼 단순성을 아주 중요하게 다룹니다. 단순성은 꼭 필요한 작업 만을 진행한다는 것을 의미합니다. 필요하지 않은 작업은 하지 않겠다는 의미이기도 합니다. 단순성은 진행하지 않는 작업량을 최대화하는 것입니다.
애자일 프로젝트에서 제품 백로그는 프로덕트 오너가 식별한 기능, 특징, 스토리의 목록입니다. 제품 백로그는 개발 팀과의 의사소통을 위한 중간 매개체 역할을 하기도 합니다. 제품 백로그는 제품을 구축하기 위해서 진행해야 하는 모든 기능들의 우선순위 목록이며 모든 제품 요구 사항에 대한 단일 소스 역할을 합니다. 백로그의 아이템들은 구축될 특징들과 기능들, 요구 사항들, 품질 속성들, 비기능 요구 사항들, 개선 사항들, 수정 사항들을 포함합니다. 제품 백로그는 프로젝트에서 남아 있는 작업 목록을 알 수 있는 가장 좋은 수단입니다. 애자일 프로젝트에서 프로덕트 오너는 개발 팀 사이의 커뮤케이션에서 브릿지 역할을 하게 됩니다.
애자일 프로젝트에서 백로그 개선은 프로젝트 전반에 걸쳐서 이루어집니다. 제품 백로그는 지속적으로 정제되며 백로그 항목에 더 상세한 사항을 추가하고 추정 값을 조정하는 프로세스를 진행하게 됩니다. 이러한 개선 작업을 백로그 개선이나 백로그 정리라고 합니다. 백로그 개선 활동은 개발 팀과 프로덕트 오너가 함께 작업하고 프로젝트 진행 중에 언제든지 할 수 있습니다. 고객이 스토리 우선순위를 지정하기 어려운 경우 스토리를 더 작은 스토리로 분할하여 고객이 원하는 조각을 선택할 수 있도록 하는 방법이 있습니다.
고객이 유저 스토리의 우선순위를 정하기 어려운 이유는 스토리의 가치와 투입되는 자원의 양이 명확하지 않기 때문입니다. 이러한 경우 스토리를 더 작은 스토리로 분할하면 스토리의 가치와 투입되는 자원의 양이 명확해집니다. 이러한 방법으로 우선순위를 지정할 때 도움이 됩니다. 유저 스토리의 개발 우선순위를 결정하는데 가장 중요한 요인은 비즈니스 가치입니다.
프로덕트 오너는 리스크와 비즈니스 가치, 개발 노력, 종속성, 기능의 크기, 상대적 비용, 필요한 날짜와 같은 고려 사항들을 바탕으로 제품 백로그의 우선순위를 정합니다. 이중에서 가장 중요한 요소는 비즈니스 가치입니다.만약 진행 중 업무 제한을 사용하고 있는 칸반 시스템의 특정 구간에서 병목 현상이 발생하였다면 프로젝트 팀에서는 가장 먼저 기존 리소스를 사용하여 단계 속도를 높이는 방법을 찾아야 합니다.
칸반 시스템에서 완성되지 않은 업무가 너무 많으면 오히려 업무 진행을 방해하게 됩니다. 따라서 적당한 양의 업무 만을 받아 집중도를 높여 완료된 업무를 산출하고자 하는 것입니다. 그리고 병목 현상을 쉽게 파악하기 위한 목적이 있습니다. 병목 현상이 확인 되면 가장 먼저 해야 할 것은 업무의 흐름을 방해하는 병목 현상을 해소하기 위해 전체 프로세스가 효율적으로 운영되도록 개선하는 것입니다.
애자일 방법론 중 하나인 익스트림 프로그래밍(XP)에서는 리팩토링을 적용합니다. 리팩토링은 외부 행동을 변경하지 않고 코드를 개선할 수 있도록 코드를 재구성하는 것입니다. 코드 리팩토링은 기존의 컴퓨터 프로그래밍 코드를 재구성하는 과정으로 외부의 행동을 변경하지 않고 팩토링을 변경합니다. 리팩토링은 소프트웨어의 비기능적 특성을 개선하기 위한 것으로 코드의 가독성 향상과 복잡성 감소 등을 해소하기 위한 관행입니다. 반복이 진행될 때 마다 소프트웨어를 그 위에 계속 증분 시켜야 하기 때문에 복잡하지 않고 에러가 나지 않도록 하기 위해 작성된 소프트웨어 코드를 지속적으로 단순화하고 깨끗하게 정비하는 것입니다.
애자일 프로젝트의 대응 전략 설명
애자일 프로젝트에서 최소 상품성 제품(MVP, Mimimal Viable Product)은 중요한 애자일 사상의 개념입니다. 애자일 프로젝트에서는 여러 번에 걸쳐서 릴리즈가 진행되는데 첫 번째 릴리즈 때는 최소한의 상품성이 보장되어야 합니다. 그래야지만 제품으로서의 인정을 받을 수 있습니다. 이러한 제품을 애자일에서는 최소 상품성 제품이라고 합니다. 애자일 프로젝트에서 완료 정의은 특정 작업 항목이 완료 되었는지를 확인할 수 있는 체크 항목입니다. 프로젝트 팀에서는 작업을 추정하는 동안 처음 완료 정의를 사용합니다.
애자일 프로젝트의 프로젝트 헌장은 전통적인 프로젝트 헌장과 다릅니다. 애자일 헌장은 더 가볍고 변경의 불가피성을 인정하고 있습니다. 애자일 프로젝트의 경우 조직의 목적을 달성하기 위해서 진행하기 때문에 타당성 분석도 진행되며 비즈니스 케이스도 작성됩니다. 일반적으로 전통적인 헌장이 애자일 헌장 보다 더 상세화 되어 있습니다. 그리고 애자일 헌장은 필요할 경우 변경될 수 있습니다. 하지만 그렇다고 해서 반복 주기마다 변경되는 것은 아닙니다. 반복을 진행하는 동안 프로덕트 오너는 개발팀이 계속 더 많은 작업 항목을 포함하도록 요청하고 있다면 스크럼 마스터는 프로덕트 오너에개 애자일 프로젝트 진행 방법을 설명해야 합니다.
개발에 관한 것은 개발 팀에서 자율적으로 결정하는 것이기 때문에 이는 프로덕트 오너와 협상해야 할 대상이 아닙니다. 애자일 프로젝트에서는 팀의 속도에 맞게 제품 백로그에서 유저 스토리를 가지고 오게 됩니다. 많이 가지고 온다고 해서 모두 완료할 수 있는 것도 아니며 오히려 속도를 저하시키거나 품질을 떨어뜨릴 리스크가 있는 것입니다. 스크럼 마스터는 팀의 애자일 프로세스를 안내하는 역할을 맡게 됩니다. 애자일 프로젝트 팀은 기본적으로 자율 구성 팀이기 때문에 특정한 사람에 의해서 조직되거나 지휘되지 않습니다.
유저 스토리의 우선순위를 지정하는 것은 프로덕트 오너입니다. 스크럼 마스터는 전통적인 프로젝트 매니저와 다르게 프로젝트에 대한 관리 역할은 거의 없습니다. 스크럼 마스터의 역할은 스크럼 방법론을 효과적으로 이해하고 사용하도록 보장하는 역할을 하게 됩니다. 스크럼 마스터는 개발팀의 리더로서 진행 상황에 대한 방해 요소를 없애고 이벤트와 회의 등을 촉진하여 팀 구성원을 가이드 해야 합니다. 스크럼 프로세스를 유지하고 팀의 관행을 촉진하며 팀이 원칙에 집중하도록 보장해야 합니다. 프로젝트 팀이 생산적이고 기능적이 되도록 보장하지만 프로젝트 팀원들에게 업무를 할당하지 않습니다. 모든 역할과 기능이 협력하도록 조정하고 장애를 제거해줍니다. 스크럼 마스터는 외부의 간섭과 방해로부터 팀을 보호하는 역할을 맡게 됩니다. 그리고 데일리 스크럼 미팅, 스크럼 계획 수립, 검토 회의에 참석하게 됩니다.