Agile 모델
그 전까지는 실제 현장에서 사용할 수 있는 모델들과 워터폴과의 차이점을 이야기 했다.
원래 Agile 개발 방법은 책의 9판까지는 없었다고 한다.
10판에 새롭게 추가된 내용인데, 여기서 알 수 있는 점은 Agile 방법을 최근에 많이 쓰게 됐다는 것이다.
등장 배경
Waterfall 방식의 장점이자 아이덴티티는 매 단계가 끝이 나면 문서가 나온다는 것이다.
하지만 문서 제작에 의한 오버헤드가 꽤나 컸다.
매 단계가 끝이 나면 문서가 나오는 것은 좋지만 그 장점을 위한 오버헤드가 생각보다 많이 컸기에 이 오버헤드를 줄이는 Agile 방식을 고안하게 되었다.
목표
Agile 모델의 목표는 요구사항 변경에 빠르게 반응하여 delivery time을 줄이는게 목표다.
Agile이라는 단어의 뜻이 민첩하다는 것인데, 바로 요구사항 변경에 민첩하다는 의미이다.
Plan-based와 Agile의 프로세스
Plan-based development
3가지 단계로 진행이 된다.
- Requirements Engineering
- Requirements Specifications
- Design and implementation
요구 사항을 찾고, 요구 사항에 대한 문서를 작성하고 이를 디자인과 구현하는 과정을 거친다.
만약 디자인과 구현 과정에서 요구사항이 바뀌게 되면 다시 Requirements Engineering으로 돌아가 요구사항을 찾고, 문서를 작성하게 된다.
심지어는 한 단계를 계속해서 반복할 수도 있다.
Agile development
Agile에서는 Requirements Specification 단계인 문서화 단계가 사라지게 된다.
그러나 없다는 의미는 아니다.
비중이 획기적으로 줄었다는 것이지 문서화는 존재한다.
Agile 방식은 위의 두 단계를 반복적으로 수행하여 문서화라는 오버헤드를 줄임으로서 Delivery time을 줄인다.
특징
점진적인 개발(Incremental development)
Agile 모델은 계속 붙여나가는 개발하는 방식이라고 할 수 있다.
단계들(increments)의 연속으로 개발이 된다.
작고 빈번한 시스템 배포(small and frequent system releases)
위의 점진적인 개발에서 말한 단계의 단위가 작으며, 작은 만큼 자주 일어난다.
모든 increment가 배포되는 것은 아니지만, 굉장히 잦게 배포가 된다.
반복적인 접근 (Iterative approach)
각 단계를 한 번 하고 끝나는 관점이 아니라, 특정 단계들을 계속해서 반복하는 방식으로 접근한다.
고객 참여(Customer involvement)
개발 팀에 고객이 참여한다는 것인데, 조금 와닿지 않을 수 있다.
이 말은 고객이 개발하는 입장으로 개발 팀에 참여하는 것이 아니라, requirement와 testing에 참여한다는 것이다.
공식적으로 개발 팀에 들어간다기 보다 고객의 의견을 반영한다는 것을 조금 비유적으로 말한 것이다.
문서화작업의 축소로 인한 오버헤드 축소
위에서도 이야기했지만, 문서화 작업이 완전히 제거된 것이 아니다.
문서화 작업을 축소 시킨 것이다.
문서화 작업 시간이 줄어들은 만큼 오버헤드가 줄어든게 된다.
Extreme Programming (XP)
그러면 Agile 모델 중 하나인 Extreme Programming을 보자.
프로그래밍이 Extreme? 스포츠도 아닌 프로그래밍이 Extreme이라니 상상하기 힘들다.
그렇다면 뭐가 Extreme 한 것일까?
Increment의 사이즈가 Extremely small하기에 Extreme이라고 이름이 붙여진 것이다.
Release cycle
Increment의 사이즈가 Extremely small한 만큼 반복 주기와 각 요소가 굉장히 짧다. ▼
각 요소들을 하나씩 보자.
1. Select user stories for this release
여기서 user stories는 고객의 요구사항을 의미한다.
이번 릴리즈에 출시할 고객의 요구 사항을 하나 선택하는 단계이다.
2. Break down stories to tasks
1번에서 선택한 고객의 요구 사항에서 해야할 일을 분석한다.
3. Plan release
2번에서 분석한 것을 토대로 계획을 세운다.
4. Develop integrate test software
본격적으로 개발을 한다.
5. Release software
개발한 소프트웨어를 배포한다.
6. Evaluate System
배포한 소프트웨어에 대해 평가하고 버그와 개선방안을 찾아 유지보수를 한다.
User stories for requirements
위의 과정을 보면 user stories를 토대로 업무를 구분하고 개발을 한다.
이렇게 유저는 개발과 상관없는 역할이 아니라, 오히려 팀에 포함되고 요구사항 결정을 하는 중요한 역할을 한다.
XP의 문서화 작업을 줄여주는 3 요인
Extreme Programming, 줄여서 XP는 아래의 3단계를 통해 문서화 작업을 줄여준다.
- Refactoring
- 테스트 (말 그대로 시험해보는 것이므로 설명은 넘어가겠다.)
- pair 프로그래밍
Refactoring
Refactoring은 코드를 개선하는 것을 말한다.
하지만 버그를 잡는 Debugging 과는 다른 개념이다.
프로그램에서의 버그는 프로그램이 제대로 동작하지 않게 하는 요인으로, Debugging은 프로그램이 제대로 동작하지 않기에 제대로 동작하기에 프로그램을 고친다는 것과 같은 말이다. ▼
하지만 Refactoring은 프로그램이 제대로 동작하지 않는다는 것을 전제로 깔고 들어가는 Debugging과는 다르게 프로그램이 제대로 동작한다는 것을 전제로 한다.
Refactoring은 현재 프로그램은 잘 동작하고 있지만, 이 프로그램의 구조와 작동 방식을 수정하여 조금 더 좋은 프로그램으로 만드는 것을 목표로 한다.
지속적인 Refcatoring은 구현에 있어서, 코드 변경을 더 쉽게 도와준다.
Refactoring말고도 Restructuring이라는 것이 있는데, 이는 외부 인터페이스에는 영향을 주지 않고 내부 인터페이스를 고쳐 개선하는 방법을 말한다.
Pair programming
짝을 지어 프로그래밍 한다는 것으로, 한 명은 코드를 짜고 다른 한 명은 리뷰하는 방법이다.
"두 명 다 코딩을 하는게 좋지 않나요?"
두 명다 코드를 짜는게 조금 더 효율적일 것 같지만, 생각과는 다르게 각자 코딩하는게 비용이 더 많이 든다.
말은 같이 앉아서 코딩하는것이지만 사실은 리뷰 프로세스라고 볼 수 있다.
문서화 작업 축소가 가능한 이유
"위의 두 과정이 문서화 작업을 줄여준다고 했는데, 위의 과정들이 문서화 작업과 무슨 관계가 있는 것일까?"
이제 Agile 방식의 핵심을 이야기할 차례다.
Agile 방식이 문서화를 축소할 수 있는 이유는 바로 “프로젝트의 이해도” 덕분이다.
소프트웨어를 문서화 하는 이유는 요구사항을 정확히 해놓는 것도 있지만, 프로젝트에 대한 이해도가 부족할 경우 문서를 보고 그 이해도를 보충할 수 있게 하기 위함도 있다.
“개발하는 사람이 프로젝트에 대한 이해가 부족한게 말이 되나요?”
만약 해당 팀에 새로 들어온 사람이라면 어떨까?
처음 들어왔는데 해당 프로젝트에 대해 많은 것을 알고 있다면 아마 그 회사의 보안은 굉장히 허술한걸지도 모른다.
일반적으로는 프로젝트에 대한 이해도가 부족하고, 이 이해도를 보충하기 위해 문서를 읽는 과정을 거친다.
그런데 이해도가 높은 사람들만 모여있다면 어떨까? 개발속도가 올라가지 않을까?
Agile 방식은 바로 이 점을 이용한 것이다.
Refactoring과 Pair Programming을 통해 이해도를 높여놓아 문서를 별도로 작성하지 않아도 괜찮은 상황을 만드는 것이다.
즉, 문서화를 할 시간에 프로젝트의 이해도를 높여놓는 것이다.
Agile 실무의 문제점
Agile 방식을 들어보면 굉장히 편리한 방식 같지만, Agile에는 여러 문제점이 있어서 제대로 알고 사용하지 않으면 오히려 더 많은 비용이 들 수 있다.
소프트웨어 문서 부족
문서화 작업이 없기에 문서가 부족하다는 단점이 있다.
이해도가 높은것은 사실이지만, 이해도와 세부적인 디테일을 잘 아는 것은 이야기가 다르다.
세부적인 디테일들이 정리되어있지 않아서 요구사항을 확인하기 힘들다.
개발팀 유지의 어려움
소규모의 인원으로 서로 즉각적인 피드백을 통해서 여러 버전업을 통해 개발이 진행되는 것이 Agile 방식이다.
그러나 Agile 방식은 아이러니 하게도 버전업을 많이 하게 되면 힘들어진다.
앞에서도 언급했듯이 Agile 방식은 팀원들의 높은 이해도를 바탕으로 진행이 된다.
하지만 이해도가 높은 팀원들끼리 꽤나 많은 버전업을 해놓았는데, 팀원들이 오래 남아 있을거라는 보장이 없다.
이렇게 기존 멤버들이 사라지게 되면, 해당 프로젝트에 대한 이해도가 부족한 사람들이 들어오게 되며 별도의 문서화 작업이 진행되어있지 않아 그 이해도를 높이는데 많은 시간과 노력이 들게 된다.
기존 멤버들이 하나 둘 사라지게 되면 프로젝트에는 점점 이해도가 부족한 사람만 남게 되고 유지보수에 어려움이 생기게 된다.
그럼 어디에 적합?
위의 문제점과 특징들을 보면 그 답이 쉽게 나온다.
작은 규모의 소프트웨어 개발과 같은 장소에 있는 팀들
Agile 방식은 큰 규모의 소프트웨어 개발에는 맞지 않다.
이는 문서화가 제대로 되어있지 않기 때문인데, 그 이유는 위에서 언급했다.
그리고 인원이 많은데서도 적합하지 않다.
계속 피드백을 받고 이를 반복시키는 Agile 특성상, 서로 간의 소통이 중요하기 때문에 가까운 위치에 있는 팀에 적합하다.
유지보수 보다 새로운 개발이 많은 프로젝트
팀의 구성원들이 오래 유지될 거라는 보장이 없기 때문에 유지보수가 어렵다.
하지만 처음부터 개발을 시작하게 되면 높은 이해도로 프로젝트를 진행할 수 있기 때문에 새로운 개발이 필요한 프로젝트에 적합하다.
Customized software development
Generic한 개발에서는 적합하지 않을 수 있다.
모든 사람들이 사용할 수 있는 프로젝트에 매주 업데이트가 하나씩 나온다는 것은 상상하기 힘들다.
마이크로소프트 오피스가 매 주 업데이트가 하나씩 나온다는 것은 상상할 수 없다.
요런데에 적합
팀에 고객이 계속 포함될 수 있는 경우
고객들에게 쉽게 소프트웨어를 배포할 수 있어야 Agile을 사용하기에 좋다.
계속해서 피드백을 받을 수 있는 환경이 조성되어야 한다.
Agile vs Plan-driven
4가지 질문을 통해 Agile이 적합한지 Plan-driven이 적합한지 간단하게 테스트해 볼 수 있다.
- 개발을 시작하기 전에 굉장히 세부적인 요구 사항을 받아놓는게 중요한지?
- 고객들에게 빠르게 배포될 수 있으며 즉각적인 피드백을 받을 수 있는 점진적인 개발 방식인지?
- 시스템의 규모가 큰지?
- 개발 팀이 같은 장소에 모여 있는지?
| 1번 | 2번 | 3번 | 4번 | |
| N번 조건이 해당 됨 | Plan-Driven | Agile | Plan-Driven | Agile 가능 |
| N번 조건이 해당 안됨 | Agile | Plan-Driven | Agile | Agile 불가능 |
4번에서 같은 장소에 있는지에 대한 조건은 Plan-Driven은 모여도, 안모여있어도 괜찮다.
하지만 Agile의 경우엔 멀리 떨어져있다면 수행하기 어렵다.
위에서 이렇게 분류를 해놓았지만, 대부분의 프로젝트는 둘 다 쓰고 있다.
각 서브시스템과 컴포넌트에 적합한 개발 방식을 적용하고 있다.
UI와 Entertainment 컴포넌트에는 Agile 방식을, 자율주행 차 개발에는 Plan-Driven한 방식을 적용한다.
자율주행 차 개발을 Agile로 하겠다고 하면 그건 차 사고가 나면 고치겠다는 뜻이다…
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 8. 요구사항 포착 (0) | 2024.01.26 |
|---|---|
| 7. Modeling Concepts (0) | 2024.01.26 |
| 5. Process Iteration (0) | 2024.01.21 |
| 4. Process Activities (0) | 2024.01.20 |
| 3. 소프트웨어 프로세스 모델 (0) | 2024.01.19 |
