Шаблон User Story и INVEST-критерии помогают написать историю так, чтобы она была одинаково понятна для всех участников процесса разработки. Благодаря этому оценить и реализовать ее получится гораздо эффективнее.


Согласно критериям, пользовательская история должна быть:

🔹Независимой
Independent
🔹Обсуждаемой
Negotiable
🔹Ценной
Valuable
🔹Оцениваемой
Estimable
🔹Масштабируемой
Sized Appropriately или Small
🔹Тестируемой
Testable

Разберём каждый критерий подробнее.


1️⃣ Независимая

Пользовательская история должна быть автономной в реализации. Это значит, что её проектирование не должно пересекаться с другими историями.

Например, вам нужно спроектировать функциональность для регистрации пользователя в приложении. Вы сформулировали две истории:

🔸Как пользователь приложения, я хочу иметь возможность указать свои ФИО, чтобы создать личный кабинет в приложении.
🔸Как пользователь приложения, я хочу иметь возможность указать свой номер телефона, чтобы создать личный кабинет в приложении.


В описанных историях сложно определить, с какой истории начать разработку, но зато очевидно, что эти истории похожи по логике реализации и пересекаются по функциональности: пользователь хочет указывать персональные данные при регистрации. А значит их можно объединить в одну:

👍 Как пользователь приложения, я хочу иметь возможность указать свои личные данные, чтобы создать личный кабинет в приложении.



2️⃣ Обсуждаемая

Пользовательская история — это результат коллективной работы проектной команды. Поэтому историю нужно записывать так, чтобы команде было что обсуждать.

❗️История не должна содержать точные указания на то, как её нужно реализовывать.

История должна включать только цель планируемых изменений и их ожидаемый результат.

👎 Как пользователь приложения, я хочу указывать для входа в личный кабинет адрес электронной почты, который интегрирован с личным кабинетом, чтобы быстрее авторизоваться.

👍 Как пользователь приложения, я хочу иметь возможность авторизоваться с помощью электронной почты, чтобы быстрее попадать в личный кабинет.

В прошлый раз разобрали два критерия пользовательских историй – Независимость и Обсуждаемость.
Продолжаем со следующими двумя ⤵️


3️⃣ Ценная

Карточку истории можно назвать ценной, если она действительно приносит пользу заинтересованным лицам. Поэтому, создавая историю, нужно думать о её ценности для пользователей и заказчиков.

Зачастую ценность заключается в:
🔹уменьшении затрат бизнеса;
🔹увеличении его доходов;
🔹оптимизации процессов;
🔹улучшении сервиса для пользователя
и так далее.

Если при отказе от реализации истории не изменится ровным счётом ничего, то эту историю можно отложить, либо вообще от неё отказаться.

👎 Как пользователь приложения службы доставки посылок, я хочу указывать для входа в личный кабинет данные паспорта, чтобы у компании были данные о моих документах.

👍 Как пользователь приложения службы доставки посылок, я хочу иметь возможность указать паспортные данные в профиле, чтобы получать свои посылки без документов.

4️⃣ Оцениваемая

История должна быть доступной для оценки затрачиваемых для неё ресурсов: усилий проектной команды в человекочасах.

❗️Не рекомендуется, чтобы одна пользовательская история превышала 80 часов разработки — большие и трудозатратные истории менее гибкие к изменениям.

Их границы могут со временем расширяться засчёт добавления новых требований, влияния изменений других процессов и так далее.


Проектной команде будет сложно оценить размер истории, если:
🔹ей не хватает знаний о предметной области или технологиях проектирования;
🔹история слишком объёмная.

Отслеживайте, чтобы в историях, которые вы описываете, не было «слепых пятен» или длинных конструкций.


👎 Как пользователь администраторского ПО, я хочу указывать статьи ДДС, проводки, а также коррекспондирующие счета в разделе «Бухгалтерия» для грамотного проведения оплат внутри системы.

👍 Как пользователь администраторского ПО, я хочу фиксировать движение денежных средств внутри компании, согласно Федеральному закону о бухгалтерском учёте.


В первой истории указана специализированная терминология. По сути, каждую указанную единицу нужно описывать отдельной историей. Но вторая история даёт ссылку на законодательство, в котором указаны все правила и сущности, на основании которых следует реализовать историю.

