대규모 프로젝트에 대한 사용자 스토리 관리하기 [닫기]

https://stackoverflow.com/questions/118064

02-07-2019
|

문제

우리는 이제 막 많은 하위 프로젝트가 포함된 꽤 큰 프로젝트를 시작하고 있습니다.우리는 현재 어떤 종류의 명명된 프로세스도 사용하지 않지만 뒷문에 일종의 민첩하고 스크럼 같은 프로세스가 도입되기를 바라고 있습니다.

제가 가장 집중할 영역은 전체 프로젝트에 대해 좋은 백로그를 갖는 것이고, 적어도 내 머리 속에는 백로그에서 일부 항목을 가져와서 더 자세히 살펴보고 합리적인 기한에 맞춰 개발하는 반복 아이디어가 있습니다. .

사람들이 프로젝트를 백로그에 넣을 항목으로 나누는 데 어떤 기술을 사용하는지, 백로그가 생성되면 어떻게 유지 관리되고 정렬되는지 궁금합니다.또한 요소들 사이의 관계가 어떻게 유지되는지(즉, 그렇게 하기 전에 이 작업을 수행해야 합니다. 그렇지 않으면 이것이 하나의 스토리였는데 이제는 5개가 되었습니다)

이 질문에 대한 대답이 어떤 모습일지 잘 모르겠습니다.내 생각에 가장 도움이 될 수 있는 것은 어떤 방식으로든 백로그를 온라인으로 유지하여 다른 사람들이 어떻게 하는지 볼 수 있는 오픈 소스 프로젝트가 있는 것입니다.

나에게서 +1을 얻을 수 있는 또 다른 것은 실제 프로젝트의 실제 사용자 스토리의 예입니다("사용자가 로그온할 수 있음" 스토리는 내 프로젝트의 내용을 파악하는 데 도움이 되지 않습니다.)

감사해요.

해결책

도구를 채택하기 전에 신중하게 생각하라고 조언하고 싶습니다. 특히 발을 찾을 때 처음에는 프로세스가 유동적일 가능성이 높기 때문입니다.내 생각에는 도구가 이 단계에서 당신을 가능하게 하기보다는 당신을 제약할 가능성이 더 높으며, 당신은 그것이 도구를 대체할 수 없다는 것을 알게 될 것입니다. 물리적 공간에 있는 좋은 카드월.대신에 당면한 작업에 노력을 집중하고, 정말로 필요하다고 느낄 때 도구를 잡는 것이 좋습니다.이 단계에서는 요구 사항에 대한 명확한 아이디어를 갖게 될 가능성이 높습니다.

저는 지금까지 여러 개의 민첩한 프로젝트를 실행해 왔으며 예산이 백만 파운드가 넘는 프로젝트에서 스프레드시트보다 더 복잡한 도구가 필요했던 적이 없습니다.대부분 우리는 화이트보드와 색인 카드(사용자 스토리당 하나)이면 충분하다는 것을 알았습니다.

스토리를 식별할 때 항상 사용자가 이해할 수 있는 용어로 스토리를 표현해야 합니다. 이는 표면화된 기능의 일부(아마도 작은) 부분입니다.사용자에게 보여줄 수 없는 기술적 세부 사항에 대한 이야기를 작성하는 데 빠져들지 마십시오.

스토리를 계획할 때 가장 먼저 아는 것부터 우선순위를 정하는 동시에(하고 싶은 것보다 배우고 싶은 것에 대한 계획) 핵심 기능을 개발할 수 있는 스토리부터 시작하는 것이 좋습니다. 후속 스토리를 사용하여 기능(및 기술 복잡성)을 래핑합니다.

퍼즐의 일부 조각을 나중까지 남겨둘 수 있다고 확신한다면, 그 세부 사항을 파악하는 데 애쓰지 마세요. 나중에 해야 할 중요한 대화를 나타내는 스토리 카드를 하나만 작성하고 다음 내용을 확인하세요. 더 중요한 것들에 대해.앞으로 다가올 일의 규모에 대한 느낌이 필요하다면 다음과 같은 광대역 델파이 추정 기술을 살펴보십시오. 포커 계획.

특히 Mike Cohn 책은 민첩한 추정 및 계획 이 단계에서 많은 도움이 될 것이며 작업에 유용한 몇 가지 기술을 제공할 것입니다.

행운을 빌어요!

다른 팁

DanielHonig와 마찬가지로 우리도 RallyDev(소규모)를 사용하고 있으며 최소한 조사해 보면 유용한 시스템이 될 수 있을 것 같습니다.

