2장 애자일 설명

 

워터폴vs 애자일

워터폴

• 폭포수 모델은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌다.

워터폴이란?

 

요구사항 수집과 분석

• 프로젝트에 사용될 기능적, 시스템적 또는 기술적 사양 정보를 클라이언트와 주요 이해관계자로부터 수집한다.

설계

• 사용자 경험 전문가는 고객 제품팀 및 기타 주요 이해관계자와 함께 제품의 모양새와 여타 요소들을 결정한다.

구현

테스트

• 성능, 시스템 및 사용자 승인 테스팅을 수행하여 제품이 요구사항을 충족하는지 확인한다.
• 만약 결함이나 버그가 발견되면 제품이 전달되기 전에 해결된다.

프로젝트 최종 결과물 전달

• 프로젝트를 착수할 때 확정했던 사양을 제품이 충족하면 클라이언트에게 전달한다.

유지보수

• 클라이언트는 제품을 전달받은 후 추가적인 스코프 변경을 요청할 수 있다. 프로젝트 비용과 시간은 추가될 수 있다.

장점 및 단점

장점

1. 역사가 오래된 만큼 많은 사람들이 사용하고 단점 보완에 대한 예시들이 풍부하다.
2. 수직적인 방법론이므로 각각의 과정에 대한 이해가 용이하다.
3. 결과물에 대한 관리가 편하다.

단점

1. 각 단계별 수직적인 관계를 가지므로 각 단계를 병행할 수가 없다.
2. 단계별 발생한 오류들에 대한 즉각적인 피드백을 하기가 어렵다. (결과물을 바로 받을 수 없기 때문)
3. 개발이 완료되기 전까지 사용자(고객)의 의견을 100% 담아내기 힘들다
4. → 완료 후 고객의 생각과 다를 수 있다.

애자일

👉 왜 애자일?

• 워터폴 방식의 요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하는 경우가 거의 없음
  • 프로젝트 전체를 대상을 플래닝 → 프로젝트 전체에 대한 기획이 완료된 수 개발에 들어가는 등의 진행방식
• 개발 단계에서 개발을 하더라도 그것도 역시 예측할 수 없는 이슈들이 터져나온다는 점
• 이슈들이 처리되지 않고 엉킨채로 진행될 때의 문제점
  • 코드의 품질 하락
  • 요구사항 충족x의 상태의 결과물로 인한 불만족
  • 늦춰진 시간으로 인한 종료 예측 정확도 하락
  ⇒ 모두가 힘들어짐

 

• agile : 1. 날렵한, 민첩한 2. (생각이)재빠른, 기민한
• 짧은 주기의 개발단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식
• 애자일의 핵심은 협력과 피드백(협력과 피드백을 자주, 빨리)
• 애자일은 방법론은 아니다. 사상 또는 철학 일뿐
  • 계승한 사상 : 스크럼, 칸반 등의 방법론
  • 애자일의 핵심 → 유연한 일의 진행+변화의 대응
  • 소프트웨어 개발에 필요한 작업을 알려주는 일련의 규정이 아님

애자일 4대 선언 및 12가지 원칙

• 2001년 2월 11일에서 13일까지 유타의워새치산맥에 있는 스노우버드 스키 리조트 라운지에서 소프트웨어 업계를 주도하는 리더들이 애자일 소프트웨어 개발을 위한 선언을 다음과 같이 공표하였다.
• 4대 선언
  1. 공정과 도구보다 개인과 상호작용을
  2. 포괄적인 문서보다 작동하는 소프트웨어를
  3. 계약 협상보다 고객과의 협력을
  4. → 급여를 받고 하며 계약 협상시 리스크를 줄이자.
  5. 계획을 따르기 보다 변화에 대응하기를
  6. → master plan <delay 에 유연한 대응
  가치있게 여긴다
