Sprint Review에서 UI가없는 소프트웨어를 어떻게 시연합니까?

10

우리는 기본적으로 Scrum을 따르는 민첩한 소프트웨어 개발을하고 있습니다. 스프린트 리뷰를하려고하는데 어려움을 겪고 있습니다. 우리 소프트웨어는 많은 데이터 처리 작업을 수행하고 있으며,이 문제에 대한 다양한 규칙 변경에 대한 이야기가 종종 있습니다.

UI 또는 가시적 워크 플로우 변경이 없을 때 스프린트에서 발생한 변경 사항을 시연하기위한 몇 가지 옵션은 있지만 대신 변경 사항은 처리 작업에 대한 미묘한 비즈니스 규칙으로 10 분 또는 몇 시간이 걸릴 수 있습니다. ?

agile scrum sprint

— 제프 마틴
소스

2

unittests 또는 file manip

— ratchet freak

@ratchetfreak : 기술적 인 용어입니까, 파일 조작입니까?

— Robert Harvey

@RobertHarvey 파일 조작, 나는 명령 줄 도구와 같은 생각

— 괴물

1

@ratchetfreak : 나는 그것이 무엇을 의미하는지 알고 있었다. > _ <

— Robert Harvey

아니 당신은 :-D

— Esailija

9

스프린트 동안 당신은 가치를 창출합니다. 스프린트 시작과 종료 사이에 항상 약간의 차이가 있습니다. 일반적으로 클라이언트가 눈에 띄는 방식으로도. 차이점 만 보여주십시오.

어떤 경우에는 스프린트가 미묘하게 들릴 수있는 발견 또는 내부 재 배열을 다루지 만, 여전히 차이를 보여주고 대중이 왜 자신이 좋다고 생각하는지와 모든 노력의 이점이 무엇인지 설명 할 수 있어야합니다. 코너 케이스는 작동하는 전구를 만드는 것이 불가능한 방법에 대해 수천 가지가 넘는 방법을 처음 발견 한 에디슨을 언급 할 수 있습니다.)

실제 처리에 시간이 오래 걸리면 시간이 걸린 비디오 나 그림 표만 표시해도됩니다. 또는 사전 수집 된 결과 출력.

— 발 로그 팔
소스

+ 자동 수락 테스트 (AAT). 이전 소프트웨어에서 AAT를 실행 한 다음 새 소프트웨어에서 AAT를 실행하십시오. 차이점에 유의하십시오. 기본적인 문제와 해결책을 보여주는 축소 된 표현 (예 : 작고 작동하는 데이터 세트)을 통합합니다.

— JustinC

5

백엔드 작업을하는 것에 대한 나의 개인적인 선호는 최종 사용자 변경을 찾는 것입니다. 처리중인 데이터가 결국 보고서에 표시되면 보고서의 전후 차이를 표시하십시오.

나는 변화에 대한 욕구가 필요에서 온 것이라고 가정합니다. 이야기를 할 필요성을 유발 한 문제는 무엇입니까? 사용자 스토리 '음성 양식'은 스토리에서 사용자 역할을하여 문제를 시연 할 수있는 방법을 알려줍니다 (Joanne이 유럽에있는 사용자없이 보고서를보아야 함).

또한이 경우 테스트 팀에 도움을 줄 수 있습니다. 테스트 팀이 스토리가 완료되었음을 확인할 수있는 방법이 있었을 것입니다. 그들은 이것을 어떻게 했습니까? 데모 내에서 해당 프로세스를 보여줄 수 있습니까?

— 제이 S
소스

2

기능이 스스로 작동한다는 것을 어떻게 알 수 있습니까? 배포 할 때 실제로 작동하는지 어떻게 확인합니까?

당신이 그 질문에 대답 할 수 없다면 당신은 스프린트 검토보다 더 큰 문제가 있습니다. 데모에서이를 보여줄 수 있어야합니다.

Scrum에서 데모 중 제품 소유자는 개발중인 각 스토리를 검토하고이를 수용하거나 개발로 되돌려 보냅니다. 기능이 작동하고 있음을 증명할 수 있어야합니다. 이것은 일반적으로 자동 테스트로 수행하는 것이 가장 좋습니다. 수락 테스트에 해당하는 자동 테스트를 선택하고 주요 변경 사항을 강조 할 수 있습니까?

제품 소유자도 도움을 줄 수 있어야합니다. 개발중인 제품을 자세히 이해해야합니다. 전체 구현 세부 사항을 이해할 필요는 없지만 각 기능의 목적 (또는 비즈니스 가치)을 설명 할 수있을만큼 충분히 이해해야합니다. 결국, 제품 소유자는 스토리를 구현하도록 요청한 사람입니다.

— 데이브 힐 리어
소스

-1

내가 비즈니스에 잠재적으로 충족시키는 옵션 중 하나 (BSA, BA, 관리자 등)는 예상 한 것과 달성 한 것에 대해 5-10 개의 슬라이드 프레젠테이션을 제공하는 것입니다. 그런 다음 데이터 덤프 또는 SQL 쿼리 결과와 같이 수행 한 작업의 결과를 표시하고 결과를 다소 설명 할 수있는 의미있는 방법이있는 경우 이해 관계자가 종종 만족하는 것으로 나타났습니다.

백엔드 유형 시스템의 비 프로그래머 / 비 기술 직원에게는 의미있는 데모를 제공하기가 어려운 경우가 많습니다. 위의 내용을 몇 번 시도했으며 소프트웨어를 단순히 실행하여 결과를 보여줄 때보 다 이해 관계자의 반응이 더 만족 스러웠다 고 생각합니다.

그러나 이것은 당신에게 가치가있는 것보다 더 많은 일이 될 수 있습니다. 이점과 이점을 달성하는 데 필요한 작업에 가중치를 부여해야합니다.

— 나단 데 레인
소스

8

슬라이드 프리젠 테이션의 경우 -1입니다.

— Reactgular

나는 항상 슬라이드에도 큰 노력을 기울였습니다. Slideware는 미끄러운 경사입니다. 대신 실제 제품을 사용합니다.

— Balog Pal

+1. 나는 특히 슬라이드 프리젠 테이션을 좋아하지 않지만 다운 보트에 동의하지 않습니다. 슬라이드는 차트를 정리하는 방법입니다.

— Frax

-1

파워 포인트 또는 그래픽을 사용하여 변경 사항을 전달할 수 있습니다. 예를 들어 스프레드 시트의 셀 값에 따라 추가 된 비즈니스 규칙이있는 경우 해당 셀을 표시하고 변경 방법을 설명 할 수 있습니다.

백엔드 변경 사항이 많고 UI가 변경되지 않은 경우 목록을 통해 설명하고 전체 변경 사항을 표시 할 수 있습니다. 차이점을 강조 표시하는 차트 나 그래픽을 만들 수 있으면 충분할 수 있습니다. 스프린트에서 수행 된 일부 코드 변경 사항 또는 변경 / 커밋 목록을 플래시합니다.

— 루돌프 올라
소스

-2

변경 사항이 "백엔드"인 경우 변경 사항이 표시되는 최종 사용자 인터페이스가있을 수 있습니다. 당신은 그것을 보여줄 수 있습니다. 우리 팀은 해당 시스템을 "소유"하지 않기 때문에 그 일을 좋아하지 않지만 하루가 끝날 때 고객이 변경 사항과 상호 작용하는 방식 인 경우 해당 UI를 알고 잘 알고 있어야합니다. 완성 된 제품을 보여주기에 충분합니다.

— 케빈
소스