2019.08.05

“매끄럽고 섬세하게” 애자일 제품 관리 방법

Isaac Sacolick | InfoWorld
애자일 도구가 잘 작동하는지 질문하면 엇갈린 반응을 보인다. 때로는 부정적인 반응도 나온다는 이야기다. 애자일 도구는 애자일 부서를 도와주지만, 제품 소유주가 일할 때 필요한 모든 기능을 제공하는 것은 아니다.

이와 유사하게 프로그램과 포트폴리오 관리자를 도와주는 기능에도 제약이 있다. 애자일 도구는 부서와 릴리즈, 에픽에 대한 보고서를 제공하지만, 일반적으로 프로그래머가 하향식 전략 이니셔티브에 대해 보고할 때 충분히 도움을 줄 수 있는 정도는 아니다.

이런 이유로 부서의 제품 오너는 애틀라시안의 지라(Jira)를 선호하지 않는 경향이 있다. 또 프로그램 매니저는 지라나 마이크로소프트 애저 데브옵스(Azure DevOps)에서 필요한 보고서를 얻지 못한다. 이 도구들은 부서의 직능 가운데 일부에만 도움을 준다.

백로그, 스프린트 보드, 스크럼 보고서는 제품 매니저가 좋은 제품을 구상할 때 필요한 도구를 제대로 다루지 못한다. 또 프로그래머 매니저가 전략 목표를 애자일 부서가 수행하는 업무에 일치할 때도 도움을 주지 못한다. 파워포인트 프레젠테이션을 통해 비지니스 전략을 배우고, 업무 현황을 검토하는 제품·프로그램 관리자와의 회의가 많다면 애자일 제품 관리, 또는 포트폴리오 관리 플랫폼에 대한 준비가 되어 있다고 볼 수도 있다.

지라와 애저 데브옵스 같은 애자일 관리 플랫폼은 개발자와 테스터, 데브옵스 엔지니어로 구성된 애자일 딜리버리 부서가 주로 사용할 수 있는 도구이다. 활성 스프린트에 해당되는 사용자 스토리와 다른 종류의 업무 상태를 관리할 수 있는 보드가 있다. 또 미래의 스프린트를 위해 스토리를 평가, 배열, 우선순위를 부여할 때 도움을 주는 다른 백로그 관리 도구도 있다. 그리고 애자일 부서가 속도를 추적하고, 블록을 검토하고, 사이클 타임을 측정하고, WIP(진행 중인 업무)를 관리할 때 도움이 되는 번다운 보고서와 기타 보고서 기능이 내장되어 있다. 여기에 더해, 애자일 도구는 제품 오너의 스토리 작성, 승인 기준 문서화, 추정 스토리 포인트 검토에도 도움을 준다. 제품 오너는 스프린트 업무에 대한 우선 순위 부여, 진행 상황 추적에 이 도구를 사용한다.
 

“비전을 공유하고, 로드맵을 캡처하는 제품 관리 플랫폼”

제품 매니저와 오너는 고객과 유망 잠재 고객에 귀를 기울이는 것부터 시작한다. 고객의 요구를 판단하고, 비즈니스 가치를 전달하는 방법을 파악하고, 내부 이해당사자에게서 아이디어와 전략적 요구 사항을 반영하고, 우수한 고객 경험을 전달하는 제품과 서비스를 정의한다. 제품 개발 초기 단계의 업무는 시장 조사, 아이디어 테스트, 이해당사자와 전략에 대해 커뮤니케이션을 하는 과정으로 구성되어 있다.

이런 여정을 밟으면서, 리더와 애자일 부서에 목적을 커뮤니케이션하는 데 도움을 주는 산물, 비즈니스 목표, 사용자 페르소나, 경쟁 분석, 비즈니스 모델, 제품 비전이 발전하거나 개발된다.

제품 매니저는 전통적으로 파워포인트와 엑셀을 사용해 이런 산물을 캡처해 커뮤니케이션했다. 이런 도구는 제품 개발 초기에 이해당사자를 설득하고 부서를 일치시키는 데 효과가 있기는 하지만, 제품이 개발되고, 출시되고, 강화되는 동안 이해당사자의 기대 사항을 관리하는 업무에는 유용하지 못하다. 제품 매니저와 오너는 이런 책임을 이행하기 위해, 더 고수준의 피처 백로그를 관리해야 하고, 릴리스 상태에 대해 커뮤니케이션해야 하며, 장기 로드맵을 공유해야 한다.

