3. Agile software development

Plan-driven 방식의 소프트웨어 개발 프로세스는 개발과정도중 요구사항의 변화나 요구사항의 문제에 대해서 빠르게 대처하지 못하는 문제점이 있다. 빠르게 변화하는 환경속에서, 빠르게 요구사항에 발맞추어 개발을 하기 위해 Agile 개발 프로세스가 도입되었다. Agile방식의 특징은 다음과 같다.

1) Interleaved specification, design, implementation, minimized fomal documentation 

2) Development in series of increment

3) Extensive tool support for development process

 

3.1 Agile methods

 

대규모의 시스템이 아닌 빠르게 요구사항이 변화하는 중소규모의 시스템 개발에서의 overhead문제 때문에  Agile method의 필요성이 대두되었다. Agile manifesto는 다음과 같다.

 

Individual and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

 

Agile method는 다음과 같은 시스템 개발에 적합하다.

1) 중소규모의 판매용 소프트웨어 제품 개발

2) 개발과정에서 고객이 참여하는 시스템 개발

 

3.2 Agile development techniques

 

Agile method에 대한 초기의 중대한 아이디어중 하나는, XP(eXtreme Programming)였다. XP에서 요구사항은 scenarios(user stories)의 형태로 작성되고, 일련의 task들로 분해되어 구현된다. 이렇게 구현된 task들은 pair를 이룬 프로그래머들에 의해 코드가 작성되기 전에 테스트된다. 모든 테스트들은 이후 새로운 코드들이 작성되어 시스템에 통합될 때 성공적으로 수행되어야 한다. 

 

3.2.1 User stories

개발과정에서 사용자가 적극적으로 참여하도록하여 user stories를 생성하고, 분해되어 task들로 구현되도록 한다. 사용자들과의 토론을 통해 user stories의 우선순위를 결정할 수 있고, 필요없는 task들은 버려지기도 한다. 이러한 방식은 사용자들이 더 요구사항 도출에 쉽게 참여할 수 있도록 하고, 더 나은 개발자와의 커뮤니케이션 방식을 제공한다. 하지만, 이러한 story방식의 문제점은 완전성에 있다. story가 모든 유형의 요구사항을 명백히 담고있는지를 판단하기 어렵다.

 

3.2.2 Refactoring

전통적인 방식에서, 변화를 고려하여 design을 결정하는것은 매우 중요한 문제이다. 하지만, XP와 같은 방식에서 변화를 고려하여 디자인을 결정하는 것은 종종 overhead로 간주된다. XP에서, 코드는 지속적으로 변화를 고려하여 refactoring되어야 한다고 한다. 하지만, 이러한 방식은 처음 코드가 생성될 때의 디자인에 종속되어 시간이 지날 수록 소프트웨어의 구조적인 품질 저하를 야기한다는 문제점이 있다.

 

3.2.3 Test-first development

XP에서, 명백한 specification 없이 테스트를 하는 것이 어렵다는 문제점을 해결하기 위해 test-first development를 도입하였다. 분해된 각각의 task들은 하나 이상의 unit test에 매칭되고, 코드가 생성되기 이전에 테스트 된다. 

하지만, 프로그래머는 테스트보다 프로그래밍을 선호하는 경향이 있기 때문에 불완전한 테스트를 생성할 가능성이 있고, 어떤 테스트의 경우 점진적으로 작성하기 어렵다는 문제점이 있다.

 

3.2.4 Pair programming

XP에서 도입한 pair programming에서 프로그래머들은 집단적 수준에서 책임감과 주인의식을 가지고 일한다. 짝을 지어 일한다는 것은 informal review process가 활성화 됨을 의미한다. 또한, 서로가 서로의 코드를 보면서 refactoring하는 것을 돕게 된다.

 

3.3 Agile project mangement

 

Professional software development에서 중요한 것은 프로젝트가 관리되어야 한다는 점이다. 초기의 agile method에서 비공식적인 계획과 프로젝트 관리는 가시성이라는 비즈니스 요구사항에 부합하지 못했다. 이러한 문제에 대한 해결책으로, Scrum agile method가 개발되었다. Scrum은 원칙적으로는 agile manifesto를 따르지만, 특정한 개발 방식(ex) pair programming, test-first development) 을 따르도록 하는 것이 아닌, agile project organization을 위한 Framework를 제공하는 것에 초점을 맞추었다. 따라서, 기존의 조직의 개발 방식에 쉽게 통합될 수 있고 mainstream approach가 될 수 있었다.

 

scrum sycle을 한번 반복할 때마다, 하나의 product increment가 생성되고 고객에게 배포된다. 한번의 개발의 진행을 sprint라고 부르는데, 이러한 sprint의 시작점은 product backlog이다. product backlog는 product feature, requirements, engineering improvement와 같은 item들의 list이다. 이러한 product backlog에서 해당 cycle에 수행할 item들을 선택하고 고정된 기간(2~4주)동안 sprint를 진행하며, 미완성된 부분이 있다고 해도 이 기간을 절대 넘길 수 없다. 미완성된 부분은 cycle이 끝난후 다시 product backlog로 돌아온다.

