Как правильно разделить разработку веб-проекта на юзер-стори?

Question

[Алекс Понтик]

Пытаемся в команде внедрить гибкую методологию разработки веб-проектов. До этого работали по классическому waterfall (Каскадная модель), но проекты тянуться в сроках.

В данный момент пришла задача на перенос крупного проекта с одной платформы(asp.net) на другую(php). И у меня стал вопрос, каким образом правильно подойти к поставлению юзер-стори проекта.

Проект должен пройти в любом случае через:

• разработку интерфейса
  
• верстку
  
• программную часть
  
• админ-панель
  
• api
  

Коллеги, прошу вашей помощи :)

Принцип работы по методологии сложился полностью, затык именно в юзер-стори(хотя может я и ошибаюсь)

Answer 1

[samizdam]

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

Надо также учитывать, что все Agile методологии, требуют постоянного (и на мой взгляд большего) вовлечения заказчика в процесс, в сравнении с традиционными подходами. Например в месте где я сейчас работаю, при всей моей любви к User Stories, Scrum, я прекрасно понимаю что любые попытки внедрить их обречены на провал - т.к. заказчику это не нужно, не интересно, не когда. А насаждать Agile только ради того чтобы разработчики поигрались, не самая удачная идея. Разные фишки пытались внедрять, но всё шло прахом из-за низкой вовлечённости заказчика в процесс. Хотя отдельные, чисто технические Agile-фичи в разработке успешно используем: TDD, CI, рефакторинг, ну и многое из XP в разработке хорошо приживается, разработчики довольны. Платформа у нас кстати тоже php =)

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

В общем это я своими словами описал принцип "Заказчик всегда рядом".

Ещё один из основополагающих принципов ( в той же книге ему не мало внимания уделено, насколько я помню): интерфейсные решения должны приниматься как можно позже. Темы вёрстки и интерфейса и должна быть не раскрыта как можно дольше. Идите от функциональных требования к системе, а не от прототипов интерфейса! Я лично вообще считаю проектирование от гуя большим злом и признаком не высокой компетентности бизнес-аналитика, если проект посложнее сайта визитки — стоит смотреть в сторону DDD. У Фаулера, кажется, на эту же тему есть формулировка о хорошем программном дизайне (воспроизвожу по памяти, могу ошибаться как в точности, так и в источнике):

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

Answer 2

[Тим]

Как всегда и везде, люди не до конца изучили agile/scrum и что то постят..

Ни где четко не прописано что заказчик должен быть вовлечен в процесс.

В первую очередь, SCRUM это управленческий фреймворк который позволяет упорядочить процессы, наладить коммуникации и поставлять инкременты итеративно.

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

Если мы говорим о настоящем Agile Scrum, то собираем команду, изолируем её от всего кроме нашего проекта и дальше по методологии:

(тут есть только 2 простейших процесса где нужен заказчик на 1-2 часа в 2 недели. типичная ошибка, звать его везде как этому учат на дурацких тренингах за 1000$)

1. Собираем с заказчика хотелки и пихаем в беклог
2. Собираемся и грумим беклог дробя эпики на мелкие стори или еще мельче эпики
3. Делаем спринт пленинг и дробим беклог на задачи, поочередно оценивая всё
4. Согласовываем инкремент и какой Definition of Done
5. Работаем итерацию попутно проводя дейли статус митинги для синхронизации статусов и раннего выявления проблем
6. Демонстрируем в конце что получилось, собираем от заказчика фидбек и форматируем беклог, возвращая в него то что не готово и все что не влезло в спринт
7. Делаем ретроспективу и убеждаемся что копаем в нужном направлении и не делаем ничего лишнего либо добавляем в процессы работы то что стоило бы делать
8. Возвращаемся к пункту 1

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

Когда вы начинаете оценивать стоимость и сроки проекта под Agile/Scrum вы наступаете на теже грабли. Если заказчик не знает на что он идет то это не Agile.

Наши клиенты уже с шишками и готовы платить деньги не представляя стоимости проекта в целом и тем более его сроков. С большего это стартапы. На опыте запуски и провалы хороших проектов. Один из них уже 4й год на рынке и поднял 20 лямов инвестиций в США и сейчас является одним из успешных интернет магазинов в США.

Изначально на кармане у заказчика было денег понты и работало 2 человека на проект - бекенд и айос и копали-копали пока не выросли до постоянной команды в 5 человек (бекенд, фронтенд, айос, андроид, qa) которые непрерывно работают на проекте и копают спринтами один за другим. И ни кто никого не гонит. Заказчик купается в бабле

Answer 3

[Сергей Протько]

правильно подойти к поставлению юзер-стори проекта

user story - или пользовательский сценарий - это высокоуровневое описание фичи. Оно не содержит (ну точнее не должно) никаких деталей о том, как именно будет реализована фича. То есть никаких ссылок на то что "пользователь кликает на что-то", или там "пользователь шлет запрос на API". Только бизнес выжимка.

Пытаемся в команде внедрить гибкую методологию разработки веб-проектов

Главное понимать зачем вы это делаете и чем это от вотерфола отличается. Agile != scrum или kanban, там не обязательно загоняться по юзес сторям и т.д. Суть только в уменьшении цикла обратной связи. Что бы клиент что бы посмотреть результат ждал не пару месяцев а пару недель. Что бы в тестирование фичи попадали не раз в месяц а хотя бы раз в неделю. Ну и т.д.

Ну и рекомендую посмотреть докладик: Agile is Dead • Pragmatic Dave Thomas

Comments

[Алекс Понтик]

Спасибо, буду смотреть.

Answer 4

[Петр]

"Проект должен пройти в любом случае через" этим вы уже отстраняете себя от гибкой методологии.
А далее user story это просто маленькие задачки, притом целостные.
И эти задачки должны иметь бизнес цену.
К примеру "добавить функцию в API" для бизнеса в разы ценнее, чем "Добавить анимацию на кнопку".

Comments

[Сергей Протько]

"добавить функцию в API" может быть таким же как и "добавить анимацию на кнопку" если его изначально интересовало "сделать возможность оформления заказа".

[Петр]

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

[Сергей Протько]

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

Answer 5

[Елизавета Борисова]

Проект уже реализован, со всеми user story. Или вы собираетесь новые фичи добавлять ? Перенос все-таки немного отличается от разработки нового проекта (вы уже видите весь объем, детали проработаны, часть можно использовать и т.д.), не вижу целесообразности описывать user story снова.

перенос крупного проекта с одной платформы(asp.net) на другую(php)

Тема верстки и интерфейса в этом разрезе не раскрыта. Видимо, дизайн тоже новый, возможно, действительно юзер стори поменялись