애자일 개발의 핵심 원칙 가운데 하나는 모든 스프린트의 끝에 작동하는 소프트웨어를 제공하는 것이다. 이를 위해 철저한 사용자 시나리오 수락 기준을 정의하고 팀 전체가 스프린트에 전념하고 테스트를 자동화하고 스프린트 결과를 시연하고 코드의 완성도와 프로덕션 적합성을 확보하기 위한 기타 활동의 성숙도를 높인다.

CI/CD(지속적 통합/지속적 제공) 파이프라인을 포함한 데브옵스 방식을 도입하는 조직은 코드를 테스트 환경으로 푸시하기 위한 자동화를 개발한다. 가장 진보된 팀은 모든 스프린트, 또는 이보다 더 빈번하게 코드를 프로덕션에 배포하는 지속적 배포를 구현한다.

이 팀에 다음 달, 또는 다음 릴리스에 무엇을 제공할 지를 물으면 대부분 대답을 잘 하지 못한다. 팀의 우선순위가 고객과 최종 사용자에게 긍정적인 영향을 미칠지 어떻게 확신하는지 물으면 이들은 제한적인 이해와 소통, 가시성으로 인해 이 질문에 충분히 답할 수 없음을 인정한다. 나아가 다음과 같은 더 심층적인 질문을 고려해 보자.

- 구현하기 쉬워 보이는 하나의 사용자 시나리오가 여러 스프린트에 걸쳐 실행되는 여러 시나리오로 이어지는 경우가 얼마나 자주 있는가?
- 제품 소유자가 백로그에 기재할 때부터 고객에게 완전히 제공될 때까지의 시간으로 측정되는, 새로운 기능의 사이클 시간은 어느 정도인가?
- 팀이 불필요한 작업으로 시간을 낭비하는가? 또는 팀이 새로운 기능을 제공하는 과정에서 표준이 발전하는가?
- 채용, 인프라 업그레이드, 교육을 비롯해 계획과 실행을 위해 1~2회 스프린트보다 긴 리드 시간이 필요한 활동으로 인해 팀의 작업이 차단되는가?
- 운영 팀이 중요한 애플리케이션 릴리스의 시점, 범위, 활동 또는 위험에 대해 전혀 준비가 되지 않은 상황이 얼마나 빈번하게 발생하는가?

이와 같은 질문에 대한 답을 모르거나 질문이 이미 알려진 문제라면 그 조직은 계획에 더 신경을 써야 한다.

애자일 개발 팀은 더 빈번하고 안정적인 애플리케이션 릴리스를 위한 기술 프로세스와 자동화에 많은 투자를 해왔다. 그런데 제공한 결과물이 비즈니스 가치를 제공하도록 보장하기 위한 측면에서는 어떠한가?

애자일 팀에서 계획이 어려운 이유

필자는 많은 애자일 리더와 계획에 대해 이야기하며 다음 스프린트 이상의 미래를 계획하는 백로그를 개발하기 위해 시간을 투자하는지 여부를 물었다.

일부는 여러 스프린트를 미리 계획하는 것은 애자일과 맞지 않는다고 말한다. 이들의 관점에서 애자일은 제품 소유자와 팀이 고객 피드백을 듣고 애플리케이션을 통해 생성된 사용자 행동 데이터를 검토하고 여타 신호를 감안해서 매 스프린트 시작 시 우선순위를 조정할 수 있게 해준다. 정리하자면 “어차피 우선순위를 조정할 텐데 미리 계획할 필요가 있는가?”이다.

계획을 하고자 하지만 효과적인 계획을 위한 실천 방안과 협업 체계를 개발하지 못한 팀도 있고, 제품 소유자가 미래의 우선순위에 대한 세부 정보를 충분히 제공하지 않거나 제품 소유자가 너무 많은 우선순위를 전달하는 경우도 있다. 대부분의 팀은 충분히 잘 정의된 요구사항을 받지 못하고 이로 인해 계획이 어려워지고 비용도 많이 들게 된다.

필자가 항상 듣는 이야기는 계획할 시간이 충분히 주어지지 않으며 계획 프로세스가 없다는 것이다. 팀은 너무 많은 기능과 사용자 시나리오, 기술 부채, 운영 개선 및 기타 개발 우선순위에 매몰돼 있다. 계획이 우선순위에 들어갈 여지가 없다.

비즈니스에 미래를 내다보는 계획이 필요한 이유

성숙한 기업은 애자일 팀에 미래를 내다보는 계획과 로드맵을 필수적으로 요구하는 경우가 많다. 애플리케이션 릴리스와 연계된 다른 비즈니스 활동을 계획하기 위해 필요하기 때문이다. 소프트웨어 기업이라면 이런 비즈니스 활동에는 마케팅 자료 준비, 영업팀 교육, 주요 고객을 대상으로 한 새로운 기능에 대한 정보 제공 등이 포함된다. 또한 오늘날에는 더 많은 기업이 내부 및 고객의 요구사항에 모두 대처하는 애플리케이션을 개발한다. 이런 조직은 새로운 기능에 대한 직원 교육과 고객 지원 기능 업데이트도 감안해야 한다.

