Comments 23
Основная проблема, с котороя я сталкиваюсь в последние годы - это неспособность бизнеса четко ответить на вопрос ЧТО мы делаем. Продукт оунеры часто либо неспособны сформулировать свою мысль, либо вместо ответа на вопрос ЧТО пытаются ответить на вопрос КАК. Все это почему то оправдывается Agile методологией - дескать так Скрам велит. Как результат - разработчики очень быстро, очень эффективно и очень"гибко" бегают по кругу.
Бог с ним с ТЗ, но вот хотя бы такая простая постановка задачи в Confluence способна разорвать этот замкнутый круг, и уменьшить стоимость разработки в разы. Респект!
Скрам все же не велит, чтобы в голове у заказчика была каша. Скрам оптимистично исходит из того, что заказчик как раз имеет желаемый образ, но не имеет ресурсов описать его языком ТЗ. И тогда и начинается "схватка", имеющая результатом дорожную карту, устраивающие все стороны.
Если в голове таки каша, то толку от конфлюенса (и любой другой системы) тоже ноль.
Не скажите. Написание постановки в конфлюенсе на несколько порядков дешевле разработки. Пусть уж лучше продакт оунер бегает по кругу в конфлюенсе, чем вся команда разработчиков будет бегать по кругу в git'е. И в первом и во втором случае проект провалится, но в первом случае компания потеряет гораздо меньше денег.
Если исполнители будут из-за частой "смены требований от владельца продукта" перерабатывать, то каких-то пиков или падений графиков у руководителя этого владельца продукта не будет. А если он не умеет рефлексировать, то...
Короче, за 8 лет я только один раз в одной компании встретил случай, когда задача была подробно описана и задокументированна. Ее писал бизнес- аналитик. Потом этого аналитика сделали менеджером и он стал ставить задачи в 1-2 строчки.
Я не знаю какой тут вывод нужно сделать.
Я не знаю какой тут вывод нужно сделать.
Вывод уже сделал Михаил Афанасьевич Булгаков почти 100 лет назад.
"Разруха не в клозетах, а в головах"!
Как показывает моя практика, часто под "изменениями рынка за один день" маскировалась чья-то плохая работа или лень.
Ну не может проектироваться интерфейс, а потом когда его реализовали, потыкать и сказать, что все гадость, надо переделать. Просто важное лицо поленилось вдаваться подробности и нашло это на этапе приемки.
В целом согласен. Но, ИМХО, какое то краткосрочное проектирование все таки нужно делать. Хотя бы для того, чтобы продакт и разработчики разговаривали на одном языке. И не играли в испорченный телефон. Грубо говоря, договорились в какой то спринт сделать новый функционал - пошли в confluence, зафиксировали договоренности. Нельзя оставлять все только на словах. Иначе у продакта в голове будет одна картинка, а у разработчика совсем другая. И дальше начминается - "я не это имел ввиду...", "а помнишь, мы еще договаривались..." и т.д. и т.п.
Новый термин придумал - "Микро-ТЗ" :)
Молодой дружный коллектив, скрам, печеньки. Гибко пилим микосервисы по микро-тз!
Потом этого аналитика сделали менеджером и он стал ставить задачи в 1-2 строчки.
Я не знаю какой тут вывод нужно сделать.
Это иллюстрация принципа Питера, вроде.
Работа в госорганах, показала, что написание ТЗ долгая и нуд(ж)ная задача. Она дорогая. Но, я попал в большую ИТ компанию, в проектах где царит неразбериха Agile. Работал и там и там. Чесно, Agile разочаровал. Либо люди не умеют его готовить либо это муть, реально, больше хаоса, теледвижения, непонятных совещаний 1000щи и результат, итеративные доделывания.
Нет, я не то, чтобы совсем против Agile (не подумайте), наверное, хорошая штука, но я мало видел, где ее готовят годно, плюс как в художестве, надо начинать классические методы, если умеешь, иди в сюреализм, так и здесь мне кажется, надо всем начинать с ТЗ, а потом идти в гибкость). .... но спасибо, что тема поднята.
Судя по загловку, уже надеялся увидеть чудо Чудо!
Однако чуда не случилось. А по факту получилось переосмысление, адаптация и формализация того, что обычно и описывается в техническом задании, но представлено это у Вас в том виде, в котором команде удобно работать. Как ни крути, а без ТЗ никуда :)
Я бы даже так сказал — у нас бывают случаи, когда задача в jira ставится одним предложением. Значит ли это, что у нас нет ТЗ? Вовсе нет — просто задача ставится одним человеком, который в теме, другому человеку, который тоже в теме. То есть у них у обоих есть в голове представление о том, как работает система. И постановка задачи сводится к тому, что нужно изменить. Если изменение можно описать одним предложением/абзацем — это тоже будет ТЗ. Но только член команды, который разбирается в предмете, сможет его реализовать, а скажем новичок — уже вряд ли, и ему придется расписать задачу подробнее.
Я правильно понимаю, что посыл статьи - это заменить одно большое ТЗ на ТЗ, разбитое по фичам?
Если да, то исходная проблема никуда не делась, правильно?
Фичи по-прежнему хочется описывать в деталях, покрывая edge cases, etc. - просто куски описания стали меньше. Но, чтобы это делать, нужно время и квалификация.
ТЗ по-прежнему устаревает после очередной итерации. Нужно писать либо новое ТЗ на фичу, либо переписывать старое. Чтобы это делать, нужно время и квалификация.
Можно трактовать и так. В моей практике такой подход зашёл. И он устраивает и постановщиков задачи и исполнителей.
С более мелкими фичами легче работать. Проще описать, тем более когда работа коллективная.
Не устаревает. Так как работа над изменениями начинается с описания. Сначала меняется описание, потом ставится таск в трекере. Наличие истории в конфлюенсе помогает если в процессе доработки нужна информация о текущей реализации.
А на серверную часть вы требования не пишете? И на сценарии взаимодействия мобильного приложения с сервером?
Что вы имеете ввиду под требованиями к серверной части?
Если речь об апи и взаимодейстии фронт-бек, то обычно просиходит таким образом:
Фронт-разработчик ознакамливается с задачей, с дизайном. На основании этих вещей составляет требования к апи. Это могут быть как новые роуты, так и существующие. Описывается какие данные передаются и в каком виде. Описывается какие данные хочется получать. Дальше это передаётся бэк-разработчику. И либо принимается к исполнению либо явлается основанием для обсуждения где совместно вносятся коррективы.
Если про нагрузку и скорость ответа. То отдельно к фукнционалу эти требования обычно не пишутся, так как мы знаем нашу посещаемость и темпы роста. Эти параметры были обгововоерны один раз и закреплены. За работоспособностью следят девопсы и админы.
Надеюсь смог ответить на ваш вопрос. :)
Обычно пользовтельский сценарий отображает путь пользователя по экранам, с которых делаются запросы к серверу, соответственно получается ответ от него. Каких-то отдельных сценариев взаимодействия приложения с сервером нет. Мы всегда рассматриваем общение клиента с сервером с точки зрения необоходимости пользователя.
Имея описание, довольно легко разделить его на задачи и оформить в таск-трекере. Зачастую раздел это эпик, фукнционал это юзерстори а экраны это задачи. Внутри задач создаются подзадачи на отдельные аспекты реализации.
Если эпик = раздел, то эпик становится бесконечным по мере развития продукта, соответственно теряется его смысл в контексте управления задачами.. Мы как раз уходим от этого. Видится правильнее юзерстори = эпик. По описанию разделов делаю аналогично и актуализирую по мере фактической разработки и тестирования. Проблема остается в синхронизации сторей и описаний разделов) Вы как то это решаете?
Думаю вы нашли неточность в статье. Спасибо. :)
Эпик это не сам раздел. Эпик это совокупность работ для реализации раздела либо изменений в разделе.
В этой статье моей целью было рассказать про форму. Про её примеренние, пожалуй, можно написать отдельную статью. Здесь я решил кратко отобразить способ работы с этой формой, так как мне показалось что без этого статья была неполная.
Для решения проблемы синхронизации сейчас пробуем два способа:
В тикете указывается конкретная версия страницы (из истории изменений) на которую нужно смотреть при реализации либо при проверке.
Прям на странице описания есть плашка указывающая какая версия описания является актуальной для приложения находящегося в проде/тесте.
Разработка без ТЗ