이 포스팅은 Development Method 시리즈 10 편 중 3 번째 글 입니다.

  • Part 1 - 01: Problem Definition
  • Part 2 - 02: Select Right Language and IDE
  • Part 3 - This Post
  • Part 4 - 04: Design by figure
  • Part 5 - 05: Select Right OS
  • Part 6 - 06: Software Maintenance
  • Part 7 - 07: Test and Enhancement
  • Part 8 - 08: Design Pattern
  • Part 9 - 09: Open Source Licence
  • Part 10 - 10: Project Planning and Management
▼ 목록 보기

소프트웨어 개발 방법

  • 과거 - Software
    • 소프트웨어 자체가 목적
      • Office
      • 한글
      • Photoshop
      • Game(CD)
    • 긴 개발 과정
    • 많은 인력, 돈
    • 데드라인이 중요
  • 현재 - Service
    • 서비스가 목적
      • Search Service
      • Free Game with Pay items
      • 카카오 실시간 메신저
      • Ad based Free Services
    • 가능한한 빨리 (일간, 주간 월간)
      • 경쟁 심화
      • 제한된 인력과 돈
      • 시장의 요구사항을 맞춰야 함

Waterfall

스크린샷 2021-04-30 오전 12 26 18

  • 요구사항 분석
  • 디자인
  • 개발
  • 테스팅
  • 유지/보수

  • 장점
    • 코딩하기 전에 많은 고민
    • 많은 문서가 발생
    • 이를 통해 개발이 편리
    • 새로운 팀원이 와도 업무 인수인계 가능
    • 서로와의 이해가 힘든 문제도 해소 가능
  • 단점
    • 문서 너무 많아
    • 고민 모두 하는 것 불가능함
    • 빠른 속도 불가능
    • 계속해서 바꿔야 하는 경우가 비일비

Agile

Agile이라는 단어는 많이 쓰지만 정작 제대로된 이해는 부족한 경우가 많다. Agile의 핵심은 원리, 가치, 원칙에 더 가깝다. 프로젝트에 참가하는 팀이 어떠한 신념을 가지고 일을 진행시키겠냐는 약속에 가까운 것이다. 프로젝트를 진행하게되면 의사 결정의 순간에 팀만의 가치 우선순위가 없을 경우 일을 진행시키는 것이 매우 어렵다. 이러한 부분에서 Agile 원칙이 한가지 예로 존재하는 것. 아래에 서술할 Agile 개발 방법론으로부터 이 개념은 파생되어, 무언가 좋은 제품을 만드는데 있어서 빠르고, 낭비없이 만드는 원칙과 같은 관용어로 사용하게 되었다.

Agile의 전제

세상에 확실한 것은 아무것도 없다.

고객도 자신이 원하는 바를 정확히 모른다.

Agile menifesto

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.

이 작업을 통해 우리는 다음을 가치있게 여기게 되었다:

  • 공정과 도구보다 개인과 상호작용
  • 포괄적인 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응하기

가치있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

Agile Principles

  • 우리의 최우선 순위는 귀중한 소프트웨어를 조기에 지속적으로 제공하여 고객을 만족시키는 것입니다.
  • 개발 후반에도 변화하는 요구 사항을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
  • 짧은 기간을 선호하여 2 주에서 2 개월까지 작업 소프트웨어를 자주 제공합니다.
  • 비즈니스맨과 개발자는 프로젝트 전체에서 매일 함께 작업해야합니다.
  • 동기 부여 된 개인을 중심으로 프로젝트를 구축하십시오. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수 할 수 있도록 신뢰하십시오.
  • 개발 팀과 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
  • 작업 소프트웨어는 진행 상황의 주요 척도입니다.
  • 애자일 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 무한정 일정한 속도를 유지할 수 있어야합니다.
  • 기술적 우수성과 우수한 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.
  • 단순성 (완료하지 않은 작업량을 극대화하는 기술)은 필수적입니다.
  • 최상의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다.
  • 정기적으로 팀은 더 효과적인 방법을 고려한 다음 그에 따라 행동을 조정하고 적용합니다.

왜 사용하는가?

agile 방법론의 태동은 기존의 소프트웨어 방법론에서 발생한 문제점으로 부터 시사되었다. 계획에 의존하는 경우는 형식에 얽매이게 되고, 빠르게 방향을 변경하는 것이 어렵다. 그와 반대로 계획이 없는 경우 앞으로의 일을 예측하기 힘들고 효율적이지 못하다. 이러한 두가지 방법론 사이에서 타협을 찾았다고 볼 수 있다.

가장 큰 변화는 documentation보다 code를 기반하도록 변경된 것이다. 일정한 주기를 가지고 프로젝트의 생명 주기가 끝나기 전까지 그때 그때 고객과의 소통을 통해 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발하는 방법이다.

Scrum이란?

imageFootball Scrum

스크럼은 럭비에서 진형을 갖추고 있는 모습을 말한다. 이 그림을 보면 팀단위로 똘똘뭉쳐서 하나의 목표를 달성하기 위해 진형이 구축되어 있다. 스크럼 개발 방식은 이 주도적인 팀 수행이 핵심이다.

Agile 가치를 기반으로 실행할 수 있는 Framework중 하나이다. 가치를 말하는 Agile을 이러한 틀을 기반으로 진행시키면 쉽게 할 수 있다를 제안한다. 사실 이 방법이 매력적인 이유는 보통 소규모 프로젝트를 진행했을 때 팀단위가 3~10명 사이이기 때문이다. 쉽게 회의를 진행할 수 있고, 그렇기 때문에 의사소통이 편하다.

Agile Tools

  • 포스트잇
  • 칸반 보드
  • open project

DevOps

  • 개발 팀과 운영 팀으로 나뉨
  • 개발 팀
    • 하이 테크를 기반으로 개발하는데 집중
  • 운영 팀
    • 가장 안정적으로 서비스를 제공
  • Scrum 개발 방법론에서 개발이 빠르게 진행된다면 운영 팀 입장에서는 좋아할 수 만은 없는 일
  • 검증을 해야한다.
  • 안정적인 것도 맞되, 먼저가 되어야 하는 것은 서비스 사용자가 원하는 것
  • 사실 철학에 보다 가까운 것.
  • 서비스 빌드, 테스팅 - 빌드를 자동화
  • 많은 도구들의 등장
  • DevOps는 연봉 높다.
  • 개발, QA(품질관리), Operations이 모두를 관장하는 위치

image

image