소프트웨어 개발 방법론

안녕하세요. 지난 두 번의 인터뷰에서 저는 방법론에 대한 질문을 받았습니다. 이것은 가장 중요하거나 어려운 질문은 아니지만 답변에 대한 치트 시트를 가지고 있으면 좋을 것입니다. 이 기사에서는 개발 방법론이 무엇인지에 대한 아이디어를 제공하고 개인적으로 만났거나 질문을 받은 방법을 비교해 보겠습니다. 소프트웨어 개발 방법론은 특정 제품이 어떻게 개발될지 설명하는 프로세스, 즉 팀 개발을 구성하는 방법 중 하나입니다. 이러한 프로세스에는 다양한 모델이 있으며 각 모델은 자체 접근 방식을 설명하며 그중 각 프로젝트에서 사용해야 하는 모델이 있다고 말할 수는 없으며 모든 것이 순전히 상황에 따라 다릅니다. 나는 그 중 세 가지를 더 자세히 고려할 것을 제안합니다.

폭포

폭포(계단식, 폭포)는 가장 오래된 방법론 중 하나이며 모든 단계의 엄격한 순차적 구현을 ​​의미하며 각 단계는 다음 단계가 시작되기 전에 완료되어야 합니다. 즉, 다음 단계로의 전환은 이전 단계의 작업이 완전히 완료되었음을 의미합니다. 그림은 먼저 작업을 분석하고(작업 문서화, 어려움 논의) 설계가 진행되고(이 단계에서 프로젝트 구조가 형성됨) 코딩 및 테스트를 수행하는 것을 보여줍니다. 후속 단계에 대해서는 환불이 없습니다. 요구 사항이 미리 알려져 있고 변경될 가능성이 거의 없는 소규모 프로젝트에서는 이러한 시스템을 사용하는 것이 좋습니다. 장점:

• 모든 단계에서 완전하고 일관된 문서화;
• 사용의 용이성;
• 안정적인 요구 사항.
• 예산과 마감일은 미리 정해져 있습니다.

결점:

• 많은 양의 문서;
• 매우 유연한 시스템은 아닙니다.
• 클라이언트는 제품의 데모 버전을 볼 수 없습니다.
• 한 단계 뒤로 돌아갈 방법이 없습니다.

스크럼

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

• 스크럼 팀은 프로젝트(개발자, 테스터, 디자이너)를 진행하는 팀입니다.
• 스크럼 마스터는 스크럼의 원칙이 준수되는지 확인하는 사람입니다.
• 제품 소유자 – 고객.

이 시스템에서는 의사소통에 중점을 두기 때문에 많은 집회가 있습니다.

• 스탠드업은 매일 열리는 짧은 회의로, 모든 팀원이 참여하고 각 참가자는 3가지 질문에 답합니다. 무엇을 했나요? 그것은 무엇을 할 것인가? 차단제는 무엇입니까?
• 계획 – 스프린트 시작 시 개최되며 이 회의에서 다음 스프린트에서 완료해야 할 작업이 결정됩니다.
• 스프린트가 끝날 때 회고전이 열리며 그 본질은 무엇이 잘되었고 무엇이 개선될 수 있는지 알아보는 것입니다.

장점:

• 고객은 개발 과정에서 결과를 관찰할 수 있습니다.
• 개발 프로세스를 매일 제어합니다.
• 개발 중에 조정하는 능력.
• 모든 팀원과의 원활한 커뮤니케이션.
• 소량의 문서.

결점:

• 개발에 소요되는 노동력과 비용을 추정하기 어려움
• 개발을 시작하기 전에 가장 큰 병목 현상을 파악하는 것은 어렵습니다.
• 다른 팀 구성원의 개발에 모든 사람을 참여시켜야 할 필요성.

칸반

칸반(Kanban)은 팀 작업 완료 프로세스를 시각화하는 데 기반을 둔 시스템입니다. 이 시스템의 주요 아이디어는 현재 수행 중인 작업("진행 중" 열)의 수를 줄이는 것입니다. 스크럼에서는 팀이 스프린트를 성공적으로 완료하는 데 초점을 맞추고 칸반에서는 작업이 우선입니다. 주요 기능이 이미 개발되었으며 최소한의 개선 사항과 버그 수정이 남아 있는 지원 단계의 프로젝트에 적합합니다. Kanban에서는 작업이 개별적으로 제출됩니다. 작업은 다른 작업과 관계없이 보드의 모든 단계를 거치며 완료되는 즉시 고객에게 표시될 수 있습니다. Kanban 보드는 열로 구성되며 각 열은 별도의 개발 프로세스를 나타냅니다. 일부 열(예: 진행 중)은 있을 수 있는 작업 수에 제한을 둡니다. 이는 작업 분배에서 문제 영역을 쉽고 빠르게 찾는 데 도움이 됩니다. 그림은 이러한 간단한 보드의 예를 보여줍니다. 열 수와 이름은 다양할 수 있지만 가장 일반적인 이름은 다음과 같습니다.

• To do - 해야 할 일 목록
• 진행 중 – 현재 진행 중인 작업
• 코드 검토 – 완료되어 검토를 위해 전송된 작업
• 테스트 중 – 테스트 준비가 완료된 작업
• 완료 - 완료된 작업입니다.

장점:

• 사용의 용이성.
• 시각화(병목 현상을 찾는 데 도움이 되고 이해가 단순화됨)
• 프로세스 자체에 팀 참여도가 높습니다.
• 개발 유연성이 높습니다.

결점:

• 불안정한 작업 목록.
• 장기 프로젝트에는 사용하기 어렵습니다.
• 엄격한 마감일은 없습니다.

소프트웨어 개발 방법론에 대한 결론

제 생각에는 관리직에 있거나 이를 지망하는 사람들은 소프트웨어 개발 방법론에 대한 철저한 이해가 필요하지만 최소한 기본 사항은 모두가 이해하는 것이 좋습니다. 이는 개발 프로세스의 필수적인 부분이며 IT 분야에서만 사용되는 것은 아닙니다. 시간을 내어 내 기사를 읽어주셔서 감사합니다. 도움이 되었기를 바랍니다. 최대한 명확하고 간략하게 핵심 내용만 설명하려고 했기 때문에 글이 완전하지는 않습니다. 이에 대한 귀하의 의견을 듣고 귀하의 질문에 답변해 드리겠습니다. 모두 제일 좋다!