Comments 9
Жжжжуть!
Приведу только 1 пример
Критерии приемки:- Нажатие на кнопку "Лайк" увеличивает счетчик лайков у соответствующего поста.- Пользователь может нажать кнопку "Лайк" только один раз для каждого поста.- Счетчик лайков обновляется мгновенно после нажатия на кнопку без перезагрузки страницы.
Попытка нажать на лайк второй раз крашит приложение. Но по формальным признаками приемка пройдена.
Спасибо, что развиваете тему! Здесь приведены очень простые примеры, которые дадут понимание как это устроено. Хотелось бы в комментариях увидеть ваши реальные описания эпиков, юзерстори и задач. Завтра утром опубликуем здесь примеры наших рабочих задач. Надеюсь это будет полезным.
Согласно требованию, второй раз нажать не может
Как вам подход без использования саб тасок, то есть без подзадач, только эпики, задачи ну и баги со спайками?
Это же сильно зависит от того, какой смысл Вы вкладываете в сущности таск-трекера и чем собираетесь управлять через него.
По моему опыту оказалось удобно сабтаски использовать для управления конкретными работами. Одна выполненная сабтаска может быть условно "бесполезной", т.е. ее нельзя никуда задеплоить или можно, но это ни на что вообще не повлияет. А вот история (состоящая из одной или нескольких подзадач) - это видимая для пользователя функциональность или законченный рефакторинг. Законченную историю можно задеплоить, протестировать и даже иногда использовать.
В общем, подзадачи - для управления работами и загрузкой исполнителей, а истории - для управления поставкой и инкрементами функциональности.
Вполне понятная и хорошая статья. Один минус на мой взгляд, часто встречаю при декомпозиции что все хотят исследовать существующие решения. А если их не существует?
Хм, а если я декомпозирую функциональность из примера ("Разработка добавления комментирования к постам в социальной сети") вот так:
Реализовать возможность просмотра комментария в виде простого текста без форматирования. То есть, на фронте это компонент отображения текста комментария, в БД - структура для хранения комментария, в API - метод получения комментария. Пока что к одному посту возможен один комментарий, для тестирования будем создавать его в БД вручную.
Реализовать возможность просмотра всех комментариев (и там возможная пагинация, подгрузка еще что-то в этом роде).
Реализовать возможность добавить комментарий по нажатию на кнопку в UI. На фронте - кнопка и условия ее доступности, в API - метод создания комментария, который пока что будет создавать захардкоженный текст. При проверке будем нажимать на кнопку и видеть, что список комментариев пополняется.
Реализовать возможность удалить комментарий по нажатию на кнопку.
Реализовать возможность ввести произвольный текст в качестве комментария.
Реализовать возможность форматирования текста в комментарии.
К какому виду декомпозиций из перечисленных в статье относится такое разбиение? Оно правильное, ну или хотя бы более или менее правильное, чем предложенное Вами в качестве рекомендации?
Как правильно описывать и декомпозировать задачи в таск-трекере. Рекомендации и примеры