Комментарии 22
"Во всем как всегда виноват аналитик..."
Милая статья, но даже она свелась к тому, что гады-аналитики ленятся писать ТЗ подробно :)
Все в итоге свелось к "здравый смысл" во время груминга. Т.е. это хорошо если разработчики на момент груминга это заметят и обсудят. А может получиться так, что собрались обсуждать ТЗ, а всем все ясно, и формат данных так и не обсудили. Т.е. груминг не решает полностью проблему, хоть и помогает ее минимизировать.
Если в команде началась игра "Переложи проблему на другого" то тут явно проблемы. Аналитик должен вовремя получить обратную связь по ТЗ, во вторник при разработке или в среду от тестировщика. А дальше скорректировать ТЗ и оповестить исполнителей.
Так же тестировщик должен тестировать фронт и бэк отдельно. Тогда бы сам тестировщик заметил пробел в ТЗ и невозможность тестировать бэк
Рад что основная мысль дошла верно! Всё так, здравый смысл имеет место быть. Но, к сожалению, такие моменты надо отлавливать как можно раньше. Вот, кстати, вариант про вовремя полученную обратную связь по ТЗ тоже хороший инструмент, я бы даже сказал сильный!
Идея в том, что не именно груминг решит проблему, а в том, что это всё не "однопользовательский геймплей", тут нужно работать в команде. К сожалению "переложи проблему на другого" довольно частые кейсы, и я бы хотел чтобы читатели обратили на это внимание, и вовремя констатировали такой факт если что-то подобное увидят в своих командах.
Два раза перечитал статью. Стиль изложения оригинальный, но сложный. Спасибо, что в конце есть "Подведем итоги".
Справедливое замечание по поводу того что стиль изложения слегка, назовем это так, необычный :) Возьму на заметку - нужно будет упростить. Понимая это я и завершил статью подведением итогов. Но в любом случае я премного благодарен за двойное чтение. Так же буду рад если что-то из этого пригодится на практике.
аналитик реально плохо составил тз, оба разраба вместо того чтобы остановится когда непонятно в каком формате передавать нафигачили код как вздумалось и решили это все ... введением коммуникации)))
боюсь у вас все трое оказались джунами и ваше "решение" прокачает остальных джунов до такого же уровня;)
ну да, и в первой цепочке забыли про существование тестирования требований.
Угу, всё верно. И аналитик плохо заТЗшил и разрабы ушли в самоволку )
Я бы немного похоливарил на тему джуны они или нет ;) Как я вижу градацию от джуна до синьора:
Джун - не знает что делать и не знает как делать
Мидл - не знает что делать, но знает как делать
Синьор - знает что делать и знает как делать
Тут все трое а-ля "молодцы" сами сделали задание :) Это что-то типа около Middle.
Так же я хотел показать что это специалисты характера - "Ой, я сам знаю как лучше". Поэтому они ни с кем не обсуждали своё решение (которое, согласен с вами, упустил аналитик).
Но суть не в этом, мне понравилось ваше замечание про то, что они прокачают других до такого же уровня (делай тяп-ляп). Подскажите пожалуйста где я оставил брешь в системе? Её нужно срочно залатать :D Очень не хотелось бы чтобы экспертиза участников тянулась вниз. Т.е. как по вашему мнению используя груминги и совместную работу над задачей они потянут за собой остальных?
А что касается про тестирование требований - я и так уже переживал что получился слишком лонгрид, надо было сокращать )
Сергей, статья понравилась бы больше, если бы закончилась чем-то более полезным, чем просто "здравый смысл важен всегда".
Я, как бизнес-аналитик со стажем, могу еще добавить, что было бы неплохо US все-таки писать по принятому формату "Я, как пользователь ... хочу ..., чтобы ...". Это отразило бы бизнес-ценность фичи и дало бы дополнительную почву для вопросов к аналитику со стороны команды, а это поддерживает адекватность и градус "здравого смысла" в команде.
И кстати про US, так и не нашла его в статье(
Я немного в растерянности, но "здравый смысл" - это полезная вещь, как бы это странно не звучало :) Возможно я не совсем понял ваш посыл. Расскажите подробнее?
Что касается по принятому формату, я об этом отдельно писал https://habr.com/ru/company/otkritie/blog/648155/ тут всё по полочкам... хотя этих "полочек" я бы добавил побольше, но боюсь что большие тексты тяжело читать.
US в этой статье и есть некий "воз" из басни Крылова. Она тут образно выражаясь так сказать.
В названии "UserStory", а в тексте речь идет о детальном "ТЗ". ИМХО, бизнес-аналитик не должен в описании требований указывать как их реализовывать. Он пишет ЧТО должна делать система, но не указывает КАК она должна это делать. БА описал требуемое поведение системы и аксептанс-критерии. А в каком формате фронт будет общаться с бэком - решает команда (возможно вместе в архитекторами, если они есть на проекте).
Хорошая статья. Мы методом проб и ошибок тоже пришли к такой же схеме взаимодействия. Груминг - вот как называются наши презентации ТЗ разработчикам и тестировщикам! Буду знать. :-)
Мы еще на такие презентации подключаем продакт оунеров. И вот когда от всех приглашенных получен фидбек и апрув, тогда ТЗ передается в разработку. В идеале еще должны быть дизайн-макеты готовы и представлены на таких грумингах.
Тестировщики, кстати, тоже могут давать вполне себе дельные советы по реализации на таких грумингах.
А изменения в ТЗ мы фиксируем в разделе "Изменения" с обязательным описанием причин изменений. Особенно это актуально для сложных задач.
Да, вот эти все ошибки и боли мы проходили. И продакт оунеры должны быть на груминге и тестировщики. Всё верно :) Изначально я и хотел описать полностью как выглядит этот всё дело, но в процессе написания статья получилась оооооооочень длинная. Решил что это будет издевательство на читателями )
Кстати, пока от всех не будет получен апрув - действительно не стоит брать в разработку ТЗ. Это золотое правило! Могут быть ограничения, но это крайне редкие случаи, и они обсуждаются индивидуально к каждой задаче.
А что за «вотерфлоу»?
А по теме - хотелось бы послушать как у вас решаются задачи без участия аналитика, наверное вообще кровавое рубилово, скинуть ответственность то некуда…
Или аналитиков всегда хватает на все задачи? Какой тогда уровень здравого смысла у разработчиков? Или они в доту только и рубятся?
По поводу "Вотерфлоу" надеюсь это был вопрос с сарказмом про "Вотерфолл" :)
Кстати, интересная тема про "А как же быть без аналитика?" ? Надо будет попробовать написать про это ) Такой опыт тоже имеется в бардачке. А вот кровавое рубилово мы как раз исключили - об этом и повествует статья ;)
Да, сарказм присутствует :)
У нас аналитиков хватает не на всех, часть задач, хорошо это или плохо, идут вообще без анализа. Разработчики ваяют в режиме свободного художника.
Я из статьи сделал вывод, что аналитик в итоге сделал правильное ТЗ, уточнил его по результатам обсуждения на дэйлике и всем стало хорошо.
А вот если самого ТЗ нет, уточнять нечего и некому фронт и бэк остаются один на один и … что тогда?
Хм... ну по поводу того хорошо или плохо что задачи идут без анализа я бы сказал что - плохо. Объясню почему.
Я считаю что разработчик, хороший разработчик, должен сам уметь разобраться с задачей и сделать её качественно даже если будет отсутствовать системный аналитик. Так же разработчик не должен 100% расчитывать что тестировщик отловит баги. Разработчик должен понимать что он пишет и как это аффектит на систему. И тут, казалось бы, почему же я считаю плохой ситуацию когда задача выполнялась без системного аналитика? Тут всё просто - отсутствует важный артефакт, отсутсвует документация! Т.е. после системного аналитика остаётся хоть какой-то след, прочитав который можно быстро погрузиться в детали реализации самой задачи. Команда меняется, люди меняются, и вновь прибывшим коллегам на проект очень хотелось бы иметь какую-то информацию по функционалу и т.д.
Если попробовать разобрать вопрос когда фронт и бэк остаются один на один - ну что тут сказать. Ситуация хоть и неприемлемая, но допустимая, такое бывает. В данном случае тут надо идти по пути данных, т.е. от инициатора до исполнителя.
В данном случае инициатором будет фронт разработчик, т.к. он отправляет данные в бэк. И вот на каждом этапе взаимодействия между фронтом и беком от инициатора к исполнителю должно придти предложение как будет выглядеть формат взаимодействия. Далее оба участника либо соглашаются на такое взаимодействие, либо обсуждают и приходят к какому-то совместному решению. Т.е. проще говоря не должно быть ситуации когда данные переходят от фронта к беку или наоборот, а вот формат передачи и перехода данных остался без обсуждения. Это важная составляющая взаимодействия фронта и бека без системного аналитика.
Но опять, в данном случаем мы хоть и получим реализацию, но потеряем в документации :(
Почему UserStory и ныне там?