Лого vc.ru

Александр Бындю, ByndyuSoft: Пять самых важных составляющих процесса выпуска проектов

Александр Бындю, ByndyuSoft: Пять самых важных составляющих процесса выпуска проектов

Александр Бындю, руководитель компании ByndyuSoft, написал для VC колонку, посвящённую процессу разработки ИТ-продуктов, принятому в студии и найденному после долгих проб и ошибок, и привёл пример проекта, создаваемого таким путём.

Поделиться

Для создания ПО мы выбрали эмпирический подход и почти отказались от детерминистского. Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь оказывается всегда шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.

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

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

Иногда я буду писать «проект», а иногда «продукт». Для себя мы не разделяем два этих понятия. В книге «Бережливое производство программного обеспечения. От идеи до прибыли» есть интересная мысль, что любой проект можно рассматривать, как продукт, поэтому при разработке ПО мы используем подходы по созданию продуктов.

Уверен, что процесс, описанный ниже, подойдет для разных проектов, разного размера, разных предметных областей и так далее. На всякий случай скажу, что наш типовой проект обычно объемом работы от 500 человеко-дней, то есть начиная с загрузки для четырех человек на 4-5 месяцев. Вот на таких проектах мы и обкатывали предложенные подходы.

Общий взгляд на процесс

Разработка ПО — это процесс создания знания. В начале работы неопределенность очень высокая. Заказчик витает в облаках со своей идеей, разработчики неглубоко знают предметную область.

Мы много экспериментировали с разными методологиями от жёстких до гибких, от Agile до Lean, и пришли вот к такому процессу:

  1. Вся работа должна быть визуализирована: от процесса и целей до мелких пожеланий и требований. Мы исходим из простого принципа: «You cannot improve what you cannot see»
  2. Первое знакомство с проектом всегда начинаем с целей. Спрашиваем: «Как вы поймёте что достигли успеха?», «Что для вас является успешным продуктом?», «Представим, что продукт создан, по каким критериям вы его оцените?» и так до тех пор, пока цели не материализуются. Приоритизируем цели и путь до их достижения. Подробнее об этом написано в статье «Impact Mapping на практике».
  3. Следующий шаг понимания будущей системы — User Story Mapping. После описания сценариев, приоритизируем их и выбираем самые важные для ближайшего релиза, не надо пытаться охватить все разом.
  4. Выбираем список User Story для ближайшего релиза, делим истории на итерации и стартуем разработку. В каждую итерацию (у нас она равна неделе) обязательно входят: планирование на неделю, ежедневные стендапы, демо результатов работы в конце недели. Другие практики используются или нет в зависимости от потребностей проекта. Например, ретроспектива может быть раз в месяц или каждую итерацию.
  5. В любой момент заказчик и/или команда могут остановиться и вернуться к пересмотру Impact Map, или обновлению User Story Map или вообще сделать Pivot, так как текущая гипотеза оказалась ошибочной. В общем, всё является гибким, обсуждаемым и изменяемым.
  6. После реализации задуманных сценариев компануем релиз, делаем приемочное тестирование всех сценариев и другие виды тестирования, проводим демо по релизу, получаем одобрение всех стейкхолдеров и продукт выходит в свет.
  7. После релиза крайне важно вернуться к Impact Map и понять достигли мы целей или нет.
  8. Дальше весь цикл повторяется заново...

Релиз это обычно радость. Усилия наконец дают результат, все рады и довольны. Тем не менее мы считаем, что релиз прошел успешно только тогда, когда цели достигнуты. Если мы сделали все фичи, всё прекрасно работает, код отлично написан, всем, включая заказчиков, этот релиз нравится, но цели не достигнуты — значит релиз прошел неуспешно, надо сделать ретроспективу и понять в чем проблема.

Более детальный взгляд

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

Постановка задачи

Как уже было написано, для начала нам надо понять цели проекта. Для этого мы используем Impact Mapping. Обычно работа по созданию Impact Map занимает от дня до недели, зависит от размера проекта и свободного времени у всех заинтересованных лиц.

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

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

Глазами пользователей

Примерно к финалу формирования Impact Map становится возможно стартовать работу по созданию User Story Mapping. Карта сценариев состоит из:

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

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

Создание User Story Map обычно не происходит с первого раза. Часто этот процесс занимает несколько итераций с постоянным уточнением ролей, активностей и приоритетов.

Первые прототипы

