[소프트웨어공학] Chapter 03. Agile Software Developments _XP,Scrum

Agile Software Development 에 관하여

 소프트웨어 개발에서 사용되는 혁신적인 방법론으로, 작은 주기로 개발을 진행하고 지속적인 피드백을 통해 요구사항을 조정하며 효율적으로 개발을 진행하는 방식

 초기에 모든 요구사항을 정확하게 파악하기보다는 사용자와의 소통과 지속적인 피드백을 통해 요구사항을 조정하고 개선할 수 있습니다. 이를 통해 개발 초기부터 문제점을 해결하고 더 나은 제품을 만들어낼 수 있음

 

Rapid software development

•  최근들어 빠르게 개발하고 배포하는 것이 종종 가장 중요한 요구사항이 되고 있다

   그러나, 비지니스적인 요구사항들을 신속하게 반영하여 업데이트를 해야하기에

   요구사항들이 변하지 않고 유지되는 소프트웨어를 만드는 것은 사실상 불가능하다

•  Plan-driven 기법은 일부 시스템 개발 시 필수적일 수 있으나 신속하게 소프트웨어를 개발하는 것이 힘들다

•  Agile 기법은 1990년대에 나타나 빠르게 개발하고 빠르게 배포하는데 목적을 두고 있다

 

Agile development의 특징 

 - Specification, design, implementation 과정들이 inter-leaved ( 서로 왔다갔다 가능 )

 - 시스템이 일련의 버전이나 증분으로 작업되고 이해관계 당사자(skateholder)들이 각 버전의 사양과 평가 과정에 포함된다

 - 평가 후 새로운 버전으로 빈번하게 배포한다

 - 개발하는데 광범위한 tool을 지원한다

 - 문서화를 최소화하여 개발에 집중하도록 한다

 

* 작은 주기로 개발을 진행하고 이를 지속적으로 검토하며 필요한 조정을 수행하는 방식

 

 

Plan-driven and Agile development 

 Plan-driven development

   · 계획 중심 개발방법은 여러 단계로 분리되어있고 결과물들이 사전에 계획된 단계에서 생산된다

   · 각 활동들이 반복적으로 적용

   · 작성된 문서를 참고하여 제작한다.

 

 Agile development

   · specification, design, implementation, testing과정이 모두 inter-leaved 하고 결과물이 협상과정에서 결정된다.

   · 8~90년대에 소프트웨어 설계에 과도하게 시간 쓰는 것에 불만족하여 생겨남

      - 설계보다는 코드(기능)에 집중

      - 소프트웨어 개발에의 반복적인 접근에 기반

      - 작업물 배포를 빠르게 하고 변화하는 요구사항을 빠르게 적용하기 위해 생김

 ※ Agile 기법의 주요 목적은 문서들을 최소화하고 요구사항을 빠르게 과도한 추가작업 없이 적용하는데 있다

 

Principles of Agile Methods ( 애자일 방식의 원칙 )

 1) Customer involvement (고객의 참여) : 새로운 시스템의 요구사항과 우선순위를 알려주고 시스템을 평가하는데 참여한다

 2) Incremental delivery (증분 배포) : 각 반복 절차마다 고객이 추가로 제시한 요구사항들을 추가하여 ( 증분하여 ) 개발한다

 3) People not process (과정보다는 사람에 집중) : 조직에서 가장 중요한 것은 사람이다 조직 내에서 팀워크, 리더쉽, 의사소통, 문제해결능력, 창의성 등의 인적 자원이 중요하다.

 개발하는 팀의 기술력에 대하여 잘 알고있어야 하고 개발자들을 과정 절차에 구애받지 않고 그들의 방식으로 개발하도록 두어야한다

 4) Embrace change (변화 수용) : 시스템에 추가 요구사항이 있을거라 예상하고 그 요구사항들을 수용해야한다

 5) Maintain simplicity (단순성 유지) : 개발과 업데이트 과정의 단순화에 집중 (복잡한 것을 제거하자=>복잡해지면 나중에 구현하기 힘들어질 수 있다)

