[소프트웨어공학]Agile

ch 3_Agile

Agile Software Development

• 소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 waterfall 방법과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법
• 사양, 설계, 구현, 테스팅이 교차되고 개발 과정의 결과물은 소프트웨어 개발 과정에서 협상 과정을 거쳐 결정된다
• 디자인보다는 코드에 집중
• 계획 주도 개발: 소프트웨어 엔지니어링에 대한 계획 중심 접근 방식은
• 소프트웨어 개발에 대한 반복적인 접근 방식을 기반으로 함
• 변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적 개발 방법
• 작동하는 소프트웨어를 신속하게 제공하고 변화하는 요구 사항을 충족하여 신속하게 발전시키기 위함이다
• 기존의 개발 프로세스는 설계 기간이 길며 재작업 시 오버헤드가 크다
• 계획 중심의 Agile software development

애자일 방법의 목표

• 소프트웨어 프로세스 오버헤드 줄이기
• 과도한 재작업 없이 요구 사항을 신속하게 대응

원칙

12가지 원칙

1. 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 최고 우선순위로 한다.

2. 개발 작업 후반부일지라도 요구사항 변경을 기꺼이 수용한다. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3. 2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다.

4. 프로젝트 전반에 걸쳐 비즈니스 담당자들과 개발자들이 매일 함께 작업해야 한다.

5. 동기가 부여된 개인들을 중심으로 프로젝트를 구성한다. 구성원들이 필요로 하는 환경과 지원을 제공하고, 담당 업무를 완수할 것임을 신뢰한다.

6. 개발팀에 그리고 팀 내부에서 가장 효과적, 효율적으로 정보를 전달하는 방법은 대면 대화이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 스폰서와 개발자, 사용자들이 일정한 속도를 계속 유지할 수 있어야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적인 관심으로 기민함을 향상시킨다.

10. 단순성 - 아직 하지 않은 작업량을 최대한 세분화하는 기술 - 은 필수적이다.

11. 최고의 아키텍처, 요구사항 및 설계는 자율구성팀에서 비롯된다.

12. 팀은 정기적으로 더 효과적인 방법을 찾아서 반영한 다음, 그에 따라 업무 활동을 조율하고 조정한다.

---

애자일 방법론 - 익스트림 프로그래밍(Extreme Programming, XP)

• 새로운 버전은 하루에 여러번 빌드될 수 있다
• 증분은 2주마다 고객에게 전달
• 모든 테스트는 모든 빌드에 대해 실행되어야 하며 빌드는 테스트가 성공적으로 실행되면 수행된다

실천 지침

• 작고 빈번한 릴리즈 - 빠른 피드백과 지속적인 개선
• 고객도 개발 팀의 일원
• 프로세스 중심이 아닌 사람 중심의 작업
• 짝 프로그래밍(pair programming)
• 단순한 설계와 테스트 주도 개발(Test Driven Development, TDD)
• 리팩토링을 통한 코드 품질 개선

익스트림 프로그래밍 관행

1. 조금씩, 하지만 자주 발표한다.
2. 사이클을 반복해서 돌리면서 개발한다.
3. 스펙에 없는 것은 절대 집어넣지 않는다.
4. 테스트 코드를 먼저 만든다.
5. 야근은 하지 마라. 항상 정규 일과 시간에만 작업한다.
6. 기회가 생기는 족족 언제 어디서든 코드를 개선한다.
7. 모든 테스트를 통과하기 전에는 어떤 것도 발표하지 않는다.
8. 조금씩 발표하는 것을 기반으로 하여 현실적인 작업 계획을 만든다.
9. 모든 일을 단순하게 처리한다.
10. 두 명씩 팀을 편성하고 모든 사람이 대부분의 코드를 알 수 있도록 돌아가면서 작업한다.

---

테스트 우선 개발의 문제점

• 일부 테스트는 점진적으로 작성하기가 어려울 수 있기 때문에 일련의 테스트의 완성도를 판단하기 어렵다.
• 프로그래머는 테스트보다 프로그래밍 선호
• 때때로 테스트를 작성할 때 지름길 선택(예외를 처리하지 않은 불완전한 테스트 작성)

---

Agile Project Management

project Manager의 역할

: 정해진 예산, 기한에 맞게 계획을 수립하고 일정을 정한다.

기존의 프로젝트 관리 방식은 계획 주도적인 방법인 것에 비해

⇒ 누가 무엇을 언제 전달하고 누가 프로젝트 결과물 개발에 참여할 것인지 보여주는 프로젝트 계획

애자일 방법에서는 새로운 관리 방식이 필요하다.

⇒ 작은 단위의 개발과 반복적인 관리 작업(iterative development)이 주를 이룬다.

---

Scrum

iterative development에 중점을 둔다.

1. 초기 단계에서는, 프로젝트의 목표와 소프트웨어 아키텍처 설계
2. sprint Cycle로 각 사이클 개발은 increment of the system
3. 종료 단계에서는, 시스템 도움말 프레임 및 사용자 메뉴얼과 같은 필수 문서를 작성하고 프로젝트에서 얻은 교훈을 평가한다.

애자일 개발 프로세스를 따라 제품을 점진적으로 구축하는 프로젝트 팀은 각 증분에 적용되는 요구 사항도 이해해야 합니다

여기에서 incremental 은 프로그램을 다시 빌드하거나 다시 배포하기 전에 프로그램을 비교적 약간 변경하는것(소프트웨어를 점진적으로 빌드한다. ⇒ 목표 방향으로 진행되고 있는지 재평가)

Scrum 용어

