패튼 제프. 사용자 스토리. 애자일 소프트웨어 개발의 예술

추상

이 책은 애자일 기법을 이용해 아이디어부터 구현까지 개발 과정을 진행하는 알고리즘을 서술한 책이다. 프로세스는 단계적으로 구성되어 있으며 각 단계에는 프로세스 단계의 방법이 표시됩니다. 저자는 대부분의 방법이 독창적이라고 주장하지 않으면서도 독창적이지 않다고 지적합니다. 그러나 좋은 문체와 과정의 어느 정도 무결성이 이 책을 매우 유용하게 만듭니다.

사용자 스토리 매핑의 핵심 기술은 사용자가 프로세스를 진행하면서 아이디어와 성과를 구조화하는 것입니다.

동시에 프로세스는 다양한 방식으로 설명될 수 있습니다. 핵심 가치를 달성하면서 단계를 구축할 수도 있고, 시스템을 사용하면서 사용자의 근무일을 간단히 상상해 볼 수도 있습니다. 저자는 프로세스 맵에서 사용자 스토리의 형태로 프로세스를 설명하고 설명해야 한다는 사실에 중점을 두고 있으며, 이것이 사용자 스토리 맵이라는 이름을 부여한 것입니다.

누가 그것을 필요로 하는가

IT 분석가 및 프로젝트 관리자용. 꼭 읽어야합니다. 쉽고 재미있게 읽을 수 있으며, 책의 크기는 중간 크기입니다.

검토

가장 간단한 형태로 이것이 작동하는 방식입니다.

방문객은 카페에 와서 요리를 선택하고, 주문하고, 음식을 받고, 먹고, 결제를 한다.

우리는 각 단계에서 시스템에서 원하는 것에 대한 요구 사항을 작성할 수 있습니다.

시스템은 요리 목록을 표시해야 하며 각 요리에는 구성, 무게 및 가격이 있으며 장바구니에 추가할 수 있어야 합니다. 우리가 이러한 요구 사항을 확신하는 이유는 무엇입니까? 이는 요구 사항의 "표준" 설명에 설명되어 있지 않으며 이로 인해 위험이 발생합니다.

이것이 왜 필요한지 이해하지 못하는 공연자는 대개 잘못된 일을 합니다. 아이디어를 창출하는 과정에 참여하지 않는 수행자는 결과에 참여하지 않습니다. Agile은 주로 시스템이 아닌 사람, 소비자, 작업 및 목표에 초점을 맞추자고 말합니다.

우리는 페르소나를 만들고, 공감할 수 있는 세부 정보를 제공하고, 페르소나 측에서 이야기를 들려주기 시작합니다.

사무실 직원 Zakhar는 점심을 먹으러 갔는데 간단한 간식을 먹고 싶어합니다. 그에게 필요한 것은 무엇입니까? 그 생각은 그가 아마도 비즈니스 점심을 원한다는 것입니다. 또 다른 아이디어는 그가 다이어트 중이기 때문에 시스템이 자신의 선호도를 기억하기를 원한다는 것입니다. 또 다른 아이디어. 그는 점심 식사 전에 커피를 마시는 데 익숙하기 때문에 즉시 커피를 가져오고 싶어합니다.

그리고 사업도 있습니다(조직 캐릭터는 조직의 이익을 대표하는 캐릭터입니다). 기업은 평균 수표를 늘리고, 구매 빈도를 높이고, 수익을 늘리기를 원합니다. 아이디어는 - 일부 요리의 특이한 요리를 제공하자는 것입니다. 또 다른 아이디어 - 아침 식사를 소개하겠습니다.

아이디어는 사용자 스토리의 형태로 구체화되고 변형되어 제시될 수 있고 또 그래야 합니다. Zakhar Business Center의 직원으로서 시스템이 나를 인식하여 내 선호도에 따라 메뉴를 받을 수 있기를 바랍니다. 웨이터로서 고객이 빠른 서비스에 만족할 수 있도록 테이블에 언제 접근해야 하는지 시스템이 알려주기를 바랍니다. 등등.

수십 개의 이야기. 다음은 우선순위와 백로그인가요? Jeff는 발생하는 문제를 지적합니다. 작은 세부 사항에 얽매이고 개념적 이해를 잃으며 기능의 우선 순위를 정하면 목표와의 불일치로 인해 불규칙한 그림이 생성됩니다.

저자의 길: 우리는 기능이 아니라 결과 = 사용자가 결국 얻는 것에 우선순위를 둡니다.

분명하고 명확하지 않은 점은 우선순위 지정 세션이 비효율적이기 때문에 전체 팀이 수행하는 것이 아니라 세 사람이 수행한다는 것입니다. 첫 번째는 비즈니스를 담당하고, 두 번째는 사용자 경험을 담당하고, 세 번째는 구현을 담당합니다.