• 👉 우리는 소프트웨어를 개발하고 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
• 12가지 원칙
• 👉 1.가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 최고 우선순위로 한다.
• 2. 개발 작업 후반부일지라도 요구사항 변경을 기꺼이 수용한다. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
• 3. 2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다
• 4. 프로젝트 전반에 걸쳐 비즈니스 담당자들과 개발자들이 매일 함께 작업해야 한다.
• 5. 동기가 부여된 개인들을 중심으로 프로젝트를 구성한다. 구성원들이 필요로 하는 환경과 자원을 제공하고, 담당 업무를 완수할 것임을 신뢰한다.
• 6. 개발팀에 그리고 팀 내부에서 가장 효과적, 효율적으로 정보를 전달하는 방법은 대면 대화이다.
• 7. 작동하는 소프트웨어가 진처의 주된 적도이다.
• 8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 스폰서와 개발자, 사용자들이 일정한 속도를 계속 유지할 수 있어야 한다.
• 9. 기술적 탁월성과 좋은 설계에 대한 지속적인 관심으로 기민함을 향상시킨다.
• 10. 단순성 - 아직 하지 않은 작업량을 최대한 세분화하는 기술 -은 필수적이다.
• 11. 최고의 아키텍저, 요구사항 및 설계는 자율구성팀에서 비롯된다.
• 12. 팀은 정기적으로 더 효과적인 방법을 찾아서 반영한 다음, 그에 따라 업무 활동을 조율하고 조정한다.

애자일 마인드 셋

• 애자일은 사고방식, 신념, 원칙 및 사고 방식의 집합
• 마인드셋
  • 2000년 대 초반 캐롤 드웩은 고장 마인드셋과 성장 마인드셋의 개념을 대중화
  • 고정 마인드셋
    • 사람들은 자신의 특성이 변하지 않는 고정된 특성
    • “아무리 노력한다 해도 자질을 바꿀 수 없다”
    • 도전과 실패를 두려워함
  • 성장 마인드셋
    • 사람들은 학습과 지능이 시간과 경험에 따라 성장할 수 있다는 근본적인 믿은
    • “누구나 자신의 재능을 발전시킬 수 있다.”
    • 도전이 능력을 키워 준다고 믿으면 사람들은 위험을 무릅쓰면서 도전에 나서게 됨
• 애자일이란 업무방식을 개선이 아니라 사고방식을 변경하는 것

애자일 개발 방법론

스크럼

스크럼은 팀이 작업을 관리하는 데 사용하는 프레임워크

스크럼은 Agile의 원칙을 아티팩트, 사례 및 역할의 구체적인 집합으로 구현

 

칸반

칠판에 진행상태나 사람 업무 종류 등에 따라 칸을 나누고 각 칸에 이슈 내용이 적힌 포스트잇을 붙여 현재 업무 현황을 한눈에 파악하는 시스템

 

린(Lean) 스타트업

제품이나 시장을 발달시키기 위해 기업가들이 사용하는 프로세스 모음 중 하나로서 애자일 소프트웨어 개발과 고객 개발, 그리고 기존의 소프트웨어 플랫폼(주로 오픈소스) 등을 활용

“최소한의 기능만을 가진 제품을 신속하게 출시하고 고객의 반응을 관찰함으로써 문제점을 개선하거나 혹은 비즈니스의 방향을 과감히 전환하여 보다 완벽한 제품과 비즈니스 모델을 구축하는 것이다.”

애자일과 워터폴 비교

