12장 효율적인 협업을 위한 애자일 문화

[fkdl0048]

12장 효율적인 협업을 위한 애자일 문화

모두가 알지만 실천하기는 쉽지 않은 애자일

소프트웨어 개발은 계획적이어야 하며 추적 가능해야 한다. 동료는 효율적인 협업을 위해 서로가 무슨 일을 하고 있는지 알고 싶어 한다. 팀은 진척 상황을 추적해서 미래 업무를 계획해야 하며, 개발 과정에서 새로운 정보가 드러나며 업무 방향을 조율할 수 있어야 한다. 신중하게 계획된 절차를 대비해놓지 않는다면 프로젝트는 늘어지고, 끊임없는 외부 요구사항으로 인해 개발 과정은 산만해지며, 운영 이슈는 개발자를 끝없이 방해할 것이다.

애자일 선언문

애자일 개발 기법을 맛보려면 먼저 애자일 철학부터 이해해야 한다. 애자일은 2001년 익스트림 프로그래밍, 스크럼, 기능 주도 개발, 실용주의 프로그래밍 같은 기존 개발 방법론의 릳들이 협업해 만들었다.

애자일 선언문은 다음과 같다.

우리는 소프트웨어를 개발하고 다른 사람들의 개발을 도움으로써 소프트웨어 개발의 더 나은 방법을 찾아가고 있따. 이를 통해 우리가 추구하는 가치는 다음과 같다.

• 절차와 도구보다는 각 개인 그리고 서로 간의 상호작용
• 포괄적인 문서보다는 동작하는 소프트웨어
• 계약 협상보다는 고객과의 협업
• 계획을 따르기보다는 변화에의 대응
  각 문자에서 앞쪽에 언급한 것이 가치가 없다는 뜻이 아니라 뒷쪽에 언급한 것에 더 큰 가치를 둔다는 뜻이다.

애자일 방법론은 폭포수 방법론과는 반대되는 방식으로 언급된다. 또한 애자일이 유행을 하게 되며 전문가, 자격증, 개발방법론 등이 넘처나면서 가장 첫번째 원칙이 훼손되는 현상도 나타났다.

애자일 방법론 프레임워크

애자일 방법론 프레임워크 중 가장 보편적인 두 가지는 스크럼과 칸반이다. 스크럼이 가장 널리 알려져 있는데 계힉을 수정하는 체크포인트를 빈번하게 가져가면서 짧은 개발 주기를 반복한다. 개발 업무는 스프린트로 나눈다. 스프린트의 기간은 다르지만 2주가 가장 보편적이다. 각 팀은 스프린트를 시작할 때 스프린트 계획 회의를 통해 사용자 스토리나 태스트라고 표현하는 개발 업무를 팅뭔들에게 할당한다.

계획이 끝나면 개발자들은 각자 맡은 업무를 시작한다. 진척 상황은 티켓팅이나 이슈시스템을 이용해 추적한다. 매일 아침 짤막한 스탠드업 회의를 통해 업데이트를 공유하고 문제점을 논의한다. 각 스프린트가 끝나면 팀은 완료한 작업을 리뷰하고 새로 발견한 부분을 논의하며 주요 지표를 확인하고 절차를 세밀하게 조정하는 회고회의 시간을 갖는다.

중요한 점은 팀이 스크럼이나 칸반의 이상적인 애자일을 그대로 따라가는 경우는 드믈다. 보통은 일부 원칙만 가지고 나머지는 팀에 맞게 변경하거나 무시하는 경우가 많다.

스크럼으로 하는 애자일 개발 방안

대부분의 소프트웨어 팀은 어떤형태로든 스크럼을 채택하고 있으므로 스크럼이 어떻게 돌아가는지 정도는 이해해둘 필요가 있다. 모든 계획은 대부분 사전 업무로 시작한다. 개발자와 제품 관리자는 새로운 사용자 스토리를 생성하며 백로그의 티켓은 선별돼 있다.각 스토리는 복잡도를 예측해 스토리 포인트를 부여하고 태스크로 분리한다. 규모가 큰 스토리는 스파이크 스토리를 부여하고 태스크로 분리한다.

규모가 큰 스토리는 스파이크 스토리를 이용해 설계하고 연구한다. 스트린트 계획을 진행하는 동안 팀은 다음 스트린트에서 어떤 스토리를 완료할지 결정하고 스토리 포인트를 이용해 업무 부하를 관리한다.

