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