4 Agile

안녕하세요. 이 글은 소프트웨어공학개론 내용 정리 카테고리의 네 번째 글입니다. 다른 내용도 확인하고 싶다면 introduction page를 확인해주세요.

Agile은 현업에서도 각광 받고 있는 방식 중 하나이고 이 때문에 기술 면접에서도 자주 등장하는 주제입니다.

Agile은 변화가 자주 일어나는 상황에서 빠른 delivery가 중요해졌기 때문에 등장했다고 볼 수 있습니다. 또한 고객의 요구 사항을 빠르게 수용 가능하다는 강점이 있습니다.

Agile의 특징을 요약하자면,

• focus on the code rather than design
  디자인에 시간을 할애하기 보다는 동작하는 코드를 작성하는 것이 중요함
• based on iterative
  빠른 delivery를 전제로 하기 때문에 iterative 방식 사용
• individual, interaction than process, tool
  프로젝트 팀 전체가 사용하는 process, tool을 정하기 보다는 개발자 개인이 선호하는 방식 사용
• working SW than document
  document보다는 SW가 중요
  이로 인해 maintenance가 낮다는 비판도 존재함. Agile 옹호자들은 SW와 버전이 맞지 않는 문서를 작성하는데 시간을 소비하는 것이 불필요하다고 간주, system evolution 시 기존 개발 팀이 해체 된다면 효율적인 변경이 어려운 단점 존재
• customer collaboration than negotiate contract
  소비자가 개발 팀에 포함되어 즉각적으로 요구 사항, 피드백 진행, 계약 내용을 변경하는 것보다 customer와 즉각적으로 의견을 교환하여 모호함을 없애는 것에 초점, develop 중 customer와의 합의를 통해 output이 변경 됨.
  그러나 이로 인해 계약을 문서화하기 힘든 단점이 있고 이해당사자마다 성공의 기준이 다르기 때문에 프로젝트의 성공 여부를 판단하기도 어려움. 또한 개발 팀에 포함된 소비자가 소비자 단체를 대표하는 소비자인지에 대한 판단도 어려움.
• respond to change than following plan
  계획을 고수하기 보다는 변화 수용

Principle

앞서 다룬 Agile의 특징과 거의 유사하다.

• customer involved
• incremental delivery
• people not process
• embrace change
• maintain simplicity by refactoring
  문서 작업을 최소화하기 때문에 코드를 보고도 프로그램을 이해하기 쉽도록 다듬어야 함

Application

• small, medium size product development
  문서 작업을 최소화하기 때문에 대규모 프로젝트에 사용하기에는 한계 존재(유지 보수의 어려움 등)
• not external rule, regulation
  문서화, 디자인 등을 최소화로 진행하기 때문에 외부 규제, 제약 사항이 많은 상황에서는 이를 충분히 고려하지 못할 수 있음
• small, tightly-integrated team
  팀 내에서 소통이 빠르게 되어야 하기 때문에 소규모, 가능하다면 같은 사무실 내 팀에서 진행되는 프로젝트 사용하기 적합

단점 및 한계

• customer의 협조
  현실적으로 소비자가 개발팀 내에 상주하는 것이 어려울 뿐 아니라 이에 대한 반발이 존재할 수 있음
• 적절하지 않은 팀 구성
  팀원의 자유도를 존중하기 때문에 각 팀원의 능력이 뛰어나야 함
• 이해당사자 간의 우선순위 충돌
  우선순위 별로 iteration에 따라 개발이 진행되는데 이해당사자의 우선 순위가 서로 다를 경우 우선순위 조율이 힘들 수 있음
• simplicity 유지 위한 추가 작업 필요
  simplicity를 위해 refactoring(변수 이름 체계적으로 정하기, 클래스의 서브 클래스 최대 6개로 제한 등)을 진행하는 추가 작업에 시간과 노력이 소요됨
• contract 작성
  성공의 기준이 이해당사자마다 다르고 iterative하게 develop & deliver되기 때문에 계약서를 작성하기도 힘들고 제대로 이행되었는지 파악하기도 힘듦

Plan Driven vs Agile

