애자일 방법론이란 무엇입니까? 최신 소프트웨어 개발 설명

오늘날 모든 기술 조직은 소프트웨어 개발 또는 그 버전을위한 애자일 방법론을 실행하는 것처럼 보입니다. 아니면 적어도 그들은 그렇게 믿습니다. 애자일 애플리케이션 개발을 처음 접하든 수십 년 전에 워터 폴 소프트웨어 개발 방법론을 사용하여 소프트웨어 개발을 배웠 든 관계없이 오늘날 작업은 최소한 애자일 방법론의 영향을받습니다.

그러나 애자일 방법론이란 무엇이며 소프트웨어 개발에서 어떻게 실행되어야할까요? 애자일 개발은 실제로 폭포수와 어떻게 다른가요? 애자일 소프트웨어 개발 라이프 사이클 또는 애자일 SDLC는 무엇입니까? 그리고 Scrum Agile과 Kanban 및 기타 Agile 모델은 무엇입니까? 

애자일은 2001 년 17 명의 기술자가 애자일 선언문을 작성하면서 공식적으로 시작되었습니다. 그들은 더 나은 소프트웨어 개발을 목표로 애자일 프로젝트 관리를위한 네 가지 주요 원칙을 작성했습니다.

  • 프로세스 및 도구에 대한 개인 및 상호 작용
  • 포괄적 인 문서에 대한 작업 소프트웨어
  • 계약 협상을 통한 고객 협력
  • 계획에 따라 전환에 대응

애자일 이전 : 폭포수 방법론의 시대

저와 같은 노련한 사람들은 폭포수 방법론이 소프트웨어 개발의 표준이었던 시절을 기억합니다. 소프트웨어 개발 프로세스에는 코딩을 시작하기 전에 많은 양의 문서가 필요했습니다. 일반적으로 비즈니스 분석가 인 누군가가 먼저 애플리케이션에서 비즈니스에 필요한 모든 것을 캡처 한 비즈니스 요구 사항 문서를 작성했습니다. 이러한 비즈니스 요구 사항 문서는 전체 전략, 포괄적 인 기능 사양 및 시각적 사용자 인터페이스 디자인 등 모든 것을 자세히 설명하는 길었습니다.

기술자는 비즈니스 요구 사항 문서를 가져 와서 자체 기술 요구 사항 문서를 개발했습니다. 이 문서는 애플리케이션의 아키텍처, 데이터 구조, 객체 지향 기능 설계, 사용자 인터페이스 및 기타 비 기능적 요구 사항을 정의했습니다.

이 폭포수 소프트웨어 개발 프로세스는 마침내 코딩을 시작한 다음 통합을 시작하고 최종적으로 애플리케이션이 생산 준비가 된 것으로 간주되기 전에 테스트합니다. 전체 프로세스는 쉽게 몇 년이 걸릴 수 있습니다.

우리 개발자는 문서 작성자와 마찬가지로 완전한 문서가 호출 될 때 "사양"을 알고 있어야했습니다. 200 페이지의 77 페이지에 설명 된 주요 세부 사항을 제대로 구현하는 것을 잊으면 종종 비난을 받았습니다. 페이지 문서.

당시에는 소프트웨어 개발 자체도 쉽지 않았습니다. 많은 개발 도구에는 전문 교육이 필요했으며 오늘날 존재하는 오픈 소스 또는 상용 소프트웨어 구성 요소, API 및 웹 서비스 근처에는 없었습니다. 우리는 데이터베이스 연결을 열고 데이터 처리를 멀티 스레딩하는 것과 같은 저수준의 것들을 개발해야했습니다.

기본 애플리케이션의 경우에도 팀 규모가 크고 커뮤니케이션 도구가 제한되었습니다. 우리의 기술 사양은 우리를 일치 시켰고 성경처럼 활용했습니다. 요구 사항이 변경되면 팀 전체에서 변경 사항을 전달하고 코드를 수정하는 데 비용이 많이 들기 때문에 비즈니스 리더는 긴 검토 및 승인 프로세스를 거쳐야했습니다.

