"그래서 애자일 과 스크럼 에 대해 말씀드리고 싶습니다 ."
"21세기 초에 사람들이 프로그래밍에 대해 생각하는 방식은 완전히 뒤집어졌습니다."
"모두가 장기 계획이 효과가 없다고 확신했기 때문에 완전히 포기하기로 결정했습니다."
"그들은 어떻게 했습니까?"
"방법은 다음과 같습니다."
"그들은 가능한 가장 유연한 프로젝트 관리 접근 방식을 발명했습니다."
민첩한 개발의 기본 아이디어는 다음과 같습니다 ."
- 프로세스와 도구보다 사람과 커뮤니케이션이 더 중요합니다.
- 작동하는 제품이 철저한 문서화보다 더 중요합니다.
- 계약 조건을 충족하는 것보다 고객과의 협력이 더 중요합니다.
- 원래 계획을 고수하는 것보다 변화하려는 의지가 더 중요합니다.
빠른 개발의 원칙은 다음과 같습니다.
- 가치 있는 소프트웨어를 조기에 지속적으로 공급하여 고객을 만족시킨다.
- 개발 종료 시에도 요구 사항의 변경을 환영합니다(최종 제품의 경쟁력을 높일 수 있음).
- 작동하는 소프트웨어를 자주(매월 또는 매주 또는 더 자주) 제공합니다.
- 전체 프로젝트에서 고객과 개발자 간의 긴밀한 일상 커뮤니케이션
- 프로젝트는 필요한 작업 조건, 지원 및 신뢰를 제공받는 동기 부여된 개인이 수행합니다.
- 정보 전달에 선호되는 방법은 개인(대면) 대화입니다.
- 작동하는 소프트웨어는 진행 상황의 가장 좋은 척도입니다.
- 스폰서, 개발자 및 사용자는 무기한으로 일정한 속도를 유지할 수 있어야 합니다.
- 기술적 우수성과 사용자 친화적인 디자인 개선에 지속적으로 집중합니다.
- 단순함은 불필요한 작업을 하지 않는 기술입니다.
- 최고의 기술 요구 사항, 디자인 및 아키텍처는 자체 조직된 팀에서 나옵니다.
- 변화하는 상황에 대한 지속적인 적응.
"소프트웨어 개발의 주요 문제는 어떤 단계에서든 참여자 중 누구도 무엇을 해야 하는지에 대한 완전한 정보를 가지고 있지 않다는 것입니다."
"고객은 자신이 프로그램을 구상하는 방법을 말할 수 있지만 무언가를 생략하거나 당연하게 여길 것입니다."
"매니저는 일반적으로 프로그래밍 전문 용어에서 고객의 언어로 요구 사항을 번역하고 다시 번역해야 합니다."
"불확실성이 너무 큽니다."
"종종 고객의 요구 사항은 다음과 같습니다. 어떤 방식으로든 수행한 다음 보여주세요. 마음에 들지 않으면 다시 실행할 수 있습니다."
"어... 끔찍해."
"새로운 패러다임에 따르면 프로그래머는 더 이상 제품이나 프로그램을 개발하는 것이 아니라 고객이 필요로 하는 기능을 구현하는 것입니다."
"차이점이 뭐야?"
"예전에는 프로그램 개발에 1년이 걸렸다고 가정해 보겠습니다. 그리고 6개월이 지나야 볼 것이 생겼습니다. 마치 큰 집을 짓는 것과 같습니다. 벽, 지붕, 트림 등을 만듭니다."
"그러나 이제 프로그래머들은 가능한 한 빨리 필요한 기능을 출시하려고 합니다. 이것은 처음에는 오두막을 짓고, 그 다음에는 이동 주택을 짓고, 그 다음에는 작은 집을 짓고, 그 다음에는 큰 집을 나누어서 짓는 것과 같습니다."
" 고객이 자신이 원하는 것이 무엇인지 정확히 알지 못한다는 점을 고려하면 이는 매우 합리적인 접근 방식입니다."
"손님이 큰 사냥터를 원한다고 가정해 봅시다."
"개발자들이 그를 위해 작은 집을 짓습니다. 그는 그 안에서 겨울을 삽니다. 그런 다음 그는 목조 주택이 마음에 들지 않는다고 결정합니다. 벽돌로 집을 만들자."
"그는 여름 동안 호수 근처에 살지만 모기가 그를 산 채로 잡아먹습니다. 그는 어디선가 호수가 시원하다는 말을 듣고 호수가 있는 것을 좋아했습니다. 하지만 이제 그는 호수를 원하지 않습니다. 그리고 그것은 건설하기 더 쉬울 것입니다. 호수가 없다는 것은 홍수의 위협이 없다는 것을 의미하며, 지주 대신 땅 위에 집을 지을 수 있어 25% 더 빠를 것입니다."
"흥미로운 비유입니다. 고객이 실제로 요구사항을 그렇게 자주 변경합니까?"
"예, 하지만 문제는 고객이 아닙니다."
"첫째, 미래에 일이 어떻게 될지 상상하기가 매우 어렵습니다. 관리자, 테스터, 프로그래머 모두 이 작업을 수행합니다. 또한 일이 어떻게 진행되는지에 따라 마음이 바뀝니다."
" 둘째 , 고객의 요구 사항이 가장 중요하지 않습니까? 결국 이 모든 작업의 요점은 고객이 처음에 만들라고 한 것이 아니라 고객이 필요로 하는 것을 만드는 것입니다 ."
"사실 예전에는 이렇게 작동했습니다. 비즈니스 분석가는 모든 요구 사항 목록을 작성했습니다. 그들은 이 목록을 계약서에 포함하고 서명한 다음 목록에 따라서만 작업했습니다."
" 고객이 정말로 필요로 하지만 잊어 버린 것이 목록에 없으면 아무도 그것에 대해 아무것도 하지 않을 것입니다."
"그렇구나. 계획대로 하는 게 편하긴 하지만, 모든 일을 계획대로 할 수는 없지!"
"정확히."
"그래서 민첩한 개발 방법이 발명되었습니다."
"그리고 오늘은 스크럼 중에서 가장 인기 있는 스크럼 에 대해 말씀드리겠습니다 .
"스크럼의 주요 기능은 프로젝트 개발을 보통 2~4주 길이의 작은 반복으로 나누는 것입니다. 각 반복을 스프린트라고 합니다."
"스프린트가 시작될 때 스프린트 계획 회의가 열립니다. 3-4시간 동안 지속됩니다."
"마지막에는 완전히 완료된 모든 작업에 대한 시연이 있습니다."
"모든 것이 일반적으로 작동하는 방식은 다음과 같습니다."
"첫 번째 스프린트 전에 고객(또는 고객의 대리인)은 요구 사항 목록, 즉 프로그램이 수행할 수 있어야 하는 일련의 작업을 구성합니다. 이러한 요구 사항을 일반적으로 사용자 스토리 라고 하며 고객은 일반적 으로 제품 소유자 라고 합니다 ."
"그는 제품 소유자 라고 불립니다. 제품이 그를 위해 작성되었기 때문입니다. 그 자신만이 요구 사항 목록을 정의합니다. 무엇을, 언제, 어떤 순서로."
"또한 제품 소유자는 일반적으로 작업 우선 순위를 지정합니다. 우선 순위가 가장 높은 작업이 먼저 구현됩니다. 전체 요구 사항 목록을 제품 백로그 라고도 합니다 ."
"스프린트가 시작되면 모두 모여 회의를 합니다. 일반적으로 팀의 구성원인 스크럼 마스터가 회의를 주도합니다. 회의의 목표 는 현재 스프린트(개발의 반복)에 대한 작업( 사용자 스토리 )을 선택하는 것입니다. "
"먼저 팀은 각 작업에 스토리 포인트라고도 하는 추상적 맨데이(man-days)의 대략적인 추정치를 할당합니다. 그런 다음 팀은 스프린트 동안 완료할 시간이 있는 작업 수를 결정합니다."
"다시 말하지만, 스프린트 동안 완료해야 할 작업의 수를 결정하는 것은 팀 자체입니다."
"예를 들어 제품 오너가 팀이 처음 7개의 작업을 선택하기를 기대했지만 5개만 선택한 다음 6, 7개의 작업은 다음 스프린트로 연기됩니다. 제품 소유자가 적합하지 않으면 작업의 우선 순위를 높일 수 있습니다. 6과 7이 선택되었는지 확인하지만 다른 작업 중 일부는 스프린트에서 제외됩니다."
" 스크럼 마스터는 일부 작업을 더 작은 작업으로 나누고 제품 소유자를 최대한 행복하게 만들기 위해 다른 우선 순위를 설정하도록 제안할 수도 있습니다."
"그것이 회의의 요점입니다. 작업을 변경하고 분할할 수 있으며 우선 순위를 변경할 수 있습니다. 이것은 처음에는 보이지 않았지만 많은 가치를 제공하는 작업입니다."
"알았다. 차를 운전하는 것과 같다. 처음에는 그냥 직진하면 된다고 생각하더라도 현실은 끊임없이 움푹 들어간 곳을 피하고, 좌우로 방향을 틀고, 다른 사람을 추월하거나 지나치게 해야 한다."
"그래, 그런 거."
"스프린트를 위해 선택된 작업 목록을 스프린트 백로그 라고 합니다 ."
"프로그래머는 누가 무엇을 할지 결정하고 나서야 일을 시작합니다." 효율성을 개선하기 위해 Scrum은 매일 5~15분 회의를 개최하여 모든 사람이 어제 무엇을 했고 현재 무엇을 하고 있는지 서로 말할 수 있도록 제안합니다. 오늘 할거야."
"팀워크. 존중할 수 있어!"
"시각화하기 쉽도록 일반적으로 특수 보드에 현재 스프린트 상태를 표시하는 것이 좋습니다."
"왼쪽에 있는 세 개의 기둥을 주목하십시오."
"약식 작업 이름은 스티커 메모에 기록됩니다. 스티커 메모는 상태(계획됨, 진행 중, 완료)에 따라 다른 열에 배치됩니다."
"오른쪽에서 번다운 차트를 볼 수 있습니다. 매일 이 차트에는 아직 실행되지 않은 작업이 나열됩니다. 이상적으로는 완료되지 않은 작업의 수가 스프린트 중에 0으로 떨어집니다."
"스프린트가 끝나면 스크럼 마스터는 완전히 완료된 모든 항목의 목록을 보여주기 위해 데모를 제공합니다 ."
"그런 다음 스프린트 회고 회의를 엽니다 . 이 회의도 몇 시간 동안 진행됩니다. 이 회의 중에 참가자들은 일반적으로 무엇이 잘 되었고 어떤 일(그리고 어떻게)을 더 잘 할 수 있었는지 알아내려고 노력합니다."
"보통 2~3회 스프린트 후에 팀이 보다 효율적으로 작업하는 데 방해가 되는 주요 문제를 식별하고 제거할 수 있습니다. 이는 팀의 작업량을 늘리지 않고도 생산성을 높일 수 있습니다. 이는 애자일 방법론 시대 이전에는 불가능했습니다. "
"때때로 스프린트 중에 그루밍 회의도 열립니다. 그 목적은 다음 스프린트를 계획하는 것입니다. 참가자는 일반적으로 이 회의에서 작업 우선 순위를 명확히 합니다. 또한 일부 작업을 부분으로 분할하거나 제품 백로그에 새 작업을 추가할 수도 있습니다 . "
"글쎄, 그게 기본적으로 내가 가진 전부입니다. 이것은 단지 개요일 뿐입니다. 단 몇 마디로 모든 것을 설명하는 것은 불가능하지만 여기에서 주제에 대한 좋은 기사를 읽을 수 있습니다."
GO TO FULL VERSION