한 명의 사용자 문제를 해결하기 위한 최소값(최소 실행 가능한 솔루션)을 선택하겠습니다.

우리는 프로세스의 각 단계에서 사람과 이해관계자에게 필요한 것이 무엇인지 팀과 이야기하고 논의함으로써 사용자 스토리 맵의 사용자 스토리, 디자인 스케치, 제약 조건 및 비즈니스 규칙을 사용하여 최우선 아이디어를 자세히 설명합니다. 우리는 남은 아이디어를 기회의 백로그에 검토하지 않은 채로 둡니다.

프로세스는 카드에 왼쪽에서 오른쪽으로 기록되어 있으며, 카드의 프로세스 단계 아래에 아이디어가 있습니다. 전체 이야기의 경로를 팀원들과 함께 논의하여 상호 이해를 보장하는 것이 필수적입니다.

이러한 방식으로 정교하게 작업하면 프로세스를 준수하면서 무결성이 만들어집니다.

받은 아이디어는 테스트를 거쳐야 합니다. 팀원이 아닌 사람이 그 사람의 모자를 쓰고 그 사람의 하루를 머릿속으로 살며 문제를 해결합니다. 그가 개발 내용을 보지 못하고 카드를 다시 만들고 팀이 스스로 대안을 발견할 수도 있습니다.

그런 다음 평가를 위한 세부정보가 있습니다. 세 사람이면 충분합니다. "만약..."이라는 질문을 가장 좋아하는 사용자 경험, 개발자, 테스터를 담당합니다.

각 단계에서 토론은 사용자 이력의 프로세스 맵을 따르며, 이를 통해 사용자의 작업을 염두에 두고 일관된 이해를 만들 수 있습니다.

작성자의 의견으로는 문서가 필요합니까? 예, 필요합니다. 그러나 귀하가 동의한 내용을 기억할 수 있도록 하는 메모입니다. 외부인을 다시 참여시키려면 토론이 필요합니다.

저자는 토론의 필요성에 초점을 맞춰 문서의 충분성 주제를 탐구하지 않습니다. (예, 애자일에 대한 깊은 이해가 없는 사람들이 아무리 주장하더라도 문서화는 필요합니다.) 또한 기능 중 일부만 정교화하면 전체 시스템을 완전히 재작업해야 할 수도 있습니다. 저자는 생각이 틀릴 경우 지나치게 정교해질 위험이 있다고 지적한다.

리스크를 없애기 위해서는 만들어진 제품에 대한 피드백을 빠르게 받아 '잘못된' 제품을 만들어 피해를 최소화하는 것이 필요하다. 우리는 아이디어의 스케치를 만들었습니다. 사용자와 함께 검증하고, 인터페이스 프로토타입을 스케치하고, 사용자와 함께 검증했습니다. (별도로 프로그램 프로토타입을 검증하는 방법에 대한 약간의 정보가 있습니다). 특히 초기 단계에서 소프트웨어를 만드는 목적은 빠른 피드백을 통해 학습하는 것이므로, 첫 번째 제품은 가설을 증명하거나 반증할 수 있는 스케치가 됩니다. (저자는 Eric Ries의 "린 방법론을 사용한 스타트업"의 작업을 참고했습니다.)

스토리맵은 여러 팀에 걸쳐 구현을 수행할 때 의사소통을 개선하는 데 도움이 됩니다. 지도에는 무엇이 있어야 할까요? 대화를 계속하기 위해 필요한 것. 사용자 스토리(누가, 무엇을, 왜)뿐만 아니라 아이디어, 사실, 인터페이스 스케치 등...

히스토리 맵의 카드를 여러 개의 수평선으로 나누면 작업을 릴리스로 나눌 수 있습니다. 즉, 최소한의 기능, 증가하는 기능 및 활의 레이어를 강조 표시할 수 있습니다.

우리는 프로세스 맵에서 이야기를 전합니다.

직원이 점심 먹으러 왔습니다.

그가 원하는 것은 무엇입니까? 서비스 속도. 그래서 그의 점심은 이미 테이블이나 적어도 쟁반에서 그를 기다리고 있습니다. 이런 - 놓친 단계: 직원이 식사를 원했습니다. 그는 로그인하여 비즈니스 점심 옵션을 선택했습니다. 체중이 늘지 않고 다이어트에 도움이 되는 칼로리와 영양성분을 봤습니다. 그는 그 장소에서 먹을지 말지 결정하기 위해 요리 사진을 보았습니다.

