프로젝트 관리를 위한 스크럼 방법론. Certified Agile Professional 인증 과정 psm scrum org 준비

Agile(Agile, 영어로 "유연함")은 소프트웨어 개발 프로젝트 관리에 대한 접근 방식입니다. 2000년대 중반(또는 그 이전)에 개발되었습니다. Agile 접근 방식에는 다음과 같은 여러 기술이 포함됩니다.

스크럼(비즈니스와 IT 간의 상호 작용을 구성하는 데 적합)
칸반(직원의 업무에서 멀티태스킹을 구성하는 데 적합하며 스크럼과 잘 어울림)
XP(익스트림 프로그래밍의 원리);
린(린 개발의 원칙).

우리가 스크럼을 제공하는 이유는... 이는 비즈니스 부서와 IT 부서 모두의 참여가 필요한 프로젝트를 구축하는 좋은 방법입니다.

스크럼은 다음과 같은 분야에서 적극적으로 사용됩니다. 대기업그리고 기업.

프로세스의 주요 본질은 다음과 같습니다.

프로젝트는 짧은 반복(소위 스프린트)으로 수행되며 각 반복은 1~4주 동안 지속됩니다.
프로젝트에는 제품 소유자, 스크럼 마스터, 팀의 세 가지 역할만 있습니다. 역할은 서로 효과적으로 상호작용하고 협력합니다.
스크럼에는 제품 백로그(제품 요구 사항), 스프린트 백로그(스프린트에서 구현될 요구 사항), 스프린트 목표(스프린트 목표, 반복), 번다운 다이어그램(작업 번다운 다이어그램) 등 4개의 아티팩트(문서)만 있습니다.
스크럼에는 4가지 의식만 있습니다. 그러나 해당 기사에서 이에 대해 읽는 것이 좋습니다.

팀은 일일 회의의 "의식"을 수행합니다.

Agile 접근 방식의 장점:

가장 우선순위가 높은 기능을 빠르게 제공합니다.
프로토타입 제작 및 반복을 통해 요구 사항의 불확실성을 줄입니다.
문서의 양을 줄이려는 욕구;
변화에 대한 빠른 대응;
고객과의 협력을 지향합니다.

스크럼 구현 서비스

우리는 귀사에서 민첩한(유연한) 프로젝트 관리 프로세스를 구현하는 서비스를 제공합니다. 프로젝트가 완료되면 다음을 받게 됩니다:

회사의 훈련된 관리자. 비즈니스 및 IT 측면의 소프트웨어 개발 프로젝트에 참여하는 모든 직원을 대상으로 교육을 제공합니다. 교육은 비즈니스 및 IT, IT만, 비즈니스만, "파일럿" 프로젝트 팀만 등 여러 차례 실시됩니다. 총 5회 이상의 세션이 진행됩니다.
훈련된 스크럼 팀. 우리는 귀하가 파일럿 프로젝트를 가장 먼저 수행하고 사례를 사용하여 효과를 입증할 팀을 구성하는 데 도움을 드릴 것입니다. 우리는 팀의 가용성(역량)을 평가하고, 팀의 중점 요소를 제안하며, 여러 프로젝트 간에 리소스를 분배하는 방법을 제안하고, 기타 종속성을 고려합니다.
프로세스가 "처음부터 끝까지" 어떻게 작동하는지 보여주는 "파일럿" 프로젝트를 시작합니다. 이것이 우리 작업의 가장 중요한 부분입니다. 파일럿 프로젝트의 예는 비즈니스 발전을 방해하는 모든 숨겨진 문제(자원 충돌, 분석가 부족, 신속한 의사 결정 불가능 등)를 드러냅니다. 발생한 갈등을 적절하게 피하고 향후 유사한 사례를 예방하는 방법을 알려 드리겠습니다.
팀과 마스터를 위한 지침. 스크럼의 모든 프로세스를 올바르게 수행하기 위해 팀과 해당 환경에 필요한 기본 작업을 설명하는 간단하고 접근 가능한 문서입니다.
IT 환경. 프로젝트 관리 소프트웨어가 있는 경우 스크럼 프로젝트에서 이를 올바르게 사용하도록 도와드릴 수 있습니다.

구현 프로젝트는 어떻게 진행되나요?

우리의 구현 접근 방식은 2주 단계를 기반으로 합니다. 우리는 단 3단계로 프로젝트를 완료할 준비가 되었습니다:

구현을 위한 교육 및 준비. 우리는 귀하의 직원을 교육하고 프로세스를 평가하며 파일럿 프로젝트 선택을 돕습니다. 또한 전체 기업이 구현 범위에 대해 동일하게 이해할 수 있도록 스크럼 구현 프로젝트 헌장에 서명하는 것이 좋습니다.
파일럿 프로젝트에서 스크럼을 구현합니다. 우리는 귀하의 파일럿 프로젝트 프로세스를 시작하는 데 도움을 드립니다. 우리는 팀과 제품 소유자를 위한 추가 교육을 제공합니다. 우리는 팀의 실제 작업량, 다른 프로젝트의 영향 등을 고려합니다. 또한 스크럼 팀을 위한 지침도 개발합니다.
파일럿 프로젝트를 지원합니다. 필요한 경우, 우리는 재교육 브리핑팀을 위해서. 우리는 직원들이 스크럼 의식을 올바르게 수행하고 있는지 매일 확인합니다. 확인된 오류는 현장에서 수정됩니다.

작업을 시작하기 전, 1단계의 세부 작업 일정과 2, 3단계의 권장 일정을 협의합니다.

애자일은 스크럼과 어떻게 다른가요?

간단히 말해서 Scrum은 Agile 방법 중 하나입니다.

스크럼이 적합합니다.

작업 속도를 높이고 자신이 만드는 제품의 비즈니스 가치를 높이려는 제품 팀을 위한 것입니다.
아웃소싱 팀의 경우 - Agile/Scrum 구현에 대한 요구 사항이 고객으로부터 나온 경우 작업 프로세스를 구성하는 최선의 방법을 이해하도록 도와드립니다.
내부 자동화 프로젝트 프레임워크 내에서 IT와 비즈니스 간의 상호 작용을 구축하려는 조직에 적합합니다.

가격 및 구현 비용

우리는 일반적으로 6주 동안의 구현을 제공합니다. 비용은 13~15,000달러입니다. 일반적인 구현 비용은 조직의 복잡성과 구현에 참여할 사람의 수에 따라 달라집니다. 사업장의 위치도 중요한 역할을 합니다. 여행 경비추가로 지급됩니다.

스크럼으로 가장 먼저 이동할 파일럿 프로젝트를 결정합니다. 이는 회사에 중요한 프로젝트여야 하지만 가장 중요한 프로젝트는 아닙니다(프로젝트 중단에 따른 위험은 허용 가능해야 함).
스크럼 마스터를 선택하세요. 이는 파일럿 프로젝트 팀에 압력을 가하지 않는 재치 있고 갈등이 없는 사람이어야 합니다. 마스터는 프로젝트의 세부 사항을 이해해야 하지만 기술적인 사람일 필요는 없습니다.
구현 프로젝트의 결과와 영향에 진심으로 관심이 있는 제품 소유자를 찾으세요. 프로젝트 자체 외에 할 일이 많은 최고 관리자를 선택하지 마십시오. 할 것이다 이상적인 옵션제품이 시장에 출시되는 속도에 따라 효율성과 보너스가 직접적으로 달라지는 직원을 찾으십시오.
프로젝트 팀이 다른 직원의 방해를 받지 않고 작업할 수 있는 공간을 마련하세요. 팀이 업무에만 집중하도록 하세요.
프로젝트 고객으로서 신속하게 문제를 해결할 수 있도록 팀과 지속적으로 가까워져야 합니다.

Project Office 회사는 벨로루시에서 "민첩한" 소프트웨어 개발 방법을 교육하고 구현하는 유일한 회사입니다.

우리는 다음을 돕습니다:

변경 사항을 구현하는 가장 최적의 방법을 선택합니다.
사람 선택 - 프로세스의 주요 참가자(고객과 합의)
구현 목표를 달성하고 프로젝트 완료 후 고객 지원을 제공합니다.

스프린트 동안 제품의 작업 버전을 얻는 데 필요한 모든 작업을 완료해야 합니다. 스프린트의 범위는 고정되어야 합니다. 덕분에 팀은 구현에 대한 책임을 질 수 있습니다. 이를 바탕으로 스프린트 백로그는 팀 외에는 누구도 변경할 수 없습니다.

이 모든 것에 대해 "Scrum -"책에서 자세히 알아볼 수 있습니다. 혁명적인 방법프로젝트 관리'(Jeff Sutherland), 실무 주제에 대한 대화를 계속하겠습니다. 이들에 익숙해지면 스크럼 프로젝트가 어떻게 구현되는지 이해할 수 있을 것입니다.

일일 스크럼 회의

일일 회의는 업무 시작 전 아침에 열립니다. 각 팀 구성원이 현재 프로젝트에서 누가 정확히 무엇을 하고 있는지 알기 위해 필요합니다. 이러한 회의의 최적 지속 시간은 15분입니다. 그 과정에서 아무런 문제도 해결되지 않기 때문에... 참가자들은 단지 정보를 공유할 뿐입니다. 해결이 필요한 문제가 있으면 회의 외부로 가져갑니다.

스크럼 마스터는 매일 회의를 진행합니다. 차례로 그는 각 참가자에게 다음과 같은 질문을 합니다.