소프트웨어가 기술 아키텍처를 기반으로 개발 되었기 때문에 하위 수준의 아티팩트가 먼저 개발되고 이후에 종속 아티팩트가 개발되었습니다. 작업은 기술별로 할당되었으며, 데이터베이스 엔지니어가 먼저 테이블 및 기타 데이터베이스 아티팩트를 구성한 다음 애플리케이션 개발자가 기능과 비즈니스 로직을 코딩 한 다음 마지막으로 사용자 인터페이스를 오버레이하는 것이 일반적이었습니다. 누군가 애플리케이션이 작동하는 것을보기까지 몇 달이 걸렸고, 그 무렵 이해 관계자들은 그들이 진정으로 원하는 것에 대해 불안해하고 종종 더 똑똑해졌습니다. 변경 사항을 구현하는 데 비용이 많이 드는 것은 당연합니다!

사용자 앞에 놓은 모든 것이 예상대로 작동하는 것은 아닙니다. 때때로 사용자는 기능을 전혀 사용하지 않을 것입니다. 다른 경우에는 기능이 널리 성공했지만 필요한 확장 성과 성능을 지원하기 위해 리엔지니어링이 필요했습니다. 폭포수 세계에서는 긴 개발주기를 거쳐 소프트웨어가 배포 된 후에 만 ​​이러한 것들을 배웠습니다.

관련 비디오 : 애자일 방법론의 실제 작동 방식

모든 사람이 애자일 소프트웨어 개발에 대해 이야기하는 것 같지만 많은 조직이 프로세스 작동 방식을 제대로 파악하지 못하고 있습니다. 이 5 분 분량의 동영상을보고 빠르게 익히십시오.

애자일 소프트웨어 개발의 중심

1970 년에 발명 된 폭포수 방법론은 따라야 할 명확한 사양을 보장하기 위해 소프트웨어 개발에 규율을 가져 왔기 때문에 혁명적이었습니다. 이는 Henry Ford의 1913 년 조립 라인 혁신에서 파생 된 폭포 제조 방법을 기반으로했으며, 이는 최종 제품이 처음에 사양과 일치하도록 보장하기 위해 생산 공정의 각 단계에 대한 확실성을 제공했습니다.

폭포수 방법론이 소프트웨어 세계에 등장했을 때 컴퓨팅 시스템과 해당 애플리케이션은 일반적으로 복잡하고 모 놀리식이 어서 제공하려면 규율과 명확한 결과가 필요했습니다. 요구 사항도 오늘날에 비해 느리게 변경되었으므로 대규모 작업은 문제가 적었습니다. 사실, 시스템은 변경되지 않을 것이지만 영구적 인 전함이라는 가정하에 구축되었습니다. 다년 기간은 소프트웨어 개발뿐만 아니라 제조 및 기타 기업 활동에서도 일반적이었습니다. 그러나 폭포의 강성은 속도와 유연성이 요구되는 인터넷 시대에 아킬레스 건이되었습니다.

소프트웨어 개발 방법론은 개발자가 인터넷 애플리케이션 작업을 시작하면서 바뀌기 시작했습니다. 초기 작업의 대부분은 팀이 더 작고 함께 배치되어 있으며 종종 전통적인 컴퓨터 과학 배경이없는 스타트 업에서 이루어졌습니다. 웹 사이트, 애플리케이션 및 새로운 기능을 더 빨리 출시해야하는 재정적, 경쟁적 압박이있었습니다. 이에 대응하여 개발 도구와 플랫폼이 빠르게 변경되었습니다.

이로 인해 스타트 업에서 일하는 많은 사람들이 폭포수 방법론에 의문을 제기하고 더 효율적인 방법을 모색했습니다. 모든 세부 문서를 미리 처리 할 여유가 없었고 더 반복적이고 협업적인 프로세스가 필요했습니다. 우리는 여전히 요구 사항의 변경 사항에 대해 논의했지만 실험과 최종 사용자 요구 사항에보다 개방적이었습니다. 우리 조직은 구조화가 덜하고 애플리케이션이 엔터프라이즈 레거시 시스템보다 덜 복잡했기 때문에 애플리케이션을 구축하는 것보다 구매하는 데 훨씬 더 개방적이었습니다. 더 중요한 것은 우리는 비즈니스를 성장 시키려고 노력하고 있었기 때문에 사용자가 무언가 작동하지 않는다고 말했을 때 우리는 더 자주 듣는 것을 선택했습니다.

