소프트웨어 개발 방법론에 대해 알아야 할 모든 것: 초보자를 위한 경향, 원칙 및 함정

소프트웨어 개발은 ​​복잡한 비즈니스 프로세스입니다. 즉, IT 전문가는 최적화, 계획 및 비용 계산의 언어를 구사해야 합니다. 관리 개념에 대한 이해는 고용주와 개발자 모두에게 큰 이점을 제공하고 협업을 다음 단계로 끌어올리는 데 도움이 됩니다.

주의, 초보자! 모델, 방법론 및 일반적인 혼란

시작하려면 중요한 설명이 필요합니다. 소프트웨어 개발 모델과 소프트웨어 개발 방법론은 별개의 별개의 것입니다. 모델은 시스템이 어떻게 작동할지 예측합니다. 시스템이 제대로 작동하려면 방법론이 필요합니다. 혼란스러운 소프트웨어 개발 모델과 방법론은 모든 IT 초보자를 위한 표준 운영 절차이므로 큰 실수로 간주되지 않습니다. 모델의 예로는 선형 진행, 각 단계의 목표에 대한 명확한 정의, 마감일에 대한 엄격한 제어가 있는 고전적인 폭포수 모델이 있습니다. 또 다른 모델은 나선형 모델 입니다., 프로젝트 위험의 조기 감지 및 완화에 중점을 둡니다. 나선형 개발은 작게 시작하여 먼저 지역 문제를 해결한 다음 더 복잡한 문제로 진행합니다. 마지막으로 또 다른 모델은 IID(반복 및 증분 개발) 로, 여기서 프로젝트 수명 주기는 각각 "미니 프로젝트"와 유사한 일련의 반복으로 나뉩니다. 일반적으로 모델은 소프트웨어 개발 프로세스에 대한 설명입니다 . 그러나 방법론은 할당된 작업에 대한 작업을 제어, 평가 및 모니터링하는 시스템입니다.. 방법론은 개발 프로세스의 각 단계를 제어하는 ​​데 필요한 현대 시대의 채찍과 당근입니다. 그들은 프로젝트의 방향, 예산 및 최종 제품 구현 마감일에 따라 선택됩니다. 또한 프로젝트 리더와 팀의 기질에 따라 방법론을 선택할 수 있습니다. 회사 또는 고객의 철학을 기반으로하더라도. 가장 널리 사용되는 방법론을 살펴보겠습니다.

1. 스크럼

Scrum은 민첩한 프로젝트 관리 방법 입니다.. "스프린트" 또는 짧은 반복을 기반으로 하며 시간이 엄격하게 제한됩니다(보통 2-4주). 이렇게 하면 회의 시간이 최소화되지만 빈도는 증가합니다. 각 스프린트는 반복이 끝날 때까지 완료해야 할 작업 목록으로 구성되며 각 스프린트에는 자체 "가중치"가 있습니다. 회의 중에 팀은 팀원이 무엇을 했는지, 무엇을 할 계획인지, 어떤 문제가 있는지 논의합니다. 스크럼은 계획을 위해 백로그를 사용합니다. 이 접근 방식에서 팀에는 일반적으로 스크럼 마스터가 있습니다. 이 사람은 팀이 중단 없이 일할 수 있도록 돕고 팀을 위한 편안한 환경을 만듭니다. 프로젝트에는 제품 소유자 역할을 하는 사람도 있습니다. 이 사람은 개발 책임자이며 제품을 모니터링하고 고객이 요청한 것과 팀이 생산하는 것 사이의 주요 연결 고리 역할을 합니다.

장점:

• 가능한 가장 낮은 예산으로 프로젝트를 신속하게 시작하는 능력;
• 일일 진행 상황 모니터링, 빈번한 프로젝트 데모;
• 프로젝트 중에 조정하는 기능.

단점:

• 고정 예산 부족으로 인한 계약 체결의 어려움;
• 경험이 부족한 팀이나 마감일 또는 예산이 과소 평가된 경우에는 작동하지 않습니다.
• 스프린트 간에 지속적으로 변경하는 기능은 혼란을 야기할 수 있습니다.

누구를 위한 것입니까?

이와 같은 시스템은 독립적이든 대기업 내에 존재하든 최대 10명의 프로젝트에 적합합니다. 이는 팀이 많은 양의 작업과 새로운 시장 조건에 적응하고 변경해야 하는 수명 주기가 긴 경우에 편리합니다.

2. 칸반

Kanban의 가장 중요한 기능은 프로젝트 수명주기의 시각화 입니다.. 작업 항목 수행을 위한 열이 생성됩니다. 작업 항목은 개별적으로 처리됩니다. 열에는 할 일, 진행 중, 코드 검토, 테스트 중, 완료와 같은 상태가 표시됩니다(물론 열 이름은 다를 수 있음). 각 팀원의 목표는 첫 번째 열의 작업 항목 수를 줄이는 것입니다. Kanban의 접근 방식은 직관적이며 문제가 있는 위치를 이해하는 데 도움이 됩니다. Kanban의 구조는 명확하고 취소 불가능하게 고정되어 있지 않습니다. 프로젝트의 세부 사항에 따라 즉석 열을 추가할 수 있습니다. 예를 들어 일부 팀에서는 작업 항목을 수행하기 전에 완료 규칙을 정의해야 하는 시스템을 사용합니다. 이 경우 지정(매개 변수 지정) 및 구현(작업 시작)의 두 열이 추가됩니다.

장점:

• 계획의 유연성. 팀은 현재 작업에만 집중하고 작업의 우선 순위도 정의됩니다.
• 시계. 모든 참가자가 데이터에 액세스할 수 있으면 글로벌 문제를 더 쉽게 파악할 수 있습니다.
• 개발 프로세스에 대한 높은 참여. 프로세스를 시각화하면 자기 조직화와 자기 통제력이 향상됩니다.

