폭포수 개발
이름 그대로 소프트웨어를 한 번에 한 단계씩 만들어가는 방식이다.
폭포수 개발의 SDLC는 순차적이다.
SDLC
소프트웨어를 개발하기 위해 요구사항 분석부터 소프트웨어 설계, 구현, 테스트, 배포, 유지 보수로 끝나는 일련의 과정이다.
요구사항 분석
개발할 소프트웨어에 필요한 요구사항을 전부 알아내는 단계.
무엇을 해야 할까? 어떤 기능이 있어야 할까? 어떻게 보이고 어떻게 동작해야 할까?
디자인
어떻게 만들지 알아낼 단계.
요구사항을 바탕으로 시스템 아키텍처를 설계하고, 저수준 알고리즘과 UML 다이어그램을 만들며 그 시스템을 어떻게 만들고 동작하게 할지 결정한다.
구현
코딩하는 단계. 앞서 한 설계를 코드로 바꾼다.
테스트
테스트 단계.
모두가 다음 단계로 넘어가도 좋다고 동의할 때까지 최대한 많은 버그를 수정한다.
배포
만든 작품이 실제 작동하는지 확인할 시간.
유지 보수
소프트웨어는 세상에 내보낸 후에도 계속 지원해야 한다.
고객이 찾아내는 버그를 고치고 새로운 기능을 추가한다.
애자일
12가지 원칙
- 우리는 가치 있는 소프트웨어를 빠르게 그리고 지속적으로 제공해서 고객을 만족시키는 것을 가장 중요하게 생각한다.
- 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해서 고객의 경쟁력을 높이는 데 기여한다.
- 새로운 소프트웨어는 몇 주나 몇 달의 주기로 자주 제공하라. 간격은 짧을수록 좋다.
- 프로젝트가 진행되는 동안 사업부서 사람들과 개발자는 매일 만나서 함께 일해야 한다.
- 의욕 있는 사람들 위주로 팀을 구성하라. 그들이 필요로 하는 환경과 지원을 제공하고 그들이 맡은 일을 완수할 거라고 믿어라.
- 개발팀으로, 혹은 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 서로 얼굴을 보고 하는 소통이다.
- 업무 진척을 측정하는 기본 척도는 작동하는 소프트웨어다.
- 애자일 프로세스는 지속 가능한 개발을 장려한다. 후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
- 기술적 우수성과 좋은 설계에 대한 꾸준한 관심이 기민성을 높인다.
- 해야 할 일의 양을 최소화하는 단순성이 꼭 필요하다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.
- 팀은 정기적으로 더 효과적으로 일할 방법을 고민하고 이를 통해 이른 결론에 따라서 팀이 어떻게 움직일지 조율하고 조정한다.
스크럼
1990년 대 초반 켄 슈와버와 제프 서덜랜드가 함께 만들었다. 두 사람은 1995년에 두 가지 방법론을 합쳐서 완성한 스크럼 방법론을 정의하는 공동 논문을 작성했다.
스크럼은 소프트웨어 개발팀의 특정 역할, 소프트웨어를 개발하는 작업 흐름, 개발의 반복 주기마다 여는 스프린트라고도 부르는 회의를 까다로운 규범에 따라 정의한 정형화된 방법론이다.
직책
스크럼에는 세 가지 주요 직책이 있다.
첫 번째, 제품 책임자
- 고객의 소리를 전달하고 작업의 우선순위를 결정하는 역할
- 사업과 관련된 나머지 사람들, 다른 이해 당사자, 고객과 소통하는 역할
두 번째, 개발팀
- 코드 작성 외에도 분석, 설계, 테스트 등 소프트웨어 배포와 관련된 모든 일
세 번째, 스크럼 마스터
- 팀이 하는 일을 지연시키는 장애물을 제거하고 제품 책임자와 소통하며 스크럼 프로세스가 문제없이 진행될 수 있게 돕는, 팀의 코치 역할
진행 방식
소프트웨어 개발을 스프린트라고 부르는 작은 반복 주기로 나눈다. 스프린트로 정해둔 기간 내에 해야 할 일의 양을 정하고 스프린트를 마칠 때마다 나오는 결과를 점진적으로 고객에게 전달한다.
소프트웨어를 위해 개발해야 할 모든 기능을 우선순위를 정해서 제품 백로그에 넣어둔다. 스프린트 백로그를 만들어 제품 백로그 항목 중 해당 스프린트에 작업할 항목을 모아둔다. 스프린트는 보통 1~2주 정도로 나뉜다.
매일 모든 팀원이 한데 모여 자신이 진행하는 업무에 대해 아주 짧게 공유하는 스크럼 회의를 연다. 업무 진행 상황을 전체 팀원과 공유하고 업무를 지연시키는 장애물을 제거하는 것이 스크럼 회의의 목적이다.
- 어제는 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 했는가?
- 오늘은 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 할 것인가?
- 본인이나 팀의 스프린트 목표 달성을 막는 장애물이 있는가?
업무 진행 상황과 속도를 추적하기 위해 소멸 차트를 쓴다. 소멸 차트는 남은 시간, 스토리 포인트, 업무 난이도를 비롯해 남은 업무의 양을 확인할 때 필요한 거라면 무엇이든 추적한다. 스프린트가 끝나면 스프린트가 진행되는 동안 완료한 목표를 이해 관계자에게 보여주는 리뷰를 수행한다.
마지막으로 지난 스프린트를 돌아보고 다음 스프린트에 대한 아이디어를 떠올리는 회고 회의를 연다.
칸반
칸반은 도요타 생산 체계와 린 제조 방식에 기원을 둔다. 원래 칸반은 제조 생산 업무를 제한해서 효율을 높이고 재고를 줄이기 위해 만들어졌다. 이를 소프트웨어 개발에 적용할 때는 칸반 보드에 주로 초점을 맞춘다.
칸반 보드는 칼럼으로 개발 프로세스가 진행되는 업무 단계를 표현한다. 병목현상이 발생하는 구간을 알아내서 제거할 수 있도록 프로젝트에서 해야 하는 일을 시각화하고, 동시에 진행하는 업무의 양을 제한하는 것이 핵심이다.
백로그나 해야 할 일을 적은 업무 목록을 만들고 우선순위를 정해둔다. 그러면 팀원들은 자신이 할 일을 고르고 이를 칸반 보드에 올린다. 업무가 단계별로 진행됨에 따라 보드에서도 위치를 옮긴다. 분석, 설계에서 시작한 업무가 개발, 테스트를 거쳐 마지막으로 배포로 옮겨갈 것이다. 하지만 그 사이에 다양한 단계나 방법이 존재할 수도 있고 새로운 방식으로 업무를 조직할 수도 있다.
익스트림 프로그래밍
XP라고도 불리는 이 방법론은 1996년 켄트 벡이 만들었다.
XP는 단위 테스트, 테스트 주도 개발, 객체지향 프로그래밍, 고객 중심 등 당시의 모범 사례를 많이 가져와서 극단의 경지라고 부를 수준까지 끌어올렸다.
XP 프로젝트의 개발 프로세스는 아주 빡빡한 원칙을 중심으로 진행된다. 스크럼 방법론과 유사하게 해야 할 일을 먼저 정한 다음 그 일의 완료 기준을 설정한다. 업무가 실제로 완료되면 테스트를 시작한다. 합격 판정 테스트에서 그 업무가 실제 완료되었는지 확인하기 위해 통과해야 하는 완료 기준을 정의한다. 실제 코드를 작성하기 전에 코드가 다양한 상황에서 해야 할 일을 정확히 정의하는 단위 테스트를 만든다. 그리고 실제 코드 개발은 이에 맞춰서 진행한다.
XP는 페어 프로그래밍에 크게 의존한다. 페어 프로그래밍이란 개발자 두 명이 함께 앉아서 공동으로 작업해 모든 코드를 함께 만드는 것이다. 미래보다는 현재의 필요를 염두에 두고 기능을 최대한 단순하게 설계해서 구현하는 것이 목표다.
