Agile Software Development

애자일 프로세스의 배경에는 소프트웨어 개발 자체가 과거와 양상이 바뀌었다는 전제가 있다. 90년대 후반까지의 소프트웨어 개발은 장기간에 걸쳐 많은 사람들을 투입하고 충분한 비용을 투입하여 진행하는 것이었다. 소프트웨어 공학이나 많은 관리 방법론들이 모두 이러한 종류의 프로젝트를 대상으로 삼고 있다.

그러나 지금의 소프트웨어는 개발기간이 짧고 적은 비용을 투입한다. 게다가 매우 복잡하고 개방적이다. 또한, 사회의 상황이나 시장의 변동에 따라 변화가 심하고 요구사항도 시시각각 변해가고 있다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법 만으로는 대처할 수 없게 되었다.

이런 문제에 대한 기술적인 해결책으로 "객체지향(OO:Object Oriented)"이 있다. 객체지향 기술은 그 동안의 개발 문제를 적절하게 대처해 주었다. 그리고, 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서, 애자일 개발 프로세스의 상당수는 객체지향 기술을 기반으로 한다.

애자일 개발 프로세스는, 제한된 시간과 코스트 안에서 정보는 불완전하고 예측은 불가능 하다는 전제를 가진다. 그리고 그 전제아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 프로세스이다.

Agile의 정의

- 개발과정에서의 시스템의 변경사항을 유연하게 또는 기민하게 대응할 수 있는 방법론

Agile의 등장 배경

- 변화에 대한 대응력, 품질 유지, 비용관리의 장점을 유지하면서 시스템을 어떠한 방법으로 빠른 시간 내에 개발하느냐 하는 문제에 대해서 90년대 들어 새로운 방법론들이 나타나기 시작함.

- 2001년 XP(Extreme Programming), Crystal, ADS(Adaptive Software Development) 등 방법론 대표자들이 모여서 Agile Alliance 라는 연합체를 구성하면서 “Agile Development” 라는 공식 이름 발표

Agile 선언문의 주요 골자

- 프로세스와 도구보다 개인과 상호 작용

- 전반적인 문서화보다는 제대로 작동하는 소프트웨어

- 계약 협상보다는 고객 협력

- 계획을 따르기보다는 변화에 응대함

Agile 지지자의 권고 사항

- 우리는 가치 있는 소프트웨어를 일찍 자주 산출함으로써 고객을 만족시키는 것을 최우선시 한다.

- 2주에서 두 달 간격으로 작동하는 소프트웨어를 빈번하게 산출한다. 간격은 짧을수록 좋다.

- 제대로 실행되는 소프트웨어는 1차적인 도구이다.

- 개발이 다소 늦어지더라도 요구 사항의 변화를 환영하라. Agile 프로세스는 고객의 경쟁 우위를 위해 변화를 이용한다.

- 비즈니스 인력과 개발자는 프로젝트 기간 동안 날마다 함께 일해야 한다.

- 동기 부여가 된 개인을 중심으로 프로젝트를 구축하라. 그들이 필요로 하는 지원과 환경을 제공하고, 그들이 일하는 것에 대해 신뢰를 부여하라.

- 개발 팀 내에서 그리고 개발 팀에게 정보를 전달하는 가장 효율적이고 효과적인 방법은 직접 대면하고 대화하는 것이다.

- 자발적으로 조직하는 팀에서 최상의 구조, 요구사항, 설계가 만들어진다.

- 기술적인 우수함과 훌륭한 설계 확장의 민첩성에 지속적으로 관심을 갖는다.

- Agile 프로세스는 지속적인 개발을 촉진한다. 스폰서, 개발자, 사용자는 끝까지 일정한 속도를 유지할 수 있어야 한다.

- 단순함- 행해지지 않는 작업량을 최대화하는 기술-은 필수적이다.

- 정기적으로 팀이 어떻게 효과적으로 운영될 수 있는지를 고려해 보고 이에 따라 행동을 조율하고 수정해야 한다.

Agile의 특징

- 소규모의 타임박스화된 서브 프로젝트나 반복주기에 적합

- 각 반복주기의 마지막 계획의 재수립 필요 à 요구사항 우선순위 변경, 새로운 요구사항의 정의 , 어떤 기능을 어떤 버전에서 릴리즈할 것인지 결정