🤖Кстати, часть истории с указанием цели в этом случае можно опустить, ведь соблюдение законодательства уже является целью.

5️⃣ Масштабируемая

Истории должны иметь масштаб (или размер), подходящий для использования на разных этапах разработки и для разных целей.

🔹 Истории высокого уровня реализуются для достижения бизнес-целей. Обычно они формулируются заказчиком и в таком виде поступают к аналитику.

🔹 Истории среднего уровня направлены на достижение целей заинтересованных лиц. Чаще всего формулируются пользователями.

🔹 Истории низкого уровня максимально детализированы. И именно их следует передавать в работу разработчикам.

Низкий уровень истории чаще всего появляется после декомпозиции историй среднего и высокого уровня.

Разберём примеры историй по уровням ⤵️


История высокого уровня:
🔸 Как директор компании, я хочу увеличить выручку компании от продажи товаров для отдыха, чтобы иметь больше возможностей для бизнеса.

Такую историю нельзя передавать в разработку, потому что вариаций решения для достижения бизнес-цели множество.



История среднего уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупки в приложении различными способами, чтобы выбирать удобный для меня способ оплаты в момент времени.

Такая история уже говорит о том, что именно необходимо внедрить – возможность оплатить покупки в приложении различными способами. Но какими?



История низкого уровня:
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку наличными, чтобы оплачивать заказ в момент его получения.
🔸 Как пользователь, я хочу иметь возможность оплачивать покупку банковской картой, чтобы произвести оплату в момент оформления заказа.

Эти истории уже можно оценить для проектирования, а значит задача по масчштабированию до уровня разработки выполнена успешно ☑️

6️⃣ Тестируемая

Команда должна хорошо представлять, как проверить исполнимость истории. Нетестируемые истории (те, что нельзя проверить) по большей части возникают для нефункциональных требований.

👎 Как пользователь, я не хочу долго ждать создания личного кабинета, чтобы быстрее приступать к оформлению заказа в приложении.

👍 Как пользователь, я хочу, чтобы личный кабинет создавался не дольше двух секунд, чтобы быстрее приступать к оформлению заказа в приложении.

Первую историю проблематично тестировать из-за формулировки «долго», потому что каждый может тракотовать долготу по своему. Вторую историю мы сможем протестировать, а значит, она будет соответствовать последнему INVEST-критерию.



Подведём итог.

При формировании пользовательских историй старайтесь соблюсти два правила:

🔑 Стройте историю по шаблону:
Как [роль], я хочу [выполнить задачу], чтобы [достичь цель];

🔑 Соблюдайте INVEST-критерии в формулировке.

Благодаря этому вы и ваша команда сможете грамотно оценить и спланировать работу в проектировании ПО 😊

Друзья, всем привет!😊


Недавно мы рассказывали вам про INVEST-критерии для грамотной формулировки пользовательских историй (user stories). Предлагаем вам закрепить полученные знания и пройти КВИЗ 👀💡

Представьте, что вам необходимо проверить пользовательские истории, которые сформулировал ваш коллега-аналитик 🦸‍♀️🦸
Ознакомьтесь с условиями каждого вопроса и укажите, соответствует ли история заданному критерию.

Пока коллега несёт вам документацию, предлагаем отмотать сообщения выше и вспомнить про каждый из критериев 😉

Начинаем через два часа ⏰💥 #quizGetAnalyst

1️⃣ Внимательно изучите историю:

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

2️⃣ Проверим выполнимость критерия масштабируемости.

Вы уже знаете, что в разработку рекомендуется передавать истории низкого уровня, которые максимально детализированы.


Вернёмся к нашей истории про хранение персональных данных:

🔸 Как пользователь, я хочу, чтобы мои персональные данные хранились в системе в зашифрованном виде, чтобы предотвратить утечку данных.

И финальный вопрос (в чём сила?) 👀

3️⃣ Внимательно изучите историю:

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

💥 БОНУСНЫЙ ВОПРОС для самых умниц
(то есть для всех вас) 😊🖤

Представьте, что в бэклоге продукта две истории:

🔸 Как пользователь, я хочу привязывать банковскую карту к профилю, чтобы удобнее оплачивать заказы в приложении;

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

Друзья, очень важно не забывать, что история может совсем не соотвествовать INVEST-критериям (не надо так), а может соответствовать только части из них.


Разберём на примере:

🔹 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных

☝️ История явно не выполняет критерий оцениваемости, потому что нет информации о том, каким способом необходимо зашифровать номер банковской карты.

✌️Но эту историю можно протестировать, банально проведя анализ того, какие данные указывает клиент и как они отображаются в системе и на интерфейсе пользователя.



Задача бизнес- и системного аналитика как раз и заключается в том, чтобы сформировать конечное пользовательское требование в истории так, чтобы все INVEST-критерии были учтены.
Поэтому очень круто, что мы можем ошибаться на этапе обучения, чтобы потом меньше ошибаться на реальных проектах, верно? 🙃


Вот такие вот дела. Как вам КВИЗ, кстати?
Если такой формат для закрепления материала понравился, ставьте реакции – будем почаще запускать 😊

В мире IT существуют два вида аналитиков: бизнес-аналитики и системные аналитики #expertGetAnalyst

🟡 Бизнес-аналитики разбираются в потребностях заказчика в автоматизации бизнеса.
🟡 Системные аналитики превращают потребности заказчика в понятные задачи для команды разработки, а также занимаются проектированием функциональной и архитектурной части систем.

Системный аналитик - это почти архитектор, который строит фундамент системы и рассказывает как она должна работать программистам и тестировщикам. Без нашей работы процесс разработки был бы хаосом из переговоров между непонимающими друг-друга программистами и бизнес-заказчиками.

В статье "О роли системного аналитика и шаблоне для проектирования" я рассказала:
▫️кто такие аналитики в IT,
▫️познакомила с их задачами,
▫️поделилась шаблоном для написания требований и постановки задач.

Если вы только пытаетесь понять кто такие системные аналитики и их зону ответственности, или уже работаете системным аналитиком и ищете свои точки роста, то эта статья для вас 😉

У многих не было возможности подойти к делу, которым они занимаются, осознанно, с толком, чтобы нравилось изначально. Обычно просто нет на это времени.

Очень много случааев, что работа или учеба были выбраны, потому что так сказали родители, или потому что нужны были деньги и важно было закрыть базовые потребности.

Но есть и другие истории, когда люди выбирали из того, что нравится. Так как не было финансовых проблем, или ранняя осознанность, что случается реже.
Я рассказывала о том, что выбрала профессию системного аналитика сразу после школы. Но мой случай скорее исключение из правил, чем норма.
И если так получилось, что свою работу вы выбрали сами, то скорее всего вы кайфуете от нее, как я от системного анализа ❤️

Сейчас я делюсь своей любовью к профессии с вами, рассказываю о своем призвании. Чтобы вы могли посмотреть на эту ИТ-профессию моими глазами и принять осознанное решение куда и как расти в ИТ, или как войти в ИТ на позицию системного аналитика.

Важно, чтобы при выборе профессии было время подумать и не было паники. И появлялось ощущение кайфа от того, чем вы будете заниматься. Хорошо, когда есть возможность попробовать поделать что-то на практике. В фоне к основной работе. Не обязательно менять резко свою сферу деятельности.

Для меня в профессии аналитика кайф - это релиз. Когда я вижу, как результаты сбора требований, проектирования, плотной работы с разработчиками и тестировщиками, начинают приносить пользу людям. Это важно 🙌

Я точно знаю, что своё дело можно выбрать в любой момент. Можно менять профессию, менять компанию, направление деятельности, расти в должности. Главное заниматься тем, что нравится, прямо сегодня.

И хорошо, когда рядом с вами есть люди, которые вас поддерживают: любимые, родные, друзья и наставники. Их энергия поможет пройти любые испытания и преодолеть любые трудности. Их поддержка - ваша мотивация расти.

Окружайте себя людьми, кто верит в вас. И тогда любые перемены и рост в карьере будут даваться вам в гармонии, уверенности и с легкостью 🚀❤️

Привет! Записала для вас подкаст про то, как аналитики могут влиять на риски в IT-проектах и помогать их выявлять 😉