그리고 이러한 도구를 부서가 전달할 솔루션에 몰입하고, 우선순위를 조정하고, 자체적으로 구성되도록 도움을 주는 애자일 원칙과 일치시켜야 한다.

지라 얼라인(Jira Align, 기존 AgileCraft), 아하(Aha), 버전 원 얼티메이트 에디션(Version One Ultimate Edtion)은 제품 매니저에게 이런 도구를 제공한다. 또 애자일 백로그 및 릴리스 계획에 대한 통합을 지원한다. 여기에는 제품 매니저가 제품 전략을 커뮤니케이션하는 중앙화 된 플랫폼, 이해당사자와 아이디어를 공유할 수 있는 도구들, 릴리스 상태와 로드맵에 대해 공유할 수 있는 보고 메커니즘이 포함되어 있다.

예를 들어, 아하는 지라, 애저 데브옵스, 랠리, 트렐로와 통합, 부서와 사용자 스토리, 피처, 릴리스에 대한 정보를 제공하는 기능을 제공한다. 이런 정보를 피처 백로그, 로드맵, 이니셔티브, 목표 같은 몇몇 아하 구성요소에 매핑할 수 있다. 이는 제품 매니저가 이해당사자와 현황 정보를 공유하고, 계획을 수립하는 상향식 인터페이스이다.
또 제품 매니저가 전략을 발전시키고, 비즈니스 모델을 포착하고, 사용자 페르소나를 커뮤니케이션할 수 있는 도구를 제공한다. 이런 도구를 사용하는 조직은 제품 매니저가 조직이 목표, 비전, 우선순위에 몰입할 수 있도록 도와주는 기준과 중앙화된 방식을 갖고 있다.
 

“규모가 큰 조직에서 일치와 기준에 원동력이 되어주는 포트폴리오 관리”

고객이 사용하는 제품, 워크플로우 애플리케이션, 통합, 비즈니스 인텔리전스 대시보드, 기타 기술 산물을 모두 개발하는 대기업에는 전략적 목표에 부합해 이니셔티브를 완성하도록 도와주는 추가적인 도구가 필요하다. 이런 대기업은 일반적으로 계층적인 조직 위계 구조를 갖고 있으며, 우선 순위에는 하향식 커뮤니케이션, 매트릭스에는 상향식 매트릭스가 필요하다. 이를 상태 보고서에 통합할 수 있어야 한다.

꽤 오래 전에 PPM(프로젝트 포트폴리오 관리) 도구가 등장했다. 조직의 전략 이니셔티브 관리와 추적에 도움을 줄 수 있는 도구다. 그러나 초창기 도구 중 상당수는 전통적으로 잘 구성되어 있는 폭포수 프로젝트 스케줄을 통합하도록 만들어져 있다. 시작일과 종료일이 규정된 태스크와 마일스톤 등이 여기에 포함된다. 이런 도구로는 자체 구성형 부서가 관리하며, 계속 바뀌는 스케줄과 우선순위가 특징인 스프린트와 사용자 스토리를 지향하는 애자일 프로젝트를 쉽게 통합할 수 없다. 애자일 프레임워크를 지원하지 않는 일부 PPM 도구는 릴리스와 에픽에 대한 애자일 데이터를 배포할 때 데이터 통합이 복잡해진다. 더 큰 문제는 ‘톱던(To-done)’ 방식의 스케줄링과 우선순위에 바탕을 둔 PPM 워크플로우는 포트폴리오 매니저와 애자일 부서 간 ‘문화적 충돌’을 초래한다는 것이다.

포트폴리오 매니저는 애자일 프랙티스 스케일링을 책임지고 있으며, SAFe, DAD, LeSS, Driving Digital 같은 프레임워크를 사용한다. 이들 또한 여러 애자일 부서를 관리하고, 프로세스 기준을 수립할 수 있는 포트폴리오 도구가 필요하다.

지라 얼라인과 버전 원 얼티메이트 에니션 같은 애자일 포트폴리오 도구를 이용, 애자일 부서가 수행하는 업무 위의 계층에서 이니셔티브를 관리할 수 있다. 또 부서가 속도와 역량에 대한 가시성을 제공하기 때문에, 부서에 이니셔티브를 할당하고 타임라인을 예상할 수 있다. 이니셔티브에 비즈니스 가치를 할당하고, 부서와 우선순위, 투자 수준을 적절히 조정해 일치시키는 도구도 제공한다.