Когда User Story Map близок к полноте, UI/UX-специалисты приступают к первым UI-прототипам. Важно быстрее проверить основные концепции, которые есть в нашем User Story Map. Бывает, что эти прототипы рисуют просто на бумаге, сканируют и рассылают. Но даже от таких простых прототипов возникают более конкретные вопросы и возвраты на переформатирование User Story Map. Пример прототипа на бумаге из нашего проекта:

В это же время разработчики пишут код через TDD, чтобы лучше понять предметную область. Вот один из примеров такого кода на C#:

[Test]

public void IgnoreAdsIfStartDateIsNotReached()
{

var entertainmentVideo1 = new Video(VideoType.Noncommercial, 30) {Id = 1};

var adsVideo1 = new Video(VideoType.Ads, 10) {Id = 2};

var adsCampaign = new AdsCampaign(adsVideo1, 120, new DateTime(2014, 09, 10), new DateTime(2014, 10, 25));

var videoTimeline = new VideoTimeline(new List {adsCampaign},
new List {new NoncommercialContent(entertainmentVideo1)}, new DateTime(2014, 09, 09), 30);

IEnumerable playlist = videoTimeline.CreatedPlaylist;

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

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

Результатом первой фазы является понимание измеримых целей, набор User Story на релиз и некоторое представление о системе за счет прототипов интерфейса и кода, написанного через TDD.

Работа над релизом

В этой фазе идет активное печатание кода, настройка Continuous Deployment, тестирование и так далее обычная такая разработка. Мы часто используем TDD, CQRS, различные СУБД, чтобы точнее попасть в требования к системе в рамках стоимости инфраструктуры и гибкости. Большое внимание уделяем DDD.

Практически никогда не создается Big Design Up Front. Работа над программной архитектурой происходит инкрементально. Мы рисуем архитектуру, выбираем точки расширения и масштабирования, которые согласуются с целями системы. Как мы уже говорили, цели системы периодически меняются, поэтому архитектура должна быть гибкой, чтобы успевать меняться за видением проекта. В архитектуре важно с одной стороны не быть архитектурным астронавтом, а с другой — иметь опыт проектирования сложных систем.

UI/UX, разработчики и QA-инженеры постоянно взаимодействуют друг с другом. Промежутки от планирования до демо небольшие — всего одна неделя, поэтому работа получается довольно плотная. Результатом каждой итерации является инкремент к релизу, который двигает нас в сторону достижения целей.

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

К чему готовить заказчика

Это может быть странно, но далеко не все заказчики готовы к такому интенсивному взаимодействию. Гораздо проще закинуть ТЗ в команду и через полгода вернуться, чтобы посмотреть на результат работы.

Нам такой вариант не подходит. Рекомендуем ещё на старте проекта обратить внимание заказчика на следующее:

  1. Заказчик должен быть готов, что ему придется активно участвовать в жизни проекта и работать наравне с командой
  2. Заказчику придется принимать довольно много решений под свою ответственность исходя из своего опыта, целей, знаний или чего-то еще, отсидеться в стороне не получится

Практика включения заказчика в команду известна под названием Onsite Customer и является, например, частью Extreme Programming. Обсудите в самом начале, как вы будете общаться, как часто это будет происходить, через какие каналы связи, что значит принять участие в демо и так далее Всё это важно, так как может изменить привычный ритм жизни заказчика.

Бизнес-кейс

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

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

Предметная область проекта: транспортная компания, работа с налогами на экспортные перевозки. Создание продукта включает несколько релизов, первый релиз был объёмом около 800 человеко-дней.

Первая попытка создания продукта

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

Предыдущая компания придерживалась каскадного процесса. Им написали ТЗ, они ушли в работу. Вернулись через сколько-то месяцев и показали то, что сделали. Как оказалось, сделали совсем не то, что нужно, но ровно то, что написано в ТЗ. Созданной системой невозможно было пользоваться в реальных условиях бизнеса.

Из описания причин провала мы выделили:

  • Главная проблема — сложная предметная область. На данный момент мы можем сказать, что предметная область действительно сложная и довольно запутанная, но разве с налогами бывает как-то иначе?
  • В ТЗ написано одно, а по факту надо было другое. Например, количество Приложений, относящихся к одному акту, может быть неограниченным, может перечисляться через запятую, а может и через интервал посредством дефиса.
  • В ТЗ многие детали были пропущены. Например, не было сказано, что номер Акта является уникальным в рамках Договора и года. На первый взгляд небольшая деталь, но она может значительно повлиять на реализацию.

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

Начинаем с целей

Мы подготовили всех стейкхолдеров к Impact Mapping. Разослали материалы с описанием этого инструмента, попросили выделить пару часов времени для созвона.

На Impact Mapping со стороны заказчика пришли: технический директор с заместителем, главный бухгалтер с помощниками и коммерческий директор. Это была большая удача, так как удалось с первого раза собрать всех нужных людей. С нашей стороны была вся команда.

Обычно в начале я говорю провокационную фразу, звучит она примерно так: «Давайте по-быстрому запишем цели и пойдем дальше рассматривать роли и так далее». Каждый участник уверен, что цели все знают, поэтому кто-то просто озвучивает то, что считает целями проекта. Вся соль в том, что этого человека сразу поправляет другой, так как цели в его голове были другие, его тоже поправляют и так далее Начинается оживленная дискуссия на тему того, что же мы собрались сделать? Команде разработчиков на этой стадии важно замолчать. Не надо мешать всем заинтересованным лицам высказаться. Во время обсуждения происходит кристаллизация целей в голове заказчика (всех стейкхолдеров), от команды требуется эти цели просто записать.

Конкретно в этом проекте на Impact Mapping ушло около трех часов, вот одна из частей:

После этого в течение нескольких недель заказчики сами возвращались к Карте воздействий и вносили туда изменения.

Важно правильно настроиться к Impact Mapping. Надо понимать, что стейкхолдеры — это люди с высокой квалификацией в своей предметной области. Они очень глубоко знают предмет, но не имеют большой опыт в создании ПО. Поэтому мы им помогаем активным слушанием и задаем много «глупых» вопросов, чтобы как можно сильнее раскрыть их знания.

Работаем с историями пользователей

Когда цели и путь до них были определены, мы стартовали User Story Mapping. Со стороны заказчика участвовали технический директор с заместителем, а с нашей стороны, как обычно, вся команда. Обратите внимание, что «нетехнические» стейкхолдеры в этот момент уже не принимали участие.

Первую версию User Story Map сделали примерно за два-три часа:

В отличие от Impact Map, который часто меняется только в начале проекта, User Story Map меняется и пересобирается на протяжении всего проекта. Чем сложнее предметная область, тем чаще нас и заказчика посещают озарения, тем чаще вы возвращаетесь к пользовательским историям.

User Story Map дает заметное преимущество — у вас появляется шанс до старта разработки углубиться в предмет. Для нас этот инструмент относится к артефактам, без которых практически невозможно делать полезные проекты.

Модель предметной области

Проработка модели предметной области ведется волнами, как и все другие части проекта. Разработчики и дизайнеры совместно работают с этой моделью. В модель мы обычно включаем только ключевые сущности, почти никогда не рисуем все-все объекты. Развитие модели выглядело вот так:

В этой анимации показано полгода работы.

Разработка интерфейса

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

  1. Когда дизайнеры внутри своей группы считают, что ценный инкремент достигнут, они показывают его внутри команды.
  2. Разработчики дают обратную связь о реализуемости, все вместе проверяют на работоспособность и непротиворечивость, макеты дорабатываются.
  3. Исправленные макеты дизайнеры демонстрируют заказчику, получают новую порцию замечаний уже по бизнесу.
  4. На этом половина пути дизайн-макетов пройдена. После запуска макетов в работу часто возникают новые непредвиденные проблемы. Например, разработчики обнаруживают, что новая часть системы не стыкуется со старой концепцией. Или реализация интерактивности блока потребует больше времени, чем его осталось. В этих случаях дизайнеры с разработчиками совместно приходят к решению, как решить задачу элегантно и в срок.

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

Нет смысла рисовать красивые дизайны, которые разобьются впух при встрече с реальными данными. Чтобы не было мертворожденных макетов, дизайнеры с самого начала собирают данные у заказчики или «в поле». Если никто данных не даёт, почти во всех случаях можно прикинуть экстремальные значения для каждого блока или элемента (например, самые длинные и самые короткие строки, длинные непереносимые слова, самое больше разумное для этой системы число и так далее) и проверять макет на них.

Разработка и релиз

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

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

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

Почему это работает

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

  1. В самом начале мы понимаем, что на самом деле надо продукту для успеха.
  2. Постоянная обратная связь и полная прозрачность процесса. Подробней про это в статье «Customer satisfaction для программистов: Доверие и прозрачность».
  3. Качественный код, но это же по умолчанию должно быть.

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

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Великолепная статья, спасибо!

Вопрос есть вот такой: что делать, если на этапе «работы над релизом» с заказчиком приходим к решению, что функционал надо менять. Если возвращаемся к «Impact mapping», но работаем по фиксированной цене, как правильно подсчитать, сколько клиент должен доплатить? Ведь, если честно говорить, это ведь работа веб-разработчиков – грамотно запланировать релиз.

И ещё очень интересно, на каких этапах этого процесса клиент вносит деньги и как подсчитывается стоимость конкретного этапа?

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

Единственное, что осталось в статье про деньги, вот этот фрагмент: «Интересно, что глобально проект разрабатывался по схеме Fixed price». Действительно, работа шла по Fixed price, но Scope был гибкий :) Большенство наших контрактов идет по схеме T&M. В статье я немеренно уточнил, что этот проект был по Fixed price, чтобы показать, что процесс довольно адаптивный к разным схемам оплаты.

