An Agile approach

지금 열정적으로 수행하는 ‘좋은’ 계획이 다음 주에 실행할 ‘완벽한’ 계획보다 낫다. - 패튼 장군

Agile Manifesto를 이해한 팀은 어떻게 일할까?

프로젝트에 대한 애자일 접근법

위의 네가지 가치를 전부 내재화한 애자일 팀은 어떻게 일을 하고 있을까?

• 하나의 팀으로 일한다.
• 짧은 이터레이션 단위로 일한다.
• 이터레이션이 끝날 때마다 무엇인가를 내놓는다.
• 비즈니스 측면에서의 우선순위에 초점을 맞춘다.
• 점검하고 적응한다.

애자일 팀은 하나가 되어 일한다

프로젝트를 성공시키는 데 중요한 것은 팀의 모든 구성원들이 공통의 목표를 지향하는 하나의 팀원으로서 행동하는 것이다.

• 그렇기에 협의를 거치지 않은 무언가를 일방적으로 전달하는 행위는 금기다.
• ”우리는 이 안에서 하나다” 라는 인식을 가져야 한다. 즉, 연대의식이다.
• 각 개인의 역할이 있되, 하나의 팀이라는 의식을 새겨야 한다.

• 개인의 역할은 위와 같이 4가지로 구분된다.
• 마지막 프로젝트 관리자의 경우, 제품 책임자 혹은 프로젝트 관리자가 겸임하는 경우도 있다.

애자일 팀은 짤막한 이터레이션 단위로 작업한다

• 기존의 계획 방법에는 Phase를 도입하여 일을 진행했었다.
• 즉, 특정 단계를 넘어서야 다음 단계를 진행할 수 있었기 때문에 상대적으로 무게가 실렸다.
• 하지만 Agile에서는 그렇게 일처리를 하지 않는다.
• 이터레이션이라는 단위를 기반으로 모든 작업(분석, 설계, 코딩, 테스팅 등)이 반복된다.
• 이렇기 때문에, 이터레이션에는 시간제약이 엄격할 수 밖에 없다.
• 반복이 더 중요하기 때문에 더 많은 논의를 하다 길어지는 것을 방지해야 하기 때문이다.
• 대부분은 2~4주 길이를 사용한다.

애자일 팀은 이터레이션이 끝날 때마다 뭔가를 내놓는다

• 이터레이션의 길이로 토론하는 것보다, 더 중요한 것은 해당 이터레이션 이후에 delivery가능한 형태의 제품이 나오냐이다.
• 그렇다고 매 이터레이션 마다 릴리즈를 대비하라는 말은 아니다.
• 릴리즈를 대비하여 그에 상응하는 모든 프로세스를 한번은 시행해보아야한다는 의미에 가깝다.
• 즉, 1회의 릴리즈는 하나 이상의 이터레이션들로 구성된다.

애자일 팀은 사업적 관점에서의 우선순위에 초점을 맞춘다

이를 위해 두 가지의 접근법을 사용한다.

• 애자일 팀은 제품 책임자가 명시해준 우선 순위에 따라 기능을 구현한다.
  • 앞서 제품 책임자는 최적의 결과물을 가져오기 위한 기능의 우선순위를 정립한다고 설명했다.
  • 이 때, 기능 명세는 기술적 의존도가 최소가 되도록 작성되어야 한다. 그래야 독립적으로 우선순위를 설정할 수 있다.
• 애자일 팀은 독립적인 작업을 마치는 데 집중하기 보다는 사용자 입장에서 가치가 산정된 기능을 구현하고 전달하는데 초점을 맞춘다.
  • 이를 위한 방법이 User Story이다.
  • <이런 타입의 사용자>는 <이런 종류의 비즈니스 가치를 증대시키기 위해> <이러저러한 기능을> 사용할 수 있다.
  • 이 과정에서 중요한 것은, 이 user story를 기반으로 많은 대화를 하는 것이다.

애자일 팀은 점검하고, 적응한다

• 계획은 불완전하다. 모든 불확실성을 감안할 수 없다.
  • 인력 구성 변동
  • 기술적 문제
  • 사용자의 심적 변동
  • 경쟁사로 인한 대응 방침 변화
• 변화를 새로운 기회로 보고 계획을 수정해야 한다.
  • 새로운 이터레이션마다 이전 이터레이션에서 배운점을 토대로 적응한다.
  • 계획과 추정을 변경한다.
• 이런 배움은 제품 책임자와 고객에게도 적용된다.
  • 보여줄 수 있는 소프트웨어를 기반으로, 위 둘은 구현된 기능에 대한 우선순위에 대해 재고하게 된다.
  • 이를 기반으로 실질적으로 고객이 원하는 기능을 알아차릴 수 있다는 점에서 가치는 증대된다.

계획 과정에 대한 애자일 접근법

프로젝트는 일련의 단계를 밟는 과정이라 생각하면 안된다. 새로운 능력, 새로운 지식을 창출하는 원천으로 보아야 한다. 그리고 그 능력은 제품 형태로 인도되며, 지식은 최고의 제품을 만드는데 사용된다. - 맥커머