* increment : 이전 제품 증분에 새로운 기능이 추가되어 업그레이드 된 제품.

고객이 사용 가능한 수준의 기능이 구현되어있음

 

Agile method Applicability  ( 애자일 방식의 적용가능성 )

 - 중, 소규모의 시스템을 판매하는 소프트웨어 회사에 적용가능. ( 현재, 대부분의 시스템과 앱들은 agile 방법을 쓴다 )

 - 고객이 확실히 참여하고자 하고 외부의 규칙, 규율이 거의 없을 때 적용가능.

 

 

---

Agile development techniques

1. Extreme Programming(XP) : 소규모 개발 팀에 적합한 애자일 방법론으로, 고객과의 긴밀한 협력, 작은 주기로 개발을 진행하며 테스트 주도 개발 (Test-Driven Development, TDD) 및 지속적인 통합 (Continuous Integration, CI) 등의 실천 방법을 강조합니다.
2. 스크럼(Scrum) : 가장 대표적인 애자일 개발 방법론으로, 일정한 주기로 나누어진 작업 단위를 통해 팀원 간의 협업을 강조합니다.
3. 칸반(Kanban) : 작업을 진행하는 과정에서 시각적인 보드를 활용하여 작업 상태를 관리하며, 작업량을 최적화하고 공정성을 유지하는 방법론입니다.
4. 크리스털(Crystal) : 소규모에서 대규모 프로젝트까지 다양한 규모에 적용 가능한 애자일 방법론으로, 프로젝트의 복잡성과 중요도에 따라 다양한 레벨의 크리스털을 적용합니다.
5. 리스크 중심(Risk-Driven) : 프로젝트에서 발생할 수 있는 위험을 파악하고, 그 위험에 대한 대응책을 세우는 것을 중심으로 개발을 진행하는 방법론입니다.  etc..

[ Extreme programming (XP) ] 

Extreme Programming (XP)은 애자일 개발 방법론 중 하나입니다. XP는 소규모 개발 팀에 적합한 애자일 방법론으로, 고객과의 긴밀한 협력, 작은 주기로 개발을 진행하며 테스트 주도 개발 (Test-Driven Development, TDD) 및 지속적인 통합 (Continuous Integration, CI) 등의 실천 방법을 강조합니다. XP는 소규모 개발 팀에서 빠르고 유연하게 개발을 진행하며 더 나은 소프트웨어를 만들기 위해 고객과 함께 협력하며 지속적인 피드백을 받는 방식을 추구합니다.

 

   반복적인 개발을 extremely 하는 기법

    · 새로운 버전이 하루에 여러번 만들어지기도/빌드되기도 한다

    · 증분(추가 작업분)은 매 2주마다 고객에게 배포된다

    · 모든 테스트는 각 빌드마다 수행된다(테스트가 모두 성공적으로 이루어졌을때 해당 빌드는 받아들여짐.)

 

 The XP release cycle (p 14 참고)

 해당 배포판에서의 유저스토리 선택 => 스토리를 여러 작업으로 쪼개기 => 계획 세우기 => 개발, 통합, 테스트 => 배포 => 평가  => 해당 배포판에서의 유저스토리 선택  => … 반복

( 위 과정이 순환 형태로 반복 )

 