지라 얼라인은 이니셔티브 포트폴리오 관리, 에픽 추적, 애자일 프로젝트 매트릭스 통합 기능 이상을 지원한다. 부서 간 종속성을 가시화해 관리하고, 위험을 추적하고, 애자일 부서와 전략 정보를 공유할 수 있는 도구도 갖고 있다.
 

애자일 부서에 도움을 주는 도구

애자일 도구는 전통적으로 부서의 백로그 관리, 요구사항에 대한 일치, 스프린트에 몰입, 신뢰할 수 있는 릴리스 구현에 도움을 주는 도구이다.

규모가 큰 조직에서, 애자일 도구가 제공하는 데이터는 관리진이 상태를 파악하고, 애자일 부서가 가장 큰 비즈니스 가치를 견인하는 이니셔티브에 몰입하는 데에 중요한 역할을 했다. 애자일 부서는 이를 효과적으로 수행하기 위해, 업무 항목과 스프린트, 릴리스를 중심으로 도구와 워크플로우, 데이터 필드 사용 방법에 대한 기준을 도입해 적용해야 한다. 기준 없이 도구를 사용하면 데이터 품질 문제가 발생하고, 제품 관리 및 포트폴리오 도구로 매트릭스와 상태를 도출하기 훨씬 더 어려워진다.

좋은 데이터가 없다면, 부서의 현재 상태를 논의하기 위해 제품 및 프로그램 매니저와 많은 회의를 하게 될 것이다. 그러면 기능 개발과 기술 ‘부채’ 해결에 대한 부담이 많은 개발자가 힘들어진다. 관리진은 적합한 프로세스와 도구를 선택해 체계적으로 적용, 애자일 개발 부서에 지나치게 부담을 주지 않으면서 전략적 우선순위를 견인하는 데 필요한 하향식 워크플로우와 보고서를 획득할 수 있다. editor@itworld.co.kr 


2019.08.05

“매끄럽고 섬세하게” 애자일 제품 관리 방법

Isaac Sacolick | InfoWorld
애자일 도구가 잘 작동하는지 질문하면 엇갈린 반응을 보인다. 때로는 부정적인 반응도 나온다는 이야기다. 애자일 도구는 애자일 부서를 도와주지만, 제품 소유주가 일할 때 필요한 모든 기능을 제공하는 것은 아니다.

이와 유사하게 프로그램과 포트폴리오 관리자를 도와주는 기능에도 제약이 있다. 애자일 도구는 부서와 릴리즈, 에픽에 대한 보고서를 제공하지만, 일반적으로 프로그래머가 하향식 전략 이니셔티브에 대해 보고할 때 충분히 도움을 줄 수 있는 정도는 아니다.

이런 이유로 부서의 제품 오너는 애틀라시안의 지라(Jira)를 선호하지 않는 경향이 있다. 또 프로그램 매니저는 지라나 마이크로소프트 애저 데브옵스(Azure DevOps)에서 필요한 보고서를 얻지 못한다. 이 도구들은 부서의 직능 가운데 일부에만 도움을 준다.

백로그, 스프린트 보드, 스크럼 보고서는 제품 매니저가 좋은 제품을 구상할 때 필요한 도구를 제대로 다루지 못한다. 또 프로그래머 매니저가 전략 목표를 애자일 부서가 수행하는 업무에 일치할 때도 도움을 주지 못한다. 파워포인트 프레젠테이션을 통해 비지니스 전략을 배우고, 업무 현황을 검토하는 제품·프로그램 관리자와의 회의가 많다면 애자일 제품 관리, 또는 포트폴리오 관리 플랫폼에 대한 준비가 되어 있다고 볼 수도 있다.