구분	애자일	워터폴
장점	- 개발과정이 빠르면서 유연하다 - 짧고 반복적인 스프린트로 구성돼 있으면서 품질에 초점을 맞추기 때문에 워터폴 방법론보다 빠르게 결함을 식별 및 수정할 수 있다. - 여러 소규모 팀들이 개발 과정상의 여러과제를 각각 할당 받아 처리할 수 있다. - 짧은 반복 과정을 거치므로 필요시 개발과정 중에 신속하게 제품 변경을 할 수 있다.	- 개발 주기가 애자일보다 형식적 연속적이긴 하지만 프로세스가 길고 순서가 잡혀 있기 때문에 팀의 규모에 상관없이 따르기가 쉽다. - 개발 주기가 이미 정해져 있어서 팀이 새로운 프로젝트를 안정적으로 시작할 수 있다. - 프로젝트 요구사항이 확정돼 있기 때문에 프로젝트를 싱핼하기가 수월하며 개발목표를 자주 변경하지 않아도 된다. - 프로젝트 전 과정에 필요한 예산과 자원이 초기에 확정되기 때문에 예상 결과와 리스크를 통제하기가 훨씬 쉽다.
단점	- 스프린트에 대한 경험이 있으면서 빠른 반복 작업에 익숙한 스크럼 마스터가 필요하다 - 고객이 수많은 변경사항을 검토해야 하는 번거로움이 발생할 수 있따. - 팀원이 다양한 시간대의 지역에 흩어져 있음에도 잘 조직되지 않거나 자립성이 없는 경우, 애자일 방법론을 채택하면 문제가 발생할 수 있다.	- 개발이 순차적으로 진행되기 때문에 앞단계가 완성돼야 다음 단계로 너어갈 수 있다. 이로 인해 개발 속도가 느리며 유연성이 떨어진다. - 테스팅 단계에 이르러서야 이슈가 발견되고는 한다. - 개발 요구사항이 프로젝트 초기에 정해지기 때문에 범위 변경이 자유롭지 못하다.
적합한 조직	- 고성능 소프트웨어 개발 팀 중에서도 특히 소프트웨어 개발 분야 팀 - 고품질의 결과물과 지속적인 개선에 초점을 맞춘 조직, 특히 이들이 생각하는 가치 제안이나 경쟁 차별화 요소에 퀄리티가 포함되는 경우 - IBM, 시스코, AT&T, 마이크로소프트처럼 크고 복잡한 회사들이 프로세스를 간소화 함으로써 변화에 더욱 신속하게 대응하고자 할 때 - 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀 - 프로젝트가 완벽하게 수행될 떄 까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 팀	- 높은 예측 가능성과 순차적인 프로젝트 타임라인 사전 확정 예산이 필요한 팀 - 프로젝트 팀의 경험이 적은 경우 - 개발상의 변경이나 리스크에 덜 민감한 기업 - 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 - 요구사항이 간단한 프로젝트 - 타임라인이 긴 프로젝트

 

 

스크럼 VS 칸반 with Agile

스크럼

• 미식축구 포지션 이름에서 유래
• 프로세스 도구 중 하나로 역할을 규정하며 기간이 고정된 이터레이션을 규정하여 경험적으로 프로젝트를 관리해 나가는 방법

👉 프로젝트 관리를 위한 상호 점진적 개발 방법론이며 애자일 소프트웨어 공학 중의 하나이다. 스크럼은 소프트웨어 개발 프로젝트를 위하여 고안되었지만 소프트웨어 유지보수 팀이나 일반적은 프로젝트/프로그램 관리에서도 적용될 수 있습니다.

 

스프럼을 하는 이유

• 계획한 대로 일이 진행되지 않아서
  • 스프린트 마다 계획과 프로세스를 수정하며 개선
• 요구사항이 수시로 바뀜
  • 스프린트 백로그/제품 시연을 통해 백로그를 관리하고 한 회의 스프린트 동안에는 백로그 추가를 허용하지 않음
• 자신의 능력으로 할 수 없는 일들에 막혀 있음
  • 계획 회의 /일일 미팅/회고 회의를 통해 팀원들간의 협력을 도모

스크럼 진행과정