Extreme programming practices ( 실무에서의 XP )

 - Incremental planning ( 점진적 계획 ) : 요구사항은 story cards로 기록되고 배포시 포함되어야한다 개발자는 이 기록된 것(story cards) 을 여러 업무로 쪼갠다.

 - Small releases ( 조금씩 배포 ) : 사업가치를 갖는 최소한의 유용한 기능으로 이루어진 시스템을 먼저 배포 후 점진적으로 기능을 추가해서 배포한다

 - Simple design ( 단순한 디자인 ) : 현재 요구사항들만 만족할 정도로 설계

 - Test-first development ( 테스트 우선 개발 ) : 구현되기 전에 자동화된 단위 테스트 프레임워크를 써서 새 기능에 대한 테스트부터

 - Refactoring ( 리팩토링 ) : 코드의 단순성과 유지 보수성을 높이기 위해 개발하면서 리팩토링 과정을 지속적으로 하기

 - Pair programming ( 짝지어 개발 ) : 2명 이상을 묶어서 같이 개발 ( 서로의 작업을 점검하고 도와줄 수 있음 )

 - Collective ownership ( 공동소유 ) : 팀이 시스템 전체를  개발하기 때문에 모든 코드에 공동으로 책임감을 갖고 개발 (누구든지 코드를 수정가능)

 - Continuous integration ( 연속적인 통합 ) : 업무가 완성되면 각자 개발한 것을 합친다 ( 각자 개발한 것이 문제가 없어야함 )

 - Sustainable pace ( 유지할 수 있는 속도 ) : 과도한 업무는 코드의 질을 떨어뜨리고 생산성을 저하시킨다

 - On-site customer ( 현장의 고객 ) : 시스템의 최종 사용자의 대표자( = customer )는 XP프로그래밍 시 full time으로 옆에서 확인할 수 있어야 한다 ( 즉, 고객이 개발팀의 구성원이 된다. 요구 사항을 잘 알려주는데 책임이 있다. )

 

XP and Agile principles ( XP와 Agile의 원칙 )

 - 증분 개발(incremental development)은 시스템을 조금씩 나누어서 개발하며, 짧은 주기로 시스템을 출시하는 방식으로 지원됨

 - 고객참여는 개발 처음부터 끝까지 함께 팀에 관여한다는 것 ( full-time )

 - 프로세스보다는 사람에 집중 ( 협업으로 개발, 공동 책임감, 과로 지양 )

 - 정기적인 시스템 배포를 통해 변화를 지원함

 - 꾸준한 리팩토링을 통해 코드의 단순성 유지

 

Influential XP practices ( 영향력 있는 XP 실용 방법 )

 - XP 기법은 기술적인 부분에 집중하고 대부분 회사에서 실무에 적용하기 쉽지않다,,

 - XP기법 중 필요한 부분만 골라서 사용

  ▪ User stories for specification
  ▪ Refactoring
  ▪ Test-first development
  ▪ Pair programming

 

User stories for requirements ( 요구사항이 담겨있는 사용자 스토리 )

 - XP에서 고객이나 사용자는 XP팀의 일원이 되고 요구사항을 결정하는데 책임이 있다.

 - 사용자의 요구사항은 사용자의 스토리나 시나리오 등으로 표현된다.

 - 이 요구사항들을 문서화(cards) 하고 개발자들은 이를 업무로 쪼갠다 ( cards를 보고 시간과 비용 예측 가능 )

 - 고객은 우선순위와 시간,비용 고려하여 다음 배포판에 추가될 스토리들을 택한다

 

A 'prescribing medication' story - 사용자 스토리 예시

스토리카드 : ‘~를 선택하면, ~하게 동작한다’의 여러선택지들에 대해 쓰여있음

   사용자 : ~~하게 돌아가야해 ! / 개발자 : ~~하게 구현해야겠구나!

 

Refactoring (리팩토링)

 - 과거엔, 시스템의 변화를 예측/대비하여 개발하는 것이 cost를 절감시켜주었기에 현명하였음

 하지만, XP기법에서는 변화를 믿을만하게 예측할 수 없으므로 가치를 크게 두지 않는다

 대신, 변화를 쉽게 반영하기위해 꾸준히 코드를 개선한다

 - 개발 팀에서는 당장 필요하지 않아도 개선할만한 소프트웨어를 찾아 코드를 꾸준히 개선함

   (소프트웨어의 이해도를 높여주고 문서화 필요성을 줄일 수 있게된다)

 - 리팩토링을 하면 코드가 잘 구조화 되어있고 가독성이 좋아 쉽게 변경 할 수 있다

  하지만, 가끔은 구조 리팩토링(엄청 큰 변화)을 해야 하는데 이는 개발 비용이 더 많이 들 수 있다

 