우리의 기술과 혁신 능력은 전략적으로 중요해졌습니다. 원하는 모든 돈을 모을 수는 있지만, "사양"을 엄청나게 따르는 하위 ​​코더로 취급한다면 빠르게 변화하는 인터넷 기술로 작업 할 수있는 재능있는 소프트웨어 개발자를 끌어들일 수 없었습니다. 우리는 개발해야 할 사항, 애플리케이션 출시시기, 때로는 코드 구조화 방법까지 설명하는 종단 간 일정을 제시하는 프로젝트 관리자를 거부했습니다. 우리는 폭포수 프로젝트 관리자가 초안을 작성하고 끊임없이 업데이트하는 3 개월 및 6 개월 일정을 맞추는 것이 끔찍했습니다.

대신 인터넷 애플리케이션을 어떻게 엔지니어링해야하는지 알려주기 시작했고, 반복적으로 작성한 일정에 따라 결과를 전달했습니다. 우리가 1 주에서 4 주 사이의 작은 간격으로 약속했을 때 우리가 말한 것을 전달하는 데 그렇게 나쁘지 않은 것이 밝혀졌습니다.

2001 년에 숙련 된 소프트웨어 개발자 그룹이 모여서 그들이 기존의 폭포수 방법론과는 다른 방식으로 소프트웨어 개발을 공동으로 실행하고 있음을 깨달았습니다. 그리고 그들은 모두 스타트 업에 있지 않았습니다. 기술 전문가 인 Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber 및 Jeff Sutherland가 포함 된이 그룹은 현대 소프트웨어 개발 프로세스의 작동 방식에 대한 공통된 신념을 문서화 한 Agile Manifesto를 작성했습니다. 그들은 문서화, 엄격한 관리 관행보다는 자기 조직, 그리고 엄격한 폭포 개발 프로세스에 얽매이지 않고 지속적인 변화를 관리 할 수있는 능력에 대한 협업을 강조했습니다.

이러한 원칙으로부터 소프트웨어 개발을위한 애자일 방법론이 탄생했습니다.

애자일 방법론의 역할

민첩한 소프트웨어 개발 프로세스는 항상 사용자를 정의하고 해결해야 할 문제, 기회 및 가치 범위에 대한 비전 선언문을 문서화하는 것으로 시작됩니다. 제품 소유자는이 비전을 포착하고 다 분야 팀 (또는 여러 팀)과 협력하여이 비전을 실현합니다. 그 과정에서 역할은 다음과 같습니다.

사용자

애자일 프로세스는 항상 사용자 또는 고객을 염두에두고 시작됩니다. 오늘날 우리는 종종 소프트웨어가 지원하는 워크 플로의 다양한 역할 또는 다양한 유형의 고객 요구와 행동을 설명하기 위해 사용자 페르소나로 정의합니다.

제품 소유자

애자일 개발 프로세스 자체는 내부 이해 관계자를 포함하여 고객의 목소리가되어야하는 사람으로부터 시작됩니다. 그 사람은 제품 비전을 만들기 위해 모든 통찰력, 아이디어 및 피드백을 추출합니다. 이러한 제품 비전은 종종 짧고 간단하지만 그럼에도 불구하고 고객이 누구인지, 어떤 가치를 다루고 있는지, 그리고이를 해결하는 방법에 대한 전략을 보여줍니다. 저는 Google의 원래 비전이 "간단한 키워드 기반 인터페이스와 검색 결과에서 평판이 좋은 출처를 더 높은 순위로 매기는 알고리즘을 사용하여 인터넷에 접속할 수있는 사람이라면 누구나 관련 웹 사이트와 웹 페이지를 쉽게 찾을 수 있도록합시다"라고 생각할 수 있습니다.

이 사람을 제품 소유자라고 합니다. 그의 책임은이 비전을 정의한 다음 개발 팀과 협력하여이를 실현하는 것입니다.

개발 팀과 협력하기 위해 제품 소유자는 제품 비전을 대상 사용자가 누구인지, 어떤 문제가 해결되고 있는지, 솔루션이 왜 중요한지 자세히 설명하는 일련의 사용자 스토리로 제품 비전을 세분화합니다. 어떤 제약과 수용 기준이 솔루션을 정의하는지. 이러한 사용자 스토리는 제품 소유자가 우선 순위를 지정하고 팀이 검토하여 요청 된 내용을 공유 할 수 있도록합니다.

