Резюме
Книгата е разказан алгоритъм за провеждане на процеса на разработка от идея до внедряване с използване на agile техники. Процесът е разложен на стъпки, като на всяка стъпка се посочват методи за този етап от процеса. Авторът посочва, че повечето методи не са оригинални и не претендират за оригиналност. Но добрият стил на изложение и известна цялостност на процеса правят книгата много полезна.
Ключовата техника на картата на потребителските истории е структуриране на идеи и постановки по хода на преминаването през процеса от потребителя.
В същото време преминаването през процеса може да бъде изложено по различен начин. Може да се изгради стъпките по ключова стойност, или просто да се представи работния ден на потребителите, как той протича с использованием на системата. Авторът се фокусира върху това, че процесите трябва да се излагат, да се разказват във вид на история на потребителя на картата на процеса, което е довело до названието карта на потребителските истории.
Кому е нужно
За ИТ анализатори и ръководители на проекти. Задължително за четене. Чете се лесно и приятно, книгата е със среден размер.
Отзив
В най-простия вариант, как работи това.
Посетителят идва в кафето, избира ястия, прави поръчка, получава храната, яде, плаща.
Може да се напишат изисквания какво искаме от системата на всеки етап.
Системата трябва да показва списък с ястия, всяко ястие да има състав, тегло и цена и да предоставя възможност за добавяне в кошницата. Защо сме сигурни в тези изисквания? В 'стандартното' описание на изискванията това не е описано и това поражда рискове.
Изпълнителите, които не разбират защо това е нужно, обикновено правят нещата неправилно. Изпълнителите, които не са ангажирани в процеса на създаване на идеята, не са ангажирани и в резултата. Agile казва, да се фокусираме преди всичко не на системата, а на хората, на потребителите, техните задачи и цели.
Създаваме персонажи, за да придадем емпатия, добавяме детайли и от страна на персонажите започваме да излагаме истории.
Офисният служител Захар отиде на обяд и иска бързо да хапне нещо. Какво му трябва? Идеята - вероятно иска бизнес обяд. Друга идея - иска системата да помни предпочитанията му, тъй като е на диета. Още една идея. Иска да му донесат кафе веднага, тъй като е свикнал да пие кафе преди обяд.
Има един бизнес (оргсонаж — персонаж, представляващ интересите на някаква организация). Бизнесът иска да увеличи средната стойност на чека, да увеличи честотата на пазаруване, да увеличи печалбата. Идея — защо да не предложим необичайни ястия от някаква кухня. Друга идея — защо да не въведем закуска.
Идеите могат и трябва да бъдат конкретизирани, преобразувани и оформени във вид на потребителска история. Като служител на бизнес център Закар, искам системата да ме разпознава, за да получавам меню с оглед на моите предпочитания. Като сервитьор искам системата да ме уведомява кога да отида на масата, за да е клиентът доволен от бързото обслужване. И така нататък.
Десетки истории. А какво следва с приоритизацията и беклога? Джеф посочва възникващите проблеми: заплитането в малките детайли и загубата на концептуално разбиране, плюс приоритизацията на функционалността създават разнопосочна картина заради несъгласуваността с целите.
Пътят на автора: Приоритизираме не функционалността, а резултата = това, което потребителят получава в крайна сметка.
Очевидно неочевиден пункт: сесията по приоритизация не се провежда от целия екип, защото е неефективно, а от трима души. Първият отговаря за бизнеса, вторият за потребителския опит, а третият за изпълнението.
Изолирайте минимум за решаване на една потребителска задача (минимално жизнеспособно решение).
Детайлизирайте идеите от първия приоритет с помощта на потребителски истории, скици на дизайна, ограничения и бизнес правила на картата на потребителските истории чрез разказ и обсъждане с екипа какво е необходимо на персонажите и заинтересованите лица на всяка стъпка от процеса. Останалите идеи оставяме неразгледани, в беклога на възможности.
Процесът се описва във вид на карти отляво надясно, а идеите на картите под стъпките на процеса. Обязательно пътят на цялата история трябва да бъде обяснен заедно с членовете на екипа, за да се постигне взаимно разбирателство.
Обработката по този начин създава цялостност на съответствието с процесите.
Получените идеи трябва да бъдат проверени. Не член на екипа поставя шапката на персонажа и преживява деня на персонажа в главата си, решавайки неговата задача. Възможен е вариант, при който той не вижда постигнатото, създавайки картите наново, докато екипът открива алтернативи.
След това се извършва подробностната оценка. За това са нужни само трима души. Отговорният за потребителското изживяване, разработчик и тестер с любимия си въпрос: “А какво ако…”.
На всяка стъпка дискусията се води по картата на процесите на потребителската история, което позволява, запазвайки задачата на потребителя в съзнанието, да се създаде цялостно разбирателство.
Нужна ли е документация според автора? Да, нужна е. Но в качеството на бележки, които позволяват да си спомним за уговореното. Включването на човек отстрани отново изисква обсъждане.
Авторът не задълбочава темата за достатъчността на документацията, акцентирайки основно на необходимостта от обсъждания. (Да, документация е нужна, независимо какво твърдят хора, които не разбират дълбочината на agile). Също така, обработването само на част от възможностите може да доведе до необходимостта от пълна преработка на цялата система. Авторът посочва риска от прекалена работа, ако не са угадали с идеята.
За намаляване на рисковете е необходимо бързо да се получава обратна връзка за създавания продукт, за минимизиране на щетите от създаването на "не този" продукт. Създадохме скица на идеята — валидирахме я при потребителя, скица на интерфейсни прототипи — валидирахме я при потребителя и т.н. (Отделно е споменато как да се валидират програмните прототипи). Целите на създаването на софтуер, особено на начален етап — обучение чрез получаване на бърза обратна връзка, следователно, първият създаден продукт е скици, които могат да докажат или опровергаят хипотезата. (Авторът се опира на работата на Ерик Рийс “Стартап по методология Lean”).
Картата на историите помага за установяване на комуникация, ако реализирането се осигурява от няколко екипа. Какво трябва да бъде на картата? Това, което е нужно за поддържане на разговора. Не само потребителската история (кой, какво, защо), но и идеи, факти, скици на интерфейси и др.…
Разделяйки картите на историята на няколко хоризонтални линии, можем да разделим работата на изпускания — да изолираме най-минималното, слой за нарастване на функционалността и лъкове.
Изговаряме историите на картата на процеса.
Служителят дойде на обяд.
Какво иска? Скорост на обслужване. Да може обядът му да го чака на масата или поне на поднос. Опа — пропуснато стъпало: служителят решил да хапне. Той влиза в системата и избира вариант за бизнес обяд. Вижда калорийната стойност и съответствието на хранителните стойности, за да спазва диета и да не наддаде на тегло. Вижда снимки на ястията, за да реши дали да се храни на това място или не.
Следва ли да отиде да вземе обяда и да се храни? Или дали ще му доставят обяд в офиса? Тогава стъпката в процеса е избор на място за хранене. Иска да вижда срока, когато му бъде доставен и колко ще струва, за да избере къде да инвестира време и усилия — да слезе надолу или да работи. Иска да вижда натовареността на кафенето, за да не се блъска в опашките.
След това служителят пристига в кафето. Иска да види своя поднос, за да го вземе и веднага да отиде да се храни. Кафето иска да приеме пари, за да печели от обслужването. Служителят иска да загуби минимално време за разплащане с кафето, за да не губи ценно време без полза. Как да стане това? Да плаща предварително или обратно, след обслужване дистанционно. Или да плаща в момента с помощта на киоск. Какво от това е най-основното? Колко хора са готови да плащат с кредитна карта за обяда? Колко хора ще се доверят на съхранението на номера на картата за повторни плащания към това заведение? Без полеви изследвания неясно, необходимо е тестване.
На всяка стъпка от процеса трябва да се осигури функционалност, за това трябва да се вземе основа някаква персона и да се избере какво е по-важно за него (тази тройка избиратели). Прекарали сме историята до края = направили сме жизнеспособно решение.
Следва детайлизиране. Клиентът иска да вижда натовареността на кафето, за да не се блъска в опашките. Какво точно иска?
Да види прогнозата колко хора ще има след 15 минути, когато той там пристигне.
Да види средното време за обслужване в кафето и неговата динамика за половин час напред.
Да вижда ситуацията и динамиката на заетостта на масите.
А какво, ако системата за прогнозиране дава неясен резултат или спре да работи?
Да гледа через видео камерите опашките в кафето, а също така и заетостта на масите. Хм, а защо да не го направим първо?!
Авторът предлага малко упражнение за усъвършенстване на практиката: опитайте се да си представите какво правите сутрин след събуждане. Една картичка = едно действие. Обобщете картичките (вместо да смилате кафе — пийте ободряваща напитка), за да премахнете индивидуалните детайли, фокусирайки се не на начина на реализиране, а на целта.
За кого е тази книга — за ИТ анализатори и ръководители на проекти. Задължително за четене.
Приложения
Дискусията и вземането на решения са ефективни в групи от 3 до 5 души.
Запишете на първата картичка какво трябва да се разработи, на втората — какво да се коригира от първата, а на третата — какво да се поправи от първата и втората.
Пригответе истории като торти — не пишете рецептата за изработка, а се интересувайте на кого, по какъв повод и за колко души е тортата. Ако се фокусирате върху реализирането, не го правете на изработка на блатове, кремове и т.н., а на малките готови торти.
Разработката на софтуер прилича на създаването на филм, когато трябва внимателно да се разработи и доведе сценария до съвършенство, да се организират сцената, актьорите и пр. преди началото на снимките.
Винаги ще има недостиг на ресурси.
20% от усилията дават осезаем резултат, 60% дават неясен резултат, 20% от усилията вредят — ето защо е важно да се фокусирате върху обучението и да не се отчайвате в случай на негативен резултат.
Комуникирайте директно с потребителя, опитайте се да се поставите на негово място. Фокусирайте се върху някои проблеми.
Детайлизацията и разработването на историята за оценка е най-трудната част от scrum, направете дискусиите в режим на аквариум (при дъската обсъждат 3-4 души, ако някой иска да участва, той заменя някого).
Източник: habr.com
