ДИТ Банка России. "Есть вещи которые по agile делать нельзя"

А как это, делать по agile? :)

А то непонятно что конкретно нельзя

Сейчас кто-нибудь спросит

Agile vs безопасность

"Есть вещи которые делать, разделяя ценности agile мы еще не научились" - вот что он сказал

О, точно

Но как обычно, слушать и слышать - вещи разные

Согласен

В ДИТ - 7000 человек

Так кстати классно, Банк России* при тесном знакомстве очень технологичная компания

Теперь Альфа

Надежда Авданина очень живенько рассказала

Такой вопрос про сторирайтинг: Может есть у кого ссылка-пример с описанием всех возможных story по некой фиче продукта?

Здесь где-то пробегал вебинар про стори

@beskov ваш по-моему

наверное, об этом речь http://product.vision/user-stories/

О, а он платный :)

Такой вопрос про сторирайтинг: Может есть у кого ссылка-пример с описанием всех возможных story по некой фиче продукта?

1. User Story зачастую и есть фича 2. Тебе только заголовки User Story или полный текст?

1. User Story зачастую и есть фича 2. Тебе только заголовки User Story или полный текст?

лучше полный и мне тоже)

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

Обеденный полезняк - https://www.startwithwhy.com/About.aspx

Чтобы не утонуть специально обученные люди в 2006-году придумали User Story Map

https://docs.google.com/document/d/1e5XwZeBrvoYnrF8y7C5eRCpXxvfas4rPN3u12XT3RXM/edit# gid

https://docs.google.com/document/d/1e5XwZeBrvoYnrF8y7C5eRCpXxvfas4rPN3u12XT3RXM/edit# gid

что означают цифры в файле, например 24.1

номера сценариев

внутри истории

это копи-паст из jira, убрал лишнее

понял, спасибо

1. User Story зачастую и есть фича 2. Тебе только заголовки User Story или полный текст?

1. User Story зачастую и есть фича серьезно? мне всегда казалось, что фича - это уже решение, какой то результат. А стори - больше про проблему.

мне на собесе задали такой вопрос: чем отличается стори от фичи

А почему они задают такие вопросы?

Вот в чём вопрос :)

это собеседование, и они имеют право задавать разные вопросы, которые их интересуют :)

это еще вполне безобидный вопрос

Ну вы как думаете, интересно

:)

Я вот думаю какой толк мне от того знает pm разницу или нет, важно только делал он или нет

just curious

ну так а какой ответо то?

Я не знаю, мне кажется вопрос так себе :)

Юзер стори не предлагает детальное решение? А описывает процесс, который юзеру предстоит пройти?

Нет это шаблон для описания

us = pain, feature = solution

вот так

а стоит ли в us писать решение? или это скорее ошибка?

Дык... книжечку надо почитать, на вебинарчик сходить, чтобы разобраться. RTFM как говорят девелоперы :)

Можно ли так написать US, чтобы было понятно какое решение будет однозначно - скорее всего да, для тривиальных кейсов

Feature в широком смысле — свойство (продукта, приложения, системы, товара)

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

Эти "отличительные особенности" могут быть как функциональными, так и нефункциональными (атрибуты качества, ограничения)

фича имманентна

Обычно у B2C порядка 3-10 фич, которые используются при его маркетировании.

У B2B-продукта/системы фич может быть до нескольких сотен.

сейчас кодерок пояснит, что есть фича, а что - US

Дык... книжечку надо почитать, на вебинарчик сходить, чтобы разобраться. RTFM как говорят девелоперы :)

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

Классический пример названия фичи, например «Управление контрактами»

исторически пытались использовать такие перечни названий фич для задания рамок продукта/системы

но практика показала, что они слишком абстрактны

согласна)

а если переходить на реестр ПТ/ТТ — то получается очень подробно, но сложно оценить полноту и приоритетеы

так сначала для оценки рамок возникли Use Cases, а когда стало понятно, что они слишком объёмные как единица поставки, придумали User Story

С точки зрения классической инженерии требований и UC и US – это не требования, а трассировки. Диполи.

Обычно UC – это трассировка пользовательского требования «Отправить письмо» на множество технических требований (шаги сценария)

Я долго думал, что US – это трассировка пользовательского требования (возможность, задача) на бизнес-требование (польза, ценность)

Но практика последних лет показала, что в US может быть полный стек требований по 3-м уровням БТ->ПТ->ТТ

Теперь вернёмся к фиче

в US «Как респондент, я хочу сохранить черновик письма на потом, чтобы вернуться к нему позже»

часть «сохранить черновик письма» может быть маркетируемой фичей

а может и не быть — в зависимости от концепции и позиционирования продукта

само собой, есть авторы, которые предпочитают, чтобы истории писались в виде

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

Как респодент, я хочу иметь возможность дописать письмо позже, чтобы... ЧТО?

или даже «Как респондент, я хочу вернуться к неотправленному писму позже»

Это зависит от степени инновационности продукта

если мы создаём новый мобильный клиент, чтобы изменить то, как люди общаются, то критически необходимо задумываться над такими вопросами, как у Славы

если просто повторяем привычные паттерны в нашей мини-ERP, то можно и на уровне черновиков

Вот это круто :)

Но в целом все теже старые истины - создаем = думаем, копируем - не думаем