단점:

• 5명 이상의 팀과 함께 일하지 않습니다.
• 장기 계획을 위한 것이 아닙니다.
• 의욕이 없는 팀에는 적합하지 않습니다. Kanban에는 모든 작업 항목에 대한 기한이 없습니다. 또한 방법론은 지연에 대한 벌칙을 규정하지 않습니다.

누구를 위한 것입니까?

Kanban은 팀이 성장하고 결과를 달성하려는 동기가 있는 회사에서 잘 작동합니다. 이것은 이미 명백해야 합니다. 이것은 소규모 팀을 위한 것입니다. 아마도 분리 또는 팀의 일부일 수도 있습니다.

3. 합리적인 통합 프로세스(RUP)

RUP 방법론은 반복 개발 모델을 사용합니다. 각 반복(2주에서 6주 소요)이 끝날 때마다 팀은 계획된 목표를 달성하고 일시적이긴 하지만 작동하는 프로젝트 버전을 얻어야 합니다. RUP는 프로젝트를 4단계로 나눌 것을 요구합니다 . 각 단계에서 차세대 제품에 대한 작업(시작, 정교화, 구성 및 전환)이 수행됩니다. 단계가 끝나면 프로젝트 이정표가 달성됩니다. 팀이 결과를 평가하는 순간은 프로젝트 이정표로 간주될 수 있습니다. 이것은 방법론이 첫 번째 단계에서 주요 기능이 릴리스되고 후속 단계에서 추가가 추가됨을 의미합니다.

장점:

• 고객과 작업 과정에서 발생하는 변경 사항 모두에서 변경되는 작업을 처리할 수 있습니다.
• 제품의 지속적인 개선을 보장합니다. 반복하는 동안 프로젝트를 꼼꼼하게 평가할 수 있습니다.
• 작업 초기 단계에서 위험을 식별 및 제거하고 개발 품질을 효과적으로 제어할 수 있습니다.

단점:

• 이 방법론은 소규모 팀이나 회사에서 구현하기 다소 복잡하고 어렵습니다.
• 전문가의 작업 설정 능력에 따라 달라집니다.
• 요구 사항에 대한 과도한 문서화가 필요합니다.

누구를 위한 것입니까?

제품을 가능한 한 빨리 릴리스해야 하는 경우 명확하게 설정된 요구 사항과 잘 이해되는 위험이 있는 대규모 프로젝트입니다. 기능을 희생하더라도 틈새 시장을 빠르게 차지하고 나중에 마무리 작업을 추가하기 위해.

많은 방법론이 있지만 하나의 트렌드

부정할 수 없이 대중적이고 애자일 원칙 에 기반한 스크럼과 칸반 뿐만 아니라 견고하고 반복적인 RUP 방법론 외에도 회사에서는 다양한 방법론을 사용합니다. 한 회사는 익스트림 프로그래밍에 더 가깝고 가장 빠르고 간단한 결정을 내릴 수 있습니다. 또 다른 방법은 테스트 주도 개발에 더 가깝습니다. 또 다른 사람은 RAD(Rapid Application Development)를 여전히 선호할 수 있습니다. 즉, 여러 방법론을 동시에 사용하는 강력하고 확실한 추세가 있습니다.. 또는 모델과 방법론을 고유한 관리 시스템으로 결합할 수도 있습니다. 오늘날의 기업은 부서와 조직 단위 간에 책임을 전가하지 않고 관료적 장벽을 제거하고 조직 내에서 통합된 팀워크 분위기를 조성하기 위해 노력합니다. 스크럼 얼라이언스 에 따르면, IT 회사의 70%가 스크럼을 사용합니다. 그 중에는 Google, Amazon, Salesforce, Microsoft 및 Adobe와 같은 거대 기업이 있습니다. 신생 기업과 신생 프로젝트는 Kanban에 더 관심이 있지만 Toyota와 예를 들어 Wargaming의 게이머도 Kanban을 사용합니다. Scrum은 계획 도구이고 Kanban은 진행 상황을 모니터링하기 위한 것입니다. RUP의 경우 직원이 50~200명이고 매출이 100만~1000만 달러인 서구 기업에서 가장 많이 사용합니다. 그러나 IBM은 RUP를 수정하여 애자일 원칙에 더 가깝게 이동하여 OpenUP 방법론(RUP, 그러나 애자일)을 발표했습니다. 이 자랑스러운 애자일 방법론은 이제 IT 세계를 주도하고 있습니다 . 이것은 일시적인 유행이 아니라 여전히 혁신적이며 실제로 많은 대기업에서 활용되고 있습니다. 애자일은 실리콘 밸리에서 사용됩니다. 페이스북과 우버가 사용합니다.

결론

각 프로젝트에는 팀, 자금 지원, 기한 및 고객 요구 사항에 따라 고유한 소프트웨어 개발 방법론이 있습니다. 보편적인 관리 기술은 없습니다. 널리 사용되는 애자일 방법론도 개발 프로세스에 대한 최상의 접근 방식을 보장할 수 없습니다. 결과적으로 방법론은 때로는 원칙에 따라 신중하게 선택됩니다. 방법론을 살펴봄으로써 회사 자체 또는 고객에 대한 결론을 도출할 수 있습니다. 방법론이 혼합되고 모델로 보완되며 조정됩니다. 새로운 접근 방식을 제공합니다. 즉, 관리 영역은 궁극적으로 스크럼과 칸반의 손에 남아 있으며 폭포수 모델 또는 반복적인 RUP 방법론의 예상치 못한 요소가 있습니다.