plan driven	agile
detailed specification, design	increment, rapid feedback
analysis before implementation	implementation first
distributed, outsourced team	small, co-located team
cultural & organizational issue, external regulation 많을 때	적을 때
develop & output 분리	specification, design, implementation, testing inter-leaved

Extreme Programming(XP)

• Agile 방법 중 가장 많이 사용되는 방법으로 새로운 버전이 하루에도 여러 개 나오는 특징이 있다.
• 2주마다 customer에게 새로운 version deliver
  iterative develop & delivery 방식 사용

• 모든 build에 대해 test 진행 by TDD

  ### TDD

  • 테스트를 먼저 개발 후 실제 동작 프로그램을 작성하는 TDD 방식을 통해 모든 build에 대해 테스트를 자동적으로 진행함(automated unit test, regression test)
  • 테스트 데이터보다는 program으로 테스트 진행
  • 개발자가 테스트 기피, incremental write이 어려운 경우 존재, test complete 했는지 파악하기 힘들다는 단점이 존재함
• 개발자의 full time engagement
  다른 프로젝트와 병행하는 것이 아닌 XP 사용 프로젝트에만 전적으로 참여
• pair programming & collective ownership
  2명이 한 팀을 이뤄 한 명은 코드를 작성하고 한 명은 옆에서 지켜보는 pair programming을 통해 즉시 informal review를 진행할 수 있음, 돌아가며 코드의 여러 부분을 작성함으로써 코드 전체에 대해 책임감을 느끼는 collective ownership 방식 사용, 한 명의 개발자가 그만두더라도 모두 그 부분을 알고 있기 때문에 문제가 발생하지 않음
• support change
• maintain simplicity
  refactoring을 통해 readability, reusability 향상, document 수 줄임
• continuous integration
  component가 완성되자마자 합치고 그에 대한 test도 진행, 우선순위가 높은 부분이 먼저 개발됨으로써 그 부분에 대해서는 test가 여러 번 진행되므로 customer의 신뢰도가 향상됨
• sustainable pace
  적절한 pace 조절로 너무 루즈해지지 않도록 조절
• on-site customer
• requirement scenario
  story card를 이용함으로써 requirement를 얻어내고 분석함, 개발자는 이를 user story를 task 단위로 쪼개 scenario로 만듦

SCRUM

• Agile의 또 다른 방식 중 하나로 가시성이 좋고 팀 내 소통이 원활히 되며 개발자와 소비자가 프로젝트가 성공할 거라는 확신을 갖는다.
• 3 phase로 이뤄졌다.
• outline planning → sprint 반복 [access → select → develop → review] → closure
  • outline planning: general objective, design SW architecture
  • sprint: 실제 개발
  • closure: user manual과 같은 문서 작성
• 소규모 develop team: 7명 이하
• potentially shippable product: incremental develop을 할 때 언제든지 deliver 될 수 있는 완성된 상태로 제품을 만들어 version을 만드는 것이 목표
• product backlog: to do list로 다음 sprint 때 해결해야 할 일
• product owner: customer 뿐 아니라 project manager도 가능
• SCRUM: 매일 진행되는 회의
• SCRUM master: 외부와 팀을 소통하도록 해주는 역할로 팀은 개발하는 단계에서는 다른 것을 신경 쓰지 않고 개발에만 집중하고 master를 통해 소통함
• sprint: 반복되는 주기로 주로 2 ~ 4 주 단위
• review work to be done → select item & plan sprint → sprint → review sprint
  • product backlog를 review work to be done, select item 단계에서 참고
  • sprint backlog가 plan sprint에서 생성되어 sprint 동안 참고 및 수정됨
  • sprint의 결과는 potentially shippable SW

Scale up & Scale out

Agile은 주로 소규모 프로젝트에 작은 팀으로 진행이 된다. 이를 대규모 프로젝트, 대규모 팀에 사용하기 위해 agile 방식을 수정하기도 한다.

이 글은 공부한 내용을 정리한 글으로 오류가 존재할 수 있습니다. 오류를 발견하신다면 댓글로 알려주시길 바랍니다.