- 전통적인 기법에 비해 암묵적 지식에 보다 신뢰를 두고 있음

- 암묵적 지식을 전파하거나 팀웍을 증진시키기 위한 메커니즘 중요 업무 담당자와 개발자가 물리적으로 동일한 장소에 함께 함

- Pair-wise Programming(하나의 시스템을 동시에 두 사람이 코딩 하는 것)을 규정화

- 처음 릴리즈할 때부터 실제 활용될 수 있는 시스템 개발에 초점을 둠

- 초기 단계에서 개발된 기능 및 아키텍처가 신뢰를 얻으면 그 후속 Iteration은 ROI를 극대화시키기 위한 기능 구현에 초점을 맞추게 됨

Sweet Spots(Agile을 위한 최적위치)

효율적인 소프트웨어 개발의 Sweet Spots를 명확하게 하고 프로젝트를 그러한 Sweet Spots에 가능한 가깝게 다가가도록 한다. Sweet Spots에 도착할 수 있는 팀은 보다 효율적인 메커니즘을 이용할 수 있다.

1. 한 작업실에 2~8명의 작업자

목소리를 높일 필요 없이 다른 사람에게 질문을 할 수 있고, 다른 사람이 언제 자신의 질문에 답해 줄 수 있는지 알고 있으며, 일을 중단하지 않고도 관련된 대화를 들을 수 있다. 이런 환경이 다소 소란스러워질 수 있음에도 불구하고 가장 효율적인 프로젝트는 작은 팀이 같은 방에서 함께 작업할 때이다.

2. 현장 사용 전문가

언제나 사용 가능한 전문가가 있다는 것은, 상상에서 평가된 솔루션에 이르는 피드백 시간이 단지 몇 분에서 몇 시간 정도로 짧아질 수 있다는 것을 의미한다. 신속한 피드백은 개발팀이 사용자의 요구와 습관에 대해 더 깊이 이해하고 새로운 아이디어를 대할 때 실수를 덜한다는 것을 의미한다. 더 많은 아이디어를 시도함으로써 더 나은 최종 산출물을 얻을 수 있다. 프로그래머는 유용한 전문가의 아이디어를 테스트하고 반대 제안을 할 것이다. 이를 통해 새로운 시스템이 어떻게 보여야 하는가에 대한 고객의 아이디어는 다듬어질 수 있다.

3. 한 달간의 증가

제품 및 개발 프로세스 그 자체에 대하여 신속한 피드백을 대처할 만한 것은 없다. 증가적 개발은 피드백 시점을 제공하기에 충분하다. 짧은 증가를 통해 요구 사항 및 프로세스 모두 신속하게 수정할 수 있다. 문제는 “증가 전달 지속 기간”인데 1~3개월이 가장 적당하다. 증가 기간이 길면 산만해지고 집중력이나 추진력을 잃는 경향이 있다.

4. 완전 자동회된 회귀 테스트

회귀 테스트(단위 또는 기능별 테스트)를 통해 2가지 이점을 얻을 수 있다.

개발자는 버튼 하나만 누르면 코드를 수정하고 재검사를 할 수 있다. 이것을 경험한 사람들은 이런 테스트가 미묘한 버그를 방지하리라는 사실을 알고 있다.

누군가 시스템을 변경했는지 여부를 쉽게 알 수 있다.

5. 숙련된 개발자

이상적인 상태는 팀은 숙련된 개발자들로만 구성하는 것이다. 숙련된 훌륭한 개발자들은 동료보다 2~10배 효율적으로 일할 수 있다. 이러한 Sweet Spots을 잡지 못한다면 경험이 부족한 사람들의 능력을 향상시키기 위해 반일제 또는 전일제 강사나 조언자의 고용을 고려할 수 있다.

전통적 SW 개발 방법론과의 차이

Agile의 향후 전망

- 방법론으로 적용하기에 프로세스 정립의 부족

- 대형 프로젝트에 부접합, 감리 대응 어려움, 관리 가이드라인 부족

- 제약조건, 적용 조건이 가장 중요하나 적용하기 어려운 부분임

- 방법론이 아닌 일부 기법

- 중소형 프로젝트에 적합