이렇게 sprint가 시작되면, scrum team은 선택한 item들의 우선순위를 선정하고, 이전 cycle을 통해 얻어진 진행속도(velocity)에 근거해 한번의 sprint가 cover할 수 있는 일들을 선택해 sprint backlog를 생성한다. 

sprint동안 scrum member들은 short daily meeting을 통해 모든 사람들이 정보를 서로 공유할 수 있도록 한다. 또한, scrum board를 통해 서로간의 상호작용을 할 수 있도록 지원한다.

sprint의 마지막에는 review meeting을 진행한다. 이것은 프로세스 개선과 다음 sprint를 위한 product backlog 변경사항 결정이라는 두가지 목적이 있다.

scrum master은 기존의 project manager와 비슷한 역할을 수행하며, HW 및 SW구매결정, 예산 및 계획 결정등에 참여한다.

scrum은 기본적으로 협업을 전제로 하기 때문에, 같은 공간에 있지 않다면 도입하기 어렵다는 문제점이 존재한다. 최근에는 24시간 원격의 사람들과 함께 일하는것이 일반적인 현상이 되었기 때문에, 이러한 문제점을 해결하기 위해 Distributed Scrum이 개발되기도 하였다.

 

3.4 Scaling agile methods

 

지난 몇년동안, 대규모 시스템과 거대 기업에서 빠른 소프트웨어 배포를 위해 agile method 를 확장(scaling)하려는 시도가 있었다. 

 

3.4.1 Practical problems with agile methods

Agile method은 long-life lifetime을 갖는 시스템이나 embedded system과 같은 시스템에는 적합하지 않은 측면이 있다. 기존의 계약의 경우, 계약사항에 명백한 요구사항이 있으며 이것은 interleaved requirement and code라는 agile method의 원칙에 위배된다. 또한, 거대 기업에서 주된 소프트웨어 비용은 개발이 아닌 maintenance에서 나온다. 하지만, agile method는 유지보수보다는 지속적인 새로운 소프트웨어 개발에 적합하다.

Agile method를 maintenance에 까지 적용하려 했을 때 발생할 수 있는 문제점은 다음과 같다.

1) lack of product documentation : 명백한 required document가 존재하지 않아 유지보수시 변경영향을 평가하기 어려움

2) keeping customer involved : change는 우발적으로 발생하고, 고객을 지속적으로 maintenance과정에 참여시키기가 여려움

3) development team continuity : 프로그래머는 유지보수보다는  새로운 개발을 하는 것을 선호하기 때문에 계속 팀을 유지시키기가 어려우며, 명백한 문서화를 하지 않는 agile method의 특성상 이는 정보의 손실을 의미함

 

3.4.2 Agile and plan-driven methods

거대기업의 경우, 실제로 그들의 프로젝트 중 어떤 것은 Agile방식으로 개발하고, 어떤 것은 Plan-driven방식으로 개발하는 것을 선택했다. 둘 중 어떤 방식을 사용할지 결정는데 고려해야 할 것은 다음과 같다.

1) 시스템의 크기, 2) 시스템의 유형, 3) 기대되는 lifetime, 4) 외부 규제에 얼마나 영향을 받는지

또한, Agile method를 사용하기 위해서는 다음과 같은 것들을 고려해야 한다.

1) 디자이너와 프로그래머의 수준, 2) 어떻게 개발 팀이 조직되는지, 3) 어떤 기술들이 이용가능한지

하지만, 구매자는 우리가 어떠한 방법론을 사용하여 개발하는지는 관심이 없다. 그들의 주요 관심사는 실행가능한, 그들의 필요를 만족시키는 유용한 소프트웨어를 사용할 수 있는지다. 따라서, 상황에 맞추어 가장 효과적인 방법론을 선택하는 것이 중요하다.

 

3.4.3 Agile methods for large systems

대규모 시스템의 경우, 중소규모의 시스템보다 복잡하고, 이해하고 관리하기 어렵다. 따라서, Agile method는 large system에서 사용하기 위해 진화해야만한다. IBM은 Agile Scaling Model을 제안했고, 이것은 초기에 agile 방법론 개발을 충분히하고 그것을 통해 배포하는 것을 훈련한뒤, agility를 scaling하는 것을 의미한다. 지금까지 주로 large-scale development로는 Scrum 방식이 채택되어 사용되어왔다. 

 

3.4.4 Agile methods across organizations

Agile method를 scale out하여 조직 전체에 적용시키기란 어려움이 있다. 주된 원인은 다음과 같다.

1) Agile method에 익숙하지 않은 project manager의 거부, 2) 전사적 품질절차와 표준의 준수에 관한 문제, 3) 구성원간의 기술적 차이, 4) 문화적 저항

조직 전체에 Agile method를 유지시키는 것은 문화적 변화 프로세스이다. 따라서, 조직의 성공적으로 완료된 작은 Agile 프로젝트부터 시작하여 그것을 전사적으로 확장시키도록 하는 긴 기간의 노력이 필요하다.