My Profile Photo

DongChanS's blog

수학과 학생의 개발일지

애자일 방법론 (1) - 소개, XP

1) 서론

마이크로서비스

  • 기존에는 서비스들이 통합되어 있으면, 일부분을 수정하기 위해서 모든 서비스를 kill -> restart해야하므로 매우 불편했음.
  • 독립적인 마이크로서비스별로 따로 개발하고 운영하는 방식을 추구함

=> 그 서비스를 운영하는 각 팀이 애자일 방법론을 따름.

11

2) 애자일

2-1. 애자일이란?

애자일은 개발하는 방법보다는 일하는 방법이라고 생각하면 됨!

  1. 비전과 전체 기간을 정의, 변화하는 시장에 대응할 준비

    • 언제든지 개발 범위는 변경될 수 있음.

  2. 시장의 변화를 반영하여 지속적으로 프로젝트 계획

  3. 결과물을 지속적으로 시장에 전달

  4. 작은 프로젝트(스프린트)의 반복

    • 프로젝트가 끝나면 정리하는 시간도 필요함

      ex) Tdd, 리팩토링, 디자인패턴

      • 단위테스트, 통합테스트, 부하테스트??

애자일 방법론에도 여러가지가 있는데, 대표적으로 스크럼이나 XP가 있습니다.

2-2. 애자일에 꼭 필요한 것

  • Daily standup

    매일마다

    • 프로젝트 진행상황을 보고 (Trello)
    • Continuous integration
  • Sprint / iteration planning

    다소 가까운 계획을 구체적으로 작성하기

  • Retrospectives

    상황에 맞춰서 지속적으로 범위, 요구사항을 개선

  • Sprint / iteration review

    개선한 제품을 지속적으로 출시

  • Short iterations

    빠르게 출시하여 고객의 피드백을 받기.

12

2-3. 애자일을 하면 안되는 경우

기본적으로 애자일을 하기 위해서는,

  • 자원과 개발일정은 고정될 수 밖에 없으나,

  • 개발범위와 요구사항은 변경될 수 있어야 합니다.

    => 만약 그렇지 못한 상황이라면 (ex, 고객사의 갑질) 애자일은 의미가 없음.

    (Collaboration with Stakeholders, Business Understanding)

2-4. 주의사항

  1. 기본적으로 애자일 방법론에서는,

    개발 아키텍쳐가 변경될 수 있으므로 최대한 단순하게 만들어야 한다.

    하지만, 단순하게 만든다고 해서 아예 아키텍쳐들을 기록하지 않으면 안됩니다.

    => DB, 시스템 아키텍쳐, 일정관리같은 증거물을 반드시 기록해야함.

  2. 모든 요구사항(Feature creep)을 받아들여서는 안된다.

    팀의 누군가가 고객의 요구사항들을 관리하고 피드백 할 수 있는 역할이 필요함.

  3. 전통적인 방식과 애자일을 혼합할 수도 있다!

    ex) Water-Agile-fall : 분석, 설계는 Waterfall 방식 & 개발만 애자일하게!

3) 애자일 방법론 : XP

XP : eXtreme Programming

이름그대로 굉장히 빡빡한 방법론이기때문에 전부 따르지는 않아도 된다.

  1. 아키텍쳐 스파이크
    • Planning game
      • 스토리 만들기 : 페르소나 이용
        • 페르소나 : 30대 남자 이런거보다는 실감나는 특징을 표현하는게 좋음.
      • 만든 스토리에서 우선순위를 정함
    • Simple design
  2. Release : 조금씩 배포하기
  3. Testing : 조금씩 테스트하기 (Testing Tool 이용하기 ex, Mocha)
    • 버그수정
    • 요구사항 수정
      • On-site customer
  4. 반복 : 스프린트 끝남
    • Pair programming
    • Collective ownership

13

comments powered by Disqus