어제 무엇을 했나요?
당신은 오늘 무엇을 할 것인가?
어떤 문제가 발생했나요?

스크럼 마스터는 모든 미해결 질문을 "작업 항목" 목록에 입력합니다. “뭐? WHO? 언제?". 다음은 이러한 목록의 간단한 예입니다.

배경 디자인 세부 사항 논의
톨리야와 콜야
점심 식사 직후

관심 있는 사람이라면 누구나 일일 회의에 참여할 수 있지만 모든 결정은 개발팀 구성원에 의해서만 내려집니다. 그 이유는 스프린트 목표 달성을 위한 참가자들의 헌신 때문입니다. 다른 사람이 의사 결정에 기여하면 그 사람은 팀 구성원의 책임을 제거하게 됩니다.

스프린트 검토 회의

각 스프린트가 끝나면 스프린트를 검토하기 위해 데모 회의를 갖는 것이 일반적입니다. 이러한 회의의 최적 기간은 4시간을 넘지 않습니다.

회의가 시작될 때 개발 팀은 제품 소유자에게 작업 버전을 보여줍니다(완료된 작업 결과 시연). 회의는 소유자 자신의 통제하에 이루어지며 관심있는 모든 사람과 대표자를 초대 할 권리가 있습니다.

회의 중에 제품 소유자는 스프린트 백로그의 어떤 요구 사항이 완료되었는지 평가하고 팀 및 고객과 결과를 논의하며 새 스프린트에서 완료할 작업을 함께 계획합니다.

회의 후반부에는 스크럼 마스터가 나머지 참가자들과 함께 지난 스프린트를 분석합니다. 개발팀은 이를 결정, 분석하고 결론을 도출하며 추가 작업을 개선할 결정을 내립니다.

회의가 끝나면 결과가 요약되고 다음 스프린트가 계획됩니다(이는 이미 논의한 일반적인 스프린트 계획 알고리즘에 따라 발생합니다). 두 번째 스프린트를 마친 후 새로운 데모 미팅을 진행하는 등 스크럼 프로젝트가 완전히 완료될 때까지 순회합니다.

스프린트 비상 정지

긴급 스프린트 정지는 특별한 경우에만 필요합니다. 팀은 이 스프린트에 설정된 결과를 달성하는 것이 불가능하다고 인식하는 경우 마감일(스프린트 완료 마감일) 전에 스프린트를 중지할 수 있습니다. 더 이상 스프린트 목표를 달성할 필요가 없으면 제품 소유자가 스프린트를 중지할 수도 있습니다.

스프린트가 중단되면 모든 프로젝트 참가자가 총회에 모여 중단 이유와 향후 조치를 논의합니다. 그 후에는 동일한 알고리즘이 사용되는 새로운 스프린트를 시작하고 계획하기 위한 승인이 제공됩니다.

스크럼 관행이 매우 간단하다는 것을 쉽게 알 수 있습니다. 그러나 스크럼 프로젝트 관리의 역할과 관행 외에도 다음과 같은 것들이 있습니다. 중요한 문서, 인공물이라고 합니다. 이미 간략하게 언급했지만 이 주제에 대해 좀 더 깊이 탐구하면 더 좋을 것입니다.

스크럼의 아티팩트

모든 스크럼 프로젝트에는 세 가지 주요 아티팩트(문서)가 있습니다.

제품 백로그
스프린트 백로그
스프린트 차트(번다운 차트)

각 유물에는 고유한 특성이 있습니다.

제품 로그

제품 백로그는 프로젝트 초기에 준비됩니다. 중요도별로 정렬된 요구사항 목록입니다. 이는 제품 소유자가 편집하고 개발 팀은 각 요구 사항을 구현하는 데 드는 비용 추정치를 포함하여 이를 완성합니다.

제품 백로그에는 개발에 필요한 기술 및 기능 요구 사항이 포함되어야 합니다. 이러한 요구 사항의 우선 순위를 정해야 하며, 가장 높은 우선 순위의 요구 사항을 자세히 기록하여 팀이 이를 평가하고 테스트할 수 있도록 해야 합니다.

시기적절하고 준비된 프로젝트 세부 사항을 작성하는 것뿐만 아니라 전체를 적시에 제공하는 것은 제품 소유자의 임무입니다.

스프린트 로그

스프린트 백로그는 제품 소유자가 이전에 컴파일한 제품 백로그에서 선택한 기능을 반영합니다. 각 기능은 작업으로 구분됩니다. 하나의 작업을 완료하는 데 이틀 이상 걸리지 않도록 분류가 이루어집니다.

기능을 작업으로 고품질로 분류한 덕분에 스프린트가 끝날 때까지 취소된 항목이 없도록 계획할 수 있으며 이는 반복 목표가 달성되었음을 의미합니다.

