소프트웨어 공학 CH3. Agile Development

Agile Development

• 빠른 개발과 배포
• 비즈니스 요구에 빠른 대처
• Specification / Design / Implementation을 동시에
• 빠른 버전 업데이트
• 자동화 테스팅 툴
• 문서 최소화
• Output을 계획하는 Plan-Driven 방식과는 달리 개발 과정에서 Output이 달라질수 있다.

---

Agile method

• 문서화 보다는 코딩을 먼저
• 코딩과 실패와 성공의 반복
• 빠른 개발과 요구에 맞는 업데이트

-> 비용 절감

---

Agile 원칙

고객 참여 - Customer Involvement

• 개발과정에 고객이 참여, 요구사항 확인

증분 배포 - Incremental Delivery

• 고객의 요구를 나누어 개발

People not progress

• 개발자의 능력을 활용하되, 업무 방식에 관여하지 말것

Embrace Change

• 요구사항이 바뀔것을 감안하여 변화에 유연하게 구현할것

Maintain Simplicity

• 소프트웨어의 단순함에 초점
• 복잡한건 없애기 위해 노력할것

Applicability

• 큰 프로젝트에선 쓰기 힘들다.

---

Extreme Programming

Agile의 한 종류

1. 매일마다 새로운 버전의 프로그램이 빌드된다.
2. 2주마다 증분을 배포한다.
3. 모든 빌드는 테스트가 성공했을때만 통과된다.

요소

• Incremental planning
  • 요구사항/Story를 업무/Task 로 나누어 계획한다.

• Small releases
  • 작은 변경을 배포한다.

• Simple Design
  • 현재 목표에 딱 맞는 정도의 디자인을 한다.

• Test-First Development
  • 테스트의 통과를 매우 중요시
  • 테스트의 자동화가 중요하다.
  • 요구사항 통해 테스트할 항목을 정한다.

• Refactoring
  • 단순하고 보수 가능하게 코드를 재작성한다.

• Pair Programming
  • 둘이서 한명은 리뷰하고 한명은 코딩하기
  • 퇴사시 코드 정보 유실 방지
  • 문서화 없이 코드 내용 파악
• Collective ownership
  • 서로가 서로의 코드를 스스럼 없이 수정하기

중요한 부분

1. User story / 요구사항

• 유저 스토리 / 시나리오로 표현 -> Task로 세분화 한다.
• 비용 추산은 Task 기준
• 우선순위/일정 기반으로 다음 배포를 결정한다.

2. Refactoring / 소스코드 재작성

• 나중에 고치기 쉽게 미리 고쳐놓기
• 코드에 대한 이해도 상승

Refactor 예시

• 클래스 상속구조
• Identifier 이름 변경
• 파일나누기/모으기 , 라이브러리화

3. Test First Development

• 시나리오별 테스트
• 유저 참여 테스트
• 테스트 자동화/매 빌드마다 실행

POINT

• 구현 전에 요구사항을 바탕으로 테스트를 작성한다.
• 자동화 라이브러리 이용하기
• 새 기능을 추가한다면 새로운 test case가 필요해 진다.

문제점

• 프로그래머가 테스트 되는 사항만 구현할수도 있다.
• 복잡한 UI와 같이 테스트 케이스의 생성이 어려울수 있다.
• 테스트를 아무리 많이/잘해도 아예 무결하다 할수는 없다.

---

Agile management

일정과 비용관리

• 배포 시기 지키기
• 계획적 프로젝트 관리

Scrum

• 개발의 반복적 과정의 관리

• 스프린트 단위
  • < Initial Phase / 계획 -> Sprint code / 개발 -> Closure Phase / 종료 및 문서화 >

요소

• Potentially shippable product increment

  • 한번의 스프린트마다 배포될것

• Product backlog

  • 해야할 사항

• Product owner

  • backlog를 작성하는 개발자, 이를 사용하는 고객

• Scrum

  • 일일미팅
  • 진행상황 확인 및 우선순위 결정

• Scrum master

  • Scrum 주관하는 리드 개발자

• Sprint

  • 반복되는 개발단위
  • 1 Sprint에 1 Backlog 개발
  • 2~4주로 중 하나로 고정한다.

• Velocity

  • 1 Sprint에 처리 가능한 backlog를 분석한다.

    

• 외부 방해요인으로부터 개발팀 방어

• 불명확한 요구사항이 개발진행을 늦추지 않음

• 고객과 개발자간 상호 신뢰

---

Scail / Agile

• 큰 프로젝트에 Agile 방법론을 도입하기 위해선 여러 팀으로 나누어 분업을 해야 한다.

Agile 에서 프로젝트의 크기를 키울때 중요한 점

• 유연한 계획
• 그래도 최대한 자주 release
• CI
• Test-Driven Development

• 큰 시스템을 작게 나누어 Agile
• 팀이 많아져 커뮤니케이션이 많아진다.

어려움

• 완벽하게 큰 시스템을 증분으로 나눌수는 없다.
• 1 프로젝트가 1시스템이 아니루도 있다.
• 팀간 소통이 중요하다.

Agile의 문제점

• 대형 회사에선 쓰기 힘듦
• 멤버 하나 하나가 직접 만나기 어려운 경우 힘들다

---

Maintenance

• 최소한의 문서화
  • 코드를 통해 구현을 이해해야 한다.
• 고객의 요구 변경 반영

• 개발팀 != 유지보수팀일때 문제가 발생한다.

---

Agile? Plan Driver?

plan driven

• 디테일 설계 / 디자인이 중요
• 작은 에러가 큰 문제를 일으킬 때

agile

• 증분 배포 및 빠른 피드백이 필요할때

---