리팩토링의 예시

 - 클래스 계층구조를 다시 조직하는 것  ( 중복된 코드 제거 )

 - 함수, 변수 등의 이름을 이해하기 쉽게 바꾸는 것

 - 인라인 함수를 메서드화 하여 언제든지 계속 쓸 수 있게 하는 것

 

Test-first development (테스트 우선 개발)

"테스트를 먼저 작성한다"는 뜻.

개발자가 코드를 작성하기 전에 테스트 케이스를 작성하고 해당 테스트 케이스를 통과시키기 위한 최소한의 코드를 작성하여 이를 통과시키는 방법

이렇게 함으로써 개발자는 코드 작성 전에 예상되는 동작과 결과를 미리 생각하고 검증할 수 있다.

 

 XP에서 테스트는 가장 중요하고 업데이트될 때(변화가 있을 때)는 항상 프로그램(전체)이 테스트되는 접근방식을 사용

 

XP 테스트 특징

 - 테스트 우선 개발

 - 시나리오로부터 증분(추가 부분) 개발

 - 테스트 및 점검 과정에 사용자가 꼭 참여

 - 자동화된 테스트를 이용하여 모든 요소를 새로운 배포판(new release)이 생길때마다 점검 (생산성 향상)

 

*모든 요소를 테스트하는 이유 : 새로 개발한 부분말고 기존의 부분이 안돌아갈 수 있기에.

( 쉬는 동안 돌리면 되기에 개발시간 사용되지않음 )

 

 

테스트 우선 개발( Test-first development )의 문제점

 - 대부분의 개발자들은 테스팅보다 프로그래밍을 선호하기에 테스트케이스를 만드는데 부족함이 있을 수 있음

  ( 모든 케이스들을 체크하지 못할 수 있음 )

- 일부 테스트는 점진적으로 작성되기 어려울 수 있음

  ( ex. 초기에 구현되지 않은 부분이 많음 / 유저인터페이스가 복잡,많으면 테스트할 경우가 너무 많음 )

 - 테스트케이스의 완성도를 판단하기 힘듦

  (충분히 많이 테스트해도 테스트되지 않은 부분이 있어 문제가 생길 수 있다)

 

Test-driven development (테스트 주도 개발)

테스트가 개발의 중심이 되는 개발 방법

개발자가 작성할 코드를 정의(specification)하기 전에 테스트 케이스를 작성한다. 작성한 후 해당 테스트 케이스를 통과시키기 위한 최소한의 코드를 작성한다. 이후에는 작성한 코드를 리팩토링하면서 코드의 가독성, 유지보수성, 성능 등을 개선할 수 있습니다. 이를 통해 코드의 품질을 높일 수 있다.

 

 - 코드 작성 전에 테스트 코드를 먼저 작성 ( 요구사항이 완전히 이해되지 않았을 때 테스트코드를 작성해보면 이해하는데 도움을 줌. 이해도가 부족할 때 작성하기에 코드의 완성도가 낮음 )

 - 테스트는 데이터보다는 프로그램으로 만들기 (자동화 하기위해) => 정확하게 실행됐는지 체크할 수 있어야함

 - 모든 기존의, 새로운 테스트는 새로운 기능이 추가될 때마다 자동적으로 진행되어야함 (새로운 기능이 에러를 유발하지 않는지 체크)

 

Customer involvement (고객 참여)

 - 고객의 역할은 다음 배포판에서 구현될 것들의 테스트 항목을 만들어 주는 것이다.