> на этапе «работы над релизом» с заказчиком приходим к решению, что функционал надо менять

Я бы сказал не «если», а это 100% происходит. Из статьи может быть не очевидно, но у нас релиз выкатывается минимум раз в неделю, а вообще обычно каждый день. Т.е. этап «работы над релизом» это не какая-то последняя неделя, а это весь процесс разработки, те самые итерации (если Scrum) или поток (если Kanban).

Представьте себе, что в течение 3-4 месяцев стейкхолдеры каждую неделю видят куда мы двигаемся. В этом случае функционал надо менять постоянно, User Story Map надо пересматривать постоянно. Зато, когда приходит время завершать проект, все стейкхолдеры уже сто раз видели результат и пользователи им уже пользуются и вся обратная связь учтена.

> Ведь, если честно говорить, это ведь работа веб-разработчиков – грамотно запланировать релиз.

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

Фокус планирования релиза в том, что мы идем к целям проекта, это и есть наш план. Что мы для этого реализуем? Будем архитектура монолитная или горизонтально масштабируемая? Будем у нас мобильное приложение или нет? И другие вопросы довольно сложно запланировать. Даже сами заказчики признают, что в долгосрочной перспективе всё не так понятно и возможно будут изменения. Но мы то с вами знаем, что изменения будет наверняка :)

