제품 소유자가 사용자 스토리를 스크럼에 작성해야한다는 것을 알고 있습니다.
사용자 스토리는 최종 사용자를위한 기능을 설명합니다.
그러나 기술적으로 개발해야 할 사항과 구현 방법을 설명하는 사람
스크럼에 관한 정보는 어디에 저장되어 있습니까?
정말 흥미로울 것입니다!
개발자가 스토리를 구현하기 시작할 때 회사에 대한 지식이 부족하지만이를 구현하는 방법을 모릅니다.
예를 들어 레거시 COM API를 처리해야하며 처리 방법을 모릅니다. 또는 WPF / WEB 또는 그 밖의 기술에 능숙하지 않습니다.
스크럼은 사람들이 사용자 스토리를 시작하는 데 어떻게 도움이됩니까?
답변:
민첩하지 않은 증오 자. 구현 세부 사항을 구체화하고 수행해야 할 작업을 결정하는 것은 스프린트 계획 회의에서 발생하며, 이는 사용자 스토리를 스프린트에 대한 실제 작업 / 요구 사항으로 바꿉니다. 많은 민첩한 프로세스의 실패는 스프린트 계획 회의가 실제로 개발자들에 의해 주로 수행된다는 것입니다. 단지 제품 소유자라면 달을 얻기로 결정할 것입니다. 여기에 다음과 같은 (사악한) 사용자 이야기가 나옵니다.
As a non-technical user, I need to have a simpler interface with the API
제품 소유자는 어떤 사용자 스토리가 가장 우선 순위가 높은지를 정의하지만 프로그래머는 이러한 우선 순위를 취하여이를 작업 목록 (스프린트 백 로그라고 함)으로 전환합니다. 여기에서 당신이 어떻게 구현할 것인지에 대한 아이디어를 얻을 수 있습니다. 스프린트 백로 그는 당신이 원하는대로 기술적으로 될 수 있습니다. "더 간단한 API를 달성하려면 미친 COM API를 리팩터링해야합니다. 누구나 어떻게 사용하는지 알고 있습니까?" 대답이 "Hell No"이면 해당 사용자 스토리의 범위가 생각보다 클 수 있음을 알 수 있습니다. 따라서 사용자 스토리를 작업으로 나눌 수 있습니다.
이를 감안할 때 사용자 스토리를 협상하여 더 작은 변경으로 나누는 것이 좋습니다. 민첩한 방법론은 사람이 원하는 단계로 단계적으로 접근하고 싶다는 것을 의미합니다. "이봐 요. 한 번의 반복으로 API를 정밀 검사 할 수 없습니다. 기술이 아닌 고객 인 경우 잘 문서화 된 API가 필요합니다."
개발자 팀은 기술적 인 내용을 작성합니다. 스크럼은 약간의 기술적 인 도움을 제공하지만 도움이되지는 않습니다. 사용자 스토리 시작하기 스크럼은 거의 What-World 전용입니다. 기술 분석은 How-World 입니다.
스크럼이 제공하는 분석은 다음과 같습니다.
사람들이이 위에 자주 사용하는 고장은 다음과 같습니다.
또한 팀은 수행해야 할 것으로 알고 있지만 (프로젝트를 시작할 때 모든 사람을 위해 IntelliJ IDEA 설치) 비즈니스 가치가없는 기술 작업 을 작성할 수 있습니다 .
작업을 분석하는 방법에 대한 자세한 지침은 XP (익스트림 프로그래밍), 클린 코드 , 실용 프로그래밍 , 소프트웨어 엔지니어링 , CRC- 카드 , OOP / OOA / OOD , 디자인 패턴 , 리팩토링 , 레거시 코드를 사용한 효과적인 작업 , TDD ( 테스트 주도 개발), BDD (행동 주도 개발), ATDD (허용 테스트 중심 개발).
이 무엇-세계 와 방법 세계 . 올바르게 느꼈 듯이, 사용자 스토리 는 사용자를 위한 것이며 What-World 에서 비즈니스 가치 ( 일차적 인 2 차 가치) 를 생성 합니다. 스크럼은 대부분 What-World 전용입니다. How-World 에 대해서는 아무 것도 말하지 않고 기본적으로 "How-World는 개발자 팀의 책임"입니다.
일반적으로 How-World에 대한 백 로그 항목 은 사용자 스토리가 아니라 기술 작업 또는 하위 작업 이라고 합니다. 많은 도구는 분해 허용 사용자 스토리 로부터 무엇-세계 로 하위 작업 의 방법 세계 .
How-World에 대한 Scrum의 도움은 Sprint Planning Meeting 의 몇 가지 지점에서 끝납니다 .
백 로그 개선 회의 또는 스프린트 계획 회의 의 두 번째 부분 (일부 팀의 경우 스프린트 계획 2 회의) 에서 사용자 사례를 하위 작업으로 분류하는 것이 도움이된다는 것을 알았습니다 .
경험이 부족한 팀으로 인해 백 로그 개선 및 스프린트 계획 중에 원자 사용자 스토리 를 위해 노력하는 것이 도움이된다는 것을 알았습니다 . 원자 사용자 스토리는 비즈니스 가치를 완전히 잃지 않고 더 작은 사용자 스토리로 세분화 될 수없는 사용자 스토리입니다. 일반적으로 사용자 스토리는 원자 일 필요는 없습니다. 경험이 부족한 팀에게 도움이된다는 것을 알게되었습니다.
그리고 사용자 스토리로 "기능 X의 (아키텍처 | 디자인 | 구현 | 테스트)"를 수행하지 마십시오. 이것을 하위 작업으로 피하는 것이 좋습니다.
Atomic User Stories를 가지고 있고 수용 기준을 제외하고 추가 분석이 필요한 것 같으면 어떤 것이 최적의 수준에서 작동하지 않는다는 것을 의미합니다. 아키텍처가 잘못되었거나 너무 복잡하여 비즈니스 지향적 이라기보다는 기술적 것입니다. 또는 팀이 경험이 없습니다. 아니면 둘다. 어쨌든, 지식을 훈련시키고 전파함으로써 상황을 개선하기위한 조치가 필요합니다.
오늘날 스크럼 마스터는 대부분 관리자 역할 로 이해되며 헛소리입니다. 원래, 스크럼 마스터가 있었고, 나는이를 옹호하는 기술의 역할 단지 등이 아닌 관리 역할, 코치 에 XP .
스크럼 이 하우 월드에 대해 거의 아무 것도 말하지 않기 때문에 스크럼 과 스크럼 마스터에 의지하는 것은 너무 쉬운 일이므로 큰 차이에 빠지게됩니다 .
이상적으로, Scrum Master는 팀의 모든 사람들이 마음 속 깊이 "검사 및 적응"할 때까지 충분한 관리 및 의사 소통 기술을 보유한 숙련 된 개발자들 사이에서 회전합니다. 누구와도 동시에 스크럼 마스터가 될 수 없습니다.
그러나 스크럼 마스터리는 테이블 청소와 설거지가 아니라 요리와 비슷합니다. 모두가 할 수 있듯이 누가 테이블을 청소하고 설거지를하는지 회전시킬 수 있습니다. 그러나 요리를 할 수 없거나 요리를 좋아하지 않는 사람들이 있고 좋은 음식을 먹고 싶어하기 때문에 모든 사람에게 요리를 돌리고 싶지 않을 것입니다.
전문가 개발자들 사이에서 Scrum Master를 교체하는 것이 좋은 점은 팀이 더 많은 방법에 대해 배울 가능성이 높다는 것입니다.
Scrum의 관점에서, 팀은 이상적으로 Scrum Master 의 도움으로 스스로를 찾아야합니다 .
스크럼은 또한 개발팀 과 만 이야기합니다 . Scrum에는 Architect 또는 Lead Engineer 와 같은 역할 이 없습니다. 그것은 그들이 금지되었다는 것을 의미하는 것이 아니며, 스크럼이 그들에 대해 아무 말도하지 않는다는 것을 의미합니다. 스크럼은 자체 조직 팀을 선포합니다. 즉, 팀이 건축가를 선언하면 팀에 건축가가 있습니다. 그것은 Scrum에 의해 정의되지 않았지만 Scrum과 호환됩니다. 나는 전담 건축가를 선포하지 않고 있습니다 (지정된 건축가로 수년간 근무했으며, 그것을 좋아했지만 기본적으로 지정된 건축가의 아이디어에 반대합니다).
사용자 스토리에는 수락 기준이 있습니다. 이 합격 기준은 합격 시험 으로 바뀝니다
자세한 내용 은 프로그래밍 프로젝트를 다른 개발자를위한 작업으로 나누는 방법을 참조하십시오 .
도움이 되었기를 바랍니다.
팀에서 최고의 자격을 갖춘 사람은 제품 소유자의 요구 사항을 실행 가능한 사용자 스토리로 세분화해야합니다. 내 경험상 다음과 같은 접근 방식을 사용했습니다.
개발자가 스토리를 구현하는 방법을 모른다면 다음 중 하나에 해당 할 수 있습니다.
Udemy의 SCRUM에서이 과정을 무료로 수강하고 SCRUM 프로세스의 개별 측면에 대해 배울 수 있습니다 ( https://www.udemy.com/scrum-methodology/).
이것은 민첩한 문제가 아닙니다. 문제는 팀에 사용자 스토리 (민첩) 또는 요구 사항 (전통)을 완료하기에 충분한 기술 지식이 없다는 것입니다. 이 상황에서 애자일이 도움이 될 수 있습니까? 아니요, 팀을 신중하게 선택하지 않았고 팀의 어느 누구도 자신의 작업을 수행하기에 충분한 기술 경험이없는 경우. 예, 일부 팀 구성원이 다른 팀 구성원이 자신의 작업을 수행하도록 도울 수있는 훌륭한 기술 지식을 보유하고있는 경우. 그 팀은 스스로 조직해야하며, 강점과 약점을 알아야합니다.
다음 민첩한 원칙을 기억하십시오.
"최고의 아키텍처, 요구 사항 및 디자인은 자체 구성 팀에서 나옵니다."
이는 애자일 환경에서 팀의 신뢰가 높고 업무를 위임하기 때문에 발생합니다.