* Acceptance test : 사용자가 ok할 수 있는 테스트

 - 팀의 일원인 고객은 개발과정에서 테스트케이스들을 작성한다 => 새로운 코드들은 고객의 요구에 맞게 확인받아야한다

 - 개발자와 같이 해결해나아가야 문제가 발생하지 않을 수 있는데,

     full time으로 같이 작업할 수 없어 요구조건을 제공하는 것만으로 충분하다고 느끼는 고객들도 있음

 

Test case description for dose checking ( testcase 예시 )

Test automation ( 테스트 자동화 )

 - 구현/배포되기 전에 테스트가 실행가능한 구성요소로 작성되는 것
- stand-alone ( 독립 실행 방식 )

- 결과( output )가 정확해야함

- 테스트가 자동화 되면 빠르고 쉽게 테스트가 진행된다

 

Pair programming ( 짝지어 개발 )

 - 여러명 짝지어 코드를 같이 개발

 - 코드 소유를 같이할 수 있고 팀 내에서 지식들이 공유가 된다

 - 각 행을 여러명이 확인하기 때문에 비공식적인 점검 과정을 거치게 된다

 - 리팩토링을 하면 팀원 전체가 이득을 볼 수있다

 - 같은 공간, 컴퓨터에서 협업 진행

 - 지식을 공유하며 개발하면 다른 팀원이 사라졌을 때(이직 등) 위험을 덜게 된다

 - 따로따로 개발하는거보다 pair programming이 더 효율적인 경우도 있다

 

 

---

Agile project management

Agile project management ( 애자일 프로젝트 관리 )

Agile기법의 한계를 고려하여 Agile 방식 프로젝트를 관리하는 방법

 

 - 프로젝트 매니저의 주된 책임사항은 소프트웨어를 제시간안에 개발하고 계획한 cost내에서 진행되도록 관리하는 것

 - 프로젝트 관리의 기본 방식은 plan-driven방식임

  프로젝트 매니저는 무엇을, 언제까지, 누가 개발할 것인지 계획한다

   ( 현재 진행률과 프로젝트 계획을 비교 후 고객에게 진행률을 알려주고 프로젝트가 올바르게 나아가고 있는지 확인가능) 

 - 하지만 Agile 프로젝트 관리방식(Agile project management)에서는 plan-driven과는 다른 접근방식을 채택한다

   · 개발은 증분해서 진행

   · Agile 방식에서 실용적인 것들을 이용

-> Scrum방식이 나옴

 

[ Scrum ] 

애자일 방법론 중 하나로, 소프트웨어 개발 프로젝트를 위한 프로세스 프레임워크.

Scrum은 팀 기반의 프로젝트 관리 방법으로, 프로젝트를 작은 주기(sprint)로 쪼개어 반복적으로 개발하고, 팀원들이 지속적인 협력과 피드백을 통해 프로젝트를 진행하는 것을 중요시한다.

 

각 주기(sprint)마다 Product Owner는 이번 주기에 해야 할 작업을 정의하고, 개발팀은 이 작업을 진행한다. Scrum Master는 프로젝트를 지원하고 개선하기 위해 개발팀과 협력하며, 장애물을 제거하고 팀원들이 원할하게 작업할 수 있도록 돕는다.

Scrum에서는 주기별로 개발한 결과물을 검토하고, 문제를 식별하고 수정해나가는 Retrospective(회고적)를 실시한다. 이를 통해 프로젝트 진행 상황을 체크하고 개선할 점을 파악한다.

Scrum은 빠르고 유연하며, 팀원들이 자율적으로 작업할 수 있는 환경을 제공한다. 또한, 프로젝트의 진행 상황을 빠르게 파악할 수 있으며, 지속적인 피드백과 개선을 통해 프로젝트를 완성해 나갈 수 있다.

 

