Это понятно, далее как с этими числами работать?

выбирать только из этих чисел?

Да.

Павел, вы спасли мой день! ТеперЬ я знаю, как нужно попугаев считать

Источник на аглийском есть?

https://www.mountaingoatsoftware.com/tools/planning-poker

Проще всего начать с этого.

https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning

Вот это совсем подробно.

https://www.youtube.com/watch?v=iEHyrNX4IR8

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

А на что повлияет тот или иной вариант?

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

Логически много что связано )

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

Вообще конечно это разные фичи, т.к. там даже персоны разные

Авторизация это права пользователя. Регистрация - создание учетки. Совсем разные вещи.

Есть какие-то примеры как делить проект или все опытно-эмперическим путем?

Если речь шла об аутентификации, то объединение с регистрацией выглядит логично.

Если речь шла об аутентификации, то объединение с регистрацией выглядит логично.

И даже тут имхо стоит делить

Либо я не понял оттенки смысла )

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

Вобще, это разные функции, конечно. А вот цель у них одна и та же

И даже цели разные )

Это зависит от уровня абстракции )

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

Под общей целью я имел ввиду персонифицированный доступ. Но есть и персональные цели, если детализировать. В конце концов, регистрироваться чтобы потом НЕ использовать. Это бизнесу не нужно. Для бизнеса цель одна. В чем может быть цель пользователя зарегистрироваться и НЕ использовать я не знаю. Разве что конкурент исследует boarding процесс. Но вряд ли создатели системы должны думать об удобстве конкурентов.

Но если говорить именно о BDD, то проще говорить о них независимо. Я бы сделал иерархию тестов - auth - login - register

Т.е. оставил бы в иерархии тестов и общий контекст и создал бы индивидуальный.

Есть какие-то примеры как делить проект или все опытно-эмперическим путем?

Есть.напомни мне во вторник, я сброшу Тебе шаблоны для разбиения.

Есть какие-то примеры как делить проект или все опытно-эмперическим путем?

Нашел https://agileforall.com/wp-content/uploads/2013/05/Story-Splitting-Flowchart-RUS.pdf

Есть.напомни мне во вторник, я сброшу Тебе шаблоны для разбиения.

Ты просто космос

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

Тесты - это тоже код, и они тоже должны быть поддерживаемы и должны рефакториться по мере необходимости. Поэтому всё что справедливо для кода (в данном случае говорим о модульности, связности и связанности), справедливо и для логики сценариев BDD. Если можно эти сценарии разделить, то скорее всего удобнее будет разделить.

Тесты - это тоже код, и они тоже должны быть поддерживаемы и должны рефакториться по мере необходимости. Поэтому всё что справедливо для кода (в данном случае говорим о модульности, связности и связанности), справедливо и для логики сценариев BDD. Если можно эти сценарии разделить, то скорее всего удобнее будет разделить.

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

Да, тут прям целевая аудитория собралась )

Мне вот яндекс.директ начал предлагать работу курьером в деливериклаб.

Намекает

намекает что все эти ваши агили фигня а могли бы курьером работать 😄

Ну курьеры сейчас как бы сильно востребованы. Без них никуда))

Ну курьеры сейчас как бы сильно востребованы. Без них никуда))

Коучи тоже. Аж из США импортируют :)

Всем доброе утро

У кого доброе)) а у кого уже рабочий день заканчивается)

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

Спасибо что выслушали :)

😀

Коллеги-люди, пожалуйста представляйтесь и используйте тег #whois 😉, коллегам-ботам представляться необязательно

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

@Maksimgeolog * Регистрация * Аутентификация * Авторизация это три разные функции. Могут быть реализованы в трех разных системах. Тремя разными командами. в разное время. Могут дублироваться. Как минимум разделите регистрацию и вход в систему.

@Maksimgeolog * Регистрация * Аутентификация * Авторизация это три разные функции. Могут быть реализованы в трех разных системах. Тремя разными командами. в разное время. Могут дублироваться. Как минимум разделите регистрацию и вход в систему.

но зачем? скорее всего это часть одной user story

но зачем? скорее всего это часть одной user story

Неа. Особенно, если это разные системы. Код для одной лежит в гите, другой в слиаркейс, третьей в расшаренной сетевой папке (не спрашивайте почему так). Добро пожаловать в мир кровавого энтерпрайза!

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

всякие там лдап... ага

но это скорее редкая ситуация

Чаще все таки делают общую систему. Ибо они тесно связаны. Одна база юзеров. И регистрация и аутентификация с ними работают. Но вот тесты точно стоит делить

Чаще все таки делают общую систему. Ибо они тесно связаны. Одна база юзеров. И регистрация и аутентификация с ними работают. Но вот тесты точно стоит делить

+1. Для простеньких систем можно объединить аутентификацию и авторизацию, но регистрацию делайте отдельно.

Странно )

Я бы авторизацию как раз бы выносил даже на простеньких системах )

Потому что она по смыслу совсем о другом

Регистрация и аутентификация о пользователях. Авторизация об их правах.

но зачем? скорее всего это часть одной user story

Нет, разве что аутентификация и авторизация. И то не во всех с системах. Регистрация точно отдельно

Нет, разве что аутентификация и авторизация. И то не во всех с системах. Регистрация точно отдельно

а зачем оно пользователю?

я как пользователь хочу регистрироваться на сервисе что бы что?

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

да нифига

В целом чтобы что будет в каждой системе своё, но оно будет

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

Чтобы что?

во 😄

Ортодоксальные юзерстористы

и тут есть достаточная свобода чтобы DT вообще сделала это без пользовательской регистрации 😄

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

Это очень общая сторя

Тебе чтобы ее впихнуть в спринт, придётся делать спайки для верификации опций :)

Это очень общая сторя

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

Какое это отношение к авторизации имеет?:) Или ты поспорить хочешь?

такое что это все части одной user story 😄

Так-то разумеется лучше с формулированиям проблемы начинать

такое что это все части одной user story 😄

Это эпик :)

или иметь историю на сервисе и иметь возможность эту историю прочитать это разные кейсы? ну как бы нифига на самом деле 😄

Из минимум двух user journeys