> Если возвращаемся к «Impact mapping», но работаем по фиксированной цене, как правильно подсчитать, сколько клиент должен доплатить?

Если вдруг клиент должен доплалить по схеме Fixed Price, то значит процесс был построен как-то не так. Если мы не успели, значит фичи не были порезаны до необходимого минимума, значит мы дали клиенту полную свободу воображения и он улетел в космос далеко от реальных целей, которые мы планировали.

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

> И ещё очень интересно, на каких этапах этого процесса клиент вносит деньги и как подсчитывается стоимость конкретного этапа?

Если мы говорим про T&M, то здесь оплата ежемесячная. Если про Fixed Price, то обычно это предоплата до начала работ, оплата по этапам (те самые мини-релизы) обычно раз в 2-3 месяца и оплата после релиза.

Надеюсь на всё ответил, если нет, то буду рад продолжить :)

0

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

Андрей, согласитесь, что любое, даже самое подробное ТЗ обычно разбивается об реальность. Я могу себе представить ТЗ на проект, который длится 1-2 месяца и даже могу представить, что его можно сделать просто по ТЗ. Но если мы говорим о проекте, который идет годами, то ни одно ТЗ не выдерживает проверку реальностью.

> подробное ТЗ не нужно

А я не говорил, что оно не нужно. Я даже очень рад, если у заказчика уже есть подробное ТЗ. Речь ведь не о том нужно оно или нет. Речь о том, что надо быть готовым к тому, что в ТЗ учтено не всё. Весь процесс построен на вытаскивании знаний, которых как раз не опишешь в ТЗ.

Разве можно в ТЗ описать живое общение со стейкхолдерами, когда они спорят друг с другом о целях проекта? :)

> В будущем высока вероятность, что функции системы, которые в случае водопада были бы сразу предусмотрены

Предусмотреть можно при любом процессе, как и не предусмотреть можно в любом. Водопад же не гарантирует, что вы всё предусмотрели :)

Весь вопрос в том, на сколько глубока будет проработка и на сколько гибко мы будем относится к изменениям в дальнейшем. Я видел как гибнут проекты, где был жестокий Big Design Up Front. Ситуация была неприятная со всех сторон:
- архитектор уже всё прорисовал и не хотел признавать, что архитектура не идеальна
- разработчики выкручивались как могли, чтобы втиснуть "реалии" бизнеса в придуманную архитектуру
- заказчик получит систему, про которую все знали в начале проекте, а не ту, которая могла бы родиться, когда архитектор и разработчики углубились в детали предметной области
- в итоге, все получили то, что было на бумаге, но это очень тяжело ложилось на реальный бизнес

Архитектура в понимании многих, к сожалению, это набор любимых кубиков, из которых они пытаются построить что-то, что нравится им самим. На интервью один архитектор-wannabe так и сказал: "критерий качества архитектурного дизайна - это чтобы я сам всё в нём понимал"

Том Гилб в своей курсе "архитектуры" вообще не затрагивает процессы или технологии. Он начинает и заканчивает практически тем же, чем и вы в своём подходе - цели бизнеса, цели проекта. И для него важно, чтобы целей было не много и они были измеряемыми.

Очень бодрый дед, крайне рекомендую - vimeo.com/28763240

Читал взахлёб, местами узнавая себя :) После многих лет разработки, пришел примерно к этой же концепции и практикую нечто схожее, но в меньшем масштабе: при реализации новых фич, которые просит Product Owner и схожих задачах.

да есть у него название, есть. Как только появляется термин "быстрая обратная связь" - можно с уверенностью говорить, что вы используете аджайл-методологию. То что она не классифицируется четко как Скрам или ХР, говорит только о зрелости вашей команды, которая переросла уровень doing by the book, и может свободно комбинировать различные методологии для достижения желаемого результата.

Отличная статья!
Во вторник еду в Зеленоград заказывать SaaS-сервис за один миллион рублей для своей "Пивной сетевой компании".
Покажу им эту статью. Пусть попробуют поработать по-новому.

Лев, вы хоть не рассказывайте в Зеленограде, что хотите заказать SaaS сервис для своей пивной компании ))) SaaS - это Software As Service, ПО как услуга - облачный сервис для широкого круга потребителей (типа Dropbox), а не для одного конкретного заказчика.

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

Было бы очень интересно поподробнее узнать про то, как построена работа с User Story, да и инструмент, который вы для этого используете.

Никита, какие конкретно вопросы есть по работе с User Story?

На счет инструмента. Если команда и заказчик могут встретиться, то идеально использовать стикеры и стену. Это самый гибкий и наглядый инструмент. Прикрепил пример User Story Map из нашего офиса.

Если команда распределенная, то тут без интерактивных инструментов не обойтись. Мы пробовали самые разные и остановились на Google Docs. У него есть два очень важных преимущества: 1. У всех есть аккаунт в Google Docs. 2. Никому не надо объянять как работать с Google Docs. Для клиентов не-айтишников это огромные плюсы.

0

Очень интересно.

А анимация (в которой полгода работы) в каком инструменте сделана?

Я так понимаю, это по сути наметки базы данных. Я с таким инструментом для такого визуального проектирования встречался:
www.databaseanswers.org/data_models/medical_laboratories_with_payments/index.htm

0

Александр, эта анимация является простой gif-файлом и сделана вручную, никакой магии.

> это по сути наметки базы данных

Как раз нет, это не БД. Важно то, что это именно предметная область. Схема БД гораздо сложнее и менее наглядная.

0

То, что gif-файл, это понятно.

А сами блок-схемы в чем рисовались? В MS Visio?

0

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

Сейчас обсуждают
Миша Иванов

Ребят, броcить кyрить сейчас действительно легко, за 2 дня я излечился и чувствую себя намного здоровее, не теряй шанс изменить свою жизнь. Вот мой блог - ur1.ca/pqc2w

«Подделки принесли нам 1,5 миллиона рублей за два месяца»
0
Миша Иванов

Ребят, броcить кyрить сейчас действительно легко, за 2 дня я излечился и чувствую себя намного здоровее, не теряй шанс изменить свою жизнь. Вот мой блог - ur1.ca/pqc2w

Mozilla высмеяла запреты Европейской комиссии по копирайту с помощью культовых мемов
0
Миша Иванов

Ребят, броcить кyрить сейчас действительно легко, за 2 дня я излечился и чувствую себя намного здоровее, не теряй шанс изменить свою жизнь. Вот мой блог - ur1.ca/pqc2w

Почему компаниям выгодно делать свои продукты хуже
0
Миша Иванов

Ребят, броcить кyрить сейчас действительно легко, за 2 дня я излечился и чувствую себя намного здоровее, не теряй шанс изменить свою жизнь. Вот мой блог - ur1.ca/pqc2w

Xor — бот для поиска вакансий и сотрудников в ИТ
0
Миша Иванов

Ребят, броcить кyрить сейчас действительно легко, за 2 дня я излечился и чувствую себя намного здоровее, не теряй шанс изменить свою жизнь. Вот мой блог - ur1.ca/pqc2w

Бесплатная раздача товара для привлечения покупателей: примеры Mountain Dew, Velle и других компаний
0
Показать еще