Scrum의 3가지 단계

 1. Initial phase : 초기화, 전반적인 목표 설정, 소프트웨어 구조 설계 (개발의 목적과 소프트웨어 구조 디자인)

 2. Sprint cycle phase : 각 사이클마다 시스템을 증분해서 개발 (여러번 반복)

 3. Project closure phase : 프로젝트를 마무리하고 결과를 문서화하는 단계 (사용설명서, 개발 후기 등)

 

Scrum terminology (스크럼 용어)

기존 용어와는 다른 용어사용

• Development team (개발 팀) : 직접 조직한 7명 이하의 개발자 그룹 (개발하고 필수 문서를 만드는 작업을 함. / face to face meeting을 해야하기에 소규모(7명이하)로 팀을 짬. )
• Potentially shippable product increment (잠재적으로 전달 가능한 소프트웨어 증분) : Sprint에서 개발팀이 완료한 모든 작업을 통합한 결과물로, 고객에게 직접 제공할 수 있는 상태의 제품 증분
• Prouduct backlog (제품 백로그) : 해야될 일들의 리스트들 ( To-do list ) (소프트웨어의 특징 정의, 요구사항, 사용자의 말, 추가적으로 해야될 업무 기록)  
• Product owner (제품 소유자) : 고객 / 프로젝트매니저 or 회사 대표일 수도 있음
• Scrum (스크럼) : 스크럼 팀이 매일( 중간중간 문서화를 안하기 때문에) 대면으로 하는 회의 => 매일 정보 공유
• ScrumMaster (스크럼 마스터) : 회의를 주도하는 사람(project leader/manager)
                                                   ( 역할 : 팀가이드, 회사와 조율 )  (프로젝트 관리자와는 같거나 다를 수 있다)
• Sprint : 반복되는 개발 주기, 2~4주를 주기로 함.
• Velocity : 일을 얼마나 감당할 수 있는지 (한 팀이 한 sprint 동안)

 

Scrum sprint cycle

Scrum sprint cycle

 - 개발주기는 고정된 길이로 보통 2~4주 (이 기간안에 못끝내면 backlog에 추가된다)

 - Sprint cycle의 시작시점은 product backlog이다 (프로젝트에서 완성되야 할 업무)

    ( 제품 백로그 : 해야될 일들의 리스트들, To-do list )

 - Selection phase에서는 고객과 일하는 모든 팀이 참여해서 product backlog에 있는 특징들과 기능들 중 어떤 것들을 해당 sprint동안에 개발할지 정한다

 

 - 특징들과 기능들을 선택하면 팀을 꾸린다

 - 한 sprint 동안 팀은 고객과 분리되고 모든 의사소틍은 스크럼 마스터를 통해서만 이루어진다

 - 스크럼 마스터의 역할은 개발팀이 외부로부터 방해받는 것을 막는 것

 - 한 sprint의 마지막에는, 한 일들을 검토하고 이해관계 당사자에게 보여준다. 이후 다음 sprint가 진행됨

 

Teamwork in Scrum

 - 스크럼 마스터는 매일 하는 회의를 주도하고 해야 할 일 점검, 결정 기록, backlog와 비교하여 진행률 파악, 고객과의 소통 등을 한다

 - 모든 팀은 daily meetings(Scrums)에 참여하여 정보를 공유하고 진행률과 진행과정에서 발생한 문제, 오늘 무엇을 할 지에 대해 말한다

 ( 매일 회의를 함으로써 팀의 모든 사람들은 어떻게 진행되어가는지 알 수 있으며, 문제가 발생하면 대처하기 위해 단기적인 작업 계획을 재조정할 수 있다 )

 

스크럼의 장점 ( Benefits )

 - 규모가 큰 것을 관리 가능한 업무로 쪼갠다 (진행률을 파악하기 좋다)

 - 기간이 고정되기 때문에 불안정한 결과물도 진행에 방해를 주지 않는다

 - 모든 팀이 모든 것을 알 수 있고 팀원간 의사소통능력이 향상된다

 - 고객은 시간안에 결과물을 기대할 수 있고 어떻게 진행되는지 피드백 받을 수 있다

 - 고객과 개발자간 신뢰도 상승 

 

