Как мы должны обращаться с дополнительными косметическими функциями в спрутах Scrum?

Я читал документы Scrum, и там говорится, что задачи в Sprint должны быть «потенциально отправляемыми».

Я смущен тем, что это значит. Предположим, что в Спринте 1 целью была «форма регистрации пользователя».

Сколько деталей мне нужно добавить, чтобы что-то было готово к отправке? Например:

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

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

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

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

Согласитесь с владельцем продукта и командой Scrum, а не с Интернетом. Это должно быть определено в вашем определении «Готово» и будет в значительной степени зависеть от того, как работает команда.

Хотя функция должна быть «отправляемой» (я ненавижу этот термин в Scrum), можно утверждать, что функциональность может быть доставлена ​​без пользовательского интерфейса. Многие люди страдают от этого заблуждения в Scrum - цель спринта состоит в том, чтобы получить как можно больше историй (в идеале, всех) «Готово», но совершенно точно не нужно встраивать их во что-то, что можно было бы выпустить.

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

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

Пока команда знает ответ, не имеет значения, какой ответ.

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

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

Если вы спрашиваете об этом как разработчик, ответом будет «вы знаете, потому что владелец продукта скажет вам, хотят ли они косметические функции или нет».

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

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

«Потенциально отправляемый» означает способный к отправке, не обязательно тот, который вы отправляете. Например:

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

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

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

Идея в том, чтобы быть как можно более гибким. Чем быстрее вы сможете что-то донести до реальных пользователей; будь то бета-копии кода для выбора отдельных лиц или A / B-тестирование на вашем сайте, тем лучше. Если вы покажете пользователям слишком грубый и грубый код, определенный их ожиданиями в отношении вашего продукта, он даст вам бесполезную обратную связь. Они будут говорить о вещах, которые вы не ищите, например: им не нравится, что кнопка желтая или текстовое поле не совпадает с метками. Если это достаточно хорошо, то вы можете получить полезную обратную связь. Чем быстрее вы получите этот отзыв, тем лучше! Вы можете проверить соответствие продукта / рынка и сделанные вами предположения относительно функции, которую вы пытались создать.

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

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

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

Помимо других замечательных ответов на этот вопрос, вы также можете думать о косметических особенностях как о переменной области действия треугольника scope-resources-time. Убедитесь, что вы соответствуете основным требованиям этой истории, и добавьте красивые вещи, если у вас есть время.

Скрам не должен гарантировать доставку определенных функций в данное время. Это должно дать вам максимально полезную работу, которая возможна в данный момент времени. Если «дополнительные» косметические функции не были выполнены во время этого спринта, это должно быть потому, что они были невозможны.

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

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

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