또한, 사용자 스토리 개발 방법에 관한 훌륭한 책은 다음과 같습니다. 적용된 사용자 스토리 마이크 콘 지음.아직 읽어보지 않으셨다면 꼭 읽어보시길 권하고 싶습니다.그것은 당신의 많은 질문에 답할 것입니다.

이것이 당신이 찾고 있는 것인지 확실하지 않지만 여전히 도움이 될 수 있습니다.codequeeze의 Max Pool은 그의 "Agile Wall"을 설명하는 비디오를 가지고 있습니다.귀하의 질문과 꼭 관련이 없더라도 그의 프로세스를 보는 것은 멋진 일입니다.

내 민첩한 벽(몇 가지 요령 포함)

다음은 몇 가지 팁입니다.우리는 RallyDev를 사용합니다.
요구 사항이 포함된 패키지 보기를 만들었습니다.대규모 스토리는 에픽으로 분류되며 의도한 릴리스의 릴리스 백로그에 배치됩니다.서사시에 어린이 이야기가 추가됩니다.우리는 이야기를 매우 세부적으로 유지하는 것이 가장 좋다는 것을 알았습니다.조잡한 스토리로 인해 스토리를 현실적으로 추정하고 실행하기가 어렵습니다.

따라서 일반적으로:

릴리스별로 구성
2-4 주 사이의 반복을 유지하십시오
제품 소유자 및 프로젝트 관리자는 릴리스 백 로그에 스토리를 추가합니다.
Dev 팀은 Tshirt 크기, 포인트 등을 기반으로 스토리를 추정합니다 ...
Spring Planning meeetings에서 Dev 팀은 릴리스 백 로그에서 반복 작업을 선택합니다.

이것이 우리가 지난 4개월 동안 해온 일이며 잘 작동하는 것으로 나타났습니다.스토리의 크기를 작고 세부적으로 유지하는 것이 매우 중요합니다.

사용자 스토리를 평가할 때 Invest 및 Smart 약어를 기억하세요. 좋은 스토리는 다음과 같아야 합니다.I- 독립적 인 N- 협상 가능한 v- 귀중한 e- 추정 가능한 s- 작은 t- 테스트 가능

똑똑한:

s- 특정 m- 측정 가능한 a- 달성 가능한 r- 관련 t- 시간 상자

단순하게 유지하라는 말부터 시작하겠습니다.추적(및 백업) 기능이 있는 공유 스프레드시트를 사용하세요.백로그를 일관된 상태로 유지하는 데 점점 더 많은 시간이 소요되는 확장 또는 동기화 문제가 발생하는 경우 교환하십시오.그러면 지출/재교육 비용이 자동으로 검증되고 정당화됩니다.

나는 좋은 내용을 읽었습니다. Thoughtworks의 어울림.

다음은 당신에게 몇 가지 아이디어를 줄 수 있는 비슷한 질문에 대한 나의 답변입니다.

BA를 도와주세요!사용자 스토리 관리...

이러한 응답의 대부분은 사용할 도구에 대한 제안이었습니다.그러나 현실은 프로세스를 구현하는 데 사용하는 도구보다 프로세스가 훨씬 더 중요하다는 것입니다.방법론을 목구멍에 집어넣으려고 하는 도구를 멀리하세요.그러나 또한 단순히 새로운 도구를 사용하여 기존의 비민첩한 프로세스를 구현하는 것에 주의하십시오.프로세스 도구를 결정할 때 고려해야 할 몇 가지 중요한 사실은 다음과 같습니다.

소프트웨어 도구로 계측 된 나쁜 프로세스는 소프트웨어 도구 구현이 잘못됩니다.
관리하는 그룹에 따라 프로세스가 변경됩니다.중요한 것은 프로세스가 아니라 사람들입니다.그들이 성공적으로 일할 수있는 것을 구현하면 프로젝트가 성공할 것입니다.

그렇다면 도움이 될 몇 가지 지침은 다음과 같습니다.

문서화된 프로세스를 순수하게 구현하는 것부터 시작하세요.
반복을 작게 만들고,
각 반복이 팀과 대화하고 그들이 무엇을 바꿀지 물어 보면, 의미가있는 변경 사항을 구현하십시오.

대규모 조직의 경우 SCRUM을 사용하는 경우 계단식 스탠드업 메커니즘을 사용하십시오.스크럼 마스터는 해당 팀과 만납니다.그런 다음 스크럼 마스터는 6~9명의 스탠드업으로 만나며, 슈퍼 스크럼 마스터는 스컴 마스터 스크럼의 항목을 다음 레벨로 보고하는 일을 담당합니다.기타 등등..

계층 구조의 최고 수준에서는 매주 슈퍼 스크럼 회의를 갖는 것으로 충분할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow