#12 DevOps와 애자일 개발

애자일 개발
 - DevOps의 전신이 되는 개발 방법
 - 개발 방법의 개선 + 팀 구성의 변화 => 지속적 성과물 개선

애자일 개발 방법론
 - 계속적인 프로세스 확장 > 지속적 통합 방법 > 개발과 운영의 관계 개선 > DevOps의 시작

서비스 개발의 성공
 - 애자일 개발이 해결하고자 했던 과제 : 서비스 개발의 성공
 - 서비스 개발 성공의 의미
  : 요건이 정의된 사양 > 납기까지 완성
  : 모두 충족했으나 사업 실패

 - 폭포수 모델
  : 치밀한 시장조사 ~> 기획/요건 정의 ~> 난관 극복 ~> 납기 내 릴리즈
  : 개발 도중, 경쟁사의 유사한 서비스 등장 및 시장 선점
   > 시장 점유율 확보 실패 > 사업 실패로 이어짐

 - 단순히 계획대로 서비스를 릴리즈 하는 것 뿐만 아닌 비즈니스적 가치를 제공해야 서비스 개발 성공

사업의 실패 방지
 - 경쟁사의 릴리즈
  > 개발 중 제품의 기능 단순화 + 릴리즈 시점 앞당기기
  > 경쟁사의 서비스를 철저히 분석한 후, 대응할 수 있는 서비스 배포

 - 문제점
  > 서비스 개발 ~> 폭포수 모델의 경우 변화에 대응하기 어려움
  > 빠르게 변화하는 비즈니스 환경
   : 새로운 가치 창출
   : 개발 자체도 변화에 대응해야 함

 - 빠른 변화에 대응하는 개발 요구
  : 여러가지 개방 방법론들이 제안됨(스크럼, 익스트림 등)
  : 공통된 특징을 취합 => 애자일 소프트웨어 개발

애자일 개발
 - Agile : 빠름, 유연함
 - 애자일 개발
  : 빠름/유연함을 강조했던 다양한 개발 기법을 기원으로 함
  : 각 개발 방법의 엔지니어들이 모여, 공통되는 지식으로 재구성한 것

DevOps와 Agile 개발
 - Agile의 문제
  : 발생하는 운용 측면(비용 등)에 대한 과제가 남아있음 ~> DevOps라는 발상 태동
 - Agile 개발
  : "개발 공정 관련 기획 > 설계 > 개발 > 테스트 > 릴리즈" 의 반복
  : 반복 주기를 짧게 구분
   - 구분 마다 계획하고 구현한 성과물 > 릴리즈 : 민첩함
   - 피드백 > 다음 반복주기에 반영 : 유연함

  : 기획 ~> 릴리즈 까지 하나의 팀
   - 전체 개발 공정을 지속적으로 통합
   - 팀원 전원이 서비스나 상품에 대해 책임
    : 서로의 업무에 대한 이해가 필요
    : DevOps의 계기 발현 

Agile 개발의 진행
 - Keyword : Iteration(반복), User Story
 - Iteration
  : 1주 ~ 4주 단위의 짧은 서비스 개발 일정
  : 단계)
   1. 계획 단계
    > 기획 + 개발 + 운영 팀 구성원 모두 참여
    > 팀 차원의 Output 검토하고 토론 ~> 팀 구성원 모두가 Output에 대해 알게 해야 함
   2. 피드백 단계
    > 잘 된 것, 개선해야 할 것을 회고
    > 서로의 개선점을 찾아 추가 개선할 수 있게 정리

 - 팀에서의 역할에 한정하지 않음 > 팀원 전원이 충실한 업무 수행
  : 성과물의 운용에서 문제가 발생(혹은, 해결해야할 과제 발생)
   > 개발 팀 뿐만 아니라, 기획 ~ 릴리즈에 참여한 모든 구성원이 무슨 일이 발생하고 진행되는지 이해할 수 있음
   > 자연스러운 협력 관계 도출
   > 피드백 전파 ~> 팀원 모두의 업무의 개선이 이루어질 것으로 기대 가능

 - User Story
  : Iteration 계획 중 "무엇을 달성하고 싶다" 라는 요구 사항(문장으로 표현)
  : ex) "사용자의 충성도 높이기" : 대략적 요구사항
         ~> 달성 방법 논의 > "로그인 할 때 마다 포인트 제공"
  : 광범위한 요구사항을 Epic이라 부름

 - Epic
  : 광범위한 요구사항
  : Epic을 세분화(breakdown) > user story
  : User Stroy 달성 ~> 개발 ~> Iteration 단계 구분 ~> 진행되는 Iteration 단계에 맞는 User Story 선택 및 개발

Agile 개발의 기원 : 방법론이 따로 정의된 것은 아님(기존의 것들이 Agile에 해당한다는 개념)
 - Scrum 개발
 - Extreme Programming(XP)
 - Feature Driven Development(FDD)

SCRUM 개발
 - 럭비의 scrum 에서 유래

Scrum 역할
  : Product Owner
   > 개발 상품에 대한 가치를 극대화할 책임
   > 사용자를 위한 Epic 발굴 > User Stroy의 Backlog(기능)의 우선 순위 제어
  : Developer
   > 상품에 구현되는 개별 기능을 개발
   > 3 ~ 9명 정도가 적정선 : 의사소통 비용이 들지 않는 인원 수의 기준(숫자는 중요하지 않음)
   > "자율적인 자기 조직" : 개별 기능 개발의 구체적인 작업 계획 및 관리는 스스로 진행
   > 각 계층의 전문성을 가진 구성원 : 개발 / 운영 / 기획 / 사업 등을 구분하지 않음
  : Scrum Master > Scrum 팀의 최고 책임자
   > Scrum 팀이 보다 좋은 팀이 되도록 하는 책임
   > 개선과 교육 실시
   > Product Owner에 대한 지원
   > Developer의 개발을 방해하는 요인 제거

Scrum 개발의 흐름
 - 릴리즈 계획 > 스프린트 계획 > 스프린트( = Agile의 Iteration) > 일간 스크럼(정보 공유) > 스프린트 리뷰 > 스프린트 회고

 - 릴리즈 계획
  > Product Owner 중심 : Product Backlog를 기반으로 우선순위 선정
  > User Story와 기능 목록은 구체적인 상태
    : Product Backlog는 확정 아님(수시로 변할 수 있음) > 비즈니스 상황, 사용자 변화, 개발자 피드백
  > 프로젝트의 로드 맵 상정(완성 X) : 스프린트 할 때마다 검토

 - 스프린트 계획
  > Product Backlog의 기능 개발을 실제 스프린트에 할당
  > 1회의 Sprint(2~4주)
   : Developer는 Sprint에 맞게 기능을 더욱 세분화
   : Developer에게 스프린트 분량을 할당
   : Backlog 기능 <=> 담당 Developer 연결 ~> Sprint Backlog 생성 : 정량적 평가 항목을 정하는 것이 좋음

 - 스프린트
  > 실제 성과물에 대한 개발 실시 
  > 개인 환경에서 개발(DevOps 적용)
   : DevOps 관련 도구 활용 ~> 개발에 집중 가능한 환경 ~> 생산성의 향상을 위한 노력 중요
  > 스프린트 기간 [원칙] : 하나의 개발에 집중
   : 개발 내용 변경하지 않기(스프린트와 스프린트 사이에서 변경)
   : 스프린트 계획에서 결정한 내용과 다른 개발 하지 않기

 - 일간(데일리) 스크럼
  > 매일 짧은 회의 수행, 각 구성원은 다음의 내용 보고(15~30분)
   : 어제 한 일, 오늘 할 일, 진행에 방해가 되고 있는 것(Blocker) 등을 공유
  > Blocker에 대한 정보 공유 : Scrum Master는 Blocker의 해결에 협력 혹은 조언

 - 스프린트 리뷰
  > 결과물을 확인하는 회의 : "동작하는 것을 보여주는 것"
    : 스프린트 계획에서 정한 것이 수행되는 것이 요구
  > User Story에 관계된 이해 관계자(Stake Holder)가 참석 가능
   : 다양한 이해 관계자와 결과물을 보고, 의사소통에 대한 점검
   : 또 다른 아이디어 획득 > 다음 스프린트에 피드백

 - 스프린트 회고(Retrospective)
  > 검토 과정
    : 스프린트 완료 > 회고 / 검토 > 다음 스프린트 시작
  > 구성원 별 수행
   : 좋았던 것 / 나빴던 것 / 다음 Sprint에서 반드시 해야할 일 메모
   : 회고 시 발표 > 각 메모를 분류 > 팀에서 가장 중요하다고 생각되는 발표에 투표
   : 투표 후 Best 3~4 > 서로 칭찬
                Worst 3~4 > 구체적인 개선책 마련 
  > 구성원 모두가 참석 및 수행
   : 스프린트 계획의 정량 평가 항목 사용
   : 이 후 개발에서 관리할 수 있게 함

Agile 개발에서 중요한 문구 : "Do not just Do Agile, Be Agile"
  > Do not just Do Agile
   : 기술 / 노하우나 도구의 도입에 만족하지 말 것
   : "도구를 도입한 결과 어떤 효과를 얻고 싶은 것인가?"에 집중
  > Be Agile
   : "변화에 맞서 계속하는 것"

티켓 시스템(ticket System)
 - Red Mine, Trac, Bug Tracking System, Issue Tracking System ==> 애자일 개발의 User Story 관리