애자일과 애자일 방법론

폭포수 개발

폭포수처럼 각 단계가 위에서 아래로 물이 떨어지듯 차례대로 진행되어 이름이 붙여졌다.

한 단계가 끝나면 다음 단계로 내려가며 소프트웨어를 한번에 한 단계 씩 만들어나가는 방식이다. SDLC(Software Development Life Cycle, 소프트웨어 개발 수명 주기)를 순차적으로 따라간다. 애자일이 등장하기 전 개발 프로젝트 대부분은 폭포수 개발 방식을 사용했다.

• 계획 중심
  : 폭포수는 일에 필요한 모든 사항을 완벽하게 측정하여 계획을 수립한다.
• 마지막 단계에 테스트
  : 폭포수는 마지막 전까지 통합하지 않기 때문에 마지막까지 테스트할 수 없지만, 초기에 모든 것을 고려하여 계획을 세웠기 때문에 계획대로 진행한다면 버그는 없을 것으로 기대한다.
• 빅뱅 (Big Bang) 릴리즈
  : 요구사항을 제대로 따르면 모든 것이 기술적이고 기능적으로 잘 작동할 것으로 인식하기 때문에 통합을 빨리하거나 자주 하지 않는다.
• 미리 정의된 요구사항
• 고객과의 드문 의사소통

---

애자일

  애자일(Agile)이란 단어는 ‘날렵한’, ‘민첩한’이란 뜻을 가진 형용사로 애자일 개발 방식도 그 본래 의미를 따른다. 정해진 계획만 따르기보다, 개발 주기 혹은 소프트웨어 개발 환경에 따라 유연하게 대처하는 방식을 뜻한다.

• 점증적 개발
• 지속적으로 반영하는 요구 사항
  : 개발 도중에 요구사항이 변경, 추가될 수 있다.
• 고객과의 지속적인 의사소통
• 지속적인 테스트

  애자일 자체를 방법론으로 보기는 어렵다. 애자일은 소프트웨어 개발이 어떻게 이루어져야 하는지를 매우 높은 수준에서 정의하기 때문이다. 그보다는 애자일이라고 여겨지는 특성을 지닌 다른 여러 방법론의 부모 격이라고 볼 수 있다. 이는 애자일의 역사를 알아야만 이해할 수 있다.

  애자일은 유타주에 있는 로지 앳 스노버드 스키 리조트에서 시작되었다. 서로 다른 개발 방법론을 입안한 이들과 업계 선두주자 몇몇이 모여서 소프트웨어 개발이 어떤 방식으로 이루어져야 하는지에 대해 공통 기반을 찾으려 한 시도라고 볼 수 있다. 처음에 모인 인원은 17명이었다. 이들은 소트으웨어 개발에 영향을 미치는 몇가지 문제를 논의 하던 중 애자일 선언문을 만들었다.

 

 우리는 소프트웨어를 개발하고 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법을 찾아나가는 과정에 있다.
 이 작업을 통해 우리는 과정이나 도구보다 개인이나 상호작용을,
 포괄적인 문서보다 작동하는 소프트웨어를,
 계약 협상보다 고객과의 협력을,
 계획을 따르는 것보다 변화에 대응하는 것을 가치있게 여긴다는 결론에 이르렀다.
 이 말인즉 먼저 언급한 것도 가치가 있지만, 우리는 뒤에 언급한 것에 더 높은 가치를 둔다는 뜻이다.

 

이는 다음에 정의된 12가지 원칙을 기반으로 한다.

