Rapid Software Development
Rapid Development and Delivery는 사용자가 원하는 요구사항을 빠르게 만들어서 제공하는 개발 방법론이다. 물론 모든것을 한번에 만들진 못하므로 부분부분 만들어서 제공한다. 사용자의 바뀌는 요구사항에 빠르게 대처할 수 있다. 또한 계획을 많이 짤 필요가 없으므로 쓸모없는 문서 작업이 줄여지게 된다.
- 사용자나 동료들과 버전에 대한 확인을 하고 프로그램을 발전시킨다. 이걸 몇번에 거쳐서 한다.
- 프로그램을 새 버전으로 자주 발전시킨다.
- 광범위한 지원이 필요하다.
- 불필요한 문서 작업을 최소화 하는 대신 코드를 깔끔하게(clean code) 만든다.
Waterfall vs Agile
Agile Methods
- 탄생 배경
- Waterfall을 이용하는 기존의 방식은 일을 처리하는 데 시간이 너무 오래 걸렸다.
- 이런 처리 시간을 줄이기 위해서 요구사항 변화에 대한 대처가 빠르고 쓸모없는 시간을 안 쓸 수 있는 방법이 필요해졌다.
- 에자일 방법론
- 디자인보단 코드에 집중한다.
- 반복적인 접근을 기본으로 한다.
- 소프트웨어 개발을 빠르게 하고 발전시켜 바뀌는 요구사항에 대응하게 한다.
- Two types of Agile methods
- Agile Development Techniques
- Agile Project Management
Agile Manifesto(에자일의 마음가짐)
에자일은 폭포수 모델과 비교되는 특성들이 있다. 굵은 글씨는 에자일이고 취소선은 폭포수 모델이다.
- Individual over
processes and tools: 정해진 도구와 방법들을 쓰기보단 개개인에게 맡긴다 - Working software over
documentation: 문서화를 하기보단 코드를 깔끔하게 만든다. - Customer collaboration over
contract negotiation: 계약서를 만들기 보단 사용자와 협업한다. - Responding to change over
following a plan: 계획에 따라서 진행하기보단 변화에 따라 진행한다.
Principles of Agile Methods
Applicability of Agile Methods
에자일 방법론은 다음과 같은 프로젝트에 적합하다.
- 작거나 중간 사이즈의 결과물을 만들어서 판매한다.
- 이러한 특성 때문에 대부분의 소프트웨어 개발에서 에자일을 사용한다.
- Customer(요구자, 사용자)가 개발하는 과정에 참여할 수 있다.
- customer가 개발하는 옆에서 요구사항을 말해준다.
- 중간에 참여하여 내 의도와 다르게 만들어지고 있는 프로그램을 바로 잡아줄 수 있다.
Agile vs DevOps
Agile Development Techniques
Extreme Programming(XP)
Extreme Progamming은 반복적인 개발에 대한 '극단적인'접근이다.
- 새로운 버전이 하루에 수십개씩 나온다.
- 2주마다 사용자에게 반복적인 개발 결과를 보내 확인받는다.
- 모든 빌드에 대해서 모든 테스트가 수행이 된다. 모든 테스트를 통과한 빌드만 통과한 빌드가 된다.
XP principles
- 많은 시스템들의 도움을 받아서 반복적으로 개발한다.
- 사용자가 팀에 참여한다.
- pair programming을 통해서 팀적으로 만든다.
- regualar system release가 변경을 보조한다.
- 기능을 유지하면서 코드를 refactioring한다.
- Incremental planning : 처음부터 다 짜놓는 것이 아니다. 반복적으로 계획을 짜면서 그때그때 수행한다.
- Test-first development : 특정한 기능의 구현이 끝났으면 바로 테스트를 해봐야 한다. 테스트가 잘 끝나야지만 다음 과정으로 간다.
- Refactoring : 이미 짜여진 코드의 기능을 유지하면서 더 깔끔한 코드로 바꾼다.
- Pair programming : 짝을 이루어서 개발을 한다. 이 짝은 계속 바뀌면서 서로의 코드를 확인한다. 이전에 개발했던 사람에게 도움을 받는다. 이런 과정을 통해 자기가 짠 코드에 대한 이해가 높아지고(높아져 있어야한다. 그래야만 다른 개발자에게 코드를 설명할 수 있으므로) 코드 전체의 신뢰도가 높아진다.
- Continuous Intergration : 내가 맡은 일이 끝나면, 그것은 한번의 반복(Integrate)이 끝난 것이다. 이런 반복들이 모여서 프로그램이 만들어진다. 각각의 반복들 사이에는 unit test가 실행되며 통과해야한다.
- Sustainable pace : 사람이 하는 일이기 때문에 너무 빠르고 힘들게 하면(high pace) 일을 관두어 버릴 수 있다. 너무 느리게 하면(low pace) 일이 진전이 안 되고 개발 과정이 서로 맞지 않을 수 있다. 적절한 속도를 유지해야 한다.
- On-site customer : 사용자가 직접 참여하여 요구사항을 전달하고 잘 되는지 확인한다.
XP in Practice
XP 방법론은 잘 쓰이지는 않는다. 개발자한테 굉장히 의지하게 되며, project management를 하는데 문제가 생길 수 있다. 이러한 단점을 극복하기 위해 아래의 방법들과 같이 사용한다.
1. User stories for specification
2. Refactoring
3. Test-first development (TFD)
4. Pair programming
1. User stories for specification
아무런 기록도 저장하지 않는 것은 별로 좋은 방법은 아니다. 사용자의 요구사항를 스토리나 시나리오로 작성한다. 요구사항들을 시간 순서대로 적어놓음으로써 간략하게마나 기록해놓는다. 굳이 많은 정보를 기록하지 않으면서 해결할 중요 부분들을 정리할 수 있다.
2. Refactoring
코드를 쉽게 알아보기 위해 고치는 행위를 의미한다. 쉽게 알아볼 수 있게 함으로써 유지보수가 수월해지고 다른 사람이 봐도 쉽게 고칠 수 있다. 이런 코드를 clean code(클린코드)라고 한다.
리펙토링할때 중요한 건 기능이 변하면 안된다. 코드를 쉽게 알아보도록 고치다보면 기능이 바뀌는 경우가 종종 있다. 이를 방지하기 위해 Unit Test가 동반되곤 한다.
3. Test-first development (TFD)
모든 변화에는 테스트가 동반되어야 한다. 내가 변경한 코드 하나가 프로그램을 어떻게 바꿔놓을 지 모르므로 사소한 변화 하나라도 테스트를 통해 문제가 없는지를 확인한다.
TFD는 어려움이 따른다.
- 어느 정도까지 테스트를 해야하는지를 정해야하는데 정확히 결정할 수 없다.
- 어떤 테스트는 난이도가 높다.
- 많은 시간이 들어간다.
이런 어려움을 극복하기 위해 자동화된 테스트를 진행한다.
CTIP(Continuous Testing and Integration Platform)를 사용하면 각 분야마다 자동화된 테스트를 진행할 수 있다.
Test-Driven Development(TTD)
테스트는 데이터로 실행하는 것 보다 프로그램으로 실행하는 게 좋다. 자동으로 실행할 수 있기 때문이다. 이 자동화된 테스트가 모두 정상적으로 실행될 때 까지 코드를 고치면 된다
Customer Involvement
사용자는 XP의 한 부분을 담당한다. 사용자가 참여함으로써 테스트는 쓸데 없는 부분을 줄일 수 있고 문서 작성 작업이 많이 사라지게 된다. 그러나 사용자는 개발자에 비해 항상 참여할 수 없으므로 중요할 때 참여해야한다.
4. Pair programming
특정한 일을 한명이 하는 게 아닌 여러명이서 한다. 짝지어서 프로그래밍을 하며, 짝을 계속 바꾼다.
- 코드에 대한 동일한 이해를 할 수 있으며 모든 코드에 대한 어느 정도의 이해가 가능하다.
- 많은 사람들이 참여하므로 잘못 짜여진 코드를 줄일 수 있따.
- 마치 한 사람이 코드를 짠 것처럼 코드간의 통일성을 유지할 수 있다.
- 리팩토링(refactoring)이 수월해진다.
Agile Project Management
개발 프로세스 자체를 관리하는 방법이다. 개발 방법론보단 비즈니스 모델에 가깝다. 에자일을 할 때 고려해야 할 여러가지 요소들을 관리한다. 돈, 시간, 인적 자원, 스트레스 관리 등이 포함된다.
Scrum
스크럼은 iterative development를 할 때 에자일을 사용하는 방법이다. 날마다 짧은 회의를 하여 정보, 문제점을 공유하고 계획을 새운다. 회의를 통해 현재의 중요한 부분과 문제점을 모두가 파악하고 빠르게 수정함을 목표로 한다.
- Initial phase : 계획을 세우고 어떻게 디자인할지를 설계한다.
- A series of sprint cycles : 개발한다.(각 sprint마다 2~4주)
- Project closire phase : 프로그램을 정리하고 문서 작성을 완료한다.
어디까지 했는지 보고한다 -> 다음 할 일과 계획을 수립한다. -> 개발한다. -> 개발한 결과물을 검토한다.
