---

Scrum 프레임워크 이전의 혼란과 좌절은 무엇 때문에 생겼을까요? 놀라실 수도 있습니다!

Scrum 프레임워크가 소프트웨어 엔지니어링 실천과 사업에 미치는 영향을 더 잘 이해하려면 소프트웨어 프로젝트의 하루를 살펴보는 것이 좋습니다.

그러므로 조직에 Scrum 개발 및 소프트웨어 제공 프레임워크를 도입하기 전 과거의 소프트웨어 프로젝트를 잠시 이야기하고 싶습니다.

이 글을 쓰기 며칠 전, 거의 20년 전에 함께 일했던 옛 동료와 점심을 먹었습니다.

Marcus는 다음을 취득했습니다. Scrum Master 자격증 및 Scrum Product Owner 자격증 발급 기관은 International Scrum Institute™는입니다. 현재는 애자일 프로젝트 관리 소프트웨어 분야의 선도적인 소프트웨어 회사에서 Scrum Master로 일합니다.

Scrum Master로서 Marcus는 지금 전 세계 여러 지역에 지리적으로 분산된 구성원들로 이루어진 애자일 Scrum 팀을 지원합니다.

점심을 먹으며 Marcus는 분산 애자일 Scrum 팀에 전형적인 어려움이 많다고 인정했습니다. 자신의 소프트웨어 프로젝트 구조와 관련하여 구체적으로 언급한 문제는 다음과 같습니다.

• Scrum 팀원 간 업무 방식 차이,
• 시차,
• 문화적 부조화,
• 언어 제약.

이러한 어려움에도 Marcus는 애자일 Scrum 프로세스로 소프트웨어 프로젝트를 운영하는 것이 20년 전의 업무 방식보다 더 즐겁고 생산적이며 풍요롭다고 덧붙였습니다. Scrum 소프트웨어 개발 및 제공 프로세스 없이 일하던 때와 비교해서 말입니다.

Marcus의 말은 매우 뛰어나고 경험 많은 관리자이자 Scrum Master, Product Owner가 전하는 Scrum 프레임워크의 가치에 대한 강력한 증언이었습니다.

Marcus, 감사합니다!

그런 다음 저희는 Scrum 프레임워크를 도입하기 전 과거의 소프트웨어 프로젝트 하나를 설명했습니다. 많은 Scrum Master가 자격증 취득 전 프로젝트에서 비슷한 경험을 했을 것이라고 확신합니다.

1990년대 후반 저희는 스마트카드 기반의 다음 시스템을 만드는 소프트웨어 엔지니어링 그룹에 속해 있었습니다. 공개 키 기반 구조. 스마트카드는 기반 구조 구성원의 개인 키를 안전하게 보호했고, 관련 공개 키와 이를 감싸는 인증서는 공개라는 이름처럼 공개적으로 배포했습니다.

당시에는 이것만으로도 상호 의존적인 여러 하드웨어 및 소프트웨어 엔지니어링 팀이 필요한 비교적 복잡한 IT 프로젝트였습니다. 저희는 막대한 양의 연구개발(R&D)을 수행해야 했습니다 . 완전하게 작동하는 하드웨어 및 소프트웨어 시스템을 만들기 위해서였습니다.

그 프로젝트에서는 아직 다음 개념을 사용하지 않았다는 점을 기억하세요. 최소 기능 제품(MVP) 즉 실험하고 만들고 배우고 다시 실험하는 개념입니다.

Scrum 없이 수많은 하드웨어와 소프트웨어 요소로 이루어진 정교한 기반 구조를 만드는 일은 정말 어려웠습니다.

다음은 세 가지 주요 차질입니다 . 팀에 Scrum Master나 Scrum Master 자격증 보유자가 전혀 없을 때 겪었던 일입니다.