development team	7명 이하의 self-organizing 소프트웨어 개발자 그룹
Potenially shippable product increment
(잠재적으로 출하 가능한 제품 increment)	sprint로 부터 제공되는 소프트웨어 increment
product backlog	scrum team에서 “할 일” 리스트
소프트웨어에 대한 기능정의, 요구사항, 사용자 스토리, 추가적인 보완작업의 정의 또는 사용자 문서(description)
product owner	customer
Scrum	scrum 팀의 일일 회의(커뮤니케이션)
진행상황을 검토하고, 그날 수행할 작업의 우선 순위를 지정
이상적으로는 전체 팀을 포함하는 짧은 대면 회의
ScrumMaster	Project Manager과는 다른 의미
Scrum 프로세스를 준수하고 팀이 scrum을 효과적으로 사용하도록 이끌어갈 책임이 있다.
회사와 인터페이스하고, 외부 간섭에 의해 스크럼 팀이 우회되지 않도록 할 책임이 있다.
⇒ ScrumMaster의 역할은 외부의 방해로부터 개발 팀을 보호하는 것이다.
Sprint	development interation(개발 반복), 전체적인 개발의 Cycle 기간, 스프린트는 일반적으로 2~4주
Velocity	팀이 단일 스프린트에서 처리할 수 있는 제품 백로그 노력의 추정치(개발 속도)
스프린트에서 다룰 수 있는 항목을 추정하는데 도움이 되며, 성능 향상을 측정하기 위한 기초를 제공

Scrum Sprint Cycle

Sprint backlog : 개발자들의 역량을 파악하여 2~4주동안 할 수 있는 일의 backlog를 계획한다.

Sprint의 기간은 2~4주의 고정된 기간 (Cycle동안 일을 마무리 못하더라도 연장하지 않는다.)

Sprint Cycle의 시작은 product backlog

Select items : product backlog의 선택은 customer와 협력하는 모든 프로젝트 팀이 포함된다.

모든 사항이 합의되면 팀은 소프트웨어를 개발한다.

이 단계에서 팀은 고객 및 조직과 격리되며, 모든 커뮤니케이션을 ‘Scrum Master’를 통해 이루어진다.

Sprint가 끝나면 완료된 작업을 검토하고 Skateholder(이해 관계자)에게 제공한다. ⇒ 이후 다음 Sprint Cycle이 시작된다.

Teamwork in Scrum

‘Scrum Master’ : 매일 일정을 조율하는 facilitator(조력자), 팀의 회의나 수행할 작업의 백로그에대한 진행상황을 측정하고 기록, 팀 외부에서 고객 및 회사 경영진과의 커뮤니케이션을 한다.

전체 팀이 Scrum(짧은 일일 회의)에 참석하여 모든 팀원이 정보를 공유 ⇒ 지난 회의 이후의 진행상황, 이슈, 계획 등의 커뮤니케이션

⇒ 이는 개인이 팀의 다른 사람들이 하는 일을 알고 있으며, 문제가 발생하면, 문제에 대처하기 위한 방식을 수립한다.

Scrum의 장점

• product는 관리/이해 가능한 작은 단위로 쪼개어져 진행상황을 파악할 수 있다.
• Unstable requirements(불안정한 요구사항)은 진행을 방해하지 않게 한다.
• 전체 팀이 프로젝트 진행의 모든 것을 알 수 있으므로 팀 커뮤니케이션의 향상
• customer는 increment의 진행을 확인하고, 제품 작동방식에 대한 피드백을 얻는다.
• 고객과 개발자 간의 신뢰가 형성되어 긍정적인 분위기 조성

---

Scaling agile methods (애자일 방법의 확장)

애자일 방법은 소규모 팀에서 개발할 수 있는 중소 규모 프로젝트에서 성공적인것으로 입증됨

애자일 방법 확장시 유지해야하는 것

• Flexible planning
• frequent system releases
• continuous integration
• test-driven development
• good team communication

agile 방법의 문제점

• 계획의 불확실성

  애자일은 타임박스 제공에 기반을 두고 있으며, 프로젝트 관리자가 작업에 우선 순위를 두는 경우가 많기 때문에 원래 릴리즈로 예약된 일부 항목이 제때 완료되지 않을 수 있다.

• 팀을 구성하기가 어려움

  애자일 팀은 대개 작기 떄문에 팀 구성원들은 함께 구성하기 어려울 수 있는 다양한 분야에서 높은 수준의 기술을 보유하고 있어야 한다.

• 비포괄적인 설명서

  신속한 변화를 위한 선언문은 적절한 문서보다 작업 소프트웨어를 선호하기 때문에 일부 개발자는 적절한 문서를 작성할 수 있다 .

• 최종 제품이 요구사항과 다를 수 있음

  애자일(Agile)은 매우 유연하기 때문에 고객 피드백 진화에 따라 새로운 반복 작업을 추가하여 최종 결과물을 다르게 제공할 수 있다.

Key point!

애자일 방법

• 신속한 소프트웨어 개발
• 소프트웨어의 빈번한 릴리스
• 문서를 최소화
• 고품질 코드 생성
• 프로세스 오버헤드를 줄이는데 중점
• 점진적인 개발 방법

애자일 개발 방식에는 다음이 포함됨

• 시스템 사양에 대한 사용자의 스토리
• 소프트웨어의 빈번한 릴리스
• 지속적인 소프트웨어 개선
• 테스트 우선 개발
• 고객 참여

스크럼

스크럼은 프로젝트 관리 프레임워크를 제공하는 애자일 방법이다

• 시스템 증분이 개발될 때 고정된 기간인 스프린트 세트를 중심으로 한다

많은 실용적인 개발방법은 계획 기반과 애자일 개발이 혼합되어 있다

애자일 방법을 대규모 시스템에 확장하는 것은 어렵다

• 대규모 시스템은 사전 설계가 필요하며 일부 분서 및 조직 관행은 애자일 접근 방식의 비공식성과 충돌할 수 있다