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

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

초보자를 위한 참고 사항: 모델, 방법론 및 일반적인 혼란

우선 중요한 설명은 소프트웨어 개발을 위한 별도의 모델과 바로 이 개발을 위한 별도의 방법론이 있다는 것입니다. 모델은 시스템의 미래 동작을 예측합니다. 시스템이 필요한 방식으로 작동하려면 방법론이 필요합니다. 소프트웨어 개발 모델과 방법론을 혼동하는 것은 모든 IT 초보자의 신성한 작업이므로 이는 심각한 실수로 간주되지 않습니다. 그럼에도 불구하고 모델은 선형성, 각 단계에 대한 명확한 목표 설정 및 마감일에 대한 엄격한 제어를 갖춘 고전적인 계단식 폭포 입니다. 모델은 프로젝트 위험의 조기 식별 및 완화에 중점을 둔 Spiral 모델입니다. 나선형 개발은 소규모로 시작하여 먼저 지역 문제를 해결하고 그 다음에는 더 복잡한 문제를 해결합니다. 최종 모델은 IID 로 , 프로젝트 수명 주기를 일련의 반복으로 나누며 각 반복은 "미니 프로젝트"와 유사합니다. 일반적으로 모델은 소프트웨어 개발 프로세스를 설명하는 것입니다 . 그러나 방법론은 할당된 작업에 대한 작업을 제어, 평가 및 모니터링하기 위한 시스템입니다. 방법론은 개발 프로세스의 모든 연결을 제어하는 ​​데 필요한 현대 개발의 당근과 채찍입니다. 프로젝트 방향, 예산, 최종 제품 출시 시기를 기준으로 선택됩니다. 또한 프로젝트 관리자와 팀의 기질에 따라 방법론을 선택할 수 있습니다. 회사나 고객의 철학에 따라서도 말이죠. 가장 널리 사용되는 방법론을 살펴보겠습니다.

1. 스크럼 방법론

스크럼은 민첩한 프로젝트 관리 방법 입니다 . 이는 "스프린트"(일반적으로 2~4주)로 시간이 엄격하게 제한된 짧은 반복을 기반으로 합니다. 회의 기간은 최소한으로 줄어들지만 빈도는 늘어납니다. 각 스프린트는 반복이 끝날 때까지의 작업 목록으로 구성되며 각 작업에는 고유한 "가중치"가 있습니다. 회의 중에 팀은 누가 무엇을 했는지, 무엇을 할 것인지, 어떤 문제가 있는지 논의합니다. 스크럼은 계획을 위해 스프린트 저널을 사용합니다. 이 접근 방식에서는 전체 팀의 지속적인 작업을 설정하고 편안한 조건을 만드는 스크럼 마스터가 팀에 자주 등장합니다. 또한 프로젝트에서는 제품 소유자의 역할, 즉 개발 관리자, 제품을 모니터링하고 고객의 요청과 팀 결과 사이의 주요 연결 고리 역할을 하는 사람이 나타납니다.

장점:

• 가능한 가장 낮은 예산으로 빠른 프로젝트 시작;
• 작업 진행 상황을 매일 모니터링하고 프로젝트를 자주 시연합니다.
• 프로젝트가 진행됨에 따라 변경하는 능력.

단점:

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

누구에게 적합합니까?

이 시스템은 최대 10명(독립 또는 대기업 내부)의 프로젝트에 적합합니다. 이는 팀의 작업량이 많고 수명 주기가 길어서 새로운 시장 상황에 적응하고 변화해야 하는 경우에 편리합니다.

2. 칸반 방법론

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

장점:

• 계획 유연성. 팀은 현재 작업에만 집중하고 작업의 우선순위도 결정합니다.
• 시계. 모든 행위자가 데이터에 접근할 수 있게 되면 글로벌 문제를 더 쉽게 알아차릴 수 있습니다.
• 개발 과정에 대한 높은 참여. 프로세스 시각화는 자기 조직화와 자기 통제력을 향상시킵니다.

단점:

• 5명 이상의 팀에서는 작업하지 않습니다.
• 장기 계획을 위한 것이 아닙니다.
• 동기 부여 없이 팀에서 일하는 데는 적합하지 않습니다. 칸반에서는 각 작업에 정해진 기한이 없으며, 방법론에서는 지연에 대한 페널티를 제공하지 않습니다.

누구에게 적합합니까?

Kanban은 팀이 결과를 개발하고 달성하려는 동기를 부여받는 회사에서 훌륭하게 작동합니다. 이미 분명한 것처럼 소규모 팀입니다. 아마도 부서나 팀의 일부일 수도 있습니다.

3. RUP 방법론

