애자일 프로세스 케이스 별 대응 전략에 대해서 알아보는 것은 매우 의미 있는 일입니다. 애자일 프로젝트는 적응형 접근 방식의 대표적인 방법론입니다. 애자일 프로젝트는 워터폴 방식의 프로젝트와는 다릅니다. 애자일 프로세스는 특수성이 있기 때문에 그 특징을 잘 이해하고 케이스 별로 대응할 필요가 있습니다. 애자일 프로젝트의 프로젝트 매니저는 스크럼 마스터이며 서비스 기획자는 프로덕트 오너(PO)입니다. 애자일 프로세스의 케이스 별 대응 전략에 대해서 좀 더 자세히 알아보겠습니다.
애자일 프로세스와 프로덕트 오너의 역할
애자일 프로젝트를 진행 중인데 프로젝트의 진행이 절반 이상을 넘어선 상황에서 프로젝트를 통해서 구현하고자 하는 시스템과 서비스가 수익성을 조사해보았더니 초반에 조사했던 것 보다 더 낮게 측정 되었다고 할 때 이 부분에 대해서 책임지는 사람은 프로덕트 오너(PO)입니다. 애자일 접근 방식에 대해서 이해하기 위해서는 가장 중요한 것 중 하나가 바로 애자일 프로젝트에서의 역할자와 역할자들의 책임과 역할에 대해서 알고 이해하는 것입니다.
애자일 프로젝트에서 가장 중요한 역할자는 프로덕트 오너입니다. 프로덕트 오너는 기본적으로 비즈니스 쪽 인력입니다. 프로덕트 오너는 제품 백로그의 우선순위를 정하고 제품에 대한 수익성에 대해서 책임을 지는 사람입니다. 애자일 프로젝트에서 프로덕트 오너는 비즈니스를 대표하며 다른 영역에 초점을 둔 프로젝트 팀의 다른 구성원들 보다 프로덕트에 대한 가치를 더 잘 이해하고 있어야 합니다. 프로덕트 오너는 비즈니스와 대화를 하고 제품 백로그를 관리하는 주체입니다. 프로덕트 오너는 제품에 대한 로드맵에 대해 외부 이해 관계자들과 의사소통을 하는 주체입니다. 프로덕트 오너의 역할은 매우 중요하며 다양한 역할을 하게 됩니다. 수행할 작업 목록을 관리하며 제품의 가치를 극대화할 책임이 있습니다. 제품의 특성과 기능을 정의하고 릴리즈 일자와 내용을 결정해야 합니다. 프로덕트 오너는 제품의 수익성에 대해서도 책임을 집니다.
백로그의 작업 항목을 가장 최신 상태로 유지하고 있는 사람이며 비즈니스 가치에 따라 정확하게 우선순위를 부여하거나 변경하는 역할을 담당합니다. 작업 결과에 대한 승인과 거부 결정을 합니다. 또한 외부 이해 관계자들과 의사소통을 통해서 프로젝트를 진행합니다. 프로덕트 오너는 개발팀의 제품에 대한 질문에 대해 답변을 하는 역할을 맡게 됩니다. 스프린트 보류나 취소에 대한 결정을 하기도 합니다. 프로덕트 오너는 비즈니스와 팀이 프로젝트 비전, 프로젝트 목표에 대해서 공통된 비전을 가지도록 하는 역할을 합니다.
애자일 프로세스의 케이스별 이해
스크럼 마스터는 애자일 프로젝트에서 프로젝트 매니저(PM)로써의 역할을 하게 됩니다. 다만 전통적인 프로젝트 매니저(PM)와는 다른 성격과 특징을 가지고 있습니다. 만약 반복 계획 중에서 프로젝트 팀원들이 유저 스토리의 설계에 대해서 논의하고 있을 때 어떤 팀원은 본질적으로 시스템이 복잡하기 때문에 설계 문서를 작성해야 한다고 하고 어떤 팀원은 애자일 프로젝트에서는 문서 작성이 필요 없다고 이야기한다고 하였을 때 상호 작용은 문서보다 가치가 있지만 문서는 금지되지 않는다고 설명해야 합니다.
애자일 선언문에서는 포괄적인 문서보다 작동하는 소프트웨어를 더 중요하게 보고 있습니다. 해당 의미는 문서 보다 작동하는 소프트웨어가 더 중요하다는 의미이며 문서를 만들지 않겠다고 하는 것은 아닙니다. 만약 프로젝트 개발 팀에서 문서가 필요하다고 하였을 때 당연히 문서를 만들 수 있습니다. 애자일 선언문에서는 프로세스와 도구 보다 개인과의 상호 작용을 더 중요하게 보며 포괄적인 문서 보다 실질적으로 작동하는 소프트웨어를 더 중요하게 봅니다. 프로젝트 스폰서가 개발하고 있는 제품 중 일부라도 전시회에서 시연할 준비가 되었는지 알고 싶어할 때 스크럼 마스터는 스폰서에게 최우선 순위 기능을 시연하는 것이 가능하다고 대답해야 합니다.
애자일 팀은 반복을 통해서 우선순위가 높은 기능에 대해서 작동하는 제품을 만드는 것을 목표로 합니다. 반복 후에는 반복 검토를 통해서 시연까지 하게 됩니다. 이렇게 개발이 완료된 제품은 증분 하게 되어 필요하다면 릴리즈도 가능한 것입니다. 따라서 애자일 프로젝트에서는 제품에 대한 시연이 언제든지 가능해야 합니다. 다만, 제품에 대한 전체 기능이 아닌 우선순위가 높은 요구 사항을 먼저 진행하는 사상이 깔려 있습니다. 애자일 프로젝트에서 완료의 정에 대해서 알아보면 모든 이해 관계자들이 완료의 의미에 대해서 공통된 이해를 갖게 하는 것입니다.
완료 정의가 중요한 이유는 이해 관계자들이 새로운 기능에 대한 설명을 다른 방식으로 해석하여 발생할 수 있는 불일치를 방지하기 위해서 입니다. 완료의 정의가 기능을 협상하거나 협상 기술을 향상 시키거나 새로운 요구 사항을 제시하는데 사용되도록 의도한 것은 아닙니다. 토론을 통해서 모든 사람이 완료나 성공에 대한 공통된 이해를 갖게 하는 것이 무엇보다 중요합니다.
완료의 정의(DoD, Definition of Done)은 유저 스토리가 완료로 간주되기 위해서 충족되어야 하는 기준 목록을 의미합니다. 완료의 정의는 개발 팀이 동의를 한 내용이어야 합니다. 이 부분에 대해서는 프로젝트 룸에서 눈에 잘 띄도록 하는 것이 좋습니다. 완료의 정의가 중요한 이유는 개발자가 생각하는 완료와 고객이 생각하는 완료의 기준이 다를 수 있기 때문입니다. 일반적으로 개발자에게 해당 기능이 완료 되었는지를 확인하면 개발자는 프로그래밍이 끝났다는 것을 기준으로 완료되었다고 이야기할 것입니다. 하지만 테스트가 끝났고 문서화도 끝나서 당장 인도가 가능한지 여부로 완료의 기준을 판단한다면 해당 케이스는 완료되지 않은 사항입니다.
완료의 정에 대해서 명확히 하기 위해서는 완료 체크 리스트를 사용하여 완료 여부를 판단하는 것이 좋습니다. 완료의 정에 대해서 합의를 하면 개발 팀과 고객, 그리고 프로덕트 오너(PO) 사이의 오해와 갈등의 리스크를 없앨 수 있는 장점이 있습니다. 완료의 정의가 정의되지 않았다면 프로젝트의 각종 추정치가 정확하지 않고 반복 작업에 대한 부정확한 예측이 이루어지며 프로덕트 오너(PO)가 제품의 진행 상황을 이해하기 어렵고 반복 리뷰에서 투명성이 없어지는 것입니다.
애자일 프로세스의 상황 별 대응 방법
애자일 프로젝트에서는 각 반복 후 검사를 통해서 제품의 품질을 보장합니다. 전통적인 프로젝트 관리에서는 별도의 품질 관리 계획을 수립하고 품질 활동을 하여 품질을 보증하게 됩니다. 하지만 애자일에서는 별도의 품질 활동은 없습니다. 품질은 결국 고객의 요구 사항에 맞추는 것이기 때문입니다. 애자일 접근 방식에서는 고객에게 증분을 자주 인도하고 시연하고 검토를 받음으로써 품질을 달성하는 것입니다. 애자일 접근 방식에서 제품을 개발할 때 여러 개발 팀이 동시에 작업을 한다면 제품 백로그는 한 개만 작성하면 됩니다.
한 개의 애자일 프로젝트에서는 한 개의 제품 백로그만 있습니다 .아무리 대형 프로젝트이고 여러 개의 개발 팀이 있어 반복이 동시 다발적으로 여러 번 진행된다고 하더라도 제품 백로그는 하나 만 있으면 됩니다. 애자일 프로젝트 팀이 가지고 있는 가장 강력한 기능은 스스로 조직하고 권한을 부여 받는 것이라고 할 수 있겠습니다. 사람들은 일반적으로 할당된 업무를 하는 것보다 내가 주도해서 일을 할 때 동기 부여를 더 잘 받는 것으로 알려져 있습니다. 애자일 프로젝트는 그러한 특징을 잘 활용한 방법론이라고 볼 수 있습니다.
애자일 접근 방식에서 반복 회고의 목적은 잘 작동하는 것, 잘 작동하지 않는 것, 프로세스 개선을 위해서 필요한 조치를 식별하는 것입니다. 회고는 반복 검토 후 반복 계획 회의 전에 반복에 대한 최종 검사와 적응을 위해서 진행하게 됩니다. 회고를 진행하는 가장 중요한 목적은 지속적인 프로세스 개선과 품질 개선 조치가 필요한 사항을 식별하고 합의하기 위한 것입니다. 그리고 반복하는 동안 배운 교훈을 모아서 개선의 기회를 찾는 것도 중요합니다. 반복 검토의 중요한 목적은 스프린트 동안 달성된 것을 시연하는 것입니다. 반복 검토 회의는 반복 마지막에 진행하는데 개발 팀, 프로덕트오너, 스크럼 마스터, 다른 이해관계자들이 참석할 수 있습니다. 반복 검토 회의에서는 팀이 반드시 진행해야 할 사항들이 있습니다.
첫 번째는 완료된 작업과 계획되었지만 완료되지 않은 작업을 확인하는 것입니다. 두 번째, 빌드 한 증분이나 진화하는 제품을 프로덕트오너에게 시연해야 합니다. 세 번째, 프로덕트오너는 작업이 완료되었는지 여부를 확인하거나 누락 여부를 확인하기 위해서 작업을 검사해야 합니다. 네 번째, 프로젝트 보고서를 검토합니다. 다섯 번째, 프로젝트 팀과 프로덕트오너는 제품 백로그에 대한 변경이 필요한 사항이 있는지를 확인하고 다음 반복 주기에서 진행할 작업에 대해서 협의를 합니다.