소프트웨어 개발팀

애자일에서 개발 팀과 구성원의 책임은 기존 소프트웨어 개발의 책임과 다릅니다.

팀은 업무를 완수 할 수있는 기술을 가진 다양한 그룹의 사람들로 구성된 다 분야입니다. 작동하는 소프트웨어를 제공하는 데 중점을두기 때문에 팀은 종단 간 작동하는 응용 프로그램을 완료해야합니다. 따라서 전체 애플리케이션이 아니라 애플리케이션 일부 의 데이터베이스, 비즈니스 로직 및 사용자 인터페이스 가 개발되고 데모됩니다. 이를 위해 팀 구성원은 협력해야합니다. 그들은 자주 만나서 모든 사람이 자신이 무엇을 만들고 있는지, 누가 무엇을하고 있는지, 소프트웨어가 정확히 어떻게 개발되고 있는지에 대해 조정합니다.

개발자 외에도 소프트웨어 개발 팀에는 소프트웨어 프로젝트 유형에 따라 품질 보증 (QA) 엔지니어, 기타 엔지니어 (예 : 데이터베이스 및 백엔드 시스템), 디자이너 및 분석가가 포함될 수 있습니다.

Scrum, Kanban 및 기타 애자일 프레임 워크

소프트웨어 개발 수명주기에 맞춰 개발 프로세스 및 애자일 개발 사례에 대한 세부 사항을 제공하는 많은 애자일 프레임 워크입니다.

가장 널리 사용되는 애자일 프레임 워크는 스크럼 입니다. 다음을 포함 하는 스프린트 및 회의 구조 라고하는 전달주기에 중점을 둡니다 .

  • 계획 — 스프린트 우선 순위가 식별되는 곳
  • 약속 — 팀이 사용자 스토리 목록 또는 백 로그를 검토하고 스프린트 기간 동안 수행 할 수있는 작업의 양을 결정하는 곳 
  • 일일 스탠드 업 회의 — 팀이 개발 상태 및 전략에 대한 업데이트를 전달할 수 있습니다.)

스프린트는 제품 소유자에게 기능이 표시되는 데모 회의로 끝나고, 팀이 잘 된 부분과 프로세스 개선이 필요한 부분에 대해 논의하는 회고 회의가 이어집니다.

많은 조직에서 팀이 스크럼 프로세스를 관리 할 수 ​​있도록 스크럼 마스터 또는 코치를 고용합니다.

스크럼이 지배적이지만 다른 애자일 프레임 워크가 있습니다.

  • Kanban은 팀이 인테이크 보드에서 사용자 스토리를 가져와 완료 될 때까지 단계별 개발 프로세스를 통해 전달하는 팬인 및 팬 아웃 프로세스로 작동합니다.
  • 일부 조직은 새로운 애플리케이션에는 민첩한 프로세스를 사용하고 레거시 애플리케이션에는 폭포수를 사용하는 하이브리드 민첩 및 폭포수 접근 방식을 채택합니다.
  • 조직이 여러 팀으로 관행을 확장 할 수 있도록하는 몇 가지 프레임 워크도 있습니다.

애자일 프레임 워크는 프로세스와 협업을 정의하지만 애자일 개발 관행은 애자일 프레임 워크에 따라 수행되는 소프트웨어 개발 작업을 처리하는 데 특화되어 있습니다.

예를 들면 다음과 같습니다.

  • 일부 팀은 두 명의 개발자가 함께 코딩하여 더 높은 품질의 코드를 작성하고 더 많은 시니어 개발자가 중학교 개발자를 멘토링 할 수 있도록하는 쌍 프로그래밍을 채택합니다.
  • 고급 팀은 테스트 기반 개발 및 자동화를 채택하여 기본 기능이 예상 된 결과를 제공하도록합니다.
  • 또한 많은 팀이 기술 표준을 채택하여 개발자의 사용자 스토리 해석이 원하는 기능으로 이어지지 않고 보안, 코드 품질, 명명 규칙 및 기타 기술 표준을 충족합니다.

애자일 방법론이 더 나은 이유