세부 작업이 완료되면 스프린트 백로그를 추정하고 이 추정치를 초기 제품 백로그 추정치와 비교합니다. 심각한 불일치가 확인되면 개발 팀은 제품 소유자와 협력하여 특정 스프린트 동안 완료해야 하는 작업량과 다음 반복으로 이월할 수 있는 작업량을 결정합니다.

반복 목표 달성에 큰 영향을 미치지 않는 사소한 작업은 스프린트 백로그에서 제외됩니다.

스프린트 일정

스프린트가 끝날 때까지 남은 총 작업량의 일일 변화를 표시하려면 스프린트 차트가 필요합니다. 이를 통해 팀은 현재 상황을 분석하고 적시에 변화에 대응할 수 있습니다.

또한 제품 소유자는 스프린트 일정을 사용하여 반복 진행 상황을 추적할 수 있습니다. 따라서 그가 확립하는 것은 매우 쉽습니다. 작업량이 매일 감소하지 않으면 프로세스에 약간의 편차가 있음을 의미하며 팀의 조치를 긴급하게 조정해야 합니다.

이는 스크럼 방법론의 일반적인 특징입니다. 이 방법을 더 자세히 이해하고 싶다면 Jeff Sutherland가 도움을 줄 것입니다. 이미 언급한 책 "스크럼 - 프로젝트 관리의 혁명적인 방법"을 확인하세요. 그리고 우리는 이것만 요약할 수 있습니다 간략한 개요스크럼.

스크럼에 대한 결론

따라서 방법 시스템과 관련하여 유연한 관리 Agile, Scrum은 프로젝트와 관련된 활동을 하는 사람들에게 진정한 발견이라고 안전하게 부를 수 있습니다. 장점 중 우선 지향성과 적응성이 돋보인다. 이 방법을 사용하면 언제든지 프로젝트 요구 사항을 변경할 수 있습니다(이러한 변경 사항이 구현된다는 보장이 없더라도). 그리고 이 기회는 고객에게 매우 매력적입니다.

둘째, 스크럼은 배우기가 매우 쉽습니다. 또한 이 방법은 많은 시간이 걸리지 않습니다. 그리고 작업 시스템이 반복 원칙(그리고 각 반복마다 고유한 목표가 있음)을 기반으로 구축되었기 때문에 스크럼 방법을 사용하면 각 스프린트가 끝날 때 제품의 작업 버전을 얻을 수 있습니다.

셋째, 이 방법은 최소한의 조정으로 대부분의 문제를 해결할 수 있는 다기능 및 자체 조직 팀에 중점을 둡니다. 이러한 이유로 스크럼 프로젝트는 스타트업 및 소규모 기업에 적합하며 전문 관리자를 교육하거나 외부 전문가를 고용할 필요가 없습니다.

하지만 스크럼 방법론이 모든 문제에 대한 해결책이자 성공을 보장한다고 생각해서는 안 됩니다. 또한 몇 가지 단점이 있습니다. 예를 들어, 미니멀리즘과 단순성은 비록 소수이지만 여전히 엄격한 규칙, 특히 팀 내 상호 작용 규칙을 결정하며, 이는 경우에 따라 고객에게 특정 불편을 초래할 수 있습니다.

또 다른 단점은 프로젝트 참가자의 모든 작업이 실시간으로 수행되기 때문에 계획이 부족하다는 것입니다. 그리고 마지막으로 팀에 집중하는 것도 항상 유용한 것은 아닙니다. 팀 조정이 특별히 필요하지는 않지만(따라서 비용이 들지 않음) 직원 채용, 교육 및 동기 부여 비용이 증가할 수 있습니다. 예를 들어, 노동 시장에 적합한 전문가가 충분하지 않은 경우 값비싼 전문가를 고용하거나 누구도 고용하지 않아야 합니다.

그러나 스크럼 방법론의 장점은 단점과 비교할 수 없으며, 어느 정도 끈기가 있으면 이를 익히는 것이 어렵지 않습니다. 스크럼을 사용하면 기업이 다양한 프로젝트를 구현하고 경쟁력을 높일 수 있습니다. 방법은 변화 지향적이며 끊임없는 발전, 그리고 그 유연성은 프로젝트 참가자들 간의 지속적인 상호 작용을 통해 달성됩니다.

하지만 이 리뷰는 순전히 정보 제공 목적으로만 작성되었음을 알려드립니다. 추가 정보어떤 경우든 제3자 소스를 이용해야 합니다. 그리고 그들로부터 스크럼 프로젝트 관리의 다른 복잡성과 해당 애플리케이션의 기능에 대해 배울 수 있습니다. 이 짧은 비디오로 시작해 보세요. 행운을 빌며 모든 프로젝트가 성공적으로 수행되기를 바랍니다!

프로젝트 관리 ,

기민한

제품 관리

