Scrum 팀은 계획 회의에서 개발 / 인프라 작업을 어떻게 설명합니까?
언뜻보기에는 최종 사용자 가치를 제공하지 않기 때문에 사용자 이야기처럼 보이지 않습니다.
그러나 특정 사용자 스토리에 작업으로 첨부하는 것도 때로는 의미가 없습니다. 예를 들어, 작업이 "Setup Bamboo"라고 가정하십시오. 팀이 수동으로 구축 및 배포 할 수 있으므로이 작업은 사용자 스토리를 완료 할 필요가 없습니다. 따라서이 작업이 사용자 스토리를 완료하는 데 필요하지 않으므로 사용자 스토리에 첨부하는 것은 의미가 없습니다.
따라서 이러한 작업이 사용자 스토리가됨을 나타냅니다. 그러나 팀 스토리가이를 지적하면 제품 소유자가 수많은 기술 사용자 스토리가 첨부 된 백 로그가 아닌 백 로그에 대한 속도를 알고 싶어하기 때문에 속도가 이상하게 변경됩니다.
답변:
그들은 실제로 사용자 이야기가 아닙니다. 그들은 이해 관계자의 이야기입니다. 소프트웨어가 실제로 사용자가 직접 비용을 지불하지 않는 한, 스토리가 완전히 이익을 위해 만들어지는 경우는 거의 없습니다.
몇 가지 예를 들어 보겠습니다.
대부분의 기술 사례는 실제로 비즈니스 이점을 제공하지만 사용자에게는 거의 해당되지 않습니다. 다른 방식으로 표현하면 도움이 될 수 있습니다. 나는 보통 Chris Matts의 Feature Injection 템플릿을 사용합니다.
In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.
이는 개발 팀을 포함한 모든 종류의 이해 관계자를 명시 적으로 인식합니다. 이제 비즈니스 이점을 불러 와서 기술 스토리를 표현할 수 있습니다.
In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.
나는 이것에 관한 몇 가지 블로그 게시물을 썼습니다 : 그것들은 사용자 이야기가 아니며 , 기능 주입 및 기술 기사 다루기 . 그들이 도움을 바랍니다.
속도는 (드래그와 달리) 유용한 작업을 수행 할 수있는 팀의 능력을 측정 한 것입니다. 인프라 작업은 팀을 장기적으로보다 효율적으로 만들어서 간접적이지만 최종 사용자 가치를 제공합니다. 나는 사용자 스토리 (이 경우 사용자는 개발자 팀)로 이러한 것들을 추적하고 적절하게 우선 순위를 지정하는 데 아무런 문제가 없습니다. 고객과 의사 소통이 잘되는 제품 소유자는 결과물을 방해하지 않고 그러한 작업이 적합한 위치를 파악할 수 있어야합니다.
점차적으로하십시오.
이해 관계자가 원하지 않으면 이야기하지 마십시오. 한 번에 조금만 돌봐주세요. 예를 들어, 수동으로 처음 배포 할 때 두 번째로, 당신은 약간 자동화합니다. 세 번째로, 당신은 조금 더 자동화합니다. 결국, 빌드가 가장 큰 문제는 아니므로 다른 것에 집중하십시오.
처음에는 이러한 개발자 중심의 작업이 더 많을 것입니다. 당신의 속도 (스토리로 측정)는 더 낮아질 것입니다. 상황을 올바르게 표현한 것입니다. 그러나 당신은 항상 일부를 가질 것이므로 팀이 프로세스를 개선하는 데 필요한 일을하는 습관을들이는 것이 중요합니다.
이상적인 접근 방법 IMHO는 인프라 스트럭처 노력을 사용자 스토리의 첫 번째 가치가되는 작업으로 배치하는 것입니다. 당신이 언급했듯이.
당신의 모범을 보임; 수동으로 구축하고 배포한다는 것은 지속적인 노력이며 완성 된 형태가 없음을 의미합니다. 무한정 존재합니다.
이전에 수동으로 수행 한 일반적인 응용 프로그램에서 모든 노력을 자동화하는 코드에 대해서도 마찬가지입니다. 사용자 스토리에서 작업으로이 노력을 정의하는 것은 완전 함을 정의합니다. 본질적으로 최종 사용자에게 가치가 있습니다.
각 스프린트마다 확실히 애플리케이션을 빌드하고 배포 할 수 있지만 백 로그를 통해 공식적으로 추적되지 않는 일상적인 작업의 일부가되고이 모든 것이 무례하게됩니다.
사용자 스토리는 사용자 관점에서 비즈니스 가치를 정의합니다. 이러한 인프라 작업으로 인해 일반적으로 "폐기물"로 간주됩니다. 반드시 필요하지 않다는 의미는 아닙니다. 더 많은 인프라 작업을 수행하면 비즈니스 가치가 낮아집니다. 이러한 인프라 작업으로 인해 사용자가 사용자로 간주해서는 안되며 사용자 스토리에 첨부해서는 안됩니다.
계획 회의 팀에서는 다음 스프린트 동안 어떤 인프라 작업이 절대적으로 필요한지 고려해야합니다. 이러한 인프라 작업을 염두에두고 약속합니다. 속도는 팀이 제공 할 수있는 비즈니스 가치를 측정하기 때문에 올바른 결과 인 팀 속도에 영향을 미칩니다.
나는 사용자 스토리를 최종 사용자 가치를 제공해야한다고 생각하지 않았습니다. 일반적이지만 사용자 스토리를 처리하는 방식은 아닙니다. 때로는 이러한 유형의 작업이 급격한 것으로 간주되지만 다른 사용자 사례와 마찬가지로 일반적인 사용자 사례가 있습니다.
내가 본 많은 인프라에서 주어진 것으로 간주됩니다. 여기에는 다음과 같은 것들이 포함됩니다 :
내가 작업 한 대부분의 방법론은 그들에게 많은 관심을 기울이지 않습니다. 이것들은 제가 Release 0이라고 부르는 형태입니다. 개발을 시작하기 전에 준비해야합니다. 스토리에 대한 작업을 시작하면 이러한 변경 사항이 프로세스 개선으로 추적 될 수 있습니다.
개발 팀에 의견이있을 수 있지만 대부분의 항목은 프로젝트 지원 팀이 처리해야합니다. 여러 프로젝트에서 이러한 항목을 표준화하면 조직에 상당한 투자 회수가 이루어져야합니다.
다음을 고려하세요:
기존 제품군에 주요 기능을 추가하는 Scrum 팀.
엔지니어링 모범 사례를 기반으로 최신 상태를 유지하려면 개발 기술 / 도구 / 유틸리티를 업그레이드해야합니다.
이 작업을 통해 릴리스를 전면로드하면 릴리스 과정에서 Sprints 문제를 해결할 수 있습니다.
사업체가이 품목들로부터 간접적 인 가치를 얻었 기 때문에 투명성을 위해 PBI ( Product Backlog Items ) 라고 제안합니다 .
팀은 이러한 항목의 크기를 조정하고 PBI처럼 취급합니다.
이 문제는 다른 비즈니스 중심의 PBI 아래에서 작업 으로이 작업을 숨기는 방법을 찾는 데 시간을 낭비하고 싶지 않다는 사실로 귀결됩니다.
이런 종류의 인프라 작업으로 인해 PBI 크기 조정이 왜곡되는 것을 원하지 않습니다. 무엇을하고 있는지, 내가 무엇을 지불하고 있는지 이해하고 싶습니다.
또한 양질의 솔루션을 제공하는 데 필요한 인프라에 투자하여 팀이 비즈니스의 약속을 이해하도록하는 데 가치가 있다고 생각합니다.
XP 는 모든 도구와 인프라가 설정되어있는 "반복 제로"를 권장 합니다. 이것에 대한 이야기를 쓰는 것은 선택 사항이지만 아마도 좋은 생각 일 것입니다. 인프라 (증분 빌드, 자동 테스트 및 배포, 알림 등)를 테스트 할 수 있으면 유리합니다.
우리 팀에서는 다음을 수행합니다.
2 단계가 가장 중요합니다. 민첩한 연습과 마찬가지로 Scrum에서는 작업을 수행하기 위해 가능한 한 적은 노력을 기울입니다. 불필요한 작업을하면서 인생을 낭비하지 않는 방법으로 활용하십시오. 저의 경험에 따르면 "차가워 질 것"의 50 % 정도가 장기적으로 포기되고 유지되지 않는 것으로 나타났습니다.