애자일 팀은 긴 리드 시간이 필요한 요구사항도 고려해야 한다. 예를 들어 새로운 기술을 도입하는 경우 운영 팀은 클라우드 또는 데이터센터에서 이 기술을 설치하고 구성하기 위해 시간이 필요하다. 조직에서 직원을 채용하거나 서비스 제공업체에서 파견된 신규 인력을 온보딩해야 하는 경우에도 대부분 다음 스프린트를 넘어서는 범위의 사전 계획이 필요하다.

애자일 계획의 역설 해결하기

애자일 팀과 계획할 때는 여러 가지 원칙을 고려해야 하는데, 이 가운데 핵심적인 5가지는 다음과 같다.

1. 조직은 미래를 내다보는 관점을 가져야 한다. 비전 성명이나 전략적 계획이 될 수도 있고, 고객이나 사용자가 필요로 하는 것이 무엇인지, 목표로 하는 비즈니스 성과 지표는 무엇인지에 대한 일종의 북극성 역할을 하는 기타 커뮤니케이션이 될 수도 있다. 진짜 북극성과 달리 이 커뮤니케이션은 민첩해야 하며 고객과 비즈니스 요구사항이 발전함에 따라 반복적인 업데이트도 필요하다. 

2. 팀에는 계획할 시간이 필요하다. 계획은 공짜로 되지 않는다. 따라서 미래를 내다보는 계획을 중시하거나 필수로 여기는 기업이라면 팀이 브레인스토밍을 하고 데이터를 검토하고 고객으로부터 직접 이야기를 듣고 개념 증명에 투자하고 실제 시나리오에 우선순위를 부여하기 몇 주 전에 사용자 시나리오를 문서화할 수 있는 시간을 부여해야 한다.

3. 팀에는 애자일 원칙 및 사용 중인 애자일 백로그 툴에 부합하는 규정된 계획 프로세스가 필요하다. 이 계획 프로세스는 사람들의 시간을 효율적으로 사용해야 하며 명확히 규정된 출력과 확립된 역할 및 책임이 필요하다. 또한 조직은 계획 표준을 고려하고, 팀이 자율적인 구성을 통해 애플리케이션과 기술의 상세한 부분을 직접 처리할 수 있는 영역을 파악해야 한다.

4. 계획은 애자일 개발 팀이 사용하는 기본 아티팩트, 특히 사용자 시나리오의 요구사항 품질, 사용자 시나리오 평가를 위한 단계, 그리고 시나리오가 기술, 데이터, 보안, 사용자 경험 및 기타 표준과 정렬되는지 여부와 부합해야 한다. 또한 계획은 프로덕션 환경에서 애플리케이션을 지원하기 위한 운영 요건과도 정렬되어야 한다.

5. 계획 실행 방안에는 효과와 영향을 측정하는 메커니즘이 필요하다. 팀이 계획에 따라 결과를 제공하고 있는가? 팀이 우선순위화된 계획으로 비즈니스에 영향을 미치고 있는가? 팀이 릴리스 이후 수집된 정보와 데이터를 사용해 방식과 우선순위를 재조정하는가?

이런 원칙은 광범위한 계획 실행으로 이어질 수 있다. 규모가 큰 조직은 계획 활동의 일정이 혁신 및 계획 반복 중에 정해지는 SAFe의 PI 계획 프로세스를 채택할 수 있다. 민첩한 조직은 팀이 매 스프린트에서 사용자 시나리오를 제공하기 위한 작업과 함께 계획 활동에 전념하는 지속적인 애자일 계획을 고려해야 한다. 조직에 따라서는 애자일 제품 및 포트폴리오 관리 툴을 통해 계획하는 방안도 살펴볼 만하다.

계획이 없으면 길을 잃기 쉽다

애자일 방식의 강점은 팀이 명확히 규정된 단기 결과물에 집중할 수 있다는 점이다. 약점은 팀이 이 과정에서 길을 잃기 쉽다는 것이다. 팀은 완료된 시나리오를 통해 과거의 제공 내역을 검토해서 중장기적 성과를 평가해야 한다.

팀이 제공하기로 약속한 것을 실제로 제공하는가? 결과물이 고객과 최종 사용자에게 긍정적인 영향을 미치는가? 백로그를 우선순위화하고 요구사항을 다듬기 위한 커뮤니케이션 및 피드백 루프가 존재하는가?

애자일 계획 실천 방안을 확립하면 팀이 이러한 공백을 메우는 데 도움이 될 수 있다. editor@itworld.co.kr 

원문보기:
http://www.itworld.co.kr/news/131827#csidx3e6119cdda39d70afb5fe4b964caa1b