RUP 방법론은 반복 개발 모델을 사용합니다. 각 반복(2~6주 소요)이 끝날 때마다 팀은 계획된 목표를 달성하고 임시이지만 작동하는 프로젝트 버전을 보유해야 합니다. RUP에는 프로젝트를 4단계로 나누는 작업이 포함되며 , 각 단계에서는 프로젝트 시작 단계, 개선, 구성 및 구현 등 차세대 제품에 대한 작업이 수행됩니다. 단계가 끝나면 단계 완료 표시(프로젝트 마일스톤)가 입력됩니다. 프로젝트 마일스톤은 팀이 달성한 결과를 평가하는 순간으로 간주될 수 있습니다. 결과적으로 이 방법론은 첫 번째 단계에서 주요 기능이 출시되고 후속 단계에서 추가 기능이 추가된다는 것을 의미합니다.

장점:

• 고객과 작업 과정에서 발생하는 변화하는 작업에 대처할 수 있습니다.
• 제품의 지속적인 개선을 보장합니다. 반복하는 동안 설계를 면밀히 조사할 수 있습니다.
• 작업 초기 단계에서 위험을 식별하고 제거할 수 있을 뿐만 아니라 개발 품질을 효과적으로 제어할 수 있습니다.

단점:

• 소규모 팀이나 회사에서는 구현하기 어려운 다소 복잡한 방법입니다.
• 작업을 설정하는 전문가의 능력에 대한 의존성;
• 요구 사항에 대한 과도한 문서화가 필요합니다.

누구에게 적합합니까?

명확하게 정의된 요구 사항과 정의된 위험이 있는 대규모 프로젝트에서 제품을 최대한 빨리 출시해야 합니다. 기능을 희생하더라도 틈새 시장을 빠르게 점유하고 뉘앙스를 개선하기 위해서입니다.

다양한 방법론, 하나의 트렌드

"애자일(Agile)"이라는 일반 이름으로 유연성 원칙을 기반으로 하는 부인할 수 없이 인기 있는 스크럼(Scrum) 및 칸반(Kanban) 과 집요한 반복 RUP 외에도 기업에서는 다양한 방법론을 사용하여 작업합니다. 어떤 사람들은 극단적인 프로그래밍과 가장 빠르고 간단한 결정을 내리는 것을 선호하고, 어떤 사람들은 테스트 중심 개발을 선호하고, 어떤 사람들은 신속한 애플리케이션 개발(RAD)을 선호합니다. 동시에, 주요하고 무조건적인 추세는 여러 방법론을 동시에 사용하는 것 입니다 . 또는 모델과 방법론을 고유한 제어 시스템으로 결합할 수도 있습니다. 현대 기업은 부서와 블록 간에 책임을 이동하지 않고 관료적 장벽을 제거하고 조직 내 일반적인 팀워크 분위기를 조성하기 위해 노력합니다. Scrumalliance 보고서 에 따르면 IT 기업의 70%가 스크럼을 사용하고 있습니다. 그중에는 Google, Amazon, Salesforce, Microsoft, Adobe와 같은 거대 기업이 있습니다. 신생 기업과 젊은 프로젝트는 Kanban에 더 관심이 있지만 Toyota와 Wargaming의 게이머도 Kanban을 사용합니다. 좀 더 겸손한 CIS 회사인 Prom.ua, Bigl.ua, Kabanchik.ua는 Scrum 및 Kanban 방법론을 동시에 사용하지만 다른 작업에 사용합니다. 스크럼 - 작업 진행 상황을 모니터링하기 위한 계획 도구인 Kanban입니다. RUP의 경우 직원 수가 50~200명이고 수익이 100만~1000만 달러인 서구 기업에서 가장 자주 실행됩니다. 그러나 동시에 IBM은 OpenUP 방법론인 "RUP, only agile"을 출시하여 Agile 원칙에 더 가까워지도록 RUP를 변경했습니다. 그와 같은 자랑스러운 민첩한 민첩성이 이제 IT 환경을 지배하고 있습니다 . 이는 요즘 유행하는 것이 아니라 여전히 혁신적이며 실제로 많은 대기업에서 작동합니다. Agile은 Silicon Valley에서 사용되며 Facebook과 Uber에서도 사용됩니다.

결론

각 프로젝트에는 팀, 자금, 시기 및 고객 요구 사항에 따라 자체 소프트웨어 개발 방법론이 있습니다. 보편적인 관리 기술은 없습니다. 매우 인기 있는 Agile조차도 개발 프로세스에 대한 최상의 접근 방식을 제공할 수 없습니다. 따라서 방법론은 신중하게 선택되며 때로는 근본적으로 선택됩니다. 이를 사용하여 회사 자체나 고객에 대한 결론을 도출할 수 있습니다. 방법론은 혼합되어 모델로 보완되고 자체적으로 조정됩니다. 너무 많아서 새로운 접근 방식이 생겨납니다. 결국 관리 영역은 Scrum과 Kanban의 손에 남게 되지만 예상치 못한 Waterfall 모델이나 반복 RUP가 포함됩니다.