Size: a a a

2021 September 23

R(

Roman (rpwheeler) in Pzdc
7) Есть подходы которые за написание тесткейзов заранее. Школа RST преимущественно против тесткейзов, за чеклисты, или гибкие тесткейзы, или их откладывание. Одного подхода заведомо нет. Где-то можно и полезно писать их подробно, где-то не нужно, где-то на них вообще нет времени и условий.  

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

R(

Roman (rpwheeler) in Pzdc
8) А ещё можешь вспомнить примеры книжек-док которые тебе нравятся, и делать как там. Но всё равно кому-то не понравится. :)
источник

К🌚

Катя 🌚 in Pzdc
А чего контакты писать, в джире и конфлюэнсе же и так все видно, не?
источник

R(

Roman (rpwheeler) in Pzdc
Всяко бывако. Иногда в джире и конфлюэнсе ты deleted user , а по факту ты ещё на том же аккаунте, просто команду сменил. Или две.
источник

К🌚

Катя 🌚 in Pzdc
Ого, не встречалась, спасибо
источник

К🌚

Катя 🌚 in Pzdc
Но по сути написанного опять согласна)
источник

MP

Mike Petrov in Pzdc
Переслано от Mike Petrov
А кто работал с требованиями к проектам. Возник такой вопрос, у меня вот есть юзер стори, требования и прочее. Но в первую же очередь надо по факту как можно больше претензий найти и задать вопросы по исключительным ситуациям которые не описаны, в ту сторону копаю ?
Если на примере интернет магазина - юзер может выбрать товары и их заказать. Про флоу отказа(отмены) заказа ничего не написано.
Правильно ли я думаю что мне надо уточнить конкретнее как будет этот флоу работать и что делать если скажем - заказ оплачен но отменен юзером?
источник

MP

Mike Petrov in Pzdc
Переслано от Mike Petrov
Просто помню что в первую очередь позитивные проверки, в контексте требований - задать вопросы по тому что уже написано и уточнить как это будет правильно работать.
А потом уже пытаться "сломать систему" не типичными ситуациями ? Или этот этап вынести на потом? 🙄
источник

MP

Mike Petrov in Pzdc
Куа юа что то не особо захотели ответить ))) Мож тут эксперты есть ? )
источник

D

Denys 👻 in Pzdc
да, все норм =)
источник

К🌚

Катя 🌚 in Pzdc
Я не знаю, как на это ответить. Вдруг у тебя стартап и спасибо и на том, что хоть что-то в требованиях есть
источник

MP

Mike Petrov in Pzdc
да не, тут просто вопрос. Моя цель это доебаться до всего, или лучше сделать упор на бизнес флоу от заказчика который он описал на сегодня а исключительные ситуации оставить на потом и не выносить это всё на первые созвоны чтоб не пугать заказчика ? )
источник

К🌚

Катя 🌚 in Pzdc
Так-то нужно
1. Чтобы все работало в случае ожидаемого поведения (товары в корзину добавлялись, например)
И уже 2. Чтобы в случае неожиданного поведения все не ломалось а тоже как-то адекватно работало
источник

VY

Valentin Yuriev in Pzdc
А почему отмена заказа єто не бизнес флоу?
источник

К🌚

Катя 🌚 in Pzdc
Я б спросила, когда лучше уточнять неописанное
источник

К🌚

Катя 🌚 in Pzdc
Может там другой состав участников на встрече нужен
источник

MP

Mike Petrov in Pzdc
бизнес флоу, но тут вопрос про эксепшен ситуейшон. Когда скажем произшла какая то хуйня. Скажем два заказа на один товар а он один на складе, и кто изних получит этот товар(имею ввиду админ не успел обновить наличие)
источник

К🌚

Катя 🌚 in Pzdc
Ну скажи что у тебя много вопросов и спроси когда их удобнее обсудить, все равно же когда-то придётся
источник

К🌚

Катя 🌚 in Pzdc
Возможно на встрече-знакомстве не стоит этого делать
источник

К🌚

Катя 🌚 in Pzdc
Мы же рил не знаем твоих процессов
источник