1. 우리는 가치 있는 소프트웨어를 빠르게 그리고 지속적으로 제공해서 고객을 만족시키는 것을 가장 중요하게 생각한다.
2. 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해서 고객의 경쟁력을 높이는 데 기여한다.
3. 새로운 소프트웨어는 몇 주나 몇 달의 주기로 자주 제공하라. 간격은 짧을수록 좋다.
4. 프로젝트가 진행되는 동안 사업부서 사람들과 개발자는 매일 만나서 일해야 한다.
5. 의욕 있는 사람들 위주로 팀을 구성하라, 그들이 필요로 하는 환경과 지원을 제공하고 그들이 맡은 일을 완수할 것이라고 믿어라
6. 개발팀으로, 혹은 개발팀 내에서 저보를 전달하는 가장 효율적이고 효과적인 방법ㅂ은 서로 얼굴을 보고 하는 소통이다.
7. 업무 진척을 측정하는 기본 척도는 작동하는 소프트웨어이다.
8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 우수성과 좋은 설계에 대한 꾸준한 관심이 기민성을 높인다,
10. 해야할 일의 양을 최소화하는 단순성이 꼭 필요하다.
11. 팀은 정기적으로 더 효과적으로 일할 방법을 고민하고 이를 통해 이른 결론에 따라서 팀이 어떻게 움직일지 조율하고 조정한다.
12. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.

---

 

❓ 애자일에서는 왜 자기 조직화(self-organizing)가 중요한 것일까?

 

  고객의 요구사항을 만족하기 위해서는, 끊임없이 변화하고 적응하고 발전하기 위해서는 고정된 목표도 고정된 능력이 아닌 상황에 맞게 모두가 변하고 모두가 노력해야 하는 모두가 공동의 노력으로 공동의 목표를 향해 가는 조직 이어야만 하기 때문이다.

 

Reference : 애자일의 핵심은 팀의 자기조직화

애자일의 핵심은 팀의 자기조직화

 

---

애자일 방법론 : 스크럼

스크럼은 1990년대 초반 켄 슈와버(Ken Schwaber)와 제프 서덜랜드(Jeff Sutherland)가 함께 만들어졌다. 두 사람은 1995년에 스크럼 방법론을 정의하는 공동 논문을 작성했다. 스크럼은 소프트웨어를 개발하는 작업 흐름, 개발의 반복주기마다 여는 스프린트라고 부르는 회의를 까다로운 규범에 따라 정의한 정형화된 방법론이다.

 

👉 스크럼 직책

1. 제품 책임자(PO, Product Owner)
   : 고객의 소리를 전달하고 작업의 우선순위를 결정하는 역할을 한다. 사업과 관련된 나머지 사람들, 다른 이해 당사자, 고객과 소통하는 역할도 한다.
2. 개발팀
   : 코드 작성 외에도 분석, 설계, 테스트 등 소프트웨어 배포와 관련된 모든 일을 맡는다.
3. 스크럼 마스터(Scrum master)
   : 팀이 하는 일을 지연시키는 장애물을 제거하고 제품 책임자와 소통하며 스크럼 프로세스가 문제 없이 진행될 수 있기 돕는, 팀의 코치 역할을 한다.

👉 스크럼 진행방식

  스크럼의 기본 아이디어는 소프트웨어 개발을 스프린트라고 부르는 작은 반복 주기로 나누는 것이다. 그리고 스프린트로 정해둔 기간 내에 해야 할 일의 양을 정해둔다. 그러면 각 스프린트를 마칠 때마다 나오는 결과를 점진적으로 고객에게 전달한다

  소프트웨어를 위해 개발해야 할 모든 기능을 제품 백로그에 넣어둔다. 제품 백로그에는 우선순위를 정해둔다. 각 스프린트마다 스프린트 백로그를 만들어 제품 백로그 항목 중에서 해당 스프린트에 작업할 항목을 모아둔다. 스프린트는 보통 1~2주 정도로 나뉜다. 각 스프린트가 시작될 무렵 계획 회의를 연다. 이 회의를 통해 그 스프린트에 처리한 백로그 항목을 정하고 그 백로그를 달성하기 위해 필요한 노력의 수준은 어떠한지 추산한다.

  매일 모든 팀원이 한데 모여 자신이 진행하는 업무에 대해 아주 짧게 공유하는 데일리 스크럼을 연다.이 회의는 서서 진행한다. 업무 진행 상황을 전체 팀원과 공유하고 업무를 지연시키는 장애물을 제거하는 것이 데일리 스크럼의 목적이다. 매일 같은 장소, 같은 시간에 열며 각 팀원은 세가지 질문에 답해야 한다.

