애자일 Agile 개발 방법론

전통적인 프로젝트 수행 방식의 한계

• 프로젝트 초기에 구체적인 요구사항을 도출하기 어렵다.
• 프로젝트 중간에 발생하는 요구사항의 변경을 반영하기 어렵다.
• 프로젝트 과정 중 중간 문서 산출물이 많이 요구되어 개발 업무가 지연된다.
• 프로젝트 관리자 중심의 명령과 통제 방식때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션이 부족하다.

 

애자일 소프트웨어 개발 선언문의 중심 내용

• 프로세스와 도구보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다.
• 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.
• 계약 협상보다는 고객과 협력에 더 큰 가치를 둔다.
• 계획을 따르기보다는 변화에 대응하는 것에 더 큰 가치를 둔다.

 

애자일 소프트웨어의 개발 원칙 12가지

1. 소프트웨어 개발의 최우선 목표는 빠르고 지속적으로 가치 있는 소프트웨어를 전달하여 고객을 만족시키는 것이다.
   Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2. 고객의 경쟁력을 위해서라면 비록 개발 후반일지라도 요구사항의 변경을 환경한다.
   Welcome changing requirements, even late in development, Agile processes harness change for the customer's competitive advantage.
3. 동작하는 소프트웨어를 2주일에서 2개월까지 짧은 간격으로 자주 전달하라.
   Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
4. 요구사항을 내는 고객과 개발자는 전체 프로젝트에서 매일 함께 일해야 한다.
   Business people and developers must work together daily throughout the project.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하고, 그들에게 필요한 환경과 지원을 제공하고, 일을 잘 끝낼 수 있도록 신뢰하라.
   Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.
6. 개발팀 내부에서 정보를 전하는 가장 효율적인 방법은 서로가 얼굴을 마주 보면서 대화하는 것이다.
   The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. 작동하는 소프트웨어는 진척의 주된 척도다.
   Working software is the primary measure of progress.
8. 지속 가능한 개발을 장려하며 스폰서, 개발자, 사용자는 일정한 개발 속도를 계속 유지해야 한다.
   Agile processes promote sustainable development, the sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. 기술적 탁월성과 좋은 설계에 갖는 지속적 관심이 민첩성을 높인다.
   Continuous attention to technical excellence and good design enhances agility.
10. 간단함, 즉 하지 않은 일의 양을 최대화하는 기술이 필수적이다.
    Simplicity -- the art of maximizing the amount of work not done -- is essential.
    나중에 변경하게 될 과도한 분석과 설계는 바람직하지 않다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직화된 팀에서 창발한다.
    The best architectures, requirements, and designs emerge from self-organizing teams.
    자기 조직화된 팀에서는 구성원이 누군가의 지시가 없어도 자기 주도적으로 업무를 수행하고 유기적으로 협력한다.
12. 정기적으로 어떤 방법이 팀에 더 효과적일지 숙고하며 이에 따라 팀의 행동을 조율하고 조정한다.
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    프로젝트 중간에 주기적으로 참여자들이 모여 잘한 점이나 잘못한 점을 토론한다.

 

사용자 스토리, 기술 스토리, 완료 조건

• 사용자 스토리: 제품 기능을 문장 형태로 기술한 것.
  [누가] [비즈니스 가치]를 위해 [어떤 기능]을 원한다.
  e.g. 교육생은 수강신청을 위해 신청, 취소, 리스트보기를 할 수 있다.
• 기술 스토리: 사용자 스토리를 지원하는 기술적/관리적 업무를 기술한 것.
• 완료 조건: 관리자와 팀원을 생각을 일치시킬 데 도움이 되는 개발 결과.

 

제품 백로그

제품 백로그는 제품 개발에 필요한 모든 업무를 우선순위화한 목록이다.

 

제품 백로그 구성 항목은 기본적으로 다음 내용을 포함할 수 있다. 제품 책임자 주도하에 주기적으로 개발팀과 협의하여 우선순위를 갱신한다.

• 요구 기능과 비기능 요구사항
• 기술적, 관리적 업무 (아키텍처 수립, 하드웨어 선정과 발주, 교육 훈련, 통합 테스트 등)
• 문제 해결 (모듈 안정화, 사용성 개선 등)
• 수정해야 할 버그

 

제품 백로그 작성 지침

1. 상호 독립적이어야 한다.
2. 변경이 가능해야 한다.
   실제로 구현할 때 필요한 세부 내용은 해당 스프린트 계획 미팅에서 도출하면 된다.
3. 사용자와 고객에게 가치가 있어야 한다.
   그리고 고객이 이해할 수 있는 언어로 작성해야 한다.
4. 추정이 가능해야 한다.
   개발 규모와 투입공수 등을 추정할 수 있어야 한다.
5. 크기가 적절해야 한다.
   스프린트 기간 안에 완료할 수 있는 수준으로 나누는 것이 좋다.
6. 테스트가 가능해야 한다.
   너무 개념적으로 기술하지 않고, 테스트 가능한 수준으로 기술해야 한다.

 

