개발 방법론

Updated:

소프트웨어 개발 방법론

최근 읽은 책인 ‘커리어 스킬’ 에는 방법론 내용의 시작을 다음과 같이 시작한다.

“글러브를 착용하고 링 안에 설 준비가 되었는가?”

전통적인 폭포수 Waterfall 개발


  • 폭포수 개발 방법론에는 소프트웨어 개발 생명주기(SDLC)가 포함되어 있다. SDLC란 소프트웨어를 개발하기 위해 요구사항 분석부터 시작해 소프트웨어 설계, 구현, 테스트, 배포, 유지 보수로 끝나는 일련의 과정을 가리킨다. 한 번에 한 단계식 앞으로 전진하고 절대 뒤로 가지 않는다. 각 단계 사이에는 겹치는 부분도 조금씩 있다.

폭포수 개발론의 문제

  • 폭포수 개발에서는 요구사항 변화가 문제가 된다. 더 정확히는 프로젝트 후반이 될 때까지 요구사항의 변화를 알 수 없다는게 문제다.

애자일


애자일은 확실한 형태가 없다. 애자일 자체를 방법론으로 보기는 어렵다. 아래는 애자일 선언문

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

스크럼

  • 애자일 개발 방법론 중 하나, 스크럼은 소프트웨어 개발팀의 특정 역할, 소프트웨어를 개발하는 작업흐름, 개발의 반복 주기마다 여는 스프린트 라고도 부르는 회의를 까다로운 규범에 따라 정의한 정형화된 방법론이다.
  • 스크럼 회의에서 각 팀원은 세가지 질문에 답해야한다.
    • 어제는 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 했는가?
    • 오늘은 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 할 것인가?
    • 본인이나 팀의 스프린트 목표 달성을 막는 장애물이 있는가?

스크럼 관련 문제

  • 스크럼이 성공적으로 구현되지 못하는 가장 큰 이유가 헌신이 부족해서다라라는 얘기가 있다. 제대로 수행하기만 한다면 스크럼은 소프트웨어를 매우 효과적으로 개발할 수 있게 해주지만 ..

Leave a comment