1. 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다.
2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다. 조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다.
3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.
4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
5. 실행가능한 제품을 개발한다.
6. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해 한다.
7. 제품의 학습과 이해가 끝나면, 스프린트 회고를 통해 팀의 개발 프로세스에 대한 개선의 시간을 갖는다.
8. 다음 스프린트 시작한다. 스프린트는 PO가 출시할 준비가 되었다고 판단할[대까지 계속된다

스크럼 팀 구성

• Product Owner
  • 제품 책임자(프로젝트리더, PL 등이 될 수 있음)로서 제품 백로그를 정의하여 우선순위를 정하는 역할이다.
• Scrum Master
  • 스크럼 관리자 및 코치로서 일반적인 관리를 수행하는 프로젝트 관리자들과는 달리 팀원을 코칭하고 프로젝트의 문제 상황을 해결하는 역할을 하며, 제품 책임자가 독단적으로 목표를 결정하지 않게 고객과 관리자 및 팀원들이 모여서 목표를 정하도록 하는 역할이다.
• Development Team
  • 개발팀은 팀원들이 주도적으로 스프린트 목표를 달성하기 위한 작업을 정해 나가도록 하는 역할이다. 물론 작업을 정하고 할당하는데는 고객이나 제품 책임자와는 상관없이 팀원 자율로 진행된다. 이와 같은 자율적인 행위를 통해서 팀원들은 의사를 활발하게 주고 받게 되고 끈끈한 협업체계를 가지게 된다.

3가지 산출물

1. 제품 백로그
   • 제품 기능의 우선순위를 정리한 목록
2. 스프린트 백로그
   • 하나의 스프린트 동안 개발할 목록(사용자 스토리와 이를 완료하기 위한 작업을 테스크로 정의)
3. 소멸차트
   • 개발을 완료하기까지 남은 작업량을 보여주는 그래프

스프린트

• 스크럼에서 스프린트란 반복적인 개발 주기를 뜻함
• 한 스프린트 내에서는 의미 있느 ㄴ산출물이 나오기 위한 목표를 설정
• 정해진 목표는 그 누구도 팀원들의 동의 없이 바꿀 수 없음

스크럼을 위한 4가지 미팅

1. 스프린트 계획 회의
   • 스프린트가 끝나고 다음 스프린트의 시작 전
   • 스프린트 목표와 스프린트 백로그를 계획하는 회의
   • 세부적으로 어떤 것을 구현해야 하는 지에 대한 세부 작업 항목, 작업자, 예상 작업 시간 등을 수립
2. 일일 스크럼 회의
   • 매일 정해진 시간에 일반적으로 15분
   • 일반적인 일일 스크럼과 미팅 시간을 획기적으로 줄여주는 일일 스크럼 방법
     • 매일 정해진 시간에 일어서서 한다.
     • 모든 팀원이 참석한다.
     • 스프린트 현황판에 대한 업데이트를 진행한다.
     • 한 사람씩 어제 한 일과 오늘 할 일을 이야기 하며 어려운 점이 있다면 이야기한다.
     • 되도록 짧게 한다.
3. 스프린트 검토 회의
   • 매 회 스프린트 종료 전
   • 고객이 요구했던 사항에 얼마나 부합하는지 참석자들 앞에서 시연
   • 개선할 점 등에 관해 피드백
4. 스프린트 회고 회의
   • 매 회 스프린트 종료 후 다음 스프린트 계획 회의전
   • 그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아 보고 개선점을 없는지 팀이 정한 규칙이나 표준을 잘 준수 했는지 검토
   • 단점보다는 강점을 찾아 극대화 시키는데 주안점을 둠
   • 문제점을 확인하고 기록하는 정도로만 진행함
   • 문제점의 해결 방안을 찾는 회의가 아님

칸반

• 일본어로 간판이라는 뜩이 어원으로 눈에 보이는 기록을 통해 제품을 개발하는 방법
  • 도요타 생산 시스템에 있는 칸반이라는 카드에서 사용한 것
• Scrum에 비해 Kanban은 조금 더 규범적이지 않은 개발 방법론
• Agile 개발 프로세스 전반에 걸친 적시 개발을 지원하는 방법론
• 특징
  • 작업 지시서 : 생산 시스템에서 작업 지기서에 해당
  • 애자일병행 : 매우 적은 규칙을 갖고 있으므로 스크럼 등과 같이 사용
• 3가지 규칙
  1. Workflow 가시화
     • 일을 작게 분할, 카드에 기록하여 보드에 게시
     • 단계를 알 수 있도록 Flow별 단계 기록
  2. WIP 제한
     • Workflow 상에서 동시에 진행될 수 있는 항목을 제한한다
  3. 리드 타임 측정
     • 한 항목을 완료하는데 걸리는 평균 시간 타임을 산정한다.
     • 예측 가능하고 소요시간을 최소화하기 위해서 프로세스를 최적화 한다.

칸반의 개념도

• Workflow 상의 공정을 가시화하여 진행사항을 관리

칸반의 구성요소

• Kanban Board
  • 프로세스를 기재한 board와 스토리 카드를 이용하여 업무 흐름을 제어한다
  • 산출물 : 스토리카드
• Process
  • 실제 업무가 이루어지는 단계 및 업무 수행을 통한 산출물 작성
  • 산출물 : 업무성과
• Work Queue(대기 행렬)
  • 대기행렬, 개발 대기, 테스트 대기, 배포/릴리즈 대기과정
  • 산출물 : Work Queue List
• 총 주기 시간
  • 총 작업의 수행시간, 개별 업무의 Cycle Time의 합으로 구성된다.
  • 산출물 : Total Cycle Time
• 칸만 시스템은 애자일의 대표적인 스크럼 기법과 함께 사용될 수 있음
• 칸반의 단점을 스크럼으로 변경하는 것보다는 애자일의 단점을 칸반 기법으로 극복하는 것이 효과적

스크럼과 칸반 비교

• 역할을 지정하지 않는다.
  • 스크럼은 일반적으로 제품책임자/개발팀/스크럼 마스터 로 나뉘는데 반해 간반은 이를 자유롭게 지정할 수 있다. (물론 스크럼도 유연하게 변경 가능하다)
• 기간이 고정된 이터레이션을 사용하지 않는다.
  • 스크럼은 스프린트를 통하여 계획/개선/릴리즈 와 같은 단계를 밟아가며 경험적으로 개선해 나가지만, 간반의 경우에는 이를 고정하지 않는다. 필요하면 스프린트의 이터레이션을 사용해도 좋고, 필요할 때마다 릴리즈하도록 지정할 수 있다.
• 워크플로우 상태에 기 반하여 WIP(work in process)를 제한한다.
  • 앞서 말했듯이 스프린트는 경험에 기반하여 매 스프린트마다 계획하는 일의 양을 조정하며 속도를 측정하지만, 간반은 이터레이션을 사용하지 않기 때문에 워크플로우 상태에 WIP제한을 지정하여 일의 속도를 조절 및 파악한다. (보드 그림의 상태 이름 아래에 있는 숫자가 WIP를 의미하며 이를 넘는 아이템이 상태로 옮겨질 수 없다는 것을 의미한다)
• 이터레이션 내에서 변경이 가능하다.
  • 스크럼은 변경이 발생할 경우 현재 스프린트의 아이템을 변경하지 않고 다음 스프린트 계획에 포함시기는 것에 비해 간반은 백로그에 언제든지 아이템을 주가할 수 있다. 다만 이를 다음 상태로 전환할 때 앞서 말했던 WIP제한을 통해 상태별로 할 수 있는 아이템을 제한시켜 우선순위별로 저리될 수 있도록 할 것이다.
• 보드는 초기화되지 않는다.
  • 스크럼은 스프린트마다 새롭게 보드를 구성하며 시작 시에 할일에 대부분, 끝날 때 완료에 대부분 아이템이 위치하는 반면 간반은 그럴 필요가 없다. 따라서 간반은 항상 할일/진행 중/완료 에 자유롭게 아이템이 위치하고 있다.
•  

비교 항목	스크럼	칸반
기간	기간이 고정된! 이터레이션을 규정한다.	기간이 고정된 이터레이션은 선택사항.
약속	팀이 이터레이션에서 할 일의 양을 결정, 약속한다.	약속은 선택사항이다
지표	계획 하기와 공정 개선에 속도 (velocity)를 기본 지표로 사용한다	리드 타임을 기본 지표로 사용한다.
팀	교차 기능 팀을 규정한다	교차 기능 팀은 선택사항, 전문가 팀도 허용한다.
아이템 크기	아이템들을 하 스프린트 안에 완료될 수 있을 정도의 크기로 잘게 쪼개야만 한다	아이템 크기를 특별히 규정하지 않는다.
차트	번 다운 차트를 규정한다.	차트 사용 규정 없다.
WIP	WIP 리 밋을 간접적으로 한다.(스프린트마다)	WIP 리밋을 직접적으로 한다.(작업 름 단계마다)
추정	추정을 하도록 규정한다.	추정은 선택
아이템 추가	이터레이션이 진행 중일때는 아이템 추가 불가.	수용 능력이 허용한다면 새로운 아이템을 추가할 수 있다.
보드 소유	스프린트 백로그는 특정 팀이 소유한다.	간반 보드는 다수의 팀이나 개인들 간에 공유하기도 한다.
역할	세가지 역할을 규정 (제품 책임자, 팀, 스크럼 마스터)	어떤 역할도 규정하지 않는다
보드 초기화	이터레이션마다 스크럼 보드 초기화	칸반 보드는 계속 유지
우선순위	제품 백로그에 우선순위를 정의할 것을 규정한다.	우선순위 정의하기는 선택 사항이다.
규칙	스크럼 마스터 -제품 책임자 -스크 러 티 -스프린트 계획미팅 이 01 스크 러 -스프린트 리뷰 -제품 백로그 -스프리트 BH로그 -소멸 사트	3개 -WorkFlow 시각화 -WIP 제한 -flow의 측정 및 최적화