릴리스 계획

뼈대가 되는 전체 일정으로, 여러 개의 스프린트 계획으로 구성되어 있다. 다만 스프린트 계획은 미리 수립하지 않고 해당 시점에 수립한다. 

 

릴리스 계획 수립 절차

1. 제품 백로그 작성
   사용자와 제품 책임자, 개발팀이 한데 모여 프로젝트에서 수행할 사용자 스토리와 기술 스토리를 도출하고 우선순위를 선정하여 정리한다.
2. 스토리 점수 추정
   개발팀은 제품 백로그의 스토리 점수를 추정한다. 이 때 해결해야 할 이슈와 리스크를 식별하고 별도로 기록하여 관리한다.
3. 스프린트 기간 설정
   너무 짧으면 팀원에게 부담이 될 수 있고, 너무 길면 예상치 못한 상황에 계획을 변경할 수 있다.
4. 평균 개발 속도 추정
   개발 속도는 개발팀에서 단위 스프린트에 완료할 수 있는 스토리 점수의 합을 의미한다. 물론 이 값은 초기 가정 값이며 스프린트를 수행하면서 갱신해 나가야 한다.
5. 전체 일정 추정
   제품 백로그의 전체 스토리 점수와 개발 속도를 고려하여 적절한 전체 일정 계획을 수립한다. 예를 들어, 평균 개발 속도가 25점이고, 2주일 짜리 스프린트의 평균 개발 속도가 25점이라면 이 프로젝트는 최소 스프린트 8개, 4개월이 필요하다. 이때 요구사항의 불명확성과 프로젝트 리스크를 고려하여 일정에서 버퍼를 반드시 설정해야 한다. 버퍼는 일정 지연을 보완하고 제품 마무리를 위해 스프린트 1~2개(전체 일정의 10~20%)를 설정하면 좋다.
6. 스토리 우선순위 선정
   제품 책임자와 개발팀은 스토리에서 우선순위를 선정하고 스프린트 단위로 스토리를 할당한다. 처음 스프린트 2~3개는 평균 개발 속도보다 10~20% 낮춰서 배정한 후 점차 높여 나간다. 새로운 프로젝트를 수행할 때는 아직 팀워크를 형성하기 전이라 생각만큼 퍼포먼스가 나지 않는다.

릴리스 계획 예

 

스프린트

프로젝트를 짧은 여러 개의 스프린트 단위로 나눈다. 스프린트를 계획할 때, 기존에 계획한 요구사항과 전 스프린트에서 나온 변경사항을 비교하고, 구성원 간의 검토를 거쳐서 우선순위화 하여 반영한다. 중간에 요구사항을 변경해도 다음 스프린트에 언제든지 반영할 수 있다.

 

스프린트 기간은 개발 범위에 상관없이 2~4주일로 규칙적이다. 이를 타임박싱이라고 한다. 애자일을 처음 적용하는 팀이라면 2주일로 설정하는 게 적당하다.

 

각 스토리를 누가 작업할 것인지는 미리 결정하지 않고 어느 스프린트에서 어떤 스토리를 수행할 것인지만을 결정한다. 이는 담당자를 미리 결정하면 자신의 업무에만 관심을 갖고 전체 업무에는 관심을 갖지 않기 때문이다.

 

스프린트 안에서 분석, 설계, 구현, 테스트 같은 과정이 있긴 하지만 공식적으로 산출물을 만들고 다음 단계로 넘어가는 형태는 아니다. 어떻게 중간 산출물을 최소화하면서 품질 높은 제품을 만들 수 있는지에 초점을 맞춘다. 고객이 관심 있는 것은 동작하는 시스템이지 중간 산출물이 아니다.

 

스프린트 계획 수립 절차

1. 제품 백로그 정제(refinement) 미팅
   고객과 제품 책임자가 중심이 되어 개발팀과 함께 새롭게 도출한 요구사항과 이전 스프린트에서 완료하지 못한 스토리 등을 종합하여 스토리들을 추가/분할/병합/제거하고 우선순위대로 정렬한다.
2. 스프린트 목표와 범위 설정
   제품 책임자는 제품 백로그를 바탕으로 해당 스프린트에서 개발하려는 업무 목표와 스토리들을 개발팀에 제시한다(e.g. 도서 검색과 주문 기능 개발 희망). 개발팀은 해당 스프린트 기간동안 완료할 수 있는 스토리들을 제품 백로그 우선순위에 따라서 가져온다. 서로 이견이 발생할 수 있기 때문에 충분히 토론한다.
3. 스프린트 백로그 도출
   개발팀은 스토리를 구현하는 상세 작업들을 도출한다. 스프린트 백로그는 제품 백로그와 다르게 개발팀이 실제 수행하는 개발 용어로 작성한다. 백로그에는 개발팀이 수행하는 모든 작업을 도출해야 한다(코드 리뷰, 업무 회의, 교육, 세미나 등).