• 즉, 프로젝트는 그 과정에서 발생하는 부산물을 계속해서 추적하고 배워야 한다는 점을 시사하고 있다.
• 애자일 프로젝트의 경우에 이 능력과 지식을 바탕으로 작업의 방향을 탐지하는데 사용한다.
  • 제품의 경우에는 어떠한 제품이 되어야 하는지 알도록 도와주고, 프로젝트의 경우에는 팀, 관련 기술, 위험성 같은 것이 될 수 있겠다.
• 애자일 프로젝트는 목적지를 향해 달리는 경주라기보다는, 시간을 정해놓고 멀리가는 정도를 경쟁하는 경주에 가깝다.
  • 무엇을 인도하느냐보다, 언제 끝날지에 대해 알고 있다.
  • 이의 이면에는 프로젝트의 결과라는 것은 미리 알 수 없다는 전제가 은연중에 깔려있다.

다층적인 계획 과정

수평선을 넘어선 위치까지 도달하는 계획을 짜는 것이 가능할까? 그 정확도는 급감할 것이다. 프로젝트 계획도 마찬가지다.

• 가시권 바깥에 있는 지점까지 계획을 하는 경우, 그 계획의 정확도는 급감한다.
• 즉, 장기적 계획은 오히려 독이 될 가능성이 높다.
• 프로젝트 계획 과정의 위험이 발생하는 경우는 다으모가 같다.
  • 수평선을 보고 계획을 수정할 시간을 주지 않는 경우
  • 수평선 너머를 계획하려하는 경우

• 애자일에서는 세가지의 수평선을 기준으로 계획을 세운다.
  • 릴리즈
  • 이터레이션
  • 오늘
• 릴리즈
  • 새롭게 포함될 스토리, 테마를 고려한다.
  • 이 과정에서의 목표는 프로젝트 범위, 일정, 자원에 대한 적절한 답을 얻는 것이다.
• 이터레이션
  • 이터레이션의 시작에서 이전에 끝난 이터레이션 성과에 근거하여 우선순위 높은 일을 골라낸다.
  • 릴리즈보다 바라보는 목표의 크기는 좀더 작다.
• 오늘
  • 매일의 미팅을 통해 활동을 조율하고 동기화한다.
  • 하루 이상 내다보지 않고 오늘만 사는 방식으로 처리한다.

이런 계획 과정을 통해, 만드는 계획에 있어 가시적이고 중요한 문제에 집중할 수 있다.

만족 조건

• 목적은 단순히 제품만을 위한 것이 아니다.
• 해당 목적을 이루기 위한 제약조건(일정, 예산, 품질)을 만족했을 때 비로소 목적을 달성했다고 할 수 있을 것이다.
• 이를 만족 조건이라 한다. 이는 프로젝트 성패에 있어 중요하다.

• 하지만 이런 만족 조건을 모두 충족시킬 수 없는 경우가 있다.
• 제품, 일정, 예산, 품질을 현실적으로 모두 맞추기는 쉽지 않다. 이런 경우, Trade-off를 통해 선택해야 한다.
• 이런 만족 조건들은 릴리즈 계획 과정과 이터레이션 계획 과정을 움직이는 원동력으로 작용한다.

요약

• 애자일 팀은 하나가 되어 일한다.
• 그럼에도 각자의 역할이 있다.
  • 제품책임자: 제품의 Vision, 작업 기능에 우선순위를 매김
  • 고객: 자금줄, 구매자
  • 개발자: 제품에 연관있는 사람들
  • 제품 관리자: 리더십을 이끄는 사람
• 이터레이션 단위로 일한다.
  • 이터레이션의 끝에는 동작하는 제품이 있다.
  • 개발 기능은 사업 관점에서 바라본 우선순위에 따라 선정한다.
• 사용자 스토리는 사용자 요구를 표현하기 위해 사용하는 방법이다.
• 계획의 유효기간은 짧다. 따라서 시의 적절하게 바꾸어 나가야 한다.
• 프로젝트는 새 능력과 지식을 빠르고 신뢰있게 만들어내는 원천이다.
  • 제품에 대한 지식, 프로젝트에 대한 지식을 생산한다.
  • 이는 제품과 팀에 다시 반영하여, 최고의 가치를 성취하는데 도움을 준다.
• 애자일 과정에서 계획은 세 단계로 구성된다.
  • 릴리즈: 3개월 ~ 6개월
  • 이터레이션: 2주 ~ 4주
  • 오늘: 하루 - 매일의 미팅에서 약속한다.
• 제품 책임자의 만족 조건을 이해하는 것은 계획 과정에서 아주 중요하다.
  • 이 제약 사항을 만족 시킬 방법을 찾아나간다.
  • 이 과정에서 계획이 변경될 수도 있다.

토론 거리

• 한 팀으로 일한다는 생각은 프로젝트에 어떤 영향을 미쳤는가?
• 현재 프로젝트에서의 만족 조건들은 무엇인가?
• 그 만족 조건들에 대해 이해 당사자들이 동의하였는가?
• 만약 만족 조건에 대해 합의하지 않은 상태로 진행하게 되면 어떤일이 생길까?
• 그림 3.2를 보면, 이터레이션 계획에서는 예산과 일정이 만족조건으로 사용되지 않는다. 이유가 무엇일까?
  • 이미 릴리즈 계획 과정에 정의되어 input으로 넣어지고 있기 때문에?

Reference

• 불확실성과 화해하는 프로젝트 추정과 계획
• Agile Estimating and Planning