애자일 개발 도입에 대해 생각하기 전에 먼저 조직 / 프로젝트에 가장 적합한 것을 탐색하십시오. 예를 들어 스크럼을보고 있다면 엄격하게 사용하는지 아니면 더 느슨한 형태의 스크럼 또는 다른 방법이 더 잘 맞는지 고려하십시오. 내 대답은 민첩한 방법으로 스크럼에 있습니다.
스크럼은 거의 알려지지 않았으며 실험이 필요한 혁신이 필요한 프로젝트에 적합합니다. 기존 제품 유지 관리 또는 반복적 인 유지 관리 작업 처리와 같은 작업에 가장 적합하지 않습니다. 다행히도 스크럼은 느슨한 프레임 워크이므로 최선의 방법으로 사용할 수 있습니다.
유지 관리 작업의 경우 Kanban이 더 좋을 수도 있고 스프린트를 관리하고 일일 스탠드 업과 같은 작업을 수행하기 위해 몇 가지 스크럼 요소를 시도 할 수도 있습니다. 나는 이것을 "스크럼-하지만"이라고 부릅니다. "그렇습니다. 우리 회사에서 스크럼을 수행하지만 ..." 괜찮습니다. 기분 나쁘지 않습니다.
조직에 적절한 스크럼을 도입하려면 제품 소유자 및 이해 관계자의 참여가 필요합니다. 소규모 회사 인 경우 그 사람은 한 사람, 보스, 큰 회사에서는 제품 관리자 및 부서 책임자 일 수 있습니다. 스크럼을 도입하는 두 가지 방법을 제안합니다.
1) 기존 작업 대기열을 즉시 관리하기 위해 약간 느슨한 형태로 스크럼을 사용할 수 있습니다. 그러나 칸반도 살펴보십시오.
2) 혁신, 조기 피드백이 필요하고 알려지지 않은 새로운 프로젝트에서 스크럼을보다 엄격한 형태로 사용하기 시작하십시오. 스크럼이이 새로운 프로젝트에 이상적이라고 보스 / 제품 소유자에게 제안 할 수 있습니다.
하지만 기억해! 이것은 코드에만 국한된 것이 아니라 제품 소유자가 중요한 역할을하며 자신의 역할을 이해하고 이행해야합니다. 예를 들어, 최소로 시작하고, 빠르게 반복하고, 피드백을 받고, 학습하고 피드백을 제공하는 등 모든 사양을 미리 작성하지는 않습니다. 제품 소유자와 마찬가지로 스크럼을 소개하는 데 관심이있는 제품 관리자와 함께 작업 해보십시오. 이상적으로는 관리 요청을 차단하고 스프린트를 보호 할 수있을 정도로 강해야합니다.
개발 및 제품 관리에서 스크럼을 도입하려면 통합 노력이 필요합니다.
이러한 새 프로젝트에서 새 팀을 별도의 방으로 옮기고 포스트잇 메모를 사용하여 백 로그, 진행 중 등 다양한 상태의 작업을 시각화하십시오.이 단계에서 전자 도구에 얽매이지 마십시오. 가능한 한 간단하게 유지하십시오. 팀을 시작할 때 카드로 포커를 계획하는 것을 바보처럼 생각하지 마십시오. 팀이 속도를 맞추면 숫자를 말하지 않을 것입니다.
내 경험상 스크럼을 순수한 형태로 도입하는 것이 더 쉬우 며 더 많은 유지 보수 유형의 작업 대기열을 위해 완화시킵니다. 다른 방법으로는 더 어렵습니다.
마지막 의견은 스크럼이 일부 개발 만병 통치약이라는 점을 명심하는 것입니다. Scrum은 제품 혁신을위한 유용하고 간단한 프레임 워크이지만 비즈니스에서 요구하고 나쁘지 않은 방법으로 결합 된 다른 방법을 탐색합니다.