다음에는 점심과 저녁을 먹으러 갈까요? 아니면 점심이 그의 사무실로 배달될까요? 그런 다음 과정의 단계는 식사할 장소를 선택하는 것입니다. 그는 그것이 언제 배달될지, 비용이 얼마나 되는지 확인하고 싶어합니다. 그래서 아래층으로 갈지, 출근할지 등 시간과 에너지를 어디에 쓸지 선택할 수 있습니다. 그는 줄을 서지 않기 위해 카페가 얼마나 바쁜지 확인하고 싶어합니다.

그러다가 직원이 카페에 왔습니다. 그는 쟁반을 보고 곧바로 저녁 식사를 하러 가고 싶어합니다. 카페는 서비스로 돈을 벌기 위해 돈을 받고 싶어합니다. 직원은 소중한 시간을 쓸데없이 낭비하지 않기 위해 카페와의 합의에 최소한의 시간을 낭비하고 싶어합니다. 어떻게 하나요? 원격으로 서비스를 받은 후 선불로 결제하거나 그 반대로 결제하세요. 아니면 현장에서 키오스크를 이용해 결제하세요. 이것에서 가장 중요한 것은 무엇입니까? 은행 카드로 점심 값을 지불할 의향이 있는 사람은 몇 명입니까? 반복 결제를 위해 이 매점에 카드 번호를 저장해 두는 사람이 몇 명이나 될까요? 현장 조사 없이는 불분명하므로 테스트가 필요합니다.

프로세스의 각 단계에서 어떻게든 기능을 제공해야 합니다. 이를 위해서는 특정 사람을 기반으로 그 사람에게 더 중요한 것이 무엇인지 선택해야 합니다(동일한 세 가지 선택기). 이야기를 끝까지 따라갔습니다 = 실행 가능한 솔루션을 만들었습니다.

다음은 디테일입니다. 고객은 줄을 서지 않기 위해 카페가 얼마나 바쁜지 확인하고 싶어합니다. 그가 원하는 것은 정확히 무엇입니까?

그가 도착하면 15분 후에 얼마나 많은 사람이 있을지 예측해 보세요.

카페의 평균 서비스 시간과 그 역학을 XNUMX분 전에 미리 확인하세요.

상황과 테이블 점유 역학을 확인하세요.

예측 시스템이 불분명한 결과를 제공하거나 작동을 멈추면 어떻게 되나요?

카페의 줄과 테이블 점유율을 영상으로 감상해보세요. 흠, 먼저 해보는 건 어떨까요?!

저자는 연습할 수 있는 작은 운동을 지적합니다. 잠에서 깨어난 후 아침에 무엇을 하는지 상상해 보십시오. 하나의 카드 = 하나의 행동. 구현 방법이 아닌 목표에 초점을 맞춰 개별 세부 사항을 제거하려면 카드를 확대하십시오 (커피를 갈는 대신 상쾌한 음료를 마시십시오).

이 책은 누구를 위한 것인가: IT 분석가와 프로젝트 관리자. 꼭 읽어야합니다.

애플 리케이션

토론과 의사결정은 3~5명의 그룹에서 효과적입니다.

첫 번째 카드에는 개발해야 할 내용을 적고, 두 번째 카드에는 첫 번째에서 수행한 작업을 수정하고, 세 번째 카드에는 첫 번째와 두 번째에서 수행한 작업을 수정합니다.

케이크와 같은 이야기를 준비하세요. 레시피를 적는 것이 아니라, 케이크가 누구를 위한 것인지, 어떤 행사를 위한 것인지, 몇 명을 위한 것인지 알아가면서 준비하세요. 매출을 세분화하면 케이크, 크림 등의 생산이 아니라 작은 기성품 케이크의 생산이 될 것입니다.

소프트웨어 개발은 ​​영화 제작과 유사합니다. 촬영이 시작되기 전에 대본을 신중하게 개발 및 다듬고, 장면, 배우 등을 구성해야 합니다.

항상 자원이 부족할 것입니다.

20%의 노력은 가시적인 결과를 낳고, 60%는 이해할 수 없는 결과를 낳고, 20%의 노력은 해롭습니다. 그렇기 때문에 학습에 집중하고 부정적인 결과가 나와도 절망하지 않는 것이 중요합니다.

사용자와 직접 소통하고 자신의 입장에서 느껴보세요. 몇 가지 문제에 집중하세요.

평가를 위해 스토리를 자세히 설명하고 개발하는 것은 스크럼에서 가장 지루한 부분입니다. 수족관 모드에서 토론을 스탠드업하게 만드세요(3~4명이 보드에서 토론하고 누군가 참여하고 싶다면 그가 다른 사람을 대체합니다).

출처 : habr.com