"Agile은 단순한 Scrum 그 이상입니다."라는 글을 읽었을 때 ScrumTrek의 Certified Agile Professional 인증 과정에 대한 설명에서 제가 가장 먼저 생각한 것은 왜 ScrumTrek이냐, 그러면 AgileTrek이라고 불러야 했을까 하는 생각이었습니다. 이 훈련을 마친 후 나는 더욱 진지한 태도로 이 성명서를 다시 읽었습니다. 그럼 제가 훈련을 통해 무엇을 얻었나요? 메모, 유인물 및 Certified ICAgile Professional 인증이 필요하십니까? Agile이 무엇인지 이해하는 것은 어떻습니까? Agile 접근 방식의 개념은 무엇입니까? 애자일 사고방식이란 무엇입니까?

이 노트에서는 훈련에 대한 나의 인상을 공유합니다. 이것은 훈련 내용을 다시 말하는 것이 아니라 그로부터 얻은 지식의 이점에 대한 주관적인 평가입니다. 이 교육이 필요한지 결정하는 데 도움이 되기를 바랍니다.

애자일의 역사

트레이너가 전체 소프트웨어 개발 산업의 점진적인 성숙의 형태로 제시했던 Agile 이야기를 잘 기억합니다.

Code-and-Fix를 통해 업계는 개발자 자격에 대한 계획, 문서 또는 특별한 요구 사항 없이 비교적 저렴하게 코드 작성을 시작할 수 있었습니다.

1970년대에는 위험을 줄이고 소프트웨어 개발의 투명성을 높이며 개발자 자격에 대한 낮은 요구 사항을 유지하면서 높은 소프트웨어 유지 관리 비용 문제를 제거하는 폭포수 모델로 대체되었습니다. 이 모델은 모든 곳에서 사용되기 시작했고 문제가 빠르게 드러났습니다. Waterfall은 어떤 제품을 개발해야 하는지, 어떤 구현 기술을 사용해야 하는지 등 모든 것이 미리 알려져 있고 도중에 변경 사항이 발생하지 않는 경우에만 잘 작동합니다.

상황을 바로잡기 위한 첫 번째 시도는 1990년대 반복적 접근 방식의 출현과 관련이 있습니다. 한편으로는 컴퓨터 시간이 더 이상 객관적인 제한이 되지 않고 제품의 기능을 향상시키기 위한 반복적인 실험이 가능해지면 컴퓨터 가격이 인하되면서 이러한 현상이 촉진됩니다. 반면, 새로운 IT 기술로 인해 경쟁이 점점 심화되고 있으므로 기업은 이를 비즈니스에 빠르게 적용해야 합니다. 누가 구현했는가 새로운 기술그는 다른 사람들보다 먼저 고객과 시장을 모두 확보했습니다. 이 순간부터 기업에 신속한 기능 제공을 목표로 하는 유연한 개발 프로세스의 적극적인 개발이 시작됩니다. 본질적으로 "빠른" 코드 및 수정 방법으로의 롤백이 있지만 위험을 계획하고 제거함으로써 보완됩니다.

그건 그렇고, 오늘날 대부분의 기업 개발자는 그들이 생각하는 것처럼 스크럼을 전혀 사용하지 않고 반복 폭포수를 사용하는 것 같습니다. 아래 다이어그램을 보세요. 이것이 모두 작동하는 방식입니다. 그렇죠?

아니면 여전히 스크럼과 동일합니까?

1992년에 Crystal이 등장하여 처음으로 최종 사용자에게 작업 코드를 자주 제공하는 데 중점을 두었습니다. 그러다가 1994년에 비즈니스 요구 사항과 축소할 수 없는 수준의 소프트웨어 품질에 중점을 두는 DSM(동적 시스템 개발 방법)이 도입되었습니다(같은 해에 리팩토링이라는 용어가 등장했습니다). 마지막으로 스크럼 프레임워크는 1996년에 도입되었으며 애자일 개발 관리를 위한 사실상의 표준이 되었습니다. 같은 해에 처음으로 페어 프로그래밍이 사용되기 시작했습니다. 그리고 1999년에는 사용자 스토리(User Story), 출시 계획 및 지속적인 통합(Continuous Integration)의 개념을 가져온 XP가 등장했습니다. 이러한 모든 민간 계획의 결과는 2001년에 개발된 소프트웨어 개발을 위한 애자일 선언문으로, 기업에 기능을 신속하게 제공하기 위해 10년간 입증된 가치와 원칙을 담고 있습니다.

