애자일 개발
애자일 개발은 문서가 생성되지 않는다는 것을 의미하는 것이 아니고, 개발 프로세스의 뒤에서 참조되어질 수 있는 문서들을 만든다는 것을 의미한다. 애자일 방법은 종종 라이트 방법(light methods) 또는 린 방법(lean methods)라고도 한다.
[애자일 소프트웨어 개발 선언문]
우리는 소프트웨어를 개발하면서, 또 다른 사람들이 그 일을 하는 것을 도와주면서, 소프트웨어 개발을 위한 더 좋은 방법을 찾아내고 있다. 이 작업을 통해 다음과 같은 것에 가치를 둔다.
프로세스와 도구보다 개인과 상호작용에
포괄적인 문서보다 작동하는 소프트웨어에
계약 협상보다 고객과의 협동에
계획을 따르는 것 보다 변경에 대한 대응에
즉, 왼쪽 항목도 가치가 있지만, 오른쪽 항목에 더 높은 가치를 둔다.
1 민첩성이란
민첩성이란 환경의 변화에 재빨리 그리고 효율적으로 적응하는 능력의 의미한다. 애자일에서는 고객을 개발 팀의 멤버로 받아들이고, 커뮤니케이션을 보다 쉽게 할 수 있도록 해주는 팀 구조와 사고방식을 장려한다.
2 민첩성과 변경 비용
[그림 1] 개발에서의 시간에 따른 변경 비용
소프트웨어 개발에 있어서 전통적으로는 변경 비용이 시간이 증가함에 따라 비선형 형태로(짙은 실선) 비용이 급속하게 증가한다. 하지만 잘 설계된 애자일 프로세스는 변경 비용 곡선이 평평하게 되도록 하고, 소프트웨어 팀이 과도한 비용을 쓰지 않고 또 개발시간에 영향을 받지 않으면서 나중에 변경하는 것이 가능하게 해준다고 한다. 애자일 프로세스는 소프트웨어가 점증의 형태로 릴리스 되고, 점증 내에서 변경을 보다 잘 제어할 수 있기 때문에 변경 비용을 감소시켜 준다. 또한, 단위 테스팅과 페어 프로그래밍과 같은 다른 애자일 실무와 연관되어 있으면 변경을 하는 데 드는 비용이 적어진다.
페어 프로그래밍 : 한 개의 컴퓨터에 두 명의 프로그래머가 앉아 컴포넌트의 코드를 작성하는 소프트웨어 개발 접근법. 키보드를 잡고 있는 사람을 driver라고 하고 다른 한 사람을 Observer, pointer, navigator라고 한다. 실시간 코드 리뷰가 수행된다는 것을 암시적으로 의미한다.
3 애자일 프로세스란?
애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말이 아니라 애자일(agile=기민한, 좋은 것을 빠르고 낭비 없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다 - 애자일 소프트웨어 개발, 위키백과
3.1 애자일리티 원칙
애자일 연합은 민첩성을 달성하기 원하는 사람들을 위해 12가지 애자일리티 원칙을 정의하였다.
1) 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시킨다.
2) 개발 후반부일지라도 요구사항 변경을 반겨라. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3) 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두 달 간격으로 하되 더 짧은 기간을 선호하라.
4) 비즈니스 쪽의 사람들과 개발자들은 프로젝트 진행하는 동안 같이 일해야 한다.
5) 동기부여가 된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 자원을 주고 그들이 일을 끝내리라고 신뢰하라.
6) 개발 팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7) 작동하는 소프트웨어가 진척의 주된 척도이다.
8) 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.
9) 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다.
10) 간결함-처리하지 않은 작업의 양을 최대로 해주는 기술-은 필수적이다.
11) 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.
12) 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
3.2 애자일 개발 전략
"... 아무도 민첩성을 반대하지는 않는다. 실질적인 질문은 다음과 같은 것이다. 민첩성을 얻기 위해 가장 좋은 방법이 무엇인가? 중요한 것은, 고객의 오늘의 요구를 만족하고 오랜 기간 동안 요구를 만족하도록 확장 가능한 품질 특성을 가지고 있는 소프트웨어를 어떻게 개발하나?이다. ... 두 학파의 좋은 점만 생각하면 얻을 수 있는 것이 많이 있고, 각 방식을 폄하하면 아무것도 얻을 것이 없다."
애자일리티와 소프트웨어공학 중에서 선택할 필요는 없다. 그보다는 애자일한 소프트웨어 공학을 정의하라.
4 익스트림 프로그래밍
익스트림 프로그래밍(eXtreme Programming, XP)은 켄트 백 등이 제안한 소프트웨어 개발방법으로, 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다. -위키백과
4.1 XP 프로세스
XP는 객체지향 기법을 개발 패러다임으로 사용하고, 네 가지 프레임워크 액티비티(계획 수립, 설계, 코딩, 테스팅) 맥락 안에서 이루어지는 규칙들과 실무들을 포함한다.
[그림 2] 익스트림 프로그래밍 프로세스
● 계획 수립 : 계획 수립 액티비티(=planning game)는 요구하는 출력과 주요 특징과 기능에 대한 요구 사항(스토리)을 수집한다. 고객은 각 스토리를 인덱스 카드에 정한다(우선순위 설정). XP팀은 스토리를 평가하고 비용과 시간(주 단위)을 판단한다. 3주 이상이 된다면 스토리를 더 작은 스토리로 나눠야 한다.
● XP팀에 의해 개발될 다음 릴리스(다음 점증)에 요구사항 그룹을 어떻게 나눌지 결정하기 위해 고객과 개발자는 같이 작업한다. 개발이 진행되면서, 고객이 요구사항을 변경할 수 있다. XP는 남아 있는 모든 릴리스를 다시 생각하고 그것에 따라 계획을 수정한다.(Small Release)
● 설계 : XP설계는 엄격하게 KIS(keep it simple), KISS(keep it small and simple) 원칙을 따른다. 복잡한 표현보다는 항상 간단한 설계를 선호한다.(Simple Design)
● XP에서는 소프트웨어를 객체지향 맥락으로 생각하기 위한 효율적인 방법으로 CRC카드를 사용할 것을 권장한다. CRC(class-responsibility-collaborator) 카드는 객체 지향 소프트웨어설계에서 사용되는 브레인스토밍 툴로, 지금의 소프트웨어 점증에 적합한 객체지향 클래스를 파악하고 구조화한다. 일반적으로 디자인을 시작할 때 어떤 객체가 필요하고 그들이 어떻게 상호 연계할지 여부를 결정하는 데 사용한다.
● 만약 스토리 설계의 한 과정에서 어려운 설계 문제를 접하게 되면, XP는 그 부분에 대해 작동하는 프로토타입을 즉각적으로 만들 것을 권장한다.
● 코딩 : 코딩을 시작하기 전에 단위 테스트를 생성한다.(XP 방식의 핵심 요소) 관련 없는 것은 더 이상 추가하지 않는다(KIS). 코드가 완성되면 즉시 단위 테스트가 이루어지고, 개발자에게 즉각적인 피드백을 제공하게 된다.
● 코딩 액티비티를 진행하는 동안의 핵심 개념은 페어 프로그래밍(pair programming)이다. 이 방법은 실시간 문제 해결과 실시간 품질보증을 위한 메커니즘을 제공한다. 작업을 완수하면 다른 사람이 작업한 것과 통합한다. 통합 팀에 의해 하루 단위로 이루어지고, 다른 경우 페어 프로그래머가 통합의 책임을 진다. "지속적인 통합" 전략은 호환성과 인터페이스 문제들을 피하도록 해주고, 초기에 에러를 발견하는 "스모크 테스팅(smoke testing)" 환경을 제공해 준다.
● 테스팅 : 단위 테스트는 자동적인 수행을 가능하게 해주는 프레임워크를 사용하여 구현되어야 한다. 이렇게 하는 것은 코드가 수정될 때 마다(XP 리팩토링 철학에 따라, 자주) 회귀 테스트 전략을 쓸 것을 권장한다.
● 고객 시험(customer test)이라고도 하는 XP의 인수시험(acceptance test)은 고객에 의해 명시되고, 보여지고, 검토되는 전반적인 시스템 특성과 가능에 초점을 맞춘다. 인수 시험은 소프트웨어 릴리스의 일부분으로 구현되는 사용자 스토리로부터 만들어진다.
4.2 산업계 XP
Joshua Kerievaky는 산업계 익스트림 프로그래밍(Industrial Extreme Programming, IXP)을 다음과 같이 묘사하였다. "IXP는 XP가 자연스럽게 발전한 것이다. XP가 가진 최소화, 고객 중심, 테스트 구동 정신으로 가득 차 있다. 기존 XP와의 차이점으로 더욱 많이 포함되어 있는 관리, 확장된 고객의 역할, 개선된 기술적 실무 측면이 있다. 대규모 조직 안에서 XP팀이 중요한 프로젝트를 성공적으로 수행하기 위해 고안된 여섯 가지의 새로운 실무과정은 다음과 같다.
● 준비 평가 : 모든 구성원이 준비가 되었는지, 적합한 개발환경이 만들어졌는지, 연관된 수준의 기술을 이해하고 있는지 확인한다.
● 프로젝트 커뮤니티 : 커뮤니티는 기술자와 다른 이해관계자들을 포함해야 하고, 프로젝트 팀을 위해 알맞은 사람들이 필요한 기술과, 훈련이 잘 되어있는지 결정한다.
● 프로젝트 차터링 : 프로젝트를 위한 적합한 비즈니스 명분이 있는지와, 프로젝트가 조직의 전반적인 목표와 목적을 발전시킬 것인지를 결정하기 위해 프로젝트 자체를 평가한다.
● 테스트-주도 관리 : 일련의 측정 가능한 목표를 설정하고, 이러한 목표에 도달하였는지 여부를 결정하기 위한 메커니즘을 정의한다.
● 회고 : 소프트웨어 점증이 인도된 후에 특별한 기술적 검토를 수행한다. 회고라고 불리는 검토에서는 소프트웨어 점증과 또는 전체적인 소프트웨어 릴리스를 통해 "이슈, 이벤트 그리고 학습한 교훈"을 조사한다.
● 지속적 학습 : 고품질 프로덕트를 만들 수 있도록 새로운 방법론과 기술을 배울 것을 권장한다.
5 그 외 애자일 프로세스 모델
가장 광범위하게 사용되는 애자일 프로세스 모델은 익스트림 프로그래밍이다. 그 외에 네 가지 일반적인 애자일 방법에 대해 살펴본다.
5.1 스크럼(scrum, 럭비 경기의 액티비티에서 유래)
스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 프로젝트관리를 위한 상호, 점진적 개발방법론으로, 개발 프로젝트를 위해 고안되었지만 유지보수 팀이나 일반적 프로젝트/프로그램 관리에서도 적용 가능하다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같 은 특성을 가지고 있다.
● 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
● 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
● 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
● 날마다 15분 정도 회의를 가져라.
● 항상 팀 단위로 생각하라.
● 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.
[그림 3] 스크럼 프로세스 흐름
각각의 프레임워크 액티비티(요구사항, 분석, 설계, 변경, 인도를 포함하는 개발 액티비티)에서, 작업 태스크는 스프린트(Sprint)라 불리는 프로세스 패턴 안에서 생긴다. 스프린트 안에서 수행되는 작업은 스크럼 팀에 의해 당면한 문제에 맞춰지고 실시간으로 정의되고 또한 종종 수정된다.
스크럼은 빠듯한 시간, 요구사항의 변경, 그리고 사업상 위험한 상태를 가지고 있는 프로젝트에 효과적이고, 프로젝트 우선순위, 구분되어 있는 작업 단위, 커뮤니케이션, 그리고 빈번한 고객 피드백을 강조하는 일련의 프로세스 패턴을 포함하고 있다
● 백로그(Backlog) : 개발할 제품에 대한 요구 사항 목록
● 스프린트(Sprints) : 반복적인 개발 주기, 미리 정의된 타임박스(일반적으로 30일)에 적절하게, 백로그에 정의되어 있는 요구사항을 완수하는 데 필요한 작업 단위.
● 스크럼 미팅(Scrum meeting) : 스크럼 팀에 의해 매일 열리는(일반적으로 15분) 회의. 세 가지 주요 질문내용에 대해서 모든 팀 멤버가 묻고 대답한다.
● 지난번 팀 미팅 이후에 무엇을 하였나?
● 어떤 걸림돌이 있나?
● 다음 팀 미팅 때까지 무엇을 완수할 계획인가?
스크럼마스터(ScrumMaster)라 불리는 팀 리더는 미팅을 주관하며, 팀원을 코칭하고, 프로젝트의 문제 상황을 해결하는 역할을 하고, 각 멤버들의 답변을 평가한다.
● 데모(Demos) : 소프트웨어 점증을 고객에게 인도해서, 고객에게 구현된 기능이 보여지고 평가될 수 있도록 한다. 데모에는 계획한 모든 기능이 포함되어 있지 않을 수 있지만, 설정된 타입-박스 안에는 인도될 수 있는 기능들이 포함되어 있다는 것을 아는 것이 중요하다.
5.2 동적 시스템 개발 방법(Dynamic Systems Development Method, DSDM)
DSDM은 통제된 프로젝트 환경에서, 점증적 프로토타이핑을 통해 빠듯한 시간 제약조건 내에 시스템을 개발하고 유지보수하기 위한 프레임워크를 제공하려는 개발 방식이다. 또한, Rapid Application Development (RAD) 방법론에서 발전한 것으로, 초기부터 지속적으로 사용자의 적극적 참여를 통한 요구사항 즉시 반영 방식이다.
● DSDM의 9개의 철학
● 적극적인 사용자 참여.
● DSDM 팀은 결정을 내릴 수 있어야 한다.
● 수시로 제품을 인도해야 한다.
● 비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.
● 반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴
● 개발 동안 변경이 가능함
● 요구사항은 상위 수준에서 우선순위가 정해져야 한다.
● 생애주기를 통한 통합 테스팅
● 모든 이해관계자 간의 협업과 협조가 필수적이다.
● DSDM의 5단계
● Feasibility Study(타당성 분석)
● Business Study(비즈니스 요구사항 분석)
● Functional Model Iteration(기능 모델 반복)
● Design and Build Iteration (설계와 구현통합)
● Implementation(구현)
5.3 애자일 모델링(Agile Modeling)
"애자일 모델링은 소프트웨어-기반 시스템의 효과적인 모델링과 문서화를 위한 실무-기반 방법론이다. 간단히 말하자면, 애자일 모델링은 소프트웨어 개발 프로젝트에 효과적이고 경량적인 방법으로 적용할 수 있는, 소프트웨어를 모델링하기 위한 가치, 원칙 그리고 실무의 모임이다. 애자일 모델은 전통적인 모델들보다 더 효과적이라. 왜냐하면 그것은 약간 좋은 것이고 완벽할 필요가 없기 때문이다. ", AM을 유일한 것으로 만들어주는 원칙들은 다음과 같다.
● 목적을 가진 모델 : 모델을 생성하기 전에 특정한 목표를 가지고 있어야 하며, 목표가 정해지면 어느 표기 유형을 사용할 것 인지와 요구되는 상세함의 수준이 더 명확해 질 것이다.
● 다중 모델 사용 : 필요한 통찰력을 제공하기 위해서 각 모델이 시스템의 다른 측면을 나타내야 하고, 대상으로 삼은 고객에게 가치를 제공해 주는 모델만 사용 하여야 한다는 것을 제안한다.
● 가벼운 여정 : 소프트웨어공학 작업이 진행됨에 따라, 장기적인 가치를 제공하는 모델만을 유지하고, 나머지는 폐기하라. 보관되는 모든 작업 산출물은 변경이 이루어지면 유지보수가 되어야 한다.
● 표현보다 컨텐츠가 더 중요 : 모델링은 대상으로 하는 고객에게 정보를 전달해 주어야 한다.
● 개발툴과 모델에 대해 알기 : 소프트웨어를 개발하기 위해 사용하는 각 모델의 강점과 약점을 이해하라.
● 부분 적 적용 : 모델링 방식은 애자일 팀의 필요에 따라 적응되어야 한다.
5.4 애자일 통합 프로세스(Agile Unified Process, AUP)
AUP는 크게는 순차적, 작게는 반복적인 철학을 채택하였다. 전통적인 UP 단계 액티비티 -inception, elaboration, construction, transition-를 채택함으로써 순차적 오버레이를 제공한다. 각 액티비티동안 민첩성을 얻기 위해, 그리고 가능한 한 빨리 최종 사용자에게 점증을 인도하기 위해 팀은 반복 수행한다. AUP 반복에서는 다음과 같은 액티비티에 역점을 둔다.
● 모델링 : 비즈니스와 문제 영역에 대한 UML 표기를 생성한다. 하지만, 민첩성을 유지하기 위해 "단지 좋을 정도"이어야만 한다.
● 구현 : 모델은 소스코드로 변환 되어야 한다.
● 테스팅 : XP와 같이 에러를 발견하고 소스코드가 요구사항을 만족시킨다는 것을 확실히 하기 위해 팀은 일련의 테스트를 설계하고 실행시킨다.
● 배치 : 소프트웨어 점증의 인도와 최종 사용자부터의 피드백 획득에 초점을 맞춘다.
● 형상과 프로젝트 관리 : 형상관리는 변경관리, 리스트관리, 팀이 개발하는 것을 제어한다. 프로젝트 관리는 팀의 진척사항을 추적하고 관리하며 팀 액티비티를 조정한다.
● 환경 관리 : 팀에 가능한 표준, 도구, 다른 지원 기술을 포함하는 프로세스 인프라를 조정한다.
6 애자일 프로세스 도구
협력과 커뮤니케이션 "도구"들은 일반적으로 기술수준이 낮으며, 애자일 개발자간의 정보와 조화를 제공하는 매커니즘("물리적 근접, 화이트 보드, 포스트 시트, 인덱스 카드 그리고 스티커 메모지" 또는 최근 소셜 네트워킹 기술들)을 포함한다. 능동적 커뮤니케이션은 팀 역학(예를 들어, 페어 프로그래밍)을 통해 얻어지며, 반면에 수동적 커뮤니케이션은 "정보 라디에이터"에(예를 들어, 하나의 점증을 구성하는 서로 다른 컴포넌트들의 전체적인 상태를 나타내는 평범한 패널 디스플레이)에 의해 얻어진다. 애자일 프로세스를 지원하는 "도구 모음"은 기술적인 측면보다는 사람 측면에 더 초점을 맞추고 있다.
Temperature.c