사용자 스토리

사용자 스토리는 사용자의 관점에서 필요한 기능을 정의하는 특별한 종류의 티켓이다. 이 티켓은 "나는 <사용자>로서 <목적>을 하기 위해 <기능>을 원한다." 라는 형태로 이뤄진다. 요구사항을 서술하므로 사용자에게 가치를 전달하는 것에 더 집중할 수 있다.

태스크

하나의 스토리는 소요 시간에 대한 예측, 여러 개발자 간의 작업 분배, 구현 진도의 추적 등을 위해 더 작은 크기의 태스크 여럿으로 분리해야 한다. 업무를 더 작은 단위로 나누는 가장 좋은 방법은 아주 상세한 설명을 작성하는 것이다.

스토리 포인트

팁의 업무량은 스토리 포인트로 측정한다. 스토리 포인트란, 팀 전체가 동의한 작업량 단위를 말한다. 스프린트의 업무량은 개발자의 수에 개발자당 스토리 포인트를 곱한 값이다. 예를 들어 4명의 엔지니어에게 각각 10포인트씩을 할당했다면 스프린트 업무량은 40포인트가 된다. 사용자 스토리에 대한 시간 예측 역시 스토리 포인트로 정의한다.

백로그 선별

백로그 선별 또는 그루밍은 주로 계획 회의를 하기 전에 시행한다. 백로그는 앞으로 처리해야 할 스토리의 목록이다. 이런 스토리의 작업 내용을 최신 상태로 유지하고 우선순위를 결정하는 과정이 바로 '선별'이다.

스프린트 계획

스프린트 계획 회의는 사전 작업을 완료한 시점에 진행한다. 계획 미팅에서는 협업이 중요하다. 엔지니어링 팀은 제품 관리자와 함께 어떤 업무를 처리할지를 결정한다. 우선순위가 결정된 스토리에 대한 논의를 진행하고, 엔지니어는 제품 관리자와 함께 그 스토리를 이번 스프린트에 할당할지 여부를 결정한다.

신속한 업무 공유를 위한 스탠드업 회의

스프린트 계획을 끝내면 이제 업무가 시작되고 팀은 스탠드업 회의를 진행하게 된다. 스탠드업은 스크럼 회의 또는 허들이라고도 한다. 또한 모든 팀원이 서로 친적사항을 공유함으로써, 각자의 업무에 집중할 수 있으며, 스프린트 목표를 달성하는 데 방해가 되는 요소에 대응할 수 있다.

진솔한 피드백이 오가야 하는 리뷰

스프린트 리뷰는 매 스프린트 사이에 진행하며 주로 데모와 프로젝트 리뷰 등 두 부분으로 나뉜다. 데모 시간에는 모든 팀원이 이번 스프린트에서 자신이 담당했던 업무를 다른 팀원들에게 보여준다. 그 후에는 목표에 대비해 현재 스프린트를 평가한다. 스프린트가 성공적이었다면 목표를 달성하고 완료한 스토리 비율도 높을 것이다.

재평가와 조정을 위한 회고

회고 회의에서는 지난번 회고 이후로 잘 해낸 일과 잘 해내지 못한 일에 대한 함께 이야기한다. 이 회의는 주로 공유, 우선순위 결정, 문제 해결 등 세 가지 단계로 진행한다.

중장기 계획을 위한 로드맵 수립

2주 단위 스프린트는 중소 규모의 업무를 수행하기 좋은 방법이지만 규모가 더 큰 프로젝트는 더 세밀한 계획이 필요하다. 개발자는 고객과 약속한 출시일을 지켜야 하고 비즈니스는 어떤 팀에 엔지니어가 더 필요할지를 알아야 하며 대규모 기술 프로젝트는 더 작은 크기로 나누고 계획하고 조율해야 한다.

지금 진행하는 프로젝트도 당장의 마일스톤보다 3개월 정도로 목표를 잡는게 좋을 것 같다.

결론

애자일에 대한 가장 중요한 점은 꼭 개발이 아니더라도 변경이 잦은 반복성이 있는 모든 것들에 적용할 수 있다는 점이다. 또한 권장하는 방법들을 모두 사용하기보다 핵심적인 부분들을 적용하고 나머지는 팀에 맞게 조정하는 것이 중요하다.

논의사항

• 애자일이 이상적인 방법이라고 불리는 이유가 뭘까요?