Distributed Scrum

분산 환경에서 스크럼 프로세스를 수행하는 방법이다.

 분산 환경에서는 지리적 거리와 시간차이 등으로 인해 팀원들 간의 협업이 어렵다. 이러한 어려움을 극복하기 위해 스크럼의 프로세스, 역할, 이해관계자 간의 커뮤니케이션 등을 조정하여 분산된 팀원들 간의 협업을 원활하게 하는 방법이다.

인건비가 낮은 나라에 일을 맡기는 것

 

---

Scaling agile methods

애자일 방법론을 대규모 조직 또는 대규모 프로젝트에 적용하기 위한 방법론

다수의 팀이 작업하는 경우, 각 팀이 자체적으로 애자일 방법론을 적용하는 것뿐만 아니라 팀 간의 협력과 조율을 위한 프로세스를 구축하고 관리하는 것

 

Scaling out and Scaling up

Scaling Up ( 규모 확장 , 더 크게 )

 대규모 조직/프로젝트에 애자일 방법을 적용하는 것, 전체 프로젝트를 한 번에 처리하고 프로젝트 수행 중 모든 조각들이 잘 맞아떨어지도록 하는 것이 목표

 

Scaling Out ( 분산 확장 , 여럿이서 )

 여러 팀이 협력하여 대규모 프로젝트를 처리하고, 다양한 기능 영역에서 프로세스를 통합하여 전체적으로 애자일 방법론을 적용하는 이 목표로

 

애자일 기법의 실무에서의 문제 ( Practical problems )

- 애자일 방법론은 소프트웨어 유지보수보다 새로운 소프트웨어 개발에 적합함.

 그러나, 대규모 기업에서 대부분의 소프트웨어 비용은 유지보수에서 발생함

 또한, 문서화가 최소화됐는데 유지보수가 가능할지도 문제임.

- 애자일 방법론은 소규모의 공동 위치의 팀들에 적합함.

 그러나, 현재 많은 소프트웨어 개발은 전세계로 분산된 팀들로 이루어져있음

 

애자일 기법의 계약적인 이슈 ( Contractual Issues )

- 맞춤형 시스템( custom system ) 에 관한 대부분의 계약은 개발자가 고객을 위해 구현해야할 내용을 설명하는 명세서를 기반으로 한다.  하지만, 이는 애자일 개발에서 명세서와 개발을 번갈아가며 수행하는 것을 불가능하게 한다.

- 요구되는 기능성보다 개발자의 시간에 대해 값을 지불하는 계약을 한다.

  그러나, 이는 개발되어야하는 하는 부분이 보장되지 못하기에 많은 법무 부서에서  (조직에서) high risk로 여겨진다.

 

애자일 방법론에서의 유지보수 

주요 문제

  1) 문서화 부족 

  2) 고객을 개발과정에 계속해서 포함시키는 것

  3) 개발팀의 연속성 유지 ( 팀원이 바뀌었을 때 해당 팀원의 업무를 새로운 팀원이 잘 해낼지 ) ( long-lifetime system에서 실제 문제가 됨 )

 

 

* 실용적인 문제 : 개인이나 조직, 사회에서 직접적으로 경험하고 해결해야 하는 문제

 

Agile and Plan-driven methods

대부분의 프로젝트들은 애자일과 plan-driven의 요소들을 균형있게 포함함.

 - 구현 전에 매우 상세한 명세서와 설계를 원하면, plan-driven

 - 증분개발을 하고자하면, agile

- 비정형적으로 소통하는 소규모의 공동 공간의 팀이면, agile

 - 큰 개발팀을 필요로 하는 대규모 시스템이면, plan-driven

 

애자일 원칙들과 실무