지라와 애저 데브옵스 같은 애자일 관리 플랫폼은 개발자와 테스터, 데브옵스 엔지니어로 구성된 애자일 딜리버리 부서가 주로 사용할 수 있는 도구이다. 활성 스프린트에 해당되는 사용자 스토리와 다른 종류의 업무 상태를 관리할 수 있는 보드가 있다. 또 미래의 스프린트를 위해 스토리를 평가, 배열, 우선순위를 부여할 때 도움을 주는 다른 백로그 관리 도구도 있다. 그리고 애자일 부서가 속도를 추적하고, 블록을 검토하고, 사이클 타임을 측정하고, WIP(진행 중인 업무)를 관리할 때 도움이 되는 번다운 보고서와 기타 보고서 기능이 내장되어 있다. 여기에 더해, 애자일 도구는 제품 오너의 스토리 작성, 승인 기준 문서화, 추정 스토리 포인트 검토에도 도움을 준다. 제품 오너는 스프린트 업무에 대한 우선 순위 부여, 진행 상황 추적에 이 도구를 사용한다.
 

“비전을 공유하고, 로드맵을 캡처하는 제품 관리 플랫폼”

제품 매니저와 오너는 고객과 유망 잠재 고객에 귀를 기울이는 것부터 시작한다. 고객의 요구를 판단하고, 비즈니스 가치를 전달하는 방법을 파악하고, 내부 이해당사자에게서 아이디어와 전략적 요구 사항을 반영하고, 우수한 고객 경험을 전달하는 제품과 서비스를 정의한다. 제품 개발 초기 단계의 업무는 시장 조사, 아이디어 테스트, 이해당사자와 전략에 대해 커뮤니케이션을 하는 과정으로 구성되어 있다.

이런 여정을 밟으면서, 리더와 애자일 부서에 목적을 커뮤니케이션하는 데 도움을 주는 산물, 비즈니스 목표, 사용자 페르소나, 경쟁 분석, 비즈니스 모델, 제품 비전이 발전하거나 개발된다.

제품 매니저는 전통적으로 파워포인트와 엑셀을 사용해 이런 산물을 캡처해 커뮤니케이션했다. 이런 도구는 제품 개발 초기에 이해당사자를 설득하고 부서를 일치시키는 데 효과가 있기는 하지만, 제품이 개발되고, 출시되고, 강화되는 동안 이해당사자의 기대 사항을 관리하는 업무에는 유용하지 못하다. 제품 매니저와 오너는 이런 책임을 이행하기 위해, 더 고수준의 피처 백로그를 관리해야 하고, 릴리스 상태에 대해 커뮤니케이션해야 하며, 장기 로드맵을 공유해야 한다.

그리고 이러한 도구를 부서가 전달할 솔루션에 몰입하고, 우선순위를 조정하고, 자체적으로 구성되도록 도움을 주는 애자일 원칙과 일치시켜야 한다.

지라 얼라인(Jira Align, 기존 AgileCraft), 아하(Aha), 버전 원 얼티메이트 에디션(Version One Ultimate Edtion)은 제품 매니저에게 이런 도구를 제공한다. 또 애자일 백로그 및 릴리스 계획에 대한 통합을 지원한다. 여기에는 제품 매니저가 제품 전략을 커뮤니케이션하는 중앙화 된 플랫폼, 이해당사자와 아이디어를 공유할 수 있는 도구들, 릴리스 상태와 로드맵에 대해 공유할 수 있는 보고 메커니즘이 포함되어 있다.

예를 들어, 아하는 지라, 애저 데브옵스, 랠리, 트렐로와 통합, 부서와 사용자 스토리, 피처, 릴리스에 대한 정보를 제공하는 기능을 제공한다. 이런 정보를 피처 백로그, 로드맵, 이니셔티브, 목표 같은 몇몇 아하 구성요소에 매핑할 수 있다. 이는 제품 매니저가 이해당사자와 현황 정보를 공유하고, 계획을 수립하는 상향식 인터페이스이다.
또 제품 매니저가 전략을 발전시키고, 비즈니스 모델을 포착하고, 사용자 페르소나를 커뮤니케이션할 수 있는 도구를 제공한다. 이런 도구를 사용하는 조직은 제품 매니저가 조직이 목표, 비전, 우선순위에 몰입할 수 있도록 도와주는 기준과 중앙화된 방식을 갖고 있다.
 

“규모가 큰 조직에서 일치와 기준에 원동력이 되어주는 포트폴리오 관리”