Agile의 추가 개발은 소프트웨어 개발 프로세스에서 가능한 모든 손실(다운타임)을 제거하여 기능 제공 속도를 더욱 높이려는 시도와 관련이 있습니다. 2003년에 린 소프트웨어 개발(Lean Software Development)이 개념을 적용하여 등장했습니다. 린 제조 Toyota가 소프트웨어 개발 산업에 진출했습니다. 2006년에는 비즈니스에 가치(기능)를 전달하는 흐름에서 낭비를 제거하기 위한 기성 알고리즘을 제시하는 Kanban 소프트웨어 개발의 등장으로 이러한 움직임이 계속되었습니다. 또한 2011년에는 SAAS(Software as a Service)의 폭발적인 성장에 맞춰 개발과 유지 관리를 결합하여 인터페이스에서 낭비를 없애는 DevOps 개념이 등장했습니다.

전체적으로 생산(개발)은 더 이상 병목 현상을 일으키지 않으며 가능한 한 빨리 비즈니스 요구 사항을 충족시키는 방법을 배웠습니다. 그러나 Agile 개발은 계속됩니다. 먼저 Agile을 확장하는 영역에서는 대기업(안전한). 둘째, 엄청난 양실패한 투자 프로젝트제품 개발에 대한 질문을 제기합니다. 어떻게 하면 가장 수요가 많은 제품을 최대한 저렴하게 개발할 수 있습니까? 2009년에는 린스타트업(Lean Startup)이 이러한 한계에 대한 해답이 되었습니다.

민첩한 가치와 원칙

트레이너는 참가자들과 함께 애자일 개발 선언문의 각 가치와 원칙을 일관되고 깊이 있게 분석합니다. 소프트웨어. 나는 훈련을 받기 전에 가치와 원칙을 완벽하게 이해했다고 진심으로 믿었음을 인정합니다. 이것은 전적으로 사실이 아닌 것으로 밝혀졌습니다.

예를 들어 두 번째 Agile 가치는 "포괄적인 문서보다 제대로 작동하는 제품이 더 중요합니다."입니다. 한때 이것은 진보에 대한 이해가 주로 다음을 기반으로 하는 폭포 모델에 대한 거부 선언이었습니다. 프로젝트 문서. 그러나 Agile Manifesto 버전 2에서는 "비즈니스 가치가 작동하는 제품보다 더 중요합니다"(Agile Manifesto 2.1 - "MoreAgile Manifesto")라는 문구가 변경되었습니다. 이것은 린 스타트업의 출현과 관련된 애자일 가치의 진화의 예입니다. 너무 많은 작동 제품이 누구에게도 쓸모가 없는 것으로 판명되었습니다.

스크럼과 칸반

교육의 중요한 부분은 Scrum Framework 및 Kanban에 대한 개요입니다. 훈련의 이 부분을 다시 설명하는 것은 이 노트의 목적이 아닙니다. 나는 코치가 당신의 손끝에서 모든 중요하지 않은 순간을 느낄 수 있도록 도와준다는 점만 주목할 것입니다. 팀 게임. 그러나 이것은 더 자세히 이야기할만한 가치가 있습니다.

애자일 게임

모든 게임은 배우기 쉽고 재미있게 플레이할 수 있었습니다. 훈련 둘째 날의 한 경기에서 참가자 중 한 명이 이렇게 외쳤습니다. “우리는 이전에 무엇을 하고 있었나요? 여기있어!" 아래에서는 우리가 게임에서 배운 내용에 대해 이야기하겠습니다.

페니/멀티태스킹 게임은 작업의 작은 부분을 수행하고 동시에 여러 작업을 수행하지 않아야 한다는 필요성을 실시간으로(스스로) 그리고 설득력 있게(일반 스톱워치를 사용하여) 시연했습니다. 우리는 이것이 엄격하게 순차적인 작업 프로세스(폭포수)에서 가동 중지 시간으로 인한 손실, 완료되지 않은 작업의 축적으로 인한 손실(입을 가득 채우면 씹는 데 더 오랜 시간이 걸림), 컨텍스트 전환으로 인한 손실(폭포수 모델에서는 직원은 동시에 여러 프로젝트에서 작업할 가능성이 가장 높습니다.)

플래닝 포커는 짧은 게임 내에서도 그 장점을 느낄 수 있을 정도로 평가팀에게 매우 간단한 기술입니다. 예를 들어, 게임 팀의 모든 구성원은 결국 대부분의 시간을 이 작업 또는 저 작업의 인건비를 추정하는 것이 아니라 처음에 다르게 이해했던 작업을 논의하는 데 소비한다는 데 동의했습니다. 즉, 주요 이점은 평가 횟수가 아니라 작업에 대한 동일한 이해에 있습니다. 반면에 시간이 부족하기 때문에 우리의 평가가 즉시 동의한다면 논쟁과 토론을 피했습니다. 간단한 일이지만 작업에서 이를 따르는 것이 얼마나 어려운 일입니까! 안 그래?