원칙	실무에서의 한계
고객참여	개발 팀과 full time으로 시간을 쓸 수 있고 이해관계자를 대표할 수 있는 고객이 필요하나, 종종 고객 대표자들은 다른 업무에 시간을 할애하여 개발에 완전히 참여하지 못하는 경우가 있다. 또한, 외부의 이해관계자(ex.규제기관)가 있는 경우 이들의 의견을 애자일 팀에게 효과적으로 전달하는 것은 어렵다.
변화수용	여러 이해관계자가 있는 시스템에서 각 이해관계자는 서로 다른 변경사항들에 다른 우선순위들을 매긴다. 이해관계자들의 의견을 모두 수렴하여 우선순위를 결정하는 것은 어려울 수 있다.
증분 개발	개발의 빠른 반복 및 단기 계획은 사업 계획 및 마케팅의 장기 계획 주기와 항상 일치하지 않을 수 있다. 마케팅 매니저들은 몇 개월 전에 제품의 기능을 미리 알아야 효과적인 마케팅 캠페인을 준비할 수 있다.
단순성 유지 (리팩토링)	고객에게 전달되어야하는 일정의 압박으로 팀 멤버들은 시스템 단순화를 바람직하게 수행할 시간이 부족할 수 있다.
과정 보다 사람	개별 팀 멤버가 애자일 방법론의 집중적인 참여에 적합한 성격이 아닐 수 있으며, 따라서 다른 팀 멤버와 원활하게 상호작용을 하지 못할 수 있다.

 

* regulator(규제기관) : 금융 산업에서는 금융감독원,

의료 산업에서는 보건당국 및 의약품 규제 기관 등이 규제기관의 역할을 수행

 

시스템 이슈들

- 어느 정도 규모의 시스템이 개발될지

   애자일 방법론은 비정형적으로 회의하는 작고 공동 작업의 팀에게 효율적이다

 

- 어떤 유형의 시스템이 개발될지

   구현 전에 많은 분석이 필요한 시스템들은 이 많은 분석들을 수행하기 위해 상당히 자세한 설계가 필요하다

 

- 시스템이 얼마나 오래 사용될지

   장기간 사용되는 시스템은 개발자의 의도를 지원팀에게 전달하기 위해서, 그리고 유지보수와 같은 시스템 지원 작업이 오랜기간에 걸쳐 이루어져야 하기에 문서화가 필수적이다.

   애자일 방법론에서는 문서화를 최소화하고 코드 자체를 자세하게 주석처리함으로써 시스템을 설명하는 것이 일반적.

 

- 시스템이 외부 규제기관에 영향을 받는지

   시스템이 규제되어 있으면 시스템 안전 증명서의 일부로 자세한 문서가 필요할 수도 있다

   규제기관에서 시스템 안전성을 검토할 때 자세한 문서가 필요할 수 있다. 이러한 경우에는 애자일 방법론에서도 일부 문서화가 필요할 수 있다. 자세한 문서에는 시스템 설계 및 구현, 시스템 테스트 결과, 위험 분석, 사용자 매뉴얼, 유지보수 정보 등의 내용이 포함된다.

   

People and Teams

- 애자일 방법론에서는 설계한 것을 코드로 바꾸기 위해 plan-driven에 비해 고수준의 프로그래머를 필요로 한다.

- 개발 팀이 어떻게 구성되어있는지. 만약 팀이 분산되어있으면 설계에 관한 문서가 필요할 수 있다.

- 어떤 support 기술이 필요한지. 만약 설계 문서가 없으면 시각화 및 프로그램 분석을 위한 IDE 지원이 필요하다.

 

조직적인 이슈들 ( organizational issues )

- 전통적인 조직들은 plan-driven development 를 사용하는 문화가 있다. 
-  상세한 시스템 명세서를 개발하는 것이 표준적인 조직 관행인지?

- 고객 대표가 시스템 증분에 대한 피드백을 제공할 수 있는지?

- 상세한 문서화를 중요시하는 조직 문화에서 비정형적인 애자일 개발 방법론이 적합할지?