고객이 사용하는 제품, 워크플로우 애플리케이션, 통합, 비즈니스 인텔리전스 대시보드, 기타 기술 산물을 모두 개발하는 대기업에는 전략적 목표에 부합해 이니셔티브를 완성하도록 도와주는 추가적인 도구가 필요하다. 이런 대기업은 일반적으로 계층적인 조직 위계 구조를 갖고 있으며, 우선 순위에는 하향식 커뮤니케이션, 매트릭스에는 상향식 매트릭스가 필요하다. 이를 상태 보고서에 통합할 수 있어야 한다.

꽤 오래 전에 PPM(프로젝트 포트폴리오 관리) 도구가 등장했다. 조직의 전략 이니셔티브 관리와 추적에 도움을 줄 수 있는 도구다. 그러나 초창기 도구 중 상당수는 전통적으로 잘 구성되어 있는 폭포수 프로젝트 스케줄을 통합하도록 만들어져 있다. 시작일과 종료일이 규정된 태스크와 마일스톤 등이 여기에 포함된다. 이런 도구로는 자체 구성형 부서가 관리하며, 계속 바뀌는 스케줄과 우선순위가 특징인 스프린트와 사용자 스토리를 지향하는 애자일 프로젝트를 쉽게 통합할 수 없다. 애자일 프레임워크를 지원하지 않는 일부 PPM 도구는 릴리스와 에픽에 대한 애자일 데이터를 배포할 때 데이터 통합이 복잡해진다. 더 큰 문제는 ‘톱던(To-done)’ 방식의 스케줄링과 우선순위에 바탕을 둔 PPM 워크플로우는 포트폴리오 매니저와 애자일 부서 간 ‘문화적 충돌’을 초래한다는 것이다.

포트폴리오 매니저는 애자일 프랙티스 스케일링을 책임지고 있으며, SAFe, DAD, LeSS, Driving Digital 같은 프레임워크를 사용한다. 이들 또한 여러 애자일 부서를 관리하고, 프로세스 기준을 수립할 수 있는 포트폴리오 도구가 필요하다.

지라 얼라인과 버전 원 얼티메이트 에니션 같은 애자일 포트폴리오 도구를 이용, 애자일 부서가 수행하는 업무 위의 계층에서 이니셔티브를 관리할 수 있다. 또 부서가 속도와 역량에 대한 가시성을 제공하기 때문에, 부서에 이니셔티브를 할당하고 타임라인을 예상할 수 있다. 이니셔티브에 비즈니스 가치를 할당하고, 부서와 우선순위, 투자 수준을 적절히 조정해 일치시키는 도구도 제공한다.

지라 얼라인은 이니셔티브 포트폴리오 관리, 에픽 추적, 애자일 프로젝트 매트릭스 통합 기능 이상을 지원한다. 부서 간 종속성을 가시화해 관리하고, 위험을 추적하고, 애자일 부서와 전략 정보를 공유할 수 있는 도구도 갖고 있다.
 

애자일 부서에 도움을 주는 도구

애자일 도구는 전통적으로 부서의 백로그 관리, 요구사항에 대한 일치, 스프린트에 몰입, 신뢰할 수 있는 릴리스 구현에 도움을 주는 도구이다.

규모가 큰 조직에서, 애자일 도구가 제공하는 데이터는 관리진이 상태를 파악하고, 애자일 부서가 가장 큰 비즈니스 가치를 견인하는 이니셔티브에 몰입하는 데에 중요한 역할을 했다. 애자일 부서는 이를 효과적으로 수행하기 위해, 업무 항목과 스프린트, 릴리스를 중심으로 도구와 워크플로우, 데이터 필드 사용 방법에 대한 기준을 도입해 적용해야 한다. 기준 없이 도구를 사용하면 데이터 품질 문제가 발생하고, 제품 관리 및 포트폴리오 도구로 매트릭스와 상태를 도출하기 훨씬 더 어려워진다.

좋은 데이터가 없다면, 부서의 현재 상태를 논의하기 위해 제품 및 프로그램 매니저와 많은 회의를 하게 될 것이다. 그러면 기능 개발과 기술 ‘부채’ 해결에 대한 부담이 많은 개발자가 힘들어진다. 관리진은 적합한 프로세스와 도구를 선택해 체계적으로 적용, 애자일 개발 부서에 지나치게 부담을 주지 않으면서 전략적 우선순위를 견인하는 데 필요한 하향식 워크플로우와 보고서를 획득할 수 있다. editor@itworld.co.kr 


X