Agile Software Development
Agile : 기민한, 민첩한
애자일 개발 방식에 대해 알아보자. 개념은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 방법과 지나치게 많은 개발 방법들에서 중간점을 찾고자 하는 방법론이다. 기존의 폭포수모델 같은 전통적인 방법론과의 차이는 less-document-oriented 즉, 문서를 통한 개발 방법이 아니라 code-oriented인 실질적인 코딩을 통한 방법론이다.
● "Rapid" development and delivery is now often the most important requirement for software systems.
비지니스 변화가 빠르고, 요구사항의 변화가 빈번하므로 안정적인 소프트웨어 요구사항을 생성해 내는것이 불가능해졌다.
● Rapid Software Development (특징)
- Specification, design and implementation 이 중첩된다. (inter-leaved)
즉, 명세하는 동안 설계가 진행된다.
- System이 여러 버전의 시리즈로 만들어짐
- 각 version마다 고객이 관리 됨
- User interfaces는 IDE(Interactive Development System) 및 graphical toolset을 통해 개발됨
- focus on the code rather than the design. (디자인보다 코드에 중점을 둔다 여기서 디자인이란 설계같은것을 말한다)
- Based on an iterative approach to software development. (개발에 반복적인 접근방식을 기반으로한다)
- Intended to deliver working software quickly and evolve this quickly to meet changing requirements. (소프트웨어 납품을 빨리하고 요구사항 변화에 빠르게 대응한다)
하지만 지나친 재작업은 지양한다.
● The principal of agile methods (애자일의 원칙들)
Customer involvement (고객을 끌어들임)
개발과정을 통해 Customer가 긴밀이 협조함
Customer는 요구사항 및 이들간의 우선순위를 제공하고, 각 반복에 대한 평가를 수행하게 됨
각 반복에 대한 평가를 수행하게 됨
Incremental delivery (점진적인 전달)
소프트웨어를 increment단위로 개발
이때 고객이 각 increment에 포함되어야 할 요구사항을 명세한다.
People not process
개발자를 위해 별도의 process를 강제하지 않고 자신의 방법대로 개발하도록 장려한다.
Embrace change
요구사항에 변동이 있을 것으로 미리 가정하고, 시스템이 변동에 잘 적응할 수 있도록 설계한다.
Maintain simplicity
소프트웨어 및 개발 과정에서 단순성(simplicity)을 강조한다.
● Agile method 적용분야
small or medium-size product, (작은 단위라고해도 20,30만 line정도)
custom system (대학교 학생시스템)
개발자들은? Small, tightly integrated team에 의해 진행 (팀원간의 협력이 중요함)
● Agile development
-명세, 설계, 구현 및 테스트가 중첩되어 같이 일어남. 이거 완전 개판이겠는데? 라고 생각할 수 도 있다. 하지만 그럴 능력들이 있는 개발자들이 모인다면 전혀 문제가 되지 않는다. 오히려 문서작성이 귀찮다.
-output이 개발과정중에 결정됨.
● Extreme Programming (익스트림 프로그래밍)
단어가 화끈하다. 문서고 뭐고 프로그래밍을 핵빡세게 한다는 것이다. 이 개발방식이 애자일 방식에서 제일 널리 쓰이는 방식이다.
The best-known and most widely used agile method.
- Extreme Programming(XP)은 반복적 개발을 위해 "extreme"한 방법을 사용한다.
- New versions may be build several times per day (새로운 방식이 하루에도 몇 번씩 나온다)
- Increments are delivered to customers every 2 weeks (납품기간이 2주로 매우 짧다)
- All test must be run for every build and the build is only accepted if test run successfully (매 빌드마다 엄청난 테스트를 한다)
하루에도 몇 번씩 피드백->수정->QA->피드백->수정->QA ....
- 문서는 스토리만 쓴다. 예를들어 물건 판매기능인데 상품검색을 하고 주문을 하고 결제를하고 뭐 어떻게해서 완료되고... 이렇게 스토리 단위로만 쓴다.
● Extreme Programming Practices
Incremental Planing (점진적 계획) " 아 그냥 아는데 까지만 세우고 나중에 추가합시다. 대신 품질은 보증할 정도로 합시다."
요구사항을 story cards에 기록하고, 중요도에 따라 해당 release에 포함될 story를 결정한다.
개발자는 해당 story를 Task로 나눔 (일의 단위이다)
Small releases
최소한의 유용한 기능을 가진 단위로 첫 번째 release를 구성하여 개발을 시작한다.
Release를 매우 빈번히 한다.
Simple design
일단 요구사항을 만족할 만큼 설계를 한 후 더 이상 설계에 많은 투자를 하지 않는다.
Test-first development
새로운 기능을 구현하기 전에 해당 기능에 대한 test를 먼저 작성한다.
이를 위해 자동화된 unit test framework를 사용한다.
Refactoring (재구조화)
모든 개발자들은 code에 대해 지속적으로 리팩토링을 수행한다. (simple하고 maintainable한 코드를 유지하기 위함이다)
예를들어 class계층도 재조직 : 중복코드제거, 속성 이름변경 등.
자기성찰과 비슷하다. 써놓았던 코드들을 다시 보는 작업이다.
● Extreme programming practices
Pair programming
개발자들이 pair로 일함. 각자의 작업을 검토해 주고 도움을 줌.
언뜻보면 인건비 낭비인듯 하다. 하지만 개발을 해본 분들이라면 알겠지만 진짜 죽어도 잘못한 것이 없는데 루프를 안탄다거나 정말 틀린게 없는거 같은데 런타임때 안된다던지 뭐 이런 컴퓨터를 때려 부수고싶은 상황이 종종 있음에 동의할 것이다. 그럴때 그냥 덮고 잔 후 아침에 일어나서보면 진짜 어이가 없는 실수를 발견한 경우나 다른 사람에게 도저히 안된다고 코드를 보여줬을 때 뭐야 여기 부등호 틀렸네 혹은 single quote double quote 실수 했네 이런식으로 바로바로 잡힌다. 그래서 페어로 일하는 것이 효율적이다.
Collective Ownership
개발자 pair가 시스템 전체부분에 걸쳐 작업한다. 그러므로 모든 개발자들이 모든 코드에 대해 책임을 진다. 임의의 사람이 코드의 어떤 부분도 변화시킬 수 있다. 한 코드의 주인이 집단이 된다. 이것의 장점은 어떤 개발자가 결근하거나 이직을 해도 큰 타격이 없다,
Continous Integration
Task가 완료되면 전체시스템에 즉각적으로 통합된다.
통합 후, 모든 unit test를 수행하여 통과되어야 한다. 무엇이 잘못되었는지 바로 알 수 있다.
Sustainable Pace
Large amounts of overtime are not considered acceptable! 지속적 페이스를 유지하라는 것이다. 벼락치기는 좋지않다.
On-site customer
고객 대표가 XP팀과 full time으로 관여한다.
● 부작용ㅎㅎ
가장 최악은 계획대로 되지 않는 경우이다.
# 납기일전 핵버닝 (밤샘작업)
# 지연에 따른 비난과 개발자 멘탈 파괴, 스트레스
# 결국 고객 만족못하는 경우
이런 부작용들은 접근을 잘 해야 한다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어모델을 따른다. 이것은 인풋 아웃풋이 확실하다. 하지만 소프트웨어는 경험적 프로세스 제어모델로 접근해야 한다. 경험적 프로세스 제어모델은 항상 불확실성을 수반한다.
'프로그래밍 > SoftwareEngineering' 카테고리의 다른 글
| [소프트웨어공학] 프로젝트 관리와 비용추정 (0) | 2017.04.09 |
|---|