여기에서는 비교적 작은 새 소프트웨어 개발 프로젝트의 범위를 정하고 추정하는 과정에 있습니다. 나는 고객이 제안한 사용자 스토리를 겪고 각각의 작업에 대해 작업을 수행하는 방법에 대한 견적과 간단한 메모를 작성했습니다. 수락 기준이 있습니다. 모두 세상에 좋을 것입니다.
계획 한 작업을 살펴보면 뭔가 빠진 것이 있다는 것을 깨달았습니다. 단순히 기능을 강화할 수있는 것들을 설정하는 데 초기 비용이들 것입니다. 하나의 특정 사용자 스토리가 아닌 모든 사용자 스토리에 속하는 것.
예를 들어이 응용 프로그램의 일부는 XML을 구문 분석하는 서비스입니다. 사용자 관점에서 XML의 내용에 따라 다른 작업을 수행해야하는 구체적인 사례가 있습니다. 실제로 파일을 찾고, 파일을 읽고, 내용과 관련하여 무엇을할지 결정하기 전에 관련 데이터를 꺼내는 XML 파서를 작성하는 것은 모든 이야기의 일부입니다. 설치 프로그램 등을 사용하여 Windows 서비스에 래핑하는 것처럼 사용자와 직접적인 관련이없는 개발자 중심 작업입니다.
이 특정 응용 프로그램의 또 다른 관련 예는이 응용 프로그램의 기능에 유용한 가난한 레거시 코드 블록을 가져와 다시 작성하는 것입니다. 다시 말하지만 이것은 사용자에게 즉각적인 결과는 없지만 필요한 작업입니다. 사용자 스토리에 중점을 둔 프로젝트 계획에서이 작업의 계획 및 실행은 어디에서 "실제"입니까?
사람들이 "개발자로서하고 싶습니다"라는 사용자 스토리를 작성하여이 문제를 해결하는 것을 보았지만 다른 곳에서 논의 된 것처럼 이것은 사용자 스토리 가 아닙니다 . 개발자입니다.
TFS 온라인과 같은 엄격한 관리 프레임 워크를 사용하여 프로젝트를 계획하는 데 도움이되는 구체적인 답변을 찾고 있습니다. 이들은 "이해 관계자의 이야기"나에 대한 답변에 언급 된 다른 모호한 메타 솔루션을 만들 수있는 기능을 가지고하는 경향이없는 계획 회의에서 인프라 작업을위한 스크럼 팀 계정을 수행하는 방법을?