SCRUM 또는 그 파생물이 소프트웨어 개발 관리를위한 좋은 방법 일 것임을 이해함으로써 내 질문을 시작하고 싶습니다. 모든 대기업과 관리자가 그것을 사용하거나 사용한 것처럼 보이며 실제로 모든 경험을 다룰 수는 없습니다. 그러나 나는 "이유"를 이해하기 위해 고군분투하고 있으며 직장에서의 모든 독서와 공식 스크럼 훈련조차도 나를 위해 일하지 않습니다. 그것은 단지 모든 수사입니다. 그래서 나는 여기에 답을 찾고 있습니다.
지금까지 나는 4-5 명으로 구성된 팀에서 훈련, 방법론 또는 특수 소프트웨어없이 매우 효과적으로, 완전히 자체 구성되었습니다. 큐브 토론, 임시 회의 및 일대일 코드 검토 나는 지금 직장에서 스크럼이가는 길이며 그에 따르는 모든 것이 있다고 들었습니다. 그들이 나에게 스크럼을 설명 할 때, 나는 다음과 같은 것을 읽습니다.
- 프로세스 및 도구에 대한 개인 및 상호 작용
- 포괄적 인 문서에 대한 작업 소프트웨어
- 계약 협상을 통한 고객 협업
- 계획에 따라 변경에 응답
대단하지만 모두 상식 인 것 같습니다. 왜 이것이 성문화되어야합니까? 그런 다음 방법론이 변화에 대응하는 데 도움이된다고 들었습니다. 어떤 특정SCRUM의 측면은 내가 이전에 임시 회의, 큐브 토론 및 개발자 계획 회의로 달성 할 수 없을 정도로 유연 해졌습니까? 그들은 매 2 주마다 작업 결과물 또는 스프린트를 가져야 할 필요성을 설명합니다. 내 특정 프로젝트에는 "클라이언트"가 없으며 소프트웨어가 1 년 이상 완료되지 않으며 그 동안 매월 최고 경영진에게만 시연 할 것입니다. 그렇다면 격주로 결과물을 명시 적으로 필요로하는 이유는 무엇입니까? 팀 전체가 다음 스프린트에 대한 이야기와 과제를 제시하는 스프린트 계획 회의의 중요성을 강조합니다. 이것은 내가 과거에 한 즉석 계획 회의와 다르지 않습니다. 매주 월요일마다 왜 발생해야합니까? 그리고 왜 전체 팀이 참여해야합니까? 나는 제품을 "소유"하는 모든 구성원의 개념을 이해하지만 실제로는 소수의 개인 만이 실제로 각 이야기를 작업으로 나누는 데 기여할 수 있지만 나머지는 그냥 볼 수 있습니다.
다시 말하지만, 대다수의 사람들이이 과정의 배후에 있다는 것을 이해하고, 그것이 작동해야하며, 탑승해야합니다. 왜 그런지 이해하고 싶습니다. 내가 이미 이런 것들을 연습하고 불필요하게 그것들을 체계화하는 것을 좋아하지 않는 나의 문제는? 아니면 이러한 기술이 부적절하게 수행되어이 기술의 장점을 아직 보지 못했을까요? 모든 현실 이에, 개인 정보 나 조언은, 내가 수신에 사용하고있어 손님을 끄는 반대로 매우 감사하겠습니다.