4. 평균 투입 공수 추정
   개발팀이 공동으로 개발 규모와 공수를 추정한다. 이로써 팀의 집단 지성을 활용할 수 있고, 팀원이 업무를 전체적으로 이해할 수 있게 해준다.
5. 작업 담당자 할당
   팀원 스스로가 자신이 잘할 수 있는 업무를 선택하는 것이 좋다. 
6. 스프린트 목표 업무량 결정
   리더는 업무량이 적절하게 부과되었는지 점검한다. 여기서, 자기가 맡은 업무만 잘하면 된다고 생각해서는 안 된다. 스프린트 백로그는 팀의 공동 책임이다. 또한 설정한 목표 업무만 수행하면 된다고 생각해서도 안 된다. 적절한 업무량은 업무 몰입을 유도하기 위함이다. 빠르게 업무 목표를 달성한다면 다음 스프린트에서 수행 예정인 스토리를 가져와 작업한다.

스프린트 계획 예

 

평균 투입 공수 추정

애자일 개발에서는 소프트웨어 규모를 추정하기 위해 스토리 점수(story point)를 도입한다. 

스토리 점수는 상대적인 개념으로, 전체 스토리 중에서 투입 노력이 가장 적게 드는 스토리를 1점으로 잡는다. 이때 1점에 해당하는 평균 투입 공수(중간 역량의 사람이 구현시 소요되는 작업 일수)를 정해 놓으면 좋다. 애자일에서는 평균 투입 공수를 추정하기 위해 플래닝 포커 기법을 가장 많이 사용한다. 이 기법에선 질문 및 토론 후 각자 추정 값을 적은 카드를 제시한다. 가장 작은 추정 값과 가장 큰 추정 값을 낸 사람이 이유를 설명하고 토론한다. 차이가 줄어들 때까지 다시 새로운 추정 값을 제시한다. 2~3라운드를 했는데도 값 차이가 줄어들지 않는다면 건너뛰고 다른 항목부터 진행하는 것이 좋다.

 

프로젝트 킥오프

킥오프 미팅은 프로젝트 이해관계자를 모두 모아놓고 프로젝트의 목표와 진행 방법, 상호간의 책임과 역할 등을 공유하는 공식적인 활동이다. 킥오프 미팅은 프로젝트 시작을 알리는 공식 이벤트로, 하루 이상의 워크숍이 될 수도 있다. 보통 다음 활동을 포함한다.

• 프로젝트의 목적과 범위, 수행 전략, 릴리스 일정 소개
• 개발/관리 방법론과 수행 참여들 간의 책임과 역할
• 프로젝트의 이슈/리스크 도출, 해결 방안 탐색

 

애자일 프로젝트 성과 지표

분류	지표	측정 목적	지표 정의	측정 시기
일정	포인트 진척률 (%)	일정 시점에서 프로젝트가 실제 달성한 실적을 파악한다.	완료 포인트 / 전체 포인트	매주 또는 스프린트 단위
	백로그 진척률 (%)		완료 백로그 / 전체 백로그	매주 또는 스프린트 단위
	번다운 차트	단위 기간 동안에 남은 작업량을 파악한다.	시간 경과에 따른 남은 작업량을 그래프로 표시한 도표 - 스프린트 번다운 차트 - 릴리스 번다운 차트	매일 또는 스프린트 단위
	번업 차트	단위 기간 동안에 남은 작업량을 파악한다.	시간 경과에 따른 증가한 작업량을 그래프로 표시한 도표 - 스프린트 번업 차트 - 릴리스 번업 차트	매일 또는 스프린트 단위
생산성	속도 velocity	단위 가간 동안에 완료된 팀의 생산성을 파악한다.	스프린트 기간에 수행된 제품 백로그들의 스토리 포인트 합	스프린트 단위
팀워크	팀 사기 team morale	개발팀의 사기를 파악한다.	팀의 사기와 협업 수준의 설문 측정	월간
품질	결함 발생률	시스템의 품질 상태를 파악한다.	결함 발견 건수	월간

 

데일리 스탠드업 미팅

데일리 스탠드업 미팅은 매일 팀원이 스프린트 진행 상황판 앞에 모여서 15~20분간 진행 상황을 공유하고 업무 조율과 협력을 수행하는 활동이다. 이 때 팀원은 각자 다음 네 가지 사항을 이야기한다.

• 어제 내가 한 일
• 오늘 내가 할 일
• 업무 진행 중 발생한 장애 요인
• 도움이 필요한 사항

데일리 스탠드업 미팅은 업무를 보고하는 미팅이 아니다. 팀원끼리 업무 진행 상황을 공유하고 업무 협력을 촉진하려는 목적에서 수행한다. 이 미팅에서는 간단한 이슈 정도만을 이야기하며 이슈 해결 토론은 별도 미팅으로 진행한다. 미팅 시간이 15~20분을 넘기지 않도록 각자 2분 이내로 말하며, 리더가 중간에 개입하여 발언 시간을 조정해주어야 한다.