Daily Standup Meeting에서 장난스럽게 방해 행위를 벌이면서 우리는 애자일 가치에 대해 다시 논의하게 되었습니다. 예를 들어, 스크럼 마스터(프로세스 코치)가 개발팀의 관리자가 되거나 그에 따라 행동, 즉 작업을 분배하고, 감정을 개입시키고, 그룹에 반대하여 회의를 팀원들의 지루한 보고 회의로 만들어서는 안 됩니다. 그들 자신에게.

교육 비용: 개인용-25,250 루블. / 조직의 경우 - 29,260 문지름. 수료증:과정을 마치면 학생들은 PM Expert - PMI® 글로벌 등록 교육 제공업체로부터 인증서를 받게 되며 PMI Agile Certified Practitioner(PMI-ACP) 시험을 위해 24시간의 교육 시간(PDU)을 계산할 수 있습니다.

Talent Triangle별 PDU 분석

인위적인	전략적	지도
8	8	8

주석

지난 10년 동안 수천 개의 회사가 소프트웨어 프로젝트 관리에 새로운 접근 방식, 특히 Agile 원칙을 기반으로 하는 다양한 방법론을 적용하기 시작했습니다. 그 중 가장 유명한 것은 스크럼(Scrum)이다.

그러나 PMBOK® 역시 입지를 잃지 않고 있습니다. 대다수에 따르면 PMBOK® 또는 Scrum을 선택해야 합니다. 하지만 세 번째 방법이 있습니다. 이 과정에서는 PMBOK®의 철저함과 Scrum의 유연성을 결합하여 개발에 도움을 주는 방법을 배우게 됩니다.

이 과정의 모토는 "말에서 행동으로"입니다. 강좌 자료를 공부할 때 가장 중점을 두는 것은 실습입니다. 강좌의 60% 이상이 다음으로 구성됩니다. 실습 수업. 3일간의 수업을 통해 스크럼 방법론을 사용하는 방법을 이해할 뿐만 아니라 스크럼을 실제로 "느끼게" 됩니다.

훈련의 목적(결과)

워크숍 동안 참가자는 다음을 수행할 수 있습니다.

Agile 방법론의 기본 아이디어를 통해 개발자의 "영원한" 문제를 어떻게 해결할 수 있는지 이해하세요.
스크럼과 같은 상대적으로 간단한 프로세스가 소프트웨어 개발의 효율성과 생산성에 어떻게 큰 영향을 미칠 수 있는지 이해하세요.
Agile 커뮤니케이션 도구를 사용하는 방법을 알아보세요.
유용하고 실용적이며 신뢰할 수 있는 계획을 세우는 방법을 알아보세요. 강좌가 소개됩니다 다양한 기술포커 계획을 포함한 평가를 통해 적시에 고객이 원하는 결과를 얻을 가능성이 크게 높아집니다.
정리하는 방법 이해하기 효과적인 작업고객에게 가장 유용한 제품을 적시에 개발하기 위해 이해관계자와 협력합니다.
개발 효율성을 여러 번 높이기 위해 스크럼 팀의 작업을 구성하는 방법을 알아보세요. 소프트웨어 유지 관리가 중요한 역할을 하는 조직의 직원에게는 칸반에 관한 과정 섹션이 흥미로울 것입니다.
소프트웨어 개발 프로젝트 관리에 있어 상당한 실무 경험을 갖춘 최고의 전문가로부터 질문에 대한 답변과 조언을 얻으세요.
제품 백로그, 스프린트 백로그, 일일 스크럼 회의, 스프린트 계획 회의, 번다운 차트 등과 같은 스크럼 도구 작업을 실질적으로 마스터하세요.
다양한 복잡성과 범위의 프로젝트에 스크럼을 사용하는 방법을 이해합니다.
스크럼 구현이 때때로 심각한 어려움을 겪는 이유를 이해하고 문제를 처리하는 방법을 이해합니다.

코스 트레이너

Nikolay Ryamzin, CSM, RMR, RME - 선도적인 컨설턴트 PM 전문가

청중

과정을 완료하면 24 PDU가 수여됩니다.

교육 프로그램 설명

지식 분야로서의 프로젝트 관리는 많은 상업 및 실무 분야에서 확고히 자리 잡았습니다. 국영 기업그리고 조직. 그러나 주로 지적 영역에서 여러 프로젝트를 실행하는 동안 "고전적인" 접근 방식이 밝혀졌습니다. 프로젝트 관리부분적으로만 작동하거나 전혀 작동하지 않습니다.
프로젝트에 많은 양의 분석 작업을 해결하는 경우, 프로젝트의 상황이 매일 또는 매시간 변경되는 경우, 프로젝트에 5/9로 구성된 소규모 전문가 팀이 포함되는 경우, 프로젝트가 미래의 내용과 기능을 자주 변경하는 경우 작업이 정시에 필요한 품질 수준으로 완료되어야 한다면 프로젝트 관리에 유연한(민첩한) 접근 방식을 사용해야 할 수도 있습니다. 스크럼 방법은 가장 인기를 얻었으며 정보 기술, 금융, 교육, 경제 등 경제의 다양한 부문에서 성공적으로 사용됩니다. 과학적 연구등.
스크럼 애자일 프로젝트 관리 과정은 프로젝트 팀에게 가장 발전된 애자일 방법을 사용하여 첨단 기술 프로젝트를 보다 효과적으로 계획, 실행 및 제어할 수 있는 도구를 제공하도록 설계되었습니다.
과정을 마친 후 학생은 다음을 수행하게 됩니다.
알다:

스크럼 구현 시 유연한 프로젝트 관리(PM)의 주요 프로세스 및 이벤트
PM의 유연한 방법에 대한 기본 정보를 찾는 방법;
PM의 고전적인 접근 방식과 Scrum에서 제안한 접근 방식의 차이점
스크럼 방법을 사용하여 프로젝트 관리를 구성하는 기능
스크럼 프로젝트의 라이프사이클.

가능하다:

프로젝트 이해관계자를 식별합니다.
최종 결과로부터 이해관계자의 목표와 기대를 결정합니다.
요구 사항을 공식화하고 사용자 스토리를 정의합니다.
스프린트를 위한 계획 작업
스프린트의 진행 상황을 제어합니다.
프로젝트 중 변경 사항을 관리합니다.
스크럼 프로젝트 중 위험을 식별, 분석 및 대응합니다.
위험을 관리합니다.

소유하다:

제품 백로그 작성 기술;
스프린트 백로그 생성 기술;
스크럼 프로젝트에서 회의를 개최하는 기술;
결과를 보여주는 기술.

이 과정을 성공적으로 이수하면 전문가는 다음을 수행할 수 있습니다.
스크럼 프로젝트의 전반적인 진행 상황을 관리합니다.

코스의 목적

스크럼(Scrum) 방식을 활용한 프로젝트 수행 분야 전문역량 형성 및 향상

타겟 고객

개발 및/또는 구현 프로젝트와 관련된 활동을 수행하는 전문가 정보 시스템(이다):

관리자 및 분석가,
프로젝트 팀원

필요한 준비

IS 개발 및/또는 구현 프로젝트에 참여한 경험.
UP130 "프로젝트 관리 기초" 과정에서 지식과 기술을 갖추거나 이 과정을 수강하는 것이 좋습니다.

유연한(민첩한) 프로젝트 관리 소개.
스크럼 방법을 사용한 프로젝트 관리의 기본입니다.
스크럼 방법에 대한 일반적인 설명입니다.
스크럼 프로젝트의 라이프사이클.
스프린트의 정의.
스크럼 프로젝트의 주요 아티팩트입니다.
스크럼 방식을 사용한 프로젝트 구성
프로젝트 외부의 역할. 이해관계자. 프로젝트 고객(Customer), 후원자(Sponsor), 소비자 최종 제품(사용자)
역할 프로젝트 팀(스크럼 팀, 스크럼 팀). 제품 소유자. 스크럼 마스터. 개발팀.
스크럼 프로젝트의 라이프사이클
개시. 우선순위가 높은 제품 백로그 생성.
계획 및 평가. 사용자 스토리 개발 및 평가. 과제의 형성 및 평가. 스프린트 계획. 플래닝포커.
실행. 프로젝트 결과물 생성. 스프린트 구조, 포커스 팩터. 일일 스크럼 미팅을 실시합니다.
제어. 스프린트 리뷰. 스프린트 회고전. 스프린트를 취소하세요.
완성. 프로젝트 결과 승인. 프로젝트 회고.
스크럼 방법을 사용한 프로젝트 관리의 추가 측면
변경 관리. 스크럼 프로젝트를 변경합니다. 스프린트 중 변경 사항.
품질 관리. 그루밍(제품 백로그 관리). 스파이크(인에이블러 - 기록).
위험 관리. Scrum 방법을 사용하여 프로젝트 중 위험 관리.
프로젝트 활동의 문서

실용적인 수업

강요 수명주기스크럼 - 프로젝트.
제품 백로그 생성. 사용자 스토리의 분해 및 우선순위 지정.
작업 단계(스프린트) 계획, 스프린트 백로그 컴파일. 사용자 스토리 및 작업 평가.
작업 단계의 실행. 일일 팀 회의(일일 스크럼 회의).
얻은 결과를 고객에게 시연합니다(스프린트 검토 회의).
작업단계 결과 회의(스프린트 회고회의)
스크럼 프로젝트 관리 및 작업 단계. 시각화 도구 작업: 작업 보드 및 번다운 차트. 성능 평가.
스크럼 프로젝트의 위험 관리.

받은 문서

고급 훈련 증명서 및 국제 증명서.