1. 어제는 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 했는가?
2. 오늘은 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 할 것인가?
3. 본인이나 팀의 스프린트 목표 달성을 막는 장애물이 있는가?

  스프린트가 진행되는 동안 팀은 백로그에 있는 모든 항목을 수행하기 위해 함께 노력한다. 그리고 업무 진행 상황과 속도를 추적하기 위해 보통 소멸 차트를 사용한다. 소멸 차트는 남은 시간, 스토리 포인트, 업무 난이도를 비롯해 남은 업무의 양을 확인할 때 필요한 것이라면 무엇이든 추적한다. 스프린트가 끝나면 스프린트가 진행되는 동안 완료한 목표를 이해 관계자에게 보여주는 리뷰를 수행한다.

마지막으로 지난 스프린트를 돌아보고 다음 스프린트에 대한 아이디어를 떠올리는 회고 회의를 연다.

 

---

애자일 방법론 : 칸반

스크럼은 작업 흐름이나 조직 면에서는 정형화되고 규범이 까다로운 편인데 반해 칸반은 그렇지 않다. 칸반에 스크럼과 유사한 면이 있지만 훨씬 더 느슨하게 정의된 방법론이다. 그래서 구체적인 지시보다는 원칙에 의존한다.

칸반은 도요타 생산 체계와 린 제조 방식에 기원을 둔다.원래 칸반은 제조 생산 업무를 제한해서 효율을 좊이고 재고를 줄이기 위해 만들어졌다.

칸반 보드는 몇 개의 칼럼이 있는 간단한 보드인데, 개발 프로세스가 진행되는 업무 단계를 표현한다. 병목현상이 발생하는 구간을 알아내서 제거할 수 있도록 프로젝트에서 해야 하는 일을 시각화하고, 동시에 진행하는 업무의 양을 제한하는 것이 핵심이다, 동시에 진행하는 업무를 WIP(Work In Progress)라고 부른다.

 

 

---

애자일 방법론 : 익스트림 프로그래밍

익스트림 프로그래밍(XP, eXtream Programing)은 1996년 켄트 백(Kent Beck)이 만들었다. XP는 단위 테스트, 테스트 주도 개발, 객체지향 프로그래밍, 고객 중심 등 당시의 모범 사례를 많이 가져와서 극단의 경지라고 무를 수준까지 끌어올렸다. 그래서 이름도 익스트림 프로그래밍이다. 극단적이 엄격하다는 특징 때문에 그렇게 인기를 끌지는 못했지만 오늘날에도 여전히 쓰는 팀이 있다.

XP는 엄격한 원칙을 중심으로 진행된다. 스크럼 방법론과 유사하게 해야 할 일을 먼저 정한 다음 그 일의 완료 기준을 설정한다. 업무가 실제로 완료되면 테스트를 시작한다. 합격 판정 테스트에서 그 업무가 실제 완료되었는지 확인하기 위해 통과해야 하는 완료 기주능ㄹ 정의한다. 실제 코드를 작성하기 전에 단위 테스트를 만든다. 그리고 실제 코드 개발은 이에 맞춰서 진행한다.(TDD 느낌)

XP는 페어 프로그래밍에 크게 의존한다. 페어 프로래밍이란, 개발자 두 명이 함께 앉아서 공동으로 작업해 모든 코드를 함께 만드는 것이다. 미래보다는 현재의 필요를 염두에 두고 기능을 최대한 단순하게 설계해서 구현하는 것이 목표다. 시기상조 격으로 미리 최적화를 해둔다거나 당장 필요하지 않은 유연성을 제공하려고 하기보다 실제로 복잡한 상황이 발생했을 때 이를 코드가 처리할 수 있게 진화시키는 것이 핵심이다. 굳이 미리 해두려고 하면 보통은 복잡성이 증가하기 때문이다. 코드 공동 소유와 코딩 표준이라는 개념이 XP에서는 매우 중요하다.

 

---

 

Reference

커리어 스킬 (John Sonmez, 2019) CH27. 소프트웨어 개발 방법론

http://www.incodom.kr/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%B0%A9%EB%B2%95%EB%A1%A0

폭포수 방법론 - 인코덤, 생물정보 전문위키