소프트웨어 개발 방법론

많은 인터뷰에서 방법론에 대한 질문을 받게 될 것입니다. 이것은 가장 중요하거나 어려운 질문은 아니지만 치트 시트가 있으면 좋을 것입니다. 이 글에서는 개발 방법론이 무엇인지 전달하고 비교하려고 합니다. 소프트웨어 개발 방법론은 특정 제품을 개발하는 데 사용되는 프로세스입니다. 즉, 개발자 팀이 개발을 구성하는 한 가지 방법입니다. 다양한 개발 모델이 있으며 각 모델은 고유한 접근 방식을 정의합니다. 모든 프로젝트에 이들 중 누구라도 사용해야 한다고 말할 수는 없습니다. 올바른 접근 방식은 전적으로 상황에 따라 다릅니다. 나는 그들 중 세 가지를 더 자세히 고려할 것입니다.

폭포

폭포수 방법론은 가장 오래된 것 중 하나이며 엄격하게 순차적으로 구현됩니다. 각 단계는 다음 단계가 시작되기 전에 완료되어야 합니다. 즉, 다음 단계로의 전환은 이전 단계의 작업이 100% 완료되었음을 의미합니다. 그림은 작동 방식을 보여줍니다. 먼저 문제를 분석(작업 문서화, 문제 논의)한 다음 디자인(프로젝트 구조가 이 단계에서 구체화됨), 코딩 및 테스트를 수행합니다. 이전 단계로 돌아가는 것은 허용되지 않습니다. 이 접근 방식은 요구 사항이 미리 알려져 있고 변경 가능성이 없는 소규모 프로젝트에 권장됩니다. 이점:

• 각 단계에서 완전하고 일관된 문서화
• 사용의 용이성
• 안정적인 요구 사항
• 예산 및 기한은 사전 정의됩니다.

단점:

• 다량의 문서
• 매우 유연하지 않음
• 클라이언트는 제품의 데모 버전을 볼 수 없습니다.
• 뒤로 이동하는 옵션 없음

스크럼

스크럼은 전체 프로세스를 반복으로 나누는 소프트웨어 개발 방법론입니다. 각 상호 작용이 끝나면 팀은 제품의 데모 버전을 제공할 준비가 됩니다. 그림은 팀이 모든 개발 단계를 병렬로 진행하여 각 반복이 끝날 때마다 프로젝트의 완성된 부분을 가질 수 있음을 보여줍니다. 간단한 단어를 사용하여 방법론의 본질을 간략하게 설명하려고 노력하지만 많은 용어가 있습니다. 가장 중요한 것은 본질을 이해하는 것이라고 생각합니다. 경험을 통해 용어를 기억할 것입니다. 모든 개발은 스프린트 (보통 2~3주) 로 나뉩니다 . 백로그 가 있습니다.(작업 목록) 전체 개발 기간 및 각 개별 스프린트에 대해. 각 작업에는 자체 스토리 포인트(난이도 등급)가 있습니다. 프로세스의 각 참여자는 역할이 있습니다.

• 스크럼 팀은 프로젝트에 참여하는 전문가(개발자, 테스터, 디자이너)로 구성됩니다.
• 스크럼 마스터는 스크럼의 원칙이 존중되는지 확인하는 사람입니다.
• 제품 소유자는 고객입니다.

이 방법론은 의사 소통에 의존하므로 많은 수의 회의가 있습니다.

• 스탠드업 – 매일 열리는 짧은 회의로, 모든 팀원이 참여합니다. 각 참가자는 3가지 질문에 답합니다. 내가 무엇을 했습니까? 나는 무엇을 할 것인가? 그리고 어떤 차단 문제가 있습니까?
• 계획 회의 – 이 회의는 스프린트 시작 시 개최됩니다. 다음 스프린트에서 수행해야 하는 작업은 이 회의에서 식별됩니다.
• 회고 - 이 회의는 스프린트가 끝날 때 개최되며 그 목적은 잘 수행된 것과 개선할 수 있는 것을 식별하는 것입니다.

이점:

• 고객은 개발 과정에서 결과를 볼 수 있습니다.
• 개발 프로세스의 일일 모니터링
• 개발 중 조정 가능
• 모든 팀원과의 커뮤니케이션 확립
• 소량의 문서

단점:

• 개발에 필요한 인건비 및 기타 비용을 산정하기 어려움
• 개발 시작 전에 병목 현상을 식별하기 어려움
• 다른 팀 구성원의 작업에 모든 사람을 참여시킬 필요성.

칸반

Kanban은 팀의 작업 완료 과정을 시각화하는 방법입니다. 주요 아이디어는 현재 수행 중인 작업의 수를 줄이는 것입니다("진행 중" 열에서). 스크럼에서 팀은 스프린트를 성공적으로 완료하는 데 집중합니다. Kanban에서 작업은 탁월한 위치를 차지합니다. 이는 기본 기능이 이미 구현되었으며 최소한의 개선 및 버그 수정이 남아 있는 유지 관리 단계의 프로젝트에 좋습니다. Kanban에서는 작업이 개별적으로 할당됩니다. 작업은 다른 작업과 독립적으로 보드의 모든 단계를 거치며 완료되면 고객에게 표시될 수 있습니다. Kanban 보드는 열로 구성되며 각 열은 별도의 개발 프로세스를 나타냅니다. 일부 열(예: '진행 중' ) 보유할 수 있는 작업 수를 제한합니다. 이것은 작업 분배에서 문제 영역을 빠르고 쉽게 찾는 데 도움이 됩니다. 그림은 그러한 보드의 예를 보여줍니다. 열 수와 해당 이름은 다를 수 있습니다. 가장 일반적인 것을 제시하겠습니다.

• To Do – 수행해야 할 작업 목록
• 진행 중 – 현재 작업 중인 작업
• 코드 검토 – 완료되어 검토를 위해 제출된 작업
• 테스트 중 - 테스트 준비가 된 작업
• 완료 – 완료된 작업

이점:

• 사용의 용이성
• 가시성(병목 현상을 찾는 데 도움이 되고 이해를 단순화함)
• 프로세스 자체에 대한 높은 팀 참여
• 매우 유연한 개발

단점:

• 불안정한 작업 목록
• 장기 프로젝트에 적용하기 어려움
• 마감 기한 부족

소프트웨어 개발 방법론에 대한 마지막 말

관리직에 있거나 지망하는 사람들은 소프트웨어 개발 방법론을 철저히 이해해야 하지만 모든 사람이 최소한 기본 사항은 이해해야 합니다. 방법론은 개발 프로세스의 필수적인 부분이며 IT 영역에서만 사용되는 것이 아닙니다. 제 글을 읽어주셔서 감사합니다. 도움이 되었기를 바랍니다. 핵심 포인트만 최대한 알기 쉽고 간결하게 설명하려고 노력했습니다. 따라서 이 문서는 완전하지 않습니다. 나는 그것에 대한 귀하의 의견을 듣고 귀하의 질문에 답변하게되어 기쁩니다. 모두 제일 좋다!